Le cliquet de complexité à l’ère du code par IA : pourquoi une couverture de tests de 90 % est nécessaire

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 à construire deux projets open source avec des agents IA (Claude Code, Codex, etc.). Environ 970 000 lignes de code et la plupart des 665 fichiers de test auraient été écrits par l’IA, tandis qu’il exploitait en parallèle 15 sessions d’agents. À travers ce processus, il affirme que l’ancien principe du génie logiciel selon lequel « vitesse et qualité sont un choix binaire » a volé en éclats, et propose comme mécanisme central le concept de « cliquet de complexité (Complexity Ratchet) ».

Résumé des concepts clés

• Qu’est-ce qu’un cliquet (Ratchet) : une métaphore empruntée au mécanisme à rochet qui ne progresse que dans un seul sens ; ici, cela désigne une structure qui fait avancer la qualité d’une base de code sans possibilité de retour en arrière.
• Trois accumulations : à chaque session de coding 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 ligne de base 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 les tests, d’ignorer la documentation ou de faire baisser le score d’évaluation.

Ce qui distingue cette approche des méthodes classiques

• Changement de modèle d’erreur : depuis 50 ans, le génie logiciel a construit des processus complexes — code review, QA, staging, etc. — à partir du postulat que « les erreurs sont critiques, donc il faut les prévenir ». Désormais, la plupart des erreurs peuvent être diagnostiquées et corrigées par l’agent au tour suivant.
• Élargissement de la limite de complexité : la borne supérieure de la complexité système est passée de « ce qu’une équipe peut garder en tête » à « ce qu’une personne peut gérer avec des agents ayant chargé l’ensemble de la base de code dans leur contexte ».
• Pérennité de la mémoire institutionnelle : les personnes partent à cause des départs ou du burnout, mais les connaissances conservées dans les tests et la documentation peuvent être rappelées à tout moment, par n’importe quel modèle.

La signification d’une couverture de tests à 90 %

• Courbe de qualité non linéaire : selon une étude de Capers Jones portant sur plus de 10 000 projets, quand la couverture est inférieure à 70 %, le taux d’élimination des défauts reste entre 65 et 75 %, tandis qu’entre 85 et 95 %, il bondit entre 92 et 97 % ; il existe donc un « point de bascule ».
• Précédent dans l’aéronautique : le standard logiciel aéronautique DO-178C impose une couverture MC/DC pour les systèmes de niveau A (critiques), afin d’atteindre un taux d’élimination des défauts supérieur à 99 %.
• L’IA a brisé la barrière des coûts : compléter les 20 derniers points de couverture était ennuyeux et coûteux pour les humains, mais les agents ne ressentent pas la fatigue et peuvent écrire sans fin des tests de cas limites, même en pleine nuit.

Exemples concrets donné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 qui attribuait à tort dans 35 % des cas « qui avait formulé l’affirmation » a été figé via 17 tests, de sorte qu’aucune version ultérieure ne puisse descendre en dessous de ce niveau.
• Tests TTY de Superpowers : l’agent IA avait tendance à contourner les revues interactives ; ce comportement a été directement surveillé et bloqué grâce à la fonctionnalité de pseudo-terminal de Bun, transformant ainsi en test une exigence non conventionnelle : « l’IA a-t-elle réellement eu la conversation ? ».

Avantages et limites

• Avantages : même sans comprendre l’ensemble du système, des contributeurs externes peuvent faire merger leurs PR en toute sécurité dès lors 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, faille de sécurité, fuite de vie privée) restent critiques, et environ 10 % des points d’intégration ainsi que l’infrastructure sont intrinsèquement difficiles à tester.
• Réponse aux objections : face à l’argument selon lequel « les personnes qui écrivent de bons tests conçoivent aussi mieux l’architecture », il insiste sur le fait que le cœur du cliquet n’est pas l’humain, mais le filet de sécurité du tour suivant.

Le message central de l’auteur est que la vraie valeur du coding par IA n’est pas de « coder plus vite », mais d’avoir rendu gratuit un niveau de vérification jusque-là abandonné parce qu’il coûtait trop cher. Une couverture de tests à 90 %, longtemps réservée pendant 50 ans aux secteurs de l’aéronautique et du médical, pourrait désormais devenir le quotidien d’une seule personne ; selon lui, cela relève de façon spectaculaire le plafond de complexité du logiciel qu’un développeur peut produire. Cela dit, le texte sert aussi à promouvoir ses propres projets open source (Superpowers, GBrain), et certaines références statistiques citées (par ex. GPT-5.5) demandent vérification, ce qui en fait aussi un texte qui appelle une lecture critique.

[skymer]

https://www.youtube.com/watch?v=mJ2GZRV63TE
La personne qui a créé un blog RoR avec 4 fois plus de LOC que sqlite...