Leer todo el código más allá de la ventana de contexto

Un modelo que acepta un millón de líneas no adquiere por ello la capacidad de entender un sistema de un millón de líneas. La capacidad indica si cabe el texto. No dice si el modelo encontrará la definición correcta, conectará una llamada indirecta con un efecto secundario o advertirá que un paso JCL cambia el significado del programa COBOL que ejecuta.

Esta diferencia importa especialmente al reescribir sistemas heredados. Una traducción local que parece correcta puede compilar y aun así romper el cierre de mes porque el comportamiento antiguo vive repartido entre archivos fuente, copybooks, disparadores de base de datos, control de trabajos, validación de pantallas y convenciones de producción. Meterlo todo en un prompt sustituye un problema de omisión por uno de discriminación. El contexto contiene la respuesta, pero al modelo le falta una estructura fiable para decidir qué hechos controlan el cambio.

Leer todo el código es, por tanto, un problema de sistemas, no una función del tamaño del prompt. Requiere un modelo duradero del repositorio, recorrido explícito de dependencias, razonamiento por etapas y pruebas ejecutables de que el sistema generado se comporta como el anterior.

Una ventana de contexto mide capacidad, no comprensión

Una ventana de contexto larga indica la entrada máxima que un modelo puede aceptar bajo ciertas condiciones. No promete recuerdo uniforme, razonamiento estable a lo largo de la ventana ni uniones correctas entre hechos muy separados. Son capacidades distintas, y tratarlas como una sola métrica es el primer error de diseño.

Nelson Liu y sus coautores concretaron el problema de posición en el artículo Lost in the Middle. En preguntas sobre varios documentos y recuperación de pares clave-valor, el rendimiento solía ser mejor cuando el material relevante aparecía al principio o al final de la entrada. Caía al mover el mismo material al centro. El artículo no demuestra que todos los modelos actuales fallen en todos los programas largos. Sí demuestra que aceptar la entrada no es una buena medida de su uso fiable.

El código lo pone más difícil que la prosa. Un repositorio contiene miles de formas repetidas: getters, validadores, diseños de registros, ramas de error, archivos generados y pasos batch casi idénticos. El modelo debe distinguir hechos parecidos mientras sigue relaciones que quizá nunca estén juntas en el texto. Un párrafo CALCULATE-TAX y otro CALCULATE-TAX-OLD pueden compartir casi todos sus tokens y tener llamadores diferentes. La similitud ayuda a encontrar ambos. No decide cuál gobierna la transacción.

El recuento de tokens también oculta los costes de representación. El texto fuente es una sola capa. Un análisis útil necesita identidades de símbolos, aristas de llamada, flujo de datos, metadatos de compilación, esquemas, configuración, pruebas y observaciones del software en ejecución. Si un proveedor afirma que su ventana admite el repositorio, pregunte qué excluyó, cómo ordenó los archivos, cómo codificó las aristas entre lenguajes y cómo comprueba el sistema las afirmaciones extraídas. El tamaño de la ventana no responde nada de eso.

La prueba de aceptación práctica es sencilla: mueva el archivo decisivo a otra posición, añada archivos irrelevantes pero similares y repita la tarea. Si cambia la respuesta, el sistema leyó una secuencia, no una base de código.

Otra prueba se centra en la composición. Pregunte dónde nace un campo, dónde cambia y qué efecto externo depende de su valor final. Formule luego esas preguntas por separado y compare la ruta ensamblada. Un lector que responde cada pregunta local pero no conserva la identidad a lo largo de la cadena tiene capacidad de búsqueda, no comprensión del sistema. Este fallo pasa desapercibido con facilidad porque cada respuesta aislada puede sonar correcta.

La recuperación pierde relaciones que el vocabulario no expresa

Recuperar fragmentos funciona para preguntas cuya respuesta se parece a la consulta, pero el comportamiento de un programa suele depender de relaciones en vez de palabras compartidas. El llamador puede usar un nombre genérico, despachar mediante una tabla, construir el nombre de un procedimiento, publicar un evento, invocar un procedimiento almacenado o ceder el control a un planificador. Una búsqueda vectorial del concepto de negocio puede recuperar la función llamada y perder el llamador que aporta el indicador decisivo.

