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

## Veille

Quarto capitolo della serie ADLC: Williams riformula la revisione del codice come "accusa" avversariale piuttosto che come valutazione collaborativa. Assegna agli agenti il mandato di confutare ("trovare cosa non va"), impiega revisori a lente singola con contesti nuovi (correttezza, sicurezza, conformità contrattuale, aderenza alle specifiche, qualità dei test), agisce solo su riscontri verificati (riprodotti da un test che fallisce) e itera fino a due passaggi consecutivi con zero riscontri. Misura la calibrazione introducendo bug noti, secondo uno schema simile al mutation testing. Gate di uscita: zero riscontri aperti, due passaggi a vuoto, test verdi, diff dei test vuoto.

## Titre Article

Prosecution, Not Code Review

## Date

2026-06-12

## URL

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

## Keywords

ADLC, prosecution, adversarial review, refutation vs evaluation, sycophancy, findings hallucination, fifteen-finding stopping bias, single-lens reviewers, fresh contexts, verified findings, phantom churn, loop-until-dry, review calibration, planted bugs, recall per category, false positives, exit gate, mutation testing

## Authors

Chris Williams (@voodootikigod)

## Ton

Profilo: advocacy metodologica (prospettiva del praticante in inglese, registro argomentativo e incisivo), livello tecnico elevato, pubblico target quality lead e ingegneri che costruiscono stack di revisione agentici. Il tono è quello di una riqualificazione concettuale: la metafora giudiziaria (accusa, onere della prova, riscontri verificati) struttura l'intero pezzo e sposta l'aspettativa da una revisione che "esprime un'opinione" a una che "dimostra un difetto riproducibile". L'autorevolezza si basa su un ancoraggio esplicito ai modi di fallimento (F2 compiacenza, F4 allucinazione, F6 bias sul numero di riscontri) e su un requisito di misurazione raramente applicato — "quasi ogni team si fida ciecamente del proprio stack di revisione". Stile strutturato attorno a principi numerati, un esempio concreto di bug introdotto (un controllo di verità che salta la verifica) e una chiusura con un gate di uscita rigoroso e verificabile.

## Pense-betes

- **Riformulazione centrale**: la revisione del codice non è una valutazione collaborativa ma un'**accusa** avversariale. Quando gli viene chiesta una revisione convenzionale, i modelli mostrano compiacenza, riscontri allucinati e un punto di arresto artificiale intorno a quindici problemi.
- **1. Confutazione anziché valutazione**: invece di chiedere un riscontro, assegna all'agente il mandato di "trovare cosa non va" o di spiegare come il progetto fallirebbe. Questo reindirizza il bias di compiacenza (F2) verso l'identificazione dei difetti anziché la ricerca dell'approvazione.
- **2. Accusa a lente singola**: impiega revisori paralleli con contesti nuovi, ciascuno che esamina **una sola** dimensione — correttezza, sicurezza, conformità contrattuale, aderenza alle specifiche o qualità dei test. Distribuire le preoccupazioni evita la saturazione del contesto che diluisce il giudizio.
- **3. Solo riscontri verificati**: prima che i builder agiscano, richiedi una verifica indipendente — riprodurre il bug tramite un test che fallisce, tracciare i percorsi del codice o generare l'input che lo innesca. I "riscontri non verificati" (F4) causano un reale churn per problemi fantasma.
- **4. Loop-until-dry**: riesegui l'accusa con contesti nuovi finché **due passaggi consecutivi** non producono riscontri verificati. Questo approccio basato sul campionamento neutralizza F6 (il prior di addestramento che si ferma intorno a 10-20 riscontri indipendentemente dal numero effettivo di difetti).
- **Misurazione della calibrazione**: quasi ogni team si fida ciecamente del proprio stack di revisione. La soluzione rispecchia il mutation testing: introdurre bug noti (mutazioni meccaniche + bug sottili scritti da un LLM), eseguire l'intero stack di accusa, misurare il recall per categoria e il tasso di falsi positivi.
- **Esempio di bug introdotto**: aggiungere un controllo di verità (truthiness guard) che salta la verifica quando un campo è assente — dall'aspetto difensivo, ma che introduce un degrado della sicurezza.
- **Gate di uscita**: la revisione passa quando (1) zero riscontri verificati aperti, (2) due passaggi a vuoto consecutivi, (3) suite di test verdi, (4) diff dei test **vuoto** (prova che i builder non hanno modificato i propri gate).

## RésuméDe400mots

Il quarto capitolo reinventa la revisione del codice per il mondo agentico. L'osservazione di partenza: quando ai modelli si chiede di eseguire una revisione convenzionale, deludono in modi prevedibili. La compiacenza (F2) li spinge ad approvare piuttosto che a criticare; l'allucinazione (F4) li porta a inventare problemi; e un bias di addestramento (F6) li fa fermare intorno a quindici riscontri, indipendentemente dalla densità effettiva dei difetti. Da questo Williams trae una riformulazione: ciò che serve non è una valutazione, ma un'accusa — un'imputazione avversariale.

Quattro principi strutturano questa accusa. Primo, confutazione anziché valutazione: invece di chiedere un riscontro, all'agente viene assegnato il mandato di "trovare cosa non va" o di spiegare come il progetto fallirebbe. Il bias di compiacenza, così ribaltato, gioca a favore. Poi, accusa a lente singola: anziché un unico revisore onnisciente, vengono impiegati agenti paralleli con contesti nuovi, ciascuno dedicato a una singola dimensione — correttezza, sicurezza, conformità contrattuale, allineamento con le specifiche, qualità dei test. Distribuire le preoccupazioni evita la saturazione del contesto che diluisce il giudizio tra priorità concorrenti.

Il terzo principio è solo riscontri verificati. Prima che un builder agisca su una critica, questa deve essere dimostrata in modo indipendente: riproducendo il bug tramite un test che fallisce, tracciando il percorso del codice, o producendo l'input che lo innesca. Senza ciò, i riscontri allucinati generano un reale churn di codice per problemi che non esistono. Il quarto principio è loop-until-dry: l'accusa viene rieseguita con contesti nuovi finché due passaggi consecutivi non producono più alcun riscontro verificato. Questo campionamento ripetuto neutralizza il punto di arresto artificiale di F6.

Williams segnala poi un punto cieco quasi universale: quasi ogni team si fida ciecamente del proprio stack di revisione, senza mai misurarne la reale capacità di rilevamento. La sua soluzione rispecchia il mutation testing applicato ai revisori: introdurre bug noti — mutazioni meccaniche più bug sottili scritti da un LLM — eseguire l'intero stack di accusa, quindi misurare il recall per categoria e il tasso di falsi positivi. Esempio di bug introdotto: un controllo di verità (truthiness guard) che salta la verifica quando un campo è assente, dall'aspetto difensivo ma che introduce una falla di sicurezza.

Infine, il gate di uscita è rigoroso e interamente verificabile: zero riscontri verificati aperti, due passaggi a vuoto consecutivi, suite di test verdi e un diff dei test vuoto — quest'ultima condizione a dimostrare che i builder non hanno modificato i propri gate per superarli.

## 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/it/fiches/williams-adlc-4-prosecution-not-code-review-2026-06-12/