La spirale de complexité des agents IA : pourquoi une couverture de test de 90 % est indispensable

Je code avec l'IA depuis un an. Pas seulement en donnant des instructions — en construisant de vrais logiciels. Deux projets open-source : GStack, qui améliore les agents de codage IA, et GBrain, qui transforme tout ce que tu lis et écris en une base de connaissances consultable par ton IA. Entre les deux, environ 970 000 lignes de code et 665 fichiers de test. Presque entièrement écrits par Claude Code et Codex sous ma direction (15 sessions Conductor simultanées la plupart du temps).

La semaine dernière, j'ai fusionné quatorze pull requests en 72 heures. Près de 29 000 lignes de nouveau code. Chaque version était mieux testée que la précédente.

C'est censé être impossible. La vitesse et la qualité sont censées être un compromis. Livrer vite, casser des choses. Aller lentement, livrer bien. Choisis l'un ou l'autre.

Tu n'as plus à choisir. La clé, c'est 90 % de couverture de test — et les agents IA ont rendu cet objectif gratuit. Pendant cinquante ans, ce niveau de vérification a coûté trop de volonté humaine pour être soutenu. Maintenant, l'agent écrit les tests en même temps que le code. Le résultat est ce que j'appelle le cliquet de complexité : un système qui ne peut que s'améliorer, jamais se dégrader.

(C'est le septième d'une série sur la construction avec l'IA : 1 2 3 4 5 6

Le logiciel était autrefois fragile

Pendant cinquante ans, toute la discipline du génie logiciel a été organisée autour d'une idée : éviter les erreurs, car les erreurs sont catastrophiques.

Il fallait que le code soit correct du premier coup. Manquer un cas limite et c'est le crash en production. Livrer une mauvaise migration de base de données et tu perds les données clients. Écrire une fonction qui fait quelque chose de subtil, et quand la seule personne qui la comprend démissionne, personne ne sait pourquoi ça marche. Tout le système dépendait d'humains étant prudents, et les humains ne sont pas prudents. Nous avons donc construit des processus élaborés — revues de code, environnements de staging, équipes QA, trains de livraison — tous conçus pour attraper les erreurs avant qu'elles n'atteignent les utilisateurs.

Ça a plus ou moins fonctionné. Mais c'était lent. Et ça signifiait que la complexité de tout système logiciel avait un plafond dur : le nombre de choses qu'une seule équipe pouvait garder en tête simultanément.

Maintenant, le logiciel est malléable

Je ne veux pas dire bâclé. Je veux dire résilient d'une manière qui était impossible avant.

Quand je dis « les modèles sont là », je veux dire que les agents de codage IA — Claude, GPT, Codex, et l'écosystème qui grandit autour d'eux — peuvent maintenant lire le code, comprendre le contexte, diagnostiquer les erreurs et écrire des correctifs. Pas parfaitement. Mais assez bien pour que le modèle d'erreur du logiciel ait changé.

La migration casse ? L'agent lit le message d'erreur, comprend l'historique du schéma de base de données sur 45 versions, écrit le correctif, écrit le test. La synchronisation de fichiers bloque sur un million de liens symboliques ? L'agent diagnostique le timeout de l'analyseur, le limite à 30 secondes, livre le correctif avec des tests. Un pipeline d'extraction a un bug d'attribution ? Une évaluation inter-modèles le détecte, le prompt est itéré, une contrainte est ajoutée au niveau de la base de données.

Pour la plupart des erreurs au niveau du code — bugs logiques, échecs d'analyse, cas limites cassés — les agents peuvent maintenant les diagnostiquer et les corriger au tour suivant. C'est véritablement nouveau. Les erreurs qui restent catastrophiques sont celles qui détruisent l'état : mauvaises migrations sur les données de production, failles de sécurité exploitées avant détection, fuites de données qui ne peuvent pas être « défuitées ». Le cliquet aide aussi ici (les bons tests attrapent la plupart de ces problèmes avant la production), mais le vrai changement est que la grande majorité des erreurs dans une base de code sont du genre réparable.

C'est un changement de phase pour la façon dont les logiciels sont construits. Mais ça ne fonctionne que si tu as le cliquet.

Le cliquet de complexité de l'agent

Un cliquet est un mécanisme qui permet le mouvement dans une seule direction. Une clé à cliquet tourne un boulon vers l'avant et l'empêche de tourner en arrière. C'est la métaphore.

Dans un logiciel codé par agent, chaque session de codage avec un agent IA ajoute trois choses à la base de code :

1. Des tests qui encodent ce que « correct » signifie — des vérifications automatisées qui s'exécutent chaque fois que quelqu'un modifie le code, et qui échouent bruyamment si le changement casse quelque chose
2. De la documentation qui enregistre pourquoi les décisions ont été prises — pas seulement ce que le code fait, mais le raisonnement et les compromis derrière
3. Des résultats d'évaluation qui établissent des seuils de qualité — des évaluations structurées de la qualité de la sortie avec des scores, pour savoir si la prochaine version est meilleure ou pire

La prochaine fois qu'un agent travaille sur la base de code, il charge ces trois éléments dans sa fenêtre de contexte (le texte que l'IA peut voir et sur lequel elle peut raisonner). Il ne peut pas régresser en dessous de la suite de tests — les tests échoueraient. Il ne peut pas ignorer la documentation — elle est juste là, dans le contexte. Il ne peut pas livrer une qualité inférieure à la ligne de base d'évaluation — les scores sont enregistrés.

