Il 46% dei Dev Non Si Fida dell'AI che Usa Ogni Giorno

Prompt vago, zero contesto, nessuna review. Merge. E poi ci lamentiamo che "l'AI scrive codice buggato".

Il Developer Survey 2025 di Stack Overflow — 49.000 sviluppatori, 177 paesi — racconta un paradosso: l'84% degli sviluppatori usa o prevede di usare tool AI, ma il 46% non si fida dell'accuratezza dei risultati. Solo il 3% dichiara di fidarsi completamente. Nel 2024 la sfiducia era al 31% — in un anno è salita di 15 punti.

La reazione istintiva è dare la colpa allo strumento. Ma se guardi i dati più da vicino, emerge un quadro diverso: la sfiducia non nasce tanto da quello che l'AI produce, quanto da come la usiamo. Prompt generici, nessun context engineering, zero osservabilità sull'output. È come dare un bisturi a qualcuno senza formazione chirurgica e poi lamentarsi che taglia male.

E il paradosso vero è un altro: nonostante la sfiducia, non smettiamo di usarli. Anzi, li usiamo di più. E — peggio ancora — non controlliamo nemmeno quello che producono.

Il Paradosso in Numeri

I dati non vengono da un solo report. Arrivano da almeno cinque ricerche indipendenti pubblicate nel 2025, e raccontano tutte la stessa storia.

Metrica	Dato	Fonte
Dev che usano o useranno AI	84%	Stack Overflow 2025
Dev che non si fidano dell'accuratezza	46%	Stack Overflow 2025
Dev che si fidano	33%	Stack Overflow 2025
Dev che si fidano "molto"	3%	Stack Overflow 2025
Codice committato che è AI-assisted	42%	Sonar 2025
Dev che non si fidano del codice AI	96%	Sonar 2025
Dev che effettivamente verificano	48%	Sonar 2025

Fermati un secondo su questi numeri. Il 42% del codice in produzione è AI-assisted. Il 96% degli sviluppatori ha dubbi sulla sua affidabilità. Ma solo il 48% lo verifica effettivamente.

Tradotto: la maggioranza degli sviluppatori non si fida del codice AI, lo usa comunque perché è veloce e comodo, e poi non lo controlla nemmeno. È come mangiare in un ristorante di cui non ti fidi ma dove torni ogni sera perché è sotto casa — senza nemmeno guardare cosa c'è nel piatto.

Sonar lo chiama verification gap. Ma forse il termine più onesto sarebbe "pigrizia consapevole". Sappiamo che c'è un rischio, ma il beneficio immediato vince.

"Quasi Giusto" — La Frustrazione Numero Uno

La cosa che fa più impazzire i developer non è l'AI che sbaglia clamorosamente. Quello lo riconosci subito. È l'AI che sbaglia di poco.

Il 66% degli intervistati nello Stack Overflow Survey cita come frustrazione principale le "soluzioni AI che sono quasi giuste, ma non del tutto". Quel codice che compila, che passa i test più ovvi, ma che ha un edge case nascosto, una race condition sottile, un'assunzione sbagliata su un tipo nullable.

Il 45% aggiunge che debuggare codice AI richiede più tempo che debuggare il proprio. Perché almeno il tuo codice lo capisci — sai perché hai fatto quella scelta. Il codice AI arriva senza contesto, senza ragionamento, e quando si rompe devi prima capire cosa stava cercando di fare, e poi perché non funziona.

Funziona, Ma Non È Quello che Volevo

C'è un aspetto della sfiducia che nessun survey cattura, ma che ogni developer conosce: l'AI ti dà codice che funziona, ma che tu non avresti mai scritto così.

Non è un bug. Non è una vulnerabilità. È qualcosa di più sottile. L'AI sceglie un pattern architetturale diverso da quello che avevi in mente. Usa un'astrazione che non ti convince. Nomina le variabili in modo che non rispecchia le convenzioni del progetto. Risolve il problema, sì — ma non il tuo problema, non nel tuo modo.

Questo genera un tipo di sfiducia che va oltre la correttezza tecnica. Quando leggi codice che non riconosci come "tuo", perdi il controllo cognitivo. Non sai perché l'AI ha fatto quella scelta. Non sai se c'è un motivo sottile o se è semplicemente il pattern più frequente nei dati di training. E quando qualcosa si rompe — e si romperà — devi prima ricostruire il ragionamento di qualcun altro (anzi, di qualcosa che non ragiona affatto) prima di poter fixare.

È la differenza tra guidare la tua auto e guidare un'auto a noleggio. Entrambe ti portano a destinazione. Ma solo una la conosci davvero.

I developer senior lo sentono di più. Non a caso, nello Stack Overflow Survey i dev con più esperienza hanno il tasso di "alta fiducia" più basso (2.6%) e quello di "alta sfiducia" più alto (20%). Non è resistenza al cambiamento — è che hanno un modello mentale più preciso di come dovrebbe essere il codice, e l'AI lo viola più spesso.

