L'Industria del Software Era Già un Disastro Prima dell'AI

$2.41 trilioni. Ogni anno. Solo negli Stati Uniti.

Non è il costo dell'AI. Non è il budget di OpenAI. È quanto costa il software di bassa qualità scritto da esseri umani, secondo il report CISQ del 2022. Duemilaquattrocento miliardi di dollari in bug, crash, vulnerabilità di sicurezza e technical debt — tutto prodotto da mani umane, review umane, processi umani.

Eppure apri qualsiasi thread su Hacker News o Reddit e trovi la stessa narrazione: il codice generato dall'AI è inaccettabile, illeggibile, fragile, pericoloso. Come se il codice umano fosse un tempio di perfezione ingegneristica e l'AI fosse arrivata a profanarlo.

Forse è il caso di guardarsi allo specchio.

Il conto del disastro

Partiamo dai numeri. Non opinioni, non sensazioni — dati.

Il 70% dei progetti software fallisce parzialmente o totalmente. Non è un dato controverso: lo confermano BCG, Standish Group, McKinsey. Solo il 31% dei progetti viene consegnato nei tempi, nel budget e con lo scope previsto. Il budget overrun medio è del 190%.

Il report CAST 2025, basato sull'analisi di 10 miliardi di righe di codice in produzione, dipinge un quadro ancora più crudo:

Problema	Percentuale del codice mondiale
Codice "fragile" (suscettibile a failure)	45%
Codice "bloated" (gonfio, inefficiente)	32%
Codice "rigido" (rallenta i cambiamenti)	31%

Quasi metà del codice scritto da umani in tutto il mondo è fragile. Un terzo è gonfio. Un terzo è rigido. E non stiamo parlando di side project del weekend — sono codebase enterprise in produzione.

Il 63% degli sviluppatori cita il technical debt come la frustrazione numero uno del proprio lavoro. Il tech debt accumulato solo negli USA vale $1.52 trilioni. A livello globale, parliamo di 61 miliardi di giornate lavorative perse.

Questo è il baseline. Questo è il punto di partenza prima che l'AI scrivesse una sola riga di codice.

Gli incidenti che dovrebbero farci tacere

I numeri aggregati sono una cosa. Gli incidenti specifici sono un'altra. E raccontano una storia che chi critica il codice AI preferisce ignorare.

CrowdStrike, luglio 2024. Un update difettoso al Falcon Sensor — software scritto, testato e deployato da umani — manda in crash 8.5 milioni di sistemi contemporaneamente. Il costo stimato supera i $5.4 miliardi solo per le Fortune 500. Sanità: $1.94 miliardi. Banking: $1.15 miliardi. È stato il più grande outage IT della storia. Nessuna AI coinvolta.

Knight Capital, agosto 2012. Un deploy inconsistente — 7 server aggiornati su 8, l'ottavo con codice dormiente del 2003 — causa 4 milioni di esecuzioni non autorizzate in 45 minuti. $440 milioni persi. Il titolo crolla del 75% in due giorni. L'azienda viene acquisita. Il bug? Un flag bit riusato accidentalmente ha riattivato codice vecchio di 9 anni che nessuno si era preoccupato di rimuovere. Codice umano, review umana, deploy umano.

Boeing 737 MAX, 2018-2019. Il sistema MCAS si basava su un singolo sensore e poteva sovrascrivere i comandi del pilota. 346 persone morte in due incidenti. Il contesto? Boeing aveva outsourced parte dello sviluppo software a ingegneri pagati $9 l'ora. Un ex-ingegnere Boeing ha descritto il processo: "It frequently took many rounds going back and forth because the code was not done correctly." Non era AI a $9/ora. Erano umani a $9/ora.

Toyota, accelerazione involontaria. L'analisi degli esperti nel processo Bookout v. Toyota ha trovato un software con 11.000 variabili globali e 67 funzioni classificate come "untestable". L'analisi NASA, su 35 regole MISRA-C verificate, ha rilevato 7.134 violazioni. Un programmatore Toyota ha descritto il codice come "spaghetti-like". Un esperto ha testimoniato che un singolo bit flip poteva far perdere al guidatore il controllo della velocità del motore.