Le plancher de qualité monte à chaque tour. Mouvement uniquement vers l'avant. C'est le cliquet.

À quoi ça ressemble en pratique

Je vais rendre ça concret. GBrain est un système de connaissance que je construis — il donne aux agents IA une mémoire à long terme en stockant, indexant et recherchant dans les notes, réunions, conversations et recherches d'une personne. Considère-le comme un deuxième cerveau que ton assistant IA peut réellement lire.

L'une de ses fonctionnalités est l'extraction épistémologique : il lit des milliers de pages et extrait qui croit quoi, avec quel niveau de confiance, au fil du temps. « Garry pense que Bitcoin atteindra 300 000 $ (confiance : 0,45). » « Jared pense que cette startup a une forte rétention (confiance : 0,80). » Comme ça, mais sur 28 000 pages.

La première extraction a récupéré 100 720 affirmations. J'ai utilisé une évaluation inter-modèles pour noter la qualité — j'ai demandé à GPT-5.5 et Claude de noter indépendamment la sortie. Score global : 6,8 sur 10.

Le plus gros problème ? Quelque chose que j'appelle la confusion du détenteur. Prenons l'affirmation « L'IA remplacera 80 % des ingénieurs logiciels d'ici 2027. » Qui détient cette croyance ? Est-ce la personne qui l'a écrite ? Est-ce quelqu'un qu'elle cite ? Ou est-ce le moteur d'analyse du système, qui l'a déduite d'une transcription de podcast ? La version 1 s'est trompée sur cette distinction 35 % du temps. C'est important — si tu construis un système qui suit ce que les gens croient, tu dois savoir QUI le croit.

Les résultats de l'évaluation ont donc été documentés. Six modes de défaillance spécifiques ont été identifiés. Le prompt de la version 2 a traité les six. L'arrondi des poids (les scores de confiance) a été imposé au niveau de la base de données — plus de fausse précision comme 0,74 quand 0,75 est la réponse honnête. Dix-sept tests ont verrouillé le contrat.

Maintenant, aucune future version de l'extraction ne peut être livrée sans que ces 17 tests soient réussis. Personne n'a à se souvenir pourquoi l'arrondi des poids est important ou ce qu'est la confusion du détenteur. Les tests s'en souviennent.

Le plancher de qualité a augmenté de façon permanente. C'est un tour du cliquet.

Pourquoi la plupart des projets « vibecodés » meurent

Le « Vibecoding » est le terme d'Andrej Karpathy pour coder avec l'IA en décrivant ce que tu veux en langage naturel et en laissant le modèle générer le code. C'est puissant et c'est comme ça que je construis. Mais d'après ce que j'ai vu dans les candidatures YC et les dépôts open-source, la plupart des projets vibecodés qui sautent les tests commencent à s'effondrer une fois qu'ils atteignent une complexité modérée — quelques milliers de lignes, une poignée de fonctionnalités qui interagissent.

