Vibe coding e software strategico: perché affidarsi a sviluppatori improvvisati può costare caro

Negli ultimi due anni qualcosa è cambiato nel mondo dello sviluppo software. Con l'arrivo degli assistenti AI per la programmazione, è diventato possibile costruire applicazioni funzionanti senza scriverne il codice riga per riga. Si descrive a parole cosa si vuole, l'AI genera, si copia, si incolla, si guarda se "funziona". È quello che la community ha iniziato a chiamare vibe coding.

È un'evoluzione potente, e per molti contesti — prototipi rapidi, side project, esperimenti — è una rivoluzione vera. Ma negli ultimi mesi è successo qualcosa di più ambiguo: agenzie e freelance senza solido background ingegneristico hanno iniziato a vendere prodotti software business-critical costruiti quasi interamente in questo modo, presentandoli ai clienti come sviluppi tradizionali.

Il risultato, per chi compra, è quasi sempre lo stesso: una demo che entusiasma, un prezzo che sembra un affare, e dopo 6-12 mesi un sistema che nessuno riesce più a far evolvere senza romperlo.

l termine è stato reso popolare da Andrej Karpathy nel 2025, ed è entrato rapidamente nel lessico comune del settore. La definizione operativa è semplice: scrivere software lasciandosi guidare dall'AI senza realmente leggere o capire il codice prodotto. Si descrive un'intenzione, si accetta l'output, si testa il risultato a occhio. Se funziona, si va avanti.

Per i prototipi è geniale. Per gli MVP da validare in una settimana, anche. Per uno strumento interno che userà una persona sola e che, se si rompe, non manda in tilt nessuno, può essere perfetto.

Il problema nasce quando lo stesso approccio viene applicato a un prodotto digitale strategico: il gestionale che fa girare la produzione, l'app che i clienti usano ogni giorno, la piattaforma che gestisce ordini, pagamenti, dati sensibili. Lì le regole del gioco cambiano completamente, e quasi nessuno lo spiega in fase di vendita.

La promessa è seducente: "Te lo facciamo in tre settimane, a un terzo del preventivo dell'agenzia tradizionale." Tecnicamente, è vero. Ma quello che stai comprando è una versione del prodotto in cui sono presenti solo gli elementi visibili — l'interfaccia, le feature mostrate in demo, il flusso principale — e in cui mancano quasi tutti gli strati che un software serio richiede per durare nel tempo.

La colonna di sinistra è quella che il fornitore mostra al cliente. La colonna di destra è quella che decide se il prodotto reggerà tre anni o si trasformerà in un'emergenza permanente. Nel vibe coding non strutturato, la colonna di destra spesso non esiste proprio — non perché qualcuno l'abbia tagliata per risparmiare, ma perché chi ha costruito il sistema non sa nemmeno che dovrebbe esserci.

È la differenza tra una casa che si vede finita e una casa che ha anche fondazioni, impianti a norma e collaudi strutturali. La prima costa meno e si abita subito. La seconda dura cinquant'anni.

Il preventivo iniziale è quasi sempre la parte minore della spesa totale di un prodotto software. Quello che fa la differenza è il costo totale di proprietà sui 24-36 mesi successivi: bug-fixing, performance, evoluzione delle feature, eventuali rifacimenti.

Il pattern è quasi sempre lo stesso. Il vibe coding parte molto più economico — anche meno della metà — ma scarica tutto il costo nelle fasi successive. Bug che spuntano in produzione perché nessuno ha mai scritto un test. Performance che crollano appena cresce il numero di utenti, perché query e architetture sono state generate "a sentimento". Debito tecnico che si accumula a ogni nuova feature, perché ogni modifica viene incollata sopra la precedente senza una visione d'insieme.

E alla fine, quasi sempre, arriva il momento della verità: aggiungere una funzionalità diventa più costoso che riscrivere tutto da capo. È il punto in cui il cliente scopre, suo malgrado, di aver pagato due volte per lo stesso prodotto.

Per capire davvero la differenza, bisogna guardare cosa succede al codice dopo il lancio. È lì che si manifesta il problema più sottovalutato del vibe coding non controllato: la velocità con cui l'AI produce è esattamente la stessa con cui produce incoerenze, duplicazioni e dipendenze invisibili. Senza qualcuno che capisca cosa sta entrando nel codice, ogni nuova generazione aggiunge entropia al sistema.

I primi mesi sembrano perfetti. È il vantaggio commerciale più potente del vibe coding: nelle fasi iniziali sembra davvero più veloce, più reattivo, più economico. Ma intorno al mese 9-12, qualcosa cambia: ogni piccola richiesta richiede sempre più tempo, ogni bug-fix ne crea uno nuovo, e nessuno riesce più a stimare con precisione quanto durerà un intervento.

