¿Puede trabajar un agente de IA sin todo el contexto del código?

Un agente de IA que solo ve un archivo puede hacer un cambio convincente en ese punto y aun así dañar el sistema. El fallo no suele ser una sintaxis incorrecta ni una rama evidentemente equivocada. Es una llamada que falta, una regla codificada en los datos, un proceso nocturno con otro punto de entrada o una dependencia operativa que nunca aparece en el archivo revisado.

Por eso los límites del contexto deciden si la programación con agentes funciona en software legado. La unidad de trabajo útil es la conducta que atraviesa programas, scripts, objetos de base de datos, planificaciones, archivos y procedimientos operativos. Un archivo es solo uno de los lugares donde quedó escrita una parte de esa conducta.

He visto parches impecables superar la revisión porque cada línea visible tenía sentido. El fallo llegó después, cuando un archivo de control eligió un modo antiguo, un programa con nombre dinámico recibió un parámetro en una posición que nadie había documentado o un proceso reiniciado encontró registros que la ruta en línea nunca genera. Editar cada línea con más cuidado no resuelve esta clase de problema. El agente debe descubrir primero el sistema que rodea la línea.

Un archivo no es la unidad de conducta

La conducta de un sistema legado rara vez cabe en el archivo que parece contenerla. Un programa COBOL puede calcular un importe, pero el JCL elige su conjunto de datos de entrada, un paso SORT cambia el orden de los registros, un copybook fija las posiciones de los campos y un programa posterior interpreta el byte de estado de la salida. Leer solo el cálculo le da al agente una historia coherente, pero incompleta.

El mismo patrón aparece fuera del mainframe. Un formulario VB6 llama a un componente COM cuyo registro selecciona una versión. Un controlador PHP incluye un archivo de configuración montado por scripts de despliegue. Un programa RPG lee un área de datos y llama a otro programa mediante un nombre guardado en un campo. Un paquete PL/SQL depende de un trigger que cambia la fila después de que el paquete la escriba. Ninguna de esas dependencias tiene que parecer una importación normal.

Esta distinción importa: la proximidad en el código fuente no implica propiedad de la conducta. Dos funciones de un archivo pueden no tener relación en ejecución, mientras que un miembro JCL y un párrafo COBOL de bibliotecas distintas pueden formar una única operación de producción indivisible. Si un agente clasifica el contexto sobre todo por la cercanía de directorios, las sentencias de importación o los identificadores coincidentes, omitirá dependencias que para operaciones son evidentes.

Antes de cambiar un archivo, hay que preguntar qué inicia esta conducta, qué entradas seleccionan sus ramas, qué estado persistente lee o escribe y quién consume el resultado. Esas preguntas crean el límite del sistema. Puede abarcar doce archivos o doce mil. Su tamaño sigue la conducta, no la pestaña del editor.

La consecuencia práctica es tajante. Una herramienta que no puede buscar y razonar a través del repositorio, las definiciones de compilación, el control de trabajos, los esquemas y las pruebas no debería realizar un cambio autónomo en un sistema legado. Puede explicar un párrafo o preparar una prueba unitaria. No puede establecer el impacto de una edición en producción.

Los puntos de llamada quedan fuera del grafo de importaciones

Un grafo de llamadas construido con llamadas explícitas a funciones resulta útil, pero no es el grafo de llamadas del sistema. Los sistemas legados resuelven el trabajo mediante cadenas, tablas, planificadores, código generado, pasos de enlace, archivos de órdenes y convenciones. La arista que falta suele ser la que importa.

La documentación ILE de IBM ofrece un ejemplo claro. Una aplicación IBM i puede usar llamadas estáticas a procedimientos que se resuelven al enlazar el programa, o llamadas dinámicas a programas cuyo nombre de destino se resuelve en ejecución. Un análisis limitado al código fuente suele encontrar la referencia estática. Una llamada dinámica mediante un identificador puede depender de un valor cargado desde un archivo, mensaje, área de datos o parámetro. Buscar el nombre del programa llamado no encontrará un valor que producción construye más tarde.

El mismo punto ciego adopta formas corrientes:

• Un planificador invoca un script de shell que inicia un programa bajo un alias.
• Una tabla de base de datos asigna códigos de transacción a nombres de controladores.
• La reflexión carga una clase cuyo nombre está en la configuración.
• Una macro de hoja de cálculo llama a un método COM mediante un objeto de enlace tardío.
• El JCL generado inserta el nombre de un procedimiento solo después de sustituir símbolos.

El sector suele mezclar accesibilidad estática y dependencia en ejecución. La accesibilidad estática pregunta si el texto fuente o los metadatos compilados exponen un camino. La dependencia en ejecución pregunta si producción puede dirigir datos o control por ese camino en algún estado. Tomar la primera como prueba de la segunda produce un diagrama atractivo e incompleto.

Un agente necesita pruebas de ambas. Debe extraer referencias explícitas y después examinar cadenas literales, claves de configuración, pasos de trabajos, metadatos de enlace, tablas de despacho de la base de datos y trazas de producción. Si no puede resolver un destino dinámico, debe registrar una arista sin resolver con la expresión y sus posibles fuentes. El silencio no es una resolución válida.

Una consulta básica del repositorio deja ver lo rápido que un símbolo supuestamente aislado escapa de su módulo:

rg -n -uu 'CALC-TAX|CALCTAX|calc_tax' .
rg -n -uu 'EXEC PGM=|CALL +[A-Z0-9-]+|CALLP|PROCEDURE DIVISION' .
rg -n -uu 'handler|program_name|transaction_code' config db jobs src

Una salida real contiene rutas y números de línea, como jobs/NIGHTTAX.jcl:18://STEP20 EXEC PGM=CALCTAX. El artefacto no es sofisticado, pero obliga a quien revisa a inspeccionar llamadas más allá del archivo abierto. Un agente serio debería construir automáticamente una versión más rica de este mapa y conservar las pruebas que sustentan cada arista.

Las reglas de negocio viajan en los datos

Muchas reglas legadas son valores, formatos y secuencias, no funciones con nombre. Un agente puede conservar todas las condiciones visibles y aun así cambiar el resultado si entiende mal un campo decimal empaquetado, una fecha centinela, un tipo de registro, una secuencia de ordenación o el significado de un espacio en blanco.

Pensemos en un programa nocturno de comisiones. El código dice que la clase de cuenta P recibe una exención. La clase no procede directamente de la fila de la cuenta. Una extracción anterior asigna códigos de producto mediante una tabla de control, escribe una clase de un byte en la posición 47 y ordena las excepciones antes que los registros normales. Operaciones sustituye esa tabla antes del cierre de mes. La regla que el revisor cree contenida en una sentencia IF abarca en realidad una tabla, un formato de archivo, un contrato de ordenación y un procedimiento operativo.

Aquí es donde los agentes limitados a archivos producen transliteraciones plausibles. Convierten correctamente el IF, definen un enum agradable y leen un CSV en un servicio moderno. Después eliminan espacios o interpretan un campo vacío como null. El programa original comparaba un espacio en blanco de ancho fijo, así que un subconjunto de cuentas pasa a otra rama. Todas las pruebas unitarias derivadas de la función reescrita pasan porque repiten la interpretación nueva.

Por tanto, un inventario del sistema debe incluir la semántica de los datos, no solo nombres de esquemas. Para cada registro o tabla en una frontera, hay que capturar posiciones de campo, codificaciones, valores predeterminados, tratamiento de null, formatos de signo, redondeo, orden, manejo de duplicados y política para registros no válidos. Si un valor de control cambia fuera del control de versiones, hay que registrar cómo se despliega y qué trabajo lo lee.

No dé por hecho que un tipo moderno es más correcto que la representación antigua. Convertir 9(7)V99 COMP-3 a un tipo decimal puede ser sensato, pero solo después de conservar escala, signo, redondeo, desbordamiento y conducta ante entradas mal formadas. Reemplazar una fecha de seis caracteres por una marca temporal puede eliminar ambigüedad en el diseño de destino mientras inventa sin querer una regla de siglo que la fuente nunca tuvo.

El agente también debe conectar escritores con lectores. Un campo que parece sin uso en el productor puede ser relleno posicional que necesita un consumidor tres pasos después. Eliminarlo puede desplazar todos los campos siguientes sin provocar un error de compilación. La forma más segura de representar esa relación es un contrato explícito con bytes de ejemplo y valores analizados, no una nota en prosa que diga que los archivos son compatibles.

El proceso nocturno es otra aplicación

