Chi si intende un po ‘ del mondo Marvel sa che il Jarvis originale era in realtà un personaggio in carne ed ossa che si chiamava appunto come il classico maggiordomo inglese, mentre Ultron nasce come un androide e nei primi episodi dimostra tutto tranne di essere molto intelligente.
Nei reboot dei film, per aggiornarli un pò, la storia è stata mescolata non poco, mettendo in mezzo AI, reti e androidi sintetici, il risultato è stato metterli l’uno contro l’altro finché Jarvis, trasformatosi in Visione, non vince beccandosi anche la ragazza (Wanda Maximoff signore e signori, ma questa è un’altra storia).
Fatto sta che vederli protagonisti di un talk mi ha dato una certa emozione e mi ha caricato di aspettative, che non sono andate deluse.
Infatti a Codemotion Roma 2026 uno dei messaggi più lucidi sul futuro dell’intelligenza artificiale non è arrivato da un nuovo modello, ma da una riflessione molto più concreta: cosa succede quando l’AI esce dalla demo ed entra davvero nei sistemi aziendali.
Nel talk “LLM senza MCP è solo una demo: costruire Jarvis senza creare Ultron”, Giuseppe Porro e Antonio Carito di DXC Technology hanno affrontato uno dei punti più sottovalutati dell’AI enterprise: il problema non è il modello. È tutto ciò che gli sta intorno.
E, soprattutto, è il modo in cui quel modello si collega — o non si collega — al resto del sistema.
Il momento in cui la demo smette di funzionare
C’è un pattern che chi lavora con l’AI riconosce subito.
La demo funziona perfettamente. Il modello risponde bene, genera codice, scrive testi coerenti, sembra “capire” il contesto. Poi arriva il momento della verità: integrazione nei sistemi reali.
Database aziendali, repository, API legacy, policy di sicurezza, workflow di rilascio.
È lì che qualcosa si rompe.
Non perché il modello sia scarso, ma perché è isolato. Non ha accesso al contesto giusto, non conosce le regole del dominio, non può interagire in modo strutturato con gli strumenti che definiscono il lavoro quotidiano di un team.
Il risultato è un sistema che in demo sembra intelligente, ma in produzione diventa fragile, incoerente, difficile da governare.
Il vero salto evolutivo: dal modello al protocollo
Il cuore del talk sta tutto in questo passaggio di prospettiva: il salto evolutivo non è nel modello, ma nel modo in cui lo colleghiamo al mondo reale.
Qui entra in gioco il Model Context Protocol (MCP).
Non come buzzword, ma come risposta concreta a un problema strutturale: permettere agli LLM di interagire con dati, strumenti e servizi esterni in modo standardizzato, controllato e sicuro.
In altre parole, trasformare un modello che “parla bene” in un sistema che agisce dentro un ecosistema.
Con MCP, l’AI non lavora più nel vuoto. Può interrogare database, utilizzare tool, comprendere il contesto applicativo e operare all’interno dei vincoli reali dell’organizzazione.
È il passaggio da un’intelligenza simulata a un’intelligenza operativa.
Quando l’AI entra davvero nel flusso di sviluppo
La parte più interessante della sessione non è stata teorica, ma pratica.
Porro e Carito hanno mostrato come questo approccio si traduca in scenari concreti, molto vicini alla quotidianità degli sviluppatori.
Nel primo caso, l’AI viene integrata direttamente nell’ambiente di sviluppo per generare automaticamente test a partire dal codice reale del progetto. Non suggerimenti generici, ma output coerenti con le classi, le dipendenze e la struttura effettiva dell’applicazione.
Nel secondo scenario, l’intelligenza artificiale entra nel processo di revisione del codice. Non come semplice linting avanzato, ma come agente capace di analizzare modifiche, comprendere il contesto e suggerire miglioramenti in linea con le pratiche del team.
Il punto non è automatizzare singole attività, ma portare l’AI dentro il ciclo reale dello sviluppo software.
Jarvis vs Ultron: una metafora che funziona
Il titolo del talk non è casuale.
“Costruire Jarvis senza creare Ultron” è una sintesi efficace di una tensione che oggi attraversa tutto il mondo IT.
Da un lato c’è la paura che l’AI sostituisca lo sviluppatore. Dall’altro, la realtà operativa mostra qualcosa di diverso: l’AI elimina lavoro ripetitivo, riduce il carico cognitivo e libera tempo per attività a maggior valore.
Boilerplate, verifiche manuali, task ripetitivi: sono questi i primi candidati all’automazione.
Quello che resta — architettura, modellazione del dominio, scelte progettuali — diventa ancora più centrale.
L’AI, in questo scenario, non è un sostituto. È un amplificatore.
Non costruisci un Ultron che agisce da solo. Costruisci un Jarvis che lavora con te.
Il problema reale: integrazione, non intelligenza
Se c’è un takeaway forte da portarsi via da Codemotion è questo: l’AI non fallisce per limiti di intelligenza, ma per limiti di integrazione.
Le aziende non hanno bisogno solo di modelli più potenti. Hanno bisogno di sistemi che sappiano:
- accedere ai dati giusti
- rispettare le regole di business
- interagire con strumenti esistenti
- operare dentro workflow complessi
È qui che si gioca la partita.
E infatti le stesse dinamiche emergono anche nelle piattaforme enterprise. Soluzioni come Red Hat OpenShift AI, Red Hat Ansible Lightspeed o Red Hat Developer Hub vanno esattamente in questa direzione: non aggiungere AI sopra il sistema, ma integrarla dentro il sistema.
Oltre l’hype, verso l’AI in produzione
Codemotion Roma 2026 ha mostrato chiaramente una cosa: siamo oltre la fase dell’hype. Non si parla più di “cosa può fare un LLM”, ma di come renderlo utile in produzione.
Il passaggio è sottile, ma decisivo.
Finché l’AI resta una demo, è spettacolare ma marginale. Quando entra nei sistemi aziendali, diventa infrastruttura. E a quel punto cambia tutto.
Perché non stai più sperimentando una tecnologia. Stai ridisegnando il modo in cui si costruisce software.
