La cascata sistemica del coding AI: vulnerabilità, paradosso di produttività, collasso della carriera junior

Quando misuri l'AI coding solo sull'output del singolo sviluppatore in una giornata di lavoro, hai una storia. Quando lo misuri sul sistema intero a sei mesi di distanza, ne hai un'altra completamente diversa. Nei dodici mesi tra luglio 2025 e febbraio 2026 sono stati pubblicati tre studi indipendenti che, messi in sequenza, definiscono il perimetro empirico di quello che chiamo la cascata sistemica del coding AI: la sicurezza del codice generato, il rallentamento misurabile dei senior che lo usano, e l'erosione cognitiva dei junior che imparano a programmare con l'AI a fianco. Tutti e tre sono studi RCT (randomized controlled trial), il gold standard metodologico delle scienze biomediche, e tutti e tre puntano nella stessa direzione: il sistema produce un saldo negativo sul lungo periodo che la metrica di velocità del singolo developer non cattura.

Nel primo articolo di questa serie ho introdotto il concetto di debito di comprensione e ho mostrato i numeri di GitClear su 211 milioni di righe di codice. In questo articolo passo dalla diagnosi alla cascata: cosa il debito di comprensione produce nei tre vettori che, sommati, definiscono la salute di un'organizzazione di sviluppo. Il problema non è uno solo. Sono tre, e si rinforzano a vicenda.

Quanto è insicuro davvero il codice che l'AI scrive in produzione?

Il numero più affidabile su questo aspetto viene dal Veracode 2025 GenAI Code Security Report, pubblicato a luglio 2025 e aggiornato a ottobre dello stesso anno con i risultati su GPT-5. La metodologia è la più robusta disponibile: 80 task di coding curati, oltre 100 LLM testati su Java, JavaScript, Python e C#, output passato attraverso strumenti SAST production-grade per verificare le stesse classi di vulnerabilità che vengono cercate nel codice scritto da umani. Il risultato è netto: il 45% dei sample di codice generato fallisce i controlli di sicurezza e introduce vulnerabilità OWASP Top 10.

Il dato aggregato, già pesante, diventa drammatico quando si guarda alle classi specifiche di vulnerabilità. Cross-Site Scripting (CWE-80): l'86% del codice generato per task in cui XSS è applicabile non è protetto. Log injection (CWE-117): 88%. Sono due vulnerabilità che richiedono comprensione del contesto applicativo completo (chi sanitizza l'input, dove avviene il rendering, quale layer di logging è in mezzo), e gli LLM non possiedono questo contesto. Pattern matching su training data non costruisce difesa contro classi di attacco contesto-dipendenti.

Per linguaggio, Java è il riskier in assoluto: tasso di fallimento sopra il 70%, con appena il 28,5% di output sicuro. Python, C# e JavaScript stanno tra il 38% e il 45% di tasso di fallimento. La spiegazione è interpretativa ma plausibile: Java ha decenni di codice insicuro nei training set, da Stack Overflow ai repository open source di vecchie versioni di framework. Il modello impara la frequenza, non la sicurezza.

Il dato controintuitivo del report è forse il più importante per chi sta valutando se aspettare un modello migliore: i modelli più grandi e più recenti non sono significativamente più sicuri di quelli più piccoli o più vecchi. GPT-5 in modalità reasoning ha portato il tasso di security pass al 72%, il record assoluto, ma il GPT-5-chat non-reasoning si ferma al 52%. La soglia del 45% di vulnerabilità è rimasta sostanzialmente stabile attraverso le generazioni GPT-4, GPT-5, Claude e Gemini. Veracode formula la conclusione in modo asciutto: questo è un problema sistemico, non un problema di scaling del modello. Aspettare il prossimo training run non risolve l'insicurezza.

Tradotto operativamente per chi gestisce un'organizzazione che processa dati finanziari, dati sanitari o sistemi di pagamento: se il tuo flusso di sviluppo accetta codice AI-generated nei moduli di sicurezza critica senza un layer di review specializzato, "l'AI lo ha scritto" non è una difesa. È un'ammissione. La superficie d'attacco generata da un agente probabilistico va trattata come input non fidato per default, e revisionata con la stessa disciplina con cui revisioni il codice che arriva da una pull request esterna.

Se la tua organizzazione sta integrando AI coding in pipeline che toccano dati regolamentati o sistemi di pagamento e non hai ancora formalizzato un processo di audit specifico per il codice AI-generated, nel mio hub dedicato all'AI per aziende sul lato sicurezza trovo i pattern di audit, threat modeling e regression testing che applico nelle analisi offensive su pipeline AI in produzione, con una metodologia che ho strutturato dopo aver visto la stessa classe di errori ripetersi in audit consecutivi.

