La revisione del codice — la code review — è quel momento in cui uno sviluppatore legge le modifiche scritte da un collega prima che finiscano nel prodotto. Si fa dentro una pull request: una proposta di modifica al codice, con l’elenco delle righe aggiunte e tolte, che qualcuno deve approvare.
È un rituale che tutti dicono di apprezzare e quasi nessuno fa bene. Le pull request si accumulano, chi deve rivederle ha il proprio lavoro da consegnare, e dopo la terza schermata di diff l’attenzione crolla. Da qui l’idea di far leggere le modifiche a un modello linguistico, che non si stanca e legge alla stessa velocità la riga 5 e la riga 5.000.
Funziona? In parte, e la parte conta.
Cosa fa concretamente un revisore AI
Il meccanismo è sempre lo stesso, al di là del fornitore. Quando apri o aggiorni una pull request, un sistema automatico prende il diff — cioè l’elenco delle righe cambiate — spesso insieme a un po’ di contesto attorno (i file toccati, a volte l’intero repository indicizzato), lo passa a un modello linguistico con l’istruzione “comportati da revisore”, e riporta i commenti direttamente sulle righe interessate, come farebbe un collega.
Nel caso di GitHub Copilot, la funzione si chiama Copilot code review e si aggiunge come revisore alla pull request esattamente come si aggiungerebbe una persona. GitHub ha spostato questa funzione su un’architettura ad agente che gira sopra GitHub Actions, cioè sull’infrastruttura di automazione della piattaforma: il revisore non è più un singolo passaggio del modello sul diff, ma un processo che può andarsi a leggere altri file del progetto prima di esprimersi. È il passaggio da modello ad agente nella sua forma più concreta, con tutto quello che comporta — anche sulla bolletta, come vedremo.
Con Claude di Anthropic il percorso più diffuso è la Claude Code GitHub Action: aggiungi un file di workflow al repository, metti la chiave API nei segreti, e configuri l’azione perché si attivi sugli eventi di pull request oppure quando qualcuno scrive @claude in un commento. La differenza rispetto a Copilot è che il prompt di revisione lo scrivi tu: puoi dire a Claude di concentrarsi sulla sicurezza, o sulle prestazioni, o sulle convenzioni interne del tuo team. Anthropic mantiene anche un’azione separata specifica per la revisione di sicurezza.
Su Cody di Sourcegraph serve un chiarimento, perché è il tipo di informazione che circola sbagliata per anni. Sourcegraph ha annunciato il 25 giugno 2025 la chiusura dei piani Cody Free e Cody Pro, che hanno smesso di funzionare il 23 luglio 2025; Cody è stato rimosso anche dal piano Enterprise Starter. Resta solo Cody Enterprise, che l’azienda dichiara pienamente supportato. Per tutti gli altri, Sourcegraph indirizza al nuovo prodotto Amp. Se stai valutando Cody oggi, valuta un prodotto enterprise con contratto, non un abbonamento da carta di credito.
Quello che un revisore AI trova davvero
Sui difetti a basso livello e a raggio corto, la macchina è brava. Parliamo di variabili non usate, valori che possono essere nulli e non vengono controllati, cicli che scorrono un elemento oltre la fine di un array, gestione degli errori dimenticata, risorse aperte e mai chiuse, condizioni logiche invertite. Sono errori banali, che chi li ha scritti non vede più perché ha gli occhi bruciati dal proprio codice, e che un revisore umano trova solo se è fresco e concentrato.
Sulla sicurezza il rendimento è discreto ma va inquadrato. Un revisore AI individua bene i pattern noti: input dell’utente concatenato dentro una query SQL, segreti scritti in chiaro nel codice, output non filtrato che finisce in una pagina HTML, dipendenze usate in modo pericoloso. Sono le classi di vulnerabilità documentate migliaia di volte nei dati su cui il modello è stato addestrato. Non individua invece le vulnerabilità che nascono dalla combinazione di due pezzi corretti presi singolarmente — il controllo dei permessi fatto in un servizio e non nell’altro, per dire — perché per vederle bisogna avere in testa il modello di minaccia dell’applicazione, e quello nel diff non c’è.
Sullo stile e sulle convenzioni la macchina è utile ma è anche il punto in cui produce più rumore, e ci torniamo tra poco.
Quello che non trova, e non troverà
Qui bisogna essere onesti, perché è dove si gioca la differenza tra uno strumento utile e una promessa venduta male.
Un revisore AI non valuta le scelte architetturali. Se un collega ha introdotto un nuovo servizio dove sarebbe bastata una funzione, o ha duplicato una logica che esisteva già in un altro modulo perché non sapeva che esistesse, il modello vede codice sintatticamente corretto e passa oltre. Vede l’albero, non il bosco, e il bosco è quasi sempre il problema.
Non conosce il contesto di business. Che quel campo debba essere obbligatorio perché lo chiede l’amministrazione finanziaria, che quella soglia sia 30 giorni per una ragione contrattuale e non per un capriccio, che quel comportamento apparentemente strambo esista perché tre anni fa un cliente importante ha protestato: sono informazioni che vivono nelle teste delle persone e nelle riunioni, non nel repository.
Non fa la cosa più preziosa che fa una revisione umana, che è trasferire conoscenza. Quando un senior commenta la pull request di uno junior, sta insegnando. Quando lo fa un modello, sta correggendo. Non è la stessa cosa e chi guida un team lo sa benissimo.
Il rumore dei falsi positivi, che è il vero problema
Un revisore automatico che commenta troppo è peggio di un revisore automatico che non esiste. Questa è la lezione che chiunque abbia introdotto un linter aggressivo in un team ha già imparato a proprie spese, e con l’AI il fenomeno è amplificato perché il modello non ha una nozione di soglia: se gli chiedi di trovare problemi, trova problemi. Anche dove non ci sono.
Il meccanismo di degrado è prevedibile, e lo racconto come dinamica tipica, non come misura. La settimana uno, il team legge tutti i commenti dell’AI. Qualche settimana dopo ha imparato che una buona parte sono irrilevanti — segnalano una cosa “migliorabile” che nessuno migliorerà mai — e inizia a scorrerli velocemente. Alla fine li chiude in blocco senza leggerli, e insieme agli irrilevanti chiude anche quelli veri. A quel punto lo strumento non solo non aiuta: ha addestrato il team a ignorare gli avvisi, il che è attivamente dannoso.
L’antidoto è controintuitivo e va imposto dall’alto: restringere brutalmente il perimetro. Un revisore AI configurato per commentare solo su sicurezza e su bug funzionali evidenti, con l’ordine esplicito di non commentare su stile, naming e preferenze, produce meno commenti e viene letto. Uno configurato per “aiutare a migliorare il codice” produce una valanga di commenti a ogni pull request e finisce disattivato.
I costi: chi paga la revisione e come
Dal 1° giugno 2026 il conto di GitHub è cambiato, e chi lo scopre a fine mese non è contento. In sintesi: ogni revisione fatta da Copilot consuma minuti di GitHub Actions sui repository privati, e l’uso complessivo di Copilot è passato a un sistema a crediti (il nuovo listino, confrontato con quello di Cursor e Claude Code, l’abbiamo spacchettato qui). Sui repository pubblici non cambia nulla: i minuti restano gratuiti.
Quello che interessa a chi gestisce le revisioni è la conseguenza, ed è specifica di questa funzione: la revisione automatica ha due contatori, e uno scatta a ogni push. Non a ogni pull request — a ogni push. Su un team che apre trenta PR al giorno su repository privati, con tre o quattro commit per PR, sono cento esecuzioni quotidiane di un agente che rilegge il diff, e nessuna di quelle esecuzioni è stata decisa da qualcuno: è il default. GitHub permette di impostare budget di spesa, e di limitare i trigger. Usare entrambe le leve non è pignoleria contabile, è progettazione del processo: se la revisione riparte a ogni virgola corretta, stai pagando il bot per rileggere lo stesso file otto volte.
Con Claude via GitHub Actions il modello di costo è diverso ma la sostanza no: paghi i token consumati sull’API Anthropic e i minuti di Actions del runner. Il vantaggio è che hai il controllo totale su quando far girare la revisione — solo alla prima apertura, solo sui file che contano, solo sui branch che stanno per andare in produzione — e quel controllo si traduce direttamente in bolletta.
Un esempio ipotetico, ma realistico
Immagina un team di sei sviluppatori in un’azienda di software gestionale italiana, con un repository privato e una media di venticinque pull request a settimana. Se ogni PR riceve tre push e ogni revisione impiega qualche minuto di runner, i minuti bruciati diventano una voce che si legge chiaramente nella fattura. È un esempio costruito, non un caso misurato: il punto non è il numero, è che il numero adesso esiste e prima no.
Come si integra in un flusso di lavoro serio
La configurazione che ha più senso, e che propongo come punto di partenza da adattare, è questa. È un’opinione, non un dato: poggia su come GitHub e Anthropic stesse descrivono l’uso previsto di questi strumenti nella loro documentazione.
La revisione AI gira prima di quella umana, non al posto e non dopo. Serve a ripulire: quando l’umano apre la pull request, i refusi, i controlli mancanti e le sviste evidenti sono già stati segnalati e corretti dall’autore. Il revisore umano arriva su codice già pettinato e può spendere la sua attenzione su cosa serve davvero — l’architettura, i nomi, la coerenza con il resto del sistema, le domande scomode.
I commenti dell’AI non bloccano il merge. Non sono approvazioni e non sono veti. Sono suggerimenti, e l’autore ha il diritto e il dovere di respingerli quando sono sbagliati. Un revisore automatico con potere di veto è il modo più rapido per far odiare l’automazione a un team.
L’approvazione resta umana e nominale. Deve esserci una persona con nome e cognome che ha detto “sì, questo può andare in produzione”, perché quando qualcosa si rompe alle tre di notte serve qualcuno che sappia perché quel codice è lì. Un log di sistema che dice “approvato da bot” non è una risposta.
L’opinione netta: chi vuole sostituire la revisione umana ha capito male il mestiere
Lo dico senza giri di parole, ed è la mia posizione, non un dato: chi propone la revisione AI come sostituto della revisione umana non sta ottimizzando un processo, sta smontando l’unico momento strutturato in cui un team di sviluppo condivide conoscenza.
La code review non serve solo a trovare bug. Serve a fare in modo che almeno due persone conoscano ogni pezzo di codice del sistema, che i nuovi assunti imparino guardando come si fanno le cose, che le decisioni discutibili vengano discusse quando costa poco farlo. Togli l’umano e trovi ancora i bug — forse anche più di prima, sui bug banali — ma perdi tutto il resto, e lo perdi in silenzio, senza che nessun indicatore te lo segnali, finché un anno dopo ti accorgi che metà del sistema la conosce solo la persona che sta per andarsene.
L’AI nella revisione è un ottimo primo lettore. È un pessimo ultimo lettore. Chi vende il contrario o non ha mai gestito un team, o ha qualcosa da vendere.
Cosa cambia per te
Se guidi un team di sviluppo, tre decisioni concrete.
Controlla la fattura di GitHub di giugno e luglio 2026. La revisione Copilot sui repository privati adesso mangia minuti di Actions e crediti, e se nessuno ha impostato un budget te ne accorgi dal costo, non da un avviso. Vale la pena farlo insieme al conto degli strumenti di scrittura: a parità di consumo reale il canone non è il costo, è il minimo, e le due voci finiscono nella stessa fattura.
Restringi il perimetro del revisore automatico a sicure
