Il codice che invecchia in un weekend

Il 2 febbraio 2025 Andrej Karpathy, ex direttore dell’intelligenza artificiale di Tesla e tra i fondatori di OpenAI, scrive un post di poche righe sulla piattaforma X. “C’è un nuovo modo di programmare che chiamerei vibe coding, in cui ti abbandoni alle vibrazioni, abbracci l’esponenziale, e ti dimentichi che il codice esiste”. Il post è scritto col tono dello sfogo ricreativo: Karpathy racconta che parla al suo assistente vocale, accetta tutte le proposte del modello senza leggerle, copia e incolla i messaggi di errore in chat per farli risolvere, e “per la maggior parte funziona”. L’autore chiarisce subito che è un metodo “per progetti del weekend”, definendolo poi lui stesso, mesi dopo, “un tweet butta-via, una doccia di pensieri”.

Il post viene visto quattro milioni e mezzo di volte. Nel novembre dello stesso anno il dizionario britannico Collins lo dichiara Word of the Year. E nel giro di pochi mesi il concetto sfugge agli argini con cui Karpathy lo aveva incorniciato. Ciò che era nato per “progetti buttavia del fine settimana” si trasforma nella narrazione dominante del 2025-26: chiunque, senza saper programmare, può oggi costruire un’applicazione completa parlando in italiano corrente a un modello linguistico. Strumenti come Cursor, Replit Agent, Lovable, Bolt.new, v0 generano interi prodotti software in poche ore. Su LinkedIn si moltiplicano post che mostrano Software-as-a-Service costruiti in un weekend, startup lanciate senza una riga di codice scritta a mano, founder che si vantano di avere “una squadra di sviluppo composta solo dall’AI”.

Il problema, e converrà chiamarlo per nome, è che la maggior parte di quel software è strutturalmente fragile. Non per cattiveria di chi lo costruisce, e nemmeno per immaturità dei modelli, che sono diventati molto buoni. Per la natura della procedura stessa, che è incompatibile con ciò che un sistema software deve garantire per restare in produzione oltre la prima settimana.

Il dato che chi vende vibe coding preferirebbe non si discutesse

Nel luglio 2025 il laboratorio indipendente METR (Model Evaluation & Threat Research) pubblica uno studio condotto con metodologia randomized controlled trial, lo standard d’oro della ricerca scientifica. Sedici sviluppatori open source esperti, mediamente cinque anni e millecinquecento commit sui propri progetti, vengono osservati mentre svolgono duecentoquarantasei attività reali, alcune con l’aiuto degli strumenti di intelligenza artificiale più avanzati del momento, altre senza. Gli stessi sviluppatori, prima dello studio, stimavano che l’AI li avrebbe resi più veloci del ventiquattro per cento. Dopo le sessioni, dichiaravano di esserlo stati del venti per cento. I dati oggettivi raccontano l’opposto: con l’AI sono stati il diciannove per cento più lenti.

Lo studio è stato discusso e in parte ridimensionato dalla stessa METR nel febbraio 2026, che ne ha riconosciuto i limiti di campione e contesto. Vale a dire: si trattava di sviluppatori esperti, su codice maturo che conoscevano a fondo. In un contesto diverso (un’applicazione nuova, una persona non esperta) la cifra può essere diversa. Ma il punto interessante non è il numero. Il punto è il divario di trentanove punti percentuali fra come gli sviluppatori percepivano la propria velocità e quanto effettivamente erano lenti. Se professionisti seri non sanno valutare la propria produttività con l’AI, immaginarsi la quasi totalità dei founder senza formazione tecnica che oggi dichiarano, in piena buona fede, di aver “risparmiato sei mesi di sviluppo” in tre giorni di chat. Quei sei mesi non li hanno risparmiati. Li hanno spostati in avanti, dove non si vedono ancora.

Sicurezza: il problema più sottovalutato

L’ottobre del 2025 è il mese in cui escono, una dietro l’altra, le ricerche che mettono a fuoco la dimensione del problema. Veracode, una delle principali società di analisi della sicurezza del software, pubblica il GenAI Code Security Report: oltre cento modelli linguistici testati su ottanta attività di programmazione reali. Il quarantacinque per cento del codice generato dall’intelligenza artificiale contiene vulnerabilità di sicurezza comprese nella OWASP Top 10, ovvero le dieci categorie di falle più diffuse e meglio note al mondo. Sul Cross-Site Scripting, una delle più antiche, il tasso di fallimento sale all’ottantasei per cento; sul linguaggio Java, al settantadue per cento.

Una società concorrente, Apiiro, conferma la cifra su uno spaccato diverso: il codice scritto con l’AI ha due volte e tre quarti più vulnerabilità del codice scritto a mano, comparato sulle stesse mansioni. La cifra è impressionante per la sua stabilità: si ripete su tutte e quattro le famiglie principali di modelli (OpenAI, Anthropic, Google, xAI), e non migliora con le versioni successive. La sicurezza non è qualcosa che i modelli imparano scalando; è qualcosa che richiede di essere dichiarata esplicitamente nel prompt. E chi non sa programmare non sa nemmeno cosa chiedere.