Nella mia pratica offensiva, lavorando in sandbox di red team su pipeline LLM e su codice generato da agenti, vedo regolarmente comparire le stesse tipologie di errore che Veracode misura nell'aggregato: chiavi API hardcoded come fallback "di sviluppo" rimaste in produzione, concatenazione SQL invece di prepared statement perché lo stub generato dall'agente ha rispecchiato il pattern dominante nel training set, eval su input non sanificato per "convenienza implementativa", e log che riemettono input utente in formato strutturato senza escape. È in questo tipo di analisi che ho iniziato a documentare casi come la supply chain di pipeline LangGraph compromettibile via pickle deserialization, dove una scelta apparentemente innocua del modello (usare msgpack con fallback a pickle) trasforma una pipeline AI in una superficie d'attacco RCE quando l'attaccante controlla un nodo della cache.

Cosa significa che i senior rallentano del 19% con AI?

Il secondo studio è il METR 2025 Open Source Developer Productivity Study, pubblicato a luglio 2025 e disponibile anche come paper su arXiv (2507.09089). Anche questo è un RCT: 16 sviluppatori open source con un'esperienza media di cinque anni e 1.500 commit sui rispettivi progetti, hanno completato 246 task in modalità randomizzata, alcuni con accesso ad AI tools (Cursor Pro, Claude 3.5/3.7 Sonnet) e altri senza. La metrica era il tempo di completamento auto-riportato, registrato con screen recording per validazione.

Prima di iniziare i task, gli stessi developer prevedevano che l'AI avrebbe ridotto il tempo di completamento del 24%. Dopo aver completato i task, la stima soggettiva era una riduzione del 20%. Il dato misurato è andato nella direzione opposta: l'uso di AI ha aumentato il tempo di completamento del 19%, con un intervallo di confidenza clusterizzato per developer di (1,6%, 39%). Su esperti che lavoravano su codebase a loro familiari, l'AI ha rallentato di un quinto. Il gap fra percezione e realtà è di 39 punti percentuali. Non è un dettaglio metodologico: è un'asimmetria sistemica fra il modo in cui chi usa l'AI vive l'interazione e l'effetto reale sull'output che produce.

Le ipotesi che gli autori articolano per spiegare il rallentamento sono cinque, e nessuna è dominante. La prima è che developer ottimisti sull'AI tendono a usarla anche su task in cui sarebbero stati più veloci da soli. La seconda è che molto del tempo viene speso a ripulire il codice generato. La terza è che developer molto esperti sui propri repository sono già rapidi sui task ordinari, e il margine per l'AI di accelerare è strutturalmente piccolo. La quarta è che le codebase grandi hanno regole implicite che il modello non possiede. La quinta è il context-switching aggiuntivo introdotto dal prompt loop. Probabilmente sono tutte vere insieme, in proporzioni diverse a seconda del developer e del task.

Il dato di follow-up di febbraio 2026, pubblicato da METR come aggiornamento, conferma la direzione ma con maggiore variabilità: per i developer originari il rallentamento si attesta intorno al 18% (intervallo -38%, +9%), per i nuovi developer reclutati nel 2026 il rallentamento è del 4% (intervallo -15%, +9%). Il segno resta negativo o neutro su esperti che lavorano in codebase familiari.

Tradotto in termini di gestione di un team: se i tuoi senior dichiarano in retrospettiva che l'AI li sta rendendo più veloci, e contemporaneamente vedi che i loro tempi di delivery non migliorano e i postmortem peggiorano, non è una contraddizione. È esattamente quello che lo studio METR ha documentato. La percezione di velocità è un dato reale di vissuto, ma non è correlata con la velocità misurata. E il gap si ferma quando inizi a misurare con dati e non con sensazioni. Negli ultimi audit di processo che ho condotto su pipeline di sviluppo che avevano introdotto Cursor o Claude Code da almeno otto mesi, il pattern ricorrente è esattamente questo: la self-evaluation del team racconta velocità, le dashboard di delivery raccontano stagnazione o regressione.

Perché il calo del 17% di comprensione nei junior dev è il dato più allarmante?

