Code review AI: la policy per gestire il codice generato

Una policy di code review AI impone al team una regola non negoziabile: l'AI può scrivere e analizzare codice, ma la responsabilità del merge resta a una persona identificata. Ogni modifica realizzata con l'AI deve dichiararne l'impiego, superare controlli deterministici e ricevere una revisione umana commisurata ai danni che potrebbe provocare.

Oggi questa separazione è indispensabile. Il 17 agosto 2026, Wiz ha reso nota una vulnerabilità critica di injection in GitHub Actions all'interno di un repository pubblico di Snowflake. Il commit squash finale attribuiva a Copilot Autofix il ruolo di coautore e la revisione di sicurezza assistita dall'AI di GitHub aveva dato esito positivo. Wiz ha precisato esplicitamente che non è noto se la modifica al codice fosse stata realizzata con l'assistenza dell'AI. Cinque giorni dopo l'entrata in produzione della falla, un agente di sicurezza autonomo l'ha individuata e sfruttata durante un test autorizzato.

I conti spiegano perché i team vogliano comunque automatizzare. Un gruppo che gestisce 50 pull request alla settimana e dedica 30 minuti a ciascun primo controllo umano impiega 25 ore di lavoro degli ingegneri. Con un costo complessivo indicativo di $120 l'ora, si arriva a $3,000 alla settimana prima ancora delle verifiche più approfondite. GitHub stima attualmente che una review di Copilot consumi da $0.05 a $1 in crediti AI con il livello Lite oppure da $0.25 a $5 con Balanced, oltre ai minuti di GitHub Actions. Il primo passaggio sta diventando economico; l'autorità di approvare, invece, no.

A cosa serve davvero una policy di code review AI

Una buona policy regola il traffico del codice, non mette al bando l'AI. Dice agli autori cosa dichiarare, all'automazione cosa bloccare e ai revisori quando è obbligatorio un secondo controllo umano.

Si può immaginare una pull request come una merce in ingresso al porto. Test e scanner ispezionano il container. Un revisore AI legge il manifesto e segnala ciò che appare sospetto. Ma è ancora un funzionario umano a decidere se la merce può varcare il confine. Consegnare allo strumento d'ispezione il timbro del funzionario annulla il controllo.

Questo è il nucleo della policy:

Il codice creato o modificato in modo sostanziale con uno strumento di programmazione AI è ammesso solo tramite una pull request. L'autore resta responsabile della comprensione della modifica e deve indicare lo strumento, l'ambito dell'assistenza AI, i test eseguiti e il responsabile umano. I test e i controlli di sicurezza richiesti devono superare la verifica prima dell'approvazione. La review AI ha valore consultivo e non conta mai come approvazione umana obbligatoria. I file sensibili richiedono un code owner. Le modifiche critiche richiedono un secondo approvatore indipendente e un piano di rollback. I nuovi commit invalidano le approvazioni precedenti e fanno ripartire la revisione.

La policy si basa sulle conseguenze, non sul rilevamento della paternità del codice. Uno sviluppatore non dovrebbe dimostrare quali singole righe provengano dall'autocompletamento. Deve invece dichiarare l'assistenza sostanziale dell'AI e assumersi la responsabilità dell'intero diff. È molto più utile che discutere di una percentuale che nessuno strumento può trasformare in una decisione di approvazione.

Tre livelli di revisione

Il livello Critico è volutamente costoso e dovrebbe riguardare solo una piccola parte delle modifiche. L'obiettivo è concentrare la scarsa attenzione dei profili senior dove un errore plausibile può esporre credenziali, danneggiare dati o modificare chi dispone di un accesso.

Come funziona, senza gergo

Il workflow prevede sei passaggi di controllo. Ognuno produce evidenze che il revisore successivo può esaminare.

