Refactorización a la velocidad de la misión: Un enfoque de "malla de agentes" para la modernización de sistemas heredados con Red Hat AI

El software heredado no se retira por sí solo. Permanece en producción, acumula deuda técnica, se resiste al cambio y se convierte silenciosamente en un riesgo, no por lo que hace, sino por lo que ya no puede soportar.

Este es el desafío al que se enfrentan los principales integradores de sistemas (SI) que trabajan para respaldar al gobierno y al sector industrial. En una cartera de aplicaciones de misión crítica, los SI y las empresas aeroespaciales gestionan bases de código Python y Java antiguas que deben trasladarse a una base moderna, centrada en la seguridad y con soporte: específicamente, Red Hat Enterprise Linux 10 (RHEL 10).

El objetivo no es solo realizar una actualización de software. Se trata de mantener la velocidad de entrega de software, la velocidad de la inteligencia artificial y la postura de seguridad de las que dependen los centros de datos gubernamentales, las áreas de misión desplegadas en posiciones avanzadas o los sistemas móviles en aeronaves.

Esto no es algo teórico para el gobierno federal de los Estados Unidos. El marco de gobernanza de la inteligencia artificial de la GSA y el Departamento de Guerra (DoW) ahora exigen que los organismos y servicios pongan en funcionamiento una inteligencia artificial responsable, no solo que la adopten. Para los responsables de defensa y misión, ese mandato no es un mero trámite administrativo, sino un motor de cambio para optimizar la fábrica de software antes de confiar en los agentes que la integran para cualquier tarea crítica. 

Durante una colaboración reciente, uno de los requisitos estrictos era la compatibilidad total sin conexión. Los entornos que respaldan la seguridad nacional suelen carecer de acceso a internet por diseño. Cualquier dependencia de un servicio externo (GitHub, una API de nube o un registro de paquetes remoto) constituye un vínculo que puede convertirse en una vulnerabilidad, en un punto de falla o en un motivo para que el sistema incumpla radicalmente las normativas. 

Modernizar el sistema manualmente era técnicamente posible, pero el esfuerzo de ingeniería estimado requería años de trabajo humano, lo que lo hacía inviable a la escala necesaria. La alternativa era no hacer nada y continuar operando sistemas antiguos con un riesgo operativo cada vez mayor. Entonces surgió la duda de si existía un tercer camino: ¿podríamos crear un proceso más eficiente utilizando la automatización con agentes, que permitiera a los ingenieros supervisar la modernización a escala en lugar de realizar cada paso manualmente?

Resulta que sí podíamos, y diseñamos una plataforma con agentes utilizando Red Hat AI y Red Hat OpenShift AI.

El problema de la modernización de sistemas heredados a escala

La migración de infraestructuras existentes (brownfield), es decir, el traslado de código de producción real y no una prueba de concepto (POC) desde cero (greenfield), es fundamentalmente diferente a la creación de algo nuevo. No puedes simplemente darle instrucciones a una inteligencia artificial y dar el trabajo por terminado.

Las bases de código heredadas suelen caracterizarse por lo siguiente:

• Arquitecturas antiguas: Sistemas diseñados en torno a suposiciones, marcos e infraestructuras que reflejan las normas de ingeniería de una era anterior.
• Cobertura de prueba limitada o desigual: Los desarrolladores crearon gran parte de la base de código antes de que las pruebas automatizadas se convirtieran en una práctica estándar.
• Contratos implícitos de comportamiento: Dependencias entre los módulos y los servicios que existen en la práctica, pero que nunca se documentaron ni aplicaron formalmente.
• Deuda técnica acumulada: Capas de soluciones provisionales, bibliotecas obsoletas y correcciones de compatibilidad que se han convertido gradualmente en parte del sistema de producción.

En el caso de las misiones de seguridad nacional, los riesgos de cometer un error en este proceso no son abstractos. Una migración fallida no solo rompe una aplicación, sino que también puede paralizar un flujo de trabajo, retrasar una misión o introducir una vulnerabilidad de seguridad en la infraestructura que protege a las personas.

Este es exactamente el entorno en el que los modelos de vanguardia grandes y de uso general que se ejecutan detrás de una API en la nube no son una opción. No puedes enviar código confidencial a un endpoint externo. No puedes tolerar un comportamiento de inferencia impredecible a escala. Incluso si pudieras conectarte a modelos de vanguardia en la nube, no puedes justificar el volumen de tokens y la sobrecarga de procesamiento cuando las solicitudes se expanden en largas cadenas de razonamiento en espacios de parámetros masivos. En la migración a gran escala, donde los sistemas contienen millones de líneas de código, esto se traduce rápidamente en latencia, costos de infraestructura y mayor riesgo operativo.

Por qué los modelos pequeños y eficientes son el instrumento adecuado

