🤖 machine learning

The Working Set of a Coding Agent: Coherence Debt in Repository-Scale Tasks

Cet article introduit le concept de « dette de cohérence » pour démontrer que le succès des agents de codage à l'échelle d'un dépôt dépend principalement de la disponibilité immédiate des faits contextuels requis plutôt que de leur distance ou de la mémoire paramétrique de l'agent, révélant que les agents fabriquent souvent des solutions lorsque les faits sont manquants et que les bancs d'essai actuels peuvent diagnostiquer de manière erronée les échecs en se concentrant sur les opérations de lecture plutôt que sur la cohérence des sorties générées.

Auteurs originaux : Bardia Mohammadi, Lars Klein, Aman Chadha, Akhil Arora, Laurent Bindschaedler

Publié 2026-08-18

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Bardia Mohammadi, Lars Klein, Aman Chadha, Akhil Arora, Laurent Bindschaedler

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

Dans le monde du logiciel, une seule ligne de code existe rarement de manière isolée. Pour modifier un nombre dans un fichier, un programmeur doit souvent savoir comment ce nombre est utilisé dans trois autres fichiers, quels paramètres de configuration le contrôlent et quels tests doivent réussir pour prouver que la modification est sûre. Ce réseau de connexions est ce qui rend la correction d'un bug ou la mise à jour d'un système difficile ; la bonne réponse dépend de faits dispersés dans l'ensemble du projet. Pendant des années, des chercheurs ont tenté de construire des agents d'intelligence artificielle capables de naviguer dans ces réseaux complexes, agissant comme des développeurs juniors capables de lire l'ensemble d'une base de code, d'en comprendre les règles et d'effectuer les modifications appropriées. L'espoir était que si nous donnions à ces agents d'IA suffisamment d'informations sur le projet, ils réussiraient. Mais une nouvelle étude suggère que donner simplement plus d'informations à l'agent n'est pas toute l'histoire. Le véritable défi n'est pas seulement d'avoir les faits disponibles, mais d'avoir les bons faits disponibles au moment exact où l'agent tente d'écrire une nouvelle ligne de code.

Des chercheurs de plusieurs institutions, dont l'Institut Max Planck pour les systèmes logiciels et l'EPFL, ont cherché à tester précisément comment ces agents d'IA gèrent le flux d'informations lors d'une tâche de codage. Ils ont traité le projet comme un système vivant où l'agent doit constamment garder un « ensemble de travail » de faits dans son esprit : les exigences de test actuelles, les noms des outils importés et les règles de comportement du logiciel. Ils ont posé une question simple mais profonde : que se passe-t-il lorsqu'un fait nécessaire est absent de la vue de l'agent ? L'agent s'arrête-t-il pour demander de l'aide, ou devine-t-il ? Et est-ce important si le fait se trouve juste à côté de la modification ou s'il est enfoui au fond d'une longue liste d'instructions précédentes ?

Pour trouver la réponse, l'équipe a créé une série d'expériences contrôlées. Ils ont construit des bibliothèques logicielles fictives avec des règles spécifiques que aucune IA n'avait jamais vues auparavant, garantissant que les agents ne puissent pas s'appuyer sur des connaissances mémorisées. Ils ont ensuite soumis les agents à des tâches de migration, telles que la mise à jour d'une bibliothèque d'une version à une autre, sous différentes conditions. Dans certains cas, les agents recevaient la description de la tâche mais n'avaient pas accès au code ou aux règles, les forçant à se fier entièrement à ce qu'ils avaient appris durant leur entraînement. Dans d'autres cas, les chercheurs fournissaient les règles exactes et les fichiers sources dès le début. Ils ont également testé ce qui se passait lorsqu'ils cachaient délibérément certaines informations, comme une valeur secrète nécessaire pour calculer un résultat, afin de voir comment les agents réagissaient.

Les résultats étaient frappants et clairs. Lorsque les agents se voyaient refuser l'accès aux faits nécessaires, ils ne s'arrêtaient pas simplement de travailler ou n'admettaient pas être bloqués. Au lieu de cela, ils continuaient à agir, souvent avec une confiance dangereuse. Si un fichier manquait, l'agent en inventait un nouveau. Si une valeur était inconnue, il devinait un nombre. Les agents produisaient un « travail erroné » plutôt qu'un « travail absent ». Ils fabriquaient des fichiers et devinaient des valeurs, créant un code qui semblait complet mais qui était fondamentalement défectueux. Ce comportement signifiait que les outils standards utilisés pour mesurer le succès d'un agent, qui vérifient souvent simplement si l'agent a lu un fichier, étaient trompeurs. Un agent pouvait lire un fichier qu'il avait lui-même écrit, ou lire un fichier non pertinent, et les outils compteraient cela comme « faisant le travail », même si l'agent avait manqué le fait crucial dont il avait besoin.

