Trappola del vibe coding:perché i progetti AI muoiono

Il vibe coding, cioè costruire software descrivendo a un'AI cosa vuoi senza capire l'architettura sottostante, funziona benissimo per circa tre mesi. Poi ogni nuova funzione rompe quelle vecchie, e la maggior parte dei progetti muore nella trappola del vibe coding. Il problema non è l'AI. È chi prende le decisioni architetturali: nessuno.

Vedo lo stesso ciclo ogni singola settimana. Settimana 1: "Ho costruito il mio MVP SaaS in un weekend, l'AI è magia!" Settimana 4: "Questa settimana ho aggiunto 10 nuove funzioni." Settimana 12: "Si rompe tutto. Ogni nuova funzione ne rompe 3 vecchie. Credo di dover ricostruire da zero." Settimana 16: "Il vibe coding è una bufala. Torno allo sviluppo tradizionale."

Persone intelligenti e capaci. Uno slancio incredibile. Poi un muro così duro che mollano del tutto. Ecco perché, e come essere l'eccezione.

Cos'è il vibe coding?

Il vibe coding è chiedere a un'AI di costruire funzioni senza prendere tu alcuna decisione architetturale. "Costruiscimi una dashboard utente." Pubblica. "Ora aggiungi i team." Pubblica. "Aggiungi la fatturazione." Pubblica. Ogni prompt funziona. Ogni funzione compare. Non hai mai deciso come sono strutturati i dati, come funzionano i permessi o come si collega il resto.

E l'esperienza iniziale è inebriante per ragioni reali: codice funzionante in minuti invece che in giorni, nessuna curva di apprendimento, progressi tangibili da mostrare agli altri. La dopamina è vera. Le funzioni funzionano davvero.

Finché non funzionano più. Perché ecco la verità scomoda: il vibe coding sembra produttivo perché confondi l'attività con il progresso. Rilasciare funzioni è attività. Costruire un'architettura che sopravviva all'impatto con la funzione numero 20 è progresso.

La trappola del vibe coding: il precipizio dei 3 mesi in cui muoiono i progetti AI

Il collasso segue una sequenza meccanica prevedibile:

Settimane 1–4: la luna di miele. Costruisci funzioni isolate. Ognuna funziona da sola, perché ancora nulla è collegato. L'AI genera codice ragionevole perché ogni prompt è semplice e autonomo.

Settimane 5–8: le crepe. Le nuove funzioni ora interagiscono con le vecchie, e l'AI non ricorda le decisioni architetturali prese quattro settimane prima. Sessioni diverse fanno scelte diverse. A volte collega i dati correttamente con le chiavi esterne; a volte li duplica. Un giorno scopri che il nome dell'utente è salvato in cinque tabelle diverse. Lo cambi in un posto, e negli altri quattro resta vecchio.

Settimane 9–12: la spirale mortale. Ogni nuova funzione eredita le incoerenze, aggiunge le proprie ipotesi e rompe qualcosa che funzionava. Chiedi: "Correggi il bug per cui i nomi utente non si aggiornano ovunque." L'AI risponde: "Aggiornerò i 6 punti in cui salviamo i nomi utente." Chiedi perché sono sei. Si offre di consolidarli, ma così si romperebbero 15 funzioni. Game over.

Il cortocircuito che inganna le persone: l'AI è davvero eccellente nel generare codice corretto per funzioni isolate. Non è brava a ricordare le decisioni da una sessione all'altra, a individuare conflitti con gli schemi esistenti o a fare scelte architetturali strategiche. E risponde con totale sicurezza in entrambi i casi: "per semplicità, consiglio di denormalizzare qui" suona intelligente, e non sai distinguere un buon consiglio da uno cattivo se non capisci l'architettura.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

L'architetto sei tu. L'AI è il costruttore.

È il cambio di paradigma che cambia tutto. Non "l'AI è il mio sviluppatore e io il product manager". Non "programmiamo insieme da soci". Tu progetti. L'AI costruisce.

Pensa a costruire una casa. L'architetto decide le fondamenta, i muri portanti, dove passano gli impianti: decisioni che non si cambiano una volta partiti i lavori. Il costruttore esegue quel progetto con vera abilità, ma non lo crea. Dì a un costruttore "costruiscimi una casa" senza progetto e otterrai qualcosa che sta in piedi, finché non vorrai un secondo piano e scoprirai che le fondamenta non lo reggono.

