Il Paradosso del Vibe Coding: Piu Veloce Si, Ma di Chi Ti Fidi?

"The bottleneck moved from writing code to proving it works."

Addy Osmani ha riassunto in una frase quello che migliaia di sviluppatori stanno scoprendo sulla propria pelle. Scrivere codice non e piu il problema. Generarne cento righe al minuto e banale. Il problema e diventato un altro: come fai a sapere che quel codice funziona davvero?

Non "funziona" nel senso che compila. "Funziona" nel senso che non espone secrets in produzione, non rompe il checkout di Amazon, non finisce bannato dall'App Store, non introduce una vulnerabilita che scoprirai tra sei mesi quando e troppo tardi.

Benvenuti nell'era in cui il software si scrive da solo e nessuno sa se fidarsi.

Il gap che nessuno riesce a chiudere

Partiamo dal numero che definisce il momento: 84% degli sviluppatori usa o pianifica di usare tool AI per scrivere codice. Era il 76% nel 2024. L'adozione cresce a doppia cifra ogni anno.

Fin qui, nessuna sorpresa. Il numero interessante e l'altro.

La fiducia nell'accuratezza del codice AI e al 29%. Era al 40% l'anno prima. Un crollo di 11 punti percentuali mentre l'adozione saliva di 8. E non e finita: solo il 3% degli sviluppatori dichiara di avere alta fiducia nell'output AI. Il 46% ha distrust attivo — piu di chi si fida.

Metrica (Stack Overflow 2025)	Dato
Adozione AI	84%
Fiducia nell'accuratezza	29%
Alta fiducia	3%
Distrust attivo	46%
Favorability positiva	60% (era 72%)

Il gap e di 55 punti percentuali. Usiamo uno strumento di cui non ci fidiamo. E piu lo usiamo, meno ci fidiamo.

C'e un dettaglio che rende il quadro ancora piu scomodo: i dev con piu esperienza sono i piu scettici. Solo il 2.6% dei senior ha "alta fiducia" — il numero piu basso. Il 20% ha "alta sfiducia" — il numero piu alto. Chi ha le competenze per giudicare la qualita del codice AI e chi meno si fida.

Il dato Sonar che dovrebbe togliere il sonno

Se il gap adozione-fiducia di Stack Overflow e preoccupante, il survey Sonar 2026 e terrificante.

Il 96% degli sviluppatori non si fida pienamente del codice generato dall'AI. Novantasei percento. Ma — e qui viene il bello — solo il 48% verifica sempre il codice prima di committare.

Facciamo i conti. Il 42% del codice committato oggi e gia AI-generato. Quasi la meta di quello che finisce in produzione e scritto da una macchina. E meno della meta degli sviluppatori fa review sistematico prima di pushare.

Il 96% dice "non mi fido". Il 52% committa lo stesso senza verificare.

Non e un gap. E un abisso tra quello che pensiamo e quello che facciamo. E la definizione stessa di un rischio sistemico: sappiamo che c'e un problema, lo dichiariamo apertamente nei survey, e poi ci comportiamo come se non esistesse.

Perche? La risposta e banale quanto pericolosa: la pressione a spedire e piu forte della disciplina di verificare. E quando il costo di generare codice e zero, ma il costo di verificarlo resta alto, il sistema si sbilancia nella direzione ovvia.

I segnali che il mercato ha gia capito

Non serve aspettare scenari ipotetici. I segnali concreti sono gia qui.

Apple ha iniziato a bannare app vibe-coded dall'App Store. Il 26 marzo ha rimosso "Anything", un'app il cui cofondatore Dhruv Amin e stato informato direttamente della violazione della Guideline 2.5.2. Una settimana prima aveva gia bloccato aggiornamenti per app create con Replit e Vibecode. L'ironia? Apple aveva aggiunto Claude e Codex a Xcode il mese prima. Il messaggio e chiaro: generare codice con AI va bene, ma la responsabilita di quello che finisce nell'App Store resta tua. Se il codice non regge lo scrutinio, viene rimosso.

GitGuardian ha pubblicato il report 2026 sulle secrets esposte su GitHub. Il dato che salta all'occhio: i commit generati da Claude Code hanno un tasso di secrets hardcoded del 3.2%, contro l'1.5% della baseline. Il doppio. Su 1.94 miliardi di commit pubblici nel 2025, 28.65 milioni contenevano secrets — un record, +34% anno su anno. I secrets legati a servizi AI sono cresciuti dell'81%.

