🤖 AI

The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation

Cet article démontre que l'environnement d'évaluation influence de manière significative la performance et l'efficacité des agents de codage — souvent plus que le choix du modèle sous-jacent — en révélant des variations d'utilisation de jetons allant jusqu'à un facteur de 40 et des schéages d'échec indépendants du modèle, plaidant ainsi pour la publication des spécifications complètes de l'environnement ainsi que des métriques de jetons et de latence aux côtés des comparaisons de modèles.

Auteurs originaux : Naman Vats, Oleg Golev

Publié 2026-07-28

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Naman Vats, Oleg Golev

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

La main invisible derrière le codeur robotique

Imaginez que vous regardez un concours de cuisine. Vous voyez deux chefs brillants, le Chef A et le Chef B, tous deux essayant de préparer le gâteau au chocolat parfait. Les juges se contentent généralement de regarder le gâteau final et disent : « Le Chef A a fait un meilleur gâteau ! » Mais et si les juges avaient oublié de mentionner que le Chef A utilisait une cuisine automatisée de haute technologie qui pré-découpait chaque ingrédient et préchauffait le four à la seconde près, tandis que le Chef B travaillait dans un cabanon poussiéreux avec un couteau rouillé et un poêle cassé ? Le résultat ne dépend pas seulement du talent des chefs ; il dépend de la cuisine qui leur a été donnée.

Dans le monde de l'intelligence artificielle, plus précisément pour les « agents de codage » (des programmes d'IA qui écrivent des logiciels), nous avons fait exactement cela. Nous avons classé les modèles d'IA en fonction du nombre de problèmes de codage qu'ils résolvent, tout en ignorant la « cuisine » dans laquelle ils travaillent. Cette cuisine est appelée un harnais (harness). Considérez un harnais comme l'assistant invisible qui remet ses outils à l'IA, gère sa mémoire et décide quand arrêter le travail. Certains harnais sont comme un majordome robotique ultra-efficace qui organise tout parfaitement ; d'autres sont comme un stagiaire chaotique qui pose sans cesse la même question, gaspillant temps et énergie. La grande question que se posent les chercheurs est la suivante : le cerveau de l'IA importe-t-il plus, ou la qualité de son assistant est-elle plus importante ?

La grande expérience de la « cuisine »