Pensemos en una regla de facturación implementada en COBOL. El párrafo visible lee una clase de cuenta y calcula una comisión. Un paso JCL selecciona un conjunto de entrada alternativo el último día hábil. Un copybook superpone dos campos del registro, y un disparador PL/SQL suprime la comisión para cuentas migradas. Ninguno necesita repetir las palabras del ticket. Recuperar solo el párrafo produce una función TypeScript limpia y equivocada.

SWE-bench captó un hecho relacionado a menor escala: las correcciones reales suelen exigir cambios coordinados entre funciones, clases y archivos. Su configuración original comparaba la recuperación con el acceso a los archivos modificados por el parche humano. Es una advertencia útil. Una generación mejor no recupera pruebas que la etapa de recuperación nunca entregó, y en una migración real no existe un conjunto de archivos oráculo.

El sector también confunde el recall de búsqueda con la integridad del comportamiento. El recall pregunta si un elemento relevante conocido aparece entre los resultados. La integridad pregunta si el sistema encontró todos los artefactos necesarios para explicar un resultado observado. Puede medir lo primero con fragmentos etiquetados. Solo puede establecer lo segundo siguiendo y probando el comportamiento.

Un lector del repositorio debería combinar varias rutas en el mismo almacén de pruebas:

• búsqueda léxica de identificadores exactos, literales, nombres de registros y códigos de error;
• búsqueda semántica de conceptos expresados con vocabulario distinto;
• resolución de símbolos y recorrido de llamadas para la estructura explícita;
• aristas de flujo de datos y esquemas para valores que cruzan procedimientos;
• trazas de ejecución para despacho dinámico, configuración y efectos externos.

No son cinco recuperadores rivales. Cada uno revela una clase de fallo diferente. El sistema debe conservar por qué eligió un artefacto, qué arista llevó hasta él y qué queda sin resolver. Una bolsa ordenada de fragmentos sin procedencia invita al modelo a convertir la confianza de recuperación en una certeza inventada.

Los límites de los fragmentos causan otra pérdida silenciosa. La declaración de un procedimiento puede quedar en un fragmento y su precondición, controlador de errores o definición de datos vecina en otro. Agrandar los fragmentos conserva más contexto local, pero reduce la precisión y consume más prompt. Solaparlos copia texto sin restaurar la estructura del programa. Los fragmentos basados en el parser mejoran el equilibrio, aunque ni siquiera una función completa revela una condición del planificador o el efecto de un disparador situado en otro lugar. Tras el primer resultado, la recuperación debe expandir el grafo. Debe detenerse según las preguntas resueltas, no por un top-k arbitrario.

La dilución de atención sobrevive a un prompt mayor

Añadir material relevante puede empeorar una respuesta si el modelo debe escoger entre demasiados hechos plausibles. En términos de ingeniería, diluir la atención significa que la prueba decisiva compite con código repetitivo, implementaciones duplicadas, ramas muertas, código generado, comentarios de una versión antigua y pruebas que codifican un comportamiento obsoleto.

La recomendación habitual consiste en colocar todo el repositorio en el prompt y pedir al modelo que lo examine con cuidado. Es popular porque elimina un componente visible de la canalización. No hay índice que ajustar ni recuperador al que culpar. La sencillez es cosmética. El modelo sigue seleccionando, pero ahora lo hace dentro de una inferencia opaca donde no se pueden inspeccionar candidatos omitidos ni repetir un recorrido.

El orden del repositorio se convierte entonces en una política accidental. Ordenar los archivos alfabéticamente favorece algunos módulos. Concatenarlos según dependencias requiere un grafo previo al prompt, lo que admite la necesidad de análisis. Poner archivos probables en ambos extremos explota un patrón de benchmark en vez de demostrar comprensión. Repetir archivos importantes desperdicia capacidad y puede dar demasiado peso a duplicados antiguos.

LongBench v2 incluyó la comprensión de repositorios entre tareas con entradas muy largas y mostró que responder directamente seguía siendo difícil. Su lección metodológica resulta más interesante: un razonamiento más largo y un esfuerzo adicional de inferencia pueden importar tanto como el tamaño de entrada anunciado. Una arquitectura de migración debe llevar esa idea más lejos y exteriorizar el trabajo intermedio. No debe pedir a una sola generación que descubra el sistema, decida el diseño objetivo, produzca código y certifique la paridad a la vez.

