Le quatrième volet réinvente la revue de code pour le monde agentique. Le constat de départ : sollicités pour une revue classique, les modèles déçoivent de façon prévisible. La sycophancie (F2) les pousse à valider plutôt qu'à critiquer ; l'hallucination (F4) leur fait inventer des problèmes ; et un biais d'entraînement (F6) les fait s'arrêter autour de quinze findings, quelle que soit la densité réelle de défauts. Williams en tire un reframe : il ne faut pas demander une évaluation, mais conduire une prosecution — une accusation adversariale.
Quatre principes structurent cette prosecution. D'abord, la réfutation plutôt que l'évaluation : on ne demande pas un feedback, on charte l'agent pour « trouver ce qui est faux » ou expliquer comment le projet échouerait. Le biais de complaisance, ainsi retourné, travaille pour vous. Ensuite, la prosecution mono-lentille : plutôt qu'un seul reviewer omniscient, on déploie des agents parallèles à contextes frais, chacun dédié à une unique dimension — correction, sécurité, conformité de contrat, alignement avec la spec, qualité des tests. Distribuer les préoccupations évite la saturation de contexte qui dilue le jugement entre priorités concurrentes.
trouver ce qui est faux
Troisième principe, les findings vérifiés uniquement. Avant qu'un builder n'agisse sur une critique, celle-ci doit être prouvée séparément : reproduire le bug via un test qui échoue, tracer le chemin de code, ou produire l'input déclencheur. Sans cela, les findings hallucinés génèrent un churn de code bien réel pour des problèmes qui n'existent pas. Quatrième principe, le loop-until-dry : on relance la prosecution avec des contextes frais jusqu'à deux passes consécutives sans aucun finding vérifié. Cet échantillonnage répété déjoue le point d'arrêt artificiel de F6.
Williams insiste ensuite sur un angle mort quasi universel : presque toutes les équipes font confiance à leur stack de revue à l'aveugle, sans jamais mesurer sa capacité réelle de détection. Sa solution miroite le mutation testing appliqué aux reviewers : planter des bugs connus — mutations mécaniques plus bugs subtils écrits par un LLM — faire tourner toute la stack de prosecution, puis mesurer le recall par catégorie et le taux de faux positifs. Exemple de bug planté : un garde de truthiness qui saute la vérification quand un champ est absent, d'apparence défensive mais introduisant une faille de sécurité.
Enfin, le gate de sortie est strict et entièrement vérifiable : zéro finding vérifié ouvert, deux passes sèches consécutives, suites de tests vertes, et diff de tests vide — cette dernière condition prouvant que les builders n'ont pas modifié leurs propres gates pour passer.