Due parole sul vibe coding (dedicato agli “sviluppatori per caso”)

Ok, parliamo un po’ del cosiddetto “vibe coding” prima che qualcuno ci faccia un corso da 497 euro con tanto di “certificato” in PDF (o che qualcun altro si faccia molto, ma molto male).

Partiamo da un fatto vero, perché qui non stiamo a raccontare leggende metropolitane da bar dell’informatica (l’equivalente tecnologico del bar dello sport, se non si fosse capito). Luglio 2025, piattaforma Replit: un agente IA, durante un cosiddetto “code freeze” — cioè proprio nel momento in cui qualcuno gli aveva detto “fermo tutto, non toccare niente” — decide di cancellare un database di produzione. Dentro c’erano i dati di oltre milleduecento aziende. Poi, per buona misura, l’agente genera pure un po’ di utenti finti, presumibilmente per coprire le tracce (lui, mica noi, lo giuriamo). Quando gli viene chiesto di renderne conto, l’agente stesso scrive testualmente che “si è trattato di un fallimento catastrofico”. Il CEO dell’azienda conferma su X, sostanzialmente dicendo “sì, è successo, e non sarebbe dovuto accadere”.

Tenete da parte questo aneddoto, ci torniamo alla fine.

La parola che doveva rimanere “per il weekend”

Il termine “vibe coding” lo ha coniato Andrej Karpathy, uno che di intelligenza artificiale un paio di cose le sa (ha lavorato su Tesla Autopilot e OpenAI, mica parliamo del solito “cugino smanettone”). A febbraio 2025 lo descrive così: ti abbandoni completamente alle sensazioni, accetti tutto quello che il modello propone, e a un certo punto smetti perfino di leggere le modifiche. Il dettaglio delizioso è che Karpathy lo intendeva per i progetti del weekend, quelli usa-e-getta, non esattamente per il gestionale per lo studio del commercialista di vostro zio.

Indovinate un po’? Un anno dopo lo stesso Karpathy si è visto costretto a coniare un secondo termine, “agentic engineering”, per separare la disciplina seria da quella che lui stesso aveva battezzato un anno prima. L’autore del peccato originale che scrive la propria penitenza: se non è ironia questa.

Simon Willison, uno che Django lo ha co-creato (quindi diciamo che il codice lo sa riconoscere), traccia il confine in modo chirurgico: se un modello scrive ogni riga ma tu la rivedi, la testi e la capisci, quello non è vibe coding, piuttosto è un assistente di battitura molto sveglio. Il vibe coding vero comincia quando smetti di farti queste domande.

Tre modi di chiacchierare con una macchina

Qui apriamo una parentesi tecnica, perché non tutti i “vibe coder” sono uguali, e la distinzione conta, eccome. C’è chi apre una scheda del browser su un chatbot qualsiasi, descrive l’idea, copia il codice e lo lancia in locale: la versione “facile”, la chiamano così le guide stesse. C’è chi lavora dentro un editor con assistenza IA integrata: un gradino sopra. E c’è chi usa un agente autonomo che legge i file veri, li modifica, esegue comandi, fa girare i test: il gradino “agentico”, appunto, quello che oggi i reclutatori più smaliziati considerano lo standard, tanto che c’è chi liquida l’opzione “preferisco ChatGPT in una scheda del browser” come comportamento ormai datato.

Vi racconto un dettaglio che trovo davvero simpatico. Un tizio ha “vibe-codato” un’intera applicazione usando solo ChatGPT, niente editor, niente agente. Per tenere insieme i pezzi quando un bug coinvolgeva due componenti, doveva incollare manualmente entrambi nel prompt — sue parole, più o meno nella falsariga: “non stiamo mica usando Cursor, qui si vibe-coda solo con ChatGPT!”. Alla fine, chiedendo il file di documentazione finale nella stessa identica chat usata per tutto il progetto, si chiede candidamente se il modello si ricordasse davvero tutto quello che avevano costruito insieme. Risposta sua: non ne ha la più pallida idea. Ecco, questa incertezza non è un dettaglio buffo da raccontare agli amici: è la condizione strutturale di chi sviluppa così. Il chatbot puro non vede mai i vostri file reali sul disco, non esegue mai il codice, non sa se compila. Vede solo quello che gli incollate, quando ve ne ricordate.

