Dovresti ancora rivedere il codice del tuo agente AI?

La discussione inizia allo stesso modo in ogni team. Una parte dice che gli agenti ora producono codice più pulito rispetto alla metà delle pull request che eravamo soliti approvare senza pensarci, quindi perché stiamo ancora leggendo ogni riga? L'altra parte dice perché siamo noi quelli che hanno approvato.

Entrambi hanno ragione. È esattamente per questo che la discussione non finisce mai. Non finisce perché la domanda è sbagliata, e una volta che correggi la domanda, la risposta diventa quasi noiosa.

Il caso per spedire senza leggere ogni riga

Inizia con la versione più forte dell'argomento ottimista, perché è più forte di quanto la maggior parte dei revisori ammetta.

In un compito delimitato con una chiara specifica e una suite di test, un agente di codifica moderno produce codice più coerente rispetto al mediano umano che lavora sotto scadenza. Non si annoia nel percorso degli errori. Scrive il controllo nullo alle 18:00 di venerdì. Segue le convenzioni di progetto che gli sono state date, ogni volta, senza le piccole ribellioni silenziose che un sviluppatore stanco si consente.

La revisione umana era già rotta prima che arrivassero gli agenti. Chiunque abbia lavorato in un vero team conosce il riflesso LGTM: l'attenzione del revisore crolla dopo alcune centinaia di righe, e le approvazioni che seguono sono sociali, non tecniche. Non abbiamo perso un'epoca d'oro di revisione rigorosa. Abbiamo perso un rituale che era già per lo più teatro.

Poi c'è il volume. Un sviluppatore che esegue cinque agenti in parallelo genera più diff all'ora di quanto qualsiasi umano possa leggere attentamente. Se la tua regola è "leggi tutto", ti sei silenziosamente reinstallato come il collo di bottiglia che hai appena automatizzato. Un umano che scorre un diff di 900 righe produce una firma senza produrre conoscenza, e questo è peggio che non rivedere affatto, perché produce sicurezza dove non ce n'è.

Il caso per mantenere un umano sul diff

Ora l'altra parte, che è anche più forte di quanto gli entusiasti ammettano.

La responsabilità non si trasferisce. Il modello non viene chiamato alle 3 del mattino. Non è nella revisione dell'incidente, non parla con il cliente i cui dati sono stati compromessi, e non porta la conseguenza della modifica nel trimestre successivo. Chiunque unisca possiede il risultato, e la revisione è il modo in cui la proprietà viene esercitata piuttosto che semplicemente dichiarata.

I revisori agenti falliscono nella stessa direzione degli autori agenti. Questo è l'argomento che risolve effettivamente la proposta "lascia che un altro agente lo riveda". Due agenti della stessa famiglia di modelli, dati lo stesso contesto, condividono prior, condividono dati di addestramento e condividono punti ciechi. I loro errori sono correlati. Un secondo agente catturerà felicemente un test mancante o un errore non gestito, e approverà felicemente il sottile fraintendimento del tuo dominio che ha prodotto il bug in primo luogo, perché ha fatto lo stesso fraintendimento. Due revisori che hanno torto nella stessa direzione non sommano a una revisione.

Le misurazioni non sono lusinghiere. I dati del settore mostrano che i revisori scambiano significativamente più giri su modifiche generate da AI rispetto a quelle scritte da umani: il codice arriva più velocemente e impiega più tempo a diventare affidabile. Uno studio di gennaio 2026 è andato oltre e ha scoperto che le modifiche generate dagli agenti portano più ridondanza e più debito tecnico accumulato per modifica rispetto a quelle scritte da umani, mentre i revisori segnalano di sentirsi meglio nell'approvarle. Quel divario, tra quanto bene si sente il codice e quanto è buono, è l'intero rischio in una frase.

Il dibattito è inquadrato male

Ecco il riformulamento che chiude la riunione.

