💻 computer science

Deterministic vs. LLM-Controlled Orchestration for COBOL-to-Python Modernization

Este artículo presenta un estudio empírico controlado que demuestra que la orquestación determinista supera a los flujos de trabajo agénticos controlados por LLM en la modernización de COBOL a Python al lograr una precisión de traducción comparable, mientras mejora significativamente la robustez, reduce la variabilidad del rendimiento y disminuye los costos operativos hasta en 3.5 veces.

Autores originales: Naing Oo Lwin, Rajesh Kumar

Publicado 2026-08-21

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Naing Oo Lwin, Rajesh Kumar

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Durante décadas, los sectores financiero y gubernamental han dependido de programas informáticos masivos e intrincados escritos en un lenguaje llamado COBOL. Estos sistemas ejecutan las transacciones bancarias y los pagos de la seguridad social del mundo; sin embargo, los expertos que los construyeron se están jubilando y el código en sí mismo suele tener décadas de antigüedad, estar mal documentado y ser difícil de modificar. Para mantener la operatividad de estos servicios vitales, las organizaciones deben traducir este código antiguo a lenguajes modernos como Python, un proceso que requiere una precisión extrema porque incluso un error minúsculo puede hacer que un sistema falle. Recientemente, ha surgido un nuevo tipo de inteligencia artificial conocido como modelo de lenguaje extenso como una herramienta potencial para esta tarea. Estos modelos pueden leer código y escribir código nuevo, pero a menudo funcionan actuando como agentes autónomos: deciden por sí mismos qué pasos tomar, cuándo reintentar una tarea y cómo corregir errores sobre la marcha. Esto plantea una pregunta crítica para los ingenieros: ¿es mejor dejar que la inteligencia artificial conduzca todo el proceso, decidiendo cada movimiento en tiempo real, o es más efectivo mantener el proceso en una trayectoria estricta y predefinida donde la computadora siga un conjunto fijo de reglas?

Un equipo de investigadores de la Universidad de Bucknell y Astrio se propuso responder a esta pregunta realizando un experimento controlado para ver cómo estos dos enfoques diferentes manejan la difícil labor de convertir código COBOL en Python. Construyeron un sistema llamado ATLAS para actuar como el traductor, pero diseñaron el experimento de modo que lo único que cambiaba entre las pruebas era quién estaba al volante. En una versión, la inteligencia artificial tenía el control total, permitiéndole elegir su propio camino, seleccionar sus propias herramientas y decidir cuándo detenerse o empezar de nuevo. En la otra versión, se utilizó la misma inteligencia artificial para escribir el código, pero un conjunto de reglas rígidas e inalterables dictaba exactamente qué pasos tomar, en qué orden y cuántas veces intentar de nuevo si algo salía mal. Al mantener el cerebro del sistema —el modelo de lenguaje— exactamente igual en ambos escenarios, los investigadores pudieron aislar el efecto del método de control en sí, eliminando todas las demás variables para ver qué estrategia funcionaba realmente mejor.

Los resultados de este estudio revelaron un claro compromiso entre flexibilidad y fiabilidad. Cuando se permitía que la inteligencia artificial controlara el proceso, frecuentemente lograba producir un programa funcional, teniendo éxito a menudo en la generación de un resultado que podía ejecutarse sin colapsar. Sin embargo, este éxito conllevaba un costo oculto: los resultados eran inconsistentes. Debido a que el modelo tomaba sus propias decisiones sobre cómo proceder, el mismo código inicial podía conducir a resultados muy diferentes en distintos intentos, produciendo a veces una traducción perfecta y otras veces fallando de maneras impredecibles. Además, este enfoque "agéntico" era increíblemente costoso. El modelo a menudo se perdía en largos y sinuosos caminos de razonamiento, haciéndose preguntas a sí mismo y probando múltiples estrategias que no eran necesarias, consumiendo vastas cantidades de recursos computacionales. En algunos casos, el enfoque flexible utilizó más de tres veces más tokens —las unidades básicas de información que el modelo procesa— que el enfoque fijo para lograr un resultado similar.

