# williams-adlc-4-prosecution-not-code-review-2026-06-12

## Veille

Vierter Teil der ADLC-Reihe: Williams definiert Code-Review nicht als kollaborative Bewertung, sondern als adversarielle „Anklage“ neu. Er beauftragt Agenten mit Widerlegung („finde, was falsch ist“), setzt Single-Lens-Reviewer mit frischen Kontexten ein (Korrektheit, Sicherheit, Vertragskonformität, Spezifikationstreue, Testqualität), handelt nur bei verifizierten Befunden (durch einen fehlschlagenden Test reproduziert) und wiederholt den Zyklus, bis zwei aufeinanderfolgende Durchläufe null Befunde ergeben. Die Kalibrierung wird gemessen, indem bekannte Bugs im Stil von Mutationstests platziert werden. Exit-Kriterium: null offene Befunde, zwei trockene Durchläufe, grüne Tests, leerer Test-Diff.

## Titre Article

Prosecution, Not Code Review

## Date

2026-06-12

## URL

https://www.voodootikigod.com/adlc-4-prosecution-not-code-review

## Keywords

ADLC, Anklage, adversarielles Review, Widerlegung vs. Bewertung, Sykophantie, Halluzination von Befunden, Stopp-Bias bei fünfzehn Befunden, Single-Lens-Reviewer, frische Kontexte, verifizierte Befunde, Phantom-Churn, loop-until-dry, Review-Kalibrierung, platzierte Bugs, Recall pro Kategorie, Falsch-Positive, Exit-Kriterium, Mutationstests

## Authors

Chris Williams (@voodootikigod)

## Ton

Profil: methodische Fürsprache (Praktiker-Perspektive auf Englisch, argumentatives und pointiertes Register), hohes technisches Niveau, Zielgruppe Quality Leads und Ingenieure, die agentische Review-Stacks bauen. Der Ton ist eine konzeptuelle Neuqualifizierung: Die juristische Metapher (Anklage, Beweislast, verifizierte Befunde) strukturiert den gesamten Beitrag und verschiebt die Erwartung von einem Review, das „eine Meinung abgibt“, hin zu einem, das „einen reproduzierbaren Mangel nachweist“. Die Autorität stützt sich auf die explizite Verankerung in Fehlermodi (F2 Sykophantie, F4 Halluzination, F6 Bias bezüglich der Befundanzahl) sowie auf eine selten angewandte Messanforderung — „fast jedes Team vertraut seinem Review-Stack blind“. Der Stil ist um nummerierte Prinzipien strukturiert, mit einem konkreten Beispiel eines platzierten Bugs (eine Truthiness-Prüfung, die die Verifikation überspringt) und schließt mit einem strengen, verifizierbaren Exit-Kriterium.

## Pense-betes

- **Zentrale Neurahmung**: Code-Review ist keine kollaborative Bewertung, sondern eine adversarielle **Anklage**. Bei einem konventionellen Review-Auftrag zeigen Modelle Sykophantie, halluzinierte Befunde und einen künstlichen Stopppunkt bei etwa fünfzehn Problemen.
- **1. 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. Dies lenkt den Sykophantie-Bias (F2) auf die Identifikation von Mängeln statt auf das Streben nach Zustimmung um.
- **2. Single-Lens-Anklage**: parallele Reviewer mit frischen Kontexten einsetzen, die jeweils **eine einzige** Dimension untersuchen — Korrektheit, Sicherheit, Vertragskonformität, Spezifikationstreue oder Testqualität. Die Verteilung der Anliegen vermeidet die Kontextsättigung, die das Urteilsvermögen verwässert.
- **3. Nur verifizierte Befunde**: Bevor Builder handeln, ist eine unabhängige Verifikation erforderlich — Reproduktion des Bugs durch einen fehlschlagenden Test, Nachverfolgung der Codepfade oder Erzeugung des auslösenden Inputs. „Unverifizierte Befunde“ (F4) verursachen realen Churn für Phantomprobleme.
- **4. Loop-until-dry**: Die Anklage mit frischen Kontexten wiederholen, bis **zwei aufeinanderfolgende Durchläufe** keine verifizierten Befunde mehr ergeben. Dieser stichprobenbasierte Ansatz hebelt F6 aus (den Trainings-Prior, der unabhängig von der tatsächlichen Anzahl der Fehler bei etwa 10–20 Befunden stoppt).
- **Kalibrierungsmessung**: Fast jedes Team vertraut seinem Review-Stack blind. Die Lösung spiegelt Mutationstests: bekannte Bugs platzieren (mechanische Mutationen + subtile, von einem LLM geschriebene Bugs), den gesamten Anklage-Stack durchlaufen lassen, Recall pro Kategorie und die Falsch-Positiv-Rate messen.
- **Beispiel eines platzierten Bugs**: eine Truthiness-Prüfung hinzufügen, die die Verifikation überspringt, wenn ein Feld fehlt — auf den ersten Blick defensiv, tatsächlich aber eine Sicherheitslücke einführend.
- **Exit-Kriterium**: Das Review gilt als bestanden, wenn (1) null offene verifizierte Befunde vorliegen, (2) zwei aufeinanderfolgende trockene Durchläufe erfolgen, (3) die Testsuiten grün sind, (4) der Test-Diff **leer** ist (Beleg dafür, dass Builder ihre eigenen Gates nicht verändert haben).

## RésuméDe400mots

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.

## GrapheDeConnaissance

- Chris Williams —publie→ Prosecution, Not Code Review (DOCUMENT, 0.97)
- prosecution —s_oppose_à→ revue de code collaborative (METHODOLOGIE, 0.92)
- prosecution —réduit→ sycophancie du reviewer (CONCEPT, 0.91)
- reviewers mono-lentille —réduit→ saturation de contexte qui dilue le jugement (CONCEPT, 0.9)
- findings vérifiés —réduit→ churn de code sur des problèmes hallucinés (CONCEPT, 0.91)
- loop-until-dry —réduit→ biais d'arrêt autour de 10-20 findings (CONCEPT, 0.9)
- calibration de revue —s_inspire_de→ mutation testing (METHODOLOGIE, 0.9)
- calibration de revue —mesure→ recall par catégorie et taux de faux positifs de la stack (MESURE, 0.88)
- Chris Williams —affirme_que→ presque toutes les équipes font confiance à leur stack de revue à l'aveugle (AFFIRMATION, 0.89)
- bugs plantés —permet→ mesure de la capacité réelle de détection des reviewers (CONCEPT, 0.88)
- phase Prosecute —fait_partie_de→ cycle agentique en huit phases (METHODOLOGIE, 0.9)
- gate de sortie de prosecution —utilise→ diff de tests vide comme preuve de non-altération (CONCEPT, 0.89)

---
Canonical: https://www.thekb.eu/de/fiches/williams-adlc-4-prosecution-not-code-review-2026-06-12/