MVP con l'AI: i quattro errori più comuni dei founder e come evitarli

Costruire un MVP con l'intelligenza artificiale oggi richiede giorni, a volte ore. Strumenti come Lovable, Replit o Cursor permettono a un founder di arrivare a una demo funzionante senza un team tecnico. La velocità però ha un costo che spesso non si vede subito. Questa guida, pensata per i founder early-stage dell'ecosistema milanese, raccoglie i quattro errori più comuni. Per ognuno spiega come riconoscerlo e come evitarlo. I primi due sono documentati da ricerche recenti di Veracode, METR, GitClear e Cloud Security Alliance. Gli altri due sono errori di metodo.

Perché il tema riguarda chi fonda oggi

Il termine "vibe coding" è stato coniato da Andrej Karpathy a febbraio 2025. Secondo Wikipedia, Karpathy lo pensava per prototipi o progetti "da buttare" nel weekend. Nel frattempo l'uso si è allargato. A marzo 2025 Y Combinator ha riportato che il 25% delle startup del batch Winter 2025 aveva codice generato al 95% dall'AI (dato di TechCrunch citato da Wikipedia). Il problema non è usare l'AI. Il problema è trattare un prototipo da weekend come un prodotto pronto per clienti veri.

Errore 1: un prodotto che sembra finito ma non regge

Cosa dicono i dati

Il 2026 GenAI Code Security Report di Veracode indica che circa il 44% delle attività di generazione di codice con AI ha introdotto una vulnerabilità di sicurezza rischiosa. Il tasso medio di superamento dei test di sicurezza è del 56%, quasi uguale al 55% del primo report. Secondo Veracode, codice che compila, gira e sembra pulito può comunque contenere falle sfruttabili.

Lo Spring 2026 Update aggiunge un dettaglio utile. La sintassi corretta supera il 95%, ma la sicurezza resta ferma a circa il 55%, quando non si danno istruzioni esplicite sulla sicurezza. I risultati variano molto per tipo di falla: SQL injection evitata nell'82% dei casi, crittografia insicura nell'86%, ma cross-site scripting solo nel 15% e log injection nel 13%.

I dati sulle app in produzione vanno nella stessa direzione. La Cloud Security Alliance riporta che Escape.tech ha analizzato oltre 1.400 app "vibe-coded": il 65% aveva problemi di sicurezza e il 58% almeno una vulnerabilità critica. Sono stati trovati oltre 400 segreti esposti e 175 casi di dati personali esposti. Un altro studio citato dalla CSA ha contato 69 vulnerabilità su 15 app generate con 5 strumenti AI: nessuna aveva protezione CSRF né header di sicurezza.

Ci sono anche casi concreti. A maggio 2025, in 170 delle 1.645 web app create con Lovable chiunque poteva accedere ai dati personali. A luglio 2025 l'agente AI di Replit ha cancellato il database del fondatore di SaaStr, nonostante l'ordine esplicito di non toccare nulla.

Come riconoscerlo

• La demo funziona perfettamente, ma nessuno ha mai fatto un test di sicurezza.
• Le chiavi API sono scritte direttamente nel codice.
• I permessi degli utenti sono controllati solo nell'interfaccia e non lato server.
• L'agente AI ha accesso diretto al database di produzione.

Come evitarlo

• Dare all'AI istruzioni esplicite sulla sicurezza: il dato di Veracode vale proprio quando mancano.
• Usare scansioni automatiche del codice a ogni modifica.
• Prevedere una revisione umana su autenticazione, permessi delle API e logica di business, dove secondo la CSA si trovano le falle più gravi.
• Non dare agli agenti AI accesso diretto al database di produzione.

Errore 2: il debito tecnico invisibile

Il debito tecnico è il costo futuro delle scorciatoie prese oggi. Con l'AI cresce in silenzio. GitClear ha analizzato 211 milioni di righe modificate tra il 2020 e il 2024. Il refactoring, cioè la riorganizzazione del codice esistente, è sceso dal 25% delle righe modificate nel 2021 a meno del 10% nel 2024. La duplicazione è cresciuta di circa 4 volte. Per la prima volta in vent'anni il codice copia-incollato ha superato quello riorganizzato. Il codice riscritto poco dopo il merge è quasi raddoppiato. LeadDev riporta inoltre che nel 2024 i blocchi duplicati di 5 o più righe erano 8 volte più frequenti.

C'è anche un problema di percezione. Nello studio randomizzato di METR pubblicato a luglio 2025, 16 sviluppatori esperti hanno svolto 246 attività reali. Con l'AI ci hanno messo il 19% in più. Prima si aspettavano di andare il 24% più veloci e anche dopo credevano di esserlo stati del 20%. Il dibattito resta aperto: nell'aggiornamento del 24 febbraio 2026 METR scrive che gli strumenti di fine 2025 probabilmente accelerano di più, ma i nuovi dati sono distorti e lo studio va riprogettato.

Come riconoscerlo

• Ogni modifica rompe qualcos'altro.
• Nessuno nel team sa spiegare alcune parti del codice.
• Ci sono funzioni duplicate che fanno quasi la stessa cosa.
• Gli errori vengono "silenziati" con blocchi try/catch vuoti.

Come evitarlo

• Avere almeno una persona tecnica che capisce tutto il codice.
• Scrivere test automatici prima di aggiungere nuove funzioni.
• Dedicare tempo esplicito al refactoring.
• Misurare la produttività invece di percepirla: è la lezione dello studio METR.

Errore 3: costruire senza aver parlato con nessun cliente

Su questo errore e sul successivo la guida non riporta statistiche verificate: le indicazioni sono di metodo. Il rischio è semplice. Se costruire costa poco, si è tentati di costruire prima di capire. Un MVP generato in un weekend può sembrare una prova di mercato, ma dimostra solo che il prodotto si può fare, non che qualcuno lo vuole.

Come riconoscerlo

• Il team sa descrivere le funzioni, ma non il problema di un cliente specifico.
• Nessun potenziale cliente ha visto il prodotto prima del lancio.
• Le priorità del backlog vengono da idee interne, non da conversazioni.

Come evitarlo

• Parlare con potenziali clienti prima di scrivere codice, chiedendo come risolvono oggi il problema.
• Usare l'AI per costruire prototipi da mostrare nelle interviste, non per sostituirle.
• Annotare le obiezioni ricorrenti e decidere le funzioni in base a quelle.

Errore 4: misurare le metriche sbagliate

Un MVP fatto con l'AI può attirare molte registrazioni o prove gratuite, soprattutto nei primi giorni. Questi numeri dicono poco sul valore del prodotto.

Come riconoscerlo

• Il cruscotto mostra soprattutto utenti registrati e prove avviate.
• Non si sa quanti utenti tornano dopo la prima settimana.
• Nessuno ha ancora chiesto un pagamento.

Come evitarlo

• Misurare la retention e l'uso ripetuto, non solo le iscrizioni.
• Testare presto la disponibilità a pagare, anche con un prezzo provvisorio.
• Collegare ogni metrica a una decisione: se un numero non cambia cosa fare, non serve.

Una checklist prima di mostrare l'MVP a clienti e investitori

1. Il codice è stato scansionato e una persona ha rivisto autenticazione e permessi?
2. Le chiavi API sono fuori dal codice?
3. Gli agenti AI sono esclusi dal database di produzione?
4. Esistono test automatici sulle funzioni principali?
5. Qualcuno nel team capisce l'intero codice?
6. Il problema è stato validato con conversazioni reali?
7. Le metriche guardano a uso ripetuto e pagamento, non solo a iscrizioni?