Refactoring alla velocità richiesta dalle esigenze operative: un approccio "agent mesh" alla modernizzazione dei sistemi esistenti con Red Hat AI

Il software obsoleto non si fa da parte. Si trova in produzione, accumula debito tecnico, resiste al cambiamento e diventa un rischio, non a causa di ciò che fa, ma a causa di ciò che non è più in grado di supportare.

È la sfida che affrontano i principali system integrator (SI) a supporto della pubblica amministrazione e dell'industria. In un portafoglio di applicazioni di importanza critica, gli SI e le aziende del settore aerospaziale gestiscono codebase Python e Java obsolete che devono passare a una base moderna, incentrata sulla sicurezza e supportabile, in particolare a Red Hat Enterprise Linux 10 (RHEL 10).

L'obiettivo non è solo l'aggiornamento del software. È necessario mantenere la velocità di distribuzione del software, la velocità dell'IA e il livello di sicurezza da cui dipendono i data center governativi, le aree di missione con deployment avanzato e i sistemi mobili sugli aerei.

Non si tratta di una questione teorica per il governo federale degli Stati Uniti. Il framework per la governance dell'IA della GSA e il Department of War (DoW) ora richiedono alle agenzie e ai servizi realizzare un'IA responsabile, anziché adottarla semplicemente. Nel campo delle missioni e della difesa, tale obbligo non è una semplice casellina da spuntare, ma un elemento trainante per ottimizzare la software factory prima di poter affidare compiti importanti agli agenti al suo interno. 

Durante una recente collaborazione, uno dei requisiti essenziali era la piena compatibilità offline. Gli ambienti a supporto della sicurezza nazionale spesso non dispongono dell'accesso a Internet fin dalla progettazione. Qualsiasi dipendenza da un servizio esterno (GitHub, un'API cloud, un registro di pacchetti remoto) può diventare una vulnerabilità, un punto di errore o rendere il sistema del tutto non conforme. 

La modernizzazione manuale del sistema era tecnicamente possibile, ma l'impegno ingegneristico stimato richiedeva anni di lavoro, rendendo l'approccio impraticabile per la scalabilità necessaria. L'alternativa era non fare nulla e continuare a utilizzare sistemi obsoleti, con rischi operativi sempre maggiori. A quel punto ci siamo chiesti se esistesse un altro modo: avremmo potuto creare un processo più efficiente utilizzando l'automazione basata sugli agenti, per consentire agli ingegneri di supervisionare la modernizzazione in modo scalabile anziché eseguire ogni passaggio manualmente?

È emerso che era possibile, quindi abbiamo realizzato una piattaforma basata sugli agenti, utilizzando Red Hat AI e Red Hat OpenShift AI.

Il problema della modernizzazione scalabile del software obsoleto

Una migrazione di tipo brownfield, ovvero il passaggio del codice di produzione reale (e non di un proof of concept (POC) greenfield), è fondamentalmente diversa dalla creazione di qualcosa di nuovo. Non basta inviare un prompt a un'IA per considerare il lavoro finito.

Spesso, i codebase obsoleti presentano alcune caratteristiche.

• Architetture obsolete: sistemi progettati in base a supposizioni, framework e infrastrutture che riflettono le norme ingegneristiche di un'epoca precedente.
• Copertura dei test limitata o non uniforme: ampie porzioni del codebase sono state scritte prima che i test automatizzati diventassero una disciplina standard.
• Contratti comportamentali impliciti: dipendenze tra moduli e servizi che esistono nella pratica, ma che non sono mai state documentate o applicate formalmente.
• Debito tecnico accumulato: stratificazioni di soluzioni alternative, librerie obsolete e correzioni di compatibilità che sono diventate gradualmente parte del sistema di produzione.