Non stai rivedendo il codice perché non ti fidi dell'autore. Lo stai rivedendo perché sei tu quello che firma. Queste sono attività completamente diverse, e l'intera discussione nasce dalla confusione tra di esse.

Una volta che lo vedi in questo modo, "è l'agente migliore di un umano" smette di essere la domanda decisiva. La domanda decisiva è: se questa modifica è sbagliata, quanto costa scoprirlo e quanto costa annullarlo? Un errore di battitura in un titolo di marketing viene scoperto in secondi e annullato in secondi. Un controllo dei permessi invertito in un middleware di autorizzazione viene scoperto da un cliente, o da un regolatore, e non viene mai realmente annullato, perché nel frattempo i dati sono già stati letti.

Quindi la risposta non è né "rivedi tutto" né "fidati dell'agente". È:

Smetti di rivedere le righe. Inizia a rivedere il rischio.

Concretamente, la revisione si sposta dal centro del lavoro ai suoi due confini. Prima: leggi il piano, perché un piano sbagliato eseguito perfettamente è il modo di fallimento più costoso che ci sia, e un piano è quindici righe invece di novecento. Dopo: leggi il diff in proporzione al raggio d'azione. In mezzo, le righe appartengono alla macchina.

Come appare "l'agente ha sbagliato"

La cosa più utile che puoi riportare al tuo team non è un'opinione, è un elenco di segnali oggettivi. Non "il codice sembra strano", ma segnali che puoi controllare su un diff in meno di un minuto. Questi sono quelli che hanno guadagnato il loro posto.

1. I test sono cambiati nello stesso commit del codice che coprono. Il verde è stato costruito, non osservato. Questo è il segnale con il più alto valore nella lista, ed è quello da controllare per primo.
2. Un'asserzione è stata indebolita o un test è stato disabilitato. Un skip, un only, un'asserzione ampliata per accettare ciò che il nuovo codice restituisce, un try/catch che inghiotte l'errore che il test doveva esporre.
3. Il diff è più grande del compito. File di cui nessuno ha chiesto sono stati toccati. L'espansione del campo in un agente non è entusiasmo, è un segno che l'agente ha reinterpretato l'obiettivo da qualche parte lungo il cammino.
4. Una superficie inventata. Un metodo API, un'opzione di configurazione o un percorso che non esiste. Si compila nella testa dell'agente e da nessun'altra parte.
5. L'ambiente è stato fissato invece del codice. Un percorso assoluto hardcoded, un valore specifico della macchina, un token personale, un nome utente. Il sintomo è scomparso sulla macchina dell'agente e si è spostato su quella di tutti gli altri.
6. Una dipendenza è apparsa senza essere richiesta. Nuova catena di approvvigionamento, nuova licenza, nuova superficie di manutenzione, decisa da qualcosa che non la manterrà.
7. Duplicazione invece di riutilizzo. Ha reimplementato un helper che esisteva già venti righe più in alto. Questo è il meccanismo dietro il debito misurato: ogni modifica sembra localmente ragionevole e il codice base guadagna silenziosamente un terzo modo di fare la stessa cosa.
8. Il riepilogo non corrisponde al diff. "Fissato e testato" quando nessun test è stato eseguito. La narrazione viene generata con la stessa fiducia che il lavoro sia avvenuto o meno, quindi trattala come una rivendicazione da verificare, mai come un rapporto.
9. Le istruzioni hanno smesso di essere seguite. Piccole convenzioni silenziosamente abbandonate sono come una sessione degrada prima di iniziare a allucinare apertamente. Se usi un canarino nel tuo file di contesto, questo è esattamente ciò che è lì per catturare.
10. Terreno sensibile è stato toccato di passaggio. Una lettura di un .env, una nuova chiamata di rete in uscita, una nuova riga di log contenente dati utente, una migrazione inclusa in un commit di funzionalità.

