Der vierte Teil erfindet das Code-Review für die agentische Welt neu. Ausgangsbeobachtung: Werden Modelle gebeten, ein konventionelles Review durchzuführen, enttäuschen sie auf vorhersehbare Weise. Sykophantie (F2) drängt sie dazu, eher zuzustimmen als zu kritisieren; Halluzination (F4) führt dazu, dass sie Probleme erfinden; und ein Trainingsbias (F6) lässt sie unabhängig von der tatsächlichen Fehlerdichte bei etwa fünfzehn Befunden aufhören. Williams leitet daraus eine Neurahmung ab: Gebraucht wird keine Bewertung, sondern eine Anklage — eine adversarielle Beschuldigung.
Vier Prinzipien strukturieren diese Anklage. Erstens Widerlegung statt Bewertung: Statt um Feedback zu bitten, wird der Agent beauftragt, „zu finden, was falsch ist“, oder zu erklären, wie das Projekt scheitern würde. Der Sykophantie-Bias, auf diese Weise umgekehrt, arbeitet zum eigenen Vorteil. Zweitens Single-Lens-Anklage: Statt eines einzelnen allwissenden Reviewers werden parallele Agenten mit frischen Kontexten eingesetzt, jeder auf eine einzige Dimension spezialisiert — Korrektheit, Sicherheit, Vertragskonformität, Übereinstimmung mit der Spezifikation, Testqualität. Die Verteilung der Anliegen vermeidet die Kontextsättigung, die das Urteilsvermögen zwischen konkurrierenden Prioritäten verwässert.
Das dritte Prinzip lautet: nur verifizierte Befunde. Bevor ein Builder auf eine Kritik reagiert, muss sie unabhängig belegt werden: Reproduktion des Bugs durch einen fehlschlagenden Test, Nachverfolgung des Codepfads oder Erzeugung des auslösenden Inputs. Ohne dies erzeugen halluzinierte Befunde realen Code-Churn für Probleme, die nicht existieren. Das vierte Prinzip ist Loop-until-dry: Die Anklage wird mit frischen Kontexten wiederholt, bis zwei aufeinanderfolgende Durchläufe überhaupt keine verifizierten Befunde mehr ergeben. Diese wiederholte Stichprobenziehung hebelt den künstlichen Stopppunkt von F6 aus.
Williams markiert anschließend einen nahezu universellen blinden Fleck: Fast jedes Team vertraut seinem Review-Stack blind, ohne dessen tatsächliche Erkennungsfähigkeit je zu messen. Seine Lösung spiegelt Mutationstests, angewandt auf Reviewer: bekannte Bugs platzieren — mechanische Mutationen plus subtile, von einem LLM geschriebene Bugs —, den gesamten Anklage-Stack durchlaufen lassen und dann Recall pro Kategorie sowie die Falsch-Positiv-Rate messen. Beispiel für einen platzierten Bug: eine Truthiness-Prüfung, die die Verifikation überspringt, wenn ein Feld fehlt — auf den ersten Blick defensiv, tatsächlich aber eine Sicherheitslücke einführend.
Schließlich ist das Exit-Kriterium streng und vollständig verifizierbar: null offene verifizierte Befunde, zwei aufeinanderfolgende trockene Durchläufe, grüne Testsuiten und ein leerer Test-Diff — Letzteres als Beleg dafür, dass Builder ihre eigenen Gates nicht verändert haben, um sie zu bestehen.