Tante organizzazioni hanno condotto lo stesso esperimento: fornire agli sviluppatori Claude Code, Copilot, Cursor, Windsurf, o tutti e quattro, e vedere cosa succede. Secondo il sondaggio di Stack Overflow del 2025, l’84% degli sviluppatori utilizza già strumenti di programmazione basati sull’IA. La spesa per questi strumenti ha raggiunto i 10 miliardi di dollari quest’anno e, secondo Fortune Business Insights, è destinata a raggiungere i 70 miliardi di dollari entro il 2034. L’esperimento ha funzionato. L’adozione non è più il problema.
Il problema è ciò che accade dopo. I dati di Gartner mostrano che il 69% delle organizzazioni ha prove del fatto che i dipendenti utilizzano strumenti di IA non autorizzati, indipendentemente da qualsiasi strategia centralizzata: un caso da manuale di Shadow AI, dove l’innovazione sta superando l’infrastruttura. E l’entusiasmo che ha convinto tutti a investire a capofitto nel vibe coding sta iniziando a mostrare delle crepe nel momento in cui tocca una codebase di produzione.
Il Vibe Coding porta a un lento logoramento
L’istinto di trattare ogni sessione di programmazione IA come una conversazione isolata e ad hoc comporta un costo reale, e tale costo è misurabile in termini di:
- Incoerenza: i parametri di riferimento del settore dimostrano che il codice generato dall’IA introduce 1,7 volte più bug e vulnerabilità di sicurezza rispetto al codice scritto da esseri umani, costringendo a un aumento del 91% del tempo dedicato alla revisione del codice da parte di uno sviluppatore. La velocità che si guadagna sulla tastiera, la si perde nella fase di revisione.
- Frammentazione: solo il 18% delle organizzazioni mantiene un inventario completo dell’IA all’interno della propria azienda. Nel frattempo, l’89% dei CIO concorda sul fatto che questo accesso non regolamentato all’IA stia già creando un debito tecnico irreversibile.
- Costi alle stelle: la spesa aziendale per le infrastrutture di calcolo basate sull’IA è aumentata del 166% su base annua. Eppure, l’84% delle aziende segnala una notevole erosione del margine lordo direttamente collegata a questi carichi di lavoro di IA, semplicemente perché nessuno controlla i costi alla fonte.
Tutto ciò non significa che affidarsi al codice generato dall’IA sia una cattiva idea. Significa che il vibe coding e lo sviluppo software di livello enterprise affrontano due problemi diversi, e trattarli come se fossero la stessa cosa è ciò che crea problemi.
Vibe Coding vs. Agentic Engineering
Il vibe coding è perfetto per esperimenti individuali: una mentalità orientata all’IA applicata a qualsiasi problema, prompt informali in linguaggio naturale, revisione del codice assente o manuale, iniziative autonome che nascono e muoiono in una singola chat. Il codice prodotto è volutamente usa e getta, e quindi non dovrebbe raggiungere un sistema di produzione.
L’agentic engineering è ciò di cui hanno realmente bisogno le enterprise e il software di produzione a lungo termine: una mentalità potenziata dall’IA applicata a problemi specifici e ben definiti, dove sicurezza e affidabilità non sono negoziabili, le specifiche sono formali, le valutazioni sono automatizzate, l’approvazione è obbligatoria e i team si coordinano anziché lavorare individualmente. Il risultato è una velocità sostenibile: la qualità del codice si mantiene nel tempo, non solo al primo commit.
La differenza tra questi due approcci non risiede nella disciplina o nel talento. Riguarda piuttosto il contesto.
Perché un prompt intelligente non è sufficiente
Il prompt engineering ti fornisce un assistente semplice: un prompt di sistema, un messaggio all’utente, una finestra di contesto, un output. Questo ciclo va bene per piccole task da gestire in autonomia.
Ma non è fattibile per lo sviluppo agentico. Un agente che lavora all’interno di una codebase reale necessita di Context Engineering, una disciplina più strutturata che si confà di tanti elementi:
- Risorse principali: il codice sorgente, la documentazione funzionale e i log su cui l’agente basa il suo ragionamento.
- Competenze: istruzioni che adattano il comportamento a una specifica tecnologia (linguaggio frontend, convenzioni di stile e così via).
- Specifiche di output: la struttura che garantisce la standardizzazione e la coerenza della delivery, evitando un risultato diverso a ogni sessione.
- Strumenti: le capacità operative per interrogare i dati, implementare la CI/CD e accedere al repository.
- Cronologia: un registro sintetico e compresso delle interazioni passate, in modo che l’agente non debba ripartire da zero ogni volta.
Ecco il problema: identificare il contesto giusto per un determinato compito richiede tempo e impegno reali, e se ogni sviluppatore lo ricostruisce da zero, si crea un ciclo di costi individuali che cresce linearmente con il numero di persone anziché ridursi con il riutilizzo. La soluzione è smettere di considerare il contesto come qualcosa da scrivere da zero e iniziare a considerarlo come qualcosa da standardizzare, condividere e scalare. Chiamiamola “Templating del contesto“. Scalare lo sviluppo potenziato dall’IA è la diretta conseguenza della condivisione di modelli di contesto verificati, non della creazione o del miglioramento di prompt personalizzati.
Condividere solo le istruzioni non basta
Pensare a un repository Git condiviso solo per i prompt e le istruzioni semplicemente non è sufficiente. Sebbene coordini le istruzioni locali, genera modelli simili, perché un agente ha bisogno di altri due elementi fondamentali che rimangono non condivisi: strumenti e dati.
Immaginate tre team, ognuno dei quali configura in modo indipendente le proprie connessioni agli stessi strumenti infrastrutturali (Git, CI/CD, IaaS), agli stessi strumenti applicativi (CRM, SCM, ERP) e agli stessi dati in tempo reale. Questa non è standardizzazione, è la ricetta perfetta per un’IA caotica: nessuna integrazione standard, una totale perdita di governance della sicurezza, dati estratti localmente al di fuori di qualsiasi policy e semantica mancante perché nessuno ha acquisito i metadati che avrebbero reso il tutto riutilizzabile. La conseguenza sono violazioni dei dati e vulnerabilità che compromettono sia la sicurezza che la conformità.
Il Context Catalog: dal caos delle connessioni alla gestione del contesto
Se istruzioni, strumenti e dati devono essere condivisi (e gestiti) insieme, è necessario un livello che si trovi al di sopra di tutti e tre e al di sopra di ogni team. Questo livello è il Context Catalog: una mappa governata di metadati IA che:
- Importa la semantica della vostra infrastruttura, delle applicazioni e dei dati;
- Centralizza tutte le relazioni tra team, applicazioni, dati e ambienti;
- Configura accessi e privilegi centralizzati.
In sostanza, definisce il contesto aziendale di base, sul quale è possibile configurare degli AI Playbook, o “template di contesto”, facilmente accessibili dagli sviluppatori di tutti i team.
Questa è la differenza tra un prompt di sistema e una mappa cognitiva. Un prompt dice a un agente cosa rispondere. Un catalogo di contesto specifica a un agente qual è la tua attività, la tua architettura e le tue regole, sempre allo stesso modo, per ogni agente che lo chiede.
Il risparmio non è astratto. Invece di un agente che compone al volo la relazione tra un’API, il suo gateway, il pod, il cluster, i suoi log, metriche e allarmi, il repository sorgente, la pipeline e il microservizio tramite chiamate MCP ogni singola volta, l’agente interroga il catalogo una sola volta. Tale relazione è già mappata, in tempo reale, deterministica e consente di risparmiare circa l’80% dei token che altrimenti verrebbero utilizzati per ricostruire il contesto prima ancora che l’attività abbia inizio.
Come il Context Catalog ti aiuta a risparmiare token, tempo e denaro
Affidarsi a un grafo della conoscenza come un catalogo governato anziché alla composizione estemporanea è il punto di partenza per una serie più ampia di strategie per il controllo dei token e dei costi:
- Sostituite le integrazioni punto a punto con un server MCP unificato che esegue flussi di lavoro infrastrutturali/DevOps predefiniti e accede a risorse esterne al catalogo solo quando necessario.
- Filtrate localmente i dati che raggiungono l’LLM, raggruppando le righe di log ripetitive in un singolo indicatore di riepilogo, comprimendo il codice sorgente con l’eliminazione delle righe contenenti solo commenti e riducendo i payload JSON di grandi dimensioni al loro nucleo essenziale.
- Estraete informazioni strutturate dalla risposta di un modello utilizzando la memoria locale e la cache per gestire le richieste ripetute senza dover pagare chiamate LLM aggiuntive.
- Bloccate gli agenti in loop utilizzando un interruttore automatico che rileva payload ripetitivi, riscritture di file ridondanti o errori ricorrenti.
- Valutate ogni sessione tramite un ciclo di feedback che collega i risultati alle metriche DORA e misura il valore esatto fornito per token.
- Raggruppate agenti, strumenti, competenze e filtri in AI Playbook riutilizzabili per evitare di reinventare problemi già risolti, sia per gli sviluppatori che per gli agenti. Gli agenti possono anche individuare e selezionare automaticamente il modello con il punteggio più alto per ogni attività.
- Chiudete il cerchio con l’LLM FinOps confrontando modelli, piani e costi. La selezione del modello è la conseguenza di una decisione controllata anziché di un’impostazione predefinita.
Come Mia-Platform sfrutta il Context Catalog
Portare un catalogo governato e template di contesto dalla teoria alla produzione richiede un approccio architetturale che consenta l’orchestrazione dei metadati, l’ottimizzazione dei token e la governance degli agenti senza creare silos tecnologici.
Questo è il modello su cui si basa Mia-Platform: un Context Catalog e un set personalizzabile di AI Playbook, condivisi da chiunque svolga il lavoro. Uno sviluppatore che scrive codice, un platform engineer che definisce le policy e un tecnologo aziendale che crea prototipi in linguaggio naturale: tutti lavorano sperimentando e scalando all’interno dello stesso contesto. Nessuno passa a una fonte di verità diversa a metà del processo.
Nello specifico, tale architettura comprende:
- Un’app del Catalogo che mantiene sincronizzati asset e team aziendali in un’unica mappa di metadati.
- Un’app AI Foundry per orchestrare e ottimizzare gli AI Playbook in diversi ambienti.
- Un livello di esecuzione dei Playbook che li esegue ovunque il team lavori, sia all’interno della web-app Flow di Mia-Platform che in un IDE esterno.
Alla base, tre orchestratori (AI-Ready API per la registrazione sicura degli strumenti, Fast Data per il disaccoppiamento dei dati in tempo reale e IDP/Console per fornire l’environment as a service) mantengono il catalogo connesso ad API reali, dati reali e infrastrutture reali, così che il contesto aziendale non rimanga mai un semplice diagramma.
In breve
L’istinto alla base del vibe coding non è mai stato sbagliato: gli sviluppatori vogliono velocità e l’IA la offre davvero. Il problema sta nel presupposto che un prompt di sistema intelligente possa sostituire la conoscenza effettiva del business, dell’architettura e delle regole. Non è così. Tale conoscenza deve risiedere in un luogo governato e condiviso, altrimenti ogni team si ritrova a pagare ripetutamente il costo individuale, e l’organizzazione finisce per avere un groviglio di codice IA invece di sfruttarne appieno il potenziale.
Un Context Catalog basato su metadati IA governati è proprio questa struttura. Trasforma istruzioni, strumenti e dati in un unico livello gestito e ogni problema risolto in un AI Playbook riutilizzabile, anziché in un suggerimento isolato che qualcun altro dovrà riscrivere ogni due mesi. Questa è la differenza tra uno strumento di IA che costa token e un sistema di IA che li restituisce. Ecco perché il catalogo è ciò che abilita davvero l’ingegneria agentica per un moderno ciclo di vita del software.
