- Des tests menés sur plusieurs LLM dans des conditions identiques montrent que les performances peuvent fortement progresser en ne changeant que l’outil de modification de code
- À la place des méthodes classiques Patch·Replace, l’application du format « Hashline », qui attribue un hash tag à chaque ligne de code, améliore la précision des modifications
- Hashline a montré une précision supérieure aux méthodes existantes sur 14 modèles sur 16, avec en plus une réduction moyenne de 20 à 30 % des tokens
- En particulier, le modèle Grok Code Fast 1 a vu son taux de réussite bondir de 6,7 % à 68,3 %, soit une amélioration par 10 grâce à un simple changement de harness
- L’étude montre que le véritable goulet d’étranglement des performances n’est pas le modèle lui-même mais le « harness », et souligne la nécessité d’une collaboration dans l’écosystème open source
Aperçu du benchmark d’édition de code
- L’expérience a comparé trois formats d’édition : Patch, Replace, Hashline
- 16 modèles ont été soumis aux mêmes tâches de correction de code
- Chaque modèle a été testé en corrigeant des bugs dans des fichiers sélectionnés aléatoirement au sein d’une base de code React
- Le format Hashline a obtenu de meilleurs résultats que Patch sur 14 modèles, tout en économisant en moyenne 20 à 30 % de tokens
- L’amélioration la plus marquée concerne le modèle Grok Code Fast 1, dont le taux de réussite est passé de 6,7 % à 68,3 % (+61,6 points)
- Gemini 3 Flash a progressé de 5,0 points, Claude Sonnet 4.5 de 1,6 point
Le problème du harness
- Les discussions actuelles se concentrent surtout sur la question de savoir « quel modèle code le mieux », alors que le véritable goulet d’étranglement est le harness, pas le modèle
- Le harness est l’interface centrale qui gère les tokens d’entrée et relie la sortie du modèle aux modifications du workspace
- La plupart des échecs proviennent non pas du modèle, mais de limites structurelles du harness
- L’auteur a cherché à améliorer cela via oh-my-pi, un projet personnel dérivé de l’agent de codage open source Pi, avec environ 1 300 commits
- Cet environnement est indépendant du modèle et permet des expériences où seul le harness varie
Les limites des outils d’édition existants
- La méthode
apply_patch de Codex utilise un format diff spécifique à OpenAI, ce qui entraîne un taux d’échec élevé avec d’autres modèles
- Exemple : taux d’échec des patchs de 50,7 % pour Grok 4, et de 46,2 % pour GLM-4.7
- La méthode
str_replace de Claude Code exige une correspondance parfaite de la chaîne, ce qui provoque des erreurs à cause des différences d’espaces ou d’indentation
- L’erreur « String to replace not found in file » a été signalée à de nombreuses reprises sur GitHub
- Cursor entraîne un modèle 70B distinct pour gérer la fusion, mais sur des fichiers de moins de 400 lignes, une réécriture complète (full rewrite) donne de meilleurs résultats
- Les recherches Diff-XYZ de JetBrains et EDIT-Bench ont également confirmé que les performances varient fortement selon le format d’édition
Le principe de la méthode Hashline
- Chaque ligne de code reçoit un hash de contenu de 2 à 3 caractères, afin que le modèle puisse désigner clairement la cible à modifier
- Exemple :
22:f1| return "world";
- Le modèle formule ensuite la demande de modification sur la base du hash, par exemple « replace line 2:f1 »
- Si le fichier a changé et que le hash ne correspond plus, la modification est refusée pour éviter toute corruption
- Cette méthode évite au modèle d’avoir à reproduire le contenu existant, ce qui réduit les erreurs d’espacement et d’indentation et permet des modifications plus stables
Résultats du benchmark
- Les tests comprenaient 180 tâches de correction de bugs, répétées 3 fois, avec 4 outils (
read, edit, write, etc.)
- Au final, le format Patch est le pire sur presque tous les modèles, tandis que Hashline est au moins équivalent à Replace, voire meilleur
- Plus le modèle est faible, plus le gain est important
- Grok 4 Fast a réduit ses tokens de sortie de 61 %, et MiniMax a plus que doublé ses performances
- Le gain de +8 % de Gemini est supérieur à ce qu’on observe généralement avec une mise à niveau de modèle, et a été obtenu sans entraînement supplémentaire
Politique des éditeurs et écosystème open source
- Anthropic a bloqué l’accès à Claude Code pour l’agent de codage open source OpenCode
- La raison invoquée est la « rétro-ingénierie d’API privées », mais cela a été interprété dans les faits comme un signal : « utilisez uniquement notre propre harness »
- Google a bloqué le compte de l’auteur, coupant l’accès à Gemini
- Cela s’est produit juste après un benchmark montrant que Gemini 3 Flash atteignait 78,3 % avec l’application de Hashline
- L’auteur estime que ces mesures sont contre-productives car elles bloquent des opportunités d’amélioration des modèles
- L’optimisation du harness relève d’une recherche d’intérêt public qui améliore la qualité de tous les modèles, et non d’un seul en particulier
- Avec la formule « le modèle est le fossé défensif, le harness est le pont », il souligne qu’une approche fermée freine le développement de l’écosystème
Conclusion
- Le problème du harness apparaît comme un facteur mesurable qui affecte directement les performances réelles
- Un simple changement de format peut produire un effet comparable à une mise à niveau de modèle
- La voie de progrès à suivre ne devrait pas être une amélioration fermée par une entreprise unique, mais une coopération ouverte fondée sur la communauté
- L’ensemble du code, des benchmarks et des résultats d’exécution est publié dans le dépôt GitHub oh-my-pi
3 commentaires
Le modèle est bizarre, alors pourquoi encore faire du prompt engineering...
Le harness et le prompt engineering sont deux choses totalement différentes.
Avis sur Hacker News
J’ai trouvé cet article vraiment intéressant à lire. À mon avis, l’auteur vise exactement juste.
Même avec les modèles actuels, il y a encore énormément de marge pour les rendre bien plus efficaces selon la manière dont on conçoit le harness agentique.
Je pense qu’il faut voir l’« IA » non pas simplement comme le LLM lui-même, mais comme l’ensemble du système cybernétique formé par le LLM et le harness reliés par une boucle de feedback.
Le modèle et le harness se renforcent mutuellement et évoluent ensemble, donc les deux sont tout aussi importants.
Cette perspective ne permet pas seulement d’améliorer les performances, elle aide aussi à réinterpréter l’IA générative comme un projet neurosymbolique
J’ai effectivement créé un agent de code avec la version 2023 de GPT-4.
Travailler avec un ancien modèle oblige à garder les choses simples, ce qui fait voir les problèmes autrement.
Par exemple, en Python, une compression sémantique simple comme
grep -r def .est indispensable.Si on ajoute ce genre de hook très simple à un outil comme Claude Code, il peut comprendre immédiatement la structure du code sans gaspiller de tokens
Avec seulement quelques heures de prompt tuning et un peu de code de traitement des réponses, la qualité de sortie de petits modèles locaux s’améliore de manière étonnante
Lien GitHub
OpenAI a utilisé une première version de GPT-5.3-Codex pour déboguer son propre processus d’entraînement et gérer les déploiements.
Claude Code soumet plus de 20 PR par jour, toutes générées par son propre code
En réalité, on ne sait même pas très bien quels modèles sont sensibles à une bonne ingénierie de contexte.
Mais je suis clairement d’accord sur le fait qu’il y a beaucoup de low hanging fruit
Cette technique est intéressante, mais elle donne une impression surévaluée.
L’auteur constate un gain de 5 % sur un benchmark simple de find/replace qu’il a lui-même créé, puis parle comme si la performance globale avait bondi de 14 points.
En pratique, il est probable que cela représente moins de 1 % d’amélioration sur l’efficacité globale en tokens.
En plus, le ton exagéré du texte et le style typique de ChatGPT nuisent à sa crédibilité
Cet article montre bien l’ampleur de la marge d’amélioration au niveau du harness.
Les agents gaspillent beaucoup de tokens dans l’édition, le sandboxing et le passage de données entre appels d’outils.
La combinaison adressage basé sur le contenu + numérotation des lignes est à la fois pratique et élégante
Cela facilite le développement initial, mais force à appeler des modèles inutilement énormes, ce qui est inefficace
Dans CC, la commande
/costpermet de voir le coût par session, et ce genre de métrique est utile pour évaluer l’efficacité d’un pluginL’importance du harness est bien plus grande que ce que la plupart des gens imaginent.
Par exemple, le score CORE benchmark d’Opus a presque doublé quand on a remplacé son harness interne par Claude Code
Lien associé
il explique aussi que le meilleur score sur TerminalBench venait du harness Terminus 2
Être enfermé dans un harness particulier à cause d’un abonnement à 20 dollars par mois n’est pas rationnel
J’ai créé un outil nommé tilth qui implémente une méthode de lecture/édition basée sur des hash.
Il peut être installé via npm et cargo, et s’intègre avec des éditeurs comme Claude Code ou Cursor
Lien GitHub
L’objectif est d’aider les LLM à utiliser les outils plus efficacement et à réduire le gaspillage de tokens
J’avais imaginé indépendamment une méthode similaire, mais je l’ai abandonnée à cause de la dépendance aux abstractions.
À la place, j’utilise la distance de Damerau-Levenshtein pour calculer la similarité des modifications, et si un certain seuil est dépassé, le changement est accepté.
Cela oblige le modèle à produire explicitement les tokens source à remplacer, ce qui améliore la précision
Exemple de code
Le point clé, c’est que les messages d’erreur doivent être spécifiques — une gestion d’erreur comme « Content mismatch. Reread the file » avec des instructions de récupération est importante.
Cette approche fonctionne bien même avec des modèles 4B, et pour les modèles qui ne prennent pas en charge les tool calls, je m’en sors avec un hack d’injection dans le prompt système
Code associé
Même avec d’anciens modèles, on pouvait obtenir des résultats assez précis.
L’essentiel était de « savoir les manier correctement ».
Cet article laisse entendre qu’on pourrait aller encore plus loin si les modèles ne manipulaient pas seulement du texte, mais directement une représentation structurelle du code (AST).
Par exemple, OpenRewrite utilise une Lossless Semantic Tree qui inclut le type du code, son format et les informations de dépendance.
Si les modèles pouvaient exploiter ce type de structure, ils pourraient effectuer des modifications très précises sans gaspillage inutile de tokens.
Au fond, c’est la même raison pour laquelle la réponse au débat « Vim vs Emacs » est « IntelliJ » — l’information structurelle est une arme redoutable.
Si un modèle apprenait conjointement le code, la documentation et les arbres syntaxiques/sémantiques, il deviendrait un véritable modèle de code neurosymbolique
En expérimentant les LLM dans Emacs avec gptel, j’ai découvert qu’ils étaient mauvais pour modifier du code avec l’outil Unix patch.
J’ai donc créé moi-même un outil pour gptel en utilisant tree-sitter d’Emacs.
En leur faisant modifier directement des nœuds AST avec des commandes comme
tree_sitter_list_nodesettree_sitter_update_nodes, ça a parfaitement fonctionnéLe
apply_patchde Codex utilise en réalité un schéma d’échantillonnage contraint.Code associé
L’auteur l’ignorait et a donc fait une comparaison simpliste ; un benchmark plus réaliste devrait être réalisé avec ce schéma activé
Parmi les citations de l’article, certaines m’ont particulièrement marqué
« Ce n’est pas que le modèle ne comprend pas le problème, c’est que la représentation est instable. N’accusez pas le pilote pour un problème de train d’atterrissage. »
« Le modèle est le moat, le harness est le bridge. »
« La différence entre une démo bluffante et un outil fiable, ce n’est pas la magie mais une ingénierie ennuyeuse, minutieuse et raffinée. »