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.