Le code review grandi sono difficili. Dopo molte righe, la fatica aumenta e alcuni dettagli sfuggono. L'AI può aiutare a ridurre il rumore e segnalare problemi plausibili, ma deve restare un secondo reviewer. Non conosce tutto il contesto e può sbagliare con sicurezza.
Usata bene, l'AI non sostituisce la review umana: la prepara. Evidenzia punti da guardare, edge case, incoerenze e rischi. La decisione finale resta del team.
Aggiornamento luglio 2026
La code review AI oggi si divide in tre usi: review locale prima della PR, bot automatico in CI e agente che propone direttamente correzioni. Il terzo è potente ma va governato meglio: un agente che modifica il codice deve produrre diff piccoli, test eseguiti e spiegazione dei rischi, non solo commenti. È lo stesso principio del coding assistito da AI: accelerare senza perdere controllo.
La best practice aggiornata è separare finding da preferenze. Il bot deve segnalare bug, regressioni, sicurezza, performance e test mancanti; deve evitare commenti cosmetici se il progetto ha già formatter e linter. Ogni finding dovrebbe avere file, impatto, evidenza e fix suggerito. Se non trova problemi, deve dirlo.
Nei team maturi conviene aggiungere policy: niente auto-merge da AI, niente segreti nei prompt, niente review esterna su codice regolamentato senza contratto adeguato, audit log attivi e prompt template versionati. Questa parte rientra nella governance AI aziendale, non nella sola scelta tecnica del bot.
Cosa coglie bene
Un modello linguistico può essere utile per trovare:
- controlli null mancanti;
- edge case su array vuoti;
- error handling incoerente;
- race condition evidenti;
- duplicazioni;
- naming ambiguo;
- query inefficienti;
- uso insicuro di input utente;
- test mancanti per casi limite.
È anche bravo a riassumere una pull request: cosa cambia, quali file sono coinvolti e quali aree meritano attenzione.
Cosa non coglie
L'AI non conosce automaticamente requisiti non scritti, storia del prodotto, compromessi già discussi e priorità commerciali. Può proporre una soluzione "pulita" che rompe una convenzione interna o ignora un vincolo cliente.
Può anche generare commenti inutili: preferenze di stile, refactor non richiesti, osservazioni generiche. Per questo bisogna impostare un perimetro preciso.
Setup in CI
Un bot AI può girare su pull request in GitHub Actions, GitLab CI o strumenti dedicati. Il setup migliore non commenta ogni riga: produce un report sintetico con severità, file e motivazione.
Una configurazione utile distingue:
- bug potenziali;
- sicurezza;
- performance;
- test mancanti;
- compatibilità;
- osservazioni di stile solo se bloccanti.
I commenti devono essere pochi e verificabili. Se il bot produce rumore, il team smette di leggerlo.
Prompt template
Un prompt efficace per review può essere:
Revisiona questa diff come secondo reviewer.
Concentrati su bug, regressioni, sicurezza, performance e test mancanti.
Ignora preferenze di stile se non causano rischi concreti.
Per ogni finding indica file, problema, impatto e fix suggerito.
Se non trovi problemi, dillo esplicitamente.Per PR sensibili, aggiungi focus specifici:
- autenticazione;
- gestione permessi;
- pagamenti;
- migrazioni database;
- concorrenza;
- compatibilità browser.
Review locale
Non tutto deve passare da un bot remoto. Puoi usare l'AI localmente prima di aprire la PR. Questo è utile per pulire il diff, migliorare test automatici e ridurre round trip con il team.
Un buon flusso personale:
- genera la diff;
- chiedi una review focalizzata;
- correggi finding reali;
- esegui test;
- apri la PR con descrizione più chiara.
Regola d'oro
L'AI non deve approvare codice da sola. Può segnalare, spiegare e suggerire. Non deve diventare il gatekeeper unico, soprattutto su sicurezza, dati personali o logica di business.
Ogni finding va letto come ipotesi. Se è corretto, si corregge. Se è sbagliato, si ignora o si migliora il prompt.
Conclusione
L'AI nella code review funziona quando riduce carico cognitivo senza aumentare rumore. Il valore sta nei finding concreti, non nel numero di commenti. Usala come secondo controllo, sempre da verificare.