Heartbleed, 2012-2014. Un bug in OpenSSL — una delle librerie più critiche al mondo — è rimasto nel codice per due anni senza che nessun code review umano lo trovasse. Il 17% dei server HTTPS mondiali era vulnerabile. E OpenSSL era mantenuto da soli 2 sviluppatori full-time per 500.000 righe di codice. Steve Marquess, presidente della OpenSSL Foundation, ha commentato: "The mystery is not that a few overworked volunteers missed this bug; the mystery is why it hasn't happened more often."

Due su tre outage cloud sono causati da errore umano. Non da AI, non da automazione impazzita — da configurazioni sbagliate, deploy affrettati, test saltati. Il 45% dei major outage è causato da configuration changes manuali.

Il mito della code review

Uno degli argomenti più comuni contro il codice AI è: "non passa la code review, non è leggibile, non è manutenibile." Ed è vero — il codice AI spesso non è elegante. Ma quanto funziona davvero la code review umana?

I dati dicono una cosa scomoda: il 75% dei commenti di code review non riguarda bug. Riguarda stile, naming, leggibilità, "manutenibilità". Solo il 15% dei commenti identifica problemi reali.

La code review formale trova il 60-65% dei bug. Quella informale — il tipo che facciamo tutti i giorni sulle PR — meno del 50%. E l'efficacia crolla con la dimensione: oltre 400 righe di codice, scende sotto il 70%. Oltre 1.000 righe, sotto il 50%.

Quando un collega commenta "questo metodo andrebbe rinominato" o "potresti estrarre questa logica in una funzione separata", sta facendo bikeshedding — dedicando attenzione ai dettagli estetici mentre i veri bug passano inosservati. Non è colpa di nessuno: il cervello umano è pessimo a trovare bug leggendo codice. È strutturalmente fatto per notare le anomalie superficiali e perdere quelle profonde.

Eppure, quando guardiamo il codice generato dall'AI, la prima cosa che diciamo è: "non è leggibile." Come se la leggibilità fosse mai stata la nostra difesa contro i bug.

Il paradosso dei test

C'è un dato che dovrebbe far riflettere chiunque giudichi la qualità del codice AI: solo l'8% degli sviluppatori pratica davvero il Test-Driven Development.

Il 41% delle aziende dice di aver adottato TDD. Ma quando chiedi quanti developer scrivono i test prima del codice almeno l'80% delle volte, il numero crolla all'8%. Lo studio IBM/Microsoft ha dimostrato che il TDD reale riduce i difetti del 40-90%. Ma quasi nessuno lo fa.

Anche con il 100% di code coverage — cosa che quasi nessuno raggiunge — si trovano circa la metà dei difetti reali.

Solo il 19% dei team software raggiunge performance "elite" secondo il DORA Report 2024. Il 60% è nella fascia media o bassa.

Ecco il paradosso: un'industria dove quasi nessuno testa seriamente il proprio codice si erge a giudice della qualità del codice generato da una macchina. Come un dottore che fuma 40 sigarette al giorno e ti critica perché prendi troppo caffè.

Codice AI vs umano: i dati reali

Ma veniamo al confronto diretto. I dati esistono e non sono tutti a favore dell'AI.

Il report CodeRabbit, basato sull'analisi di 470 PR, ha trovato che il codice AI-generated ha 1.7 volte più issue di quello umano:

Categoria	AI vs Umano
Logic & Correctness	+75% issue nell'AI
Readability	+3x issue nell'AI
Error handling	+2x issue nell'AI
Security	fino a +2.74x nell'AI
Performance (I/O eccessivo)	+8x nell'AI
Spelling errors	+1.76x negli umani
Testability	+1.32x negli umani

L'AI scrive codice con più problemi di logica, sicurezza e leggibilità. È un dato reale. Ma ecco il punto che quasi nessuno menziona: il baseline umano è di 6.45 issue per PR. Non zero. Non "poche". Sei issue e mezzo per ogni pull request, in codice scritto da professionisti pagati.

Il codice AI ne ha 10.83. Peggio, certo. Ma non è che stiamo confrontando il disastro con la perfezione — stiamo confrontando un disastro con un disastro leggermente più grande.

Il report GitClear 2025, su 211 milioni di righe analizzate, conferma che il code churn — codice riscritto entro due settimane — è salito dal 5.5% al 7.9% con l'adozione dell'AI. Il codice duplicato è cresciuto dal 8.3% al 12.3%. Il refactoring è crollato del 60%.