Il pensionato nostalgico e il neofita ebbro di novità

Permettetemi di tracciare due “ritratti”, costruiti non su un singolo caso ma sulle scenari ricorrenti che si leggono ovunque, da Reddit a Hacker News ai blog di settore — quindi tipologie, non persone reali con nome e cognome.

Primo ritratto: il programmatore al tramonto. Ha scritto codice negli anni d’oro, poi ha lasciato la tastiera per la carriera, la famiglia, la vita. Oggi ritrova nella chat con l’IA la stessa euforia di allora, ma con un surplus di fiducia che è quasi commovente: “io ero un programmatore” diventa il salvacondotto per saltare la verifica, perché la competenza di vent’anni fa viene scambiata, senza neanche accorgersene, per competenza di oggi. Peccato che nel frattempo siano cambiati lo stack, le pratiche di sicurezza, e perfino il concetto stesso di “produzione”.

Secondo ritratto: il neofita “inebriato”. Non ha mai scritto una riga di codice in vita sua e scopre, per la prima volta, l’ebbrezza di vedere un’interfaccia che risponde ai suoi comandi — un’app che esiste davvero, generata partendo dal nulla. Il rischio qui è speculare e opposto: zero anticorpi, nessun istinto per riconoscere quando qualcosa “puzza”, perché non c’è mai stato nulla da cui generalizzare un sospetto.

Il bello (si fa per dire) è che, partendo da biografie agli antipodi, entrambi approdano allo stesso identico gradino della scaletta di prima — la chat nel browser — e allo stesso identico punto cieco: la convinzione di avere tutto sotto controllo, per ragioni completamente diverse.

Il conto che arriva senza far rumore

Qui entriamo nel cuore della faccenda. Addy Osmani, che di ingegneria del software vive (lavora su Chrome, mica fa il “divulgatore” come il sottoscritto), ha coniato un’espressione che meriterebbe di entrare nei manuali: “debito di comprensione”. Non è il classico debito tecnico, quello che almeno si vede e si sente puzzare. Il debito di comprensione è subdolo: genera falsa fiducia. Il codice sembra pulito, i test sono verdi, e il conto arriva in silenzio, di solito proprio nel momento peggiore.

Un sondaggio su ottocento professionisti nordamericani (Clutch, giugno 2025) ha trovato che il 59% degli sviluppatori usa abitualmente codice IA che non comprende fino in fondo. E naturalmente in questo caso non sto parlando di “hobbisti della domenica”, parlo di gente che lo fa per mestiere, ottanta volte su cento più volte alla settimana.

Il labirinto senza filo di Arianna

E qui arriva la parte che, da ex direttore di rivista, mi fa più tenerezza e più tristezza insieme: il debugging che si “atrofizza”. Uno studio randomizzato su programmatori junior ha trovato un calo del 17% nella capacità di comprendere e correggere gli errori in chi usava sistematicamente l’IA. Il meccanismo è banale quanto crudele: se l’IA corregge sempre lei, non costruisci mai l’istinto che si forma incontrando, diagnosticando e risolvendo i problemi con le proprie mani.

Stephan Schmidt, quarantacinque anni di programmazione sulle spalle (quindi non uno che ha scoperto il terminale l’altro ieri), descrive il fenomeno dei “doom loop”: il modello sbaglia, prova a correggersi, peggiora la situazione, si arrovella, e finisce esattamente dove era partito — talvolta cancellando tutto e dichiarando, con la sua “faccia di bronzo digitale”, che il lavoro è completo. La sua conclusione, che condivido parola per parola: chi giura di non esserci mai finito, in un doom loop, o è stato fortunatissimo, o sta mentendo spudoratamente.

L’ultimo trenta per cento, quello vero

C’è una statistica non ufficiale ma confermata da chiunque abbia provato sul serio: l’IA vi porta al settanta per cento di un’app funzionante con una velocità imbarazzante. Il problema è che l’ultimo trenta per cento — autenticazione vera, gestione dei pagamenti, validazione dei dati, misure di sicurezza, tutti quei dettagli che nessuno “fotografa per Instagram” — è proprio la parte più difficile, e diventa quasi impossibile da affrontare senza una conoscenza ingegneristica profonda. Lo stesso Karpathy, parlando a un evento di Sequoia all’inizio di quest’anno, ha distinto due cose: il vibe coding “alza il livello” (chiunque può costruire qualcosa), l’agentic engineering “preserva l’asticella” (la qualità resta quella di prima). Sono due obiettivi diversi, e confonderli è la fonte di metà dei guai di cui stiamo parlando.