GitGuardian ci tiene a specificare che non e un "tool failure" — gli sviluppatori restano responsabili di cosa accettano e pushano. Giusto. Ma e esattamente il punto: se il 52% non verifica prima di committare, chi controlla quelle secrets?

Poi c'e il leak del codice sorgente di Claude Code stesso: 512.000 righe di TypeScript esposte per un file .map incluso per errore nel pacchetto npm. Un incidente che ha mostrato quanto sia facile che qualcosa sfugga quando la velocita ha la priorita sulla verifica.

Il paradosso della velocita: piu PR, piu review, zero miglioramento

Faros AI ha condotto uno studio su 10.000 sviluppatori in 1.255 team. I risultati sono un caso da manuale di "attenzione a cosa desideri."

Metrica	Variazione con AI
Task completati	+21%
Pull request mergiate	+98%
Dimensione media PR	+154%
Tempo di review	+91%
Bug per developer	+9%
Miglioramento aziendale	Zero

Leggi bene l'ultima riga. Le PR mergiate sono quasi raddoppiate. Il tempo di review e quasi raddoppiato. I bug per developer sono aumentati. E il risultato netto a livello aziendale? Nessun miglioramento significativo.

E la Legge di Amdahl applicata al software engineering. Un sistema si muove alla velocita del suo anello piu lento. Hai accelerato la scrittura del codice? Bene, adesso il bottleneck e il review. Hai raddoppiato le PR? Bene, adesso i reviewer sono sommersi. PR piu grandi del 154% che richiedono il 91% di tempo in piu per essere valutate — da persone che nel frattempo stanno anche generando il proprio codice con AI.

Il report Sonar conferma: il 38% degli sviluppatori dice che revisionare codice AI richiede piu sforzo che revisionare codice umano. Solo il 27% dice il contrario. Il review e diventato il nuovo bottleneck, e nessuno ha ancora trovato un modo per scalarlo.

Come scriveva Fortune ieri: "Trust is the real bottleneck."

Il costo cognitivo che nessuno contabilizza

C'e un prezzo nascosto in tutto questo, e Harvard Business Review gli ha dato un nome: brain fry.

Il 14% dei lavoratori che usano AI ne e colpito. Chi lo sperimenta riporta il 33% in piu di decision fatigue e — dato che dovrebbe far riflettere chiunque lavori su sistemi critici — il 39% in piu di errori gravi.

Non errori minori. Errori gravi. Da persone il cui lavoro e verificare che il codice sia corretto.

C'e un punto di diminishing returns che lo studio identifica con precisione: la produttivita sale con uno, due, tre tool AI simultanei. Oltre tre, crolla. Il multitasking tra strumenti AI diversi — generatore di codice, copilot, chat, agente — supera la capacita cognitiva e il sistema si degrada.

Chi ha letto l'articolo sul costo cognitivo dell'AI ricordera il ciclo: piu output, piu ore, piu drain mentale. I commit fuori orario salgono del 20%. L'AI non riduce il lavoro. Lo intensifica.

E qui il paradosso si chiude. Metti insieme i pezzi: developer sotto pressione cognitiva (+33% decision fatigue) che devono revisionare PR piu grandi (+154%) e piu numerose (+98%), con meno fiducia nello strumento (29%) e meno tempo per verificare (solo 48% controlla sempre). Il risultato e prevedibile: +9% bug per developer, e quelli sono solo i bug che si trovano.

Il paradosso della competenza invertita

C'e un paradosso piu profondo di tutti gli altri, e nessuno ne parla abbastanza.

Per verificare codice AI servono competenze superiori a quelle necessarie per scriverlo.

Pensaci. Scrivere una funzione da zero richiede un certo livello di conoscenza. Capire se una funzione scritta da qualcun altro e corretta — trovare il bug sottile, l'edge case non gestito, la vulnerabilita nascosta — richiede un livello superiore. E il motivo per cui il code review e storicamente affidato ai senior, non ai junior.

Ma se l'AI scrive codice al posto tuo, quelle competenze non le sviluppi mai. Il muscolo della programmazione si atrofizza. E ti ritrovi in una situazione dove hai piu bisogno che mai di competenze di verifica, ma il sistema che le produceva — scrivere codice, sbagliare, debuggare, capire — e stato cortocircuitato.

Karpathy, che ha coniato il termine "vibe coding" e ora lo considera superato, lo dice senza giri di parole: "At the top tiers, deep technical expertise may be even more of a multiplier than before."

