Vibe coding pro e contro: velocità o debito tecnico?

Cos'è il vibe coding, e perché tutti ne parlano come se avessero scoperto il fuoco

Il termine l'ha coniato Andrej Karpathy all'inizio del 2025, e da allora il settore tech non ha fatto altro che dividersi in due fazioni: quelli che lo vedono come la fine della programmazione tradizionale e quelli che lo trattano come una bestemmia in chiesa. La verità, come al solito, sta nel mezzo, ma è molto più interessante di così.

Il vibe coding, per chi arriva da Marte, è la pratica di sviluppare software affidandosi quasi completamente a un modello di linguaggio: tu descrivi cosa vuoi, il modello genera il codice, tu accetti, itero, accetti ancora. Poca lettura del codice prodotto, molta fiducia nel risultato. Un po' come ordinare al ristorante senza leggere il menu e sperare che lo chef abbia capito che sei intollerante al lattosio.

Funziona? Sì. Sempre? Assolutamente no. E fare finta che la risposta sia semplice è il modo più veloce per ritrovarsi con un'applicazione in produzione che nessuno sa come modificare.

Dove il vibe coding vince davvero (e non è poca roba)

Partiamo dai casi in cui questa roba funziona, perché negarlo sarebbe disonesto oltre che inutile.

Il boilerplate è il primo candidato ovvio. Se devi impostare un progetto Next.js con autenticazione, connessione al database, configurazione ESLint e struttura delle cartelle, stai parlando di due ore di lavoro meccanico e frustrante che un modello risolve in dieci minuti. Non c'è valore intellettuale nel scrivere a mano la configurazione di Prisma per la quarantesima volta. Nessuno. Il vibe coding su boilerplate non è pigrizia, è igiene mentale.

La prototipazione rapida è il secondo caso d'uso dove il guadagno è reale e misurabile. Hai un'idea, hai bisogno di validarla con un cliente o con il team prima di investire settimane di sviluppo. Il vibe coding ti permette di avere qualcosa di cliccabile in un giorno. Non sarà bello, non sarà scalabile, ma funzionerà abbastanza da rispondere alla domanda che conta: vale la pena costruirlo per davvero? Questo accelera il ciclo di decisione in modo che nessun'altra metodologia è riuscita a replicare con la stessa efficacia.

C'è poi tutto il territorio degli script interni, dei tool di automazione, delle utility che il team usa ma che nessuno vuole davvero mantenere. Conversione di formati, migrazione di dati una tantum, generatori di report. Codice che serve adesso, che non entrerà mai nel core del prodotto, e che può essere scritto velocemente, usato, e poi eventualmente buttato. Il vibe coding eccelle qui perché il costo del debito tecnico è irrilevante quando il ciclo di vita del codice è breve per definizione.

Un team di sviluppo con cui ho lavorato ha ridotto il tempo di setup di nuovi microservizi del 60% integrando il vibe coding nella fase iniziale di ogni progetto. Il segreto era semplice: usarlo solo per la struttura, non per la logica di business. Una distinzione che sembra banale finché non la applichi sistematicamente.

I rischi vibe coding che nessuno ti dice finché non è troppo tardi

Arriviamo al lato scomodo, che è anche quello più interessante da analizzare.

Il problema numero uno non è che il codice generato sia sbagliato. Spesso è corretto. Il problema è che nessuno nel team lo capisce. E il codice che nessuno capisce è, per definizione, codice che nessuno può modificare con sicurezza. Quando arriva il bug in produzione alle 2 di notte, il fatto che quel modulo sia stato generato da un'AI in tre minuti non aiuta nessuno. Aiuta ancora meno se lo sviluppatore che deve intervenire non ha idea di quale logica stia guardando, perché non l'ha mai letta con attenzione.

Questo è il cuore del debito tecnico codice AI: non è debito nel senso tradizionale, ovvero "lo facciamo male adesso e lo sistemiamo dopo". È debito cognitivo. Il codebase cresce in fretta, ma la comprensione del team non cresce con esso. A un certo punto il rapporto si inverte, e il team inizia a lavorare attorno al codice invece che con il codice. Ogni nuova feature richiede workaround, ogni fix introduce nuovi bug, ogni rilascio diventa un atto di fede.

Il secondo rischio riguarda la sicurezza, ed è sottovalutato in modo preoccupante. I modelli di linguaggio generano codice plausibile, non codice sicuro. La differenza è enorme. Un'implementazione di autenticazione generata via vibe coding potrebbe funzionare perfettamente in fase di test e avere vulnerabilità imbarazzanti che emergono solo sotto attacco reale. SQL injection, gestione scorretta dei token, validazione degli input assente o superficiale: sono tutti pattern che un modello può replicare senza che l'output sembri sbagliato a una lettura veloce. E in modalità vibe coding, la lettura veloce è spesso l'unica che avviene.

