Il vibe coding ha tradito la sua promessa

Passa un’ora in qualsiasi forum di chi costruisce software e troverai la stessa confessione scritta in cento modi diversi. Qualcuno ha costruito la sua app in un fine settimana con uno strumento di IA. Funzionava. L’ha rilasciata. Ora è lunedì, l’autenticazione è rotta, il database perde righe in silenzio e il difetto che nessuno riesce a riprodurre è quello che gli costa clienti.

Il sogno che ci siamo venduti a vicenda sei mesi fa si presenta alla porta a chiedere indietro i soldi.

Voglio essere attento a come lo dico, perché non penso che le persone che hanno costruito o usato questi strumenti abbiano sbagliato a entusiasmarsi. Il salto è stato reale. Guardare un’interfaccia funzionante materializzarsi da un paragrafo di italiano semplice è una delle esperienze davvero magiche dell’ultimo decennio di software. L’ho sentita anch’io. L’abbiamo sentita tutti.

Ma da qualche parte tra la dimostrazione e il rilascio è avvenuta una sostituzione silenziosa. Abbiamo iniziato a chiamare prodotti i prototipi. Abbiamo iniziato a chiamare software le dimostrazioni. E il conto di quella confusione ora è in scadenza.

La diagnosi sbagliata

La spiegazione più comune che vedo per ciò che sta accadendo incolpa il modello. L’IA non è ancora abbastanza intelligente. Allucina. Sceglie le librerie sbagliate. Scrive codice che una persona senior in ingegneria intercetterebbe e riscriverebbe.

Quella spiegazione è consolante perché suggerisce una soluzione già in arrivo. Aspetta sei mesi. Il prossimo modello sarà migliore. Prima o poi il divario si chiude e tutto funziona.

Non ci credo. E non ci credo perché il modo di fallire che continuo a vedere non ha nulla a che fare con quanto sia buono il codice.

Microsoft ha riferito nella presentazione dei risultati del 2025 che circa il 46% di tutto il codice inviato da utenti attivi di GitHub Copilot è ora generato dall’IA. Nello stesso periodo l’azienda di sicurezza applicativa Veracode ha pubblicato una ricerca secondo cui il codice generato dall’IA introduceva vulnerabilità di sicurezza in circa il 45% dei campioni esaminati. Quei numeri peggioreranno prima di migliorare, e un modello più intelligente non li risolverà.

Il modello non è il problema. Il processo lo è.

Cosa manca davvero

Accompagnami nella nascita di un’app fatta col vibe coding e dimmi dove avviene la decisione architetturale.

Descrivi ciò che vuoi. L’IA genera un’interfaccia e un po’ di codice dietro. Guardi l’interfaccia, clicchi in giro, fa più o meno la cosa che hai chiesto, e la dichiari finita. In nessun punto di quel ciclo qualcuno, umano o macchina, si è fermato a definire che cosa si stesse costruendo.

Non c’è uno schema. Non c’è un modello dei dati. Non c’è un elenco degli stati in cui il sistema può trovarsi né una definizione di ciò che conta come valido. Non c’è un contratto tra il frontend e ciò che finge di essere un backend. Non c’è una decisione su cosa succeda quando l’utente fa qualcosa che il generatore non aveva previsto, perché nessuno l’aveva previsto.

Ciò che è stato costruito è una cosa che assomiglia alla cosa che hai chiesto, sul percorso preciso che ti è capitato di percorrere durante la dimostrazione. Esci da quel percorso e l’intera struttura si rivela un’impalcatura. Sotto non c’è mai stato un edificio.

Non è un fallimento dell’intelligenza. È un fallimento della definizione. E nessuna quantità di intelligenza aggiuntiva applicata a un problema non definito produrrà un risultato definito. Produrrà solo una versione più convincente della stessa impalcatura.

Le tre decisioni che non sono mai state prese

Vado nel concreto, perché le astrazioni sono il motivo per cui questa conversazione continua a girare in tondo.

L’autenticazione non è una funzione che aggiungi dopo. È una decisione su chi sono i tuoi utenti, cosa possono vedere e su quale confine di fiducia si trova la tua applicazione. Attaccarla a un’app fatta col vibe coding due settimane dopo il lancio è l’equivalente software di installare una porta d’ingresso in una casa costruita senza pareti.

Lo schema di un database non è qualcosa che un’IA dovrebbe indovinare mentre genera il modulo che ci scrive sopra. Lo schema è la spina dorsale dell’applicazione. Ogni decisione a valle (cosa puoi interrogare, cosa puoi indicizzare, cosa puoi cambiare dopo senza rompere tutto) è vincolata da scelte prese, o non prese, all’inizio. Quando lo schema è improvvisato, ogni cambiamento futuro è una ristrutturazione.

Un contratto di API non è opzionale, e in un’economia in cui gli agenti di IA consumano il software direttamente è più vicino al prodotto di quanto lo sia l’interfaccia. Nel momento in cui la tua app parla con qualcos’altro (un gestore di pagamenti, un servizio di posta, un altro pezzo di software, un agente di IA) deve esistere una superficie definita. Senza, le integrazioni diventano una serie di rattoppi una tantum che nessuno può mantenere e nessuno vuole ereditare.

Non sono argomenti avanzati. Sono il minimo per costruire software che viva più del suo primo fine settimana. E sono esattamente le cose che si saltano quando tutto il processo di costruzione è descrivi, guarda, rilascia.

Il problema del 70% ora ha un nome

