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

Imaginez que vous essayez d'apprendre à un robot super intelligent comment construire une maison. Habituellement, le robot est excellent pour poser une seule brique ou peindre un seul mur, mais si vous lui demandez de redessiner entièrement les fondations alors que la maison est déjà habitée, il a tendance à s'embrouiller. Il pourrait abattre un mur porteur par accident, ou oublier que la cuisine doit rester connectée à la salle à manger. Dans le monde de l'informatique, c'est ce qu'on appelle le « refactoring » (remaniement) d'une base de code massive. La grande question que les chercheurs se posent actuellement est la suivante : un agent d'IA peut-il accomplir ce travail colossal et dangereux tout seul, sans qu'un patron humain ne vérifie chaque ligne de code ?

Pour comprendre le défi, imaginez un programme informatique comme une immense et complexe machine d'horlogerie. À l'intérieur, il y a des « invariants » — ce sont les règles inviolables qui maintiennent les engrenages en mouvement, comme « le ressort principal doit toujours être tendu » ou « les aiguilles ne doivent jamais reculer ». La plupart des outils de codage par IA sont comme des apprentis qui sont très doués pour resserrer une vis desserrée, mais terribles pour recâbler toute l'horloge sans casser la mesure du temps. Ils ont généralement besoin qu'un humain les surveille et leur dise : « Attends, tu ne peux pas faire ça ! » Mais les humains se fatiguent, et ils ne peuvent pas garder toute la carte d'une horloge géante dans leur tête à la fois. Ce document explore une nouvelle façon de travailler : au lieu de vérifier le travail du robot après qu'il ait terminé, nous forçons le robot à rédiger un manuel d'instructions détaillé et parfait avant qu'il ne touche le moindre engrenage. Ensuite, nous demandons au robot de vérifier son propre travail par rapport à ce manuel, encore et encore, jusqu'à ce que le manuel et la machine correspondent parfaitement.

L'histoire du panneau « Fantôme »

Ce document raconte l'histoire d'une expérience spécifique et à enjeux élevés où un seul agent d'IA a été chargé d'accomplir un « tour de magie » sur un programme logiciel massif. Le programme était une application de 717 725 lignes (imaginez une bibliothèque contenant près de 720 000 pages d'instructions) qui servait d'assistant de codage par IA. La tâche consistait à briser une règle fondamentale que le logiciel avait respectée depuis son premier jour : la règle qui disait : « Si vous fermez la fenêtre affichant le travail de l'IA, l'IA doit arrêter de réfléchir. »

L'objectif était de changer cela pour que, si vous fermiez la fenêtre, l'IA continue de travailler en arrière-plan, comme un fantôme. Lorsque vous rouvriez la fenêtre, l'IA se « réattacherait » instantanément à la conversation, reprenant exactement là où elle s'était arrêtée, sans perdre un seul mot ni se répéter. L'auteur du document, un développeur humain, pensait que cela était si complexe et risqué que la seule façon sûre de le faire serait de jeter l'ancien code et de tout réécrire de zéro.

Le protocole « Specification-First » (La spécification d'abord)

Au lieu de tout réécrire, l'auteur a utilisé une méthode appelée « Specification-First Convergence » (Convergence par la spécification d'abord). C'est comme un jeu de « Téléphone arabe » joué avec un arbitre très strict, mais l'arbitre est l'IA elle-même.

1. Le Plan : L'humain a donné à l'IA une requête simple en langage courant : « Faites en sorte que l'IA continue de travailler même quand la fenêtre est fermée. »
2. Le Schéma : L'IA n'a pas commencé à coder immédiatement. Au lieu de cela, elle a écrit une énorme spécification formelle de 55 pages — un blueprint détaillé de la manière dont le changement fonctionnerait, jusqu'au plus petit détail.
3. L'Audit (Affinement) : C'est là que la magie a opéré. On a demandé à l'IA de comparer son propre schéma à l'égard du code existant réel 14 fois. À chaque tour, elle trouvait des erreurs dans son propre plan. « Oh, j'ai oublié que le processus en arrière-plan a besoin d'un nouveau bouton pour l'arrêter », ou « Je n'ai pas pris en compte ce qui se passe si la fenêtre se ferme pendant que l'IA réfléchit. » Elle a réécrit le schéma 14 fois, corrigeant environ 85 erreurs dans le plan avant d'écrire une seule ligne de nouveau code.
4. La Construction : Une fois le schéma « gelé » (ce qui signifie qu'il était parfait et ne changerait plus), l'IA a commencé à coder. Elle n'a pas seulement écrit des fichiers ; elle a créé des correctifs (de petites mises à jour) pour 189 fichiers différents.
5. La Double Vérification (Vérification) : C'était la partie la plus critique. On a demandé à l'IA de lire son propre nouveau code et de le comparer au schéma gelé 17 fois. Elle a trouvé 116 erreurs supplémentaires — de minuscules problèmes architecturaux ou des failles logiques — et les a corrigées. Elle a continué ainsi jusqu'à ce que deux tours consécutifs ne trouvent aucune erreur.

Les Résultats : Un Fantôme qui ne hante pas

L'ensemble du processus a duré trois jours et a coûté 2 430 $ en frais de traitement informatique. Le résultat ? L'IA a réussi à démanteler une règle centrale du logiciel à travers 189 fichiers sans qu'un humain n'ait jamais regardé le code généré.

Lorsque l'humain a finalement lancé le programme pour la première fois, il fonctionnait parfaitement. Vous pouviez fermer la fenêtre, regarder l'IA continuer à travailler en arrière-plan, puis rouvrir la fenêtre pour voir la conversation reprendre instantanément, sans perte de mots ni doublons. Le logiciel se comportait exactement comme le schéma le promettait. L'auteur a noté que le code était si propre que, plus tard, lorsqu'un petit ajustement de l'interface a été nécessaire, il n'a fallu modifier qu'un seul fichier, ce qui suggère que l'IA avait bien fait les choses en maintenant la structure organisée.

Ce que cela signifie (et ce que cela ne signifie pas)

Ce document suggère que pour des changements logiciels très difficiles et à haut risque, nous n'avons peut-être pas besoin de compter sur des réviseurs humains pour détecter chaque erreur. Au lieu de cela, nous pouvons utiliser l'IA pour vérifier rigoureusement ses propres plans et son propre code par rapport à un standard gelé, encore et encore, jusqu'à ce qu'elle converge vers la perfection.

Cependant, le document est très prudent quant à ses affirmations. Il admet qu'il ne s'agissait que d'une seule tâche spécifique sur un seul type de base de code spécifique. Cela ne prouve pas que cela fonctionnera pour toutes les IA ou pour tout type de problème logiciel. Il note également que, comme le code est privé, personne d'autre ne peut reproduire l'expérience exacte pour voir s'il obtient le même résultat. Mais en tant que preuve de concept, cela montre qu'une IA, lorsqu'elle est forcée de planifier méticuleusement et de s'auditer de manière répétée, peut effectuer une opération « chirurgicale » sur un système logiciel géant que les humains jugent habituellement trop dangereux à toucher sans une réécriture complète.