Puede revelar la dilución con una evaluación pequeña. Elija un cambio cuyos hechos determinantes abarquen un llamador, un valor de configuración y un efecto secundario. Ejecútelo con el conjunto mínimo de pruebas y añada después diez grupos de distractores plausibles del mismo repositorio. Registre en cada ejecución la ruta de llamadas afirmada, los símbolos citados, el parche y el resultado de las pruebas. No busca calcular una puntuación universal. Busca descubrir si el contexto adicional cambia la explicación del comportamiento sin que el programa haya cambiado.

Los resúmenes del prompt no curan esto por sí solos. Resumir toma una decisión con pérdidas sobre la relevancia antes de conocer la tarea posterior. Un resumen preparado para descubrir la arquitectura puede omitir reglas de redondeo necesarias al corregir un defecto. Mantenga los resúmenes como ayudas de orientación, únalos a las entidades fuente que describen y permita que una tarea vuelva a abrir las pruebas originales. Un resumen nunca debe convertirse en la única descripción superviviente de un módulo.

El repositorio necesita un mapa tipado antes de generar

El análisis de todo el código comienza creando una representación tipada y consultable del sistema. Un índice vectorial plano resulta útil dentro de esa representación, pero no puede ser la representación. La unidad duradera es una entidad con identidad, ubicación, lenguaje y aristas hacia otras entidades.

Como mínimo, el mapa debe representar archivos, símbolos, puntos de entrada, llamadas, lecturas y escrituras, esquemas, trabajos, pantallas, pruebas, claves de configuración e interfaces externas. Las aristas necesitan tipos porque calls, loads dynamically, writes field y runs after implican razonamientos distintos. La confianza y el origen pertenecen a cada arista. Una arista de llamada obtenida por el compilador no debe parecer idéntica a una asociación inferida por el modelo.

En repositorios antiguos, las fronteras entre lenguajes forman parte de la semántica. JCL selecciona programas y conjuntos de datos. Los mapas CICS conectan pantallas y campos. Los programas RPG dependen de archivos de visualización. Los formularios VB6 contienen conexiones de eventos fuera de los procedimientos normales. Classic ASP mezcla marcado, scripts, estado de sesión y acceso a datos. Los paquetes PL/SQL pueden ocultar efectos tras disparadores y sinónimos. Un parser del lenguaje principal solo ve una fracción del sistema ejecutable.

El mapa también necesita hechos negativos y pendientes. Si el destino de una llamada dinámica no puede resolverse de forma estática, guarde la expresión y el conjunto de candidatos en vez de elegir uno en silencio. Si dos copybooks definen el mismo registro bajo opciones de compilación distintas, conserve ambas variantes y la condición que selecciona cada una. Las incógnitas deben producir solicitudes de trazas o casos de paridad, no conjeturas en prosa.

Un registro compacto de pruebas podría tener este aspecto:

{
  "claim": "late fee is suppressed for migrated accounts",
  "path": ["BILLJOB", "FEE-CALC", "ACCT_FEE_TRIGGER"],
  "evidence": ["jobs/bill.jcl:88", "src/fee.cbl:412", "db/account.sql:219"],
  "conditions": ["RUN_MODE=MONTH_END", "account.migrated=true"],
  "unresolved": ["dynamic dataset alias at BILLIN"]
}

Ese registro no es un truco de prompt. Es una afirmación inspeccionable que otra etapa puede rebatir. Cuando la generación modifica FEE-CALC, el sistema puede localizar los puntos de entrada afectados, pedir la vinculación pendiente del conjunto de datos y elegir pruebas que ejerciten la condición. Sin el mapa, cada prompt debe redescubrir estos hechos y lo hará de manera diferente.

La representación también debe estar versionada. El código generado, los commits fuente, las instantáneas de esquemas y las trazas grabadas necesitan un límite de revisión común. De lo contrario, el grafo puede conectar un llamador del martes con una función llamada reemplazada el miércoles y describir un sistema que nunca existió. El análisis incremental debe invalidar aristas derivadas cuando cambia su fuente y recalcular las afirmaciones dependientes. Reutilizar caché sin procedencia es rápido hasta que certifica la compilación equivocada.

Leer todo el código debe hacerse por etapas

