L'Infrastructure des Agents de Coding : Ce Que TraceLab Nous Apprend sur la Réalité du Terrain

L'armement en outils de coding IA a clairement changé de braquet. Claude Code, Codex, Gemini CLI — tout le monde les a testés. La vraie question n'est plus "est-ce que ça marche ?" mais plutôt : comment on fait pour servir ces bestioles à l'échelle sans que ça coûte une fortune et sans latency qui donne envie de balancer son clavier par la fenêtre ?

Une équipe de l'University of Washington, le labo SyFI, vient de publier des chiffres concrets sur ce que représentent réellement les workloads des agents de coding. Et honnêtement, ça devrait faire réfléchir pas mal de monde. Spoiler : votre infrastructure de serving LLM actuelle est probablement mal optimisée pour ce cas d'usage.

La Révolution Autonome que Personne N'avait Prévue

Voilà le truc qui paraît évident quand on y pense : les agents de coding ne se contentent pas de répondre à des questions. Ils exécutent des plans. Quand vous demandez à un assistant IA de implémenter une feature ou corriger un bug, vous ne lancez pas une simple transaction question-réponse. Vous déclenchez un workflow autonome où le modèle raisonne, exécute des commandes shell, lit et modifie des fichiers, lance des tests, et itère jusqu'à satisfaction (ou jusqu'à ce que vous l'interrompiez).

L'équipe de recherche a capturé plus de 4 300 sessions réelles représentant environ 55 milliards de tokens. Les patterns qui émergent sont marquants. Chaque requête utilisateur déclenche en moyenne 8.8 cycles LLM-tools avant complétion. Comprenez : pour chaque question d'un développeur, il y a presque neuf allers-retours entre génération du modèle et exécution d'outils. Le modèle ne parle pas juste — il agit. Et 88% de tous les tours d'inférence LLM ne sont pas des réponses à l'utilisateur mais à des résultats d'outils.

Ça change tout pour la planification du throughput. Les chatbots traditionnels sont fondamentalement des systèmes request-response avec quelques follow-ups occasionnels. Les agents de coding ressemblent davantage à des processus autonomes longue durée avec des context-switchings fréquents entre phases de génération et d'exécution. Vos politiques d'autoscaling, votre request queuing, vos stratégies de caching — tout ça doit être repensé sous l'angle des workflows multi-step autonomes plutôt que de simples conversations alternées.

L'Asymétrie Input-Output qui Sabote Votre Cache

Voici un chiffre qui devrait faire dresser les cheveux de tout engineer infrastructure : les inputs dépassent les outputs dans un ratio de 294 contre 1. Dans les traces analysées, les modèles ont lu 52.56 milliards de tokens d'input en cache et préfillé 2.34 milliards de nouveaux tokens, tout en générant seulement 186.9 millions de tokens de output. Un tour typique se situe sur un préfixe de 32K à 256K tokens et ajoute juste quelques centaines à quelques milliers de tokens avant de décoder quelques centaines en output.

Ça crée un profil de performance fondamentalement différent de ce que la plupart des systèmes de serving LLM optimisent. L'inférence de modèle de langage traditionnel se concentre lourdement sur le throughput de génération — combien de tokens par seconde peut-on produire ? Mais pour les agents de coding, le bottleneck n'est souvent pas la vitesse de decoding ; c'est le time-to-first-token (TTFT) après le retour d'exécution d'outil. L'équipe a trouvé que le TTFT de Codex pour chaque étape tourne autour de 3.1 secondes, soit environ 25% du temps total de génération d'un tour. Quand vous faites neuf tours par requête, cette overhead se cumule vite.

Le picture du caching est aussi plus nuancé qu'il n'y paraît au premier abord. Oui, le caching d'input (prefill caching) aide avec l'immense contexte que les agents de coding transportent. Mais le workload de prefill se divise entre les tokens en cache et les nouveaux tokens qui nécessitent du calcul réel. Les préfills courts et incrementaux après exécution d'outil ont des caractéristiques de performance différentes du chargement initial de long contexte. Les systèmes de serving doivent gérer les deux efficacement, et les stratégies optimales peuvent différer entre ces cas.

Les Commandes Shell Mangent le Monde (Toujours)

Si vous pensiez que les agents de coding feraient du raisonnement sophistiqué et du refactoring complexe, vous n'aviez pas tort — mais la réalité est plus bordélique. Sur les 433 000 appels d'outils capturés dans les traces, 76% étaient des exécutions shell ou commandes. Lancer des builds, des tests, des opérations git, des manipulations de fichiers via des outils CLI — le truc peu glamour qui constitue le quotidien réel du développement logiciel.

Les edits de fichiers représentent 11%, les lectures et recherches de fichiers 9%, avec la planification, la delegation à des sous-agents et les recherches web qui complètent le reste. Cette concentration sur les commandes shell compte pour plusieurs raisons. D'abord, ce sont des opérations à queue longue : un simple ls est rapide, mais lancer une full test suite ou compiler un gros codebase peut prendre des minutes. La distribution de latency s'étend sur quatre ordres de grandeur, ce qui fait du capacity planning un cauchemar.

Ensuite, le vocabulaire d'outils varie significativement entre les agents. Claude Code utilisait 54 outils différents tandis que Codex en avait 31, mais les deux concentraient l'immense majorité de leur volume sur le même ensemble core — shell, edits de fichiers, lectures de fichiers. Ça suggère que'optimiser pour ces outils high-frequency pourrait donner des améliorations disproportionnées, même sans s'attaquer à tout l'écosystème d'outils.

Ce Que Ça Signifie pour Votre Infrastructure

Si vous construisez ou opérez des outils de développement alimentés par IA, cette recherche pointe vers plusieurs takeaways concrètes.

Pensez en workflows, pas en requêtes. Votre infrastructure de serving doit intégrer la nature autonome et multi-step des agents de coding. Ça signifie des contexts de requêtes plus longs, une gestion d'état plus sophistiquée, et des opportunités de batch scheduling qui regroupent les appels d'outils liés.

Optimisez pour les gaps d'idle. Les utilisateurs passent en moyenne 46.7 minutes entre les requêtes, pour un think time médian de seulement 1.4 minute. La distribution est extremely heavy-tailed — certains développeurs itèrent rapidement pendant que d'autres lancent une requête et reviennent des heures plus tard. Du prefetching malin et des stratégies de re-prefill pendant ces périodes d'idle pourraient réduire drastiquement la latency perçue sans augmenter les coûts de compute.

Séparez vos chemins prefill et decode. Le ratio input-output de 294:1 signifie que votre computation de prefill est probablement votre coût dominant. Les préfills incrementaux après exécution d'outil nécessitent des optimisations différentes du chargement initial de contexte. Envisagez des pools de ressources séparés ou des politiques de scheduling pour ces types de workload différents.

N'oubliez pas l'infrastructure d'exécution d'outils. Quand 76% de l'activité de l'agent ce sont des commandes shell, votre container orchestration, vos patterns d'accès filesystem et votre caching d'outils de build deviennent des préoccupations de première classe pour le serving d'agents IA. L'inférence du modèle n'est qu'une partie du pipeline.

La Route Devant

L'équipe TraceLab a open-sourcé leur pipeline de collection et analyse de traces, rendant possible pour les équipes infrastructure de générer leurs propres traces et d'optimiser pour des patterns d'usage réels plutôt que des benchmarks synthétiques. Ce genre de données real-world est exactement ce dont l'espace AI infrastructure a besoin pour maturir du "faites-le fonctionner" au "faites-le fonctionner à l'échelle."

Pour la communauté NameOcean Vibe Hosting, ces insights highlight pourquoi on investit dans une infrastructure qui va au-delà de la simple allocation GPU. Servir des agents de coding IA ne se résume pas à du compute brut — c'est comprendre les caractéristiques uniques des workloads agentic et construire des systèmes capables de gérer la réalité autonome, multi-step et tool-heavy de comment les développeurs utilisent vraiment ces outils.

L'ère de l'agent de coding ne fait que commencer, et les décisions d'infrastructure qu'on prend aujourd'hui vont façonner l'efficacité avec laquelle ces outils serviront les développeurs pendant des années. Choose wisely.