Nel software, le decisioni dell'architetto sono tue: quali entità esistono e come si relazionano, se il sistema è multi-tenant, come si applicano i permessi, cosa viene normalizzato, quali schemi segue ogni servizio. Il compito dell'AI è l'esecuzione: i componenti, il boilerplate, le migrazioni che implementano il tuo schema esattamente.

E parte del lavoro è opporsi. Quando l'AI dice "per semplicità, salviamo il nome dell'utente anche nella tabella degli ordini", no, normalizza. Quando dice "per le prestazioni, denormalizziamo", mostrami prima il problema di prestazioni. Quando suggerisce una soluzione rapida, niente scorciatoie: cerca la causa radice. L'AI ottimizza per avere codice funzionante in fretta. A te serve codice di produzione che non venga mai ricostruito.

L'alternativa che parte dall'architettura (con le prove)

Non ho sviluppato questo approccio perché sono furbo. L'ho sviluppato perché non avevo scelta. Dopo aver perso tutto in un'avventura fallita, stavo ricostruendo da casa dei miei genitori: i miei genitori di 83 anni mi pagavano l'abbonamento a Claude perché io non potevo permettermelo. Avevo mesi di autonomia finanziaria, non anni. Se avessi fatto vibe coding e sbattuto contro il muro al mese 3, non ci sarebbe stato un secondo tentativo.

Così, prima di scrivere una sola riga di UI, ho passato 2 settimane a progettare l'intero schema del database di FIKR Space: ogni relazione mappata, multi-tenancy su ogni tabella dal primo giorno, sicurezza a livello di riga applicata nel database, oltre il 90% dei dati normalizzato su un'unica fonte di verità. Poi ho dato all'AI quel progetto e le ho fatto costruire, combattendo ogni giorno quando suggeriva scorciatoie.

Il risultato dopo 11 mesi: 8–12 prodotti integrati, pronti per la produzione, zero riscritture. Una volta solide le fondamenta, le funzioni volavano: un sistema OKR completo in 3 giorni, la gestione della cap table in 4. Quando le persone lo provavano, la domanda era sempre la stessa: "Come hai fatto a costruire tutto questo da solo?" Il preventivo tradizionale per quella piattaforma è di 10–15 sviluppatori per 2 anni: 1,6–2,4 milioni di € di soli stipendi di sviluppo, facilmente oltre 2 milioni di € a costo pieno. A me è costato meno di 3.250 € nel primo anno. (L'analisi completa dei costi dello stack è un post a parte.)

La scelta che hai davanti è semplice da enunciare: veloce adesso e lento dopo, o lento adesso e veloce per sempre. Il vibe coding rilascia 20 funzioni nel mese 1, poi passa il mese 3 a correggere ciò che il mese 1 ha costruito. Chi parte dall'architettura spende 2 settimane sul progetto, poi rilascia funzioni che continuano a funzionare.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Come capisco se sto facendo vibe coding?

I segnali d'allarme: hai chiesto all'AI di correggere lo stesso bug più di 3 volte, non sai spiegare a qualcun altro lo schema del tuo database, gli stessi dati sembrano salvati in modo diverso in funzioni diverse, eviti di aggiungere funzioni perché non sai cosa romperanno, oppure pensi in silenzio di "ricominciare da zero". Con tre o più di questi segnali stai andando verso il precipizio.

Il vibe coding va mai bene?

Sì, per prototipi e app semplici che sei disposto a buttare. Gli strumenti nati per il solo prompting sono ottimi per MVP veloci. La trappola scatta quando un prototipo usa e getta diventa in silenzio il prodotto, e le decisioni architetturali del mese 3 non le ha prese nessuno.

Posso salvare un progetto fatto in vibe coding o devo ricostruirlo?

Di solito puoi salvarlo. Ferma lo sviluppo di funzioni per qualche giorno, mappa ogni tabella e come si collegano, individua dove i dati sono duplicati, progetta lo schema che quelle entità avrebbero dovuto avere, poi migra: consolida i duplicati, aggiungi le chiavi esterne mancanti, aggiungi l'ambito per tenant, abilita la sicurezza a livello di riga. Sembra lento. Ma è di mesi più veloce della riscrittura verso cui altrimenti vai.

Devo imparare a programmare per essere l'architetto?

No, ma devi imparare i fondamenti di come si incastrano i sistemi: entità, relazioni, unica fonte di verità, permessi. Quelle decisioni le prendi tu; l'AI scrive l'implementazione. È una competenza che si impara in settimane, ed è la differenza tra un progetto che muore al mese 3 e uno che si accumula nel tempo. Se ci stai costruendo la tua uscita dall'azienda, comincia misurando quanto ne hai bisogno, poi costruiscila su fondamenta vere.