Una ruta en línea y una ruta por lotes que comparten código siguen siendo aplicaciones distintas cuando se ejecutan con otras entradas, identidades, horarios y reglas de recuperación. Superar una prueba interactiva dice poco sobre un trabajo que procesa estado acumulado después de medianoche.

La documentación de z/OS de IBM describe JCL como el lugar que indica al sistema dónde encontrar la entrada, cómo procesarla y qué hacer con la salida. Sus sentencias DD conectan los nombres usados por un programa con conjuntos de datos reales y especifican detalles como la disposición y el formato de registro. Eso no es embalaje alrededor de la aplicación. Es contexto ejecutable.

Pensemos en un cambio que añade un estado nuevo a una función de pedidos en línea. La ruta de la petición escribe H para pedidos retenidos, muestra el mensaje correcto y supera la revisión. El trabajo nocturno de liquidación lee el mismo archivo. Su primer paso ordena solo los valores de estado antiguos hacia la entrada de liquidación, mientras un paso de error copia los demás a un conjunto de datos temporal con DISP=(NEW,PASS). Un paso posterior solo se ejecuta cuando coincide una condición del código de retorno. El estado nuevo evita la liquidación, cae en el archivo temporal y desaparece cuando el trabajo termina con normalidad. Ningún archivo fuente del servicio revisado muestra ese resultado.

El fallo puede esperar a cierto volumen o estado del calendario. Una prueba diurna usa un registro y una base de datos limpia. El proceso encuentra duplicados acumulados por varios reintentos, cierra una fecha contable antes de procesar y confirma cada varios miles de registros. Un reinicio comienza después del último punto de control, no después de la transacción que esperaba la prueba. La corrección incluye la conducta de reinicio porque operaciones acabará repitiendo un trabajo que terminó a medias.

Para cada flujo programado, el agente debería modelar cinco hechos:

1. El disparador, calendario, identidad y entorno.
2. Los pasos ordenados y las condiciones que los omiten o repiten.
3. Las entradas y salidas concretas, incluidos los conjuntos de datos temporales.
4. La conducta de confirmación, punto de control, reintento y nueva ejecución.
5. La prueba con la que operaciones declara el éxito.

Un código de salida verde quizá no sea la condición de éxito. Algunos equipos aceptan códigos de aviso definidos, comprueban cantidades de registros o concilian un total de control en un informe posterior. Un agente que solo ve código y pruebas unitarias optimizará la señal equivocada.

La configuración ejecuta políticas

La configuración merece el mismo escrutinio que el código fuente porque selecciona conductas, aporta valores de negocio y conecta componentes en ejecución. Llamarla "solo configuración" facilita aprobar un cambio sin revisar la regla que realmente se ejecutará.

La configuración legada rara vez vive en un directorio ordenado. Puede ser un parámetro simbólico de JCL, un área de datos de IBM i, un archivo INI junto a un ejecutable de escritorio, una fila mantenida mediante un formulario de Access, un valor del registro, un miembro de entorno o una hoja de cálculo copiada a una carpeta vigilada. Algunos valores están en el control de versiones. Otros llegan mediante herramientas de despliegue o un procedimiento operativo. El agente debe encontrar y distinguir ambos tipos.

Supongamos que un programa de reclamaciones elige una rutina de precios desde una tabla. El código incluye un valor predeterminado inofensivo, de modo que el agente reescribe y prueba esa rama. Producción tiene filas por región que nombran cuatro rutinas antiguas, una de las cuales acepta un argumento adicional mediante un búfer compartido. El servicio nuevo se inicia correctamente y atiende los casos de prueba predeterminados. La primera reclamación de esa región no llama a ningún controlador o llama al nuevo con un contrato incompleto. El punto de llamada ausente era una fila, no una línea de código.

Trate los valores de configuración según su efecto. Un valor que cambia la verbosidad de los registros tiene poco riesgo funcional. Un valor que elige un programa, cambia un umbral, controla el redondeo, concede acceso, fija una versión del formato de archivo o altera la frecuencia de confirmación pertenece al mapa de impacto. La distinción sigue la consecuencia, no la extensión del archivo.

El agente debería responder cuatro preguntas por cada valor que selecciona conducta:

• ¿Dónde se define el valor y quién puede cambiarlo?
• ¿Qué código lo lee y cuándo ocurre esa lectura?
• ¿Qué valores han aparecido en entornos reales?
• ¿Qué sucede si está vacío, desactualizado, es desconocido o no está disponible?

Los valores predeterminados merecen especial desconfianza. Una alternativa que facilita una prueba unitaria puede ocultar una carga fallida de configuración en producción. El sistema fuente quizá se detenga ante un miembro de control ausente, mientras la reescritura elige silenciosamente un valor predeterminado. Ambas implementaciones producen una salida válida para casos configurados, pero sus contratos de fallo difieren. Las pruebas de paridad deben incluir configuración ausente y mal formada, no solo los valores esperados.

Capture una instantánea del despliegue junto con la revisión del código analizada. Cuando sea posible, asigne un hash o una versión a la exportación del planificador, las tablas de control, el esquema y los archivos de entorno. Si quien revisa no puede saber qué configuración supuso el agente, la afirmación sobre el impacto no es reproducible. Un índice completo del código combinado con una configuración de producción desconocida sigue siendo contexto parcial, y el agente debe decirlo con claridad.

Construya el mapa antes de pedir un parche

El agente debe elaborar un mapa de impacto respaldado por pruebas antes de proponer código. No es un póster de arquitectura. Es un conjunto de trabajo con nodos y aristas vinculados a archivos, definiciones, observaciones de ejecución y preguntas sin resolver.

Empiece por los puntos de entrada: rutas en línea, consumidores de mensajes, trabajos programados, programas de órdenes, procedimientos almacenados, eventos de escritorio y órdenes del operador. Después conecte llamadas a programas, lecturas y escrituras de archivos, acceso a tablas, artefactos generados, selección de configuración y enlaces del despliegue. Marque las aristas como estáticas, configuradas, observadas o inferidas. Esas etiquetas impiden que una conjetura adquiera la autoridad de un hecho.

Uso un registro compacto para cada cambio propuesto:

{
  "change": "add held order status H",
  "entry_points": ["POST /orders/{id}/hold", "NIGHTSET STEP20"],
  "writers": ["OrderStatus.bas", "HOLDORDR.cbl"],
  "readers": ["SETTLE.cbl", "RECON.sql"],
  "contracts": ["ORDER-REC copybook", "status_control table"],
  "unresolved": ["Does restart input retain H records?"],
  "required_evidence": ["online trace", "nightly replay", "reconciliation totals"]
}

Ese objeto resulta incómodo a propósito. Hace visibles el segundo punto de entrada y la duda sobre el reinicio antes de que nadie apruebe el parche. Los nombres exactos de los campos no importan. Sí importa exigir al agente que indique puntos de entrada afectados, lectores, contratos y pruebas pendientes.

La alternativa popular es la exposición progresiva: se entrega al agente el archivo de destino, se deja que solicite archivos relacionados y se para cuando dice tener suficiente. Ahorra tokens y parece eficaz en una demostración. Es un error para descubrir el impacto porque el primer archivo condiciona todas las peticiones posteriores. Si no contiene ninguna pista de que existen un planificador, una tabla de control o un procedimiento generado, el agente nunca los pedirá.

La exposición progresiva resulta útil después del descubrimiento, cuando el agente necesita texto detallado para una parte conocida del mapa. El descubrimiento exige indexar todo el repositorio y analizar varios lenguajes. El agente puede enfocar su razonamiento, pero el espacio de búsqueda no puede comenzar en el límite del archivo.

El mapa también ofrece a las personas una superficie de revisión mejor. Un revisor puede cuestionar una arista ausente, pedir pruebas de una inferencia o añadir un procedimiento operativo que el repositorio no contiene. Revisar solo el diff final obliga al humano a reconstruir mentalmente este mapa, precisamente la tarea en la que debía ayudar el agente.

El contexto necesita capas, no un prompt enorme

El contexto de todo el sistema no consiste en pegar un millón de líneas en un prompt. Significa que el agente puede recuperar y razonar sobre el sistema completo mediante representaciones adecuadas para distintas preguntas, sin perder el camino de regreso a las pruebas del código fuente.

