«L’IA scrive codice più in fretta» non è in discussione. Se scriva codice peggiore è una questione a parte, empirica — e preferiamo rispondervi con misurazioni piuttosto che con i punti di conversazione di uno dei due schieramenti. Tre studi indipendenti, con tre metodi diversi, convergono sulla stessa risposta.
Il punto di partenza: un tasso di difetti documentato
Lo studio fondativo lo trattiamo in dettaglio in A Clean Benchmark Is Not a Clean Codebase (in inglese): Pearce et al. (IEEE S&P 2022) trovarono circa il 40 % di 1 689 programmi generati da Copilot vulnerabile alle classi di debolezze della Top 25 di MITRE. Lo studio è ormai abbastanza datato da non dover leggere quella cifra come attuale — i modelli sono cambiati dal 2022. Ciò che ha stabilito, e su cui il lavoro successivo si appoggia: la questione è reale e può ricevere risposta con metodi standard — scenari mirati, un campione ampio, analisi statica contro un elenco di debolezze con un nome.
Il meccanismo: non bug casuali, un’assenza sistematica
Una cifra da sola non dice che cosa fare. Un confronto controllato tra codice scritto da umani e codice generato da LLM — strutture dati, algoritmi, routine crittografiche e problemi in stile LeetCode, con test unitari, fuzzing e analisi statica (arXiv:2409.19182) — è andato oltre e ha trovato questo: il codice generato da LLM è meno sicuro anzitutto perché gli mancano i costrutti di programmazione difensiva — i controlli sui limiti e la validazione degli input che un ingegnere accurato aggiunge per abitudine, non la funzionalità effettivamente richiesta. Quell’assenza è ciò che invita gli overflow di buffer e di interi. Sotto fuzzing, il codice generato da LLM era più incline a blocchi e crash rispetto alla base di confronto scritta da umani. I difetti di correttezza potevano essere sottili anziché evidenti: in un caso il modello ha prodotto un’implementazione errata di SHA-1 che tuttavia compilava pulita — sbagliata, e in silenzio al riguardo.
Il rilievo che dovrebbe preoccupare chiunque consideri «chiedi al modello di aggiustarlo» una rete di sicurezza: lo stesso studio ha costruito un ciclo di retroazione, chiedendo al modello di rigenerare il codice ed eliminare i problemi appena mostrati. Non ha funzionato in modo affidabile. In alcuni casi la correzione è riuscita. In altri il codice «corretto» conteneva problemi nuovi — e in alcuni casi l’atto stesso di fare prompting ha introdotto problemi in file che prima erano puliti. Far correggere all’autore i propri compiti non è una revisione.
L’evidenza in produzione: il costo non passa con la novità
L’evidenza più recente arriva del tutto fuori dal laboratorio. Uno studio ha seguito 807 repository open source su GitHub che hanno adottato l’assistente di codifica Cursor tra gennaio 2024 e marzo 2025, contro un gruppo di controllo di 1 380 repository comparabili senza — con SonarQube come strumento di misura per avvisi di analisi statica, duplicazione e complessità, fino ad agosto 2025. La storia della produttività si è svolta come previsto: un picco effimero di commit e righe aggiunte nei primi uno-due mesi, ritorno alla linea di base al terzo. Il costo di qualità non è passato con esso. Gli avvisi di analisi statica sono saliti di circa il 30 % dopo l’adozione e sono rimasti elevati. La complessità del codice è salita di oltre il 40 % — più di quanto la sola crescita della base di codice spiegherebbe. Il guadagno di velocità era temporaneo. Il debito no.
Un confine onesto
Questa non è l’affermazione che il codice generato dall’IA sia sempre peggiore, come legge generale. Compito, modello e modo di lavorare contano tutti — e un team che tratta l’output dell’IA come una prima bozza meritevole della stessa disciplina di revisione della pull request di un ingegnere junior vede risultati diversi da un team che lo spedisce senza revisione. Gli studi qui sopra non provano ogni modello né ogni modo di lavorare, e nessuno isola la disciplina di revisione come variabile. Ciò che stabiliscono con coerenza, attraverso tre metodi indipendenti (test CWE mirati, confronto controllato, dati longitudinali di produzione): l’effetto è reale e sistematico anziché occasionale — e chiedere al modello di controllare il proprio lavoro non sostituisce il fatto che lo faccia qualcun altro.
Perché è una questione di conformità, non solo di ingegneria
In forza del Cyber Resilience Act, un fabbricante deve garantire che i prodotti con elementi digitali siano «progettati, sviluppati e prodotti in modo da garantire un livello adeguato di cibersicurezza in base ai rischi» e «messi a disposizione sul mercato senza vulnerabilità sfruttabili note» (regolamento (UE) 2024/2847, allegato I, parte I, punti 1) e 2) a)). Nessuna delle due clausole menziona come il codice sia stato scritto. Entrambe diventano più difficili, non più facili, da soddisfare quanta più superficie di una base di codice è stata prodotta da un processo con una carenza misurata e sistematica proprio nei costrutti — controlli sui limiti, validazione degli input — che impediscono a una classe nota di debolezze di diventare sfruttabile. Generare più in fretta senza rivedere di più non è una scorciatoia attorno a quell’obbligo. È una distanza che cresce da esso.
Perché ci riguarda
In CounterProof pratichiamo la revisione avversariale di codice scritto dalle macchine, e questi tre studi descrivono esattamente il divario che la nostra practice esiste per colmare: trattare l’output dell’IA — quello che genera e quello che revisiona — come un’affermazione da verificare, non come un risultato di cui fidarsi. Si veda il pezzo gemello A Clean Benchmark Is Not a Clean Codebase (in inglese) su che cosa accade quando anche lo strumento di verifica è basato sull’IA e la sua stessa affidabilità resta inesaminata. L’argomento lungo, compresa la forma condizionale di ogni affermazione qui sopra, è nel nostro working paper sulla collazione e la provenienza del testo generato dalle macchine, leggibile per intero qui (in inglese). È una bozza di preprint, non sottoposta a revisione paritaria, e lo dichiara.
Le fonti citate sopra sono state verificate rispetto ai loro abstract pubblicati. La cifra di Pearce et al. proviene da IEEE S&P 2022 e descrive Copilot com’era al tempo di quello studio, non i modelli attuali. Le cifre su Cursor provengono da uno studio longitudinale di 807 repository contro un gruppo di controllo di 1 380, seguiti da gennaio 2024 ad agosto 2025. Le disposizioni del CRA citate rinviano al regolamento (UE) 2024/2847 e sono state verificate rispetto alla versione linguistica italiana ufficiale. Questa pagina è una traduzione dell’originale inglese; in caso di divergenza prevale l’originale. Se qualcosa qui è errato, lo correggeremo per iscritto su questa pagina.