1.7x Più Bug: I Dati sulla Qualità del Codice

Non è solo una percezione. I numeri sulla qualità del codice AI sono oggettivi — e non sono incoraggianti.

CodeRabbit ha analizzato 470 pull request confrontando codice umano e AI-generated:

Il codice AI produce 1.7x più issue di quello umano
1.75x più errori di logica e correttezza
1.64x più problemi di manutenibilità
1.57x più finding di sicurezza
Le inefficienze di performance appaiono quasi 8 volte più spesso
L'AI è 2.25x più propensa a creare errori algoritmici e di business logic

GitClear ha analizzato 211 milioni di righe di codice modificate tra il 2020 e il 2024:

Il code churn (codice riscritto entro 2 settimane) è salito dal 5.5% al 7.9%
Il codice refactorizzato è crollato dal 24.1% al 9.5%
Il codice copia-incollato è salito dall'8.3% al 12.3%
I blocchi con 5+ righe duplicate sono aumentati di 8 volte nel 2024
Per la prima volta, il codice copiato supera quello ristrutturato

In parole semplici: si scrive più codice, ma di qualità inferiore, meno strutturato, e più ripetitivo.

Il 45% Ha Falle di Sicurezza

Il problema della qualità diventa critico quando parliamo di sicurezza.

Veracode (2025) ha testato codice generato da oltre 100 LLM su 80 task: il 45% aveva vulnerabilità di sicurezza. Java raggiunge il 70%, Python e JavaScript stanno tra il 38% e il 45%.

Uno studio di Stanford è andato oltre: gli sviluppatori che usavano assistenti AI scrivevano codice significativamente meno sicuro di quelli senza. E — ecco il paradosso — erano più convinti che il loro codice fosse sicuro. Falsa confidenza.

Georgetown CSET ha trovato che il 40% di 1.689 programmi generati da Copilot era vulnerabile alle MITRE CWE Top 25, con 2.74x più vulnerabilità XSS e 1.88x più problemi di gestione password.

Apiiro, analizzando Fortune 50, ha riportato che i tool AI generano sì una velocità 4x, ma con 10x più rischi di sicurezza. In sei mesi, i finding di sicurezza sono passati da circa mille a 10.000+ al mese. I path di escalation dei privilegi sono aumentati del 322%.

Più Veloci? In Realtà, No

Qui la ricerca più interessante arriva da METR — un trial randomizzato controllato, il gold standard della ricerca scientifica.

16 sviluppatori esperti, con in media 5 anni di esperienza sui loro stessi progetti open source, hanno completato 246 task con e senza AI (Cursor Pro con Claude 3.5/3.7 Sonnet).

Risultato: con l'AI erano il 19% più lenti.

Ma ecco la parte incredibile. Prima di iniziare, i dev avevano predetto che l'AI li avrebbe resi il 24% più veloci. Dopo averla usata, erano ancora convinti di essere stati il 20% più veloci. La percezione era completamente scollegata dalla realtà.

Il campione è piccolo (16 persone), ma la metodologia è rigorosa. E il dato è coerente con altri report.

Uplevel ha studiato 800 sviluppatori: quelli con GitHub Copilot non hanno mostrato nessun miglioramento in cycle time, throughput o complessità del codice. Anzi, avevano un tasso di bug significativamente più alto. L'unico miglioramento? Meno indicatori di burnout.

Faros AI ha trovato che i team con alta adozione AI completano il 21% di task in più e fanno il 98% in più di PR per developer. Ma il tempo di code review aumenta del 91%. I guadagni individuali evaporano quando il team non riesce a gestire il volume.

Il Codice Hallucina — E Lo Fa in Modo Ripetibile

Il problema delle hallucination nel codice è particolarmente insidioso. Non si tratta solo di risposte sbagliate: su 576.000 campioni di codice, il 19.7% dei pacchetti suggeriti non esisteva.

E il 43% di questi nomi fantasma veniva ripetuto in modo consistente tra prompt diversi. Un attaccante può registrare quel nome, metterci codice malevolo, e aspettare che qualcuno faccia npm install o pip install seguendo il consiglio dell'AI. È lo slopsquatting, ne abbiamo parlato qualche giorno fa.

Qodo riporta che il 76% degli sviluppatori sperimenta hallucination frequenti. Un developer su quattro stima che una su cinque suggerimenti AI contenga errori fattuali o codice fuorviante. Solo il 3.8% riporta contemporaneamente basse hallucination e alta confidenza nel fare merge senza review.

Il Vibe Coding e la Superficie d'Attacco

Il termine "vibe coding" — coniato da Andrej Karpathy a febbraio 2025 — descrive un approccio dove ti affidi completamente all'AI e "dimentichi che il codice esiste". Collins English Dictionary lo ha eletto parola dell'anno 2025.

Ironia della sorte: Karpathy stesso ha ammesso di aver codificato a mano il suo progetto "Nanochat" perché gli agent AI "semplicemente non funzionavano abbastanza bene".

