Recentemente Scotiabank ha pubblicato un’analisi che ha attirato la mia attenzione. Un colosso farmaceutico da 25 miliardi di dollari, tra i buyer più regolamentati nel settore del software enterprise, sta sviluppando da solo i propri strumenti di vendita tramite vibe coding. Ogni nuovo euro destinato all’IT va all’intelligenza artificiale, non al rinnovo dei contratti SaaS.
“Il mercato del software è in calo, ma probabilmente non ancora abbastanza. Per vent’anni il modello di crescita del software applicativo si è basato su tre fattori: costi di transizione, radicamento nei flussi di lavoro e difficoltà nel creare soluzioni personalizzate. I modelli LLM con capacità di programmazione agentica colpiscono questi tre pilastri contemporaneamente. Quando un gigante farmaceutico, tra i più avversi al rischio nel software enterprise, sviluppa e distribuisce strumenti di vendita basati sui propri dati, il fossato difensivo delle aziende SaaS risulta più stretto di quanto dicano i multipli di borsa.”
Parliamo di un colosso farmaceutico, il tipo di azienda che impiega sei mesi solo per approvare un nuovo laptop. Oggi questa stessa realtà crea software interno usando prompt in linguaggio naturale. Se lo fanno loro, il resto del mondo corporate deve prestare attenzione.
I prezzi del software SaaS crescono del 12-25% all’anno, mentre gli assistenti di programmazione AI riducono lo sforzo di sviluppo del 20-55%. Attività che richiedevano cinque ingegneri oggi ne richiedono due. Factory, fornitore di agenti AI per la programmazione, ha iniziato a sostituire i propri abbonamenti SaaS con strumenti creati internamente. Il loro CTO lo ha sintetizzato chiaramente: “Abbiamo iniziato a sviluppare in casa molte cose che prima avremmo acquistato”.
Sviluppare software oggi è rapido ed economico. La vera sfida resta la manutenzione.
Indice degli argomenti
Vibe coding, lo Spaghetti Point
Sono un appassionato di caffè specialty. Qualche mese fa ho sviluppato un’applicazione web in React tramite vibe-coding. Diario per le degustazioni, mappa globale e tracciamento con riconoscimento immagini.
I primi giorni sembravano un miracolo: un prototipo funzionante in poche ore con funzionalità rilasciate velocemente.
Poi si è presentato il conto. Ogni nuova funzione ne bloccava un’altra. Risultava difficile ricostruire la logica del codice non avendolo scritto riga per riga. Ho risolto la situazione, ma si trattava di un progetto personale senza requisiti di conformità aziendale o utenti esterni.
In un contesto aziendale la situazione cambia. Baytech Consulting individua un “punto spaghetti” verso il terzo mese di sviluppo: la velocità si azzera e il team passa il tempo a riparare quanto appena creato. Escape.tech ha analizzato oltre 1.400 applicazioni create con vibe-coding e rilasciate in produzione. Il 65% mostrava problemi di sicurezza e il 58% presentava almeno una vulnerabilità critica.
Il costo per sviluppare è crollato. Il costo di gestione del codice rilasciato resta elevato.
Tre domande prima di sviluppare in vibe coding
Gestisco l’Open Innovation e il Venture Clienting in Lamborghini. Ho anche sviluppato strumenti personali con il vibe coding e utilizzo agenti AI quotidianamente.
Ho sperimentato direttamente questi processi e applico un modello chiaro: un pre-filtro rapido e tre domande chiave.
0. Il task è semplice, personale e ripetitivo?
Rientrano in questo ambito la sintesi di riunioni, le bozze di email, la formattazione di dati o la stesura di prime bozze. Non sono progetti ingegneristici, ma flussi di lavoro.
In questi casi non serve scrivere codice né contattare fornitori. Prima di attivare un agente AI occorre verificare se il processo è efficiente. Automatizzare un processo inefficiente non lo risolve, lo rende solo più rapido nei suoi errori.
Se il processo funziona, basta configurare un agente su Copilot o Claude in venti minuti. Utilizzo un agente che organizza le note di scouting dell’innovazione in schede sintetiche. La tecnologia è semplice, ma permette di risparmiare due ore a settimana.
Se il processo presenta lacune, vanno risolte prima di automatizzare.
Questo filtro vale se non ci sono impatti critici sul business. Quando i risultati richiedono affidabilità e controlli di sicurezza, servono le tre domande successive.
Regola generale: se l’impatto sul business è basso e riguarda la produttività personale, un agente basta. È preferibile riservare le risorse di sviluppo ai problemi rilevanti su scala aziendale.
Passata questa soglia, occorre rispondere a tre domande.
1. Questa funzionalità è unica o strategica per l’azienda?
Se la risposta è no, è meglio fermarsi. Non ha senso sviluppare strumenti generici come la gestione spese, la registrazione visitatori o il tracciamento della flotta. Sembrano semplici, ma una startup con decine di clienti ha già risolto casi limite, integrazioni e vincoli di conformità. Un team interno scoprirà questi problemi solo più avanti, trovandosi a gestire codice complesso. In questo caso è meglio acquistare software esterno. Il venture clienting permette di avviare un pilot remunerato, verificare l’integrazione e scalare la soluzione se funziona.
2. Ci sono le competenze per svilupparlo in modo corretto?
Qui si concentrano gli errori principali. Il vibe-coding riduce i costi di scrittura del codice, ma non crea competenze specifiche su un problema.
Per la manutenzione predittiva, un team aziendale può creare una dashboard per i dati dei sensori in un giorno. Il valore reale risiede nell’algoritmo che prevede i guasti. Quell’algoritmo richiede anni di dati, calibrazione e conoscenza del settore. Una startup specializzata ha già testato la soluzione su decine di impianti e conosce problemi che un team interno dovrebbe riscoprire da zero.
Il team aziendale conosce il problema, la startup possiede la soluzione. Il vibe-coding non colma questo divario.
Senza competenze specifiche conviene acquistare la soluzione sul mercato. Una startup specializzata garantisce prestazioni superiores rispetto a un team interno privo di esperienza diretta nel settore.
3. L’onere di manutenzione è basso?
Se la risposta è sì, si può sviluppare internamente. Dashboard per uso interno, automazioni semplici e strumenti per l’analisi dei dati rappresentano il caso d’uso ideale per il vibe-coding. I rischi sono bassi e i tempi rapidi. Il software si usa e si elimina quando cambiano le esigenze.
Se la manutenzione richiede costi elevati per supporto continuo, aggiornamenti di sicurezza, conformità e integrazioni complesse, l’acquisto è la scelta migliore. La startup si occupa dell’aggiornamento del prodotto e gli ingegneri interni rimangono concentrati sulle attività chiave dell’azienda.
Sviluppare soluzioni ad alta manutenzione nasconde un costo che emerge in ritardo: il debito tecnico. Le scorciatoie e le modifiche su codice poco chiaro generano inefficienze nel tempo. Forrester stima che il 75% delle aziende tecnologiche affronterà debiti tecnici rilevanti entro il 2026. Con i progetti realizzati in vibe-coding il codice si rilascia in poche ore, ma il debito si accumula in pochi mesi.
La componente umana delle decisioni
La logica economica è chiara, ma i team tendono comunque a sviluppare software in casa. Questo comportamento dipende da dinamiche umane.
Creare un prodotto genera senso di appartenenza e orgoglio. Gli ingegneri vogliono esprimere creatività e mantenere il controllo sul lavoro. Presentare un software sviluppato internamente durante il fine settimana genera entusiasmo.
Annunciare l’acquisto di un software da una startup produce un effetto diverso. È una notizia meno coinvolgente nei meeting aziendali e difficilmente viene inserita nelle valutazioni delle prestazioni individuali.
Sviluppare internamente dà l’impressione di costruire competenze aziendali e mantenere il controllo sui processi. Con gli strumenti AI la creazione di codice appare alla portata di tutti, rendendo difficile evitare lo sviluppo interno.
Questa tendenza nasce da motivazioni reali come orgoglio e senso di efficacia. In assenza di una guida chiara, porta l’azienda a scegliere lo sviluppo interno anche quando non rappresenta la soluzione migliore.
Cosa cambia per il Venture Clienting
Quando ogni team può creare automazioni e dashboard in pochi giorni, il ruolo delle startup cambia. Le aziende smettono di cercare soluzioni per problemi superficiali e si rivolgono al mercato solo per sfide complesse: competenze verticali, anni di dati di addestramento, gestione dei vincoli normativi e integrazioni su larga scala.
Il venture clienting diventa uno strumento strategico per accedere a competenze avanzate.
Aziende come BMW, Maersk e Holcim utilizzano questo modello da anni. Ogni progetto parte da una necessità aziendale concreta, un budget definito e un responsabile decisionale. Il pilot viene remunerato, gli obiettivi di successo sono fissati in partenza e il processo si conclude con l’adozione o con l’interruzione del progetto. Si evitano così attività d’innovazione prive di impatto reale.
Holcim avvia oltre 25 pilot all’anno, della durata di tre-sei mesi. Circa la metà dei progetti raggiunge gli obiettivi e una parte di questi viene integrata nei processi aziendali. Il valore risiede nella selezione: si testa la soluzione prima di investire risorse importanti. Se la startup non rispetta le attese, il progetto si chiude senza costi residui di manutenzione software.
Esiste anche un approccio ibrido efficace. Si crea un prototipo in vibe-coding per validare la necessità interna e mostrare il valore agli stakeholder. Successivamente si individua una startup in grado di fornire una soluzione pronta per la produzione. Il prototipo iniziale diventa l’analisi di fattibilità per l’avvio del progetto di venture clienting. Sviluppare per imparare, acquistare per scalare.
Con la riduzione dei costi di sviluppo software, la selezione delle startup diventa più rigorosa. Il venture clienting si conferma una scelta strategica per acquisire competenze esterne non sviluppabili internamente in tempi brevi.
Il vibe-coding permette di generare codice in modo rapido, ma non sostituisce le competenze di settore. Le aziende capaci di distinguere questi due aspetti otterranno risultati migliori nelle decisioni d’investimento.
N.B. Questo articolo è l’adattamento in italiano del post originale apparso su Open Road Ventures, la newsletter curata da Davide Ritorto
Partecipa alla community