Il vibe coding è la pratica di costruire software descrivendo a un'AI cosa vuoi ottenere, accettando il codice che produce senza leggerlo davvero. Il termine è stato coniato da Andrej Karpathy all'inizio del 2025 ed è diventato in fretta il modo in cui moltissime persone scrivono il primo prototipo di qualcosa.
Questa definizione la trovi identica su Wikipedia, su IBM e sul blog di Google. Quello che non trovi da nessuna parte è cosa succede a quel codice sei mesi dopo, quando qualcuno deve metterlo in produzione o modificarlo.
Io faccio lo sviluppatore e negli ultimi tempi mi arrivano progetti nati così, da sistemare. È da lì che parlo.
Come funziona, in concreto
Descrivi il risultato che vuoi in linguaggio naturale. L'AI genera il codice. Lo provi: se funziona vai avanti, se non funziona descrivi cosa non va e l'AI riprova. Il ciclo si ripete finché il risultato è quello atteso.
La differenza con "usare l'AI per programmare" sta tutta in un punto: nel vibe coding non rivedi il codice, guardi solo il comportamento. Sposti il criterio di accettazione dal "come è fatto" al "fa quello che volevo". È una scelta, non una pigrizia, e in alcuni contesti è la scelta giusta.
Quando funziona benissimo
Chi lo demonizza in blocco non ha mai avuto una scadenza. Il vibe coding è ottimo quando il codice è usa e getta o quando il costo di sbagliare è basso:
- Prototipi da mostrare. Serve capire se un'idea sta in piedi, non se il codice è elegante. Se l'idea non convince, quel codice sparisce comunque.
- Script personali. Rinominare tremila file, ripulire un CSV, convertire un formato. Lo usi tre volte e lo butti.
- Imparare guardando. Chiedere un'implementazione funzionante e poi studiarla è un ottimo modo di capire una libreria nuova.
- Automazioni interne senza dati sensibili. Se si rompe, se ne accorge una persona sola e nessuno perde soldi.
Il rischio vero non è quello che pensi
Quando si parla dei rischi del vibe coding, quasi tutti citano la sicurezza. È un problema reale, ma non è il primo che incontri.
1. Non sai cosa hai
Questo è il rischio numero uno, e vale da subito. Codice che nessuno ha letto è codice che nessuno può modificare con sicurezza. La prima richiesta di modifica arriva sempre, e in quel momento non sai dove mettere le mani: non hai un modello mentale del sistema, hai solo la memoria di cosa gli avevi chiesto.
Il sintomo tipico: ogni modifica successiva richiede di rigenerare pezzi sempre più grandi, finché rigeneri l'intera applicazione per cambiare un pulsante.
2. Funziona sui tuoi dati, non su quelli veri
Il codice generato gestisce il caso normale, quello che hai descritto. I casi limite li gestisce solo se qualcuno li ha nominati: campo vuoto, valore negativo, due utenti che salvano insieme, connessione che cade a metà.
Sono esattamente i casi che in produzione arrivano il primo giorno.
3. Le falle di sicurezza sono silenziose
Un bug funzionale lo vedi. Una query costruita concatenando stringhe, un endpoint senza controllo dei permessi, una chiave lasciata nel codice sorgente non fanno rumore. L'applicazione funziona perfettamente fino al giorno in cui qualcuno se ne accorge.
È la ragione per cui, appena i dati sono di clienti reali, il codice va letto. Sempre.
4. Il costo si sposta, non sparisce
Il risparmio è tutto all'inizio, ed è enorme: settimane compresse in giorni. La manutenzione però si paga a rate, e a rate più care. Un progetto che nessuno ha capito costa di più da mantenere di uno scritto lentamente.
Non è un argomento contro il vibe coding: è un argomento per sapere quale codice puoi permetterti di non leggere.
La linea di demarcazione
Dopo un po' di progetti da recuperare, la regola che uso è una sola domanda: cosa succede se questo codice si comporta male e nessuno se ne accorge per una settimana?
- Non succede niente — script personale, prototipo, automazione interna. Vibe coding senza problemi.
- Qualcuno si arrabbia — strumento usato dal team, sito vetrina. Vibe coding per la prima versione, poi qualcuno legge il codice prima della pubblicazione.
- Perdi soldi, dati o clienti — pagamenti, dati personali, gestionale, e-commerce. Qui l'AI resta uno strumento potentissimo, ma il codice si rivede riga per riga. Il flusso che uso sui progetti dei clienti l'ho descritto in questo articolo.
Se hai già un progetto nato così
Non serve buttarlo. L'ordine con cui conviene metterci mano:
- Fai un inventario di cosa fa, funzione per funzione, prima di toccare qualsiasi cosa. Anche solo un elenco scritto a mano.
- Metti sotto test i due o tre percorsi che contano — quello che porta soldi, quello che tocca i dati dei clienti. Senza test non stai sistemando, stai sperando.
- Guarda subito credenziali e permessi. Chiavi nel codice, endpoint aperti, query costruite con concatenazione di stringhe. È la parte che si paga più cara.
- Poi il resto, in ordine di quanto spesso lo tocchi.
La domanda che conta davvero
"Il vibe coding è buono o cattivo" è una discussione da social. La domanda utile è quanto ti costa se questa cosa si rompe, e la risposta la sai solo tu.
Chi lo usa per tutto prima o poi si trova con un sistema che nessuno sa manutenere. Chi lo rifiuta per principio consegna prototipi tre volte più lentamente di chi lo usa. Nessuna delle due è una posizione da professionista.
Se hai un progetto costruito così e devi capire se regge il passaggio in produzione, è un'analisi che faccio spesso: scrivimi e ti dico onestamente cosa va rifatto e cosa no.