Cosa significhi nel concreto lo mostrano due casi recenti. Il primo è la Common Vulnerabilities and Exposures numero 2025-48757, che ha coinvolto Lovable, una delle piattaforme di vibe coding più popolari. Lovable generava per default applicazioni che non implementavano la Row Level Security, una protezione di base delle banche dati. Risultato: in oltre centosettanta applicazioni in produzione, un qualsiasi utente autenticato poteva leggere, modificare o cancellare i dati di qualunque altro utente. La falla non era in una singola applicazione; era nel modello che ogni applicazione ereditava per costruzione. Un errore strutturale, replicato in serie.

Il secondo caso lo ha pubblicato la società Tenzai nel dicembre 2025: ha esaminato quindici applicazioni di produzione costruite con cinque dei principali strumenti di vibe coding. Tutte e quindici, senza eccezione, risultavano prive della protezione contro la Cross-Site Request Forgery e degli header di sicurezza minimi. Tutti e cinque gli strumenti, senza eccezione, introducevano vulnerabilità di Server-Side Request Forgery. Un esame ulteriore della società Escape.tech ha analizzato millequattrocento applicazioni vibe-coded: il sessantacinque per cento presentava problemi di sicurezza, il cinquantotto per cento almeno una vulnerabilità critica, e si contavano oltre quattrocento credenziali esposte pubblicamente.

La parte forse più inquietante non è il numero. È la ricerca di Snyk: quasi otto sviluppatori su dieci ritengono che il codice generato dall’AI sia più sicuro di quello scritto a mano. È esattamente il contrario di ciò che mostrano tutti gli studi indipendenti del 2025-26. Lo strumento, semplicemente, induce in chi lo usa un falso senso di sicurezza più potente del giudizio critico.

Il problema che si vede solo al sessantesimo giorno

Una volta scritto, un software vive per anni. Si chiama manutenzione, ed è la parte del ciclo di vita di un sistema su cui si gioca, in pratica, ogni euro del costo totale: nell’industria si stima da decenni che la fase di sviluppo iniziale rappresenti fra il quindici e il venti per cento, la manutenzione fra l’ottanta e l’ottantacinque per cento. È in quella seconda fase che il vibe coding mostra la propria struttura, e non lo fa bene.

Tre debolezze, in particolare, si manifestano quando il codice esce dalla fase di entusiasmo iniziale ed entra nella fase di dovere quotidiano. La prima è che chi non sa leggere il codice non può manutenerlo. Quando l’applicazione produrrà il primo errore in produzione, ed è una questione di settimane più che di mesi, l’autore avrà come unica strategia tornare alla chat e descrivere il sintomo al modello. Se la modifica risolve il sintomo, il problema sottostante è probabilmente rimasto; se non lo risolve, l’autore non ha gli strumenti per capire perché. Si chiama debugging cieco, e nei pochi mesi che separano il lancio dalla resa ufficiale produce una quantità di codice morto che cresce in modo geometrico.

La seconda è che il codice non contiene quasi mai test automatici. I modelli, sollecitati da un prompt che chiede “aggiungimi questa funzionalità”, tendono a non scrivere prove che la verifichino, e chi promuove il prompt non sa che dovrebbe chiederle. Senza test, ogni successiva modifica è un salto nel vuoto: cambiamenti che dovrebbero essere innocui causano regressioni invisibili che il sistema porta con sé fino al successivo incidente. Le software house tradizionali hanno costruito, nell’arco di vent’anni, una cultura del test precisamente perché senza non si manutiene. I vibe coder, in larghissima parte, non sanno neppure di doverla applicare.

La terza è che il modello, sotto, invecchia. Le librerie usate cambiano interfaccia, i fornitori dei modelli pubblicano nuove versioni e ritirano le vecchie, le pratiche di sicurezza considerate accettabili sei mesi fa non lo sono più. Un’applicazione tradizionale ben costruita riesce a sopravvivere a questa erosione perché c’è qualcuno che capisce che cosa sta cedendo e dove. Un’applicazione costruita per vibrazioni si trova a un certo punto, e quel punto arriva sempre, di fronte a un’erosione che non sa come affrontare se non chiedendo al modello di “aggiornarmi tutto”, riscrivendo magari la metà di quello che già funzionava, e portandosi dietro le vulnerabilità nuove al posto di quelle vecchie.

Allucinazioni: il dettaglio che diventa drammatico

Una nota, perché la cosa è meno banale di quanto sembri. I modelli linguistici inventano oggetti che non esistono, come parte costitutiva del proprio funzionamento. In programmazione il fenomeno si chiama package hallucination: il modello suggerisce di importare una libreria con un nome plausibile, che però non esiste nel registro pubblico. Le ricerche del 2025 stimano che circa il venti per cento dei riferimenti a pacchetti software nel codice generato dall’AI puntino a pacchetti inesistenti.

