Il vibe coding ha reso concreta un’idea che fino a poco tempo fa sembrava futuristica: descrivere un software in linguaggio naturale e lasciare che l’AI contribuisca a costruirlo.
Ma nel mondo enterprise c’è una domanda ancora più interessante: e se il codice non fosse l’output che ci interessa davvero?
Il codice è spesso un mezzo, non il risultato
Quando un’azienda chiede di gestire ferie, acquisti, lead, onboarding, approvazioni o assistenza, raramente sta chiedendo JavaScript, SQL o React. Sta chiedendo che un processo funzioni.
Il codice è storicamente il mezzo attraverso cui traduciamo quella necessità in un sistema eseguibile.
Con l’AI possiamo iniziare a immaginare un’astrazione diversa: descrivere direttamente il comportamento aziendale desiderato e ottenere come risultato un processo persistente.
Cos’è il Business Vibe Coding
Chiamiamo Business Vibe Coding questo passaggio: dal linguaggio naturale non necessariamente al codice, ma a dati, stati, azioni, decisioni, ruoli, approval gate, integrazioni e regole che formano un processo aziendale eseguibile.
Una richiesta come “quando arriva un nuovo fornitore raccogli i documenti, verifica i dati, chiedi approvazione al procurement sopra una certa soglia e poi avvisa amministrazione” contiene già gran parte della semantica del processo.
Il sistema deve trasformarla in qualcosa che non sia soltanto una risposta dell’AI, ma un comportamento che rimane disponibile anche domani, per il prossimo fornitore.
La differenza tra eseguire una richiesta e creare un processo
Un agente può ricevere un prompt e completare una serie di azioni. Ma al termine di quella conversazione la procedura potrebbe non esistere come oggetto persistente.
Nel Business Vibe Coding, invece, l’output deve diventare parte del sistema: avere una struttura, uno stato, regole, autorizzazioni, versioni e una modalità di esecuzione ripetibile.
Non stiamo chiedendo all’AI di fare il lavoro una volta. Stiamo descrivendo come il lavoro dovrà essere fatto da quel momento in avanti.
Perché MCP è un acceleratore
La trasformazione è già visibile nelle piattaforme enterprise: Salesforce descrive Headless 360 come un modo per rendere business capability governate riutilizzabili dagli agenti attraverso standard aperti (fonte ufficiale Salesforce).
MCP rende più naturale collegare agenti e capability. Un processo può quindi non vivere isolato: può leggere e aggiornare sistemi esistenti, utilizzare servizi esterni e diventare accessibile da client diversi.
Questo si collega alla trasformazione headless che analizziamo nel pillar Dopo Headless 360: se l’AI sostituisce l’interfaccia, cosa succede al software enterprise?.
Se le applicazioni diventano insiemi di capability accessibili agli agenti, il passaggio successivo è consentire all’AI di comporre quelle capability in nuovi processi governati.
Il problema non è generare: è governare
Generare una sequenza plausibile è relativamente semplice. Renderla sicura, modificabile, verificabile e recuperabile è molto più difficile.
Un processo enterprise deve sapere chi può fare cosa, quali dati sono obbligatori, quali azioni richiedono approvazione, cosa è già stato eseguito e come comportarsi dopo un errore.
Questo è anche il motivo per cui MCP da solo non basta e l’harness diventa centrale nell’enterprise AI.
Per questo Business Vibe Coding e harness engineering sono strettamente collegati: la libertà del linguaggio naturale deve terminare dentro un runtime deterministico.
Flowvenue e il processo come artefatto
È la direzione su cui stiamo costruendo Flowvenue: rendere conversazionali non soltanto l’utilizzo del software, ma anche la costruzione del modello dati e dei processi che rappresentano il lavoro dell’azienda.
L’obiettivo è comprimere una catena tradizionalmente lunga — analisi, configurazione, workflow, integrazione, interfaccia e test — avvicinandola a una relazione molto più diretta:
problema → conversazione → processo eseguibile.
Non è no-code con una chat davanti
La differenza non è estetica. Aggiungere un chatbot a un builder visuale non cambia il paradigma se l’utente deve comunque conoscere componenti, configurazioni e struttura interna della piattaforma.
Il salto avviene quando il sistema riesce a partire dall’intenzione business e tradurla nella propria struttura operativa, mantenendo governance e controllo.
È qui che il vibe coding smette di essere soltanto un nuovo modo di programmare e diventa un possibile nuovo modo di costruire il funzionamento dell’azienda.
Domande frequenti
È un approccio in cui un’esigenza aziendale espressa in linguaggio naturale viene trasformata in un processo persistente ed eseguibile, con dati, regole, azioni, ruoli e integrazioni.
Nel vibe coding l’output principale è normalmente codice o un’applicazione generata. Nel Business Vibe Coding l’artefatto centrale è il processo aziendale governato ed eseguibile.
No. Il codice continua a esistere nell’infrastruttura e nelle integrazioni. La differenza è che l’utente business non deve necessariamente produrlo o gestirlo per descrivere e implementare un nuovo processo.