Un team con cultura ingegneristica solida — code review, test automatici, documentazione, monitoring — costa di più all'inizio ma mantiene il debito tecnico sotto controllo. Il prodotto continua a evolvere a velocità prevedibile anche dopo due anni, perché ogni decisione tecnica è stata presa con piena consapevolezza di ciò che si stava costruendo.

Quando un prodotto software gestisce dati, transazioni o processi aziendali reali, la mancanza di un controllo ingegneristico non è solo un problema di qualità: è un problema di esposizione al rischio. Vale la pena guardarli da vicino.

Sicurezza. Il codice generato dall'AI può contenere vulnerabilità note che nessuno ha verificato — credenziali hardcoded, query non protette da SQL injection, gestione fragile delle sessioni. Sono errori che un ingegnere senior individua in code review, ma che chi ha solo guidato l'AI a parole spesso non sa nemmeno cercare.

Conformità normativa. Se il prodotto tratta dati personali (GDPR), dati sanitari, dati finanziari o emette documenti fiscali, ci sono obblighi precisi su come questi dati vanno trattati, registrati e protetti. Un sistema costruito senza chi sappia come funzionano queste normative è un sistema esposto a sanzioni.

Continuità. Quando il sistema si rompe alle 22 di un sabato sera, qualcuno deve sapere come è fatto, dove guardare i log, come ripristinare i dati. Se il prodotto è stato costruito senza documentazione, senza monitoring e senza chi lo capisca davvero, ogni incidente diventa una crisi.

Lock-in al fornitore. Un codice opaco, scritto velocemente e senza struttura, è un codice che solo chi l'ha generato riesce a toccare. Cambiare fornitore diventa praticamente impossibile, perché qualsiasi altro team, davanti a quel codice, proporrà — giustamente — di rifare tutto da capo.

Sarebbe un errore leggere quanto detto fin qui come una crociata contro l'AI nello sviluppo software. L'AI è uno strumento straordinario, e i team ingegneristici migliori la usano massicciamente — proprio perché sanno leggere, valutare e correggere ciò che produce.

La differenza non è tra "fatto a mano" e "fatto con l'AI". È tra codice generato e supervisionato da chi sa cosa sta accadendo e codice generato e accettato da chi non lo sa. Il primo amplifica la produttività di un team competente. Il secondo costruisce castelli che reggono solo finché nessuno li tocca.

Le aziende che fanno bene il loro lavoro, oggi, usano l'AI in tre modi precisi: per accelerare le parti meccaniche dello sviluppo, per esplorare rapidamente alternative architetturali, per ridurre il tempo speso su task ripetitivi. Ma la responsabilità del prodotto, dell'architettura, della qualità e della sicurezza resta umana — e ingegneristica.

Per chi deve scegliere un partner tecnico per un prodotto strategico, ci sono alcune domande semplici che separano molto rapidamente chi fa engineering da chi fa solo vibe coding mascherato.

Come gestite il versionamento del codice e le code review? Una risposta vaga, o l'assenza di un processo chiaro di review tra sviluppatori, è un primo segnale.

Che copertura di test avete sui progetti recenti? Non serve un numero perfetto. Serve che la domanda non sorprenda chi te la sta sentendo per la prima volta.

Come monitorate il prodotto in produzione? Logging, alerting, metriche, dashboard di osservabilità. Se la risposta è "il cliente ci chiama se qualcosa non va", sei davanti a un fornitore che sta vendendo il prodotto, non un servizio.

Cosa succede se chi ha scritto questo modulo lascia l'azienda? Una risposta solida menziona documentazione, code review condivise, convenzioni di codice. Una risposta debole è il silenzio.

Posso vedere il codice? Per un prodotto custom, il cliente dovrebbe avere accesso al codice sorgente — sempre. Se questo non è ovvio, c'è un problema di posizionamento prima ancora che tecnico.

Il vibe coding non è il nemico. È uno strumento, e come tutti gli strumenti potenti può fare cose meravigliose nelle mani giuste e disastri in quelle sbagliate. Il rischio non è che l'AI scriva codice: è che la velocità e l'apparente semplicità con cui produce risultati visibili nasconda l'assenza di tutto il resto.

Per un prodotto digitale strategico — quello che regge un pezzo del tuo business, che tratta i tuoi dati, che parla con i tuoi clienti — la domanda da fare non è "quanto costa?", ma "chi sta pensando a cosa succederà a questo software fra tre anni, e ha gli strumenti per garantirlo?".

Se la risposta non c'è, o è confusa, il preventivo basso che hai davanti non è un risparmio. È un debito che non sai ancora di aver firmato.