C’est le meme modele. Celui qui hallucinait dans le chat web pose 200 lignes de fonctionnalites d’un coup dans Claude Code. Le /goal de Codex resout un ticket entier. Le modele n’est pas soudainement devenu plus intelligent. Ce qui a change, c’est la structure.
Pourquoi ca fonctionne
La boucle de l’IA conversationnelle ressemble a ceci :
LLM → humain → LLM → humain
Le feedback est entierement en langage naturel. Une generation probabiliste suivie d’une evaluation probabiliste. La precision se degrade par multiplication.
La boucle d’un agent de code est differente :
LLM → generation de code → ecriture fichier → execution des tests → pass/fail → LLM
LLM → modification du code → build → succes/echec → LLM
LLM → verification des types → message d'erreur → LLM
Des portes deterministes s’intercalent dans la boucle. Le systeme de fichiers enregistre exactement ce qui a ete ecrit. Les tests donnent pass ou fail. Le compilateur dit quand c’est faux. Ces elements jouent involontairement le role de cliquet.
Un LLM est un composant unreliable. Mais construire un protocole reliable sur un composant unreliable, c’est le b.a.-ba de l’ingenierie. TCP cree une livraison reliable sur un reseau unreliable. RAID cree un stockage reliable sur des disques unreliable. ECC cree un calcul reliable sur une memoire unreliable.
La raison pour laquelle les agents de code fonctionnent est la meme. On a place des verificateurs deterministes (tests, build, linter, type checker) au-dessus d’un LLM unreliable. Ce n’est pas la performance du modele qui explique le succes, c’est la topology.
Alors pourquoi ca s’effondre
J’ai dit que ca fonctionne. Pourtant, ca s’effondre regulierement. Pourquoi ?
Parce qu’un cliquet qui se trouve la par hasard et un cliquet concu deliberement, ce n’est pas la meme chose.
Il existe des zones sans cliquet
Que se passe-t-il quand l’agent modifie du code sans tests ? Le build passe, le lint passe, mais la fonctionnalite est cassee. Dans les zones sans porte deterministe, le LLM juge de maniere probabiliste, et les jugements probabilistes se degradent par multiplication.
Sur 200 endpoints, 180 ont des tests et 20 n’en ont pas. L’agent traite les 180 parfaitement et introduit silencieusement des bugs dans les 20. C’est la raison du “c’est presque bon, mais quelque chose cloche”.
Le contenu informationnel du feedback est insuffisant
J’ai mene une experience de tri de 1000 mots. Le CPU : 0,08 ms, 100 %. Le LLM : 438 secondes, 97,7 %. En soi, c’est remarquable – 97,7 % par pure cognition. Mais la vraie decouverte etait ailleurs.
J’ai varie uniquement le niveau de feedback pour le meme resultat :
| Feedback | Resultat |
|---|---|
| Aucun | 6 erreurs (99,4 %) |
| “Il y a des erreurs” | 10 erreurs (99,0 %) – degradation |
| “Il y a 23 erreurs” | 1 erreur (99,9 %) |
| “6 erreurs, a tel endroit” | 0 erreur (100 %) |
Si on dit seulement “c’est faux”, la sur-correction aggrave les choses. Si on donne le nombre d’erreurs, un objectif apparait et le modele cherche avec tenacite. Si on donne aussi la localisation, la correction est parfaite.
La plupart des agents actuels restent au deuxieme niveau. Quand un test echoue, ils savent que “quelque chose ne va pas”, mais ne transmettent pas la raison structurelle de l’echec. Les messages d’erreur existent, mais ce sont des symptomes, pas des causes.
Les angles morts existent et la repetition ne les resout pas
Dans l’experience de tri, le LLM a laisse 6 erreurs au round 2. Au round 3, il a rapporte “aucune erreur”. Au round 4b, pareil : “aucune erreur”. Il a rate les memes 6 de la meme maniere.
Sans indice, meme apres plusieurs iterations, la precision convergeait a 99,4 %. C’est seulement en disant “il en reste 6” qu’il a atteint 100 %.
Le meme phenomene se produit avec les agents de code. L’agent cree un bug, juge par self-review qu’il n’y a “aucun probleme”, et meme quand on lui demande de corriger a nouveau, il rate le meme endroit. C’est pourquoi le retry n’est pas une solution. Les angles morts sont une limite structurelle liee a la nature probabiliste du modele, pas un manque d’effort.
A l’echelle, la multiplication agit
Une etape a 97,7 % de precision chainee deux fois donne 0,977^2 = 95,4 %. Trois fois : 93,2 %. Dix fois : 79,2 %.
Un agent modifie bien un seul fichier. Mais pour un refactoring sur 100 fichiers ? Meme a 97 % par etape, apres 100 etapes : 0,97^100 = 4,8 %. L’echec est pratiquement garanti.
C’est l’explication mathematique de “le vibe coding s’effondre a 200 endpoints”. Sur les petits projets, le nombre de chainage est faible et la probabilite tient. Sur les grands projets, la multiplication devient catastrophique.
Ce qu’il faut
La raison pour laquelle ca fonctionne et la raison pour laquelle ca s’effondre pointent au meme endroit : la presence ou l’absence de portes de verification deterministes.
Les agents actuels dependent de cliquets presents par hasard (tests, build, linter). En les concevant deliberement, on les rend plus robustes.
Concevoir les cliquets deliberement, cela signifie :
Premierement, identifier les zones sans cliquet. Le code sans tests, les API sans schema, les donnees sans types. Chaque endroit ou l’agent juge de maniere probabiliste est un point de vulnerabilite.
Deuxiemement, augmenter le contenu informationnel du feedback. Renvoyer uniquement pass/fail provoque de la sur-correction. Il faut transmettre de maniere structuree “ou, pourquoi, et en quoi le resultat differe de l’attendu”.
Troisiemement, inserer des portes deterministes entre les etapes du chainage. Executer 10 etapes d’un coup rend la multiplication catastrophique, mais fixer chaque etape avec un cliquet reinitialise la degradation.
Un LLM est un generateur remarquable. Il trie 1000 mots par pure pensee avec 97,7 % de precision. Meme un humain ne saurait le faire. Mais tout ce qui n’est pas 100 % s’effondre par repetition. 0,977 au carre donne 0,954.
Si les agents de code fonctionnent, ce n’est pas parce que le modele est intelligent. C’est parce que des portes deterministes sont inserees dans la boucle. S’ils s’effondrent, c’est parce que ces portes manquent.
La generation peut etre probabiliste. La verification doit etre deterministe.
Articles connexes
- Ratchet Pattern — Comment faire en sorte que les agents terminent le travail — Structure et principes du pattern cliquet
- Le QI du modèle compte moins que la topologie du feedback — La structure du feedback détermine la performance
- Les contraintes sont des contrats — Les contraintes rationnelles libèrent les systèmes
- filefunc — Un fichier, un concept — Structure de code native pour LLM
- Penser avec l’IA depuis les premiers principes — Comment penser avec l’IA