Vibe coding: cos'è, quando nasce il termine e quali rischi comporta

Descrivere il risultato, non le istruzioni

Programmare, tradizionalmente, significa scrivere istruzioni precise che una macchina esegue passo per passo: righe di codice in un linguaggio come quello descritto nell’articolo sul codice PHP, pensate e verificate da chi le scrive. Il vibe coding ribalta questo schema: invece di scrivere il codice, lo si descrive. Si dice a un modello di intelligenza artificiale cosa si vuole ottenere — “aggiungi un pulsante che esporta i dati in PDF”, “riduci lo spazio a sinistra della barra laterale” — e si lascia che sia il modello a tradurre quella richiesta in codice funzionante, spesso eseguendolo subito.

Il tratto distintivo, nella definizione originaria del termine, non è tanto l’uso di un’IA per scrivere codice — pratica diventata comune tra il 2025 e il 2026 — quanto la rinuncia a controllarlo. Chi fa vibe coding accetta le modifiche proposte dal modello senza rileggere i “diff”, cioè il confronto riga per riga tra la versione precedente e quella nuova del codice. Si valuta il risultato che si vede a schermo, non il modo in cui ci si è arrivati.

Vibe coding contro AI-assisted coding classico

Non tutto l’uso dell’intelligenza artificiale nella programmazione è vibe coding. Da anni esistono strumenti come GitHub Copilot, che suggeriscono righe o funzioni mentre si scrive, o chatbot generalisti usati per sbloccare un problema puntuale: questo è ciò che MIT Technology Review chiama “AI-assisted coding” classico, e la differenza rispetto al vibe coding sta soprattutto nel controllo che resta a chi programma.

Esempio pratico: uno sviluppatore che usa Copilot per completare una funzione già progettata, e poi ne controlla la logica riga per riga, fa AI-assisted coding classico. Uno sviluppatore che dice a voce “aggiungi un carrello con sconto automatico sopra i 50 euro” e accetta il codice che compare senza verificarlo, fidandosi del fatto che l’app sembra funzionare, fa vibe coding secondo la definizione originaria del termine.

Da un tweet a parola dell’anno

Il termine nasce da un post pubblicato su X (Twitter) da Andrej Karpathy, cofondatore di OpenAI ed ex direttore dell’intelligenza artificiale di Tesla, il 2 febbraio 2025. Karpathy raccontava di programmare affidandosi quasi interamente a un assistente IA integrato in un editor di codice, dettando persino le richieste a voce con un’app di trascrizione. Come scrisse lui stesso, “I don’t read the diffs anymore” — non leggo più i diff. Il post ha superato i 4,5 milioni di visualizzazioni secondo fonti secondarie convergenti, e un anno dopo lo stesso Karpathy lo ha definito un pensiero buttato lì di getto, dicendo di non riuscire a prevedere quali dei suoi post avrebbero avuto tanto seguito.

Da lì il termine si è diffuso rapidamente: entro pochi mesi comparivano articoli, guide e discussioni sul tema, fino a un riconoscimento che di solito arriva dopo anni, non mesi. Il 6 novembre 2025 Collins Dictionary lo ha eletto Parola dell’Anno 2025, definendolo “l’uso dell’intelligenza artificiale, sollecitata in linguaggio naturale, per scrivere codice informatico”. Nella stessa lista di parole IA selezionate da Collins per il 2025 comparivano anche “clanker” e “broligarchy”; nello stesso periodo Merriam-Webster ha scelto invece “slop” come propria parola dell’anno, a segnalare quanto il tema dei contenuti generati dall’IA fosse centrale nel dibattito pubblico di quei mesi.

Chi ne trae vantaggio, e chi rischia di più