1. Dichiarare l'assistenza. Aggiungere al template della pull request i campi AI-assisted, tool, scope, human owner e tests run. L'autore risponde di ogni riga, che l'AI abbia scritto una sola funzione o l'intera prima bozza.
2. Classificare il rischio. Un piccolo file di policy associa percorsi e tipi di modifica ai livelli Ordinario, Sensibile o Critico. Una modifica a .github/workflows/ non dovrebbe mai seguire lo stesso percorso di un refuso nella documentazione.
3. Eseguire prima i controlli deterministici. Un controllo è deterministico quando lo stesso input produce sempre lo stesso esito positivo o negativo. Prima di chiedere un parere a un altro modello, occorre compilare, verificare i tipi, eseguire il linting e i test, cercare segreti, controllare le dipendenze e svolgere un'analisi statica di sicurezza. Anche le linee guida di GitHub sulla revisione mettono al primo posto i test automatizzati e l'analisi statica.
4. Usare l'AI come interlocutore critico. Le si può chiedere di cercare casi mancanti, incompatibilità architetturali, test eliminati, API inesistenti, pacchetti sospetti e modifiche ai permessi. Per attività sensibili sul piano della sicurezza o trasversali a più servizi è opportuno adottare una review più approfondita. L'auto-review dell'agente che ha scritto il codice non deve poter soddisfare il requisito.
5. Affidare il verdetto a una persona. Il revisore verifica l'intento, mette alla prova il comportamento rischioso, contesta le nuove dipendenze e decide se il diff debba entrare nel sistema. I commenti dell'AI sono indizi, non rilievi accertati, finché una persona o uno strumento deterministico non li conferma.
6. Azzerare le approvazioni dopo ogni push. Bisogna revocare quelle ormai superate, rieseguire i controlli obbligatori e richiedere un'altra review quando arrivano nuovi commit. GitHub segnala che, di norma, la review automatica di Copilot viene eseguita una sola volta, a meno che non sia attiva l'opzione di revisione a ogni push.

La policy deve includere anche due controlli meno intuitivi. Primo: i file delle dipendenze richiedono uno scanner dedicato, perché la code review di GitHub Copilot esclude file come package.json e Gemfile.lock. Secondo: le modifiche ai file di istruzioni per l'AI devono ricevere una revisione critica. Copilot legge le istruzioni del repository, quelle degli agenti e le skill dal branch head della pull request; la modifica proposta può quindi alterare le istruzioni con cui viene esaminata.

Sette contesti in cui questa policy genera subito valore

1. Platform team che gestiscono coding agent su molti repository

I team di platform engineering sono quelli che possono ricavarne il massimo vantaggio, perché una sola policy governa migliaia di modifiche future. La mappa dei rischi può risiedere in un template condiviso, con gli stessi campi obbligatori per le dichiarazioni e un unico status check comprensibile da ogni branch protetto. Il beneficio è un controllo centralizzato, senza costringere ogni team di prodotto a inventare il proprio processo. Chi confronta i migliori coding agent AI per le aziende può cambiare strumento senza dover ricostruire il modello di approvazione.

2. Team SaaS che proteggono autenticazione, fatturazione e dati dei clienti

Un responsabile engineering SaaS può classificare come Critici l'autenticazione, i controlli dei permessi, il codice dei pagamenti e i percorsi di esportazione dei dati. Un agente può preparare una correzione e un revisore AI può valutarla, ma servono l'approvazione del responsabile per identità o pagamenti e quella di un'altra persona. Il vantaggio è la concentrazione: i revisori senior non dedicano lo stesso tempo a ogni file, ma si focalizzano sulle modifiche con un vero raggio d'impatto.

3. Team DevOps responsabili dei workflow CI/CD

I file dei workflow vanno trattati come infrastruttura di produzione eseguibile. Ogni modifica deve passare da un code owner DevOps; occorre cercare l'interpolazione diretta di contenuti non attendibili provenienti da issue o pull request, controllare i permessi dei token e richiedere un rollback. Il caso Wiz rende tangibile il beneficio: il titolo di una issue pubblica è arrivato a un comando shell e il token esposto poteva leggere progetti Jira interni. Una policy intercetta questa classe di errore prima ancora che qualcuno discuta se l'autore originale fosse una persona o un'AI.

4. Responsabili engineering che introducono Copilot, Codex o Claude Code

Chi guida l'adozione può separare il permesso di usare uno strumento dal permesso di effettuare il merge. Gli sviluppatori ottengono generazione rapida e una prima review, mentre le ruleset dei branch continuano a richiedere l'approvazione umana, workflow completati con esito positivo e review del code owner. Il risultato è un'adozione governata da controlli verificabili. Un'analisi delle modalità di review locale e su GitHub di Codex può orientare la scelta dello strumento, ma il gate umano deve restare valido anche se cambia il fornitore.

5. Maintainer open source alle prese con pull request prive di contesto