Un lector fiable separa descubrimiento, modelado del comportamiento, diseño objetivo, implementación y verificación. Las etapas pueden iterar, pero cada una produce artefactos que limitan la siguiente. Así se evita que una generación fluida borre una incertidumbre descubierta antes.

El descubrimiento inventaría lenguajes, rutas de compilación, puntos de entrada, esquemas, trabajos y fronteras externas. Analiza lo que puede analizarse, registra fallos y conecta artefactos entre lenguajes. El resultado es un mapa del repositorio junto con una lista explícita de puntos ciegos.

El modelado del comportamiento parte de operaciones observables en vez de archivos. Para cada punto de entrada, el sistema sigue condiciones, transiciones de estado, salidas y efectos secundarios. Agrupa rutas duplicadas que implementan la misma regla y separa rutas parecidas cuyas precondiciones difieren. El resultado es un conjunto de afirmaciones de comportamiento unidas a pruebas.

El diseño objetivo decide después dónde deben vivir esos comportamientos en servicios Go, núcleos Rust, clientes TypeScript o Postgres. Aquí se distingue una reescritura de una transliteración. Una conversión de párrafo a función puede conservar el flujo de control mientras arrastra estado global, acoplamiento con archivos y supuestos del planificador. El diseño debe preservar el comportamiento en la frontera y cambiar deliberadamente la estructura interna.

La implementación consume paquetes de trabajo acotados que proceden del mapa. Un paquete incluye el comportamiento objetivo, las entidades fuente pertinentes, los llamadores anteriores, los efectos posteriores, las restricciones, las incógnitas y los casos de paridad requeridos. El modelo puede pedir más pruebas. Nunca debe rellenar una arista ausente con una conjetura segura.

La verificación funciona continuamente, no después de una fusión final heroica. Los fallos actualizan el modelo de comportamiento o exponen un defecto del objetivo. Esta retroalimentación importa porque el análisis estático no puede decidir por sí solo si una rama extraña está muerta, representa una excepción regulatoria o solo aparece con datos de producción.

Este diseño por etapas emplea la atención del modelo donde tiene una tarea definida. Los modelos siguen siendo buenos interpretando código desordenado y proponiendo implementaciones. El sistema alrededor aporta identidad, memoria, recorrido y un juez que no puntúa prosa.

La revisión humana debe seguir los mismos artefactos. Los ingenieros deben revisar comportamientos discutidos y contratos objetivo, no recorrer miles de líneas generadas con la esperanza de reconocer un cambio semántico. Una etapa puede avanzar cuando sus afirmaciones tienen pruebas, sus incógnitas tienen responsables y existen las comprobaciones requeridas. Aprobar prosa pulida no pertenece a esa puerta.

Las pruebas de ejecución captan lo que la lectura estática no puede

El análisis estático describe el comportamiento posible. La ejecución grabada muestra lo que ocurrió realmente con ciertas entradas. Una reescritura seria necesita ambos porque cada uno cubre los puntos ciegos del otro.

El análisis estático puede enumerar ramas que ninguna grabación alcanzó. Puede encontrar una escritura oculta en una ruta de error, un trabajo trimestral o una acción de pantalla ausente del tráfico reciente. Las trazas resuelven llamadas dinámicas, valores reales de configuración, alias de conjuntos de datos, SQL producido durante la ejecución y el orden de los efectos externos. Ninguna fuente debe convertirse en toda la verdad.

Los equipos proponen a menudo sustituirlo por cobertura de pruebas. Las pruebas existentes son evidencia útil, pero los sistemas antiguos suelen tener suites unitarias estrechas, scripts de integración dependientes del entorno o ninguna prueba automatizada alrededor de los comportamientos que sostienen el negocio. Superarlas demuestra compatibilidad con las pruebas, no con el sistema de producción.

Un arnés de paridad da forma concreta a la comparación. Capture una entrada en una frontera estable, reprodúzcala contra las implementaciones antigua y nueva, normalice los valores no deterministas y compare las salidas y los efectos secundarios. El resultado puede representarse sin interpretación:

case: invoice/month_end/migrated_account
old: status=200 body_sha256=7c... ledger_rows=0 notices=1
new: status=200 body_sha256=7c... ledger_rows=1 notices=1
verdict: FAIL side_effect.ledger_rows expected 0 got 1