Per le missioni di sicurezza nazionale, le conseguenze di un errore non sono astratte. Una migrazione non riuscita non si limita a danneggiare un'applicazione. Può infatti bloccare un flusso di lavoro, ritardare una missione o introdurre una vulnerabilità di sicurezza in un'infrastruttura che protegge le persone.

Questo è esattamente l'ambiente in cui i modelli di frontiera di grandi dimensioni per scopi generali, eseguiti tramite un'API cloud, non sono un'opzione. Non si può inviare codice sensibile a un endpoint esterno. Non è possibile tollerare comportamenti di inferenza imprevedibili su larga scala. Anche potendo connettersi ai modelli di frontiera del cloud, non sarebbe possibile giustificare il volume di token e l'overhead di calcolo quando le richieste si estendono diventando lunghe catene di ragionamento su spazi dei parametri enormi. A livello di migrazione, dove i sistemi contengono milioni di righe di codice, questo si traduce rapidamente in latenza, costi infrastrutturali e aumento del rischio operativo.

Perché i modelli piccoli ed efficienti sono lo strumento giusto

L'istinto, nella maggior parte delle applicazioni di IA, è quello di puntare sul modello più grande disponibile. Più parametri significa più contesto e quindi risposte migliori. Questa logica decade rapidamente negli ambienti disconnessi, di importanza critica e con risorse limitate. I modelli di frontiera di grandi dimensioni spesso introducono una latenza eccessiva, cicli di ragionamento imprevedibili e richieste di memoria GPU significative, difficili da supportare in un'infrastruttura controllata.

I modelli linguistici di piccole dimensioni (SLM) sono ideali per i flussi di lavoro agentici, perché questi sistemi richiedono un'esecuzione affidabile e ripetibile e risposte a bassa latenza, non solo la semplice scalabilità del modello. I modelli più piccoli possono offrire un comportamento rapido e deterministico che funziona bene per attività di automazione come la chiamata di strumenti, l'orchestrazione e il ragionamento strutturato. Inoltre, sono più facili da sottoporre a fine tuning e da gestire in locale, consentendo ai team di distribuire flotte di agenti specifici per il dominio senza dipendere da endpoint esterni. In altre parole, quando un modello "conosce" bene un solo dominio, la distribuzione di probabilità diventa più netta e tende a produrre la stessa risposta più spesso.

Detto questo, dai nostri test è emerso che la capacità del modello è ancora strettamente correlata alla lunghezza del contesto e al numero di parametri, in particolare per le attività di migrazione del codice che richiedono la comprensione di sistemi software complessi. I modelli che hanno ottenuto buoni risultati nei primi test sono stati le varianti Llama 4 e i modelli Claude, in gran parte grazie alle finestre di contesto molto ampie (>256.000 token) e alla forte capacità di ragionamento. Al contrario, abbiamo riscontrato che a volte Claude complicava eccessivamente semplici attività di engineering, producendo catene di ragionamento inutilmente lunghe che aumentano l'utilizzo dei token e la latenza. Su larga scala, questo comportamento si traduce rapidamente in costi di elaborazione significativi.

Per questo motivo, attualmente eseguiamo Meta Maverick in locale, con test paralleli che utilizzano modelli Mistral a causa dei requisiti di memoria GPU dei modelli più grandi. Stiamo inoltre rivalutando Llama 4 Scout, che offre buone prestazioni, ma allo stesso modo spinge al limite le risorse di calcolo disponibili nell'attuale ambiente.

Come soluzione pratica, abbiamo implementato una strategia di modelli ibridi che utilizza modelli più piccoli ed esegue il refactoring dei flussi di lavoro per mitigare le limitazioni del contesto man mano che si presentano.

I modelli attualmente selezionati per l'harness dell'agente:

• mistralai/Devstral-Small-2-24B-Instruct: destinato agli agenti di codifica. Contesto da 256.000 token, prestazioni elevate nei benchmark di codifica, ottimizzato per l'analisi del software e le attività di refactoring.
• mistralai/Ministral-3-14B-Reasoning: destinato agli agenti non di codifica. Contesto da 256.000 token, efficace per il ragionamento strutturato, l'analisi delle dipendenze e l'orchestrazione tra i workflow di migrazione.

