C'è un momento preciso in cui un team di sviluppo smette di fidarsi del codice generato dall'intelligenza artificiale. Di solito arriva di venerdì sera, quando un bug in produzione fa saltare un servizio e, risalendo la catena dei commit, si scopre che quel blocco di codice non l'ha scritto nessuno del team. L'ha scritto un agente AI. E nessuno l'ha davvero letto prima di fare merge.
Google ha recentemente introdotto le Automated Reviews all'interno di Conductor, il suo strumento interno per la gestione del codice. Non è un dettaglio tecnico per addetti ai lavori: è un segnale chiaro che anche chi ha più risorse al mondo per l'AI riconosce un problema reale. Il codice prodotto dagli agenti AI va controllato. E servono processi strutturati per farlo, non buone intenzioni.
Il paradosso della produttività AI
La promessa degli strumenti di coding AI è semplice: scrivi meno codice a mano, produci di più, vai più veloce. E in effetti funziona. Chiunque abbia usato un assistente AI per lo sviluppo sa che la velocità di produzione del codice aumenta, a volte in modo significativo.
Ma c'è un problema che si manifesta con un leggero ritardo. Più codice produci, più codice devi mantenere. E se quel codice non l'hai scritto tu, se non ne conosci ogni angolo, la manutenzione diventa un'incognita.
Ho visto progetti dove il 60-70% del codice era stato generato da agenti AI nell'arco di poche settimane. I primi giorni tutto sembrava andare bene. Poi qualcuno ha provato a modificare una funzione e si è reso conto che le dipendenze interne erano un labirinto. L'AI aveva risolto ogni singolo task in modo corretto, ma l'architettura complessiva non aveva senso. Nessun essere umano avrebbe strutturato il codice in quel modo, perché nessun essere umano pensa a un problema un prompt alla volta.
Questo è il paradosso: l'AI ti fa andare veloce nella scrittura, ma può rallentarti nella comprensione. E nel software, la comprensione è tutto.
Cosa ha fatto Google con le Automated Reviews
Google non ha reagito a questo problema dicendo "usate meno AI". Ha fatto il contrario: ha aggiunto un altro layer di automazione. Le Automated Reviews in Conductor sono un sistema che analizza il codice generato dagli agenti AI prima che venga integrato nel codebase principale.
In pratica, quando un agente AI produce una pull request o una modifica, il sistema attiva una serie di controlli automatici. Non si tratta solo di linting o di analisi statica tradizionale. Le Automated Reviews verificano la coerenza con i pattern architetturali del progetto, controllano che le convenzioni del team siano rispettate e segnalano potenziali problemi di sicurezza o di performance.
La cosa interessante è la filosofia dietro questa scelta. Google non sta cercando di sostituire la review umana con una review AI. Sta cercando di filtrare il rumore. Se un agente AI produce dieci pull request in un'ora (cosa che succede regolarmente), un reviewer umano non può analizzarle tutte con la stessa attenzione. Le Automated Reviews fanno un primo passaggio, evidenziano i punti critici, e permettono al reviewer umano di concentrarsi su ciò che conta davvero.
Perché fidarsi ciecamente dell'AI è un errore
Parlo per esperienza diretta. Noi di Bajara lavoriamo quotidianamente con agenti AI per lo sviluppo software, e abbiamo imparato sulla nostra pelle che la fiducia cieca non funziona.
Il codice generato dall'AI ha alcune caratteristiche ricorrenti che lo rendono insidioso.
Primo: funziona quasi sempre al primo colpo per il caso d'uso richiesto. Se chiedi a un agente AI di creare un endpoint API che restituisce una lista filtrata, lo farà correttamente. Il problema è "quasi". Quel "quasi" si nasconde nei casi limite, nella gestione degli errori, nelle race condition, nei problemi di sicurezza che emergono solo sotto carico o con input inattesi.
Secondo: il codice AI tende a essere verboso in modo specifico. Non è il tipo di verbosità di uno sviluppatore junior che non conosce le shorthand del linguaggio. È una verbosità strutturale, dove ogni funzione è autocontenuta, con poca condivisione di logica tra componenti. Questo rende il codice apparentemente leggibile ma difficile da mantenere su scala.
Terzo, e probabilmente il punto più sottovalutato: l'AI non ha contesto progettuale. Sa tutto del linguaggio, conosce i pattern, ha visto milioni di repository. Ma non sa perché il tuo team ha scelto quella specifica architettura, non conosce i vincoli di business, non sa che quel microservizio è stato scritto in fretta tre anni fa e che toccarlo è rischioso.
Il vero costo del codice non revisionato
Quando parliamo di code review, tendiamo a pensarla come un costo. Tempo che gli sviluppatori passano a leggere il codice di altri invece di scrivere il proprio. Ma questa è una visione miope.
Il codice non revisionato ha un costo nascosto che si accumula nel tempo. Ogni riga di codice che entra in un codebase senza essere stata compresa da almeno un'altra persona è debito tecnico potenziale. Magari non esplode oggi, magari non esplode domani. Ma quando esplode, il costo per capirlo e sistemarlo è ordini di grandezza superiore a quello che sarebbe servito per una review decente.
Con il codice AI, questo effetto si amplifica. Un sviluppatore umano che scrive codice mediocre di solito lo fa in modo prevedibile. Conosci i suoi pattern, sai dove tende a sbagliare. Un agente AI può produrre codice che sembra perfetto in superficie ma contiene problemi sottili che richiedono competenza specifica per essere individuati.
Un esempio concreto: durante un progetto recente, un agente AI ha generato una funzione di autenticazione che gestiva correttamente tutti i flussi di login e logout. Superava tutti i test. Ma usava un confronto di stringhe non constant-time per verificare i token, aprendo una potenziale vulnerabilità a timing attack. Nessun test automatico l'avrebbe individuata. Ci è voluto un occhio umano, durante una review, per notarlo.
Come impostare un workflow di review che funzioni
Basta con la teoria. Vediamo cosa serve concretamente per gestire il codice AI in un team di sviluppo.
Separare le PR generate dall'AI
Il primo passo è banale ma spesso ignorato: rendere visibile quale codice è stato generato dall'AI e quale no. Non per stigmatizzarlo, ma per applicare livelli di attenzione diversi.
In pratica, questo significa taggare le pull request generate da agenti AI, usare branch naming conventions specifiche, o configurare il proprio sistema di CI/CD per aggiungere label automatiche. Se usi GitHub, una GitHub Action che rileva commit da agenti AI e aggiunge un tag è questione di poche righe di configurazione.
Perché è importante? Perché il cervello di un reviewer funziona diversamente quando sa che il codice è stato scritto da un collega rispetto a quando sa che è stato generato automaticamente. Nel primo caso, tende a dare per scontate certe cose (il collega conosce il progetto, ha un motivo per le sue scelte). Nel secondo caso, sa che deve verificare assunzioni che normalmente non metterebbe in discussione.
Automated checks come primo filtro
Qui entra in gioco l'approccio di Google. Prima che un reviewer umano guardi il codice, una serie di controlli automatici deve passare.
Non parlo solo dei classici linter e formatter. Quelli li dovresti avere comunque. Parlo di controlli specifici per il codice AI.
Analisi di complessità ciclomatica: il codice AI tende a creare funzioni troppo lunghe o con troppi branch. Un threshold automatico che blocca le PR con funzioni sopra una certa complessità è un filtro efficace.
Controllo delle dipendenze: l'AI a volte importa librerie non necessarie o usa versioni obsolete di pacchetti. Un check che confronta le nuove dipendenze con quelle approvate dal team risparmia problemi futuri.
Verifica dei pattern di sicurezza: SAST (Static Application Security Testing) tools configurati per cercare i pattern specifici che l'AI tende a sbagliare. Input non sanitizzati, query SQL costruite con concatenazione di stringhe, secret hardcodati. L'AI sa che non dovrebbe farlo, ma a volte lo fa comunque.
Test di copertura minima: ogni PR generata dall'AI deve includere test. Se l'AI non li ha scritti, la PR non passa. Questo è non negoziabile.
La review umana focalizzata
Dopo il filtro automatico, serve la review umana. Ma una review diversa da quella tradizionale.
Quando revisioni codice scritto da un collega, ti concentri sulla logica di business, sulla leggibilità, su eventuali edge case. Quando revisioni codice AI, devi aggiungere un layer: la verifica delle assunzioni.
L'AI fa assunzioni su come funziona il tuo sistema. A volte sono corrette perché ha accesso al codebase. A volte sono sbagliate perché non ha accesso al contesto non scritto: le decisioni architetturali prese in una call, i vincoli di performance scoperti in produzione, le convenzioni non documentate.
Un buon checklist per la review di codice AI include queste domande. Si integra correttamente con il resto del sistema, o è una soluzione isolata? Gestisce gli errori in modo coerente con il resto del progetto? Le scelte architetturali sono allineate con la direzione in cui il team vuole andare? C'è duplicazione di logica che già esiste altrove nel codebase?
Quest'ultimo punto è particolarmente critico. L'AI non sempre sa che una funzione simile esiste già in un altro modulo. Può creare duplicati che divergeranno nel tempo, causando inconsistenze.
Ownership e responsabilità
Questo è il punto su cui molti team inciampano. Chi è responsabile del codice generato dall'AI?
La risposta dovrebbe essere chiara: chi ha richiesto la generazione e chi ha approvato la PR. L'AI è uno strumento. Se uso un compilatore e il codice compilato ha un bug, la responsabilità è mia, non del compilatore.
In termini pratici, questo significa che chi usa agenti AI per generare codice deve essere in grado di comprendere e difendere quel codice. Se un developer fa merge di una PR generata dall'AI e non è in grado di spiegare cosa fa ogni funzione, c'è un problema di processo, non di tecnologia.
Alcuni team stanno introducendo una regola semplice: se hai usato l'AI per scrivere il codice, devi essere tu a presentarlo durante la review, spiegando le scelte e rispondendo alle domande come se l'avessi scritto tu. Questo crea un incentivo naturale a leggere e capire il codice prima di proporre il merge.
Gli errori più comuni nei team che usano AI per il coding
Dopo aver lavorato con diversi team su questo tema (è una parte significativa di quello che facciamo in Bajara con i nostri clienti), ci sono pattern di errore ricorrenti.
Il primo è quello che chiamo "merge e prega". Il team genera codice con l'AI, i test passano, si fa merge. Nessuno legge veramente il codice. Funziona per un po', poi si accumula debito tecnico a velocità impressionante.
Il secondo è la review superficiale. Il reviewer guarda il codice AI per trenta secondi, vede che è ben formattato, i nomi delle variabili hanno senso, e approva. Il problema è che il codice AI è quasi sempre ben formattato e con nomi sensati. Queste non sono metriche utili per valutarne la qualità.
Il terzo è l'assenza di standard specifici per il codice AI. Si applicano le stesse regole di review del codice umano, che non coprono i problemi specifici della generazione automatica.
Il quarto, e forse il più pericoloso, è la perdita progressiva di competenza del team. Se gli sviluppatori smettono di scrivere certi tipi di codice perché "lo fa l'AI", col tempo perdono la capacità di revisionarlo efficacemente. È un circolo vizioso: meno scrivi, meno capisci, meno revisioni, più problemi passano inosservati.
Un framework pratico in cinque punti
Per chi vuole partire domani con un processo che funziona, ecco cosa consiglio.
Uno: definire una policy chiara sull'uso dell'AI nel team. Non per limitarlo, ma per renderlo trasparente. Quali task sono adatti alla generazione AI? Quali richiedono scrittura umana? Come si tracciano le PR generate dall'AI?
Due: configurare una pipeline di CI specifica per il codice AI. I controlli automatici che ho descritto sopra non sono opzionali. Sono il primo filtro e il più economico. Investire un paio di giorni per configurarli bene ne risparmia decine nel lungo periodo.
Tre: formare i reviewer. La review del codice AI è una competenza specifica che va sviluppata. I reviewer devono sapere cosa cercare, quali sono i pattern problematici tipici, e avere checklist dedicate.
Quattro: mantenere la competenza di scrittura nel team. Anche se l'AI genera l'80% del codice, gli sviluppatori devono continuare a scrivere codice manualmente, specialmente nelle aree critiche del sistema. La competenza di lettura dipende dalla competenza di scrittura.
Cinque: misurare e iterare. Tenere traccia dei bug che passano la review, classificarli per origine (codice umano vs codice AI), e usare questi dati per migliorare il processo. Senza metriche, si va a sensazione. E la sensazione, quando si parla di qualità del codice, è un indicatore inaffidabile.
Il futuro delle review: AI che controlla AI?
La mossa di Google con le Automated Reviews in Conductor apre una domanda interessante: ha senso usare l'AI per controllare il codice generato dall'AI?
La risposta breve è: sì, ma come complemento, non come sostituto della review umana.
L'AI è brava a trovare pattern. Se addestri un modello a riconoscere i difetti tipici del codice generato, può fare un ottimo lavoro come primo filtro. Ma ci sono categorie di problemi che richiedono comprensione del contesto di business, della storia del progetto, delle intenzioni del team, e queste restano fuori dalla portata dell'automazione attuale.
Il modello che probabilmente vedremo affermarsi nei prossimi anni è a tre livelli. Primo livello: check automatici tradizionali (linting, SAST, test). Secondo livello: review AI che verifica coerenza architetturale, duplicazioni, pattern problematici. Terzo livello: review umana focalizzata sugli aspetti di business, sicurezza e architettura che richiedono giudizio.
Questo modello riduce il carico sui reviewer umani senza eliminare il loro contributo. E soprattutto, scala. Perché il volume di codice generato dall'AI crescerà, e i team devono prepararsi a gestirlo.
Cosa significa tutto questo per i team di sviluppo
Il messaggio di fondo non è "non usate l'AI per scrivere codice". Sarebbe assurdo. Gli strumenti di coding AI sono qui per restare, migliorano continuamente, e offrono vantaggi reali in termini di produttività.
Il messaggio è un altro: la parte difficile non è generare il codice. È verificarlo, integrarlo, mantenerlo. E questa parte richiede processi, competenze e investimento.
Google, con le Automated Reviews, sta dicendo a tutto il settore che anche con le risorse e le competenze più avanzate del pianeta, il codice AI va controllato. Se vale per loro, vale per tutti.
Chi ignora questo aspetto oggi si troverà domani con un codebase che nessuno nel team capisce veramente. E a quel punto, la velocità guadagnata nella generazione verrà persa, con gli interessi, nel debugging e nella manutenzione.
La buona notizia è che costruire un processo di review efficace non richiede mesi di lavoro. Richiede consapevolezza del problema, qualche giorno di configurazione degli strumenti giusti, e la disciplina di seguire il processo anche quando la tentazione di fare merge veloce è forte. Se poi avete bisogno di supporto nel definire questi processi, è esattamente il tipo di consulenza che offriamo su bajara.it.
Il codice scritto dall'AI non è né buono né cattivo. È codice che va trattato per quello che è: output di uno strumento potente ma privo di giudizio. Il giudizio resta responsabilità nostra.