Il terzo problema è la manutenibilità nel tempo. Il vibe coding in produzione su sistemi complessi genera una forma particolare di entropia: il codice è tecnicamente funzionante ma architetturalmente inconsistente. Ogni sessione con il modello produce scelte stilistiche e strutturali leggermente diverse. Nel tempo, il risultato è un codebase che sembra scritto da dieci persone diverse che non si sono mai parlate, ognuna con le proprie convenzioni, la propria gestione degli errori, il proprio modo di strutturare le dipendenze. Fare refactoring su questo tipo di codice è un lavoro che nessun developer vuole toccare, e si vede.

C'è anche un quarto rischio, più sottile, che riguarda le dipendenze. I modelli tendono a suggerire librerie che erano popolari al momento del loro training. In alcuni contesti questo è irrilevante. In altri, ti ritrovi con pacchetti npm deprecati, dipendenze con vulnerabilità note, o semplicemente soluzioni che nel frattempo l'ecosistema ha superato. Nessuno se ne accorge finché non arriva l'audit di sicurezza, o finché una libreria non viene abbandonata e smette di ricevere aggiornamenti.

Come usarlo senza farsi del male: regole pratiche, non teologia

La distinzione che fa la differenza non è "usare o non usare il vibe coding". È capire su quale strato del sistema lo stai applicando.

Tutto ciò che è infrastruttura, configurazione, scaffolding e automazione interna può beneficiare del vibe coding senza conseguenze serie. Il rischio è basso, il guadagno è alto, e il codice prodotto non ha bisogno di essere compreso nel dettaglio da tutto il team.

La logica di business è un'altra storia. Qui il vibe coding deve essere usato come punto di partenza, non come risultato finale. Il modello suggerisce, lo sviluppatore legge, capisce, modifica, e solo allora il codice entra nel repository. Non è un processo più lento di quanto sembri, ma richiede che la lettura critica del codice generato sia un passaggio esplicito e non negoziabile nel workflow.

• Stabilisci una regola di revisione obbligatoria per tutto il codice AI generato che tocca logica di business, autenticazione, pagamenti, o gestione dei dati utente. Non come best practice teorica. Come policy di team con enforcement reale.
• Tieni separati i contesti: usa il vibe coding in branch dedicati al prototipo, e tratta quei branch come codice usa e getta. Se una feature prototipata deve entrare in produzione, riscrivila con attenzione, usando il prototipo come specifica funzionale, non come base di codice.
• Fai audit delle dipendenze su tutto il codice generato prima che entri in un ambiente condiviso. Uno script automatico che controlla le vulnerabilità note con strumenti come npm audit o Snyk non è optionale, è il minimo sindacale.
• Documenta le scelte architetturali che il modello ha fatto per te. Se non riesci a spiegare perché il codice è strutturato in un certo modo, il problema non è il modello, sei tu che non l'hai letto abbastanza.
• Non usarlo mai per rifattorizzare sistemi legacy complessi senza una copertura di test solida. Il modello non ha contesto storico sul tuo sistema, non sa perché certe scelte sono state fatte, e il codice prodotto sarà corretto in isolamento ma potenzialmente rotto nel contesto reale.

Come direbbe qualsiasi buon ingegnere che ha imparato la lezione nel modo sbagliato: gli strumenti non falliscono, falliscono i processi attorno agli strumenti. Il vibe coding non è l'eccezione.

Il vero costo del debito tecnico codice AI: i numeri che nessuno calcola

C'è un esercizio che faccio spesso quando lavoro con team che hanno adottato il vibe coding senza una strategia chiara. Chiedo di stimare quante ore a settimana vengono spese a capire codice esistente invece di scriverne di nuovo. La risposta media, in team che hanno usato il vibe coding in modo non strutturato per sei mesi o più, si aggira tra il 30 e il 40% del tempo di sviluppo totale.

Per un team di cinque sviluppatori con un costo orario medio di 60 euro, stiamo parlando di 14.000-19.000 euro al mese bruciati in comprensione di codice che avrebbe potuto essere scritto in modo comprensibile fin dall'inizio. Il vibe coding aveva accelerato il delivery iniziale, certo. Ma il risparmio accumulato nei primi mesi viene eroso in pochi sprint di manutenzione.

Questo non significa che il saldo sia negativo. Significa che il saldo dipende interamente da come hai usato lo strumento. E che "ho risparmiato tempo" è una metrica troppo corta per valutare l'impatto reale del vibe coding in produzione su un sistema che deve vivere più di sei mesi.

Il punto di equilibrio esiste, ed è raggiungibile. Richiede disciplina, processi chiari, e la capacità di resistere alla tentazione di usare il vibe coding anche dove non ha senso usarlo, solo perché è veloce e dà quella soddisfazione immediata che, come qualsiasi cosa gratificante nel breve termine, presenta il conto dopo.

Alina, AI Analyst di Inceptio