Specification-first convergence with an AI coding agent: a case study of dismantling a core architectural invariant across 189 files in a 717k-line codebase with no test oracle and no human code review

Dans le monde du logiciel, les programmes sont construits comme de vastes et complexes cités. Ils se composent de millions de lignes d'instructions qui disent à un ordinateur comment se comporter, comment mémoriser des choses et comment réagir lorsqu'un utilisateur clique sur un bouton. Pendant des décennies, la méthode standard pour modifier ces cités a consisté à envoyer un architecte humain pour inspecter chaque nouvelle brique qu'une intelligence artificielle pourrait poser. Cette revue humaine est considérée comme essentielle car les connexions entre les différentes parties d'un programme sont si profondes et emmêlées qu'une petite erreur dans un coin peut provoquer un effondrement dans un autre. Lorsqu'un changement est assez important pour toucher des centaines de fichiers à la fois, la tâche de vérification du travail devient un goulot d'étranglement ; aucun humain ne peut détenir l'intégralité de la carte des changements dans son esprit à la fois. Cette limitation a conduit beaucoup de gens à croire que pour les changements architecturaux les plus complexes, la seule voie sûre est de démolir l'ancienne structure pour en construire une nouvelle à partir de zéro, un processus lent, coûteux et risqué.

Une étude de cas récente remet en question l'idée que la revue humaine est le seul moyen de garantir la sécurité lors de changements aussi massifs. Elle explore une méthode où l'accent est mis non pas sur la vérification du produit fini, mais sur la perfection du plan avant qu'une seule brique ne soit posée. Au lieu de demander à une intelligence artificielle d'écrire du code puis d'espérer qu'un humain puisse trouver les erreurs, cette approche demande à la machine de rédiger d'abord une description formelle et détaillée de ce qu'elle entend faire exactement. Cette description est ensuite rigoureusement vérifiée par rapport au code existant, non pas pour voir si le code fonctionne, mais pour voir si le plan lui-même est cohérent. Le plan est affiné, corrigé et figé jusqu'à ce qu'il ne produise plus de conclusions. Ce n'est qu'alors que la machine commence à construire, et même dans ce cas, elle est constamment auditée par rapport à ce plan figé. Le résultat est la démonstration qu'un changement architectural massif et complexe peut être achevé sans qu'un seul humain n'ait jamais lu le code généré, à condition que le processus de définition et de vérification de l'intention soit robuste.

L'expérience s'est déroulée au sein d'une grande application logicielle propriétaire utilisée pour l'assistance au codage par intelligence artificielle. Le système, écrit dans un langage appelé TypeScript, contenait plus de 717 000 lignes de code réparties sur près de 3 650 fichiers. C'était un morceau de logiciel vivant et fonctionnel, utilisé quotidiennement, et non un modèle théorique. La tâche assignée à l'agent d'intelligence artificielle était de démanteler une règle centrale qui régissait le système depuis sa création. Cette règle, connue sous le nom d'invariant, garantissait que chaque fois qu'un utilisateur commençait une conversation avec l'IA, la fenêtre affichant cette conversation resterait ouverte pendant toute la durée de la requête. Si l'utilisateur fermait la fenêtre, la conversation mourait. L'objectif était de briser cette règle : l'utilisateur devrait pouvoir fermer la fenêtre, et la conversation continuerait de tourner en arrière-plan, prête à être rouverte et reprise exactement là où elle s'était arrêtée, sans perte de données ni répétition de mots.

Ce changement spécifique était considéré comme presque impossible à réaliser par un refactorisation standard. Selon l'évaluation de l'auteur, l'interdépendance du code était si serrée que modifier le cycle de vie d'une conversation sans briser l'ensemble du système nécessiterait normalement une réécriture complète des composants affectés. La tâche impliquait la gestion de problèmes de synchronisation complexes, tels que ce qui se passe lorsqu'une fenêtre se ferme alors que des données sont encore en cours de réception, et comment rattacher un utilisateur à un flux en direct qui tourne sans lui. Pour résoudre cela, l'auteur a employé un protocole en cinq phases conçu pour maintenir l'intelligence artificielle sur une trajectoire stricte. Le processus a commencé par l'analyse de la requête par l'agent et la production d'une spécification formelle, un document détaillé décrivant exactement comment le changement devrait fonctionner.

La partie la plus critique du processus était la phase de raffinement. On a demandé à l'agent de prendre sa propre spécification et de la vérifier par rapport au code source réel, à la recherche de contradictions ou de détails manquants. Il ne s'agissait pas d'une vérification unique. L'agent a effectué quatorze cycles de cet audit. À chaque cycle, il trouvait des erreurs dans son propre plan — peut-être un fichier qu'il avait oublié de mettre à jour, ou une dépendance qu'il avait mal comprise — et réécrivait la spécification pour corriger l'erreur. Au cours de ces quatorze tours, le plan a été corrigé environ quatre-vingt-cinq fois, élargissant la portée du changement de 110 fichiers à 160 fichiers à mesure que les connexions cachées étaient découvertes. À la fin du quatorzième cycle, la spécification était figée. C'était un blueprint fixe qui avait été audité par rapport à la réalité de la base de code jusqu'à ce que le dernier cycle ne produise plus aucune conclusion, moment auquel il fut verrouillé comme référence pour toutes les phases suivantes.