Nota cosa non è nell'elenco: stile, nomi, formattazione, "l'avrei fatto diversamente". Questi sono sempre stati il punto più debole della revisione umana e ora sono genuinamente uno spreco di un umano. Eliminali dalla tua revisione e riacquisti l'attenzione di cui hai bisogno per i dieci elementi sopra.

Quanto merita una modifica di essere rivista?

Il raggio d'azione, non la dimensione del diff, decide. La tabella che il tuo team può adottare questo pomeriggio:

La dimensione del diff ti dice quanto tempo richiede la revisione. Il raggio d'azione ti dice se è opzionale.

Le righe non riguardano i livelli di fiducia. Riguardano il costo di avere torto, che è una proprietà del codice e non di chi lo ha scritto. Questo è ciò che rende la tabella utilizzabile: nessuno deve concordare su quanto siano bravi gli agenti per concordare sulla tabella. Se il tuo team è bloccato sulla questione filosofica, saltala e negozia invece le righe. Sarai sorpreso di quanto velocemente convergano.

Se il tuo prodotto gestisce dati personali in Europa, una riga in più è scritta per te dalla legge piuttosto che dal gusto: cosa deve rispettare una funzionalità costruita da AI sotto il GDPR non è una chiamata di giudizio, e "un agente l'ha scritta" non è mai stata una difesa.

Cosa cambia quando cinque agenti funzionano contemporaneamente

Tutto quanto sopra presuppone che tu possa vedere la modifica. Con agenti paralleli, quell'assunzione si rompe per prima, e si rompe in un modo specifico: il diff smette di avere un autore unico. Tre agenti hanno toccato l'albero di lavoro dall'ultimo tuo commit, e la domanda "chi ha cambiato questo file, e come parte di quale compito" non ha più una risposta ovvia. La revisione senza attribuzione non è revisione, è archeologia.

Questo è un problema di strumenti, ed è il motivo per cui AgentsRoom mette la revisione dove sono gli agenti piuttosto che alla fine di una pull request:

• Review Mode mostra ogni cambiamento che i tuoi agenti hanno fatto, come un diff leggibile, prima che venga impegnato qualcosa. È il passo "leggi il diff in proporzione al raggio d'azione", reso abbastanza economico da far sì che le persone lo facciano effettivamente.
• Revisione per agente filtra quel diff per agente e ti consente di impegnare il lavoro di ciascun agente separatamente. Cinque agenti paralleli diventano cinque unità revisionabili invece di un albero di lavoro illeggibile, e una modifica errata rimane attribuibile al compito che l'ha prodotta.
• Il messaggio di commit è generato dal vero diff con il pulsante scintillante nel campo di commit, quindi la storia descrive cosa è cambiato piuttosto che cosa l'agente ha detto di stare facendo. Quella distinzione conta alle 3 del mattino, sei mesi dopo.

Niente di tutto questo sostituisce il giudizio. Rimuove le scuse per non esercitarlo.

Fai in modo che la macchina possieda le righe

Se vuoi smettere di leggere righe, qualcos'altro deve leggerle. In pratica, quattro cose portano quel carico:

Test che l'agente non ha scritto nello stesso respiro del codice. Scritti per primi, o scritti da un agente diverso, o almeno rivisti come loro stessa modifica. Nel momento in cui codice e i suoi test provengono dalla stessa generazione, smettono di essere prove indipendenti.

Un revisore con un modello diverso. Questa è la risposta pratica al problema del fallimento correlato. Se un secondo agente rivede, eseguilo su un fornitore o una famiglia di modelli diversa da quella dell'autore. Non decorrelare completamente gli errori, ma un revisore della famiglia Codex su codice scritto da Claude cattura una classe di problemi misurabilmente diversa rispetto a un revisore dello stesso modello, proprio perché non condivide le priorità dell'autore.

Gate che non si stancano. Tipi, lint, scansione di segreti, soglie di copertura, un CI che rifiuta una migrazione inclusa in una funzionalità. Ogni regola che puoi esprimere come gate è una regola che non devi mai notare di nuovo.