Ese fallo remite a la afirmación sobre supresión de comisiones y su ruta de pruebas. El equipo puede comprobar si el código nuevo perdió el comportamiento del disparador, si la configuración de reproducción no marcó la cuenta como migrada o si la normalización ocultó una diferencia en el origen. Una afirmación genérica como «las salidas difieren» enviaría al modelo a buscar de nuevo por todo el repositorio.

El tráfico grabado requiere cuidado. Los secretos y datos personales deben tratarse según el entorno, y los efectos destructivos deben aislarse o virtualizarse durante la reproducción. La cobertura también necesita un inventario: ¿qué puntos de entrada, periodos de negocio, clases de errores y variantes de configuración aparecen en el corpus? Un millón de solicitudes felices repetidas no cubren el extraño procedimiento de cierre.

Las reglas de comparación requieren el mismo escrutinio que las entradas capturadas. Marcas de tiempo, identificadores generados, filas sin orden y rutas propias del entorno pueden necesitar normalización, pero cada regla oculta una posible diferencia. Guarde cada regla como código, explique por qué es segura y compruebe que no enmascara un cambio importante. Si otro batch consume los registros antiguos en cierto orden, ordenarlos antes de comparar fabricaría una paridad inexistente.

La lectura paralela requiere estado compartido

Dividir un repositorio entre agentes solo ahorra tiempo real si escriben en un modelo compartido y coherente del sistema. Diez resúmenes independientes crean diez vocabularios, conclusiones duplicadas y huecos en las fronteras que cada trabajador supuso que revisaría otro.

Los trabajadores paralelos deben reclamar regiones concretas del grafo o preguntas específicas. Uno puede resolver aristas de trabajo a programa mientras otro mapea efectos de base de datos y un tercero clasifica puntos externos. Cada uno escribe entidades, aristas tipadas, pruebas y conflictos en el mismo almacén. La identidad de las entidades debe ser estable para reconocer que CUSTOMER-REC en un copybook y el búfer pasado por tres programas son el mismo diseño bajo la misma condición de compilación.

Los conflictos son un resultado útil. Si el análisis estático dice que un llamador alcanza un procedimiento, pero las trazas muestran una segunda ruta dinámica, el sistema debe conservar ambas y programar su resolución. Si dos agentes atribuyen significados de negocio distintos al mismo campo, un revisor verá el desacuerdo antes de que el código generado incorpore una interpretación.

La concurrencia también necesita planificación según dependencias. Sirve de poco generar el reemplazo de un módulo posterior mientras se discute su contrato de entrada. El trabajo puede avanzar en componentes independientes, pero los cambios que cruzan aristas pendientes deben esperar o llevar interfaces provisionales explícitas.

La afirmación de un millón de líneas solo resulta creíble bajo este modelo. CodeHero lee en paralelo todos los lenguajes del árbol y usa una representación compartida del sistema entero, en vez de tratar cada prompt como una sesión de lectura aislada. Ese hecho arquitectónico es el importante. El número de agentes concurrentes no dice nada por sí solo sobre comprensión.

La superficie de revisión debe mostrar cómo se construyó una conclusión: ubicaciones fuente, ruta del grafo, casos de trazas, interpretaciones rivales y código posterior que la consume. Una barra de progreso para directivos no basta al ingeniero que debe decidir si una regla de pagos sobrevivió a la reescritura.

El estado compartido no significa un prompt enorme compartido por todos. Significa un almacén transaccional de pruebas con identificadores estables y controles de versión. Los trabajadores pueden operar en partes acotadas y fusionar hechos solo si la revisión de la fuente aún coincide. Esto evita ambos extremos: agentes aislados que se olvidan y una conversación global que crece hasta que nadie sabe qué afirmación sigue vigente.

Calidad arquitectónica y paridad son puertas separadas

Una reescritura puede igualar el comportamiento observado y aun así reproducir mal la arquitectura antigua. También puede parecer muy moderna mientras cambia el sistema en sus fronteras. Son puertas separadas y ninguna debe compensar a la otra.