Si possono aggiungere a CONTRIBUTING.md una casella per dichiarare l'assistenza AI e una checklist delle evidenze, lasciando poi all'automazione il compito di respingere le proposte senza passaggi di riproduzione, test o un maintainer responsabile. L'AI può riassumere e preselezionare la coda. Le persone dedicano così il proprio tempo all'intento, alla compatibilità e alla coerenza del contributo con il progetto. Il beneficio è un debito di review inferiore senza abbassare di nascosto l'asticella per chi arriva dall'esterno.

6. Agenzie che consegnano software di proprietà del cliente

Un'agenzia può allegare a ogni release un'attestazione di review con gli strumenti impiegati, i componenti interessati, i risultati dei test, i rilievi irrisolti e i nomi degli approvatori. I percorsi sensibili del cliente vengono sottoposti al suo code owner prima del rilascio. Il beneficio è una responsabilità più chiara e un documento di passaggio che rimane valido anche dopo l'uscita del team di delivery.

7. Founder solitari che rilasciano software con un coding agent AI

Un founder senza team non dispone normalmente di una seconda persona indipendente, quindi il workflow deve creare una separazione. Un modello prepara la bozza, i controlli deterministici vengono eseguiti, un diverso passaggio di review valuta il risultato e infine il founder prova personalmente il percorso rischioso prima del merge. Per pagamenti, autenticazione o infrastruttura di produzione va coinvolto uno specialista esterno. Il beneficio è un primo filtro economico, senza fingere che un secondo modello equivalga a una seconda persona responsabile.

Cosa si può costruire a partire da questa policy

Il mercato sta già pagando per automatizzare la review. Negli Stati Uniti, la domanda mensile su Google è di circa 1,600 ricerche per "ai powered code review platform", 1,300 per "ai code review" e 590 per "ai code review tools". CodeRabbit applica attualmente un prezzo di $24 per sviluppatore al mese per i piani Pro annuali e di $48 per Pro Plus. Qodo parte da $30 al mese. Lo spazio di mercato non è per l'ennesimo bot che commenta ogni pull request, ma per un livello di controllo capace di stabilire quale review abbia davvero valore.

1. Un gate policy-as-code per le pull request: l'opportunità più solida

Si può creare una GitHub App per responsabili engineering e sicurezza che trasformi un breve file di policy in controlli obbligatori. L'app legge i percorsi modificati, verifica la dichiarazione sull'uso dell'AI, assegna un livello di rischio, coinvolge i code owner corretti, conferma l'esecuzione degli scanner richiesti, invalida le approvazioni superate e produce un'attestazione di audit.

La domanda sostiene la categoria: "ai powered code review platform" registra circa 1,600 ricerche mensili negli Stati Uniti, mentre "ai code review" ne totalizza 1,300 con un CPC di $63.85. La versione minima vendibile richiede una GitHub App, un file di policy nel repository, uno status check, un servizio per instradare i revisori e una tabella di audit. L'ostacolo è la fatica di configurazione. Il prodotto può vincere solo se impostazioni predefinite efficaci coprono gli stack più comuni e le eccezioni sono facili da spiegare.

2. Un router dei revisori per i file critici

Si può realizzare uno strumento più mirato per i team di platform engineering e AppSec. Monitora percorsi come workflow, infrastruttura, migrazioni, autenticazione e file di policy; aumenta quindi il livello della review, coinvolge il responsabile giusto e impone una nuova revisione dopo ogni push. Può sottoporre il codice ordinario a un passaggio economico e riservare il ragionamento più costoso e il tempo umano ai diff critici.

"AI code review tools" genera circa 590 ricerche mensili negli Stati Uniti, ha intento commerciale e mostra un trend annuale del 50% nel dataset delle keyword. "Secure code review" aggiunge 170 ricerche al mese, con un CPC di $50.19. L'MVP comprende regole per i percorsi, integrazione con CODEOWNERS, un'interfaccia check-run e un instradamento della review attento al budget. Il rischio è l'espansione incontrollata della categoria: deve affiancare SAST, scansione dei segreti e analisi delle dipendenze, non presentarsi come un loro sostituto.

3. Un'attestazione di provenienza per le modifiche AI

Si può creare una CLI leggera con un bot per pull request, destinata ad agenzie e team regolamentati. Registra lo strumento dichiarato, l'identificativo della sessione, i file modificati, i test eseguiti, le decisioni dei revisori e il responsabile umano finale, poi genera un'attestazione di rilascio firmata. Deve dimostrare il processo, non tentare di indovinare la paternità del codice dal suo stile.