En la mayoría de las aplicaciones de inteligencia artificial, la tendencia es utilizar el modelo más grande disponible. Más parámetros, más contexto, mejores respuestas. Esa lógica se desmorona rápidamente en entornos desconectados, de misión crítica y con recursos limitados. Los modelos de vanguardia de gran tamaño suelen presentar una latencia excesiva, ciclos de razonamiento impredecibles y demandas considerables de memoria de GPU que son difíciles de satisfacer en una infraestructura controlada.

Los modelos de lenguaje pequeños (SLM, Small Language Models) son ideales para los flujos de trabajo con agentes porque estos sistemas requieren una ejecución confiable y repetible y respuestas de baja latencia, no solo el escalado masivo del modelo. Los modelos más pequeños pueden ofrecer un comportamiento rápido y determinista que funciona bien para tareas de automatización, como la llamada a herramientas, la orquestación y el razonamiento estructurado. Además, es más fácil ajustarlos y utilizarlos de manera local, lo cual permite que los equipos implementen flotas de agentes específicos de un dominio sin depender de endpoints externos. En otras palabras, cuando un modelo solo "conoce" bien un dominio, la distribución de probabilidad se vuelve más nítida y tiende a producir la misma respuesta con más frecuencia.

Dicho esto, nuestras pruebas revelaron que la capacidad del modelo aún se correlaciona fuertemente con la longitud del contexto y la cantidad de parámetros, especialmente para las tareas de migración de código que requieren comprender sistemas de software de gran tamaño. Los modelos que tuvieron un buen desempeño en las pruebas iniciales fueron las variantes de Llama 4 y los modelos Claude, debido principalmente a sus amplias ventanas de contexto (más de 256000 tokens) y su gran capacidad de razonamiento. Por el contrario, descubrimos que Claude a veces analizaba en exceso las tareas de ingeniería sencillas, lo que generaba cadenas de razonamiento innecesariamente largas que aumentaban el uso de tokens y la latencia. En la escala de la migración, ese comportamiento se convierte rápidamente en un costo de procesamiento significativo.

Por este motivo, actualmente ejecutamos Meta Maverick de forma local, con pruebas paralelas con modelos Mistral debido a los requisitos de memoria de GPU de los modelos más grandes. También reevaluamos Llama 4 Scout, que funciona bien, pero que también supera los límites de la capacidad informática disponible en el entorno actual.

Como solución práctica, implementamos una estrategia de modelos híbridos que utiliza modelos más pequeños y refactoriza los flujos de trabajo para reducir las limitaciones del contexto a medida que aparecen.

Nuestras selecciones actuales de modelos para el arnés de agentes:

• mistralai/Devstral-Small-2-24B-Instruct: Asignado a agentes de codificación. Contexto de 256000 tokens, rendimiento sólido en pruebas de rendimiento de codificación, optimizado para el análisis de software y tareas de refactorización.
• mistralai/Ministral-3-14B-Reasoning: Asignado a agentes que no realizan tareas de codificación. Contexto de tokens de 256000, eficaz para el razonamiento estructurado, el análisis de dependencias y la orquestación de los flujos de trabajo de migración.

Además de los modelos de agentes, el sistema utiliza modelos especializados para la indexación y la recuperación de conocimientos:

• gpt-oss-120B: Crea el grafo de conocimiento GraphRAG que representa la estructura global del código base.
• intfloat/e5-mistral-7B-instruct: Modelo integrado utilizado para la indexación de GraphRAG y la recuperación de vectores.

No fueron decisiones de compromiso. Fueron decisiones de ingeniería diseñadas para un propósito específico basadas en el entorno de computación disponible. Las limitaciones de contexto que encontramos dependen de la capacidad de la GPU, no de una restricción de la arquitectura en sí. A medida que la infraestructura escala, el sistema de gestión de agentes y la estrategia de selección de modelos pueden escalar con ella.

La arquitectura de la malla de agentes: Un "arnés de arneses" de inteligencia artificial con agentes basado en OpenShift AI

El núcleo de esta plataforma es un arnés de inteligencia artificial con agentes, un marco de orquestación modular que coordina varios agentes de inteligencia artificial especializados, cada uno responsable de una parte específica del flujo de trabajo de migración. Este arnés se ejecuta en OpenShift AI y utiliza vLLM para lograr una inferencia de modelos eficiente y de baja latencia. Con el tiempo, este patrón evoluciona hacia lo que describimos como una malla de agentes: una arquitectura de "arnés de arneses" donde varios flujos de trabajo de inteligencia artificial con agentes pueden interoperar, coordinar tareas y compartir estados en programas de modernización complejos.

Esto es lo que hace la arquitectura en la actualidad:

Agentes de codificación —basados en Devstral— analizan el código fuente heredado de Python 2 o Java, identifican las API obsoletas, generan equivalentes refactorizados y crean pruebas de caracterización que capturan el comportamiento original antes de aplicar cambios. No solo traducen la sintaxis, sino que trabajan para preservar la intención del comportamiento.

Los agentes que no son de codificación —basados en Ministral— realizan tareas de razonamiento en todo el flujo de trabajo, lo que incluye el mapeo de dependencias, la planificación de la migración y el seguimiento del progreso. La lógica de orquestación determinista rige el flujo de ejecución, por lo que los agentes coordinan lo que se ha migrado, validado o bloqueado, así como los siguientes pasos.

Un agente de gestión de seguimiento personalizado gestiona la integración con GitLab (y puede sustituirse por completo en entornos desconectados). Este componente es código totalmente inspeccionable en lugar de una caja negra, lo que permite que las organizaciones integren el arnés con sus sistemas de desarrollo y gobernanza actuales.

El propio arnés está diseñado para ofrecer modularidad y capacidad de sustitución, al combinar agentes personalizados con agentes open source como OpenCode. Cuando las organizaciones preguntan si el sistema es una caja negra, la respuesta sincera tiene matices: la capa de inferencia de los LLM, como cualquier red neuronal, es intrínsecamente opaca. Sin embargo, la lógica de orquestación, el código de los agentes, los resultados y los registros de decisiones son totalmente rastreables, auditables e inspeccionables, lo cual es fundamental para las organizaciones que operan bajo los requisitos de seguridad y garantía de DoW.

vLLM, que funciona como motor de inferencia dentro de OpenShift AI, es un facilitador fundamental. La inferencia eficiente no es solo una optimización del rendimiento; en entornos con recursos de GPU limitados, es lo que hace que los flujos de trabajo de varios agentes sean viables. El servicio optimizado de vLLM permite que la plataforma gestione los ciclos de razonamiento iterativos de varios pasos necesarios para los flujos de trabajo de migración sin agotar los recursos de computación en una sola tarea.

A medida que surgen más arneses de inteligencia artificial con agentes para tareas adyacentes, como pruebas, revisiones de seguridad, generación de documentación o validación de implementaciones, estos arneses pueden interconectarse a través de la malla de agentes más amplia, lo que permite una automatización coordinada en todos los procesos de modernización.

El flujo de trabajo de migración: Primero Python, luego Java

La fase inicial de esta iniciativa se centra en la migración de Python 2 a Python 3, lo que sirve como un entregable real y como validación del marco. Python 2 llegó al final de su vida útil en 2020, y los sistemas que aún se ejecutan en él funcionan con vulnerabilidades sin parches y sin soporte upstream. Para los sistemas gubernamentales y empresariales, este no es un riesgo teórico.

Nuestra hipótesis, validada en las pruebas, es que el costo de la migración aumenta con la complejidad de la dependencia externa. Las aplicaciones que están estrechamente vinculadas a los paquetes obsoletos de terceros requieren muchas más iteraciones de agentes para migrar sin problemas. Esto influyó en el diseño del modelo: menos subtareas de inteligencia artificial con agentes por flujo, alcances más estrictos por iteración y más pasos de validación deterministas entre ellos.

El objetivo a 30 días: 80 % de cobertura de las pruebas, no se requiere dependencia de GitLab y validación de la equivalencia funcional entre las versiones de Python 2 y Python 3.

Figura 1: Flujo de trabajo de la fábrica de software de inteligencia artificial con agentes: agentes de codificación, agentes de otros tipos y herramientas en OpenShift AI.

Luego, el plan de 30/60/90 días se centra en la migración de Java con el objetivo de las versiones de OpenJDK y Corretto (7, 8, 11, 17, 21) hacia Java 25, con planes de migración que difieren según si el entorno de destino es RHEL 8 o RHEL 9/10. Vale la pena aclarar que esto no es un botón mágico o una solución única para todos. El marco de inteligencia artificial con agentes es un punto de partida, y cada agente que se incluye se diseñó para una tarea concreta en el flujo de trabajo de migración, que es exactamente lo que lo hace extensible a Java sin tener que volver a diseñarlo desde cero.

Medir lo que realmente importa: Indicadores clave de rendimiento (KPI) de entornos existentes

Muchos de los indicadores clave de rendimiento (KPI) del desarrollo de software tradicional y de inteligencia artificial con agentes están diseñados para el desarrollo de proyectos nuevos. Suponen que conoces la arquitectura, tienes acceso a la documentación y estás construyendo algo nuevo. Recompensan la velocidad.

En la migración de sistemas heredados en entornos existentes, la velocidad sin corrección no es un éxito, sino la generación de deuda técnica a la velocidad de la inteligencia artificial.

El marco de los KPI que definimos para esta colaboración se organiza en torno a 3 preguntas:

¿Funciona? Tasa de equivalencia funcional, tasa de aprobación de las pruebas de integración y tasa de errores en los cambios. Estas son métricas de aprobación o rechazo. Si el código refactorizado no produce resultados idénticos al original con entradas idénticas, nada más importa.

¿Entendemos cómo funciona? Tasa de aceptación de los desarrolladores, delta de cobertura de las pruebas y tasa de finalización de la migración. La migración no finaliza cuando se ejecuta el código. Se completa cuando los desarrolladores responsables pueden leerla, confiar en ella y mantenerla.

¿El equipo puede mantenerla a largo plazo? Puntuación de confianza del desarrollador, tiempo transcurrido hasta la primera contribución y aumento de la capacidad del equipo. La métrica del retorno de la inversión (ROI) final no es el costo de tokens por tarea. Es la cantidad de tiempo que el equipo de ingeniería recupera del trabajo de migración repetitivo para centrarse en las contribuciones de mayor valor a la misión.

Las métricas de velocidad (el rendimiento, la latencia de las iteraciones y las acciones de los agentes por minuto) pertenecen a un panel de ingeniería para ajustar el sistema. No deben incluirse en una revisión del programa como medidas de éxito.

Lo que Red Hat AI y OpenShift AI hacen posible

Nada de esto funciona sin una plataforma que realmente pueda respaldarlo. OpenShift AI proporciona la capa base para todo lo que se describe aquí:

• Distribución de modelos con vLLM: Inferencia eficiente y escalable para los modelos de codificación y razonamiento que impulsan el marco de agentes.
• Flujos de trabajo de personalización de modelos: Soporte para el ajuste fino, LoRA y cuantificación de los modelos que deben ejecutarse en entornos con recursos limitados.
• Compatibilidad con clústeres desconectados: La plataforma está diseñada para ejecutarse en entornos sin acceso a Internet, lo cual es un requisito básico en este caso.
• Registro de auditoría y observabilidad: La trazabilidad y la explicabilidad que requieren las partes interesadas de la misión, integradas en la plataforma en lugar de añadirse a posteriori.
• Arquitectura modular en contenedores: Los agentes están basados en contenedores, son intercambiables y se pueden implementar a través de la infraestructura existente de OpenShift que los integradores de sistemas, las empresas aeroespaciales y el gobierno federal ya conocen.

Figura 2:  Componentes y funciones para la creación de agentes con Red Hat AI.

La incorporación de RHEL 10 como entorno de ejecución de destino no es casual. Red Hat Enterprise Linux (RHEL) 10 ofrece refuerzo de seguridad, compatibilidad con tiempos de ejecución actualizados para Python y Java modernos, y la confiabilidad operativa que requieren los sistemas gubernamentales. La migración no es solo una decisión sobre el ciclo de vida del software, es una decisión sobre la seguridad y la preparación de la misión.

El patrón general: Malla de agentes en las áreas de misión

Esta iniciativa es un ejemplo de algo que esperamos repetir en la base industrial de defensa, el gobierno federal y la industria en general. Los entornos de software heredados son enormes. Los recursos de ingeniería para migrarlos manualmente no existen a la escala que exige el problema. Y el plazo de seguridad para ejecutar software sin soporte se está cerrando.

La inteligencia artificial con agentes en una plataforma como OpenShift AI es un multiplicador de fuerzas que permite que un equipo de ingeniería capacitado supervise la migración de una base de código que llevaría años modernizar de forma manual, en una fracción del tiempo, con el rigor y la trazabilidad que los entornos de misión crítica requieren.

En este modelo, los arneses de inteligencia artificial con agentes coordinan a los agentes especializados para realizar tareas de modernización concretas. A medida que estos arneses se expanden a funciones adyacentes (por ejemplo, pruebas, revisión de seguridad o validación de implementaciones), comienzan a formar una malla de agentes: una arquitectura de gestión de arneses que coordina flujos de trabajo de ingeniería complejos en grandes entornos de software.

Los agentes realizan el trabajo repetitivo. Los ingenieros se encargan de la arquitectura, la supervisión, las evaluaciones de los agentes y la gestión de excepciones. Esa división del trabajo es el modelo.

Modelos pequeños. Inferencia eficiente. Agentes modulares. Funcionamiento desconectado. Modernización del sistema en consonancia con la misión.

Reflexión final

Los modelos fronterizos son motores de razonamiento extraordinarios. Las plataformas de inteligencia artificial con agentes diseñadas para un fin específico son instrumentos para la misión.

Para los organismos gubernamentales, no se trata de adoptar la última tendencia en inteligencia artificial. Se trata de contar con la infraestructura y la capacidad de inteligencia artificial para mantener los sistemas críticos seguros, modernos y al servicio de la misión.

Estamos diseñando esto con Red Hat AI.

Más información

• Red Hat AI
• Red Hat OpenShift AI