Oltre ai modelli di agente, il sistema utilizza modelli specializzati per l'indicizzazione e il recupero della conoscenza.

• gpt-oss-120B: utilizzato per creare il grafo della conoscenza GraphRAG che rappresenta la struttura globale del codebase
• intfloat/e5-mistral-7B-instruct: modello di embedding utilizzato per l'indicizzazione GraphRAG e il recupero dei vettori

Non si è trattato di scelte di compromesso. Si è trattato di decisioni ingegneristiche mirate, basate sull'ambiente di elaborazione disponibile. Le limitazioni di contesto che riscontriamo dipendono dalla capacità della GPU, non sono un vincolo dell'architettura stessa. Con la scalabilità dell'infrastruttura, anche l’harness degli agenti e la strategia di selezione del modello diventano scalabili.

L'architettura agent mesh: un harness per agenti basato su OpenShift AI

il cuore di questa piattaforma è un harness per agenti, un framework di orchestrazione modulare che coordina diversi agenti di IA specializzati, ciascuno responsabile di una parte specifica del flusso di lavoro di migrazione. Questo harness viene eseguito su OpenShift AI e sfrutta vLLM per un'inferenza del modello efficiente e a bassa latenza. Nel tempo, questo modello si evolve verso ciò che definiamo una agent mesh: un'architettura "harness of harnesses" con più flussi di lavoro agentici interoperabili, in grado di coordinare le attività e condividere lo stato tra complessi programmi di modernizzazione.

Ecco cosa fa oggi l'architettura.

Gli agenti di codifica — basati su Devstral — analizzano il codice sorgente legacy Python 2 o Java, identificano le API obsolete, generano equivalenti sottoposti a refactoring e producono test di caratterizzazione che acquisiscono il comportamento originale prima di qualsiasi modifica. Non si limitano a tradurre la sintassi, ma lavorano per preservare l'intento comportamentale.

Gli agenti non di codifica — basati su Ministral — svolgono attività di ragionamento nell'intero flusso di lavoro, inclusi la mappatura delle dipendenze, la pianificazione della migrazione e il monitoraggio dei progressi. La logica di orchestrazione deterministica governa il flusso di esecuzione, in modo che gli agenti si coordinino su ciò che è stato trasferito, convalidato o bloccato e su cosa dovrebbe accadere in seguito.

Un agente di gestione del tracciamento personalizzato gestisce l'integrazione con GitLab (e può essere rimosso completamente in ambienti disconnessi). Questo componente è codice completamente ispezionabile anziché una scatola nera, e per questo consente alle organizzazioni di integrare l’harness con i sistemi di sviluppo e governance esistenti.

L’harness stesso è progettato per garantire modularità e sostituibilità, combinando agenti personalizzati con agenti open source come OpenCode. Quando le organizzazioni chiedono se il sistema sia una scatola nera, la risposta onesta è sfumata: il livello di inferenza degli LLM, come qualsiasi rete neurale, è intrinsecamente opaco. Tuttavia, la logica di orchestrazione, il codice dell'agente, gli output e i percorsi decisionali sono completamente tracciabili, verificabili e ispezionabili, un aspetto fondamentale per le organizzazioni che operano in base ai requisiti di sicurezza e affidabilità del DoW.

vLLM, che funge da motore di inferenza all'interno di OpenShift AI, è un abilitatore fondamentale. L'inferenza efficiente non è solo un'ottimizzazione delle prestazioni: in ambienti con risorse GPU limitate, è ciò che rende praticabili i flussi di lavoro multi-agente. La distribuzione ottimizzata di vLLM consente alla piattaforma di gestire i cicli di ragionamento iterativi e in più passaggi richiesti per i flussi di lavoro di migrazione senza esaurire le risorse di elaborazione per una singola attività.