Un ciclo che si chiude su se stesso. Un agente che costruisce, esegue il proprio lavoro contro il piano e itera prima di consegnare qualsiasi cosa rimuove l'intera categoria di "non è nemmeno stato eseguito" dalla tua revisione. Questo è il ciclo dell'agente autocorrettivo, ed è la differenza tra un agente che produce un diff e uno che produce un risultato. Non risponde alla domanda se un umano debba firmare. Significa solo che l'umano sta firmando qualcosa che funziona già.

Quindi, rivedi ancora?

Sì, e meno di quanto fai oggi.

Smetti di leggere righe per sentirti responsabile. Leggi il piano prima, perché è lì che vengono commessi gli errori costosi. Leggi il diff dopo in proporzione a ciò che può rompere, usando la scala piuttosto che il tuo umore. Tieni un umano, personalmente, su autenticazione, pagamenti, permessi, dati personali e qualsiasi cosa irreversibile, perché un modello non può mantenere la responsabilità e un secondo agente condivide i punti ciechi del primo. Affida tutto il resto a test, tipi, gate e un revisore che non condivide il modello dell'autore.

I team che sbagliano in questo falliscono in una delle due direzioni, e entrambe sono evitabili. Uno rivede tutto, diventa il collo di bottiglia e inizia silenziosamente ad approvare senza leggere, che è il peggio di entrambi i mondi. L'altro non rivede nulla, spedisce velocemente per due mesi e poi trascorre un trimestre a pagare un debito che non ha mai visto accumularsi.

Il dibattito al tuo standup non riguarda davvero se gli agenti siano bravi. Riguarda chi è disposto a firmare. Rispondi a questo, e la politica di revisione si scrive da sola.

Domande frequenti

Dovresti ancora rivedere il codice generato da AI?

Sì, ma non riga per riga su tutto. Rivedi il piano prima che l'agente inizi, poi rivedi il diff in proporzione a ciò che la modifica può rompere. Testi e CSS ricevono una scorsa. Autenticazione, pagamenti, permessi, dati personali e migrazioni vengono letti riga per riga da un umano, ogni volta.

Può un agente AI rivedere il codice di un altro agente AI?

Aiuta, ma non è un sostituto per un umano su codice rischioso. Due agenti della stessa famiglia di modelli, dati lo stesso contesto, tendono a fallire nella stessa direzione. I loro errori sono correlati, quindi un secondo agente cattura errori di battitura e test mancanti ma condivide i punti ciechi che hanno prodotto il bug. Se usi un revisore agente, eseguilo su un modello diverso da quello dell'autore.

Come fai a sapere se un agente AI ha commesso un errore?

Cerca segnali oggettivi nel diff piuttosto che leggere per stile. Il più forte: i test sono cambiati nello stesso commit del codice che coprono, il che significa che il verde è stato costruito e non osservato. Altri includono espansione del campo, un'asserzione disabilitata o indebolita, un'API inventata, un percorso locale hardcoded e un riepilogo che non corrisponde al diff.

Gli agenti AI sostituiranno i revisori di codice umani?

Hanno già sostituito la maggior parte della lettura delle righe. Non possono sostituire la firma. La responsabilità non si trasferisce a un modello, quindi un umano possiede ancora la decisione di unire qualsiasi cosa sia difficile da annullare.

Devi rivedere il codice AI riga per riga?

Solo dove il raggio d'azione lo giustifica. La revisione riga per riga non scala oltre pochi agenti in esecuzione in parallelo, e un umano che scorre un diff di 900 righe alle 18:00 produce una firma senza produrre conoscenza. Dedica quell'attenzione alle modifiche che sono costose da annullare.

Cosa non dovrebbe mai essere unito senza revisione umana?

Qualsiasi cosa che tocchi autenticazione, pagamenti, permessi, dati personali, migrazioni di database, percorsi di eliminazione e infrastruttura. Questi condividono una proprietà: il costo di avere torto non è proporzionale alla dimensione del diff.