Un Anno di Vibe Coding

Il 2 febbraio 2025 — esattamente un anno fa — Andrej Karpathy pubblicava un tweet che avrebbe cambiato il vocabolario del nostro settore.

Karpathy non è uno qualunque. Co-fondatore di OpenAI, ex capo dell'AI a Tesla, uno che ha contribuito a definire il deep learning moderno. Quando parla, il settore ascolta.

Quel tweet ha superato i 4.5 milioni di visualizzazioni. Collins Dictionary ha eletto "vibe coding" parola dell'anno 2025. E da quel momento, tutto è cambiato — nel bene e nel male.

Cosa Diceva Davvero Karpathy

Il tweet originale merita una lettura attenta, perché quello che Karpathy intendeva e quello che "vibe coding" è diventato sono due cose diverse.

Karpathy descriveva il suo workflow:

• Parlava con Cursor usando SuperWhisper (voice-to-text)
• Chiedeva "cose stupide" tipo "diminuisci il padding della sidebar della metà" perché troppo pigro per cercare il file
• Faceva "Accept All" sempre, senza leggere le diff
• Quando c'erano errori, copiava e incollava il messaggio senza commenti — "di solito si sistema"
• Il codice cresceva "oltre la mia normale comprensione"
• A volte l'LLM non riusciva a fixare un bug, quindi "chiedevo cambiamenti random finché non spariva"

E poi la frase chiave: "It's not too bad for throwaway weekend projects."

Progetti del weekend. Da buttare. Non produzione. Non sistemi critici. Weekend projects.

Questa distinzione si è persa quasi subito.

Il Caso Pieter Levels: $87.000 in 17 Giorni

Un mese dopo il tweet di Karpathy, un imprenditore olandese di nome Pieter Levels decise di testare il vibe coding sul serio.

Levels non aveva esperienza di game development. Zero. Ma aveva Cursor e un'idea: un simulatore di volo 3D nel browser.

Tre ore dopo, flypieter.net era online. Un MMO funzionante. Nel browser. Fatto "parlando" con un'AI.

La monetizzazione fu geniale nella sua semplicità:

• F-16 acquistabile a $29.99
• Spazi pubblicitari su dirigibili virtuali nel cielo di gioco

Dopo 10 giorni: $38.000 di revenue mensile. Dopo 17 giorni: $87.000 MRR. Un milione di dollari annualizzato.

Elon Musk ne parlò. Patrick Collison (CEO di Stripe) anche. Il caso finì su tutti i giornali tech.

Levels lanciò il "Vibe Coding Game Jam" — una competizione dove il codice doveva essere scritto almeno all'80% da AI. Oltre 1.000 giochi furono sottomessi.

Il messaggio sembrava chiaro: il vibe coding funziona. Puoi fare soldi. Puoi creare prodotti reali senza sapere programmare.

Ma c'era un dettaglio che molti ignorarono: Levels è un imprenditore seriale con anni di esperienza nel lanciare prodotti. PhotoAI, InteriorAI, NomadList — tutti suoi. Sapeva cosa costruire, per chi, e come monetizzare.

Il vibe coding gli ha dato velocità. Ma la direzione era sua.

Un Anno di Curva di Apprendimento

Come ogni strumento nuovo e potente, il vibe coding ha richiesto — e sta ancora richiedendo — una curva di apprendimento. I numeri dell'ultimo anno raccontano questa fase di rodaggio.

I Numeri della Curva di Apprendimento

Alcuni studi hanno mostrato che il codice prodotto con assistenti AI contiene il 41% di bug in più rispetto al codice scritto manualmente. Un altro ha riportato una riduzione di produttività del 19% per alcuni team.

Numeri preoccupanti? Solo se li leggi fuori contesto.

Questi dati non dicono "l'AI coding non funziona". Dicono che usare uno strumento nuovo senza criterio produce risultati peggiori. Non è diverso da quando arrivarono gli IDE: chi li usava male era più lento di chi scriveva in Notepad.

Il problema non è lo strumento. È il processo.

