Le cliquet de complexité des agents IA : pourquoi une couverture de test de 90 % est indispensable

Le cliquet de complexité à l’ère du codage par IA (Complexity Ratchet) — résumé de l’essai de Garry Tan

Il s’agit d’un long essai partagé sur X par Garry Tan (CEO de Y Combinator), qui revient sur son expérience de l’année écoulée à créer deux projets open source avec des agents IA (Claude Code, Codex, etc.). Selon lui, l’IA a rédigé l’essentiel d’environ 970 000 lignes de code et de 665 fichiers de test, tandis qu’il pilotait en parallèle 15 sessions d’agents. À partir de cette expérience, il affirme que l’ancien principe de l’ingénierie logicielle selon lequel « vitesse et qualité sont un choix exclusif » a été brisé, et propose comme mécanisme central le concept de « cliquet de complexité » (Complexity Ratchet).

Principaux concepts

• Qu’est-ce qu’un cliquet (ratchet) : une métaphore empruntée au mécanisme à rochet qui ne tourne que dans un seul sens, pour désigner une structure qui fait progresser la qualité d’une base de code sans retour en arrière.
• Trois accumulations : à chaque session de codage avec un agent, trois éléments s’ajoutent à la base de code : les tests (ce qui est correct), la documentation (pourquoi cette décision a été prise) et les résultats d’évaluation (la référence de qualité).
• Utilisation de la fenêtre de contexte : lors de la session suivante, l’agent IA lit ces trois éléments avant de travailler, ce qui l’empêche de casser des tests, d’ignorer la documentation ou de faire baisser les scores d’évaluation.

Ce qui change par rapport aux méthodes classiques

• Évolution du modèle d’erreur : depuis 50 ans, l’ingénierie logicielle part du principe que « les erreurs sont critiques, donc il faut les prévenir », d’où des processus complexes comme les revues de code, la QA ou le staging ; désormais, la plupart des erreurs peuvent être diagnostiquées et corrigées par un agent au tour suivant.
• Extension de la limite de complexité : la borne supérieure de la complexité d’un système n’est plus « ce qu’une équipe peut garder en tête », mais « ce qu’une personne et des agents ayant chargé toute la base de code dans leur contexte peuvent gérer ».
• Pérennité de la mémoire institutionnelle : les personnes quittent l’entreprise, démissionnent ou s’épuisent, mais le savoir conservé dans les tests et la documentation peut être rappelé à tout moment, avec n’importe quel modèle.

Pourquoi 90 % de couverture de test comptent

• Courbe de qualité non linéaire : selon une étude de Capers Jones portant sur plus de 10 000 projets, en dessous de 70 % de couverture, le taux d’élimination des défauts plafonne à 65–75 %, alors qu’entre 85 % et 95 %, il bondit à 92–97 % : il existe un véritable « point d’inflexion ».
• Précédent dans l’aéronautique : la norme logicielle aéronautique DO-178C impose une couverture MC/DC pour les systèmes de niveau A (critiques), afin d’atteindre plus de 99 % d’élimination des défauts.
• L’IA a fait sauter la barrière des coûts : couvrir les 20 % finaux était une tâche fastidieuse et coûteuse pour des humains, mais les agents ne se fatiguent pas et peuvent écrire sans fin des tests de cas limites, même au milieu de la nuit.

Cas concrets cités par l’auteur

• Amélioration de la précision d’extraction de GBrain : sur plus de 100 000 extractions de croyances, un problème d’attribution erronée de « qui a formulé cette affirmation » à hauteur de 35 % a été figé via 17 tests, de sorte qu’aucune version ultérieure ne puisse repasser sous ce seuil.
• Tests TTY de Superpowers : le comportement d’un agent IA qui sautait des revues interactives a été directement surveillé et bloqué grâce à la fonctionnalité de pseudo-terminal de Bun, transformant ainsi en test une exigence non conventionnelle comme « l’IA a-t-elle réellement dialogué ? ».

Avantages et limites

• Avantages : même sans comprendre tout le système, des contributeurs externes peuvent fusionner des PR en toute sécurité tant que les tests passent, ce qui abaisse la barrière d’entrée à la collaboration.
• Limites : certains types d’erreurs destructrices d’état (mauvaises migrations de base de données, failles de sécurité, fuites de vie privée) restent critiques, et environ 10 % des points d’intégration et de l’infrastructure sont intrinsèquement difficiles à tester.
• Réponse aux objections : à l’argument selon lequel « ceux qui écrivent de bons tests conçoivent aussi une bonne architecture », il répond que l’essentiel du cliquet n’est pas la personne, mais le filet de sécurité du tour suivant.

L’idée centrale que l’auteur veut faire passer est que la vraie valeur du codage par IA n’est pas de « coder plus vite », mais de rendre gratuit un niveau de vérification jusqu’ici abandonné parce que trop coûteux. Une couverture de test de 90 %, longtemps réservée à l’aéronautique et au médical depuis 50 ans, pourrait désormais devenir le quotidien d’une seule personne ; en conséquence, le plafond de complexité du logiciel qu’un développeur individuel peut produire aurait fortement augmenté. Cela dit, le texte sert aussi à promouvoir ses propres projets open source (Superpowers, GBrain), et certaines citations statistiques (par ex. GPT-5.5) demandent vérification, ce qui appelle une lecture critique.