Rivedere codice scritto da un agente: cosa controllare prima del merge

Il codice scritto da un agente di solito compila, passa il linter e ha l'aria di essere finito. È proprio questo il problema: la review diventa una firma veloce su un diff lungo. Questa guida mette in fila cosa controllare prima del merge, ricavato dalle guide ufficiali di GitHub, Anthropic (Claude Code), OpenAI (Codex), OpenSSF e OWASP, lette il 30 ottobre 2026. Non contiene test o misure fatti per questo articolo: le indicazioni sono quelle delle fonti citate.

In breve:

• Prima le verifiche automatiche: build, test, analisi statica e scansione delle dipendenze. La guida di GitHub sul codice generato dall'AI parte da qui.
• Poi l'intento: il diff risolve il problema giusto e rispetta le convenzioni del progetto? Un agente si ferma quando il lavoro sembra finito, non quando lo è.
• Ogni dipendenza nuova va verificata a mano: esiste, è mantenuta, ha una licenza compatibile. I pacchetti inventati sono un rischio reale.
• Guarda i test con sospetto: test cancellati, saltati o che verificano solo il mock non dimostrano niente.
• Tratta l'output dell'agente come input non fidato: niente stringhe passate a shell, SQL o HTML senza validazione e encoding (OWASP LLM05).
• Una review automatica, anche di Copilot o Codex, si aggiunge a quella umana. Non la sostituisce, soprattutto su autenticazione, pagamenti e infrastruttura.

Perché il codice di un agente va rivisto in modo diverso

Il codice di un agente va rivisto con gli stessi criteri del codice di una persona, ma con attenzione a errori diversi. La guida OpenSSF per le istruzioni agli assistenti di codice lo dice in modo netto: chi sviluppa resta responsabile del codice, e il codice generato non è una scorciatoia rispetto a review, test e analisi statica. Secondo la stessa guida gli assistenti possono introdurre crittografia o dipendenze obsolete, ignorare la gestione degli errori o lasciar trapelare segreti.

GitHub elenca gli errori tipici dell'AI: API inventate, vincoli ignorati, logica sbagliata, test cancellati o saltati invece che corretti, e codice che sembra giusto ma non fa quello che serviva. La documentazione di Claude Code spiega da dove nasce una parte del problema: l'agente si ferma quando il lavoro sembra finito. Se non ha un controllo da eseguire che restituisce passato o fallito, "sembra finito" è tutto quello che ha.

C'è poi un fatto di volume. Il rapporto Octoverse 2026 dice che a settembre 2026 oltre il 40% delle pull request su GitHub partiva dalla prima bozza di un agente. Più diff da leggere significa più tentazione di leggerli in fretta. Il resto del quadro è nel pezzo su cosa cambia dopo GitHub Universe 2026.

1. Prima le verifiche automatiche

La prima cosa da controllare è che il codice compili e che tutti i test passino senza nuovi warning. GitHub consiglia di far girare test e analisi statica prima di leggere una riga, con strumenti come CodeQL per le vulnerabilità e Dependabot per le dipendenze. OpenSSF aggiunge linter, SAST e controllo delle dipendenze in ogni ciclo di correzione.

Queste verifiche non trovano gli errori di logica, ma tolgono di mezzo quelli meccanici. Il tempo umano va dove serve davvero: capire se il cambiamento è giusto.

Un dettaglio sul codice degli agenti: guarda anche cosa è cambiato nella configurazione dei controlli. Un test marcato come skip, una regola del linter disattivata o una soglia di copertura abbassata fanno passare la CI senza risolvere niente.

2. Il diff risolve il problema giusto?

Il controllo più importante è sull'intento. GitHub suggerisce due domande: questo codice risolve il problema giusto? Segue le nostre convenzioni? Un agente può implementare in modo pulito una cosa che nessuno aveva chiesto, o risolvere il caso descritto nel prompt rompendo quello accanto.

La documentazione di Claude Code propone di rivedere il diff contro una specifica scritta, non in cerca di bug generici. L'esempio è un prompt che chiede di controllare che ogni requisito della specifica sia implementato e che i casi limite elencati abbiano un test, riportando solo i problemi di correttezza e saltando lo stile:

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

La parte "skip style" non è un dettaglio. Secondo Anthropic, un revisore a cui si chiede di trovare problemi ne trova sempre qualcuno, e chi corregge ogni segnalazione finisce con livelli di astrazione in più e test per casi che non possono succedere.

Codex segue la stessa logica. La documentazione di Codex sulla code review consiglia di descrivere il comportamento atteso e poi chiedere le prove: il percorso nel codice e i test che coprono il caso, con quello che resta da verificare. Ogni segnalazione va controllata sull'ultimo diff prima di decidere se correggerla.

3. Confini: cosa tocca il diff

La domanda successiva è dove arriva il cambiamento. Un diff che doveva toccare un componente e modifica anche autenticazione, permessi, migrazioni del database o file di deploy va fermato e diviso. GitHub consiglia una nuova review dopo ogni cambiamento che attraversa più servizi o pacchetti o che tocca comportamenti legati a sicurezza e dati.

Tre controlli pratici:

• Elenca i file toccati e chiediti se ognuno serviva per il compito.
• Cerca modifiche a file di configurazione, CI e permessi: .github/workflows, file di policy, regole di accesso al database.
• Controlla che l'agente non abbia toccato file che le sue istruzioni escludevano. Le regole vanno scritte prima, in AGENTS.md, CLAUDE.md o nelle regole di Cursor.