Con l’emergere di nuovi harness di agenti per attività annesse come test, revisione della sicurezza, generazione della documentazione o convalida del deployment, questi possono interconnettersi tramite l'agent mesh più ampia, consentendo un'automazione coordinata in tutte le pipeline di modernizzazione.

Il flusso di lavoro per la migrazione: prima Python, poi Java

La fase iniziale di questo progetto riguarda la migrazione da Python 2 a Python 3, che funge sia da risultato finale reale sia da convalida del framework. Python 2 ha raggiunto la fine del proprio ciclo di vita nel 2020 e i sistemi ancora in esecuzione su di esso presentano vulnerabilità prive di patch e nessun supporto upstream. Per i sistemi della pubblica amministrazione e delle aziende, questo non è un rischio teorico.

La nostra ipotesi, convalidata dai test, è che il costo della migrazione cambi in base alla complessità delle dipendenze esterne. Le applicazioni strettamente accoppiate a pacchetti di terze parti obsoleti richiedono molte più iterazioni tra agenti per eseguire una migrazione lineare. Questo aspetto ha influenzato la progettazione del modello: meno sotto-attività degli agenti per flusso, un ambito più ristretto per iterazione e passaggi di convalida più deterministici tra di esse.

Obiettivo a 30 giorni: 80% di copertura dei test, nessuna dipendenza GitLab richiesta, equivalenza funzionale convalidata tra le versioni di Python 2 e Python 3.

Figura 1: flusso di lavoro di software factory per agenti di codifica, agenti senza codifica e strumenti su OpenShift AI.

La roadmap di 30/60/90 giorni si sposta poi sulla migrazione di Java verso le versioni OpenJDK e Corretto (7, 8, 11, 17, 21) fino a Java 25, con percorsi di migrazione che variano a seconda che l'ambiente di destinazione sia RHEL 8 oppure RHEL 9 o 10. Vale la pena precisare che non esiste un pulsante magico e nemmeno una soluzione universale. Il framework di agenti è un punto di partenza e ogni agente al suo interno è creato appositamente per un'attività specifica nel flusso di lavoro di migrazione, il che lo rende estensibile a Java senza doverlo ricostruire da zero.

Misura ciò che conta davvero: KPI brownfield

Molti KPI di sviluppo software tradizionali e basati su agenti sono pensati per lo sviluppo greenfield. Presuppongono che tu conosca l'architettura, che tu abbia accesso alla documentazione e che tu stia realizzando qualcosa di nuovo. Premiano la velocità.

Nella migrazione del software legacy di tipo brownfield, la velocità senza accuratezza non porta risultati positivi, ma genera debito tecnico con la velocità dell'IA.

Il framework KPI che abbiamo definito per questa collaborazione si basa su tre domande.

Funziona? Tasso di equivalenza funzionale, percentuale di superamento dei test di integrazione, percentuale di errore delle modifiche. Si tratta di metriche go/no-go. Se il codice sottoposto a refactoring non produce gli stessi output dell'originale a parità di input, nient'altro conta.

Capiamo come funziona? Tasso di accettazione da parte di chi sviluppa, delta di copertura dei test, percentuale di completamento della migrazione. Una migrazione non si conclude solo perché il codice viene eseguito. Si conclude quando chi se ne occuperà potrà leggerlo, averne fiducia e gestirlo.

Il team è in grado di gestirlo a lungo termine? Punteggio di fiducia di chi sviluppa, tempo per il primo contributo, incremento della capacità del team di sviluppo. La metrica definitiva del ritorno sull'investimento (ROI) non è il costo dei token per attività. È il tempo che il team di ingegneria recupera dal lavoro di migrazione ripetitivo per concentrarsi su contributi di maggior valore per la missione.