Lo sviluppatore esperto se ne accorge subito: l’importazione fallisce, e il codice viene corretto. Il vibe coder, no: o accetta passivamente la correzione del modello (che spesso reinventa un altro nome plausibile e inesistente), o riceve l’importazione dichiarando “funziona” quando il pacchetto coincidentemente esiste. È qui che si è aperta una nuova classe di attacchi informatici, chiamata slopsquatting: malintenzionati che registrano pacchetti con i nomi che i modelli più spesso “inventano”, riempiendoli di codice malevolo. Il vibe coder che, mesi dopo, ricostruirà la sua applicazione importando in buona fede uno di quei pacchetti, importerà con esso il malware dentro la propria infrastruttura.

Una nota di cautela

Non tutto è da buttare in questa storia, e merita dirlo. Karpathy, nel suo post originale, aveva fatto un’osservazione precisa: il vibe coding è una cosa straordinaria per i prototipi, per quelle decine di applicazioni interne che servono a una persona o a un piccolo gruppo per pochi giorni o poche settimane. Un foglio di calcolo evoluto, un’interfaccia minimale per esplorare dei dati, una pagina che genera un grafico. Per quegli usi il trade-off è onesto: si rinuncia alla manutenibilità in cambio di una velocità altrimenti irraggiungibile. È in questa zona che il vibe coding è una conquista vera.

Esistono anche, e sono presumibilmente in crescita, esperienze ibride dove ingegneri esperti usano gli strumenti di intelligenza artificiale come acceleratori, senza rinunciare al controllo sostanziale del codice. Le ricerche di GitClear suggeriscono che, in quel modo, si producono circa il dieci per cento in più di codice durevole. Quello è augmented coding (Kent Beck) o agentic engineering (Karpathy stesso, nella versione riformulata): non è ciò che si vende sui banchetti del LinkedIn italiano del 2026.

Cosa cambia, allora

Il discrimine non è fra “chi usa l’AI” e “chi non la usa”. È fra chi mantiene il controllo cognitivo sul sistema che sta costruendo e chi lo cede. Un imprenditore di una piccola e media impresa italiana che, oggi, valuta di affidare il sistema gestionale, la Web App interna, l’assistente per i clienti, a un fornitore che si presenta come “esperto in AI” e nei fatti spinge un agente low-code su una piattaforma a contratto, sta firmando un debito tecnico di cui non vedrà il saldo prima di sei mesi.

Quel debito si paga in tre rate. La prima, di solito fra il giorno trenta e il giorno sessanta, è il primo incidente di sicurezza: una credenziale finita per sbaglio in un campo pubblico, una falla che permette l’accesso ad altrui dati, una libreria con vulnerabilità nota che andava aggiornata. La seconda, fra il giorno novanta e il giorno centottanta, è la rigidità: le modifiche che dovevano costare un’ora ne costano due giornate, ogni intervento ne rompe altri due, l’imprenditore comincia a sentire dal fornitore frasi come “bisogna rifare l’architettura”. La terza, fra il primo e il secondo anno, è la riscrittura completa: il sistema viene messo da parte e si ricomincia da capo, questa volta da una software house tradizionale, pagando per intero ciò che si pensava di aver risparmiato.

Le software house italiane lo sanno bene. Tante hanno già visto entrare clienti che, all’inizio del 2025, avevano scelto la via rapida e nel 2026 si presentano col carico di rimettere a posto. Il mercato lo ha già notato: nei profili LinkedIn di centinaia di sviluppatori la qualifica Vibe Code Cleanup Specialist, inizialmente nata come battuta su X, è entrata a far parte dei titoli reali. Si occupano di tornare dentro applicazioni vibe-coded, capirne la struttura, ricostruirne la sicurezza, riscrivere ciò che si può salvare, buttare ciò che non si può.

La sopravvivenza di un software, oggi come venti anni fa, non si decide nella prima settimana. Si decide nel sessantesimo giorno, nel centottantesimo, nel secondo anno. Chi vende, in queste settimane, la promessa di costruire “qualunque software senza saper programmare” non sta vendendo un risparmio. Sta vendendo un’illusione che si pagherà al giorno della prima manutenzione seria. E quando arriverà quel giorno, l’entusiasmo dei post di LinkedIn non sarà di nessun aiuto.

Non è il tempo di una nostalgia per il vecchio software. È il tempo, semmai, di ricordare che cosa lo rendeva durevole. La capacità di chi lo scriveva di sapere che cosa stava facendo, riga per riga. L’intelligenza artificiale, usata bene, può moltiplicare quella capacità. Usata male, la sostituisce con un’illusione di averla. E un’illusione, quando il sistema sta in produzione su clienti veri, non resiste a lungo all’attrito della realtà.