Casi Studio: Cosa Succede Senza Review

Nel maggio 2025, su 1.645 applicazioni create con Lovable, 170 avevano vulnerabilità basilari — falle che qualsiasi developer avrebbe individuato con una review.

L'app Tea Dating Advice, costruita interamente con vibe coding, fu hackerata. Il codice "funzionava". Ma nessuno aveva verificato la sicurezza.

Questi non sono fallimenti del vibe coding. Sono fallimenti di processo. In entrambi i casi, mancava lo stesso elemento: qualcuno che leggesse il codice prima di metterlo in produzione.

Lo stesso Karpathy aveva detto chiaramente: "throwaway weekend projects". Progetti da buttare. Non produzione.

La Lezione

Il pattern è chiaro: chi tratta il vibe coding come "magia che fa tutto da sola" ottiene risultati scarsi. Chi lo tratta come uno strumento potente che richiede supervisione ottiene risultati straordinari.

Non è diverso da qualsiasi altra tecnologia. L'automobile non ha eliminato gli incidenti — ha richiesto che imparassimo a guidare. L'AI coding non elimina i bug — richiede che impariamo a fare review.

E questa è una competenza che si può imparare

La Distinzione che Conta

La differenza tra chi usa il vibe coding con successo e chi produce disastri sta in una parola: review.

Vibe coding "puro" (come descritto da Karpathy):

• Parli all'AI
• Accetti tutto senza leggere
• Se funziona, funziona
• Perfetto per: "throwaway weekend projects"

Agent coding con human in the loop:

• L'AI genera
• Tu leggi e capisci
• Tu validi la logica
• Tu correggi gli errori
• Solo dopo fai commit

La differenza non è nello strumento. È nel processo. E il processo si impara.

Pieter Levels ha fatto soldi con flypieter.net perché sapeva cosa voleva costruire, per chi, e perché. L'AI gli ha dato velocità. Ma le decisioni — e la review — erano sue.

Chi ha creato app vulnerabili non ha fallito perché ha usato l'AI. Ha fallito perché ha saltato un passaggio: verificare cosa l'AI aveva prodotto. Un passaggio che, con la pratica, diventa naturale come controllare gli specchietti prima di cambiare corsia.

Chi lo Usa Bene, Chi No

La domanda "dove funziona il vibe coding?" è mal posta. La domanda giusta è: chi lo sa usare?

Non è una distinzione tra tecnici e non tecnici. Ho visto developer con 15 anni di esperienza produrre disastri con l'AI coding — accettavano tutto senza leggere, convinti che "tanto il codice è generato bene". E ho visto persone senza background tecnico costruire prodotti solidi — perché avevano imparato a validare, a testare, a chiedere "perché hai fatto così?".

Chi lo usa male:

• Accetta tutto senza leggere
• Non testa mai manualmente
• Pensa che l'AI "sappia cosa fare"
• Copia-incolla errori sperando si sistemino
• Non capisce cosa ha in mano

Chi lo usa bene:

• Legge il codice generato (anche velocemente)
• Testa il comportamento, non solo se "funziona"
• Guida l'agente con contesto e vincoli chiari
• Riconosce quando l'output è sbagliato
• Sa quando fermarsi e chiedere aiuto

La competenza tecnica aiuta? Certo. Chi conosce i pattern riconosce più facilmente quando l'AI ha fatto una scelta sbagliata. Ma non è sufficiente — e non è nemmeno necessaria per iniziare.

Quello che serve è un mindset: l'AI è un collaboratore da supervisionare, non un oracolo da seguire ciecamente.

E questo mindset si impara. Sia che tu venga da 20 anni di codice, sia che tu abbia aperto un IDE per la prima volta ieri.

La Vera Lezione dell'Anno

Il vibe coding è nato con una promessa implicita: le persone non-tech possono finalmente creare software.

Ed è vero — in parte. Lovable, Replit, Bolt, v0: questi tool permettono a chi non ha mai scritto una riga di codice di costruire qualcosa di funzionante. Per progetti piccoli, per MVP, per validare un'idea. È straordinario.

