De 6,7 % à 68,3 % de tâches réussies : c'est le harness, pas le modèle, qui fait une différence de 10x

Le taux de réussite de Grok Code Fast sur le benchmark de codage était de 6,7 %. Sans changer le modèle, en remplaçant uniquement le format d’édition, ce taux est passé à 68,3 %. Pas un seul bit des paramètres du modèle n’a été modifié.

En faisant tourner des agents moi-même pendant les vacances, j’ai vécu quelque chose de similaire. Les sorties de modèles s’enchaînent à un rythme vertigineux, mais ce qui a radicalement différencié les performances en pratique n’était pas le modèle lui-même. C’était le harness qui l’entoure : la combinaison du prompt système, de la configuration des outils et du middleware.

Même modèle, classement différent

L’équipe LangChain a fait tourner Terminal Bench 2.0 avec son propre agent de codage. En gardant GPT-5.2-Codex intact et en retouchant uniquement le prompt système, la configuration des outils et le middleware, le score est passé de 52,8 à 66,5, et le classement est passé de hors top 30 à top 5. Coût d’entraînement du modèle : zéro.

Le point clé était la distribution du budget de raisonnement. Appliquer xhigh à toutes les tâches de manière uniforme plafonnait le résultat à 53,9 %, mais le répartir en xhigh-high-xhigh selon la difficulté des tâches a permis d’atteindre 66,5 %. Les problèmes qui échouaient par dépassement de délai ont été résolus grâce à cette stratégie de distribution. Même modèle, même budget de tokens, seule la répartition différait.

La vraie capacité masquée par le format d’édition

Un développeur d’agent open source a créé une méthode d’édition appelée hashline. Lors de la lecture d’un fichier, chaque ligne reçoit un tag de hachage de 2 à 3 caractères ; lors de la modification, le modèle ne fait référence qu’à ces tags.

Avec l’ancienne approche, le modèle devait reproduire le texte original sans la moindre erreur. Un seul espace mal placé suffisait à provoquer un échec. Quiconque a utilisé un agent de codage connaît la douleur des erreurs “String not found” qui se répètent. hashline contourne ce problème de manière structurelle.

Les résultats ont été spectaculaires. Grok Code Fast est passé de 6,7 % à 68,3 %, et Grok 4 Fast a réduit ses tokens de sortie de 61 %. GPT-4 Turbo est passé de 26 % à 59 % rien qu’en changeant le format, et Gemini 3 Flash a dépassé son ancien record de 5 points de pourcentage. Sans aucun coût d’entraînement, uniquement en changeant l’interface d’édition.

Sans boucle de validation, l’agent s’arrête à la première réponse

Le schéma d’échec le plus fréquent est le suivant : l’agent écrit du code, relit ce qu’il vient d’écrire, juge que c’est correct, puis s’arrête là sans avoir exécuté le moindre test.

L’équipe LangChain a intégré un middleware qui force une validation par rapport aux spécifications de la tâche juste avant la fin de l’agent. Une autre pièce de middleware détecte les “doom loops”, c’est-à-dire les éditions répétées du même fichier, et pousse l’agent à reconsidérer son approche. Sans ces deux mécanismes, la progression des scores aurait été bien plus modeste. Injecter à l’avance la structure des répertoires et les outils disponibles dans l’agent, puis utiliser des alertes de budget temps pour inciter l’agent à entrer en phase de validation, s’est également révélé efficace.

Plus un modèle est bon marché, plus il est sensible au harness

MiniMax M2.5 et Kimi K2.5 sont rapides, habiles dans l’utilisation des outils d’agent, et leur prix est bien inférieur à celui des grands modèles. En contrepartie, leurs connaissances de base sont moins solides que celles des grands modèles américains. MiniMax donne l’impression d’avoir été entraîné dès le départ pour des cas d’usage agents. Faute de ressources suffisantes pour la généralisation, ils ont opté pour la spécialisation, et leur faible coût leur vaut une adoption en forte croissance sur des plateformes comme Openclaw.

Les résultats du benchmark hashline montrent que plus un modèle est faible, plus l’amplitude des variations de performance liées au changement de format est extrême. MiniMax a vu son taux de réussite plus que doubler après l’application de hashline. Le coût total du benchmark s’élevait à environ 300 $.

Le benchmark n’est pas la production

Un point mérite attention. Qu’il s’agisse de Terminal Bench ou du benchmark hashline, les chiffres sont mesurés dans un environnement contrôlé. En production réelle, les variables sont bien plus nombreuses : taille du code source, conflits de dépendances, exigences ambiguës. Qu’un agent ayant affiché 66,5 % sur un benchmark maintienne ce niveau sur un projet legacy de 100 000 lignes reste à démontrer. L’optimisation du harness est clairement efficace, mais convertir directement un classement de benchmark en performance de production est risqué.

La direction est néanmoins claire. Il existe bel et bien une zone où la conception du harness surpasse le choix du modèle en termes de ROI. Une bonne partie des classements de benchmarks que nous observons aujourd’hui reflète non pas la qualité du modèle, mais celle du harness.