Il “vibe coding” promette di rendere tutti programmatori, ma sta già producendo vari problemi: database cancellati, credenziali esposte, architetture impossibili da mantenere. E intanto, i maintainer dell’open source chiudono i progetti perché sommersi da contributi AI inutilizzabili. Forse è il caso di capire cosa sta davvero succedendo.
Indice degli argomenti
“Accetto tutto, non leggo più le differenze“: anatomia di una resa
Il 2 febbraio 2025, Andrej Karpathy — cofondatore di OpenAI, già responsabile AI di Tesla, una delle menti più riconosciute nel campo dell’intelligenza artificiale — pubblica un post su X che diventerà virale in poche ore. Scrive di un nuovo modo di programmare che chiama “vibe coding“: ci si affida completamente al modello linguistico. La traduzione, quasi automatica: si accettano tutte le modifiche senza leggere le differenze nel codice, si copiano e incollano i messaggi di errore sperando che il sistema si aggiusti da solo. “Il codice cresce oltre la mia comprensione abituale”, ammette. “Non sto davvero programmando: vedo cose, dico cose, eseguo cose, e più o meno funziona.”
Il termine entra nel dizionario Merriam-Webster come neologismo nel giro di un mese. Ma c’è un dettaglio che spesso viene trascurato nel racconto entusiasta: lo stesso Karpathy specifica che si tratta di un approccio adatto a “progetti usa e getta del weekend“, mentre appare decisamente più prudente quando si parla di sistemi di produzione. Una precisazione che, nei mesi successivi, verrà ignorata da un numero fin troppo alto di persone.
A un anno esatto da quel post, nel febbraio 2026, Karpathy stesso sembra prendere le distanze dal termine che ha coniato. Propone di parlare piuttosto di “agentic engineering“: un approccio in cui il programmatore non scrive direttamente il codice ma orchestra agenti AI che lo fanno, mantenendo però supervisione e responsabilità sulla qualità. Il fatto che l’inventore della formula si sia sentito in dovere di ridefinirla dice molto su ciò che è successo nel frattempo.
I numeri del vibe coding che fanno impressione
Nel marzo 2025, durante una conversazione pubblicata su YouTube, Jared Friedman, managing partner di Y Combinator, rivela un dato che fa il giro del mondo: il 25% delle startup dell’ultimo batch, il Winter 2025, ha il 95% del proprio codice generato da intelligenza artificiale. Non si tratta di fondatori improvvisati: sono tutti tecnici di alto livello, perfettamente in grado di scrivere codice da zero. Semplicemente, non lo fanno più.
Il dato è spettacolare e viene letto, comprensibilmente, come la conferma di una rivoluzione. Ma accanto a questo numero ne esiste un altro, meno celebrato e decisamente più inquietante: il 2025 GenAI Code Security Report di Veracode, che ha analizzato il codice prodotto da oltre 100 modelli linguistici su 80 task reali di programmazione, ha riscontrato che nel 45% dei casi il codice generato conteneva vulnerabilità di sicurezza allineate alla OWASP Top 10, ovvero le criticità più gravi nel mondo delle applicazioni web. Java si è rivelato il linguaggio più rischioso, con un tasso di fallimento nella sicurezza superiore al 70%. Le difese contro il cross-site scripting hanno fallito nell’86% dei campioni, quelle contro il log injection nell’88%.
Il dato più preoccupante, però, è ancora un altro: questa performance di sicurezza non migliora nel tempo. I modelli diventano sempre più bravi a scrivere codice sintatticamente corretto, ma non sembrano diventare più bravi a scriverlo in modo sicuro. Come ha osservato Jens Wessling, CTO di Veracode: “Con il vibe coding, le decisioni sulla sicurezza vengono di fatto delegate ai modelli linguistici. E i modelli sbagliano quasi la metà delle volte.”
Ricerche indipendenti confermano il quadro. Secondo un’analisi di Apiiro su aziende Fortune 50, il codice generato da AI mostra 2,74 volte più vulnerabilità rispetto a quello scritto da umani, un aumento del 40% nell’esposizione di credenziali sensibili, e un incremento del 322% nei percorsi di escalation dei privilegi. Non sono numeri da laboratorio: sono dati estratti da codebase reali, di aziende reali, con utenti reali.
Le catastrofi del vibe coding già viste in produzione
I numeri diventano ancora più eloquenti quando si guarda ai casi concreti. Quello più emblematico riguarda la piattaforma Replit e un episodio che ha fatto scuola. Jason Lemkin, fondatore di SaaStr, aveva affidato a un agente AI di Replit la costruzione di un’applicazione di produzione. Le prime fasi erano state entusiasmanti: prototipi in poche ore, progressi rapidi. Poi, l’agente AI — ignorando un’istruzione esplicita di blocco delle modifiche in produzione — ha cancellato l’intero database di produzione. Mesi di dati persi in un istante. “Non si sovrascrive un database di produzione. Mai, in nessun caso”, ha commentato Lemkin.
Non è un caso isolato. Un ricercatore di sicurezza ha scoperto che oltre 170 applicazioni costruite con la piattaforma Lovable avevano i database completamente esposti: nessuna policy di sicurezza a livello di riga sui database Supabase. Chiunque avesse la chiave anonima pubblica poteva accedere a tutti i dati degli utenti. Il pattern è sempre lo stesso: l’AI genera codice che funziona dal punto di vista logico, ma non implementa le protezioni di sicurezza a meno che non vengano esplicitamente richieste.
Sono esattamente il tipo di errori che un modello linguistico — addestrato su milioni di repository pubblici in cui queste pratiche sono comuni — tende a riprodurre come “normali”.
Il vibe coding e il debito tecnico che cresce in silenzio
Se le vulnerabilità di sicurezza sono il danno immediato, il debito tecnico è quello che si accumula in silenzio. E qui i dati sono altrettanto significativi.
GitClear, azienda specializzata in analytics per lo sviluppo software, ha analizzato 211 milioni di righe di codice modificate tra il 2020 e il 2024, provenienti da repository di Google, Microsoft, Meta e altre grandi aziende. I risultati disegnano un quadro preoccupante. La duplicazione del codice è aumentata di otto volte in due anni. Per la prima volta nella storia delle metriche di sviluppo, le righe copiate e incollate hanno superato quelle “mosse” — cioè il codice riorganizzato e riutilizzato secondo le buone pratiche di ingegneria del software. Il refactoring, che nel 2021 rappresentava il 25% delle modifiche al codice, è sceso sotto il 10%.
L’insieme di questi fenomeni ha oramai un nome: “illusione di correttezza“. Il codice generato dall’AI è ordinato, ben formattato, scritto con variabili dal nome sensato e documentazione apparentemente solida. Appare corretto e spesso lo è nel singolo passaggio di processo (senza magari tener conto dell’architettura complessiva). Questo aspetto estetico — la pulizia superficiale — tende a disattivare il senso critico del revisore, creando una falsa sensazione di sicurezza.
Quando il vibe coding pesa sull’open source
Mentre il vibe coding trasforma il modo in cui il software viene scritto, un effetto collaterale meno visibile ma non meno grave sta erodendo le fondamenta dell’ecosistema open source.
Daniel Stenberg, creatore e principale sviluppatore di curl — uno degli strumenti software più utilizzati al mondo — ha chiuso il proprio programma di bug bounty dopo essere stato sommerso da segnalazioni generate da AI. Nel 2025, meno del 5% dei report ricevuti era legittimo. “Le submission di spazzatura senza fine hanno un peso mentale serio da gestire, e talvolta richiedono molto tempo per essere smentite”, ha scritto Stenberg. “Tempo ed energia completamente sprecati, che minano anche la nostra voglia di andare avanti.”
D’altronde, se prima un progetto open source popolare riceveva due o tre segnalazioni a settimana, oggi alcuni ne ricevono centinaia in un colpo solo. Christopher Robinson, CTO della Open Source Security Foundation, stima che ognuna di queste richieda al maintainer — quasi sempre un volontario — dalle due alle otto ore di lavoro non retribuito per essere valutata e, nella maggior parte dei casi, respinta.
Come ha osservato un’analisi su InfoWorld, il problema è l’asimmetria radicale dell’economia della revisione: un utente impiega 60 secondi per far generare a un agente una correzione su una dozzina di file. Un maintainer impiega un’ora per verificare che quelle modifiche non rompano nulla. Quando centinaia di contributori usano il proprio assistente AI personale, il risultato non è un progetto migliore ma un maintainer che si arrende.
La domanda scomoda: chi capisce davvero ciò che funziona?
Al netto dei rischi di sicurezza, del debito tecnico e della pressione sull’open source, c’è una questione più profonda che il vibe coding pone. È una questione che ha a che fare non tanto con il software, quanto con la comprensione.
Programmare, nella sua essenza, non è mai stato soltanto scrivere istruzioni per una macchina. È un atto di comprensione: del problema, della logica, delle implicazioni di ogni scelta. È un modo di pensare strutturato che insegna — o dovrebbe insegnare — a scomporre la complessità, a prevedere le conseguenze, a distinguere ciò che sembra funzionare da ciò che funziona davvero.
Il vibe coding inverte questo processo. Non parte dalla comprensione per arrivare al codice; parte dal codice per accettare il risultato. “Accept All“, accetta tutto: non è solo un pulsante in un’interfaccia, è un atteggiamento mentale. E quando diventa la norma, ciò che si perde non è la capacità di scrivere codice — quella, paradossalmente, sta diventando meno necessaria — ma la capacità di capire cosa quel codice fa, perché lo fa e cosa potrebbe andare storto.
Oltre il vibe coding: velocità, responsabilità e qualità
Armando Solar-Lezama, professore al MIT, ha usato una metafora che coglie bene il punto: l’AI è come una nuova carta di credito che ci permette di accumulare debito tecnico in modi che prima non erano possibili. È la stessa dinamica del credito al consumo: la facilità di accesso non elimina il costo, lo rende solo invisibile fino al momento in cui arriva il conto. È, tra l’altro, un modo per assumersi un po’ meno responsabilità.
Il gatto è già fuori dal sacco: il 92% degli sviluppatori statunitensi usa strumenti AI nel proprio flusso di lavoro, secondo il sondaggio GitHub 2025. Le piattaforme di vibe coding proliferano e i non-programmatori costruiscono applicazioni in un weekend e le mettono in produzione il lunedì.
Per tutte queste ragioni, l’impegno per “bloccare” questi strumenti sarebbe oramai un voler contenere l’oceano in un’insalatiera: piuttosto inutile e, probabilmente, insensato.
L’AI applicata alla programmazione è uno degli sviluppi più significativi dell’ultimo decennio, con un potenziale enorme in termini di accessibilità e di efficienza per chi sa usarla con cognizione. Ma il fatto che uno strumento sia potente non significa che sia innocuo, e il fatto che il codice funzioni non significa che sia sicuro, manutenibile o comprensibile.
Ancora una volta, come accade molto spesso quando si parla delle tecnologie contemporanee e future, la lezione più importante del vibe coding non riguarda la tecnologia, ma noi. Riguarda la nostra tendenza — profondamente umana — a scambiare la velocità per qualità, l’apparenza per sostanza, il funzionamento immediato per la solidità nel tempo. In un’epoca in cui produrre è diventato banale, ciò che resta davvero difficile è capire: questo, come ormai abbiamo detto molte volte (e forse mai abbastanza), non vale la pena di essere delegato.
