Vibe coding: cosa significa davvero il movimento nato dal tweet di Karpathy

Il 2 febbraio 2025 Andrej Karpathy pubblica un tweet che nel giro di poche settimane diventa un hashtag, una moda e un fronte di guerra culturale nel mondo del software. La frase chiave suona piu’ o meno cosi’: il vibe coding e’ quando ti abbandoni alle vibes, accetti gli exponentials, dimentichi che il codice esiste. Tre righe, e da li’ parte un movimento che oggi coinvolge milioni di persone che non hanno mai aperto un terminale prima.

Il tweet originale e il suo contesto

Karpathy non e’ un personaggio marginale. Ex OpenAI, ex direttore AI di Tesla, co-fondatore di Eureka Labs, e’ uno dei nomi piu’ ascoltati in ambito deep learning. Quando lancia l’espressione vibe coding non sta scherzando del tutto: descrive un modo di lavorare in cui apre Cursor, chiede al modello quello che vuole ottenere, accetta le modifiche senza rileggerle riga per riga, e va avanti finche’ il risultato non gli piace.

Nel tweet c’e’ un dettaglio spesso dimenticato: Karpathy ammette che il codice prodotto e’ quasi sempre fuori dai suoi standard, che a volte non capisce cosa ha combinato il modello, e che se qualcosa si rompe chiede al modello di ripararlo. E’ una confessione, non un manifesto. Ma e’ stata letta come manifesto.

Cosa significa abbandonarsi alle vibes

Il vibe coding, nella sua forma piu’ pura, ha tre caratteristiche:

• descrivere in linguaggio naturale cosa deve fare il software, non come deve farlo
• accettare le modifiche proposte dall’LLM senza leggere in dettaglio cosa cambia
• iterare a feedback: si prova, non funziona, si dice al modello di sistemare, si ripete

E’ un flusso di lavoro che funziona bene con strumenti come Cursor, Windsurf, Claude Code, e ancora meglio con builder no-code potenziati come Bolt, v0 e Lovable. L’utente non guarda il codice, guarda il risultato nel browser.

Il boom demografico dei non-dev

La cosa interessante e’ cosa e’ successo dopo. Il termine ha attecchito fuori dalla bolla dev. Designer, marketer, product manager, studenti, persone che non avevano mai scritto una riga di codice hanno iniziato a pubblicare app su Product Hunt costruite in un pomeriggio con un prompt e qualche iterazione. Lovable ha dichiarato milioni di progetti generati in pochi mesi. Bolt e v0 hanno numeri simili.

Il vibe coding ha abbassato la barriera di ingresso alla programmazione come non era mai successo prima. Non servono piu’ anni di studio per avere qualcosa che gira. Serve pazienza con i prompt e tolleranza al fatto che il risultato sia fragile.

Le critiche serie, non il gatekeeping

Molte critiche al vibe coding sono gatekeeping travestito da preoccupazione. Il classico “ai miei tempi si studiava” applicato al software. Ma ci sono critiche tecniche che vanno prese sul serio:

• debito tecnico invisibile: il codice prodotto funziona ma e’ spesso disorganizzato, ridondante, pieno di dipendenze non necessarie
• sicurezza: credenziali hardcoded, endpoint esposti, validazione input assente, permessi troppo larghi
• maintenance: chi non ha scritto quel codice e non lo ha mai letto non puo’ ripararlo senza chiedere ancora al modello, e il modello puo’ sbagliare diversamente ogni volta
• scalabilita’: cio’ che regge 10 utenti puo’ crollare a 1000 senza preavviso, e l’autore non ha gli strumenti per capire perche’

Sono problemi reali. Nei primi mesi del 2025 sono comparsi i primi casi pubblici di app vibe-coded con leak di dati, chiavi API in chiaro nel frontend, database esposti. Non e’ colpa della tecnica in se’, e’ colpa del fatto che nessuno ha guardato.

Una posizione equilibrata

Per me la lettura onesta e’ questa: il vibe coding e’ una modalita’ utile, non un sostituto. Funziona benissimo per:

• prototipi da buttare
• tool interni con due utenti
• esplorazione di un’idea prima di decidere se vale la pena costruirla sul serio
• automazioni personali, script una-tantum
• imparare guardando cosa produce il modello e poi studiarlo

Funziona male, o e’ proprio pericoloso, per:

• codice che tocca dati sensibili di altre persone
• sistemi che devono restare in piedi anni
• qualsiasi cosa in cui un bug possa causare perdita di denaro, salute, privacy
• software venduto a clienti che si aspettano supporto

La questione etica

C’e’ un punto che nel dibattito viene spesso saltato. Se accetti codice che non capisci e lo metti in produzione, a chi rispondi se si rompe o se crea un danno? Non puoi dare la colpa al modello. Il modello non e’ responsabile legalmente di nulla. L’autore sei tu, anche se non hai scritto una virgola.

E’ una forma di responsabilita’ che il vibe coding mascherato da pratica innocua tende a rimuovere. Finche’ si tratta di un side project per te stesso va benissimo. Quando coinvolgi altre persone, il fatto che tu non abbia letto il codice non ti esonera dalle conseguenze.

Bene o male per il movimento?

La domanda piu’ interessante resta aperta. Il vibe coding ha portato milioni di persone a costruire qualcosa invece di limitarsi a consumare software. E’ un bene, senza troppi dubbi. Molti di quei non-dev passeranno a qualcosa di piu’ serio proprio perche’ hanno assaggiato il piacere di veder funzionare un’idea. Altri resteranno al livello del prototipo e va bene lo stesso.

Il rischio e’ che la narrativa “non serve piu’ saper programmare” venga presa alla lettera, e che aziende inizino a spedire in produzione codice che nessun essere umano ha mai riletto. Non e’ uno scenario teorico. Sta gia’ succedendo.

La domanda da farsi non e’ se il vibe coding sia buono o cattivo. E’ se chi lo pratica sta distinguendo tra esplorazione e produzione, tra giocattolo e sistema, tra codice che vede solo lui e codice che tocca altri. Karpathy quella distinzione, nel tweet, ce l’aveva. Molti epigoni no.