Guida dello Sviluppatore alla Revisione del Codice Generato dall'AI

La code review è sempre stata incentrata sul cogliere gli errori prima che arrivino in produzione. Ma quando il codice è stato scritto da un assistente AI piuttosto che da un collega umano, le dinamiche della revisione cambiano radicalmente. Gli errori che l'AI commette sono diversi da quelli che commette un umano, e le cose che devi controllare non sono le stesse che controlleresti in una revisione tra pari.

Questa guida copre ciò che i team esperti hanno imparato sulla revisione del codice generato dall'AI. È organizzata per categorie di problemi che i modelli AI producono costantemente, così puoi eseguire una checklist sistematica invece di affidarti all'intuizione sviluppata per il codice scritto da umani.

Perché il codice generato dall'AI ha bisogno di criteri di revisione diversi

Gli sviluppatori umani commettono errori che si raggruppano attorno a stanchezza, distrazione e lacune di conoscenza — uno sviluppatore stanco perde un caso limite, uno distratto dimentica di gestire un errore, uno junior usa un anti-pattern perché non conosce alternative migliori. I modelli AI commettono errori che si raggruppano attorno ad assi completamente diversi: allucinazione, cecità contestuale e incoerenza stilistica.

Un umano che scrive una funzione che non gestisce input null probabilmente sa come si fa e si è solo dimenticato. Un'AI che scrive la stessa funzione non sa realmente se null sia possibile nel tuo codebase, a meno che tu non glielo abbia detto esplicitamente. Questa distinzione è importante perché la soluzione è diversa: un umano ha bisogno di un promemoria, ma l'AI ha bisogno di un vincolo codificato nel prompt o intercettato in revisione.

Comprendere questa differenza è il fondamento di una revisione efficace del codice AI. Non stai verificando se lo sviluppatore è stato attento. Stai verificando se l'AI aveva abbastanza contesto per produrre codice corretto e se il suo output corrisponde alle convenzioni implicite del tuo codebase che non poteva vedere.

Checklist punto 1: API e import allucinati

Il problema singolo più comune nel codice generato dall'AI è l'uso di librerie, funzioni o API che non esistono. I modelli AI sono addestrati a produrre codice plausibile e genereranno con sicurezza import per pacchetti mai pubblicati e chiameranno metodi mai esistiti. Questo non è malevolo — è il modello che interpola tra pacchetti reali visti durante l'addestramento e inventa un ponte che sembra ragionevole.

// Codice generato dall'AI che sembra plausibile ma importa una funzione inesistente
import { renderAsync } from 'react-dom'; // renderAsync non esiste
import { optimize } from 'lodash/fp/string'; // Questo path non esiste in lodash

// Quello che serve realmente
import { renderToString } from 'react-dom/server';

La soluzione è semplice ma importante: verifica ogni import e ogni chiamata API contro la documentazione reale. Non dare per scontato che, poiché il codice compila, le API siano corrette — alcune funzioni allucinate hanno firme dall'aspetto ragionevole che superano il controllo TypeScript ma falliscono a runtime. La revisione dovrebbe includere un rapido controllo di sanità su qualsiasi import che non riconosci.

Checklist punto 2: Gestione errori mancante

I modelli AI tendono a generare il percorso felice. Sono notevolmente bravi a scrivere la logica principale di una funzione — il ciclo, la trasformazione, il valore di ritorno — e notevolmente scarsi nel gestire cosa succede quando le cose vanno male. Le richieste di rete mancano di blocchi catch. Le operazioni sui file mancano di gestione errori. Le funzioni asincrone mancano di gestori di rejection.

Non è perché l'AI non sappia scrivere gestione errori. Se glielo chiedi esplicitamente, l'AI produrrà una logica try-catch approfondita. Il problema è che il comportamento predefinito del modello è scrivere la versione funzionante più semplice, e la gestione errori non fa parte di quel default. Ogni revisione di codice generato dall'AI dovrebbe includere un passaggio che guarda solo ai percorsi di errore.

• Ogni funzione asincrona dovrebbe avere un catch o un rejection handler.
• Ogni chiamata API esterna dovrebbe gestire errori di rete, timeout e formati di risposta inaspettati.
• Ogni trasformazione di dati dovrebbe gestire null, undefined e tipi inaspettati.
• Ogni operazione su file o database dovrebbe gestire errori di permessi e risorse mancanti.

Una tecnica utile è eseguire un semplice test: rimuovi i blocchi try-catch dal codice generato dall'AI e verifica se la logica rimanente ha ancora senso. Se è così, probabilmente l'AI non ha pensato profondamente alla gestione errori. Se la logica dipende dalla gestione errori per funzionare, l'AI l'ha integrata correttamente.

Checklist punto 3: Disallineamenti di stile e convenzioni

Ogni codebase ha convenzioni di stile non scritte. Il team usa return anticipati, non if annidati. I messaggi di errore seguono un formato specifico. I nomi delle variabili usano un pattern particolare. I modelli AI addestrati su milioni di repository pubblici genereranno codice che riflette la media statistica di tutti quei repository, non le convenzioni specifiche del tuo codebase.

Il risultato è codice che funziona ma sembra estraneo. Usa una convenzione di naming diversa, una struttura di moduli diversa o un pattern di gestione errori diverso dal codice circostante. Questo tipo di incoerenza si accumula rapidamente — cinque funzioni generate dall'AI scritte con cinque stili impliciti diversi creano un codebase che sembra incoerente ed è più difficile da mantenere.

La migliore mitigazione è includere esempi di stile nei tuoi prompt. Incolla una funzione rappresentativa dallo stesso modulo e dici usa questo stile. Questo dà all'AI un riferimento concreto che sovrascrive il suo default di addestramento. Durante la revisione, verifica che il codice generato potrebbe essere stato scritto dalla stessa persona che ha scritto il modulo circostante.

Checklist punto 4: Over-engineering e astrazione non necessaria

I modelli AI hanno un forte bias verso l'astrazione. Dato un problema semplice, spesso genereranno una gerarchia di classi, un'interfaccia, una factory e tre funzioni di utilità — dove una singola funzione sarebbe stata sufficiente. Questa tendenza deriva dai dati di addestramento, che sovra-rappresentano librerie open-source ben strutturate sotto-rappresentando script semplici e funzioni monouso.

I modelli AI tendono all'over-engineering per impostazione predefinita. La tua revisione dovrebbe tendere alla semplicità. Ogni astrazione introdotta dall'AI deve giustificare la sua esistenza rispetto a un'alternativa più semplice.

Durante la revisione, chiediti: questo codice ha bisogno di una classe, o basterebbe una funzione? Questa interfaccia è usata da più di un'implementazione? Estrarre questa utilità farebbe risparmiare abbastanza ripetizioni da giustificare l'indirezione? Se la risposta a una di queste è no, probabilmente l'AI ha over-ingegnerizzato, e la versione più semplice è migliore.

Checklist punto 5: Vulnerabilità di sicurezza

I modelli AI sono addestrati su codice che contiene vulnerabilità di sicurezza. Imparano pattern da quel codice, inclusi quelli vulnerabili. Mentre i modelli moderni sono migliori nell'evitare problemi ovvi come l'SQL injection, producono ancora codice con problemi di sicurezza sottili che un revisore deve cogliere.

• Controlla la presenza di segreti hardcodati, chiavi API o credenziali nel codice generato.
• Verifica che l'input utente sia validato e sanificato prima dell'uso.
• Controlla che i controlli di autenticazione e autorizzazione siano presenti sulle operazioni protette.
• Assicurati che le query SQL generate usino statement parametrizzati, non concatenazione di stringhe.
• Verifica che i path dei file non siano costruiti da input non fidati senza sanificazione.

Un passaggio di revisione focalizzato sulla sicurezza è negoziabile per il codice generato dall'AI che gestisce dati sensibili o input utente. L'AI non sa quali parti del tuo sistema sono critiche per la sicurezza a meno che tu non glielo dica. In caso di dubbio, esegui uno strumento di analisi statica sul codice generato prima di unire.

Checklist punto 6: Coerenza con l'architettura esistente

I modelli AI vedono ogni richiesta in isolamento. Non sanno che il tuo team ha concordato il trimestre scorso di usare React Query per tutto il recupero dati, che l'API restituisce sempre chiavi in camelCase o che il progetto usa un pattern specifico di gestione dello stato. Il codice che generano sarà internamente coerente ma potrebbe violare decisioni architetturali che non sono visibili nel file corrente.

È qui che il revisore umano aggiunge più valore. Tu conosci le decisioni documentate nei tuoi ADR, i pattern emersi dalle discussioni di team e i vincoli di design che non sono catturati in nessun singolo file. Revisiona il codice generato dall'AI rispetto a questi vincoli invisibili, non solo per correttezza e stile.

Costruire un processo di revisione sostenibile

Mentre l'AI genera sempre più del tuo codebase, il processo di revisione deve scalare. Un team di quattro persone che revisiona ogni riga generata dall'AI manualmente si esaurirà. L'approccio sostenibile combina controlli automatizzati con revisione umana mirata.

I controlli automatizzati dovrebbero cogliere import allucinati, violazioni di stile, gestione errori mancante e problemi di sicurezza comuni prima che un umano veda mai il codice. Questo riduce la revisione specifica dell'AI a un insieme più piccolo di preoccupazioni: coerenza architetturale, decisioni di design e i problemi sottili che i linter non possono rilevare.

L'obiettivo non è eliminare la revisione umana del codice generato dall'AI. È renderla il più efficiente possibile filtrando i problemi che gli strumenti possono cogliere automaticamente e riservando l'attenzione umana per i giudizi che solo gli umani possono fare. Con il processo giusto, revisionare il codice generato dall'AI diventa più veloce e più affidabile che revisionare il codice scritto da umani — perché gli errori dell'AI sono più prevedibili.