L'étude a également révélé que l'emplacement de l'information importait moins que sa présence. Les chercheurs ont testé s'il y avait une différence si un fait requis était placé au tout début d'une longue liste d'instructions ou juste à côté de l'endroit où la modification était effectuée. Ils ont découvert que tant que le fait était présent dans la vue de l'agent, il pouvait être utilisé tout aussi efficacement qu'il soit au début ou à la fin d'une fenêtre de contexte massive. La distance ne dégradait pas la capacité de l'agent à utiliser le fait. Cependant, si le fait était totalement retenu, l'agent échouait, peu importe la quantité d'autres informations dont il disposait. Le dommage était linéaire : cacher un fait faisait échouer l'agent sur les tâches spécifiques dépendant de ce fait, mais cela ne provoquait pas de cascade de défaillances dans des parties non liées du code.

Peut-être la découverte la plus surprenante concernait la capacité des agents à admettre qu'ils étaient bloqués. Les chercheurs ont découvert que le fait qu'un agent dise « Je ne peux pas procéder car il me manque un fichier » dépendait entièrement du modèle d'IA spécifique utilisé. Certains modèles, comme un modèle appelé Opus, rapportaient être bloqués dans chaque essai lorsqu'un fichier manquait. D'autres, comme Codex, ne signalaient jamais être bloqués ; ils fabriquaient simplement le fichier manquant et continuaient. Cela suggère que la capacité à reconnaître une lacune dans les connaissances n'est pas une caractéristique universelle des agents de codage, mais un trait spécifique du modèle lui-même. Pour les systèmes qui n'admettent pas être bloqués, la « dette de cohérence » — l'écart entre ce dont l'agent a besoin et ce qu'il sait — reste invisible jusqu'à ce que le code final soit vérifié et trouvé erroné.

Les chercheurs ont également découvert que la manière dont une tâche de codage est organisée importe plus que le volume brut d'informations. Lorsqu'ils divisaient une tâche étroitement liée entre plusieurs agents, le taux de réussite chutait car les agents ne pouvaient pas maintenir la cohérence des faits partagés. Mais lorsqu'ils divisaient des tâches indépendantes, les agents travaillaient tout aussi bien. Cela a confirmé que le problème n'est pas seulement d'avoir assez de données, mais de garder les faits spécifiques qui sont liés entre eux disponibles en même temps. Si un agent doit modifier un paramètre dans un fichier, il doit avoir la valeur actuelle de ce paramètre et la règle de son interaction avec les autres fichiers dans sa vue immédiate.

Enfin, l'étude a examiné ce qui se passe lorsque l'information disponible pour l'agent est contradictoire. Dans certaines expériences, les chercheurs ont fourni un document de norme écrite qui disait une chose, tandis que le code existant dans le projet démontrait le contraire. Dans tous les cas, les agents suivaient la norme écrite, même lorsque celle-ci prescrivait une façon de coder pire ou plus sujette aux erreurs. Cela suggère que pour ces agents d'IA, une règle écrite possède plus d'autorité que le comportement réel du logiciel qu'elle est censée décrire. Si la norme est obsolète, l'agent reproduira fidèlement la règle obsolète, rendant un document périmé plus dangereux que l'absence totale de document.

Les implications de ces découvertes sont significatives pour la façon dont nous construisons et évaluons les outils de codage par IA. Il s'avère que simplement agrandir la fenêtre de contexte ou donner plus de mémoire à l'agent ne garantit pas le succès. Le facteur critique est de s'assurer que les faits spécifiques dont un agent a besoin pour effectuer une modification sont présents et cohérents au moment où il écrit. Si un agent manque d'un fait, il n'attendra pas ; il devinera. Et si les faits qui lui sont donnés sont contradictoires, il suivra la règle écrite, même si cette règle est fausse. L'étude conclut que la meilleure façon de construire ces systèmes n'est pas seulement de les nourrir avec plus de données, mais de concevoir l'environnement de sorte que les faits nécessaires soient toujours disponibles et à jour, et de vérifier la production de l'agent par rapport à ce qu'il a réellement produit, plutôt que de supposer qu'il a lu les bonnes choses. Les agents n'échouent pas parce qu'ils sont trop petits ou trop lents ; ils échouent parce qu'ils sont trop impatients de combler les vides lorsque les faits manquent.

Résumé technique : L'ensemble de travail d'un agent de codage : La dette de cohérence dans les tâches à l'échelle d'un dépôt

Énoncé du problème

Le codage à l'échelle d'un dépôt nécessite que les agents maintiennent la cohérence entre les tests, les imports, les configurations et les règles de migration au sein d'une fenêtre de contexte bornée. Les méthodes d'évaluation actuelles n'observent souvent que le patch final, manquant ainsi un mode de défaillance critique : une édition dans un fichier n'est correcte que si elle reste cohérente avec les faits ailleurs dans le dépôt. Les agents doivent reconstruire ce « graphe de faits couplés » par des lectures, des éditions et des tests, mais aucune structure externe n'est fournie.