En contraste, el sistema que siguió una trayectoria fija y determinista produjo resultados que eran mucho más estables y predecibles. Si bien la capacidad general para traducir el código era tan buena como la de la versión flexible, el sistema rígido rara vez fallaba en los peores casos. No se perdía en bucles de pensamiento innecesario y no variaba su comportamiento de una ejecución a otra. Lo más importante es que era significativamente más barato de ejecutar. Al ceñirse a un programa estricto de pasos y utilizar la inteligencia artificial únicamente para escribir el código en lugar de para planificar el viaje, el sistema redujo el costo de la traducción en un factor de tres a tres y medio. Los investigadores descubrieron que para tareas como la modernización de software heredado, donde los pasos están bien definidos y los resultados pueden verificarse mediante reglas estrictas, dejar que la inteligencia artificial condujera el coche no solo era más caro, sino también menos fiable que tener un mapa diseñado por humanos guiando el camino.

Este estudio sugiere que el futuro del uso de la inteligencia artificial en tareas de ingeniería complejas puede no residir en dar a las máquinas libertad total para decidir cómo trabajar. En cambio, el enfoque más efectivo parece ser integrar estos poderosos modelos dentro de un marco estructurado donde las reglas de compromiso sean fijas y el camino sea claro. La inteligencia artificial sigue siendo el escritor experto, capaz de comprender instrucciones complejas y generar nuevo código, pero la orquestación del trabajo —la planificación, la temporización y los controles de seguridad— permanece bajo un control estricto y determinista. Esto asegura que el proceso no solo sea capaz de producir resultados de alta calidad, sino que también sea robusto, predecible y económicamente viable para los sistemas críticos y a gran escala que mantienen en funcionamiento nuestro mundo moderno.

Resumen Técnico: Orquestación Determinista vs. Controlada por LLM para la Modernización de COBOL a Python

Declaración del Problema

La modernización de sistemas heredados en COBOL es un desafío crítico debido a la escasez de expertos, las bases de código masivas y los estrictos requisitos de corrección. Si bien los Modelos de Lenguaje de Gran Escala (LLMs) han mostrado potencial en la traducción de código, los sistemas recientes dependen cada vez más de flujos de trabajo agénticos donde el LLM controla dinámicamente la ejecución de herramientas en múltiples pasos, incluyendo la selección de herramientas, el orden y la lógica de reintento. Sin embargo, sigue sin estar claro si delegar el control de la ejecución al LLM mejora la corrección, la robustez o la eficiencia en flujos de trabajo de ingeniería de software estructurados (como la modernización de sistemas heredados) en comparación con políticas de ejecución fijas y deterministas. La literatura existente suele confundir la estrategia de orquestación con la capacidad del modelo o el diseño de prompts, lo que dificza el aislamiento del impacto específico del mecanismo de control de ejecución.

Metodología

Los autores presentan un estudio empírico controlado utilizando el marco ATLAS (Autonomous Transpilation for Legacy Application Systems) para comparar dos estrategias de orquestación: Orquestación Determinista y Orquestación Controlada por LLM.

Diseño Experimental

Para aislar la orquestación como la única variable experimental, el estudio mantiene constantes los siguientes elementos en todas las ejecuciones:

Modelos de Lenguaje: Modelos, versiones y parámetros de decodificación (temperatura, semillas) idénticos.
Prompts: Prompts de sistema, instrucciones de tarea y restricciones de formato idénticos.
Herramientas: Conjuntos de herramientas idénticos (p. ej., read_file, write_file, run_command, git) con las mismas interfaces y permisos.
Entradas: Los mismos programas COBOL de origen y entradas de prueba.
Configuración: Límites de tiempo de espera (timeout) y banderas de configuración idénticos.

Estrategias de Orquestación

Orquestación Determinista: La secuencia de invocaciones de herramientas, las etapas de validación y los comportamientos de reintento son fijos y predefinidos. El LLM es responsable únicamente de la generación de código dentro de etapas específicas. El flujo de ejecución no depende de salidas intermedias del LLM; la ramificación condicional se rige por predicados deterministas sobre el estado del sistema (p. ej., el estado de modificación de un archivo).
Orquestación Controlada por LLM: El LLM actúa como un orquestador central, seleccionando herramientas dinámicamente, determinando el orden de ejecución, eligiendo estrategias de reparación ante fallos y decidiendo cuándo terminar. El flujo de ejecución emerge del proceso de generación del modelo y está influenciado por el muestreo estocástico.

Conjunto de Datos y Evaluación

