// TOM'S HARDWARE ITALIA — INTELLIGENZA ARTIFICIALE
Nessuno controlla più il codice scritto dall'AI. Sarà un problema enorme
Il 41% del codice in produzione oggi è generato dall'AI. La maggior parte di quel codice arriva in produzione senza che nessuno lo abbia letto davvero, riga per riga. È una descrizione di come stanno cambiando le abitudini professionali degli sviluppatori, in silenzio, sotto la pressione della velocità e del risultato immediato.
Il problema, per chi gestisce team di sviluppo o decide sull'adozione degli strumenti AI, è pratico: il codice AI non revisionato è una promessa differita di incidenti in produzione, debito tecnico accumulato e vulnerabilità di sicurezza che nessuno sa dove cercare perché nessuno ha mai letto il codice abbastanza a fondo da capire dove potrebbero nascondersi.
Il pattern è prevedibile, e lo è perché risponde a dinamiche comportamentali molto normali. Uno sviluppatore adotta Cursor o GitHub Copilot. Nelle prime settimane controlla tutto, riga per riga, perché non si fida dello strumento. Il codice generato è spesso buono, a volte ottimo. I test passano. La feature funziona. Il cervello registra un'associazione: AI produce = output affidabile.
Dopo qualche settimana, la revisione diventa più rapida. Si guarda la struttura generale, si verifica che la logica sia coerente con quello che si aspettava, si eseguono i test automatici. Se i test passano, si fa merge. Dopo qualche mese, per molti sviluppatori il processo è diventato: chiedo all'AI, guardo il diff, faccio merge se i test sono verdi.
È adattamento razionale a uno strumento che produce risultati accettabili nella grande maggioranza dei casi, non negligenza. Il problema è che "grande maggioranza" non significa "tutti". E i casi in cui il codice AI produce qualcosa di funzionalmente corretto ma strutturalmente sbagliato (un pattern di autenticazione con una race condition, una gestione di eccezioni che silenzia errori critici, una query che sembra ottimizzata ma non lo è sotto carico) non si manifestano nei test unitari. Si manifestano alle due di notte quando un picco di traffico scatena la condizione che nessuno aveva immaginato.
I dati lo confermano: gli incidenti per pull request sono aumentati del 23,5% negli ultimi dodici mesi nei team che hanno adottato strumenti AI per la generazione di codice. La ricerca di QASource e il report di Help Net Security del giugno 2026 documentano entrambi un pattern che i senior engineer descrivono già come "agent debt": un accumulo di logica applicativa che passa la review superficiale ma che nessuno ha davvero capito a fondo prima di spedirla in produzione.
C'è un malinteso comune che fa danni: trattare il codice generato dall'AI come si tratterebbe il codice di un junior developer. L'analogia è intuitiva ma fuorviante in modo pericoloso.
Il codice di un junior developer ha una caratteristica che il codice AI non ha: il junior può spiegare le sue scelte. Può dire "ho usato questo pattern perché ho letto questa documentazione", oppure "non sapevo come gestire questo edge case, ho fatto così". Quella tracciabilità del ragionamento è preziosa nella code review: permette al senior di capire non solo cosa c'è scritto, ma perché, e quindi di identificare i punti di rischio.
Il modello AI non ha ragionamento tracciabile. Produce output statisticamente plausibili, ottimizzati per sembrare corretti a una lettura superficiale. Un articolo di Tom's Hardware di novembre 2025 documentava già come la copia di codice vulnerabile generato da AI colpisse praticamente tutti, dagli sviluppatori individuali alle grandi organizzazioni. Il 76% degli sviluppatori che usa strumenti AI di coding ha dichiarato di aver generato codice che non capiva pienamente, almeno in alcuni casi. Quella percentuale è la condizione normale dell'uso degli strumenti AI per la generazione di codice, non un'eccezione.
La sicurezza non è l'unico problema. C'è il debito tecnico, che si accumula in modo particolarmente insidioso con il codice AI: le strutture dati scelte, i pattern architetturali, le dipendenze introdotte possono essere tecnicamente