Non penso che qualcuno si sia messo a costruire un settore che rilascia software fragile. Penso che gli strumenti nati in questa categoria abbiano ottimizzato il momento che vende lo strumento: il momento magico in cui un’idea diventa una schermata funzionante in meno di un minuto.

Il tempo fino alla magia è diventato la cosa misurabile. Il tempo fino alla produzione era il problema di qualcun altro.

È un’ottimizzazione ragionevole per una dimostrazione. È un’ottimizzazione terribile per una categoria di software ora responsabile di rilasciare applicazioni vere a utenti veri con soldi veri in gioco. Lascia un’intera generazione di costruttori bloccata al 90%, con una cosa che funziona sul loro schermo e si sfalda in ogni altro posto.

Chi costruisce nella comunità di Lovable ha dato un nome a questo: il problema del 70%. Arrivi a qualcosa che sembra quasi finito, e poi il progresso si ferma. Ogni correzione rompe qualcos’altro. Il lavoro che resta non è lavoro che puoi attraversare con i prompt, perché ciò che ti blocca non è codice mancante. È una decisione mancante, presa in silenzio, diverse centinaia di generazioni prima.

Il segreto sporco di questa categoria è che la parte facile era il primo 90%. Il 9% successivo, far funzionare la cosa davvero per più di un utente, su più di un dispositivo, in condizioni che non avevi previsto, è più difficile del primo 90% messo insieme. E l’ultimo 1%, la parte che distingue un’applicazione funzionante da una fragile, è la parte che richiede che tu sapessi cosa stavi costruendo prima di iniziare.

La regola che l’IA non ha cambiato

Ecco la cosa che nessuno vuole sentire, perché suona come un passo indietro in un momento che dovrebbe essere tutto avanzamento.

Il software migliore è sempre partito da una definizione. Architettura prima del codice. Un modello chiaro del problema prima che venga scritta una riga. Era vero quando squadre di cinquanta persone costruivano sistemi a mano, ed è vero ora che una persona e un modello possono costruire lo stesso sistema in un fine settimana.

L’IA non ha cambiato quella regola. L’IA l’ha resa più importante, non meno.

Quando il costo di produrre codice si avvicina a zero, anche il costo di produrre il codice sbagliato si avvicina a zero. Il che significa che l’unica cosa che ancora costa è capire quale sarebbe stato il codice giusto. Quel lavoro (il lavoro di definizione, il lavoro di architettura, la parte in cui decidi cosa stai davvero costruendo prima di iniziare a costruirlo) è l’unica parte che non è diventata merce indifferenziata.

È anche la parte che l’attuale generazione di strumenti ha saltato.

Dove porta tutto questo

Non penso che la risposta sia rallentare. Non penso che la risposta sia tornare a scrivere tutto a mano. Il salto è stato reale, e il salto resta.

La risposta è costruire il passo di definizione dentro il ciclo, la pratica che il settore ora chiama sviluppo guidato dalle specifiche. Non come cancello manuale che ti rallenta, ma come fondamento reale su cui poggia il resto del lavoro. Le persone che stanno capendo come farlo lavorano su qualcosa di più silenzioso di ciò che hai visto finora. Stanno per far apparire la versione rumorosa di questa categoria per ciò che è sempre stata. Su come è fatta davvero quella prossima generazione ho scritto a parte.

Una schermata funzionante non è mai stata la stessa cosa di un sistema funzionante. Stiamo tutti per ricordarci perché.

Letture collegate

Cosa ha preso il suo posto: lo sviluppo guidato dalle specifiche. Come si collocano oggi gli strumenti: i migliori costruttori di app con IA nel 2026.

Domande frequenti

Che cosa significa «vibe coding»? Vibe coding significa scrivere software descrivendo ciò che si vuole in linguaggio comune e accettando ciò che l’IA genera, senza specificare l’architettura, il modello dei dati o i contratti sottostanti. Andrej Karpathy ha coniato il termine all’inizio del 2025. Descrive un modo di lavorare, non una categoria di strumenti: si può fare vibe coding in quasi qualsiasi costruttore con IA.

Perché le app fatte col vibe coding si rompono in produzione? Perché il guasto è strutturale, non un problema di qualità del codice. Il ciclo di generazione non produce mai uno schema, un insieme definito di stati validi o un contratto tra frontend e backend. L’applicazione funziona sul percorso su cui è stata mostrata e si sfalda fuori da quello. Un modello più intelligente applicato a un problema non definito produce comunque un risultato non definito.

Che cos’è il problema del 70%? È lo schema in cui un’applicazione costruita dall’IA raggiunge circa il 70% di completamento e poi smette di avanzare: ogni correzione rompe qualcos’altro e nessuna quantità di prompt aggiuntivi chiude il divario. L’ostacolo è di solito una decisione architetturale presa implicitamente centinaia di generazioni prima e che non si può più cambiare senza una riscrittura.

Il codice generato dall’IA è meno sicuro? Le prove attuali dicono che ha bisogno di revisione. La ricerca di Veracode ha trovato che il codice generato dall’IA introduceva vulnerabilità di sicurezza in circa il 45% dei campioni esaminati, in un momento in cui Microsoft riferiva che circa il 46% del codice inviato dagli utenti attivi di Copilot era generato dall’IA. Il volume cresce più in fretta della verifica.

Questo significa che i costruttori di app con IA non vanno usati? No. Per prototipi, dimostrazioni e strumenti interni sono davvero eccellenti e la velocità è reale. L’argomento qui è più stretto: una schermata funzionante non è un sistema funzionante, e gli strumenti che saltano la fase di definizione non possono produrre il secondo, per quanto buono diventi il modello.