Prototipare con l'IA: quanto vale davvero il vibe coding

Prototipare con l'IA vale molto — a condizione di sapere cosa si tiene in mano alla fine. Il vibe coding, questa pratica in cui si descrive in linguaggio naturale ciò che il software deve fare e un modello produce il codice, comprime l'esplorazione da diverse settimane a pochi giorni. Ciò che produce resta un prototipo: perfetto per decidere, inadatto a servire i clienti. Tutto il valore della pratica sta in questa distinzione.

Articolo pubblicato a marzo 2026, rielaborato il 25 maggio 2026, rivisto il 7 luglio 2026.

Il vibe coding, definizione senza mitologia

Il vibe coding designa una pratica di sviluppo in cui l'intenzione espressa in linguaggio naturale precede il codice: si descrive la funzionalità attesa, un sistema alimentato da un modello generativo produce l'implementazione, la si rivede e la si aggiusta. Il termine si è diffuso all'inizio del 2025 — la formula è attribuita a un ricercatore di intelligenza artificiale di primo piano — e ha innescato una conversazione pubblica sproporzionata rispetto alla sua reale portata.

Per alcuni, la fine dello sviluppo software. Per altri, una categoria inedita di debito tecnico. La realtà osservabile si situa tra i due: la fase di prototipaggio è trasformata in profondità, la disciplina di produzione non lo è, e confondere le due cose costa caro.

Cosa cambia quando si testa un'idea

Un prototipo ha un solo obiettivo: permettere di decidere se un'idea merita lo sforzo di costruzione. Sotto questo criterio, il vibe coding cambia le carte in tavola su velocità, accesso e pluralità. La velocità: un prototipo che richiedeva diverse settimane a uno sviluppatore da solo si produce in pochi giorni, talvolta poche ore per un concetto semplice — ciò che era troppo costoso da validare diventa testabile. L'accesso: un product manager, un consulente, un analista di business può produrre un prototipo funzionante che esprime concretamente la sua intenzione, senza passare attraverso il filtro di un team tecnico. La pluralità: produrre più varianti di uno stesso concetto in parallelo e trattenere quella che sopravvive al confronto con la realtà diventa accessibile, il che cambia la qualità delle decisioni di prodotto.

Ne parlo per esperienza diretta. FiscalDoc, l'applicazione locale che gestisce la mia fiscalità, è nata esattamente così: descritta, dialogata, aggiustata in tre serate. Il racconto è pubblicato in FiscalDoc, o sostituire un SaaS con un'IA locale, e la strumentazione che utilizzo è descritta nel mio resoconto di esperienza su Claude Code.

Cosa non vi dà il prototipo

Tre zone restano estranee alle promesse del vibe coding, e si pagano care quando le si ignora.

Prima di tutto il debito invisibile. Un codice prodotto tramite dialogo iterativo funziona spesso, ma la sua coerenza d'insieme non è garantita da nessuno. Ogni aggiunta complica silenziosamente il tutto, e il costo si rivela proprio nel momento in cui il prototipo dovrebbe diventare prodotto — cioè troppo tardi per correggere senza una riscrittura sostanziale.

Poi la sicurezza. Il codice generato funziona sul percorso nominale; i casi di errore, le iniezioni, le autorizzazioni, le condizioni limite — tutto ciò che costituisce la sicurezza applicativa — non sono trattati sistematicamente. Accettabile per una maquette testata in circuito chiuso. Pericoloso davanti a utenti reali.

Infine la conformità. I settori regolamentati svizzeri — finanza, sanità, assicurazioni — esigono una tracciabilità delle scelte tecniche che la generazione dialogata non produce naturalmente: processi poco deterministici, scelte raramente documentate, revisioni alleggerite per costruzione. Niente di proibitivo per un prototipo; tutto lo diventa in produzione.

La regola di arbitraggio: validare con esso, costruire senza

La regola che applico si riassume in due frasi. Il vibe coding è lo strumento appropriato per validare che un'idea meriti di essere costruita; non è lo strumento per costruirla in seguito. Questa distinzione non è una concessione alla prudenza: è l'uso più efficace della pratica stessa.

I team che ne traggono il massimo prototipano velocemente, validano ciò che deve esserlo, poi ricostruiscono in modo pulito ciò che ha dimostrato il suo valore — architettura, test, revisione. Quelli che spingono il prototipo in produzione accumulano un debito che si paga nei mesi successivi, e che nessuna iterazione supplementare di prompt ripaga. La ricostruzione pulita, invece, rientra in uno sviluppo su misura inquadrato: è un altro regime di lavoro, con un altro livello di esigenza.

Quattro situazioni in cui non prototipo nemmeno

Anche per esplorare, alcuni contesti escono dal quadro.