Ma la lezione più interessante che ho imparato quest'anno è un'altra.

Il vero valore del vibe coding non sta nel compensare la mancanza di competenze tecniche. Su progetti complessi, la capacità tecnica resta fondamentale — e lo sarà ancora per molto.

Il vero game changer è un altro: poter guidare gli agenti da una prospettiva di prodotto.

Fino a ieri, tradurre una visione di prodotto in codice richiedeva un passaggio obbligato: spiegare a uno sviluppatore cosa volevi, sperare che capisse, iterare. Oppure essere tu stesso uno sviluppatore.

Oggi puoi sederti davanti a un agente e dire: "Voglio che l'utente possa fare X, e quando lo fa deve succedere Y". Non devi sapere come implementarlo. Devi sapere cosa vuoi.

Non è la stessa cosa di "non servono competenze". È una competenza diversa: saper guidare, saper descrivere, saper validare. Capire quando l'agente ha fatto la cosa giusta e quando no.

Il product manager che capisce il dominio può ora iterare direttamente sul prodotto. Il founder con la visione può tradurla in prototipo senza intermediari. Il designer può testare interazioni reali invece di mockup statici.

Questo non elimina il bisogno di sviluppatori. Lo trasforma. Lo sposta più in alto nello stack. Ma apre una porta che prima era chiusa.

Chi sa guidare un prodotto — non solo tecnicamente, ma dal punto di vista dell'esperienza utente, del valore, del mercato — ha ora uno strumento potentissimo.

La capacità di "vibeare" non è l'assenza di competenza. È una competenza nuova: saper dialogare con l'AI per costruire ciò che hai in testa.

Il Mio Take

Programmo da quando avevo 11 anni. Ho visto framework nascere e morire, linguaggi diventare cool e poi dimenticati, paradigmi promessi come rivoluzionari e poi abbandonati.

Il vibe coding non è una rivoluzione. È un tool. Come il debugger, come il version control, come l'IDE. Potente se usato bene, pericoloso se usato male.

Karpathy l'ha detto chiaro nel tweet originale: "throwaway weekend projects". Progetti da buttare. Non produzione.

Il problema è che il messaggio si è perso. "L'AI scrive codice per te" è diventato "non serve più saper programmare". E questo è falso. Pericolosamente falso.

L'AI moltiplica. Se sai cosa stai facendo, moltiplica la tua produttività. Se non sai cosa stai facendo, moltiplica i tuoi errori.

Pieter Levels ha fatto $87.000 in 17 giorni non perché "l'AI è magica". L'ha fatto perché in 3 ore ha costruito qualcosa che la gente voleva, l'ha monetizzato in modo intelligente, e l'ha promosso a un pubblico di milioni di follower che aveva costruito in anni di lavoro.

L'AI gli ha dato velocità. Il resto era già suo.

Un Anno Dopo

Il 2 febbraio 2026. Un anno esatto dal tweet.

Cosa abbiamo imparato?

1. L'AI coding funziona — e funziona bene, se sai usarlo
2. La review è la chiave — il passaggio che separa i successi dai disastri
3. È una competenza nuova — saper guidare, descrivere, validare: si impara
4. Il ruolo cambia — da "scrivo tutto io" a "guido e verifico"
5. La prospettiva di prodotto conta — chi sa cosa costruire ha un vantaggio enorme

Karpathy ha coniato un termine per descrivere come programmava i suoi progetti del weekend. Il settore l'ha adottato. Poi l'ha frainteso, pensando che significasse "non serve più capire il codice".

Ma la verità è più interessante: serve capire il codice in modo diverso. Non devi più scrivere ogni riga — devi sapere leggere, validare, guidare.

È una competenza nuova. Come imparare a guidare l'automobile invece che cavalcare. Diversa, non più facile.

Un anno fa Karpathy ha descritto un nuovo modo di programmare.

Un anno dopo, sappiamo che funziona — e stiamo imparando a farlo bene.

Happy birthday, vibe coding. Il secondo anno sarà ancora meglio.