Dati preoccupanti. Ma vanno contestualizzati: il code churn pre-AI non era zero. Il codice duplicato pre-AI non era zero. Il refactoring pre-AI era già in declino.

Lo studio METR: anche il codice umano viene bocciato

Lo studio METR di marzo 2026 ha fatto qualcosa di intelligente: ha preso le patch di SWE-bench — sia AI che umane — e le ha fatte valutare alla cieca da maintainer reali.

I risultati sono illuminanti:

Tipo di codice	Score test automatici	Merge rate (valutazione cieca)
Patch umane (golden baseline)	100%	68%
Claude Sonnet 4.5	~79%	~55%
Claude Opus 4	~69%	~45%

Il gap tra AI e umano è di circa 24 punti percentuali. L'AI viene mergiata meno. Fin qui, nessuna sorpresa.

Ma il dato che cambia la prospettiva è un altro: il 32% delle patch umane già mergiate — codice che era già stato accettato nel codebase — viene rigettato quando sottoposto a valutazione cieca da altri maintainer.

Un terzo del codice umano, già approvato e in produzione, non passerebbe una seconda review. Il metro di giudizio non è perfetto per nessuno. La qualità del codice è soggettiva in modi che non amiamo ammettere.

Il survivorship bias del codice umano

C'è un bias cognitivo che distorce tutto il dibattito: quando confrontiamo codice AI e codice umano, non facciamo un confronto equo.

Il codice umano che vediamo in produzione è il codice sopravvissuto. Ha passato code review, test, QA, mesi o anni di bugfix incrementali. È il risultato di un processo di selezione e raffinamento che ha eliminato le versioni peggiori.

Il codice AI che giudichiamo è output grezzo. È la prima bozza, il draft prima dell'editing. Nessuno guarda la prima versione di un modulo scritto da un developer junior cinque anni fa — guardiamo la versione attuale, dopo venti iterazioni.

Confrontare output AI grezzo con il meglio del codice umano curato da anni è come confrontare un primo draft di un romanzo con un'edizione finale rivista da tre editor. Il confronto non è sbagliato nei dati, ma è profondamente ingannevole nelle conclusioni.

C'è anche un altro aspetto: il code aesthetics privilege. Giudicare la qualità del codice dalla leggibilità è un lusso dei team ben staffati e stabili. Ma il 70% dei developer è aperto a cambiare lavoro. Il turnover medio è 13-22%. Quando un dev se ne va, il 42% della conoscenza progettuale se ne va con lui.

Quel codice "leggibile" scritto dal collega che è andato via sei mesi fa? È altrettanto opaco del codice AI per chi deve mantenerlo senza contesto. La leggibilità senza continuità del team è un'illusione.

Se funziona, è testato e le metriche sono buone — importa come è scritto?

La domanda è provocatoria, e la risposta non è un semplice "no". Ma merita di essere posta seriamente.

Se il codice — generato da AI o da un umano — soddisfa queste condizioni:

I test passano (unit, integration, e2e)
Le metriche di performance sono buone (latency, throughput, resource usage)
La sicurezza è verificata (SAST, DAST, dependency scanning)
Il comportamento in produzione è corretto (monitoring, alerting, SLO rispettati)

...quanto conta davvero che una variabile si chiami temp_data_processor invece di orderTransformer? Quanto conta che un metodo sia lungo 45 righe invece di essere scomposto in tre funzioni da 15?

La risposta tradizionale è: conta perché qualcuno dovrà modificarlo. E c'è del vero. Ma se quel "qualcuno" è un altro agente AI che non ha bisogno di leggibilità umana per navigare il codice? E se quel codice viene riscritto tra sei mesi comunque, come succede con il 7.9% del codice attuale?

Non è una questione retorica. È una questione pratica che l'industria dovrà affrontare: i criteri di qualità del codice sviluppati per team umani hanno ancora senso in un mondo dove il codice viene generato e modificato da agenti?

La vera domanda: cosa misurare

L'errore nel dibattito attuale è confondere l'estetica del codice con la qualità del software.

La qualità del software si misura in:

Correttezza: fa quello che deve fare?
Resilienza: gestisce i casi limite?
Sicurezza: è vulnerabile?
Performance: risponde nei tempi previsti?
Affidabilità: funziona nel tempo?

