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.
L’AI produce codice accettabile nove volte su dieci. La decima è quella che conta.
Il meccanismo dell’abitudine: come si smette di controllare
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.
Il codice che nessuno ha capito è codice che nessuno saprà correggere.
Il codice AI è più insidioso di quello di un junior developer
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 funzionanti ma difficili da mantenere, estendere o testare in futuro. L’engineering di lungo periodo, ovvero la capacità di un sistema di evolvere senza esplodere, dipende dalla qualità delle decisioni architetturali che vengono prese ogni giorno. Quelle decisioni, demandate all’AI senza supervisione, diventano scommesse.
Il debito tecnico generato dall’AI è silenzioso finché non smette di esserlo.
Smettere di fare code review è un errore che si paga
La posizione netta è questa: eliminare la supervisione umana sul codice generato dall’AI è una riduzione deliberata delle garanzie di sicurezza ed efficienza del software prodotto, giustificata da un’estrapolazione ottimistica di dati aggregati su un territorio dove i casi critici si manifestano negli outlier, non nella media.
I modelli AI attuali, tutti senza eccezione, non hanno una comprensione del contesto applicativo, dei requisiti di sicurezza specifici del dominio, delle implicazioni architetturali a lungo termine. Sono strumenti di accelerazione potenti per sviluppatori competenti che li usano con giudizio. Non sono sviluppatori autonomi a cui si può delegare la responsabilità dell’output.
Le aziende che hanno integrato la code review AI-assisted nel loro processo, come Cursor con il suo sistema Auto-review, hanno capito che l’AI deve verificare altro AI, non sostituire l’occhio umano: sono strati aggiuntivi di controllo automatico, non alternative alla supervisione umana. Il team che ha eliminato la code review ha spostato il costo nel tempo, dalla fase di sviluppo alla fase di incident response, con un moltiplicatore che raramente è inferiore a dieci.
Chi gestisce team di sviluppo ha la responsabilità di chiarire questa distinzione nelle proprie organizzazioni, esplicitamente e con dati alla mano. L’abitudine di non revisionare il codice AI non è nata da una decisione consapevole: si è formata per inerzia, iterazione dopo iterazione, in assenza di un incidente abbastanza visibile da invertire la tendenza. Quell’incidente, per molte organizzazioni, è solo questione di tempo.
La questione è quando arriverà il problema, e quanto costerà.
Dagli agenti AI personalizzati alla formazione.
C’è molto che possiamo fare insieme.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Sara Romano
Source link