Ils sautent le cliquet. Pas de tests, pas de docs, pas d'évaluations. L'agent ajoute de la complexité mais rien n'empêche la régression. Chaque nouvelle fonctionnalité a une chance de casser une ancienne, et sans tests, tu ne le découvres que lorsqu'un utilisateur le signale. À la version 0.5, la base de code est une maison hantée où chaque changement casse quelque chose d'inattendu. Ensuite, le développeur écrit un article de blog sur la façon dont le codage IA ne fonctionne pas.

Le codage IA fonctionne très bien. Ils n'ont tout simplement pas construit le cliquet.

On pourrait argumenter que le genre de personne qui écrit des tests est aussi celui qui écrit une bonne architecture dès le départ. Juste. Mais le mécanisme du cliquet ne concerne pas la personne — il concerne ce qui se passe au tour suivant. Quand un nouveau contributeur ouvre une PR, ou quand une version de modèle change, ou quand tu codes à 2h du matin et que ton jugement est altéré, les tests attrapent les régressions, peu importe qui les a écrits. Le cliquet fonctionne même quand l'humain n'est pas au meilleur de sa forme. C'est le but.

Sans tests, l'amélioration est un processus bruyant — les agents essaient d'améliorer les choses, mais sans signaux de régression, les bonnes et les mauvaises modifications sont également invisibles. Avec une suite de tests dense, tu obtiens un cliquet sur la surface testée : la qualité ne peut qu'augmenter pour les comportements que tu as encodés. C'est la majeure partie du système, pas la totalité. Mais c'est suffisant pour maintenir un mouvement vers l'avant à grande vitesse.

Les tests comme mémoire institutionnelle

Dans les entreprises de logiciels traditionnelles, la mémoire institutionnelle réside dans les humains. L'ingénieur senior qui sait pourquoi cette couche de cache existe. L'architecte qui se souvient de la migration qui a presque détruit la base de données. Le lead technique qui peut expliquer le cas limite étrange dans le système de facturation.

Les humains partent. Ils prennent leur retraite, ils se font débaucher, ils font un burn-out. Quand ils partent, la connaissance part avec eux. Chaque entreprise de logiciels a déjà vécu l'expérience d'ouvrir un fichier critique et de trouver un commentaire qui dit // NE PAS CHANGER CECI — demandez à Dave et Dave est parti il y a trois ans.

La fenêtre de contexte de l'agent ne démissionne pas. Elle ne se fait pas débaucher. Elle n'oublie pas. Quand la suite de tests encode « l'arrondi des poids doit utiliser des incréments de 0,05 » et que la documentation explique « parce que l'évaluation inter-modèles a montré qu'une fausse précision dégrade la confiance dans les scores », cette connaissance est durable. N'importe quel agent, n'importe quel modèle, n'importe quand peut charger ce contexte et comprendre la contrainte.

Les tests sont une mémoire institutionnelle qui survit au turnover des employés. Pour un projet solo, ils sont encore plus critiques — c'est la seule mémoire institutionnelle que tu aies.

Tout ce qui peut être exploité peut être testé

Le cliquet ne fonctionne pas seulement pour le code traditionnel. Il fonctionne pour tout ce qu'un ordinateur peut observer.

Pense aux couches d'un système moderne. L'OS te donne les arbres de processus, l'état du système de fichiers, les sockets réseau, les plannings cron. Le terminal te donne chaque frappe, chaque ligne de sortie, chaque invite interactive. Le navigateur te donne les pages rendues, les états des boutons, les événements de navigation. Les API te donnent des réponses structurées que tu peux analyser et valider. Et les agents IA te donnent un comportement observable — ce qu'ils disent, quels outils ils appellent, dans quel ordre ils font les choses, s'ils demandent avant d'agir.

Tout cela est exploitable. Et si tu peux l'exploiter, tu peux l'observer. Si tu peux l'observer, tu peux faire des assertions dessus. Si tu peux faire des assertions dessus, tu peux le cliqueter.

C'est une surface beaucoup plus grande que les tests unitaires traditionnels. Laisse-moi te montrer.

GStack est mon framework open-source d'agent de codage — 93 000 étoiles GitHub, 701 000 lignes de code, 46 compétences. L'une de ses fonctionnalités principales est la revue de plan interactive : tu lui demandes de revoir ton architecture, et il parcourt le plan section par section, posant des questions, sondant les cas limites, défiant tes hypothèses. Comme avoir un responsable technique qui lit réellement le code.

