Il vibe coding consiste nel descrivere in linguaggio naturale ciò che si vuole e accettare quello che il modello produce, senza leggerlo con attenzione. Per un prototipo, uno script, uno strumento messo insieme in una sera, è un modo di lavorare davvero valido. Io stesso lo uso così.
I guai cominciano quando la cosa costruita in vibe coding va in produzione e inizia a custodire i dati di altre persone. Non perché il codice sia brutto: spesso è ordinato, idiomatico, ben nominato. Il problema è ciò che nessuno ha scritto.
Un modello risponde alla domanda che gli hai fatto
Chiedi un modulo di prenotazione e ottieni un modulo di prenotazione. Validerà l'indirizzo email. Probabilmente verrà meglio di quello che avrei scritto a mano io.
Quello che non farà è porti le domande che decidono se la cosa sopravvive al contatto con utenti reali. Cosa succede se due persone prenotano l'ultimo posto nello stesso secondo? Se il gestore dei pagamenti va in timeout dopo aver incassato ma prima che il tuo codice lo sappia? Chi può vedere questa prenotazione: il cliente, qualsiasi utente autenticato, chiunque abbia il link? Quando il cliente chiede la cancellazione dei dati, cos'altro va cancellato insieme e cosa va conservato per legge?
Non sono domande di programmazione. Sono decisioni sulla tua azienda, e il modello non può prenderle perché non gli sono mai stati forniti i fatti che servirebbero. Produce qualcosa di plausibile per ciascuna, in silenzio, e prosegue. Il codice compila. Il modulo funziona quando lo provi. La decisione, però, non l'ha presa nessuno.
La demo funziona sempre
È questa la trappola specifica, e coglie anche le persone esperte.
Una funzionalità nata dal vibe coding viene provata come è stata costruita: una persona, un browser, un solo percorso felice, senza carico e senza avversario. In quelle condizioni passa quasi tutto. I guasti vivono esattamente nelle condizioni che non hai pensato di creare: concorrenza, guasto parziale, input ostile, il secondo cliente, la diecimillesima riga, l'utente non più autenticato il cui token funziona ancora.
Così il ciclo di feedback ti mente. Pubblichi, funziona, pubblichi di nuovo più in fretta. La fiducia cresce esattamente mentre cresce la superficie non esaminata. Nulla ti avverte finché qualcosa non lo fa, in pubblico.
Sei cose che mancano sistematicamente
L'autorizzazione, distinta dall'autenticazione. I modelli se la cavano bene con il login. Sono molto più deboli su «questo utente può leggere proprio questa riga». La vulnerabilità più frequente del vibe coding, di gran lunga, è un endpoint che verifica che tu sia autenticato e non verifica mai chi sei.
Tutto ciò che deve restare corretto in concorrenza. Giacenze, prenotazioni di posti, numeri di fattura, saldi. Codice palesemente corretto letto dall'alto in basso è spesso sbagliato quando ne girano due copie insieme.
La modalità di guasto di ogni chiamata esterna. Ogni terza parte da cui dipendi prima o poi sarà irraggiungibile. Se questo debba fermare il tuo cliente è una decisione di business. Il codice generato la prende per caso, di solito andando in errore.
Dati che non puoi permetterti di perdere. Migrazioni che eliminano colonne, cancellazioni senza soft delete, nessun backup da cui tu abbia mai davvero ripristinato. Nessuno se ne accorge fino al giorno in cui conta, e quel giorno è irrecuperabile, non scomodo.
Il back office. Il vibe coding produce le schermate che hai descritto. Hai descritto quelle rivolte ai clienti, perché sono quelle che ti immagini. Poi il tuo personale vive otto ore al giorno in quel che è rimasto.
La coerenza tra le funzionalità. Ogni sessione riparte da zero. Dieci funzionalità costruite in dieci sessioni ti danno dieci convenzioni, tre modi di trattare le date, due schemi di autenticazione e nessun vocabolario comune. Singolarmente vanno bene. Come sistema, non manutenibile, nemmeno dal modello successivo.
Quanto costa davvero
L'argomento a favore del vibe coding è la velocità, e la velocità è reale. Ciò che rimanda è il costo della comprensione, e quel costo non sparisce: lo paga più tardi chi dovrà modificare il sistema.
Modificare software in sicurezza richiede qualcuno capace di prevedere cosa romperà una modifica. Quella persona costruisce il proprio modello del sistema prendendo le decisioni. Se nessuno ha preso le decisioni, nessuno ha il modello, e ogni modifica successiva è un'ipotesi con un deploy allegato.
Vengo chiamato regolarmente su progetti così. Il salvataggio non è quasi mai una riscrittura: il codice di solito è recuperabile. Ciò che richiede tempo è ricostruire l'intenzione: leggere ogni percorso per dedurre cosa il sistema doveva fare, perché non me lo sa dire nessuno, compreso chi l'ha pubblicato.
Cosa penso davvero
L'IA è il maggiore guadagno di produttività che il mio mestiere abbia visto e non lavorerei senza. È uno strumento eccellente nelle mani di chi ne sa leggere criticamente l'output e sa quali domande non sono state poste.
Non sostituisce quella persona. La rende più veloce. Il giudizio su cosa il tuo sistema non deve mai sbagliare non è un compito di programmazione, ed è esattamente la parte per cui stai pagando.
Usala per prototipi, script interni, cose usa e getta, la prima stesura di qualunque cosa. Per il sistema su cui gira la tua azienda, serve qualcuno che lo capisca da cima a fondo, che l'abbia scritto o rivisto riga per riga.