Quando le macerie hanno un nome e cognome

Passiamo ai fatti concreti, perché qui non vogliamo fare gli allarmisti senza prove. Un report Veracode del 2025, su oltre ottanta task di codifica e più di cento modelli linguistici, ha trovato che il codice generato dall’IA introduce vulnerabilità di sicurezza nel 45% dei casi. Il CTO dell’azienda lo dice senza troppi giri di parole: l’ascesa del vibe coding rappresenta un cambiamento di fondo nel modo in cui costruiamo software, e non necessariamente in meglio.

E non dobbiamo dimenticareil cosiddetto “affare Moltbook”, un social network “vibe-codato” e violato entro tre giorni dal lancio: gennaio 2026, i ricercatori di sicurezza trovano un database privo della protezione di base sui permessi, ed esposti finiscono un milione e mezzo di token di autenticazione e trentacinquemila indirizzi email, oltre ai messaggi privati. Praticamente ogni account era dirottabile con una singola chiamata API. Per la cronaca, non era stato costruito da un chatbot nel browser: era stato costruito con strumenti agentici di tutto rispetto. Il che ci mette di fronte a una cosa piuttosto scomoda: il gradino “migliore” della scaletta di cui sopra non è automaticamente quello sicuro, è solo quello che fallisce in modo diverso.

Il paradosso della velocità che non c’è

E adesso il colpo di scena che preferisco, perché smonta anche la fiducia di chi pensava di essere immune. METR, un’organizzazione di ricerca seria, ha condotto uno studio randomizzato su sedici sviluppatori esperti — non principianti, gente con anni di mestiere su codebase che conosceva a menadito — assegnando loro compiti reali. Prima del test, prevedevano un risparmio di tempo del 24% grazie all’IA. Dopo aver finito, erano convinti di aver risparmiato comunque circa il 20%. La realtà misurata? Erano stati il 19% più lenti. Non lo dico per cattiveria: lo dico perché se può succedere a programmatori navigati su codice che conoscevano da anni, il “io ero bravo prima, quindi sono al sicuro” del nostro primo ritratto non regge granché.

Quindi, che si fa?

Non vi sto dicendo di chiudere il cassetto (in cui stavate conservando il vostro sogno digitale) e buttare via la chiave. Vi sto dicendo che tra l’idea tenuta lì dentro per dieci anni e un’app che qualcuno paga sul serio, c’è una soglia, e quella soglia ha un nome: disciplina, non talento. Willison ha una regola che varrebbe la pena incorniciare: non si mette in produzione una riga di codice che non si saprebbe spiegare a qualcun altro. Aggiungeteci una buona dose di test scritti prima del codice (sì, il vecchio TDD, quello che sembrava roba da boomer fino a ieri), la revisione di ogni singola modifica con lo stesso rigore che usereste su un collega umano, e qualche prompt esplicito sulla sicurezza invece di lasciare che il modello indovini.

E qui torniamo a Replit, al database cancellato durante il “fermo tutto”. Non era un “chatbot del weekend” a fare danni: era un agente di livello professionale, usato da gente che sapeva benissimo cosa stava facendo. Se può succedere a loro, la domanda da farsi prima di pubblicare la propria creatura dal cassetto non è “L’IA è abbastanza brava?”.

La domanda vera è: “Capisco abbastanza quello che ha scritto da sé?”.

Buon coding, e, mi raccomando, leggete i diff!

Ah, dimenticavo, qualche tempo fa ho tradotto per Hoepli questi due manuali sull’argomento, nel caso foste interessati:

Fonti utili per chi vorrà approfondire i vari aspetti:

https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure

https://incidentdatabase.ai/entities/replit

Replit quando quattro righe di codice fanno più danni di mille hacker e l’AI diventa il tuo peggior stagista

We saw Jason’s post. @Replit agent in development deleted data from the production database. Unacceptable and should never be possible.

– Working around the weekend, we started rolling out automatic DB dev/prod separation to prevent this categorically. Staging environments in… pic.twitter.com/oMvupLDake
— Amjad Masad (@amasad) July 20, 2025