Le problème : Claude Code sautait parfois toute la partie interactive. Il lisait le fichier de plan, déversait toutes ses conclusions d'un coup, et se terminait — sans poser une seule question à l'utilisateur. Tout l'intérêt de la revue est le dialogue aller-retour. Le sauter va à l'encontre du but.

Comment tu testes ça, même ? Tu ne peux pas faire un test unitaire de « est-ce que l'IA a eu une conversation ». Aucun framework de test traditionnel ne couvre ça.

J'ai donc utilisé la fonctionnalité TTY de Bun pour construire un harnais de test (PR #1354) qui lance littéralement Claude Code dans un pseudo-terminal, lui fournit un scénario de dépôt spécifique, déclenche la compétence de revue, et surveille la sortie du terminal en temps réel. Le test observe si l'agent envoie une question interactive avant de terminer. S'il déverse ses conclusions et se termine sans rien demander, le test échoue.

Ce n'est pas tester du code. C'est tester si un agent IA suit un contrat comportemental. Au niveau TTY. En le regardant littéralement travailler.

La réponse du cliquet a été en trois couches :

1. Portes STOP dans les instructions de la compétence — des règles explicites qui disent « tu DOIS demander à l'utilisateur avant de passer à la section suivante », avec des clauses anti-rationalisation qui nomment le mode de défaillance spécifique pour que le modèle ne puisse pas se convaincre de sauter l'étape
2. Clause anti-raccourci — « le fichier de plan est la SORTIE de la revue interactive, pas un substitut à celle-ci. » Une phrase qui ferme exactement la faille que le modèle exploitait sans cesse.
3. Tests de plancher de porte — les tests du harnais TTY qui lancent Claude Code dans des scénarios contrôlés et échouent si l'agent ne pose pas au moins une question interactive

Maintenant, quand Anthropic livre une nouvelle version de modèle, ou quand je modifie un prompt de compétence, la suite de tests attrape toute régression dans le contrat interactif. L'agent ne peut pas arrêter silencieusement de poser des questions. Le test surveille le terminal et vérifie.

Ou prends la PR #880, qui a livré un nouveau plugin OpenClaw. Le test ne vérifie pas seulement que le code compile. Il construit le plugin à partir des sources, lance une instance réelle d'OpenClaw dans un profil isolé, installe le plugin via le CLI, exécute plugins inspect pour vérifier que l'exécution l'a chargé, définit l'emplacement de configuration, valide la configuration, et exécute plugins doctor pour confirmer zéro diagnostic. Un aller-retour complet de bout en bout à travers deux programmes distincts. 359 lignes de code de test. Le genre de test qu'un humain n'écrirait presque jamais à la main parce que la configuration est trop fastidieuse. Claude l'a écrit en environ cinq minutes. C'est le mur de l'effort qui disparaît en temps réel.

Le principe se généralise. Tu peux tester au niveau de l'OS : est-ce que la migration a créé les bonnes tables, est-ce que le cron s'est déclenché, le processus est-il toujours en vie ? Au niveau du navigateur : est-ce que la page s'est rendue, est-ce que l'agent a rempli le formulaire correctement. Au niveau de l'API : est-ce que le modèle a renvoyé du JSON valide avec le bon schéma. Au niveau comportemental : est-ce que l'agent a suivi le protocole, a-t-il demandé avant de supprimer, s'est-il arrêté quand on lui a dit de s'arrêter.

Toute la pile est testable. Le cliquet s'applique à tout. La plupart des gens ne l'ont pas encore réalisé parce qu'ils pensent encore à la couverture de test comme « est-ce que ma fonction a renvoyé le bon nombre ». La vraie surface de test est tout ce que l'ordinateur peut voir.

Le chiffre 90 %

Alors, qu'est-ce que 90 % de couverture de test t'apporte réellement ?

Capers Jones a étudié plus de 10 000 projets logiciels et mesuré l'efficacité d'élimination des défauts (DRE) — le pourcentage de bugs attrapés avant qu'ils n'atteignent les utilisateurs. Ses données issues de Applied Software Measurement montrent une courbe non linéaire : en dessous de 70 % de couverture, la DRE se situe autour de 65-75 %. À 85-95 % de couverture, la DRE monte à 92-97 %. La relation n'est pas linéaire. Il y a un coude dans la courbe autour de 85 % où les échappatoires de défauts chutent brusquement.

