Revisione del codice con agenti di intelligenza artificiale: cosa trovano e cosa resta alla persona

La revisione del codice con agenti di intelligenza artificiale non elimina la revisione umana, ne cambia l'oggetto. Se una software house chiede a un agente di rileggere ogni pull request prima della persona, il tempo di revisione scende solo se la persona smette di leggere quello che l'agente legge bene e dedica l'attenzione a quello che non vede. Il 9 ottobre 2026 un gruppo di Microsoft Research ha pubblicato un benchmark che permette di dire, con numeri, quali sono le due categorie.

Cosa misura il benchmark di Microsoft Research sulla revisione del codice

Lo studio si intitola (When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection, è firmato da Chenyang Yang, Hao He, Ti-Chung Cheng, Jenna Butler, Emerson Murphy-Hill, Carmen Badea e Christian Bird, ed è uscito su arXiv il 9 ottobre 2026. Gli autori sono di Microsoft o Microsoft Research, e nella parte che ho letto non c'è una dichiarazione di finanziamenti o conflitti. Va tenuto presente perché l'harness che dà i risultati migliori è copilot-cli, lo strumento a riga di comando di GitHub Copilot.

Il benchmark si chiama CRBugBench e contiene 1.000 compiti ricavati da 98 repository open source in cinque linguaggi, più 800 compiti da due monorepo proprietari di una grande azienda che il testo non nomina. Ogni compito è una pull request che ha introdotto un bug vero. Metà dei bug è stata segnalata da un revisore prima del merge, l'altra metà è stata scoperta dopo, risalendo dalla correzione alla modifica che l'aveva causata.

L'agente riceve titolo e descrizione, scrive un file con i suoi rilievi in ordine di importanza, e si conta se il bug compare fra i primi cinque. Secondo gli autori il migliore, claude-opus-5 con copilot-cli, ne trova il 71,9%, contro il 47,7% di claude-opus-4.6 misurato cinque mesi prima.

Perché il 71,9% e l'82,1% vanno letti con cautela

Il 71,9% è una media fra le due metà del benchmark, e le metà differiscono: sui bug segnalati prima del merge lo stesso modello arriva al 79,6%, su quelli scoperti dopo al 64,2%. Il numero che descrive meglio la sua utilità è il secondo, perché sono i bug che nessun revisore aveva visto.

Il dato più citabile dello studio è un altro: le persone da sole troverebbero circa il 50% dei bug, l'agente migliore il 71,9%, insieme l'82,1%. Il testo ricava il 50% dalla costruzione del benchmark, perché un bug scoperto dopo il merge è per definizione sfuggito al revisore umano. È una somma costruita, non una misura di quanto trovi una persona che lavora con un agente accanto.

Due limiti riguardano il metodo. Lo studio non riporta la precisione, quindi non sappiamo quanti rilievi inutili accompagnino quelli giusti. E la verità di base è stata controllata a mano su 40 bug, di cui 37 validi, un campione piccolo. Il giudizio su cosa conti come bug trovato lo dà un pannello di tre modelli, in accordo con gli umani su 40 casi.

Dove la revisione umana deve restare, e dove si può togliere

La revisione umana deve restare dove l'agente fallisce in modo sistematico, e lo studio indica dove. Le modifiche più grandi riducono la probabilità di trovare il bug (odds ratio 0,591), le modifiche che mescolano più tipi di cambiamento la riducono (0,795), le pull request che correggono un bug sono più difficili delle altre (0,521). Le persone, invece, sono più brave a notare i problemi di manutenibilità (2,702).

Il divario più grande riguarda i repository aziendali: sui compiti proprietari la prestazione cala fino a 25,5 punti, e gli autori ne attribuiscono una parte alla visibilità. Il 22,8% dei bug dei repository interni si vede nel diff, contro il 46,1% di quelli GitHub. Per chi lavora su gestionali e integrazioni è la cifra decisiva, perché il bug tipico sta nel contratto con un sistema che il diff non mostra.

Il revisore AI si fida di quello che gli dici

Gli autori descrivono un errore di sovrafiducia: gli agenti accettano le affermazioni dell'autore o il codice esistente come prova di correttezza. Nei casi riportati un agente ha creduto a un commento fuorviante e alla descrizione della pull request in un compito su Selenium, e in uno su Elasticsearch ha usato la riga difettosa come criterio di correttezza. Gli agenti dedicano all'esecuzione del codice circa l'8% dei passi, il resto è lettura e ricerca.

Nel test del codice scritto da un agente ho scritto che una descrizione accurata sembra una validazione. Qui la stessa debolezza colpisce il revisore. Gli autori concludono che le prove reggono la modalità senza persone, in inglese "lights-off", soltanto per le pull request "narrowly scoped, low-consequence". Per le modifiche importanti serve una persona responsabile della decisione finale.

Cosa cambiare lunedì mattina nella revisione delle pull request

Le due azioni che seguono sono mie, non dello studio. Sono ipotesi di lavoro da provare su un repository vero, con soglie da tarare sui vostri dati.

Misurare su venti vostre correzioni

Prendete le ultime venti pull request di correzione unite nel vostro repository. Per ognuna risalite con git blame sulle righe corrette alla pull request che ha introdotto il difetto, poi fate rivedere quella pull request a un agente con la sola descrizione originale. Contate quante volte il difetto compare fra i primi cinque rilievi e quanti rilievi inutili escono. È il metodo dello studio, ridotto alla scala di un team, e vi dice se il 72% di un benchmark vale per il vostro codice. Se il numero è basso, l'agente resta un primo filtro e non diventa mai un sostituto.

Instradare la revisione per tipo di modifica

La regola che propongo si scrive in poche righe nel modello di pull request e nella CI:

revisione:
  primo_passaggio: agente        # su tutte le pull request
  da_dividere_prima: "più tipi di modifica nella stessa pull request"
  persona_obbligatoria:
    - "tocca un'integrazione o un contratto con sistemi esterni"
    - "correzione di un difetto già andato in produzione"
    - "diff oltre la soglia concordata (esempio: 400 righe, da tarare)"
  agente_vede: "diff, regole del repository, test; descrizione solo dopo il primo giro"

L'ultima riga è un'ipotesi non verificata, che nasce dalla sovrafiducia descritta sopra: se l'agente legge la descrizione dopo aver già formulato i suoi rilievi, ha meno occasioni di crederle.

Il blog che state leggendo ha la stessa struttura. Gli articoli li scrive una routine e li controlla lo script scripts/check-industrializzazione.mjs, che nel suo commento iniziale dichiara di non verificare che i fatti siano veri. Lo script funziona dove il perimetro è misurabile e non dice nulla fuori, ed è lo stesso limite di un revisore che vede il diff e non il contratto con il sistema esterno.

DETENT, il metodo che sto costruendo per software house e team di sviluppo, tratta la questione dal lato del processo: sul sito si legge che chi esegue non scrive le prove che lo giudicano e che prima del rilascio c'è la firma di una persona. Come si sposta il tempo di revisione senza ridurre il controllo lo spiego nella pagina su l'industrializzazione della produzione di software, e quali metriche dire in anticipo sta in cosa misurare dopo il merge.

Un revisore AI che trova sette bug su dieci è un buon primo filtro e un cattivo ultimo. Il tempo che avete risparmiato sulla lettura del diff va speso dove il diff non basta, e deciderlo prima di aprire la pull request costa meno che scoprirlo dopo il rilascio.