Le problème central est l'accessibilité des faits couplés au moment de l'édition. Un agent dispose de deux canaux pour obtenir un fait requis :

Contexte récent ( $R_t$ ) : Faits résidant dans la fenêtre de contexte effective (provenant de lectures ou de l'apport de prompts).
Mémoire paramétrique ( $K_M$ ) : Faits détenus dans les poids du modèle.

Si aucun de ces deux canaux ne couvre un fait requis, l'édition procède à partir d'une vue incomplète. Les auteurs définissent ce déficit comme une dette de cohérence. Contrairement aux pages de mémoire virtuelle, les faits d'un dépôt ne possèdent ni adresses ni bits d'invalidation ; une implémentation obsolète et une règle textuelle peuvent encoder deux versions différentes du même fait, et l'agent ne peut pas distinguer intrinsèquement laquelle est la plus actuelle.

Méthodologie

Le papier emploie un design expérimental contrôlé pour isoler les effets de la disponibilité des faits, en substitution de la connaissance, et l'impact de la distance au sein de la fenêtre de contexte.

1. Cadre théorique

Les auteurs modélisent une tâche $T$ comme un graphe de faits couplés $G_T = (V_T, E_T)$ , où les nœuds sont des faits atomiques (symboles, tests, configurations) et les arêtes représentent des exigences de cohérence.

Dette de cohérence ( $D(e_i)$ ) : Définie comme le nombre de faits requis par une édition $e_i$ qui ne sont couverts ni par le contexte récent ni par la mémoire paramétrique :
$D(e_i) = |C_T^{(i)} \setminus (R_{t_i} \cup K_M)|$
Proxy observable : Puisque la rétention du contexte interne est inobservable dans les journaux historiques, les auteurs utilisent un score de résidence ( $\rho_w$ ), mesurant la fraction des voisins d'importation à un bond (one-hop) d'un fichier lus dans les $w$ événements d'outils précédents. Ils reconnaissent qu'il s'agit d'une borne inférieure de la couverture totale, car cela omet les faits paramétriques et les dépendances non liées aux imports.

2. Charges de travail expérimentales

L'étude utilise quatre migrations d'API fictives (Sprocket, Grimwire, Kestrix, Zynet) et une migration Pydantic réelle, conçues pour contrôler la disponibilité des faits :

Essais en livre fermé (Closed-Book) : Le modèle reçoit la description de la tâche mais aucun espace de travail ou outil ( $R_t \approx \emptyset$ ). Cela teste les limites de la mémoire paramétrique.
Essais avec préchargement (Front-Loaded) : Les règles exactes et les fichiers sources sont fournis dans le prompt, testant si le contexte peut se substituer à la connaissance préalable manquante.
Essais de renommage (Renamed) : Une migration Pydantic où les noms d'API sont renommés lexicalement pour vaincre la mémoire paramétrique tout en préservant le comportement.
Injection de fautes synthétiques : Des tâches où les auteurs construisent le couplage (par exemple, un littéral secret liant trois fichiers) et retiennent systématiquement des faits spécifiques pour mesurer l'impact linéaire de la dette.
Distance et encombrement (Distance and Bloat) : Expériences variant la distance des faits fournis par rapport au point d'édition et l'insertion de contenu non pertinent dans les fichiers versus des documents autonomes.

3. Mesure

Les auteurs analysent les trajectoires via des flux d'événements (lectures, éditions, tests, réversions) et mesurent :

Succès : Passage des suites de tests ou respect des exigences mécaniques de migration.
Dette de cohérence : Calculée via la connaissance de vérité terrain dans les tâches synthétiques ou déduite via le proxy de résidence dans les tâches réelles.
Consommation de tokens : Comparaison du coût de différentes politiques de harnais pour atteindre le même ensemble de travail.

Principales contributions

Quantification de la dette de cohérence : Le papier établit que retenir des faits coûte exactement le travail qu'ils soutiennent, sans dommage composé. Le dommage est linéaire et additif à travers le graphe de faits couplés.
Substitution de canal : Il démontre que le contexte récent et la mémoire paramétrique sont des canaux substituables. Fournir les faits via le prompt restaure les taux de succès à des niveaux proches du plafond, même si le modèle manque de connaissances préalables.
Présence vs Distance : L'étude fournit la preuve que la disponibilité détermine le résultat, tandis que la distance ne semble pas dégrader l'utilité dans les plages testées. Les auteurs rapportent que les faits fournis restent utilisables à l'extrémité lointaine d'un contexte de plus de 128k tokens, notant que ces expériences bornent les effets importants concernant la distance plutôt qu'ils n'excluent les effets mineurs. Le mécanisme identifié est la présence plutôt que la proximité.
Compensation comportementale : Les agents ne s'abstiennent pas lorsque des faits manquent ; ils fabriquent des fichiers ou devinent des valeurs. Par conséquent, les instruments dérivés de la lecture (comme le score de résidence) échouent souvent à détecter les faits manquants car l'agent comble le vide par un travail incorrect.
Autorité des standards : Lorsqu'une norme écrite et un code fonctionnel divergent, les agents suivent la norme écrite, même si celle-ci prescrit un code de moindre qualité. Un fichier de convention obsolète est plus préjudiciable qu'une absence de fichier.
Limites des métriques actuelles : Le papier montre que les scores de résidence et les métriques basées sur la lecture ne prédisent pas le succès dans les dépôts réels (ex: SWE-bench) où les modèles possèdent probablement déjà les faits pertinents dans leur mémoire paramétrique, rendant le canal de « lecture » moins décisif.

Résultats clés

Plancher en livre fermé : À travers 154 essais en livre fermé sur des API inédites, aucun modèle n'a complété une seule migration (0/12 exigences). Fournir les faits dans le prompt a porté le succès à au moins 9/12 pour 299/300 essais.
Échec par mémorisation : Lorsque les noms d'API ont été renommés pour vaincre la mémoire paramétrique, sept modèles différents ont échoué au même point exact, passant les mêmes 24 tests sur 79.
Dommage linéaire : Retenir $m$ motifs (chacun soutenant 4 tests) a entraîné une perte de exactement $4m$ tests réussis. Il n'y a pas eu de défaillance composée.
Indépendance de la distance : Les taux de succès sont restés stables, que les faits fournis se trouvaient à 0 ou 128 000 caractères de l'édition. Les auteurs notent que ces bras se situent au plafond, donc qu'ils bornent les effets importants plutôt qu'ils n'excluent les petits.
Inefficacité du harnais : Différentes configurations de harnais ayant atteint 100 % de réussite aux tests variaient par un facteur de 12,8x en consommation de tokens, uniquement en raison de différents taux de récupération (renvoi de l'historique de la conversation), et non de différences dans la taille de l'ensemble de travail.
Fabrication vs Blocage : Lorsque des faits étaient retenus, les agents ne signalaient que rarement être bloqués. Au lieu de cela, ils fabriquaient des fichiers manquants ou devinaient des valeurs. Le taux de signaux de « blocage » variait énormément selon le modèle (0 % à 100 %), ce qui en fait une métrique peu fiable pour la détection de la dette.
Nullité de SWE-bench : Sur SWE-bench, où les modèles connaissent probablement les dépôts, le score de résidence (une métrique basée sur la lecture) n'a pas réussi à prédire le succès (AUC $\approx$ 0,49), suggérant que pour les bases de code familières, le canal de « lecture » n'est pas le facteur limitant.

Signification et affirmations

Le papier soutient que la dette de cohérence est le goulot d'étranglement principal dans le codage à l'échelle d'un dépôt, et non le volume de contexte ou la complexité de la tâche.

Pour la conception de harnais : Le succès dépend de maintenir les faits couplés à la prochaine édition disponibles (actuels et cohérents) au moment de l'écriture. Les harnais doivent se concentrer sur la garantie de la disponibilité des faits plutôt que sur l'augmentation simple de la taille de la fenêtre de contexte ou du volume de récupération.
Pour l'évaluation : Les métriques actuelles basées sur les « lectures » sont fondamentalement erronées car les agents compensent les faits manquants par l'action (fabrication). Une trajectoire réussie peut présenter une dette de cohérence élevée qui est invisible dans les journaux basés sur la lecture.
Pour le comportement des modèles : Les agents privilégient les standards écrits sur le code fonctionnel lorsqu'ils entrent en conflit, suggérant que les fichiers de documentation peuvent être une source de « dette de cohérence » s'ils sont obsolètes.
Limite de portée : Le cadre est plus applicable aux tâches nécessitant une cohérence entre fichiers (migrations, mises à jour). Il ne prétend pas expliquer les éditions de fichiers uniques ou le développement de nouveaux projets (greenfield) où l'agent construit le graphe au fur et à mesure de son écriture. Les auteurs précisent explicitement que leurs conclusions sur SWE-bench suggèrent que le cadre ne se transfère pas universellement aux dépôts réels où la mémoire paramétrique domine.

Le papier conclut que l'« ensemble de travail » d'un agent de codage est défini par la présence de faits couplés au moment de l'édition, indépendamment du canal (contexte ou mémoire) par lequel ils sont arrivés, et que le coût des faits manquants est strictement linéaire et additif. Les auteurs traitent le mécanisme de résidence comme un élément borné par leurs expériences plutôt que pleinement confirmé, particulièrement concernant les limites des effets de distance.