Lo stesso vale per quello che l'agente poteva fare durante il lavoro. La documentazione di sicurezza di Claude Code chiede di rivedere i comandi proposti prima di approvarli e di verificare le modifiche ai file critici. Le regole deny restano attive in ogni modalità di permesso, per esempio sulla lettura di .env.

4. Errori silenziosi e input non fidati

Gli errori più costosi sono quelli che non fanno rumore. OpenSSF chiede di gestire gli errori senza esporre dettagli interni come stack trace o percorsi del server, di validare ogni input esterno e di usare query parametrizzate. Nel codice di un agente vale la pena cercare in modo esplicito:

• blocchi catch vuoti o che registrano l'errore e continuano come se niente fosse;
• valori di default che nascondono un fallimento, come una lista vuota restituita quando la chiamata è fallita;
• segreti o chiavi scritti nel codice o nei log;
• query costruite concatenando stringhe.

Se il progetto usa un modello anche a runtime, c'è un rischio in più. OWASP LLM05:2025, Improper Output Handling descrive cosa succede quando l'output di un modello arriva a una shell, a una query SQL, a un percorso di file o al browser senza validazione: esecuzione di codice remoto, SQL injection, path traversal, XSS. La regola di OWASP è trattare il modello come qualsiasi altro utente, con un approccio zero trust. Sui segreti c'è una guida dedicata: segreti, .env e chiavi API nei progetti vibe coded.

5. Dipendenze nuove

Ogni riga nuova in package.json, requirements.txt o go.mod merita un controllo a mano. GitHub chiede di verificare che il pacchetto esista e sia mantenuto, di guardarne origine e autori, e di controllare che la licenza sia compatibile con il progetto: per esempio niente AGPL-3.0 in un progetto MIT, e niente pacchetti senza licenza dichiarata.

Il rischio più specifico degli agenti sono i pacchetti inventati. Uno studio presentato a USENIX ha misurato su 16 modelli di codice un tasso medio di pacchetti inesistenti del 19,6%: circa il 5% per i modelli commerciali e circa il 21% per quelli open source. Se un nome inventato ricorre, qualcuno può registrarlo con codice malevolo. È lo slopsquatting, spiegato nel dettaglio in dipendenze inventate dall'AI. OWASP lo usa come primo scenario d'attacco di LLM09:2025, Misinformation.

Due regole semplici: non installare un pacchetto che l'agente cita senza aprirne la pagina sul registro, e preferisci la libreria standard o una libreria nota quando basta. È lo stesso consiglio che OpenSSF dà come istruzione per l'agente.

6. Test che testano davvero qualcosa

Un test verde scritto dallo stesso agente che ha scritto il codice dimostra poco. GitHub mette tra gli errori tipici i test cancellati o saltati invece che corretti. Nel diff conviene controllare:

• se il numero di test è sceso o se compaiono skip, only o asserzioni commentate;
• se il test verifica il comportamento o solo che un mock sia stato chiamato;
• se esistono casi negativi: input non valido, permesso negato, servizio esterno che fallisce.

OpenSSF chiede esplicitamente test negativi per le funzioni critiche per la sicurezza, cioè test che verificano che quello che non deve succedere non succeda. Chi vuole misurare un agente su casi propri, oltre ai test del codice, trova un punto di partenza nel set minimo di eval per agenti.

7. Review automatica: utile, ma non basta

Copilot code review e Codex possono fare una prima passata sul diff. La documentazione sull'uso responsabile di Copilot code review è chiara: va usata per integrare la review umana, non per sostituirla. Copilot può non trovare tutti i problemi, soprattutto nei cambiamenti grandi o complessi, e può segnalare problemi che non esistono.

Dal 28 ottobre 2026 le approvazioni di Copilot sono in disponibilità generale. Se le attivi, contano tra quelle richieste dal repository e decadono quando arrivano nuovi commit. Sono disattivate di default, e chi amministra il repository sceglie su quali percorsi Copilot può approvare. OpenAI, nel post sulle regole di review per Codex, descrive Codex Code Review allo stesso modo: è un revisore in più, mentre test, protezione dei branch e approvazioni richieste restano il controllo vincolante.

In pratica: se una regola di protezione chiede una sola approvazione e quella approvazione può arrivare da Copilot, un diff può andare su main senza che nessuno l'abbia letto. Prima di attivare le approvazioni automatiche, decidi dove quella umana resta obbligatoria. Il confronto su come ogni strumento gestisce il controllo è in Claude Code vs Cursor vs Copilot in un progetto.

La checklist prima del merge

Da dove partire

• Scrivi una specifica breve prima di chiedere il codice, così la review ha qualcosa da confrontare.
• Metti le regole del progetto, i file vietati e i comandi da eseguire nelle istruzioni dell'agente.
• Fai girare test, linter e scansione delle dipendenze prima di leggere il diff.
• Controlla a mano ogni dipendenza nuova e ogni test rimosso.
• Tieni obbligatoria l'approvazione umana su autenticazione, pagamenti e infrastruttura.

Se il progetto sta per andare online, il passo successivo è la checklist per portare in produzione un sito vibe coded. Il resto del percorso su agenti e sviluppo con l'AI è nell'hub AI Engineering.