La leggibilità del codice è un proxy — un indicatore indiretto che, storicamente, correlava con queste proprietà. Ma è un proxy, non la misura stessa. E come tutti i proxy, può diventare fuorviante quando il contesto cambia.

Un software con codice "brutto" ma testato, monitorato, sicuro e performante è oggettivamente migliore di un software con codice elegante ma fragile, non testato e pieno di vulnerabilità. E come abbiamo visto, il 45% del codice "umano" rientra nella seconda categoria.

Questo non significa che la leggibilità non conti nulla. Significa che è meno importante di quanto pensiamo, e che ci sono modi migliori per garantire la qualità del software — modi che funzionano sia per codice umano che AI.

Chi lavora con agenti AI ha già iniziato a sviluppare questi approcci. L'Harness Engineering — la disciplina di controllare e verificare il lavoro degli agenti — si basa proprio su questo principio: misurare il comportamento del software, non l'estetica del codice. Test automatizzati, metriche di performance, gate di sicurezza, monitoring in produzione. Strumenti che funzionano indipendentemente da chi ha scritto il codice.

Il costo dell'iterazione è sceso a zero

C'è un aspetto che quasi nessuno sta considerando nel dibattito sulla qualità del codice AI.

Confrontare output AI con codice umano come se fossero entrambi "prodotti finiti" ignora la differenza fondamentale: il codice umano costa iterarlo. Ogni refactoring richiede tempo, concentrazione, rischio di regressioni. Ogni riscrittura è un investimento che va giustificato.

Il codice AI costa quasi nulla iterarlo. Puoi rigenerarlo, ristrutturarlo, riscriverlo da zero in minuti. Se il risultato non soddisfa le metriche, rigeneri. Se il test fallisce, correggi e rigeneri. Se la performance non è sufficiente, chiedi una versione ottimizzata.

Questo cambia radicalmente l'equazione. Quando l'iterazione è gratuita, la qualità della prima stesura diventa meno importante. Quello che conta è il loop: genera → misura → itera. E l'Harness Engineering è esattamente il metodo per rendere quel loop misurabile e convergente.

I test end-to-end diventano il vero arbitro. Non "il codice è pulito?" ma "il sistema si comporta correttamente sotto carico, in produzione, con dati reali?". Se la risposta è sì e le metriche lo confermano, il codice può convergere verso qualsiasi livello di pulizia attraverso iterazioni successive — ciascuna delle quali costa quasi nulla.

È la differenza tra giudicare la prima bozza di un romanzo e giudicare un sistema che può riscriversi all'infinito finché le metriche non convergono. Il primo ha bisogno di uno scrittore bravo. Il secondo ha bisogno di metriche giuste.

Non difendere l'AI — smontare l'arroganza

Questo articolo non è una difesa dell'AI. Il codice AI-generated ha problemi reali: più bug, meno gestione degli errori, rischi di sicurezza maggiori. I dati lo confermano e sarebbe disonesto ignorarli.

Ma la narrazione prevalente — "il codice AI è un disastro, il codice umano era meglio" — si regge su una memoria selettiva. $2.41 trilioni di danni all'anno. Il 70% dei progetti falliti. Il 45% del codice fragile. 346 morti per software outsourced al ribasso. Un outage da $5.4 miliardi causato da un update umano.

L'industria del software era già un disastro. L'AI non ha portato il caos in un giardino ordinato — ha aggiunto rumore a un sistema che era già rumoroso.

La domanda giusta non è "il codice AI è all'altezza del codice umano?" — perché il codice umano non ha mai messo l'asticella poi così in alto.

La domanda giusta è: stiamo costruendo i sistemi di verifica che servono? Test automatizzati, metriche di qualità oggettive, monitoring in produzione, gate di sicurezza. Strumenti che avremmo dovuto costruire decenni fa per il codice umano e che ora l'AI ci sta costringendo a prendere sul serio.

Se c'è un lato positivo in tutto questo, è che l'arrivo dell'AI ha reso impossibile continuare a fingere che il code review e il "buon senso" fossero sufficienti a garantire la qualità del software. Non lo erano prima. Non lo sono ora. La differenza è che ora non possiamo più far finta di niente.

Fonti: