Codice generato dall'AI: chi lo revisiona davvero

Il codice generato dall'AI oggi rappresenta circa metà di quello che finisce nei repository delle aziende che hanno adottato gli assistenti di programmazione. Il problema non è la quantità: è che la verifica non è cresciuta alla stessa velocità. Secondo il report OSSRA 2026 di Black Duck, su 947 codebase commerciali analizzate l'85% delle organizzazioni usa assistenti AI, ma solo il 54% valuta quel codice per i rischi di licenza e proprietà intellettuale. Qualcuno scrive molto più di prima. Nessuno legge molto più di prima.

Per un'azienda che fa sviluppare il proprio sito, il gestionale o un'automazione, la domanda è contrattuale e non filosofica: chi revisiona il codice che l'AI ha scritto, con quale metodo, e cosa succede quando sbaglia.

Il collo di bottiglia si è spostato, non è sparito

Gli assistenti AI non hanno eliminato il lavoro: lo hanno spinto a valle. I dati di Faros AI su 22.000 sviluppatori mostrano che la revisione mediana oggi richiede cinque volte il tempo di prima, su richieste di modifica una volta e mezza più grandi. Un sondaggio Sonar di gennaio 2026 registra che il 38% degli sviluppatori considera la revisione del codice generato dall'AI più faticosa di quella di un collega umano.

Infatti, a un sondaggio su 440 ingegneri durante una conferenza DORA dell'ottobre 2026, il 50% ha indicato "revisionare le modifiche" come attrito principale del proprio ciclo di sviluppo. Scrivere codice si è fermato al 3%: il ribaltamento completo di come funzionava questo mestiere cinque anni fa.

Il programma di ricerca DORA di Google Cloud chiama questo fenomeno verification tax: la tassa di verifica è una delle tre cause del calo temporaneo di produttività che quasi tutti i team registrano nei primi mesi di adozione. Lo stesso studio, su quasi 5.000 professionisti, trova che il 90% usa l'AI al lavoro e oltre l'80% si sente più produttivo — ma il 30% dichiara poca o nessuna fiducia nel codice che ne esce. Usano uno strumento di cui non si fidano, più velocemente di prima.

Perché il codice generato dall'AI è difficile da revisionare

La ragione è precisa e vale la pena capirla. Il GenAI Code Security Report 2026 di Veracode, che ha messo alla prova oltre 100 modelli su 80 compiti di programmazione, la riassume in una frase: la sintassi è risolta, la sicurezza no. I modelli producono codice sintatticamente corretto quasi sempre. Il tasso medio di superamento dei controlli di sicurezza, però, resta al 56% — e il modello migliore fallisce comunque quasi un compito su tre.

Questo cambia la natura della revisione. Prima, un difetto si annunciava: il codice non compilava, il test rompeva, qualcosa era visibilmente storto. L'analisi condotta da Apiiro su aziende Fortune 50 lo quantifica: con l'assistenza AI gli errori di sintassi sono calati del 76%, mentre i percorsi di escalation dei privilegi sono cresciuti del 322% e i difetti di architettura del 153%. Il rumore che segnalava i problemi è scomparso. I problemi no.

Nello stesso periodo quei team hanno prodotto commit a un ritmo tre o quattro volte superiore, con segnalazioni di sicurezza mensili passate da circa mille a oltre diecimila. Più volume, difetti più silenziosi, stessi revisori.

Dove il codice generato dall'AI sbaglia di più

I numeri di Veracode non sono uniformi, e questa è l'informazione utile. Sull'iniezione SQL i modelli passano i controlli nell'83% dei casi; sugli algoritmi crittografici nell'87%. Ma sul cross-site scripting il tasso di superamento crolla al 15%, e sull'iniezione nei log al 12%. Tradotto: l'AI ha imparato bene le lezioni che la letteratura tecnica ha ripetuto per vent'anni, e male tutto il resto.

Si aggiunge un rischio di fornitura che non esisteva prima. Uno studio presentato a USENIX Security su 576.000 campioni di codice generato dall'AI ha rilevato che circa il 20% delle dipendenze suggerite punta a pacchetti che non esistono. Il 43% di quei nomi inventati si ripresenta in modo coerente a fronte di richieste simili — abbastanza perché un attaccante registri il nome e aspetti. È la stessa categoria di problema che rende l'inventario delle dipendenze una pratica di sopravvivenza e non un esercizio burocratico.

Tuttavia, il dato più scomodo è un altro: una ricerca Snyk riporta che quasi l'80% degli sviluppatori ritiene l'AI più sicura di un collega umano, in contraddizione con tutti gli studi sistematici. E in uno studio controllato chi usava un assistente ha consegnato codice meno sicuro, dichiarandosi però più fiducioso del risultato.

Il divario di governance: cosa si controlla davvero

Qui torniamo ai numeri OSSRA. L'adozione è all'85%, i controlli no: il 76% delle organizzazioni verifica il codice generato dall'AI sul piano della sicurezza, il 56% sulla qualità, il 54% su licenze e proprietà intellettuale. Solo il 24% fa tutte e quattro le verifiche. E il 76% delle aziende che hanno vietato questi strumenti ammette che gli sviluppatori li usano comunque.

C'è poi un effetto collaterale specifico: il 17% dei componenti open source entra nelle codebase fuori dai gestori di pacchetti — frammenti copiati, inclusioni dirette, generazione AI — e resta quindi invisibile agli strumenti che leggono i file di manifesto. Non è che il controllo fallisce: non guarda nel posto giusto.

Come si organizza la revisione, in concreto

Non serve una policy di quaranta pagine. Servono quattro decisioni scritte una volta e applicate sempre.

• Zone rosse e zone verdi. Autenticazione, autorizzazioni, crittografia, validazione degli input, pagamenti: revisione umana obbligatoria, sempre, riga per riga. Codice ripetitivo, test, rinominazioni e rifattorizzazioni: controllo automatico e via. La distinzione vale più di qualsiasi divieto generico.
• Controlli automatici su ogni modifica. Analisi statica, scansione delle dipendenze e ricerca di credenziali esposte, eseguiti prima della revisione umana, non dopo. Servono a liberare l'attenzione delle persone per i problemi che solo una persona vede: la logica sbagliata, il requisito frainteso.
• Modifiche piccole, per forza. Se il collo di bottiglia è la lettura, una richiesta di modifica da duemila righe non è produttività: è una revisione che non avverrà. Un limite dichiarato sulla dimensione è la contromisura più economica che esista.
• Provenienza tracciata. Sapere quali parti sono state generate e con quale strumento cambia il modo in cui le si legge sei mesi dopo, quando esce una vulnerabilità e bisogna capire dove si è propagata.

Una nota pratica che emerge da uno studio sull'iterazione nella generazione di codice: chiedere al modello di "migliorare" ripetutamente lo stesso frammento tende a peggiorarne la sicurezza, non a migliorarla. Ogni giro ottimizza la funzionalità e perde pezzi delle protezioni precedenti. Il quinto rifinimento non è una revisione: è una nuova stesura da verificare da zero.

Infine, attenzione a delegare la revisione a un secondo strumento AI. Uno studio accademico sulla funzione di revisione automatica di Copilot ha trovato che manca regolarmente difetti critici — iniezione SQL, cross-site scripting, deserializzazione insicura — segnalando invece problemi di stile di bassa gravità. Un revisore che approva trenta volte di fila smette di leggere la trentunesima, e questo vale anche quando il revisore è una macchina: è esattamente il pregiudizio di automazione applicato al codice.

Le tre domande da fare a chi sviluppa per te

Se stai comprando software — un sito, un'integrazione, un'automazione — non ti serve sapere quale modello usa il fornitore. Ti servono tre risposte.

Primo: quali parti del progetto sono soggette a revisione umana obbligatoria, e chi firma. Secondo: quali controlli automatici girano su ogni modifica, e cosa succede quando uno fallisce. Terzo: come si risale, dopo la consegna, a chi o cosa ha scritto una certa parte. Un fornitore che lavora bene risponde in tre minuti; uno che improvvisa parla di velocità.

Il codice generato dall'AI è una leva reale e nessuno sensato propone di rinunciarci. Ma la leva moltiplica quello che c'è a monte: se il processo di verifica era debole, ora è debole su un volume dieci volte maggiore. Studiollice progetta automazioni e agenti AI con le zone rosse definite prima di scrivere la prima riga — perché la parte difficile non è far produrre codice a un modello, è decidere cosa non gli si lascia decidere.