Il revisore non deve essere amico dell'autore

C’è un’idea seducente nello sviluppo assistito dall’AI: dopo che il modello ha scritto il codice, chiedi allo stesso modello di rivederlo. Sembra una rete di sicurezza gratis. Non lo è. È teatro.

Un’istanza che ha appena scritto una soluzione è predisposta a difenderla. La sua finestra di contesto è piena del ragionamento che ha portato al codice — ogni assunzione, ogni scorciatoia, ogni «questo dovrebbe funzionare» è lì, e il modello legge quella cronologia come prova che il codice è corretto. Chiedigli «è giusto?» e non ottieni una revisione, ottieni una conferma. Stesso contesto, stessi punti ciechi, stessi bug — ora con un timbro di approvazione sopra. È confirmation bias con qualche passaggio in più.

Il principio di design

Così, quando ho costruito critic-orchestrator — un server MCP che fa da gate al codice prima che venga spedito — ho reso l’indipendenza tutto il punto. Un claim («questo fix è corretto») non passa perché un modello annuisce. Deve sopravvivere a tre critici, e ogni critico è costruito per attaccare, non per essere d’accordo:

• Falsificazione — non chiede «il fix è giusto?», chiede «dimostra che il test fallisce davvero senza il fix». Mette da parte la modifica, esegue il test, e pretende di vedere il rosso prima del verde. Un fix il cui test passa senza il fix non è un fix — è un test che non verifica nulla.
• Verifica dei caller — la funzione corretta è davvero raggiungibile dalla produzione, o abbiamo corretto codice morto? Test verdi su un percorso inutilizzato sono una bugia che ti racconti.
• Controesempio — cerca attivamente l’input che rompe il claim, invece dell’input che lo conferma.

Il verdetto non è unanimità-per-default; è un voto spaccato in cui una singola obiezione ben fondata blocca il commit. Il gate è progettato per rendere lo spedire più difficile, perché il modo in cui lo sviluppo assistito dall’AI fallisce non è troppo poco codice — è troppo codice non verificato spedito troppo in fretta.

Minimizzare il contesto condiviso, di proposito

Il dettaglio critico: ogni critico deve condividere meno contesto possibile con l’istanza che ha scritto il codice. Un revisore che eredita il ragionamento dell’autore ne eredita i punti ciechi. Perciò la configurazione più forte crea un’istanza AI fresca per ogni worker — nessuna cronologia condivisa, nessun «ecco cosa stavo pensando», solo il diff, il claim, e il mandato di romperlo. Il revisore incontra il codice da estraneo e da scettico, che è l’unico modo in cui un revisore vale qualcosa.

Non è una metafora che uso alla leggera: è lo stesso motivo per cui la code review umana funziona meglio tra team diversi che dentro una sola testa, e lo stesso motivo per cui il doppio cieco batte il cieco singolo. L’indipendenza non è un vezzo. È il meccanismo.

Trova davvero qualcosa?

Sì — inclusi bug che l’autore (io, e il modello con cui facevo coppia) si era già convinto non ci fossero. Quello che mi ha reso credente era un bug di rollback atomico in un ciclo di consolidamento della memoria che il self-review aveva lasciato passare due volte; un worker di falsificazione, partendo a freddo, si è rifiutato di accettare il «funziona» e ha prodotto il caso che falliva. È tutta qui la proposta di valore: il critico vale la pena averlo esattamente quando è in disaccordo con te — e può essere in disaccordo con te solo se non sei tu.

La lezione generale

Man mano che deleghiamo all’AI sempre più la scrittura, il collo di bottiglia si sposta dal generare codice al fidarsi di esso. E la fiducia non arriva da un modello più grande o da una risposta più sicura. Arriva dall’architettura: verifica indipendente, contesto condiviso minimo, avversariale per costruzione, e un gate che preferisce bloccare una modifica buona piuttosto che far passare una cattiva. Costruisci lo scettico prima di averne bisogno.

critic-orchestrator è open source: github.com/aureliocpr-ctrl/critic-orchestrator.