L'industrie avionique a compris ça il y a des décennies. La DO-178C, la norme FAA pour les logiciels critiques pour le vol, exige une couverture MC/DC (Modified Condition/Decision Coverage) pour les systèmes de niveau A — ceux où un bug signifie un crash d'avion. La couverture de branche seule manque 10-20 % des défauts. La MC/DC, qui est plus stricte que la couverture de ligne, atteint >99 % de DRE. Ils n'exigent pas ça parce que les bureaucrates aiment la paperasse. Ils l'exigent parce que les données ont montré qu'en dessous de certains seuils de couverture, des défauts critiques s'échappent à des taux incompatibles avec le fait de ne pas tuer des gens.

Le parallèle avec l'ingénierie de la fiabilité est clair. Les usines utilisent un système appelé Six Sigma pour mesurer la qualité. L'idée : compter combien de défauts tu obtiens par million d'unités produites, puis exprimer ça comme un « niveau sigma » — un sigma plus élevé signifie moins de défauts. Un processus à 3 sigma produit environ 67 000 défauts par million (assez mauvais). Un processus à 4 sigma en produit environ 6 200 (dix fois mieux). Un processus à 5 sigma en produit 233 (encore 27 fois mieux). Le passage de 4 à 5 sigma n'est pas une amélioration incrémentale. C'est un changement de phase.

La couverture de test suit la même courbe. Passer de 70 % à 90 % de couverture n'est pas 30 % mieux. C'est un ordre de grandeur de moins d'échappatoires. Les défauts qui passent à 70 % se cachent dans les 30 % de code non testé. À 90 %, les cachettes se réduisent à 10 % et la plupart des chemins dangereux sont verrouillés.

Maintenant, je dois être honnête sur ce que la recherche montre aussi. Mockus, Nagappan, et Dinh-Trong ont étudié Windows Vista et ont constaté que si la couverture est corrélée à moins de défauts post-livraison, l'effort pour atteindre 90 %+ augmente fortement. Les 20 % finaux de couverture prennent un travail disproportionné par rapport aux 70 % initiaux. C'est vrai depuis des décennies. C'est pourquoi la plupart des équipes s'arrêtent à 70-80 % et considèrent que c'est assez bon.

Mais quelque chose a changé : les agents de codage IA ne ressentent pas l'effort.

Ils ne s'ennuient pas à écrire le quatorzième test de cas limite. Ils ne prennent pas de raccourcis le vendredi à 17h. Ils ne regardent pas un test d'intégration tordu en pensant « je reviendrai là-dessus plus tard ». La courbe d'effort qui arrêtait les équipes humaines à 70 % ne s'applique pas aux agents. Tu peux demander à Claude d'écrire des tests pour chaque cas limite d'un module et il le fera joyeusement, minutieusement, à 2h du matin, sans se plaindre. Les 20 % finaux brutaux qui rendaient la couverture à 90 % impraticable pour les équipes humaines sont exactement le genre de travail que les agents IA font le mieux.

C'est le vrai déclic. Ce n'est pas que l'IA te permet d'écrire du code plus vite. Beaucoup de gens l'ont remarqué. C'est que l'IA te permet de vérifier à un niveau qui était auparavant trop coûteux à soutenir. Le seuil des 90 % que les données disent magique ? Il coûtait trop de volonté humaine à atteindre. Maintenant, c'est gratuit.

C'est la distinction clé. Le cliquet ne concerne pas la couverture de ligne comme une métrique de vanité. Il concerne les tests qui encodent des contrats comportementaux — le test de confusion du détenteur, le test d'arrondi des poids, la porte de la revue interactive. Chaque test verrouille une leçon spécifique apprise. La couverture est le proxy qui te dit quelle partie du comportement du système est sous contrat. À 90 %, presque tout changement de comportement déclenche un signal de test. L'agent soit réussit (sûr à livrer), soit casse un test (attrapé immédiatement).

Les 10 % restants sont des points d'intégration, de la plomberie d'infrastructure, et des cas limites qui sont vraiment difficiles à tester. C'est correct. Les 90 % sont ce qui transforme le chaos en cliquet.

