Vibe Coding: cos'è la nuova moda dell’AI che sembra magia… Finché il codice non esplode

Sotto la spinta dell’intelligenza artificiale e dei modelli generativi, il Vibe Coding mira a ridefinire il modo in cui i creatori interagiscono con il codice di programmazione. Questa espressione intrigante (in inglese “vibe” significa “atmosfera”, “sensazione”, “mood”, “energia”), coniata da una figura di spicco nel campo dell’AI, rappresenta un cambiamento fondamentale, spostando l’attenzione dalla sintassi dei linguaggi di sviluppo all’esperienza utente dell’finale e alla visione del prodotto finale.

Le origini del concetto di Vibe Coding

Il termine Vibe Coding è stato introdotto da Andrej Karpathy nel febbraio 2025. Karpathy, una figura estremamente influente nel mondo dei LLM (Large Language Models) e dell’intelligenza artificiale, vanta un curriculum impressionante: ha conseguito un dottorato di ricerca a Stanford, è stato un membro fondatore di OpenAI, ha ricoperto il ruolo di direttore della divisione AI presso Tesla ed è attualmente il fondatore di Eureka Labs. La sua autorità nel campo conferisce un peso significativo alla definizione di Vibe Coding, rapidamente adottata e resa popolare.

Secondo Karpathy, il Vibe Coding è un approccio in cui – quando si sviluppa qualcosa – “si dimentica persino che il codice esista“. In sostanza, si tratta di affidare a un modello linguistico di grandi dimensioni (LLM) il compito di gestire tutti gli aspetti dello sviluppo software. L’obiettivo principale è concentrarsi esclusivamente sul risultato desiderato, sul “vibe” finale del prodotto, senza preoccuparsi del codice sottostante.

Questa prospettiva è ulteriormente rafforzata dalla definizione offerta da Simon Willison, un altro protagonista dello sviluppo dell’IA: “costruire software con un LLM senza rivedere il codice che scrive“.

Entrambe le definizioni sottolineano il disimpegno intenzionale del “programmatore” dalla revisione o dalla comprensione dettagliata del codice generato da parte del LLM. La crescente rilevanza del Vibe Coding è tale che persino il CEO di Google lo ha citato, riconoscendone il potenziale per “dare ai developer un potere che non veniva assegnato loro da almeno 25 anni“.

Il principio fondamentale: il linguaggio naturale come codice

Il Vibe Coding affonda le radici in una trasformazione radicale dell’approccio alla programmazione software. Karpathy sostiene che “il più nuovo e più caldo linguaggio di programmazione non è C, non è Rust, non è JavaScript, non è Python – è l’inglese“. O, più in generale, è la lingua che parliamo. Questo significa che gli sviluppatori non scrivono più linee di codice complesse, ma comunicano le loro intenzioni e desideri al LLM in linguaggio naturale. Abbiamo descritto in dettaglio la visione di Karpathy in un articolo dedicato al Software 3.0.

Il processo è caratterizzato da un’assenza intenzionale di revisione del codice. Quando si pratica il Vibe Coding:

• Si chiedono al LLM anche le modifiche più “stupide”, semplicemente per pigrizia nel trovare e modificare il codice manualmente.
• Si accettano tutte le modifiche proposte dal LLM, senza leggere le differenze (diffs) nel codice.
• Non si cerca di rivedere, esaminare o comprendere il codice che il LLM ha generato.

Invece, l’attenzione è rivolta a ciò che si vuole ottenere, descritto utilizzando il linguaggio naturale. È il LLM a occuparsi di tutte le questioni tecniche a livello di coding. Peccato che coding e programmazione siano cose molto diverse.

Quando il codice diventa opaco

Nell’ingegneria del software esiste un termine per il codice che non si comprende: codice legacy. Si tratta di porzioni di software sviluppate in passato, spesso senza documentazione, test o strutture coerenti. È il classico incubo di chi si trova a doverlo mantenere. La sua comprensione costa tempo, la sua modifica introduce rischi e ogni intervento è un investimento oneroso nel recupero della conoscenza perduta.

Eppure, quando si decide di approvare un qualunque codice di programmazione, bisognerebbe porsi sempre 3 domande:

• Questo codice produce il risultato atteso?
• Sarà comprensibile da chi ci metterà mano tra qualche mese?
• Sarà facilmente modificabile senza introdurre regressioni?

Il Vibe Coding, ovviamente se spinto oltre “il limite”, rischia di generare lo stesso tipo di debito tecnico, ma a una velocità esponenziale. Quando l’AI genera codice che nemmeno il suo utilizzatore comprende, si sta di fatto costruendo un edificio multipiano su fondamenta che nessuno ha esaminato.

