contenu
Dans Le problème du harness, Can Bölük a montré que les modifications de type hashline (ancrées sur les numéros de ligne, comme 4#WB) étaient plus performantes que les modifications traditionnelles en mode replace (correspondance old_string/new_string) pour les agents de programmation.
Je fais des essais pour construire mon propre harness (tau), et je voulais vérifier ce résultat et voir si je devais envisager d’y utiliser hashline comme stratégie d’édition par défaut.
J’ai donc créé edit-bench pour tester cela moi-même sur plusieurs langages et modèles.
Configuration
edit-bench génère des tests fondés sur des mutations à partir de bases de code existantes. Vous indiquez un répertoire à un script, qui génère des mutations comme la suppression d’une instruction, l’inversion d’un booléen, la permutation d’arguments, etc.
- Langages : Python (à partir de hive), TypeScript (à partir de oh-my-pi), Rust (à partir de irradiate)
- Modèles :
gpt-4.1-mini,google/gemini-3-flash-preview,qwen/qwen3.5-397b-a17b - Modes d’édition : replace (old_string/new_string) contre hashline (ancrage sur les numéros de ligne)
- 20 tâches par langage, avec une seule tentative et une seule passe
- J’ai aussi récemment ajouté la correspondance approximative à
tau(cascade de trim :trim_end → trim_both → unicode normalization) et je voulais voir si cela aidait
Résultats
Mode replace :
| Modèle | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 95% | 80% | 95% |
| qwen3.5-397b | 90% | 85% | 85% |
| gpt-4.1-mini | 65% | 75% | 45% |
Mode hashline (d’après des exécutions précédentes) :
| Modèle | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 70% | 85% | 90% |
| qwen3.5-397b | 85% | 85% | 90% |
| gpt-4.1-mini | 50% | 70% | 55% |
Hashline dégrade nettement les résultats en Python et semble avoir un effet à peu près neutre en TypeScript et en Rust. Cette dépendance au langage est intéressante — le rôle syntaxique des espaces en Python pourrait rendre les modifications ancrées sur les lignes plus sujettes aux erreurs.
La correspondance approximative est-elle utile ?
Apparemment pas.
J’ai ajouté une collecte de traces pour voir si la cascade de trim de tau pour la correspondance approximative se déclenchait pendant les exécutions en mode replace. Sur 114 modifications réussies et 20 modifications échouées (3 modèles × 3 langages), la correspondance approximative s’est déclenchée zéro fois.
Sur les 20 modifications échouées :
- 1 comportait des espaces en fin de ligne (théoriquement corrigeable)
- ~8 incluaient des numéros de ligne dans
old_string(bug du modèle) - ~11 comportaient du contenu entièrement halluciné
Quand les modèles reproduisent correctement old_string, ils reproduisent aussi correctement les espaces.
Quand ils se trompent, ils se trompent complètement — appliquer trim en cascade n’y change rien.
(Détails de l’analyse des traces)
À retenir
-
La comparaison entre hashline et replace ne fait ressortir aucun vainqueur clair. L’effet dépend du langage et du modèle. Python pénalise hashline ; TypeScript est neutre ; pour Rust, difficile de trancher.
-
Les résultats de Can sont difficiles à généraliser. Le react-edit-benchmark ne porte que sur JavaScript et utilise un LSP pour les retours de validation. Notre configuration (sans LSP, avec plusieurs langages) donne une image différente. La boucle de rétroaction du LSP, en particulier, constitue probablement un facteur de confusion. Fournir au modèle des erreurs de typage pour guider ses nouvelles tentatives lui apporte une aide substantielle qui interagit avec le format d’édition.
-
La correspondance approximative n’est pas un enjeu pour les modèles actuels. Les LLM reproduisent le texte source à l’identique ou hallucinent quelque chose de complètement différent. Le cas d’une correspondance presque exacte à quelques espaces près, que vise la correspondance approximative, ne se produit quasiment jamais en pratique.
-
Pour les modèles de génération actuelle utilisés dans les harness modernes, le format d’édition n’est pas le facteur limitant. L’écart entre les modèles (gemini-3-flash à 90 % et plus contre gpt-4.1-mini à 55-65 %) dépasse de loin l’écart entre les formats d’édition. Investissez dans le choix du modèle et l’ingénierie de prompts avant de vous préoccuper du format d’édition.
Avertissement de rigueur : petit échantillon, absence de rigueur statistique ; à interpréter en conséquence.
Toutes les données : nwyin/edit-bench, tickets #13 et #14.