Come fare la code review del codice generato dall’IA?

Con gli agenti di programmazione c’è più codice e la review dura di più

Questi quattro numeri vengono da un solo studio. Due ricercatori della Harvard University hanno seguito 718 aziende da gennaio 2021 a marzo 2026, con i dati di una piattaforma di analytics per i team di ingegneria (la versione di agosto 2026 dello studio). Un agente di programmazione è uno strumento che prende un compito, scrive codice su più file, esegue i test e riprova finché il lavoro non è finito. Nelle aziende che sono passate a questi strumenti le righe di codice aggiunte sono aumentate del 30%, i commit del 20% e le pull request del 23%.

Il lavoro completato non è cresciuto allo stesso ritmo: l’aumento dei ticket chiusi è piccolo e non è statisticamente significativo. La differenza la spiega lo stesso studio. Il tempo che passa tra l’apertura di una pull request e il suo merge si è allungato del 49%, la quota di pull request con modifiche richieste è quasi raddoppiata e i commenti di review per pull request sono aumentati del 35%. La conclusione degli autori: il collo di bottiglia è la code review.

Altre misure indicano lo stesso punto. Nel report 2026 di LinearB (oltre 8,1 milioni di pull request) le pull request generate dall’IA aspettano 4,6 volte di più prima che la review cominci, e quando qualcuno le prende in mano vengono esaminate due volte più in fretta. Nel sondaggio di Sonar su oltre 1.100 sviluppatori il 96% dei partecipanti non si fida del tutto della correttezza del codice generato dall’IA; chi dice di controllarlo sempre prima del commit è il 48%.

Noi sviluppiamo diffox, uno strumento che esamina le pull request; la lista qui sotto viene da quel lavoro e dalle regole del nostro repository, e puoi applicarla a mano, senza nessuno strumento.

Nel codice generato dall’IA ogni riga sembra ugualmente sicura

Quando esamini il codice di un collega, sai chi l’ha scritto: intuisci che cosa conosce bene e dove ha avuto fretta, e dove non sei sicuro glielo chiedi. Quando l’autore è un modello linguistico, niente di tutto questo c’è.

Lo studio pubblicato da JetBrains Research a ottobre 2026 descrive il problema così. Il modello presenta ogni riga che genera con la stessa sicurezza; nessun segnale ti dice che la logica di autenticazione era facile e la migrazione del database difficile. Leggere ogni riga non scala, man mano che le modifiche prodotte dagli agenti crescono. Secondo i ricercatori il punto non è leggere il diff, ma la calibrazione della fiducia: saper distribuire lo sforzo della review in proporzione al rischio di ogni parte. Lo studio si basa su quattro workshop con 17 professionisti e su un sondaggio a cui hanno partecipato 43 sviluppatori.

Anche i soliti campanelli d’allarme non funzionano. Nel codice scritto da una persona, una funzione disordinata o un commento lasciato a metà ti dicono «qui fai attenzione». Il codice generato dall’IA di solito compila, ha nomi puliti, e accanto ha i commenti e i test. Nel sondaggio di Sonar il 53% degli sviluppatori mette proprio questo tra gli effetti negativi dell’IA sul debito tecnico: codice che sembra corretto ma non è affidabile.

Come dovrebbe essere una checklist per la code review?

La lista propone un ordine. Alle prime due domande cominci a rispondere prima di entrare nel codice, e ti dicono dove guardare; la terza mette alla prova le evidenze; le ultime due chiedono ciascuna una lettura a parte. Anche lo studio di JetBrains indica la stessa direzione: prima il quadro generale, poi i file, per ultime le righe.

La lista è stata compilata per questo articolo. Le fonti: la guida di GitHub «Review AI-generated code», la guida di Google alla code review e le regole che applichiamo nel nostro repository.

Prima del codice, leggi la descrizione, i commenti e l’elenco dei file

Per la prima domanda, leggi la descrizione della pull request come un elenco di affermazioni. Se dice «ritenta tre volte una richiesta fallita», cerca i tre tentativi nel diff. Leggi allo stesso modo i commenti: un commento può descrivere ciò che il codice dovrebbe fare, non ciò che fa. Un esempio:

def fetch_prices(symbols):
    """Recupera i prezzi; se c'è un errore di rete, ritenta tre volte."""
    try:
        return client.get_prices(symbols)
    except Exception:
        return []

Questa funzione compila e passa il test che verifica il caso in cui va tutto bene. Ha due problemi. La docstring parla di tre tentativi, il codice prova una volta sola. E l’errore viene inghiottito: anche se il servizio è giù, il chiamante riceve una lista vuota e la legge come «nessun prezzo».

Per la seconda domanda, guarda l’elenco dei file prima di entrare nel codice. Se il compito era aggiungere un campo a un endpoint, la descrizione deve spiegare perché è cambiato un modulo che non c’entra. Poi leggi le righe rimosse: una riga aggiunta salta all’occhio, una validazione o una riga di log rimossa no. Per ogni comportamento rimosso, cerca se c’è ancora qualche punto che dipende da lui.

Il terzo controllo è il percorso dell’errore. La regola che seguiamo nel nostro repository è questa: un errore catturato deve arrivare al chiamante. Un except troppo ampio, un fallback che restituisce un valore predefinito o un valore di ritorno ignorato non correggono l’errore; lo rendono invisibile.

Un test che passa non sempre verifica qualcosa

Un agente di programmazione esegue i test da solo e riprova finché non passano. Per questo, nella pull request di un agente, «i test passano» è la condizione di partenza, non una prova di per sé. La guida di Google alla code review chiede la stessa cosa: se il codice si rompe, i test falliranno davvero? Un esempio:

def test_discount_is_applied():
    order = make_order(total=100)
    apply_discount(order, code="WELCOME10")
    assert order is not None

Questo test passa anche se lo sconto non viene applicato affatto. Il nome parla dello sconto; l’asserzione controlla solo che l’ordine esista. La correzione è una riga: assert order.total == 90.

Il primo controllo si chiama verifica per mutazione: annulli la correzione e guardi il test fallire. Nel secondo aiuta una distinzione: una ricerca non è una verifica. Un test che dice «il messaggio di errore non è nell’output» passa anche quando il messaggio non viene mai prodotto; ha bisogno di un controesempio che dimostri che la ricerca sa trovare qualcosa.

Anche i dati di test fanno parte dello stesso problema. Un esempio inventato a mano mette alla prova come l’autore si immagina i dati. Prendi l’esempio da un record reale, oppure confrontalo con un record reale.

Anche se il codice compila, la sicurezza va letta a parte

Secondo il report di luglio 2026 di Veracode, il codice generato senza indicazioni sulla sicurezza compila quasi sempre, ma passa i test di sicurezza in media nel 56% dei casi, su oltre 100 modelli. La percentuale cambia con il linguaggio: 63% in Python, 30% in Java. Il report mette alla prova i modelli così come sono, non un agente con intorno strumenti, protezioni o una review umana. La conclusione però è chiara: la sicurezza chiede una lettura a parte.

In questa lettura guarda tre punti. L’input che arriva dall’esterno raggiunge una query, un comando di shell o un percorso di file senza essere filtrato? Il nuovo endpoint ha lo stesso controllo delle autorizzazioni degli endpoint vicini, e nel codice o nei log è finito qualche segreto? Infine apri una per una le nuove dipendenze.

Uno studio accettato a USENIX Security 2025, su 576.000 esempi di codice generati con 16 modelli, ha trovato che in media almeno il 5,2% dei pacchetti suggeriti dai modelli commerciali, e il 21,7% di quelli suggeriti dai modelli open source, in realtà non esiste. Per questo la guida di GitHub consiglia di controllare se la dipendenza suggerita esiste, se è ancora mantenuta e che licenza ha.

Le regole scritte del repository sono il metro della review

La quinta domanda non chiede se il codice è corretto, ma se appartiene a questo repository. Se le tue regole sono scritte in un file (AGENTS.md, CLAUDE.md o CONTRIBUTING.md), tienilo aperto durante la review e leggi la modifica confrontandola con quel file.

Il primo degli altri due controlli riguarda i duplicati: potrebbe essere stato scritto un helper nuovo quando nel repository ce n’è già uno che fa lo stesso lavoro. Nel sondaggio di Sonar il 40% degli sviluppatori mette tra gli effetti negativi anche il codice superfluo e duplicato. Quando vedi una nuova funzione di utilità, cerca nel repository se ne esiste già una uguale.

Il secondo è che le due metà di un’operazione derivino dallo stesso valore. Se una funzione controlla la validità su una lista e poi esegue l’operazione su un’altra, oppure legge l’ora due volte in due punti diversi, le due metà sembrano corrette prese una per una; l’errore sta nel rapporto tra loro. La nostra regola: il valore si risolve una volta sola e si passa a tutte e due le metà.

Pull request piccole e attenzione al rischio rendono la lista applicabile

Applicare quindici controlli a una pull request di mille righe è difficile. La guida di Google considera ragionevole una modifica di circa 100 righe e spesso troppo grande una di 1.000, e dà al revisore il diritto di rifiutare una modifica solo per la sua dimensione. Lo studio di Harvard non ha trovato variazioni significative nella dimensione delle pull request dopo l’arrivo degli agenti di programmazione; la media di partenza era di circa 1.168 righe aggiunte per pull request. Chiedere all’agente pull request piccole, che fanno una cosa sola, è il primo passo della review.

Anche in una pull request piccola non tutti i file chiedono la stessa attenzione. L’ordine proposto dallo studio di JetBrains è dividere i file in base al rischio prima di leggere anche una sola riga.

Una parte della lista si può lasciare a uno strumento, un’altra no:

• Lascia fare allo strumento. Build, test, linter, analisi statica, scansione dei segreti, controllo di dipendenze e licenze.
• Lo strumento segnala, tu decidi. Contraddizione tra commento e codice, errore inghiottito, test vuoto, riga contraria al file delle regole. Se ciò che è stato trovato è davvero un bug lo decide chi conosce il contesto.
• Questo resta a te. Se la modifica risolve il problema giusto, se il design si adatta al repository, e la decisione sul merge.

diffox si colloca sul secondo di questi tre gradini. Fa leggere la pull request ad agenti specializzati che cercano ciascuno una sola cosa; quattro voci della lista compaiono nei commenti con il nome di quattro agenti: Broken Promise Agent per il commento che dice ciò che il codice non fa, Silent Failure Agent per l’errore inghiottito, Empty Test Agent per il test che passa qualunque cosa faccia il codice, House Rules Agent per la riga che viola il tuo file delle regole. diffox non blocca il merge; la decisione sul merge è del tuo team (come funziona, in un articolo a parte).