Secondo Tobin South, ricercatore del MIT Media Lab, il vibe coding avvantaggia soprattutto due profili agli estremi opposti: programmatori esperti, capaci di riconoscere e correggere in fretta un errore generato dall’IA, e principianti assoluti che hanno un’idea precisa di cosa vogliono costruire ma non saprebbero tradurla in codice da soli. Il dossier non dice esplicitamente chi ci guadagni meno, ma si può ipotizzare che sia proprio chi sta ancora imparando a programmare: la comprensione del codice, che è anche il modo in cui si impara a scrivere codice migliore, viene qui delegata quasi per intero al modello. Il ragionamento alla base di questi sistemi è lo stesso che permette a un modello di riconoscere schemi in enormi quantità di dati, come racconta l’articolo sul machine learning, e che alimenta più in generale l’intelligenza artificiale generativa capace di produrre testi, immagini o codice a partire da un’istruzione in linguaggio naturale.

I rischi documentati: quando “funziona” non vuol dire “sicuro”

Uno dei rischi più discussi dagli studi di settore riguarda proprio la mancanza di revisione umana. Un dato colpisce più degli altri: nel benchmark SusVibes della Carnegie Mellon University, condotto su 200 compiti costruiti su 108 progetti open source in Python, il 61% del codice generato da un agente IA basato su Claude Sonnet 4 superava i test funzionali, ma solo il 10,5% superava anche la revisione di sicurezza. In pratica, su dieci funzionalità che sembrano funzionare, circa nove portano con sé almeno una vulnerabilità sfruttabile.

Non è un caso isolato. Test di Veracode su oltre 100 modelli linguistici hanno rilevato che il 45% dei compiti di sviluppo affidati a un’IA introduce almeno una vulnerabilità di sicurezza, spesso riconducibile alle categorie della classifica OWASP Top 10, lo standard di riferimento sulle falle più comuni nelle applicazioni web. La Cloud Security Alliance segnala inoltre un altro tipo di rischio, meno visibile ma diffuso: le fughe di credenziali. Nel 2025 sono stati individuati su GitHub 28,65 milioni di segreti — chiavi API, password, token di accesso — inseriti per errore nel codice pubblicato, il 34% in più rispetto all’anno precedente, l’aumento più marcato mai registrato in un solo anno. Tra i fattori citati per questo salto ci sono probabilmente anche i ritmi più rapidi con cui l’IA permette di scrivere e pubblicare codice, anche se attribuire l’intero aumento al solo vibe coding sarebbe una semplificazione: il fenomeno riguarda più in generale l’uso crescente di strumenti IA nello sviluppo software.

Sono comparse anche classi di attacco che non hanno un vero equivalente nel codice scritto interamente da programmatori umani. Lo “slopsquatting”, per esempio, sfrutta il fatto che i modelli IA a volte raccomandano nomi di pacchetti software inesistenti, “allucinati” durante la generazione: su un campione di 576.000 casi analizzati dalla Cloud Security Alliance, il 20% conteneva pacchetti inventati. Chi attacca registra quei nomi su repository pubblici come npm o PyPI, in attesa che qualcuno li installi per errore, portandosi in casa del codice malevolo.

Il paradosso tra fiducia e qualità

I dati raccolti dalla Cloud Security Alliance descrivono anche un divario tra quanto gli sviluppatori si fidano di questi strumenti e quanto, nella pratica, funzionano bene. Il 91% degli sviluppatori intervistati usa strumenti di codifica IA, e circa il 22% del codice unito ai progetti è scritto dall’intelligenza artificiale. Nello stesso periodo, però, la fiducia degli sviluppatori nell’accuratezza dell’IA è scesa dal 40% al 29% anno su anno, e il 66% dichiara di passare più tempo a correggere codice generato dall’IA che sembra quasi giusto, ma non lo è — un segnale che più uso di questi strumenti non è andato di pari passo con più fiducia nella loro affidabilità reale. Su un terreno collegato, chi si occupa di normare l’uso dell’intelligenza artificiale — come racconta l’articolo sull’AI Act, il regolamento europeo sull’IA — guarda con attenzione crescente proprio ai sistemi che possono incidere su sicurezza e dati delle persone, categoria in cui rientrano anche le applicazioni costruite interamente con il vibe coding e messe in produzione senza controlli aggiuntivi.