Il terzo studio è quello che, a mio giudizio, ha la portata più strutturale dei tre. È stato pubblicato da Anthropic a febbraio 2026 con il titolo How AI assistance impacts the formation of coding skills, corrispondente al paper arXiv 2601.20245 a firma Judy Hanwen Shen e Alex Tamkin. La metodologia è didatticamente perfetta: 52 sviluppatori prevalentemente junior, almeno un anno di esperienza Python settimanale, divisi randomicamente in due gruppi. Tema: imparare Trio, una libreria di programmazione asincrona sconosciuta a tutti i partecipanti. Un gruppo riceve un assistente AI in grado di generare soluzioni complete; l'altro gruppo lavora con documentazione e ricerca web. Entrambi i gruppi completano due task di coding e poi affrontano lo stesso quiz di 14 domande su debugging, lettura del codice e comprensione concettuale del materiale appena usato.

I risultati sono asciutti: il gruppo con AI ha ottenuto un punteggio medio del 50%, il gruppo senza AI il 67%. La differenza di 17 punti percentuali equivale, nel sistema di valutazione americano usato per riportare il dato, a quasi due gradi di voto. Su materiale appena utilizzato, chi aveva delegato all'AI la generazione del codice non era in grado di rispondere a domande che chi aveva scritto il codice da solo aveva interiorizzato. Il tempo di completamento è leggermente più rapido per il gruppo AI ma sotto la soglia di significatività statistica. Lo speedup percepito non c'è. Il deficit di comprensione c'è.

Lo studio è particolarmente prezioso perché ha analizzato i pattern di interazione, non solo l'aggregato. Chi ha usato l'AI per indagine concettuale (chiedere spiegazioni, esplorare alternative, verificare la propria ipotesi) ha ottenuto punteggi sopra il 65%. Chi ha delegato all'AI la generazione del codice (passive delegation, "fammi funzionare questa cosa") è sceso sotto il 40%. La differenza non è "AI sì AI no", è "come si usa l'AI". Chi la tratta come uno strumento di apprendimento attivo non perde comprensione. Chi la tratta come una sostituzione del pensiero la perde drasticamente.

Il calo più severo è nel debugging. È un dato che merita attenzione perché il debugging è esattamente la skill che chiude il loop tra "ho scritto codice" e "ho compreso il codice". Quando il debugging non si forma, l'autore non ha modo di validare la differenza tra codice che funziona per le ragioni giuste e codice che funziona per accidente. La conseguenza non è banale: senza skill di debugging, un developer non riesce a fare review informato del codice di altri (umani o AI), non riesce a interpretare un postmortem, non riesce a costruire un mental model robusto del sistema. È la skill che rende possibile la transizione da junior a senior, e lo studio mostra che è esattamente la skill che la passive delegation all'AI compromette.

C'è un caveat metodologico che gli autori esplicitano: la valutazione è stata fatta poco dopo il task. Se il deficit di comprensione misurato a breve termine si traduca in deficit di skill formativa a lungo termine è una questione che lo studio non risolve. Anthropic stessa nota che gli effetti potrebbero essere ancora più pronunciati con prodotti agentici come Claude Code, dove la delega è strutturalmente più aggressiva. Per chi gestisce un team con junior che usano Cursor o Copilot da otto-dodici mesi senza disciplina formativa esplicita, il segnale è già abbastanza chiaro: il problema non è ipotetico, è strutturale, e il momento per intervenire è prima che il team perda l'intero anno di crescita previsto per ogni junior.

Quando metti i tre studi in sequenza, la cascata si compone in modo netto. Il codice AI-generated introduce vulnerabilità di sicurezza nel 45% dei casi, e in classi specifiche (XSS, log injection) supera l'80% di tasso di fallimento. I senior che dovrebbero catturare queste vulnerabilità rallentano del 19% quando usano AI sui loro stessi repository familiari, mentre la loro percezione racconta una velocità che non c'è. I junior che dovrebbero crescere fino a diventare i senior di domani perdono il 17% di comprensione su materiale appena usato, con il calo più pronunciato proprio sul debugging, la skill che permette la maturazione professionale. Il sistema non sta accelerando: sta squilibriando, e il saldo netto è negativo se non lo gestisci. Se la tua organizzazione ha adottato AI coding senza una strategia esplicita su questi tre vettori (audit di sicurezza specifico per codice AI-generated, misurazione effettiva e non percepita della delivery, disciplina formativa per junior che li protegga dalla passive delegation), il modulo di preventivo gratuito ti permette di descrivere lo stato attuale in due minuti e ti rispondo subito su quale dei tre vettori è il più urgente per il tuo contesto. Nei prossimi articoli passo dalla cascata diagnostica alle contromisure: come cambiare la disciplina di intent management, come trattare l'AI come dependency architettonica e non come tool di produzione, e come riposizionare la carriera senior nell'era del prompt operator.