Existen billones de dólares en sistemas críticos corriendo en COBOL, Delphi, Visual Basic 6, ABAP, RPG, ColdFusion, PL/SQL antiguo, Perl, Fortran. Bancos, gobierno, industria, ERP corporativo. Estos sistemas no van a desaparecer porque alguien decidió reescribirlos en Rust el fin de semana. Funcionan, sostienen el negocio y costarían demasiado caro de sustituir. El problema real es otro: ¿quién sabe todavía leer, mantener y evolucionar estas bases?
En 2026, los agentes especialistas con LLMs se volvieron la mejor respuesta a esa pregunta. No sustituyen al ingeniero raro que conoce COBOL, pero potencian al equipo actual, traducen conocimiento, generan tests y aceleran la modernización incremental. Esta guía muestra cómo.
El problema real: deuda de conocimiento, no solo deuda técnica
Tratar el legacy como "código viejo" es una simplificación. Lo que vuelve agudo el problema es la pérdida gradual de conocimiento: las personas que escribieron el sistema se jubilaron, la documentación se evaporó, los comentarios están en otro idioma, reglas de negocio críticas solo existen en la cabeza de tres empleados, y el build depende de una máquina específica en el rincón de la sala.
Los LLMs ayudan justamente en ese vacío. Fueron entrenados con cantidades inmensas de código legado, conocen dialectos olvidados por los humanos y logran leer cientos de miles de líneas en minutos, extrayendo reglas, flujos, dependencias y generando documentación accionable.
Lo que los LLMs hacen bien con el código legado
Cinco usos con un ROI claro. 1. Documentación inversa: generar una descripción en lenguaje llano de lo que hace cada programa, módulo o stored procedure, con flujos, entradas, salidas y reglas embebidas. 2. Traducción de reglas de negocio: extraer las reglas mezcladas en el código a una spec legible por producto. 3. Generación de tests: crear una suite de tests que cubra el comportamiento actual, sirviendo de red de seguridad para los cambios. 4. Modernización incremental: traducir módulo por módulo a un lenguaje moderno manteniendo la equivalencia de comportamiento, con test de regresión. 5. Soporte al ingeniero júnior: un agente especialista responde "qué hace este fragmento y por qué" con confianza y citando el código fuente.
Arquitectura de un agente especialista en legacy
Una receta que funciona. 1. Indexación completa: todo el repositorio legacy pasa por extracción, chunking respetando la estructura (programa, procedure, copybook) y generación de embeddings. 2. Grafos de dependencia: estáticos (llamadas, includes, JCL) armados en paralelo, complementando el RAG. 3. RAG híbrido: búsqueda semántica + keyword exacta (importante para identificadores como una variable, un copybook, una transaction). 4. Tools especializadas: parser de copybook, lector de JCL, mapa de transacciones CICS, búsqueda por patrón estructural. 5. Prompt del sistema: una persona de especialista en el lenguaje objetivo, con la instrucción de citar archivo y línea en toda respuesta. 6. Validador: para los cambios de código, el agente corre el compilador o linter del lenguaje objetivo e itera si se rompe.
Modernización incremental: el camino seguro
El mayor error es intentar reescribir todo. El historial del mercado muestra que el rewrite big-bang falla en el 70-80% de los casos. El camino seguro es el strangler fig: un nuevo sistema crece alrededor del antiguo, módulo por módulo, con convivencia. Los agentes aceleran cada etapa del strangler.
Pasos típicos. (a) El agente mapea el dominio funcional del módulo a sustituir. (b) Genera una spec en SDD del comportamiento actual, con criterios de aceptación derivados de los casos de uso reales. (c) Genera una suite de tests de caracterización sobre el sistema legado para garantizar la paridad. (d) Implementa el módulo equivalente en un lenguaje moderno (con ayuda del agente). (e) Lo corre en paralelo (shadow) comparando la salida en producción hasta confiar. (f) Hace un cutover gradual con feature flag y rollback fácil.
Cuidados específicos por lenguaje
COBOL: atención a las PIC clauses, la conversión de packed decimal, los edge cases de aritmética decimal que los lenguajes modernos tratan distinto. Delphi: una dependencia fuerte de componentes VCL y bibliotecas de terceros; muchas veces la mejor estrategia es mantener el cliente Delphi y mover la lógica a servicios. VB6: COM y dependencias de DLL antiguas; la modernización tiende a recortar la superficie primero. ABAP: las integraciones profundas con SAP exigen conocimiento de BAPI, IDoc, RFC; el agente necesita RAG sobre los objetos SAP, no solo código. RPG/AS400: persistencia en archivos físicos, lógica embebida en pantallas; la modernización exige separar UI, regla y dato.
Riesgos y mitigación
Cuatro riesgos típicos. 1. Alucinación técnica: el agente "inventa" sintaxis que no existe en el dialecto exacto. Mitigación: una tool de validación (compilador, linter) y RAG sobre la documentación oficial. 2. Cambio silencioso de comportamiento: la traducción parece correcta pero trata un edge case de forma distinta. Mitigación: shadow mode con diff en producción, tests de caracterización rigurosos. 3. Pérdida de conocimiento tribal: el agente "se traga" el saber sin que los humanos lo absorban. Mitigación: revisión obligatoria por humano y documentación publicada como contenido del equipo. 4. Dependencia de proveedor: usar el agente cerrado de un vendor para todo el legacy genera lock-in. Mitigación: mantener prompts, evals y RAG en tu infraestructura, y cambiar de modelo según la relación precio-calidad.
Equipo y cultura para esta jornada
La modernización con agentes necesita tres perfiles. 1. Un ingeniero veterano que conoce el sistema. Sin él, el agente se equivoca y nadie lo nota. 2. Un ingeniero moderno que conoce el stack objetivo y tiene el hábito de testear agresivamente. 3. Producto/negocio que valida que el comportamiento traducido encaje con la intención actual, no con lo que el código simplemente hace.
Cultura: paciencia, tolerancia a la iteración, y un abandono explícito de la fantasía del "rewrite en 6 meses". Una modernización seria de un sistema crítico es una jornada de 1 a 3 años. Los agentes aceleran la jornada, no la eliminan.
ROI medible
Casos reales en 2025-2026 muestran una ganancia de productividad de 3x a 8x en tareas de lectura, documentación y generación de tests sobre código legado. Para la traducción, la ganancia es menor (1.5x a 3x), pero viene con una reducción sustancial del riesgo cuando se hace con tests de caracterización. El ROI verdadero, sin embargo, está en destrabar el conocimiento: las empresas que logran hacer el onboarding de un júnior en un sistema legado en semanas, en lugar de años, capturan una ventaja competitiva difícil de medir, pero estratégica.
Cómo actúa Steply en este escenario
Actuamos en tres frentes: arqueología asistida (mapear y documentar el sistema actual con agentes), modernización incremental (planificar y ejecutar el strangler fig con squads especializados) y capacitación interna (entrenar al equipo del cliente para operar agentes especialistas como parte del día a día, en lugar de depender de un proveedor). Esa combinación saca al legacy del "elefante en la sala" y lo transforma en una capability evolucionable, sin un rewrite suicida.