Ma il vibe coding ha comunque preso piede. E i dati sulla sicurezza sono impietosi.

Escape.tech ha analizzato 5.600+ app vibe-coded:

2.000+ vulnerabilità scoperte
400+ secret esposti (chiavi API, token)
175 istanze di dati personali accessibili (cartelle cliniche, IBAN, email)

Wiz Research riporta che il 20% delle app vibe-coded ha vulnerabilità serie: autenticazione lato client, secret hardcodati, Row Level Security mancante.

Il caso più eclatante: Lovable, una piattaforma per creare app con AI, dove 170 su 1.645 app testate avevano database Supabase completamente esposti. Importi di debiti personali, indirizzi di casa, chiavi API — accessibili a chiunque senza autenticazione.

Le Aziende che Hanno Detto "No"

Il problema non è sfuggito ai piani alti. Diverse grandi aziende hanno limitato o vietato l'uso di tool AI:

Azienda	Azione	Motivo
Samsung	Ban completo di ChatGPT	Tre incidenti di upload di codice proprietario
Apple	Restrizioni su ChatGPT e Copilot	Rischio leak su roadmap prodotto
Goldman Sachs	Restrizioni su tool AI esterni	Protezione dati proprietari
Bank of America	Restrizioni	Sviluppo AI interno preferito
Amazon	Warning ai dipendenti	Rischio IP leakage

Il 61% delle organizzazioni controlla quali tool GenAI possono usare i dipendenti. Il 63% limita il tipo di dati inseribili nei tool AI.

Dove l'AI Funziona Davvero

Sarebbe disonesto presentare solo i problemi. L'AI coding ha casi d'uso dove funziona bene, e i dati lo confermano.

Il tasso di ritenzione del codice accettato da Copilot è dell'88%: una volta che il dev accetta il suggerimento e lo adatta, quel codice resta in produzione. I migliori use case:

Boilerplate e scaffolding — codice ripetitivo dove la struttura è nota
Generazione test — il 53% degli sviluppatori riporta migliore test coverage
Documentazione — il 57% la trova migliorata
Code completion per pattern ripetitivi — il classico "completa questo switch case"
Imparare nuovi linguaggi — esplorare API e framework sconosciuti

Il pattern è chiaro: l'AI funziona bene dove il margine d'errore è basso e la verifica è facile. Funziona male dove servono giudizio, architettura e comprensione del dominio.

Il Punto: Non È l'AI il Problema, Siamo Noi

Tutti questi dati raccontano una storia che sembra riguardare l'AI. Ma se la guardi con onestà, riguarda noi.

Il codice AI ha 1.7x più bug? Sì — quando gli dai un prompt di due righe senza contesto. Il 45% ha vulnerabilità? Sì — quando non specifichi requisiti di sicurezza e non hai una pipeline che controlla. Lo studio METR mostra che siamo più lenti? Sì — perché passiamo più tempo a correggere output che non abbiamo saputo guidare che a scrivere codice da zero.

Il vero problema non è la qualità dell'AI. È che la maggior parte degli sviluppatori usa questi tool come se fossero una slot machine: inserisci un prompt, tiri la leva, speri che esca qualcosa di buono. E quando non esce, la colpa è della macchina.

Il verification gap? Non è un difetto dell'AI — è un difetto del nostro processo. Se il 42% del codice in produzione è AI-assisted ma solo il 48% viene verificato, il problema non è lo strumento. È che non abbiamo costruito workflow di review adeguati.

La sfiducia dei senior? Non è resistenza al cambiamento — è che hanno standard alti e l'AI, senza contesto sufficiente, non li raggiunge. Ma un senior che imposta un buon CLAUDE.md, che definisce regole di progetto, che fa context engineering serio, ottiene risultati completamente diversi da uno che scrive "fammi un API REST".

La differenza tra chi si fida e chi no non è ottimismo vs pessimismo. È competenza d'uso:

Context engineering — dai all'AI il contesto del progetto, le convenzioni, i vincoli. Non il prompt nudo
Osservabilità — leggi quello che produce. Sempre. Se non hai tempo di fare review, non hai tempo di usare l'AI
Prompt specifici — "aggiungi validazione input con sanitizzazione XSS sul campo email" produce codice diverso da "aggiungi un form"
Pipeline di verifica — test automatizzati, SAST nella CI/CD, code review. Lo strumento non sostituisce il processo
Usa l'AI dove ha senso — boilerplate, test, documentazione, esplorazione. Il lavoro architetturale resta tuo

Gli sviluppatori che nel Sonar survey riportano sia output veloce che alta fiducia hanno il 61% di soddisfazione lavorativa — la più alta in assoluto. Non sono quelli con l'AI migliore. Sono quelli che hanno imparato a usarla.

Il 46% non si fida. La domanda è: quanti di quel 46% hanno davvero provato a usare l'AI bene?