Una capa contiene el inventario: lenguajes, unidades de compilación, esquemas, trabajos, puntos de entrada, archivos, procedimientos y fuentes de configuración. Otra conserva relaciones como llamadas, lecturas, escrituras, planificaciones, inclusiones, enlaces y generación. Una capa semántica registra contratos y responsabilidades probables. Las pruebas de ejecución añaden trazas, ejemplos con forma de producción, registros de trabajos y destinos de despacho observados.

Estas capas responden consultas distintas. Para cambiar el nombre de un campo, el agente necesita definiciones de formato y todos sus lectores. Para cambiar un cálculo, necesita llamadas, procedencia de datos, reglas de redondeo y salidas comparadas. Para dividir un proceso por lotes, necesita condiciones de pasos, vida de recursos temporales, puntos de control y recuperación operativa. Ninguna estrategia fija de fragmentación responde a las tres.

Los resúmenes ayudan, pero son una caché con pérdidas. Pueden decir que un programa calcula comisiones y omitir la rama que solo se aplica a transacciones anuladas durante el cierre. Cada afirmación resumida debería conservar referencias a tramos concretos del código o registros de ejecución. Cuando un cambio afecta esa afirmación, el agente debe volver a abrir esas fuentes en vez de razonar solo con el resumen.

También importa que el contexto esté actualizado. Los copybooks generados, las definiciones de bases, las exportaciones del planificador y la configuración desplegada pueden desviarse del repositorio principal. El agente debe mostrar qué instantánea analizó. Mezclar un archivo COBOL actual con la exportación JCL del trimestre pasado crea un sistema sintético que nunca se ha ejecutado en ningún sitio.

El análisis del repositorio tampoco puede saberlo todo. Un operador puede editar un miembro de control durante un incidente. Un socio puede enviar variantes de registros sin documentar. Una aplicación de escritorio puede depender del registro de la máquina. La respuesta correcta es señalar la laguna y pedir pruebas de ejecución, no llenarla con una suposición segura de sí misma.

Este planteamiento por capas controla el coste sin sacrificar alcance. Los índices amplios identifican candidatos con poco gasto. La recuperación enfocada entrega la fuente exacta cuando el agente razona sobre una arista. La repetición en ejecución prueba la conducta resultante. El sistema sigue disponible para el agente aunque no todos sus tokens estén activos a la vez.

La paridad se prueba en el límite de la conducta

Las pruebas escritas solo contra la implementación nueva demuestran coherencia interna, no conservación. Una reescritura puede superar una batería unitaria nueva y completa mientras discrepa de producción en los casos que entendió mal.

El oráculo práctico más fuerte es el propio sistema antiguo. Capture entradas representativas en sus límites reales, ejecútelas en ambas implementaciones, normalice solo los valores intencionadamente no deterministas y compare las salidas observables. Pueden incluir cuerpos de respuesta, cambios de base de datos, archivos emitidos, mensajes, códigos de retorno, totales de control y registros que operaciones trata como contractuales.

Un caso de paridad debería guardar detalle suficiente para reproducir una discrepancia:

{
  "case_id": "nightly-held-order-restart",
  "entry_point": "NIGHTSET",
  "input_refs": ["orders.dat#sha256:...", "status_control#2026-08-01"],
  "source": {"rc": 4, "settled": 812, "held": 17, "control_total": "194033.22"},
  "target": {"rc": 0, "settled": 829, "held": 0, "control_total": "196801.04"},
  "comparison": "mismatch"
}

El ejemplo muestra por qué hacer coincidir códigos de salida es una prueba débil. El origen considera aceptable el código de retorno 4 y conserva los registros retenidos. El destino devuelve cero después de liquidarlos. Una comprobación de estado convencional prefiere el resultado incorrecto.

El tráfico grabado exige disciplina. Elimine o proteja valores sensibles, preserve el orden cuando afecte a la conducta e incluya fallos y reintentos en vez de muestrear solo peticiones correctas. Los fixtures de procesos por lotes necesitan categorías de volumen parecidas a producción, fechas límite, duplicados, registros mal formados y puntos de reinicio. No hacen falta todos los registros de producción, pero sí todas las clases de conducta conocidas.

La paridad no prohíbe cambiar la arquitectura. Separa los cambios intencionados de los accidentales. Puede reemplazar el procesamiento secuencial de archivos con transacciones de base de datos, dividir un monolito en servicios o mover un núcleo numérico a Rust. La comparación muestra dónde cambió la conducta visible. Una persona puede aprobar entonces una diferencia deliberada con un motivo en vez de descubrirla en la conciliación.

