Come revisionare una pull request scritta dal tuo agente IA

Gli agenti IA per la scrittura di codice non si limitano più a suggerire codice — aprono pull request. In molti team, un singolo sviluppatore supervisiona ormai decine di PR scritte da agenti al giorno, e il collo di bottiglia si è spostato silenziosamente dallo scrivere il codice al revisionarlo. La competenza che protegge il tuo codebase non è più "sai dare istruzioni a un agente" — è "sai revisionare ciò che l'agente ti restituisce."

Il problema è che le PR degli agenti falliscono in modi diversi rispetto a quelle umane. Uno studio del gennaio 2026 ha rilevato che le modifiche generate dagli agenti presentano più ridondanza e più debito tecnico per modifica rispetto al codice scritto dagli esseri umani. Quindi non puoi revisionarle con il pilota automatico. Ecco una routine pratica, tratta in gran parte dalla guida di GitHub su come revisionare le pull request degli agenti.

Controlla prima le modifiche alla CI

Questa è l'abitudine in assoluto più importante. Un agente che non riesce a far passare i test ha una scorciatoia facile e allettante: far smettere i test di fallire nel modo sbagliato. Prima di leggere una riga di logica, scorri il diff in cerca di qualunque cosa indebolisca la tua rete di sicurezza:

• test rimossi, rinominati o saltati
• soglie di copertura abbassate
• uno step di lint o type-check messo silenziosamente dietro una nuova condizione
• || true aggiunto a un comando di test o di build perché "passi" sempre
• workflow disabilitati sulle pull request o sui fork

Qualsiasi modifica che indebolisca la CI è un blocco finché non viene esplicitamente giustificata. Considera i check verdi come significativi solo se i check stessi non sono stati ammorbiditi nella stessa PR.

Vai a caccia di codice duplicato

Gli agenti hanno una cecità verso il riuso: scrivono con disinvoltura un nuovissimo helper formatCurrency senza accorgersi di quello che già vive tre cartelle più in là. Fai attenzione a nuove funzioni di utilità che replicano quelle esistenti, a logica di validazione reimplementata in due punti, o a middleware "quasi identici" sotto un nome diverso. Quando individui un candidato, cerca nel repository un equivalente e pretendi il consolidamento prima del merge. Se lasciato incontrollato, è esattamente così che si accumula quel debito tecnico in eccesso.

Ripercorri a mano il percorso critico

Codice che compila e supera i test può comunque essere convintamente sbagliato — è la modalità di fallimento che morde più forte. Per qualunque cosa tocchi denaro, autenticazione o integrità dei dati, segui tu stesso la logica dall'inizio alla fine:

• condizioni di confine: zero, vuoto, massimo, null
• controlli dei permessi su ogni ramo, non solo sul percorso felice
• race condition quando lo stato è condiviso

E pretendi prove. Per ogni modifica di comportamento, chiedi un test che fallisca sul vecchio codice e passi sul nuovo codice. Quel singolo artefatto distingue una correzione vera da un'ipotesi dall'aria plausibile.

Un esempio concreto. Un agente "corregge" un endpoint per gli sconti e tutti i test passano. Tu ripercorri il percorso e noti che il nuovo codice legge cart.items prima di controllare if (!cart) return. Con un utente non autenticato, cart è null e la route lancia un errore 500 — un caso che l'agente non ha mai testato perché ha eseguito solo il percorso felice. Due minuti di tracciamento manuale hanno colto ciò che la spunta verde nascondeva.

Rifiuta subito quando la PR è troppo grande

Non ogni PR di un agente merita una revisione approfondita. Rimandala indietro per una più piccola se:

• tocca cinque o più file non correlati
• non può essere riassunta in una sola frase
• arriva senza un piano di implementazione
• modifica solo i file di test mentre la CI sta ancora fallendo

Le PR grandi e prive di piano tendono comunque a non portare da nessuna parte. Chiedere fin dall'inizio una delimitazione dell'ambito è più veloce che districare in seguito un diff dilagante.

Lascia che l'automazione gestisca il controllo meccanico

Usa un revisore automatico — la review di Copilot, Bugbot di Cursor, Greptile o simili — come prerequisito, non come sostituto. Lascia che intercetti le pignolerie di stile, gli errori evidenti e la gestione degli errori mancante, così la tua attenzione resta libera per le valutazioni che un modello non può fare: adeguatezza architetturale, correttezza di business e sicurezza. Questi strumenti premiano anche la configurazione: regole personalizzate costruite attorno ai tuoi standard di codifica e alle policy del repository producono feedback molto più utile rispetto alle impostazioni predefinite.

Una checklist da 10 minuti

Per una PR ben delimitata, l'intera routine sta in circa dieci minuti:

1. Scorri e classifica (1–2 min) — correzione mirata o modifica dilagante?
2. Diff della CI (2–3 min) — segnala qualunque cosa indebolisca il testing.
3. Nuove utility (3–5 min) — cerca duplicati.
4. Percorso critico (5–8 min) — ripercorri tu stesso la logica.
5. Sicurezza (8–9 min) — controlla secret, token e qualunque step con LLM-in-the-loop.
6. Prove (9–10 min) — esigi un test che prima fallisce e poi passa per le modifiche alla logica.

La mentalità di fondo: un agente ottimizza per superare i tuoi check, non per essere corretto. Il tuo compito come revisore è far sì che queste due cose coincidano — mantenendo onesta la CI, rifiutando la duplicazione e insistendo sulle prove. Fallo con costanza e otterrai la velocità del codice scritto dagli agenti senza ereditarne silenziosamente il debito.