Addy Osmani part d'un constat : donner à un agent un moyen de vérifier son travail améliore fortement la qualité de ce qu'il produit. Ce qui rendait le « bon code » coûteux (tests, benchmarks, spécifications, vrais parcours de bout en bout) peut désormais être demandé à l'agent. Le travail humain se déplace donc de la relecture ligne à ligne vers la construction de boucles que l'agent exécute seul, et le goût se capitalise : chaque erreur devient une configuration partagée, un hook ou un test. Un humain reste responsable de ce qui est livré, mais il examine des preuves plutôt que des diffs.
Selon lui, les modèles sont assez bons pour que le goulot soit la vérification. Un agent qui ne peut pas se contrôler devine, et la correction passe par un aller-retour humain lent, coûteux et impossible à étendre. Un agent qui se teste écrit, contrôle, lit le résultat et recommence avant toute intervention humaine. Les tests changent de rôle : ils sont la manière dont l'agent perçoit le monde et sait qu'il a fini.
build loops the agent can run itself
Les tests de bout en bout sont l'oracle à privilégier : ils décrivent ce que fait l'utilisateur et sont difficiles à tromper, là où un test unitaire à base de mocks peut partager le malentendu de l'agent. Ils doivent indiquer l'étape en échec, et transforment une consigne vague en cible. Lents et instables, ils doivent rester peu nombreux.
Les tests de propriétés énoncent ce qui ne doit jamais arriver ; des outils comme fast-check, Hypothesis ou proptest génèrent des milliers d'entrées et réduisent l'échec au cas minimal. Propriétés courantes : aller-retour, invariants, idempotence, équivalence avec une version simple. Ils empêchent l'agent de choisir des exemples qui confirment sa propre logique et servent de spécification.
Pour une réécriture, les tests différentiels font de l'ancien système l'oracle : mêmes entrées, aléatoires ou issues du trafic réel, comparaison des sorties, normalisation de l'insignifiant et liste motivée des changements voulus, jusqu'à pouvoir retirer l'ancien système.
La boucle doit être rapide et déterministe : un agent face à des tests lents ou instables apprend à relancer plutôt qu'à corriger, ou espace ses exécutions et perd la trace des causes. Osmani recommande une boucle cœur sous la seconde, un aléa contrôlé, l'exclusion immédiate des tests instables, des sorties concises et les tests lourds avant intégration. Il conclut : écrire le contrôle avant le code.