Une fois le plan verrouillé, l'agent est passé à la phase d'implémentation. Il lui a été ordonné de générer les modifications de code nécessaires pour correspondre à la spécification figée. L'agent a refusé d'effectuer des changements partiels, identifiant correctement qu'une migration inachevée briserait le système. Au lieu de cela, il a exécuté le travail en trois étapes distinctes et confirmées. Une fois le code écrit, la phase de vérification a commencé. Tout comme le plan avait été vérifié par rapport au code, le nouveau code était maintenant vérifié par rapport au plan figé. L'agent a effectué dix-sept cycles de cet audit, comparant le code réel à l'écran aux règles écrites dans la spécification. À chaque cycle, il trouvait et corrigeait des écarts, réparant des défauts architecturaux subtils qu'un humain aurait pu manquer. À travers ces dix-sept tours, l'agent a corrigé 116 défauts dans le code lui-même. Le processus s'est arrêté uniquement lorsque deux audits consécutifs n'ont renvoyé aucune erreur, confirmant que le code correspondait au plan selon le critère de convergence défini.

L'opération entière a touché 189 fichiers, avec un total de 288 fichiers modifiés en incluant l'extraction de l'ancien code. Les changements impliquaient plus de 34 000 nouvelles lignes de code et la suppression de plus de 16 000 lignes. Remarquablement, cette restructuration massive a été achevée en trois jours. Le coût du traitement de l'intelligence artificielle requis pour la tâche était de 2 430 dollars américains. Durant toute la période de trois jours, le programme n'a été exécuté une seule fois par un humain. La première fois que le logiciel a été réellement exécuté fut après le dix-septième cycle de vérification, lorsque l'auteur a enfin testé le nouveau comportement.

Le résultat fut un succès. Lorsque le programme a été lancé, le nouveau comportement fonctionnait exactement comme la spécification le décrivait. Un utilisateur pouvait démarrer une conversation, fermer la fenêtre, et la conversation continuerait de tourner en arrière-plan. Lorsque l'utilisateur rouvrait la fenêtre, la conversation reprenait instantanément, sans perte de données et sans duplication de texte. Un nouveau bouton d'arrêt est apparu dans la barre latérale, permettant à l'utilisateur de tuer le processus en arrière-plan si nécessaire. Les tests automatisés existants, qui tournaient sur le logiciel depuis des années, n'ont montré aucun échec, indiquant que le nouveau système n'avait pas cassé les anciennes fonctionnalités. Le logiciel a été publié au public sous la version 2.3.0, et durant les trente sessions d'utilisation environ qui ont suivi la publication, aucun bug n'a été observé.

Cette étude de cas ne prétend pas que l'intelligence artificielle peut désormais remplacer les ingénieurs humains dans tous les scénarios, ni suggère que cette méthode fonctionne pour tout type de problème. L'auteur prend soin de noter qu'il s'agissait d'un cas unique et spécifique sur une base de code unique, et que les résultats ne peuvent pas être automatiquement appliqués à d'autres systèmes ou à d'autres tâches. L'étude exclut explicitement l'idée qu'un ensemble préexistant de tests aurait pu résoudre ce problème, car le comportement souhaité n'existait pas avant le changement. Il n'y avait pas de "bonne" réponse à vérifier dans l'ancien code ; la justesse devait être définie à partir de zéro. L'étude reconnaît également que le processus reposait sur un modèle d'intelligence artificielle spécifique et puissant, et que les résultats pourraient différer avec des modèles plus faibles.

La portée de ce travail réside dans sa démonstration d'une nouvelle façon de gérer la complexité. En déplaçant la charge du contrôle qualité de l'inspection du produit fini vers la définition et la vérification rigoureuses du plan, les chercheurs ont montré qu'une machine pouvait naviguer dans un champ de mines de codes interdépendants sans intervention humaine. La clé n'était pas que la machine était infaillible, mais que le processus lui permettait de détecter ses propres erreurs de manière répétée avant qu'elles ne deviennent permanentes. La spécification a été contestée quatorze fois, et le code a été vérifié dix-sept fois, créant une boucle d'autocorrection qui a poussé le système vers une correspondance entre l'intention et la réalité basée sur une règle d'arrêt empirique. Les journaux de tout ce processus, s'étendant sur plus de 1 500 pages, ont été publiés pour que quiconque puisse les inspecter, offrant un regard transparent sur la façon dont une machine peut démanteler une règle architecturale centrale et la reconstruire, brique par brique, sans jamais avoir besoin qu'un humain surveille ses arrières.