Vibe coding: più codice non significa più valore

Quando Andrej Karpathy ha coniato il termine "vibe coding", a febbraio 2025, descriveva un modo di lavorare quasi giocoso: descrivi quello che vuoi a un modello, accetti il codice che ti propone senza guardarlo troppo, e vai avanti a sensazione. Vibe, appunto. Un anno e mezzo dopo, quel gioco è diventato il modo in cui una fetta enorme di software viene effettivamente scritta — e i nodi stanno venendo al pettine.

Premessa doverosa, per non farmi passare per il vecchio che urla alla nuvola: scrivo software dal 2012, e oggi in agenzia gli agenti AI li usiamo tutti i giorni. Il passaggio dai copilot agli agenti è ormai completo: gli strumenti moderni non suggeriscono righe di codice, eseguono modifiche su più file, lanciano comandi, leggono documentazione, testano il proprio lavoro. La produttività è reale: gli studi parlano di tempi di prototipazione ridotti fino al 50%, e la mia esperienza dice che su certi task è perfino una stima prudente.

Il problema non è lo strumento. Il problema è cosa stiamo confondendo: la velocità con cui si produce codice con la velocità con cui si produce valore. Non sono la stessa cosa, e i dati cominciano a dimostrarlo con una certa brutalità.

I numeri della sbornia

Due dati su tutti, usciti negli ultimi mesi.

Il primo: CodeRabbit ha analizzato 470 pull request open-source su GitHub, confrontando codice co-firmato dall'AI con codice scritto da umani. Il codice con coautore AI conteneva circa 1,7 volte più problemi "major": più errori di logica, il 75% in più di configurazioni sbagliate, e 2,74 volte più vulnerabilità di sicurezza.

Il secondo, ancora più interessante per chi fa impresa: secondo quanto emerso alla conferenza Platmosphere 2026, solo il 10% dei progetti basati su vibe coding supera la fase pilota in ambito enterprise. Il 90% si ferma lì, principalmente per problemi di qualità, sicurezza e scalabilità.

Messi insieme, i due numeri raccontano una storia coerente: il vibe coding è straordinario per arrivare a qualcosa che funziona, e pessimo per arrivare a qualcosa che regge. La demo in tre giorni è realtà. Il sistema in produzione che gestisce dati veri, utenti veri e attaccanti veri è un altro mestiere.

Il debito invisibile

C'è un concetto che ogni sviluppatore conosce e ogni imprenditore dovrebbe conoscere: il debito tecnico. Ogni scorciatoia presa oggi è un interesse da pagare domani. Il vibe coding spinto è una macchina per generare debito tecnico a velocità mai vista, con un'aggravante nuova: è debito che nessuno ha visto contrarre.

Quando uno sviluppatore prende una scorciatoia, lo sa. Sa dov'è il punto debole, può documentarlo, ci tornerà. Quando un agente genera diecimila righe accettate "a sensazione", il punto debole non lo conosce nessuno. È lì, da qualche parte, in attesa. E gli errori degli agenti hanno una caratteristica subdola che l'analisi sulla sicurezza evidenzia bene: sono sistematici. Lo stesso pattern sbagliato — un controllo di accesso debole, una configurazione ingenua — replicato identico in cinquanta punti del codebase. L'errore umano è artigianale; l'errore dell'agente è industriale.

Per una PMI che commissiona software, questo si traduce in un rischio commerciale concreto: il preventivo stracciato di chi "con l'AI ci mette un decimo del tempo" può essere vero sulla consegna e falso sul ciclo di vita. Il software si paga due volte: quando lo compri e quando lo mantieni. La seconda voce, col vibe coding selvaggio, può divorare la prima.

Come usiamo gli agenti senza farci male

Non scrivo tutto questo per concludere "tornate a scrivere il codice a mano", che sarebbe anacronistico oltre che falso rispetto a come lavoro io stesso. La questione è di processo, e le regole che ci siamo dati in agenzia sono replicabili da chiunque.

La review non si delega. Ogni riga generata da un agente passa dagli occhi di qualcuno che avrebbe saputo scriverla. L'AI accelera la scrittura, non sostituisce il giudizio — è la differenza tra usare l'AI e farsi usare.

L'architettura resta umana. Gli agenti eccellono dentro confini ben definiti e deragliano quando i confini li scelgono loro. Le decisioni di struttura — cosa parla con cosa, dove vivono i dati, dove passano le autorizzazioni — le prendiamo prima, e l'agente lavora dentro quel perimetro.

I test non li scrive solo chi ha scritto il codice. Far verificare all'agente il proprio lavoro è come chiedere all'oste se il vino è buono. Test indipendenti, scenari pensati da umani, attenzione particolare a sicurezza e casi limite — proprio perché sappiamo che è lì che il codice generato statisticamente zoppica.

La responsabilità ha un nome. Su ogni progetto c'è una persona che risponde della qualità di quello che esce, indipendentemente da chi — o cosa — l'ha scritto. Il cliente non compra codice, compra un risultato di cui qualcuno risponde.

Se sei tu a comprare il software: le domande giuste

Questo articolo lo leggeranno anche imprenditori che il codice non lo scrivono ma lo commissionano. Per voi la questione è ancora più concreta, perché il vibe coding ha reso il mercato dello sviluppo più opaco: due fornitori con preventivi distanti il triplo possono nascondere differenze enormi di processo, invisibili alla consegna e devastanti dopo.

Qualche domanda da fare a chi svilupperà il vostro software, nell'ordine in cui la farei io. Usate strumenti AI? (Se rispondono di no, o mentono o sono inefficienti: oggi entrambe le risposte sono un problema.) Come viene revisionato il codice generato — c'è una persona che ne risponde riga per riga? Come gestite test e sicurezza, e chi li progetta? Cosa mi consegnate oltre al software funzionante: documentazione, accessi, possibilità di far subentrare qualcun altro?

Non servono competenze tecniche per valutare le risposte: serve sentire se dall'altra parte c'è un processo o c'è improvvisazione. Il fornitore serio risponde a queste domande con sollievo, perché gli capita di rado di trovare clienti che le fanno. Quello da evitare cambia discorso e torna a parlare di quanto sarà veloce.

E un'ultima nota sul prezzo: l'AI ha davvero abbassato i costi di sviluppo, quindi un preventivo più basso che un anno fa è fisiologico, non sospetto. Il sospetto nasce quando il prezzo basso si accompagna a tempi irrealistici e a risposte vaghe sul processo. La velocità senza processo non è efficienza: è debito con un altro nome.

Più codice, più giudizio

La verità di fondo è che il vibe coding ha rovesciato l'economia del software: per sessant'anni scrivere codice è stato costoso e lento, e attorno a quella scarsità abbiamo costruito tutto. Ora il codice è abbondante e quasi gratuito. Ma quando una risorsa diventa abbondante, il valore si sposta sulle risorse complementari che restano scarse: il giudizio per capire quale codice serve, l'architettura per tenerlo in piedi, la responsabilità di garantirlo nel tempo.

Il 10% dei progetti vibe-coded che arriva in produzione non è quello con gli agenti migliori. È quello con gli umani migliori attorno agli agenti. Mi sembra una buona notizia, a patto di non scoprirla dopo aver mandato in produzione il restante 90%.

---

Fonti: Wikipedia – Vibe coding, Agenda Digitale – Vibe coding: più codice, ma non sempre più valore, Tom's Hardware – Il vibe coding è una porta aperta ai cyber attacchi, Think.it