Che cos'è il Vibe Coding, davvero?

Il termine "vibe coding" si è diffuso velocemente nel 2024-2025 perché nomina qualcosa che molti sviluppatori stavano già facendo in silenzio: descrivere quello che vogliono in inglese semplice a un modello come GPT-4, Claude, o uno strumento come Cursor o GitHub Copilot, e lasciare che generi la maggior parte del codice vero. Il programmatore rimane nel loop, ma il loop assomiglia a qualcosa di diverso dal coding tradizionale.

La definizione effettiva

Andrej Karpathy ha coniato la frase, descrivendo un workflow dove "ti abbandoni completamente alle vibes" — fai un prompt, accetti i suggerimenti, esegui il codice, vedi cosa si rompe, e fai un prompt di nuovo. Non stai leggendo ogni diff riga per riga. Stai navigando per outcome: l'app fa quello che deve, il test passa, la pagina si renderizza correttamente. La skill cambia da scrivere sintassi a descrivere l'intento chiaramente e riconoscere quando l'output è sbagliato.

Questo è diverso dal semplice usare l'autocomplete. I suggerimenti inline nello stile di Copilot assumono ancora che tu stia scrivendo la funzione tu stesso con un po' di aiuto nel completare le righe. Vibe coding assume che il modello scriva la funzione, il file, a volte l'intera feature, e tu stia revisionando e redirigendo invece di scrivere da zero.

Come appare una sessione reale

Un loop di vibe-coding tipico con uno strumento come Cursor o la modalità Agent di Replit è più o meno così:

1. Prompt: "Aggiungi un rate limiter a questa API Express, 100 richieste per 15 minuti per IP, ritorna 429 con un corpo d'errore JSON."
2. Il modello modifica middleware/rateLimit.js, lo collega a app.js, magari importa express-rate-limit.
3. Esegui npm test o colpisci l'endpoint con curl in loop per verificare che il 429 si attivi davvero.
4. Qualcosa non va — il limiter si resetta a ogni deploy perché è in-memory. Lo dici.
5. Il modello sostituisce con uno store backed da Redis, aggiunge la dipendenza ioredis, aggiorna il file docker-compose.
6. Riesegui i test, funziona, fai il commit.

Nessuna riga di quel middleware è stata digitata a mano. Ma sei o sette decisioni di giudizio sono state prese da un umano: quale dovrebbe essere il limite, che lo storage in-memory era sbagliato per production, che il file docker-compose aveva bisogno di aggiornamenti anche lui.

Dove funziona bene

Vibe coding è forte per lavoro pieno di boilerplate: endpoint CRUD, validazione form, test scaffolding, file di config, glue code tra due API che conosci già. È anche buono per il prototyping — creare un demo funzionante di un'idea in un'ora invece di un giorno, poi decidere se vale la pena costruirla propriamente.

È genuinamente veloce per developer single e piccoli team che spediscono strumenti interni o MVP dove il costo di un bug è basso e la velocità di iterazione conta più della purezza architetturale.

Dove si rompe

Il modo di fallire di cui la gente non parla abbastanza: i modelli producono codice che funziona ma è sottilmente sbagliato in modi che non emergono fino a dopo. Una query SQL generata potrebbe funzionare per il happy path ma essere vulnerabile a injection perché la concatenazione di stringhe sembrava a posto al modello. Un check di auth generato potrebbe passare i test ma saltare un role check su una route. Se non stai leggendo il codice, non lo catturerai — vedrai solo i test passare e lo shipperai.

Questo conta più nel codice sensibile alla sicurezza che in quasi qualsiasi altro posto. Simon Willison e altri hanno sottolineato che i progetti vibe-coded con dati utente reali hanno bisogno della stessa rigorosità di review di qualsiasi altro codice, presumibilmente ancora di più, perché la persona che l'ha "scritto" potrebbe non essere in grado di spiegare cosa fa riga per riga.

Sistemi complessi con un sacco di stato implicito — concurrency, transazioni distribuite, qualsiasi cosa con bug di timing sottili — sono anche una cattiva scelta. I modelli tendono a generare codice plausibile per questi casi che fallisce in modi difficili da debuggare precisamente perché nessuno, umano o modello, ha completamente modellato i casi limite da principio.

La skill che conta veramente adesso

Se stai facendo vibe coding, la skill preziosa non è la velocità di digitazione, è la specificazione. I prompt vaghi ottengono codice vago e buggy. Prompt specifici — con nomi esatti di librerie, aspettative di error-handling, e casi limite evidenziati — ottengono output molto migliore. La seconda skill più preziosa è leggere il codice abbastanza velocemente da cattare cosa è sbagliato, il che significa che hai ancora bisogno di capire il linguaggio e il dominio anche se non stai digitando ogni carattere.

Tratta il codice generato da AI come tratteresti una pull request da un junior dev che è veloce ma occasionalmente troppo sicuro di sé: utile, spesso corretto, ma vale una review vera prima che tocchi production.

Vuoi approfondire di più su come scrivere codice con tool AI senza perdere il controllo della qualità? Dai un'occhiata ai segmenti AI e Python di Korra Studio per walkthroughs hands-on.