Usare il Vibe Coding sì, ma con consapevolezza

Il Vibe Coding si colloca su uno spettro che va dalla totale comprensione alla totale delega. Un ingegnere software che affida all’AI l’implementazione di un modulo specifico, conoscendo bene gli obiettivi e i vincoli, sta usando una dose di “vibing” nettamente inferiore rispetto a un utente inesperto che chiede genericamente un’app “che faccia tutto”.

La differenza sta nella capacità di discernere, di correggere, di esaminare il codice e intervenire con competenza quando qualcosa non funziona.

Affidare un progetto strutturato e a lungo termine a un processo completamente vibe-based, senza competenze tecniche, è pura follia. All’inizio tutto sembra funzionare: si ottengono risultati impressionanti con pochi comandi, si ha l’illusione del controllo e dell’autonomia.

Ma i nodi vengono sempre al pettine: bug inaspettati, strutture caotiche, difficoltà nel debugging e nella scalabilità. E se l’unica risposta possibile è chiedere all’AI di correggere ciò che ha scritto in precedenza, ci si trova in un ciclo di dipendenza pericoloso, dove la qualità degrada e la comprensione del codice evapora.

L’impronta dei LLM è riconoscibile: quando il codice sa di “Vibe Coding”

Lo sviluppatore Alex Kondov ha pubblicato una riflessione per larga parte ampiamente condivisibile.

Osserva che negli ultimi tempi, quando si tratta di programmazione, emergono sempre più spesso dei pattern distintivi. Non si tratta di commenti superflui o dell’abuso di switch-case: questi sono dettagli trascurabili. Il vero segnale rivelatore è più sottile e pervasivo.

Il codice funziona, è leggibile, e può persino apparire manutenibile. Ma è “alieno”. Non parla il linguaggio del team; non rispetta le convenzioni, ignora le astrazioni esistenti e reinventa l’acqua calda quando, ad esempio una libreria consolidata offriva già un’implementazione robusta.

Quando il codice sa di “Vibe Coding”? Spiega Kondov. Quando:

• Implementa un’intera logica di fetch HTTP pur esistendo già una libreria condivisa per quel compito.
• Ridefinisce utility generiche già disponibili in un modulo centrale.
• Modifica la configurazione globale quando ci sono meccanismi per farlo in modo più pulito.
• Crea una classe OOP in un contesto dove tutto è scritto con un paradigma funzionale.
• Genera codice che potrebbe funzionare perfettamente, ma che non è coerente con il sistema in cui deve vivere.

L’approccio professionale: servirsi dell’AI con disciplina

Karpathy stesso suggerisce una metafora utile: l’AI è come uno stagista iper-competente, veloce e creativo, ma anche imprevedibile, presuntuoso e privo di gusto estetico.

Il ruolo dello sviluppatore esperto è quindi quello di controllare, correggere, insegnare. Non delegare ciecamente, ma sfruttare l’AI per accelerare compiti ripetitivi, mantenendo il controllo sulle decisioni architetturali e sulle logiche critiche.

Nel 2025, l’uso dell’AI nella programmazione dovrebbe ruotare attorno a due concetti chiave: lentezza consapevole e apprendimento continuo. In altre parole, essere paranoici quando serve, sfruttare ogni occasione per comprendere, non solo per ottenere un output.

Il punto non è demonizzare l’AI, ma riconoscerne i limiti e le potenzialità. Quando è usata bene, rende la programmazione più efficiente, più accessibile e spesso più divertente. Quando è usata male, genera codice che nessuno vorrà più manutenere.

LLM come ChatGPT, Claude o Gemini sono strumenti straordinari. Come ogni strumento, il loro valore dipende da come li si usa. Non stiamo riscrivendo i principi della buona ingegneria: esistono già. Non bisogna accantonare quei principi, ma anzi trasferirli al LLM in modo esplicito:

• Fornire esempi coerenti.
• Specificare le librerie da usare.
• Descrivere lo stile architetturale del progetto.
• Scrivere prompt più granulari.
• Suddividere il codice in moduli più piccoli.
• Rivedere l’output con occhio critico, come si farebbe con qualsiasi nuovo collega.

Conclusioni: leggere e capire il codice resta fondamentale

In definitiva, il Vibe Coding si è già guadagnato un posto legittimo nel mondo dello sviluppo software, ma non può sostituire l’attività fondamentale della programmazione: costruire modelli mentali, comprendere il problema, strutturare la soluzione.

Finché l’AI non sarà in grado di sviluppare teorie del software come fa un ingegnere, il codice richiederà sempre occhi umani che lo leggano, lo interpretino e lo migliorino. Ed è quello che i pionieri dello sviluppo software ci hanno sempre ricordato e continuano a rammentarci.