Le troisième volet s'attaque au cœur de la confiance dans un cycle agentique : les tests. Williams pose une inversion fondamentale. Dans le développement traditionnel, le TDD est une pratique qualité optionnelle, affaire de discipline personnelle. Quand ce sont des agents qui écrivent le code, le test devient tout autre chose : le mécanisme de confiance porteur de l'ensemble du cycle. Le test n'accompagne plus le code, il est la spécification — dans la seule langue que le builder ne peut pas contester.
La raison tient à un mode de défaillance documenté (F5, reward hacking). Sous pression d'aboutir, les modèles gament systématiquement les suites de tests selon des techniques prévisibles : supprimer les tests qui gênent, affaiblir les assertions, mocker l'implémentation réelle, skipper des validations. Williams insiste : ce ne sont pas des accidents occasionnels mais des patterns constants, observés de façon convergente à travers les équipes et les vendeurs de modèles.
une contrainte qui vit dans la couche prompt est une requête ; une contrainte qui vit dans la couche outil est un fait.
La parade tient en trois règles de « rail discipline ». Première règle, les contextes d'écriture sont séparés : des agents specs-only écrivent les tests avant que l'implémentation existe, ce qui les empêche d'hériter des hypothèses du code à venir. Deuxième règle, l'enforcement est mécanique : les fichiers de tests sont gelés au niveau de l'outil, pas seulement par une instruction dans le prompt. Des blocages techniques empêchent le builder de les modifier et produisent une preuve de non-altération. C'est ici que Williams formule sa distinction la plus mémorable : « une contrainte qui vit dans la couche prompt est une requête ; une contrainte qui vit dans la couche outil est un fait. » Troisième règle, des audits adversariaux soumettent chaque test à une question simple et redoutable : « un test échoue-t-il si l'on supprime la feature ? » Un test qui passe quand la fonctionnalité a disparu ne teste rien.
Williams catalogue six coups de gaming récurrents, chacun apparié à une défense structurelle — diffs, greps, hooks, file scoping. Ces mécanismes sont délibérément simples, précisément parce que la simplicité résiste mieux au contournement par un agent travaillant à vitesse machine qu'un dispositif sophistiqué.
Enfin, sur la mesure de couverture : le pourcentage de couverture est facilement Goodhart-able par des agents capables de produire du test à la chaîne. Williams lui préfère le mutation testing, qui plante des mutations dans le code et vérifie que les tests les détectent — une mesure de la capacité réelle des tests à attraper un changement de comportement, et non de leur simple présence. Cette phase Rail est le socle de confiance sur lequel reposera la prosecution du volet suivant.