• Dati reali. Un prototipo che manipola dati clienti, finanziari o medici identificabili supera ciò che lo statuto di prototipo può assorbire. Dati fittizi o anonimizzati, ambiente isolato — senza eccezioni.
• Un'esposizione pubblica. Un prototipo online senza controllo degli accessi è una messa in produzione senza il rigore corrispondente. È l'errore operativo più frequente tra i team che adottano la pratica senza inquadramento.
• Un legame con i vostri sistemi in produzione. Collegato alla vostra gestione, a un database di mestiere o a un'API critica, un bug di prototipo ha conseguenze reali. Ambiente separato, sempre.
• L'assenza di rilettura. Nessuno mostra un prototipo a un cliente, un investitore o un utente senza che una persona competente abbia potuto dire se il risultato regge.

E FiscalDoc, allora?

Si potrebbe obiettarmi che FiscalDoc, prototipo dialogato in tre serate, gira ancora da me tutti i giorni. È esatto, e il perimetro spiega tutto: un utente — io —, i miei dati, una macchina locale, nessuna esposizione di rete, nessun dato di terzi. È esattamente il perimetro in cui un prototipo può vivere a lungo. Il giorno in cui uno strumento di questo tipo dovesse servire qualcun altro oltre al suo autore, si ricostruisce con la disciplina di produzione.

Applicate lo stesso test ai vostri prototipi: se il loro perimetro assomiglia a quello, possono vivere; altrimenti, ricostruite prima che il debito decida al posto vostro.

Cosa richiede questo nella vostra organizzazione

Per una PMI svizzera, la posta in gioco è meno tecnica che di inquadramento. Definite esplicitamente cosa può essere prototipato in vibe coding e cosa rientra in uno sviluppo controllato — questa chiarificazione si costruisce in poche settimane ed evita gli arbitraggi improvvisati. Conservate i dialoghi che hanno prodotto buoni risultati: è un capitale di metodo che si trasmette, piuttosto che un sapere tacito che si cancella.

E collegate la pratica alle vostre priorità reali. Un prototipo vale solo se testa un'ipotesi che conta, il che presuppone di aver posto i vostri flussi e i vostri cantieri di automazione preliminarmente. Per l'ordine di questi cantieri, il quadro generale è in Cosa deve fare una PMI svizzera di fronte all'IA nel 2026?.

Da ricordare

— Il vibe coding comprime l'esplorazione: ciò che richiedeva settimane si testa in pochi giorni, anche senza profilo tecnico. — Ciò che produce resta un prototipo: debito invisibile, sicurezza e tracciabilità escludono la messa in produzione così com'è. — Validare con il prototipo, ricostruire in modo pulito ciò che ha dato prova di sé: la regola sta in una frase.

FAQ

Un non sviluppatore può davvero prototipare da solo? Sì, per esplorare ed esprimere un'intenzione: il prototipo che ne esce vale più di un capitolato astratto, perché si può testare. Prima di mostrarlo fuori dal team o di collegarlo a qualsiasi cosa, una rilettura da parte di una persona competente resta necessaria.

Si può mantenere un prototipo in produzione? Solo se il suo perimetro resta quello di un prototipo: utente unico o cerchia chiusa, dati non sensibili, nessuna esposizione pubblica, nessun legame con i vostri sistemi critici. Non appena uno di questi muri cade, la ricostruzione si impone. FiscalDoc vive da me proprio perché rispetta questi limiti.

Quanto costa un prototipo assistito dall'IA? Internamente, spesso pochi giorni di lavoro laddove servivano settimane — è il cuore del guadagno. Su mandato, l'importo dipende dal perimetro: esigete un perimetro scritto e un prezzo fisso prima di lanciare, e diffidate di un prototipo venduto come un prodotto finito.

Quale differenza tra vibe coding e sviluppo assistito dall'IA? Il vibe coding mira all'esplorazione: l'intenzione precede il codice, la revisione è alleggerita, il risultato è usa-e-getta per principio. Lo sviluppo assistito conserva la disciplina di produzione — architettura, test, revisione sistematica — utilizzando l'IA come acceleratore di esecuzione. Stessa famiglia di strumenti, due regimi di lavoro diversi.

E le vostre idee in attesa? La Diagnosi d'Uso dell'IA: sessanta minuti per mappare i vostri flussi reali, identificare ciò che merita una soluzione su misura, ciò che resta in SaaS, e ciò che non ha bisogno di IA. Prenotare una diagnosi

Jérôme Deshaie è CEO e fondatore di MCVA Consulting SA, agenzia aumentata con sede in Vallese. Quindici anni al servizio di grandi marchi internazionali, oggi in diretta per le PMI svizzere. Percorso.