Atteindre 90 % était autrefois un effort héroïque. Maintenant, c'est un mardi. C'est le changement de jeu.

Preuve de concept

J'ai commencé les deux projets seul. Ils ne sont plus solos.

GStack a maintenant 37 contributeurs. La v1.30 a incorporé 21 PRs communautaires dans une seule version. GBrain a 25 contributeurs. La v0.31.1.1 a intégré 22 correctifs communautaires dans une seule PR — flux d'authentification, amorçage de schéma, synchronisation, confidentialité.

Le cliquet est ce qui rend ça sûr. Chaque PR externe doit passer la suite de tests existante. Un nouveau contributeur n'a pas besoin de comprendre tout le système. Il doit juste faire passer les tests.

Les versions de GBrain de la semaine dernière racontent l'histoire :

• v0.31.0 : une nouvelle table de faits pour la mémoire en temps réel, plus une phase de consolidation de rêve qui promeut les souvenirs à court terme en connaissances à long terme
• v0.31.1 : correction de 25 commandes CLI qui étaient silencieusement routées vers une base de données locale vide au lieu du cerveau réel de l'utilisateur
• v0.31.1.1 : vingt-deux correctifs signalés par la communauté dans une seule PR
• v0.31.2 : correction d'une synchronisation de code qui bloquait indéfiniment sur les grands dépôts avec des liens symboliques en ajoutant un délai d'attente de 30 secondes

Chaque version a été livrée avec plus de tests que la précédente. L'agent écrit les tests en même temps que le code. La couverture ne baisse pas parce que l'effort pour la maintenir n'est plus un fardeau humain.

Le nouveau plafond de complexité

Le plafond de complexité pour les logiciels vient de monter considérablement.

Il était autrefois limité par la capacité d'une seule équipe à garder le système en tête. Maintenant, il est limité par une seule personne plus des agents qui peuvent charger la base de code complète, l'historique du schéma, la suite de tests et la documentation dans leur contexte.

C'est un nombre beaucoup plus grand. Et il continue de croître à mesure que les fenêtres de contexte s'agrandissent et que les modèles deviennent meilleurs pour raisonner sur le code.

Toute entreprise de logiciels qui n'adopte pas ce modèle — agents plus goût plus une suite de tests qui ne fait que monter — livre déjà plus lentement et avec moins de qualité qu'une seule personne qui l'a fait.

Les outils sont là. Le code est ouvert. Les tests sont le cliquet. 90 % de couverture, chaque PR, sans exception.

Pendant cinquante ans, 90 % de couverture était un luxe réservé à l'avionique et aux dispositifs médicaux — des équipes avec le budget pour jeter des heures humaines sur le mur de l'effort. Les agents IA ont démoli ce mur. Le seuil de couverture qui rend les logiciels fiables n'est plus coûteux. C'est juste un paramètre. La question n'est pas de savoir si tu peux te permettre 90 %. C'est de savoir si tu peux te permettre de ne pas l'avoir.

Le cliquet, les compétences et tout le système de connaissance sont open source et gratuits sur GitHub. Allez construire.

Mes projets open source sous licence MIT :

• GStack — rend Claude Code nettement meilleur. 93K étoiles. Gratuit.
• GBrain — ton deuxième cerveau pour les agents IA. 14K étoiles. Gratuit.

La série AI Explainer :

1. Fat Skills, Fat Code, Thin Harness — l'architecture
2. Resolvers — la table de routage pour l'intelligence
3. The LOC Controversy — ce que 600K lignes ont réellement produit
4. Naked Models Are Stupider — le modèle est le moteur, pas la voiture
5. The Skillify Manifesto — chaque flux de travail devient une compétence testable
6. Meta-Meta-Prompting — les compétences composées produisent des capacités émergentes
7. The Agent Complexity Ratchet — tu es ici

https://x.com/garrytan/status/2054055071017538028

https://x.com/garrytan/status/2042925773300908103

https://x.com/garrytan/status/2044479509874020852

https://x.com/garrytan/status/2045404377226285538

https://x.com/garrytan/status/2045798603059548364

https://x.com/garrytan/status/2046876981711769720

https://x.com/garrytan/status/2053127519872614419

https://x.com/karpathy/status/1886192184808149383