--- title: "La cascata sistemica del coding AI: vulnerabilità, paradosso di produttività, collasso della carriera junior" description: "Veracode misura il 45% di codice AI con falle di sicurezza, i senior perdono il 19% di produttività e i junior il 17% di comprensione. La cascata si compone." canonical: "https://www.mauriziofonte.it/blog/post/ai-coding-cascata-sistemica-vulnerabilita-produttivita-junior.html" author: "Maurizio Fonte" date: "2026-04-21T12:14:22+02:00" modified: "2026-06-19T10:51:42+02:00" section: "AI Security" tags: ["AI Security", "Penetration Testing"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [AI Security](https://www.mauriziofonte.it/blog/cat/ai-code-security.html) [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) # [La cascata sistemica del coding AI: vulnerabilità, paradosso di produttività, collasso della carriera junior](https://www.mauriziofonte.it/blog/post/ai-coding-cascata-sistemica-vulnerabilita-produttivita-junior.html) Martedì 21 Aprile 2026, alle 12:14 ![La cascata sistemica del coding AI: vulnerabilità, paradosso di produttività, collasso della carriera junior](https://www.mauriziofonte.it/image/004410200-ai-coding-cascata-sistemica-vulnerabilita-produttivita-junior.jpg) 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](https://www.mauriziofonte.it/blog/post/debito-comprensione-ai-coding-codebase-decision-maker.html) 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](https://www.veracode.com/resources/analyst-reports/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](https://www.mauriziofonte.it/ai-aziende/ai-aziende-security.html) 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](https://www.mauriziofonte.it/blog/post/langgraph-pickle-rce-cve-2026-27794-supply-chain-pipeline-llm.html), 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](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-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](https://www.anthropic.com/research/AI-assistance-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](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai) 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. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Venerdì 19 Giugno 2026, alle 10:51 [« Articolo precedenteSemantic caching per applicazioni LLM: ridurre i costi del 60% senza compromettere la freschezza delle risposte21 Aprile 2026](https://www.mauriziofonte.it/blog/post/semantic-caching-applicazioni-llm-ridurre-costi-freschezza.html)[Articolo successivo »Ragionamento con tool: Alpha Evolve e Codex per far risolvere problemi formali a un LLM22 Aprile 2026](https://www.mauriziofonte.it/blog/post/reasoning-tool-use-alpha-evolve-codex-llm-problemi-formali-tutorial.html) ### Articoli correlati a La cascata sistemica del coding AI: vulnerabilità, paradosso di produttività, collasso della carriera junior - [Il debito di comprensione: cosa l'AI accumula nella tua codebase mentre sembra accelerare](https://www.mauriziofonte.it/blog/post/debito-comprensione-ai-coding-codebase-decision-maker.html) L'AI scrive codice che passa i test, sembra pulito, esce in produzione. Ma quando alle 2 del mattino il sistema cade, nessuno sa più cosa stiamo · 20 Aprile 2026 ![Il debito di comprensione: cosa l'AI accumula nella tua codebase mentre sembra accelerare](https://www.mauriziofonte.it/image/004400070-debito-comprensione-ai-coding-codebase-decision-maker.jpg) - [Il riposizionamento dell'ingegnere senior nell'era del prompt operator](https://www.mauriziofonte.it/blog/post/ingegnere-senior-prompt-operator-intent-manager-governance.html) L'ingegnere che l'AI sostituisce non è quello che fa il lavoro che l'AI può fare. È quello che non ha mai costruito il giudizio per riconoscere · 24 Aprile 2026 ![Il riposizionamento dell'ingegnere senior nell'era del prompt operator](https://www.mauriziofonte.it/image/004440070-ingegnere-senior-prompt-operator-intent-manager-governance.jpg) - [L'AI scrive gran parte del codice di chi la produce: cosa significa per chi assume sviluppatori](https://www.mauriziofonte.it/blog/post/ai-scrive-codice-recursive-self-improvement-assumere-sviluppatori.html) Le aziende di frontiera dichiarano che una quota crescente del loro codice è ormai scritta dall'AI, con il task horizon che si allunga di mese · 1 Luglio 2026 ![L'AI scrive gran parte del codice di chi la produce: cosa significa per chi assume sviluppatori](https://www.mauriziofonte.it/image/004760070-ai-scrive-codice-recursive-self-improvement-assumere-sviluppatori.jpg) - [Code generation con LLM: limiti reali e dove l'AI non arriva ancora nel 2025](https://www.mauriziofonte.it/blog/post/code-generation-llm-limiti-reali-ai-2025-sviluppatori-php.html) Dopo 18 mesi di utilizzo sistematico di LLM per codice PHP in produzione, ho una visione precisa dei limiti reali. L'AI eccelle nel boilerplate, · 6 Marzo 2026 ![Code generation con LLM: limiti reali e dove l'AI non arriva ancora nel 2025](https://www.mauriziofonte.it/image/003180070-code-generation-llm-limiti-reali-ai-2025-sviluppatori-php.jpg) - [Oltre lo specs-to-code: design concept, ubiquitous language e TDD per non annegare nell'output AI](https://www.mauriziofonte.it/blog/post/oltre-specs-to-code-design-concept-ubiquitous-language-tdd.html) Scrivi una spec, lasci che l'AI la trasformi in codice, e quando qualcosa non va riapri solo la spec. È seducente. Non funziona: ogni iterazione · 22 Aprile 2026 ![Oltre lo specs-to-code: design concept, ubiquitous language e TDD per non annegare nell'output AI](https://www.mauriziofonte.it/image/004420070-oltre-specs-to-code-design-concept-ubiquitous-language-tdd.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "La cascata sistemica del coding AI: vulnerabilità, paradosso di produttività, collasso della carriera junior", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/ai-coding-cascata-sistemica-vulnerabilita-produttivita-junior.html Pubblicato: 2026-04-21 · Aggiornato: 2026-06-19. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.