La tesi in una frase: generare un’app «a vibrazioni» —descrivi ciò che vuoi e l’IA scrive il codice— è meraviglioso per prototipare e un disastro per reggere in produzione. Non perché il codice esca male: oggi esce sorprendentemente bene. È perché un’app viva non è il codice che si vede nella demo; è tutto ciò che non si vede —i test che avvisano quando qualcosa si rompe, l’osservabilità che ti dice perché, la sicurezza che impedisce a un cliente di vedere i dati di un altro, e una persona che risponde quando cade alle tre di notte. È il 70% noioso, ed è proprio ciò che il vibe coding non ti dà con lo stesso gesto con cui ti dà la schermata bella.
Cos’è il vibe coding in produzione e perché inganna così tanto
Il termine l’ha reso popolare Andrej Karpathy a inizio 2025 per descrivere una cosa che facevamo già tutti: lasciarsi andare, descrivere all’IA ciò che vuoi e accettare il codice che restituisce senza leggerlo riga per riga. E funziona: in un pomeriggio hai un’app che parte, che fa il login, che salva cose in un database e che mostri in riunione tra gli applausi. Il problema non è quel pomeriggio. Il problema è la conclusione che quasi tutti ne traggono: «se l’ho montato in un pomeriggio, il sistema intero è a una settimana». Non lo è. Ciò che hai montato è la parte che si vede, e la parte che si vede è quella economica.
È lo stesso miraggio di sempre, con abiti nuovi. Una demo che funziona con dati puliti, un solo utente e zero traffico reale non dice nulla su cosa succede quando arrivano mille persone, metà dei dati arriva a metà e qualcuno prova a intrufolarsi dove non dovrebbe. La demo è una promessa; la produzione è la riscossione di quella promessa. E in mezzo c’è il lavoro di cui nessuno parla alla chiamata di vendita, perché non brilla su uno schermo.
Cosa il vibe coding non genera (ed è ciò che separa la demo dal sistema)
Non è che l’IA scriva codice debole. È che un sistema in produzione è molto più del codice, e quegli altri strati non escono da un prompt carino. Questi sono quelli che mancano quasi sempre:
- Test che avvisano prima del cliente. Il codice generato fa ciò che hai chiesto il giorno in cui l’hai chiesto. Nessuno garantisce che lo faccia ancora quando toccherai altro tra tre settimane. Senza una rete di test, ogni modifica è una scommessa e chi scopre che hai rotto qualcosa è il tuo utente.
- Osservabilità: sapere cosa succede quando succede. Nella demo, se qualcosa si rompe, lo vedi sul tuo schermo. In produzione si rompe sul telefono di un cliente a 800 km e non lo scopri, a meno che tu non abbia montato log, metriche e alert. Senza quello, la tua prima fonte di monitoraggio è una mail arrabbiata.
- Sicurezza e isolamento dei dati. Il vibe coding ti monta il login; ciò che raramente ti monta bene è che l’utente A non possa, toccando l’URL, vedere i dati dell’utente B. I permessi, l’isolamento tra clienti e la gestione dei dati personali sono precisamente dove un’app improvvisata diventa una falla.
- Un responsabile e un processo. Un sistema vivo ha bisogno di chi lo distribuisca con criterio, di chi decida cosa si tocca e cosa no, e di chi c’è quando cade. Codice senza responsabile non è un sistema: è una bomba a orologeria che funziona finché non lo fa più e nessuno sa perché.
Ognuno di questi punti è invisibile nella demo e determinante in produzione. E nessuno si risolve con un prompt migliore: si costruisce con mestiere, che è proprio ciò che il vibe coding ti tenta a saltare perché «tanto funziona già».
Allora il vibe coding non serve a nulla? Al contrario
Serve, eccome, se lo metti al posto giusto. Come strumento di prototipazione è tra i migliori arrivati da anni: valida un’idea in un pomeriggio invece che in due settimane, ti fa mostrare qualcosa di tangibile in riunione, e scarta ciò che non ha senso prima di spendere un euro per costruirlo bene. L’errore non è usare il vibe coding; l’errore è confondere il prototipo con il prodotto e mandare in produzione ciò che è nato per essere buttato.
| Il vibe coding è ottimo per | E pericoloso per |
|---|---|
| Validare un’idea prima di investire | Conservare dati reali dei clienti |
| Prototipi interni e demo | Qualsiasi cosa con utenti esterni |
| Esplorare come si sentirebbe una funzione | Processi da cui dipende il business |
| Imparare e fare prove veloci | Nulla che debba reggere un lunedì mattina |
La regola è semplice: usa il vibe coding per decidere cosa costruire, non per costruirlo. Il prototipo ti dice se l’idea vale; da lì, ciò che regge in produzione si costruisce con la parte noiosa —lo stesso mestiere che serve per automatizzare un processo del business senza che si rompa al primo colpo o per mettere un agente IA a lavorare davvero dentro un’azienda. Quel lavoro non è più lento per capriccio: è ciò che separa una demo applaudita da un sistema ancora in piedi il martedì.
Cosa fare con un prototipo che funziona
Se hai generato qualcosa «a vibrazioni» e risolve davvero un dolore, la buona notizia è che hai già la parte più difficile: la certezza che l’idea vale. Ciò che viene dopo non è riscriverlo per gusto, è dargli ciò che gli manca per vivere fuori dal tuo schermo —rete di test, monitoraggio, sicurezza, distribuzione con criterio e qualcuno che risponde. È la parte che trattiamo come ciò che è, infrastruttura, nell’infrastruttura di IA per l’azienda: prendere ciò che il prototipo valida e lasciarlo funzionare senza dipendere dal fatto che qualcuno lo guardi.
Quindi sì al vibe coding —per prototipare, per validare, per scartare in fretta. E no al vibe coding in produzione, non perché l’IA scriva male, ma perché la produzione è il 70% che l’IA non genera col prompt: i test, l’osservabilità, la sicurezza e il responsabile. L’IA non si presenta in una demo con dati finti. Si implementa sul reale, e il reale esige la parte noiosa. È quello il lavoro, ed è proprio la parte che non si vede.