Le metriche di velocità (throughput, latenza di iterazione, azioni dell'agente al minuto) devono comparire in una dashboard per la progettazione per ottimizzare il sistema. Non devono far parte della revisione del programma come unità di misura per il successo.

Cosa è possibile ottenere con Red Hat AI e OpenShift AI

Nulla di tutto ciò funziona senza una piattaforma in grado di supportarlo concretamente. OpenShift AI fornisce il livello base per tutto ciò che descriviamo di seguito.

• Model serving con vLLM: inferenza efficiente e scalabile per i modelli di codifica e ragionamento che alimentano l'harness dell’agente.
• Workflow di personalizzazione dei modelli: supporta fine-tuning, LoRA e quantizzazione per i modelli che devono essere eseguiti in ambienti con risorse limitate.
• Supporto per i cluster disconnessi: la piattaforma è progettata per l'esecuzione in ambienti senza accesso a Internet, un requisito fondamentale in questo ambito.
• Audit logging e osservabilità: tracciabilità e spiegabilità richieste dagli stakeholder della missione, integrate nella piattaforma anziché aggiunte in un secondo momento.
• Architettura modulare e containerizzata: gli agenti sono containerizzati, intercambiabili e distribuibili tramite l'infrastruttura OpenShift esistente, già nota a system integrator, aziende aerospaziali e governo federale.

Figura 2: componenti e funzionalità per creare agenti con Red Hat AI.

L'aggiunta di RHEL 10 come ambiente di runtime di destinazione non è casuale. RHEL 10 garantisce il rafforzamento della sicurezza, un supporto runtime aggiornato per i moderni Python e Java e l'affidabilità operativa richiesta dai sistemi governativi. La migrazione a RHEL 10 non è solo una decisione legata al ciclo di vita del software, ma riguarda la sicurezza e la tempestività delle missioni.

Il modello più ampio: agent mesh tra le diverse aree di missione

Questo progetto è un esempio di un modello che prevediamo di replicare nella base industriale della difesa, nel governo federale e nel settore in generale. I parchi software obsoleti sono vasti. Le risorse di ingegneria per eseguire la migrazione manuale non sono sufficienti per la portata del problema. Inoltre, la finestra di sicurezza per l'esecuzione di software non supportato si sta per chiudere.

Agentic AI su una piattaforma come OpenShift AI è un moltiplicatore di potenziale, che consente ai team di ingegneria esperti di supervisionare la migrazione di una codebase, che richiederebbe anni per essere modernizzata manualmente, in pochissimo tempo, con il rigore e la tracciabilità richiesti dagli ambienti di importanza critica.

In questo modello, gli harness degli agenti coordinano agenti specializzati per eseguire singole attività di modernizzazione. Man mano che questi sistemi si espandono a funzioni adiacenti (ad esempio test, revisione della sicurezza, convalida della distribuzione), iniziano a formare una agent mesh: un'architettura "harness-of-harnesses" che coordina flussi di lavoro di ingegneria complessi su un ampio numero di applicazioni software.

Gli agenti svolgono compiti ripetitivi. I team di ingegneria si occupano dell'architettura, della supervisione, della valutazione degli agenti e della gestione delle eccezioni. Questa divisione del lavoro rappresenta il modello.

Modelli di piccole dimensioni. Inferenza efficiente. Agenti modulari. Operatività in modalità disconnessa. Modernizzazione dei sistemi allineata alla missione.

Considerazioni finali

I modelli di frontiera sono straordinari motori di ragionamento. Le piattaforme agentiche create ad hoc sono strumenti fondamentali per le missioni.

Per le agenzie governative, non si tratta di adottare l'ultima tendenza dell'IA. Si tratta di disporre dell'infrastruttura e delle capacità di IA necessarie per mantenere i sistemi critici sicuri, moderni e al servizio della missione.

È ciò che stiamo realizzando con Red Hat AI.

Scopri di più

• Red Hat AI
• Red Hat OpenShift AI