Une équipe de chercheurs a décidé d'arrêter de deviner pour commencer à mesurer. Ils ont mis en place une expérience massive pour voir ce qui se passe lorsqu'on échange la « cuisine » (le harnais) tout en gardant le « chef » (le modèle d'IA) exactement le même. Ils ont choisi deux modèles d'IA de codage très intelligents, Qwen 3.6 Plus et MiniMax M2.5, et leur ont demandé de résoudre 50 puzzles de codage différents. Mais voici le rebondissement : ils ont fait passer ces mêmes modèles à travers trois harnais open-source différents, nommés Goose, OpenCode et OpenHands-SDK.

Les résultats ont été, pour le moins, choquants.

Lorsque les chercheurs ont examiné le nombre de puzzles résolus par l'IA (le « taux de réussite » ou pass rate), la différence entre les harnais était infime. Que l'IA utilise Goose, OpenCode ou OpenHands-SDK, elle résolvait à peu près le même nombre de problèmes — généralement entre 38 % et 50 %. Changer le harnais ne rendait pas l'IA soudainement géniale ou ratée ; le taux de réussite restait globalement stable.

Cependant, lorsqu'ils ont examiné le coût de la résolution de ces problèmes, l'histoire a totalement changé. Les chercheurs ont mesuré cela en « tokens », qui sont essentiellement les unités de données que l'IA traite (comme des mots ou des morceaux de code). Ils ont découvert que le choix du harnais modifiait le coût de façon vertigineuse : 40 fois.

Pour mettre cela en perspective : si le harnais Goose aidait l'IA à résoudre un puzzle en utilisant environ 28 000 tokens, le harnais OpenCode faisait utiliser à l'IA exacte plus de 1,1 million de tokens pour résoudre le même puzzle. C'est une différence de coût de 40 fois pour le même résultat ! C'est comme si un chef utilisait un seul œuf pour faire un gâteau, tandis qu'un autre chef en utilise 40 pour le même gâteau, simplement parce que les outils de sa cuisine sont inefficaces.

La taxe du « tour d'inactivité »

Pourquoi le coût a-t-il autant augmenté ? Les chercheurs ont découvert un coupable caché : les tours d'inactivité (idle turns).

Imaginez que vous parlez à un ami qui essaie de réparer votre ordinateur. Parfois, il reste là à réfléchir : « Hmm, laissez-moi vérifier ceci... » sans rien taper ni rien changer à l'écran. Dans le monde de l'IA, on appelle cela des « tours sans action ». Le harnais OpenCode faisait stagner l'IA dans ces boucles de réflexion environ 2 fois par tâche, alors que le harnais Goose ne le faisait que 0,2 fois.

Chaque fois que l'IA s'arrête dans l'une de ces boucles, elle doit renvoyer tout l'historique de sa conversation au serveur pour garder une trace de là où elle en est. C'est comme envoyer un journal de 100 pages à chaque fois que vous faites une pause pour réfléchir. Parce qu'OpenCode faisait faire à l'IA des pauses de réflexion beaucoup plus souvent, elle consommait des tokens à un rythme massif. Les chercheurs appellent cela la « taxe d'attente par tâche ». Ce n'est pas seulement un coût financier ; c'est un coût en temps. Un développeur humain qui regarde l'IA doit attendre à travers ces boucles d'inactivité, fixant un écran qui ne fait rien, brûlant ainsi de l'argent et de la patience.

L'« empreinte digitale » de l'échec

L'étude a également révélé que chaque harnais possédait sa propre manière unique d'échouer, comme une empreinte digitale. Ces schémas ne changeaient pas selon le modèle d'IA utilisé ; ils étaient causés par le harnais lui-même.

Goose était le prudent. Lorsqu'il était bloqué, il s'arrêtait et disait : « Je ne peux pas faire ça », plutôt que de deviner. Il perdait rarement du temps à essayer de vérifier une mauvaise idée.
OpenHands-SDK était le persistant. Il continuait à essayer de vérifier ses réponses ou à s'exécuter jusqu'à ce qu'il atteigne une limite stricte sur le nombre de tentatives (la limite des « tours maximum »).
OpenCode était celui qui s'enlisait dans des boucles. Il épuisait son temps (la limite de « temps de calcul » ou wall-time) ou restait bloqué dans un état de « suspension » (hang), tournant en rond sans jamais terminer.

Cela signifie que si vous êtes un développeur, vous ne choisissez pas seulement une IA ; vous choisissez un style d'échec. Voulez-vous une IA qui abandonne rapidement et honnêtement, ou une qui continue de patiner jusqu'à ce que vous perdiez patience ?

La grande leçon

La principale leçon de cet article est que nous avons mal interprété les tests de référence (benchmarks) de codage par IA. Nous avons classé les modèles comme Qwen ou MiniMax comme si elles étaient les seules choses importantes. Mais cette étude montre que le harnais (la cuisine) est tout aussi important que le modèle (le chef).

Si vous voulez savoir combien une IA vous coûtera réellement ou combien de temps elle mettra pour terminer un travail, vous ne pouvez pas simplement regarder le nom du modèle. Vous devez regarder la paire : le modèle et le harnais dans lequel il fonctionne. Un modèle intelligent dans un mauvais harnais peut être 40 fois plus coûteux qu'un modèle intelligent dans un bon harnais.

Les chercheurs suggèrent qu'à l'avenir, nous ne devrions pas seulement rapporter le « Taux de réussite » (Pass Rate). Nous devons rapporter le coût par tâche résolue, le nombre de tours d'inactivité et les schémas d'échec. Car pour un véritable développateur humain, la différence entre un taux de réussite de 50 % qui coûte 1 $ et un taux de réussite de 50 % qui coûte 40 $, c'est la différence entre un outil utile et un gouffre financier. L'« Effet de l'Échafaudage » (Scaffold Effect) est réel, et il est temps de cesser d'ignorer la main invisible qui guide le robot.

Résumé Technique : L'Effet de l'Échafaudage dans les Agents de Codage

Problématique
Les classements publics actuels pour les agents de codage classent principalement les systèmes par nom de modèle et par taux de réussite, traitant l'« échafaudage » environnant (le harness qui émet les outils, gère le contexte et détermine la terminaison) comme une constante fixe ou sous-spécifiée. Cette approche confond la performance du modèle avec l'efficacité de l'échafaudage. Lorsque les échafaudages varient, les mesures de performance (taux de réussite) et les mesures d'efficacité (utilisation de tokens, latence) s'entremêlent, obscurcissant le coût réel et la charge de supervision nécessaire au déploiement d'un agent. L'article soutient que, pour une évaluation centrée sur l'humain, l'unité de comparaison doit être la paire échafaudage–modèle, et non le modèle seul, car l'échafaudage dicte les coûts réels et la nature de la supervision humaine requise.

Méthodologie
Les auteurs ont mené une étude contrôlée pour isoler les effets de l'échafaudage de ceux du modèle.

Modèles : Deux modèles de codage agentiques récents ont été évalués : Qwen 3.6 Plus et MiniMax M2.5.
Échafaudages : Trois échafaudages distincts en open-source ont été testés, chacun présentant des philosophies d'échafaudage différentes :
- Goose : Un agent IDE lourd avec injection préventive de l'arborescence des fichiers.
- OpenCode : Un agent à boucle d'outils persistante sans préchargement automatique du contexte.
- OpenHands-SDK : Une architecture de micro-agent comprenant la délégation de sous-agents, des tentatives internes et des étapes de vérification explicites.
Tâches : Un sous-ensemble stratifié de 50 tâches a été extrait de l'ensemble de données Terminal-Bench Pro, couvrant huit archétypes (Correction de bug, Construction, Données, Implémentation, ML, Puzzle, Sécurité, Système). Toutes les tâches utilisaient des suites d'évaluation pytest déterministes.
Protocole : Tous les essais ont été exécutés via l'API OpenRouter avec des instructions de tâche et des prompts système identiques (variant uniquement dans le vocabulaire spécifique aux outils). L'étude a maintenu constants le manifeste de tâche, l'environnement de bac à sable (sandbox) et la limite de temps de calcul (900 secondes), tout en permettant à chaque échafaudage d'opérer avec ses propres API d'outils, sa gestion de contexte et sa logique de tentative interne.
Métriques : L'étude a mesuré les taux de réussite, le nombre total de tokens par tâche résolue, le nombre moyen de tours, les « tours sans action » (tours sans édition de fichier ni nouvelle commande) et une taxonomie d'échec à six classes (RAISON, VÉRIFICATION, TEMPS, MAX TOURS, BLOCAGE, ERREUR). La signification statistique a été évaluée à l'aide d'intervalles de confiance par bootstrap de tâches appariées à 95 % ( $B=10\,000$ ).

Résultats Clés

Disparité du Coût en Tokens (L'écart de 40×) : Le choix de l'échafaudage a induit une différence massive d'efficacité. OpenCode a consommé environ 40× plus de tokens par tâche résolue que Goose (par exemple, ~1,5 M de tokens contre ~37 k tokens pour MiniMax). En revanche, la mise à niveau du modèle en maintenant l'échafaudage fixe n'a entraîné qu'une différence de 1,0–1,3× dans l'utilisation des tokens.
Stabilité du Taux de Réussite : Au sein d'un modèle fixe, les différences de taux de réussite entre les échafaudages étaient faibles, variant de 0 à 8 points de pourcentage. La plupart des différences par paires étaient statistiquement indiscernables de zéro (les IC à 95 % incluaient zéro), sauf pour l'écart le plus important.
Empreintes de Défaillance : Des modes d'échec spécifiques se sont reproduits sur les deux modèles, indiquant qu'il s'agit de propriétés de l'échafaudage et non du modèle :
- Goose : Dominé par les échecs de type RAISON (arrêt lorsqu'il est bloqué) avec zéro échec de type VÉRIFICATION.
- OpenHands-SDK : Caractérisé par des échecs de type VÉRIFICATION et MAX TOURS, indiquant une tendance à persister vers la clôture ou à épuiser les limites d'itération.
- OpenCode : Caractérisé par des échecs de type TEMPS et BLOCAGE (épuisement des limites de temps de calcul) avec zéro MAX TOURS (en raison de l'absence de flag de budget de tours) et zéro VÉRIFICATION.
Tours Sans Action comme Taxe de Supervision : OpenCode présentait 10× plus de tours sans action (boucles de raisonnement oisives) que Goose. Ces tours accumulent des tokens de contexte sans progresser, créant une « taxe d'attente par tâche » pour les utilisateurs humains qui doivent surveiller ces boucles oisives.
Efficacité de Pareto : Goose a dominé la frontière de Pareto, offrant des taux de réussite comparables aux autres échafaudages pour une fraction du coût en tokens. OpenCode était Pareto-dominé par les deux autres échafaudages.

Contributions Clés

Quantification de l'Effet d'Échafaudage : L'étude fournit une preuve contrôlée que le choix de l'échafaudage entraîne un écart de 40× dans les coûts de tokens tout en décalant les taux de réussite de moins de 8 points, démontrant que l'efficacité est largement une propriété de l'échafaudage.
Empreinte de Défaillance Indépendante du Modèle : Les auteurs identifient que les modes d'échec spécifiques (ex: RAISON vs VÉRIFICATION vs TEMPS) sont cohérents entre les différents modèles lorsque l'échafaudage est fixe, prouvant qu'il s'agit de biais structurels de l'échafaudage.
Proxy Mécaniste pour la Supervision : L'article introduit les « tours sans action » comme un proxy de la charge de supervision humaine, les présentant comme un coût (à la fois financier et temporel) que l'utilisateur humain dans la boucle doit absorber, distinct des simples coûts de tokens.
Unité d'Évaluation Proposée : Les auteurs soutiennent que la paire échafaudage–modèle est la bonne unité de comparaison pour une évaluation centrée sur l'humain, plutôt que le nom du modèle seul.

Signification et Revendications
L'article affirme que le reporting actuel des benchmarks est incomplet car il isole le modèle de l'échafaudage. En ne rapportant que les taux de réussite, les classements masquent le coût réel, la latence et l'effort de supervision requis pour déployer un agent. Les auteurs affirment que pour un déploiement pratique, les développeurs doivent évaluer les paires échafaudage–modèle sous des budgets spécifiques de tokens/latence. Ils recommandent que les évaluations futures rapportent les tokens par tâche résolue, le nombre moyen de tours sans action et les vecteurs de catégories d'échec aux côtés des taux de réussite pour fournir une vue holistique de la déployabilité d'un agent. L'étude ne prétend pas résoudre le problème de l'évaluation des agents, mais plutôt systématiser l'observation selon laquelle le « choix de l'échafaudage » est un moteur primaire de l'efficacité et des profils d'échec, dépassant souvent les mises à niveau du modèle.