Conjunto de Datos: La Suite de Pruebas NIST COBOL85, que comprende cientos de programas COBOL autónomos con entornos de prueba ejecutables y resultados esperados bien definidos.
Métricas:
- Exactitud Computacional (CA): Equivalencia funcional entre el programa Python generado y la implementación de referencia en COBOL sobre las entradas de prueba.
- Tasa de Éxito (SR): La frecuencia con la que un pipeline de traducción produce un programa ejecutable que pasa las pruebas a través de ejecuciones estocásticas repetidas ( $N$ ejecuciones independientes).
- Robustez en el Peor de los Casos: Medida mediante el percentil 5 de la CA (P5-CA) y el Valor en Riesgo Condicional (CVaR) para capturar los fallos de riesgo de cola.
- Eficiencia: Consumo de tokens por traducción exitosa y costo operativo estimado.

Contribuciones Clave

Marco Controlado: Los autores introducen un marco experimental unificado que aísla el control de ejecución como la única variable, permitiendo una comparación directa entre la orquestación determinista y la agéntica sin factores de confusión.
Compromiso entre Robustez y Frecuencia: El estudio demuestra que, si bien ambas estrategias logran una capacidad de traducción comparable, la orquestación determinista mejora significativamente la robustez en el peor de los casos (reduciendo los fallos de riesgo de cola y la variabilidad del rendimiento), mientras que la orquestación controlada por LLM produce tasas de éxito más altas en la producción de código ejecutable a través de intentos repetidos.
Análisis de Eficiencia: El documento proporciona un análisis cuantitativo que muestra que la orquestación determinista reduce el consumo de tokens hasta en un 3.5×, lo que conlleva costos operativos sustancialmente menores en comparación con los flujos de trabajo agénticos adaptativos.

Resultados

Corrección: La orquestación determinista alcanzó consistentemente una mayor Exactitud Computacional (CA) media y una mayor robustez en el peor de los casos (mayor P5-CA y CVaR) a través de múltiples modelos (incluyendo Claude-Sonnet-4-5, GPT-5.1-Codex-Max y Grok-Code-Fast-1).
Tasa de Éxito: La orquestación controlada por LLM logró una Tasa de Éxito (SR) más alta, lo que indica que la ejecución adaptativa resultó con mayor frecuencia en programas compilables que pasan las pruebas en ejecuciones individuales. Sin embargo, esto tuvo a cambio colas de rendimiento más pesadas (fallos más severos en los peores casos).
Costo y Eficiencia: La orquestación controlada por LLM requirió significativamente más tokens (p. ej., 1.75M–2.25M de tokens para módulos complejos frente a 400k–700k para la determinista). Esto resultó en costos operativos hasta 3.5× más altos para los flujos de trabajo agénticos (p. ej., >$140 frente a ~$40 por traducción exitosa para tareas de I/O Secuencial).
Consistencia de la Suite de Pruebas: Las estadísticas agregadas de las pruebas mostraron que ambas estrategias pueden traducir el mismo conjunto de programas, pero la orquestación determinista proporcionó garantías de corrección más consistentes en los resultados finales.

Significado y Reivindicaciones

El artículo sostiene que para los flujos de trabajo de modernización estructurados, caracterizados por etapas de validación explícitas y dependencias deterministas, las políticas de ejecución fijas proporcionan una alternativa más estable y rentable a la orquestación totalmente agéntica sin sacrificar la calidad de la traducción.

Implicación de Diseño: El control de la ejecución debe tratarse como una decisión de diseño de sistemas de primer orden y no como una consecuencia implícita del razonamiento del LLM. En tareas con pipelines de transformación claros y señales de validación fuertes, separar el control de la ejecución del razonamiento generativo limita la acumulación de errores y mejora la predictibilidad.
Alcance de Aplicabilidad: Los hallazgos sugieren que, si bien la orquestación agéntica puede seguir siendo valiosa para tareas exploratorias y abiertas (p. ej., descubrimiento de requisitos), la modernización de sistemas heredados estructurados se beneficia de los valores por defecto deterministas.
Modestia: Los autores reconocen las limitaciones, señalando que los resultados son específicos para la modernización de COBOL a Python y la suite NIST COBOL85, que puede no capturar completamente la complejidad de los entornos de producción con dependencias externas (p. ej., JCL, CICS, VSAM). También señalan que el estudio aísla la estrategia de orquestación bajo condiciones controladas, y los resultados pueden variar con diferentes estrategias de prompting o arquitecturas de modelos.

En conclusión, el estudio postula que integrar los LLM dentro de marcos de ejecución deterministas es crucial para mantener la viabilidad económica y la predictibilidad de costos en la modernización a escala empresarial, desafiando la suposición de que delegar todo el control al agente es inherentemente superior.