CodeHero utiliza este límite de forma deliberada: su plataforma lee todo el código en todos sus lenguajes y después verifica el sistema reescrito mediante un arnés de paridad contra tráfico de producción grabado. Ese mecanismo importa más que la apariencia idiomática del código generado en una solicitud de cambios.

Revise la afirmación de impacto, no solo el diff

La revisión con agentes debería evaluar lo que el agente afirma acerca del impacto en el sistema. El diff sigue siendo necesario, pero es el último artefacto de una cadena que empieza con el descubrimiento y termina con pruebas de conducta.

Un paquete de revisión útil contiene la conducta solicitada, los puntos de entrada afectados, los contratos cambiados, los consumidores descubiertos, las aristas sin resolver, las pruebas y cualquier diferencia aceptada. Cada afirmación debe poder rastrearse. Si el agente dice que un campo tiene un lector, el revisor debería poder abrir la búsqueda o traza que respalda ese número.

Esto cambia la conversación de aprobación. En vez de preguntar si la función nueva parece razonable, el revisor pregunta por qué RECON.sql no resulta afectado, si se repitió el reinicio nocturno y qué prueba cubre valores de estado en blanco. Al agente le cuesta más fingir estas respuestas y un ingeniero con experiencia puede contestarlas con decisión.

Busque tres señales de aviso. Primero, el agente describe dependencias sin separar hechos observados de inferencias. Segundo, sus pruebas proceden por completo del diseño nuevo y no de la conducta legada capturada. Tercero, usa expresiones como "todas las llamadas" sin mostrar el límite de búsqueda. Cada señal indica que la afirmación sobre contexto es más fuerte que las pruebas.

Los revisores también necesitan una regla de parada. Bloquee el cambio cuando una arista sin resolver pueda alterar dinero, permisos, registros regulados, salidas irreversibles o la recuperación. Para un defecto visual de bajo riesgo puede bastar una inferencia acotada. La integridad del contexto no es binaria: las pruebas exigidas crecen con la consecuencia de equivocarse.

No mida a un agente por líneas aceptadas ni por velocidad de las solicitudes de cambios. Esas métricas premian la plausibilidad local. Mida con qué frecuencia las predicciones de impacto coinciden con efectos observados, cuántas discrepancias de paridad escapan y si las repeticiones y controles operativos se comportan como se esperaba. Incluso sin una puntuación formal, estas preguntas separan la ayuda de escritura del trabajo de ingeniería.

El alcance de todo el sistema cambia los costes

El descubrimiento en todo el repositorio cuesta más antes de la primera edición, y precisamente por eso ahorra tiempo en trabajos legados. Los fallos caros ocurren después de que un cambio local barato cruce un límite invisible: durante el cierre, en una ventana nocturna, en la conciliación o después de que se marche la única persona que conocía la secuencia de reinicio.

El coste no es solo la reparación. Una mala modernización enseña a la organización a desconfiar del sistema de destino. Los equipos mantienen la aplicación legada como sombra, comparan resultados a mano y rechazan cambios posteriores. La reescritura nominal termina, pero la migración operativa nunca lo hace.

El análisis de todo el sistema también evita un desperdicio más sutil: transliterar arquitectura obsoleta porque el agente no ve por qué existe. Si solo ve un programa, la opción aparentemente más segura es reproducir sus párrafos en otro lenguaje. Si ve llamadas, contratos de datos, flujo de trabajos y conducta en el límite, puede conservar los resultados exigidos a la vez que sustituye estructura accidental.

Ese es el criterio que aplicamos cuando CodeHero reescribe sistemas legados en Go, Rust, TypeScript y Postgres en menos de 30 días. El plazo corto solo resulta creíble cuando el descubrimiento, el razonamiento entre lenguajes y la comprobación de paridad operan sobre el sistema entero, en lugar de esperar a que personas entreguen archivos uno por uno.

Un agente de IA no necesita una comprensión mística de todas las decisiones históricas. Necesita un límite honesto, pruebas para sus aristas y comprobaciones en los puntos por los que sale la conducta. Si su agente de programación no puede decir qué proceso nocturno lee el registro que quiere cambiar, no se ha ganado el derecho a cambiarlo.