# La velocità passa. La complessità resta.

> Tre studi indipendenti, tre metodi diversi — uno studio mirato sulle vulnerabilità, un confronto controllato umano-modello e un anno di osservazione di repository reali — convergono sullo stesso rilievo: il codice generato dall'IA porta un costo di qualità misurabile che sopravvive al guadagno di produttività con cui è arrivato.

Source: https://counterproof.io/it/notes/la-velocita-passa-la-complessita-resta/ · Published 25 August 2026 · CounterProof è una practice di Clavestra Capital Limited (Malta, C 113987).


«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*](https://counterproof.io/notes/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*](https://counterproof.io/notes/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](https://research.counterproof.io/) (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.*