Circa 210 ricerche mensili negli Stati Uniti riguardano un "ai generated code detector", con un CPC di $16.70. La domanda segnala una preoccupazione reale, ma il rilevamento è la promessa di prodotto sbagliata. La versione vendibile offre invece agli acquirenti evidenze della revisione e della responsabilità. Il problema è la partecipazione: se i team possono aggirare la dichiarazione, l'attestazione diventa una messinscena. La protezione dei branch e l'integrazione dell'identità sono il prodotto, non accessori facoltativi.

Resta aperto anche il vuoto sul fronte delle citazioni. Il controllo delle citazioni su ChatGPT non ha rilevato fonti citate con regolarità per "ai code review tools". Un prodotto che pubblica uno schema di policy rigoroso e versionato, insieme a controlli trasparenti, può diventare il livello di riferimento e vendere il sistema che ne garantisce l'applicazione.

Limiti e valutazione onesta

La review AI è un filtro utile, non una garanzia di sicurezza. GitHub afferma che la review di Copilot può non rilevare alcuni problemi e deve essere affiancata da una revisione umana. Esclude inoltre alcuni file, può ricorrere a una modalità meno capace quando i runner non sono disponibili e si interrompe una volta esaurito il budget dei crediti AI. Nessuna di queste condizioni dovrebbe abbassare in silenzio la soglia richiesta per il merge.

L'autofix agentico incontra lo stesso limite. Il sistema di GitHub in anteprima pubblica può esplorare una codebase, proporre una correzione, rieseguire CodeQL e aprire una pull request in bozza, spesso in un intervallo tra due e quattro minuti. GitHub precisa anche che opera in modalità best effort, non può confermare le correzioni per alcune query personalizzate o con estensioni di sicurezza e non garantisce la qualità delle correzioni per gli alert di terze parti. Un nuovo esito verde dimostra che un rilevatore ha smesso di segnalare il problema. Non dimostra che il comportamento di business, il modello dei permessi o il workflow circostante siano sicuri.

Questa policy non risolve il rilevamento della paternità, i test deboli, la mancanza di conoscenza architetturale o una cultura in cui le pull request vengono approvate meccanicamente. Diventa inoltre troppo pesante se ogni refuso finisce nel livello Critico. Il percorso Ordinario deve restare economico, quello Critico circoscritto, e lo strumento che ha prodotto una modifica non deve mai diventare l'unica autorità autorizzata ad approvarla.

La mossa da fare lunedì

Lunedì, un engineering manager dovrebbe aggiungere cinque campi al template della pull request: AI-assisted, tool, scope, human owner e tests run. Poi dovrebbe classificare come Critici .github/workflows/, autenticazione, pagamenti, infrastruttura di produzione, segreti e migrazioni distruttive. Per questi percorsi vanno richiesti esito positivo della CI, review del code owner, revoca delle approvazioni superate e un secondo revisore umano. È sufficiente per trasformare un'opinione sul codice generato dall'AI in una prima versione applicabile.

Devo fare la code review del codice generato dall'AI?

Sì. Prima si eseguono test e scanner deterministici, poi si usa la review AI come ulteriore valutazione critica e infine si assegna a una persona identificata la responsabilità del merge. La review AI non deve soddisfare il requisito dell'approvazione umana obbligatoria.

ChatGPT può fare una code review?

Può analizzare criticamente un diff, chiedere i test mancanti e segnalare logiche sospette. Non può applicare la protezione dei branch, dimostrare che la CI sia stata eseguita né assumersi le conseguenze in produzione. Va usato all'interno della policy, non al suo posto.

Qual è la migliore AI per la code review?

La soluzione più adatta è quella che comprende abbastanza contesto del repository, si integra con i controlli esistenti, rispetta le regole sui dati e lascia una traccia di audit chiara. La qualità del modello conta, ma l'integrazione con il gate di merge e la responsabilità umana contano di più.

Esiste uno strumento gratuito per la code review AI?

Esistono componenti gratuiti o inclusi. La versione classica di Copilot Autofix di GitHub non richiede un abbonamento a Copilot né consuma crediti AI per i repository idonei, mentre gli strumenti CI esistenti possono applicare molti controlli deterministici. Una policy completa richiede comunque configurazione e revisione umana.

Per integrare questo gate di revisione nel workflow di engineering, scopri i sistemi AI per la produzione.