La paridad evalúa solicitudes, archivos, mensajes, cambios en bases de datos, orden sensible al tiempo y comportamiento ante errores. La revisión arquitectónica evalúa límites de módulos, propiedad del estado, modismos del lenguaje objetivo, tratamiento de fallos, observabilidad, despliegue y eliminación de acoplamientos antiguos. Una puntuación ponderada que mezcle ambos puede ocultar un fallo fatal. Exija que cada puerta se supere.

Esta es otra distinción que las demostraciones de repositorios suelen difuminar. Generar Go sintácticamente correcto desde COBOL demuestra traducción. Sustituir estado acoplado a batches por servicios explícitos mientras se conserva el cierre demuestra modernización. Lo segundo requiere el mapa del repositorio, restricciones operativas y pruebas de paridad. Generar código no basta para establecerlo.

Fije criterios de revisión antes de implementar. Para una frontera de servicio, registre llamadores permitidos, contratos de solicitud y respuesta, propiedad de la transacción, comportamiento de reintentos y casos de paridad. Para un núcleo numérico Rust, registre dominios de entrada, redondeo, desbordamiento y vectores de referencia. Para un cliente TypeScript, registre la propiedad de la validación y la imposición en el servidor. Son decisiones de ingeniería, no detalles inferidos del fragmento fuente que quedó primero.

No acepte «el modelo vio todo el repositorio» como prueba de ninguna puerta. Pida la ruta desde el punto de entrada al comportamiento cambiado, las aristas pendientes de esa ruta, la decisión objetivo que sustituyó el acoplamiento antiguo y los casos de reproducción superados. Si el sistema no aporta esas cuatro cosas, produjo código sin una explicación defendible del sistema.

La equivalencia operativa puede incluir más que cuerpos de respuesta. Horas límite de batch, orden de bloqueos, límites de reintento, modos de redondeo, codificaciones de archivos y momento de los mensajes pueden formar parte del contrato si otro sistema depende de ellos. El inventario debe marcar qué propiedades deben coincidir exactamente, cuáles pueden variar dentro de un límite y cuáles son cambios intencionados aprobados por un responsable. Llamar fallo a toda diferencia bloquea la modernización. Llamar mejora a toda diferencia incómoda abandona la paridad.

Evalúe al lector alterando las pruebas

La mejor evaluación para un lector de repositorios comprueba su estabilidad ante cambios que no deberían afectar la respuesta. Una sola demostración correcta dice poco porque el orden de archivos, las palabras de la consulta y los fragmentos elegidos pueden haber favorecido ese caso.

Prepare un conjunto de preguntas sobre el repositorio con respuestas respaldadas por varios artefactos. Incluya llamadas directas, despacho dinámico, variantes seleccionadas por configuración, efectos de base de datos, orden de batch, código muerto parecido al activo y fronteras entre lenguajes. Registre para cada pregunta la ruta de pruebas esperada, no solo una respuesta en prosa.

Altere después la entrada de forma controlada:

1. Reordene archivos y resultados del recorrido sin cambiar su contenido.
2. Añada implementaciones muertas casi duplicadas y comentarios obsoletos.
3. Cambie nombres de identificadores locales sin alterar estructura ni comportamiento.
4. Elimine un artefacto necesario y compruebe si el sistema declara incertidumbre.
5. Añada una traza que contradiga la hipótesis estática.

Puntúe por separado el recall de pruebas, la corrección de la ruta, el manejo de incertidumbre, el cambio generado y el resultado de paridad. Un lector que llega a la respuesta correcta por la ruta equivocada es frágil. Un sistema que se niega a concluir tras retirar una prueba puede ser mejor que otro que conserva la respuesta original.

El coste y la latencia forman parte de la evaluación, pero no sustituyen la precisión. Registre tiempo de parsing, coste de actualizar el índice, recorrido del grafo, llamadas al modelo, tiempo de reproducción y revisión humana. Los cambios incrementales deben actualizar las entidades y pruebas afectadas en vez de forzar una relectura completa. Así, leer todo el código se convierte en una arquitectura operativa y no en una demostración cara de lanzamiento.

La pregunta de aceptación no es si una llamada al modelo puede contener un millón de líneas. Es si el sistema puede explicar un comportamiento, resistir contexto irrelevante, exponer pruebas ausentes, producir un diseño objetivo deliberado y demostrar la nueva implementación frente a la anterior. Una ventana mayor puede ayudar en varios puntos. Nunca elimina la necesidad de la maquinaria que la rodea.