Cos'è davvero il "vibe coding" (e cosa non è)

Il termine "vibe coding" è nato per descrivere un modo di programmare in cui chi scrive software comunica intenti a un modello -- "fammi una pagina di login con validazione email" -- invece di scrivere ogni riga a mano. Detto così, suona come una scorciatoia, e infatti la critica più comune è: "così non capisci più cosa fa il tuo stesso codice". La critica ha un fondo di verità quando il vibe coding viene usato senza verifica -- si genera, si guarda che "sembri giusto", si va avanti. Quello non è vibe coding maturo, è delega cieca con un'estetica nuova.

La versione che funziona davvero sposta dove va l'attenzione umana, non la elimina. Chi scrive software con un agente passa meno tempo a ricordare la sintassi esatta di un framework e più tempo a specificare cosa deve essere vero alla fine: quali test devono passare, quali percorsi non devono essere toccati, quale comportamento esistente non deve rompersi. Il lavoro cognitivo non sparisce -- si sposta dal "come si scrive questo ciclo for" al "cosa significa che questa funzione ha successo", che è esattamente il tipo di domanda che un buon ingegnere si fa comunque, solo che ora deve farla esplicita invece di tenerla in testa.

Questa sessione stessa è un esempio diretto, non un'affermazione teorica: ogni migrazione di pagina da un vecchio sistema a uno nuovo è stata specificata come un contratto -- quali file possono cambiare, quali test devono restare verdi, quale comportamento deve restare identico byte per byte -- e poi verificata indipendentemente da quel contratto, non dalla parola di chi ha scritto il codice. Quando un'esecuzione ha dichiarato "fatto" mentre un test restava rosso, il sistema lo ha rifiutato automaticamente, prima che un umano dovesse accorgersene leggendo il diff a mano.

Questo è il punto centrale che la critica al vibe coding spesso manca: il rischio non è delegare la scrittura del codice, è delegare la verifica insieme alla scrittura. I team che ottengono risultati reali con agenti di codice tengono i due lavori separati -- un agente propone, un meccanismo indipendente (test automatici, un secondo agente, una revisione umana mirata) verifica -- esattamente come un buon processo di code review umano separa chi scrive da chi approva, non perché non ci si fidi della persona, ma perché un secondo paio d'occhi cattura categorie di errore diverse da quelle che l'autore stesso può vedere.

La domanda pratica per chi valuta se adottare questo modo di lavorare non è "l'AI scrive codice migliore di me". È: "il mio processo ha un modo indipendente di verificare che quello che è stato scritto -- da me o da un agente -- fa davvero quello che doveva fare". Se la risposta è sì, il vibe coding è un moltiplicatore di velocità reale. Se la risposta è no, il problema esisteva già prima dell'AI, e l'AI lo rende solo più veloce a manifestarsi.

Un'ultima distinzione che vale la pena fare esplicita: vibe coding non significa "senza codice". Significa codice reale, verificabile, versionato -- generato con l'aiuto di un modello invece che digitato carattere per carattere. La differenza con il "no-code" tradizionale è che qui il risultato resta software vero, ispezionabile, testabile, portabile -- non una configurazione chiusa dentro una piattaforma proprietaria. Questo è il motivo per cui il vibe coding, fatto bene, si integra nei processi di ingegneria esistenti invece di sostituirli con qualcosa di più fragile.