Vibe coding: cosa succede quando finisce la luna di miele

Il "vibe coding" (termine ormai diffuso per indicare l'uso di assistenti come Claude, Codex, Gemini, Cursor o Windsurf con prompt vaghi tipo "creami una dashboard", senza requisiti né architettura definiti) è genuinamente divertente: idee che prima richiedevano settimane di prototipazione prendono vita in una serata. Il problema arriva quando il progetto cresce oltre il prototipo del weekend.

Chiedi di cambiare un bottone e cambia la barra di navigazione. Chiedi di sistemare la barra di navigazione e si rompe l'autenticazione (il meccanismo che verifica chi sei prima di farti entrare). La sistemi e sparisce metà dello stile grafico. La cronologia della chat finisce per somigliare più a una seduta di terapia di coppia che a una sessione di sviluppo: "ti avevo chiesto di cambiare una cosa sola" — "lo so, ma pensavo fosse meglio così".

Il difetto non era nell'AI, era nei prompt: "creami un'app di project management" non è un requisito, è un desiderio senza forma. Lo sviluppo software tradizionale non è mai partito dal codice — parte dal capire il problema: chi sono gli utenti, cosa si sta costruendo, quali funzionalità contano davvero, cosa può aspettare alla versione due. È esattamente quello che lo SDLC (Software Development Life Cycle, il ciclo di vita strutturato di un progetto software) predica da sempre, e che il vibe coding ribalta: si genera codice prima, e si capisce cosa si voleva a metà conversazione.

I team che ci sono passati stanno reintroducendo pratiche ingegneristiche vecchio stile — a partire dal testing, che rende i progetti più affidabili e riduce i bug a sorpresa. Ma il testing da solo non basta: ti dice se hai costruito la cosa nel modo giusto, non se stai costruendo la cosa giusta. Per quello serve ancora una specifica scritta prima, non dopo.