L'expertise tecnica profonda vale di piu con gli agenti AI, non di meno. Ma chi la sviluppa, se tutti vibano?

Il survey Sonar offre un dato che illumina il problema da un'altra angolazione: i junior sono quelli che riportano i maggiori guadagni di produttivita dall'AI (40%). Sono anche quelli meno equipaggiati per verificare l'output. I senior — quelli che potrebbero verificare — sono i piu scettici e i meno entusiasti.

Il trust layer umano si sta erodendo proprio quando ne abbiamo piu bisogno. Chi costruiva l'industria del software prima dell'AI non era perfetto — tutt'altro. Ma almeno il processo di scrivere, sbagliare e capire formava competenze. Eliminare quel processo senza sostituirlo con qualcosa e come togliere le ruote di supporto dalla bici e sperare che il bambino sappia gia pedalare.

Il mercato della verifica sta nascendo

Il mercato ha fiutato il problema. E quando il mercato fiuta un problema, arrivano i soldi.

Qodo ha raccolto $70 milioni in Series B specificamente per la "code verification" — non code generation, code verification. Il CEO Itamar Friedman e esplicito: "AI is not enough when you're talking about real-world software quality and code governance. What you need, actually, is official wisdom."

Tra i clienti: Walmart, Nvidia, Ford, Texas Instruments. Non startup — enterprise che hanno capito che il vibe coding senza verifica e una bomba a orologeria.

Il concetto che Qodo propone si chiama flow engineering: un modello genera codice, un altro lo critica. Non ti fidi dell'AI? Metti un'altra AI a controllare la prima. E un approccio pragmatico che riconosce una verita scomoda: i reviewer umani non scalano, ma qualcosa deve verificare quei milioni di righe AI-generated.

L'articolo Fortune lo riassume bene: il vibe coding "overestimates how much these tools can be trusted in the short term and underestimates how much a trust layer is needed."

Il trust layer. E questa la parola chiave. Non e piu una questione di "AI si o AI no" — quella battaglia e finita, l'AI ha vinto. La questione e cosa metti tra la generazione e la produzione. Che sia un framework di harness engineering, un sistema di flow engineering, o una pipeline di test automatizzati, il layer di verifica non e opzionale.

Chi lo costruisce per primo ha un vantaggio competitivo enorme. Chi lo ignora sta accumulando debito — non tecnico, ma di fiducia.

Cosa significa per chi sviluppa

I dati raccontano una storia coerente, anche se scomoda.

La velocita e reale. L'AI genera codice piu velocemente di qualsiasi umano. Le PR raddoppiano, i task si chiudono, il throughput individuale esplode. Negarlo e disonesto.

Ma la velocita senza verifica e un'illusione. +98% PR e +91% tempo di review con zero miglioramento aziendale. Il sistema non va piu veloce — va piu veloce in un punto e si ingolfa in un altro. Il bottleneck si e spostato, non eliminato.

La competenza di verificare vale piu della competenza di scrivere. E il cambio di paradigma che pochi hanno interiorizzato. Se sai leggere codice, trovare bug, identificare vulnerabilita, capire architetture — vali piu di prima, non meno. Se sai solo promptare, sei sostituibile dal prossimo tool.

Il verification gap e il rischio piu grande. Il 96% non si fida, il 52% non verifica. Quel 52% e codice in produzione che nessuno ha controllato. E secrets esposte, e bug latenti, e app bannate. Il gap si chiudera — la domanda e se lo chiudiamo noi con disciplina o se lo chiude il mercato con incidenti.

Tre cose concrete da fare oggi:

Non committare mai codice che non sai spiegare. Osmani lo dice chiaro: "Never commit code you can't explain." Se non capisci cosa fa, non e pronto.
Automatizzare la verifica, non la generazione. La generazione e gia automatizzata. Il valore e nei test, nel security scanning, nel monitoring. Se investi tempo, investilo li.
Sviluppare la competenza di review come skill primaria. Non e piu un side task. E il lavoro. Chi sa revisionare codice AI in modo efficace sara il developer piu richiesto dei prossimi cinque anni.

Il vibe coding non e morto. Ma la fase in cui bastava generare e spedire e finita. Il prossimo capitolo e tutto sulla fiducia — come costruirla, come verificarla, come scalare la verifica alla velocita della generazione.

Chi risolve questo problema vince. Chi lo ignora finisce su un report come esempio di cosa non fare.

Fonti: