Entender código heredado con IA

El muro de los 32.000 tokens

Es la cifra más importante del post, y viene de una medición académica de 2025 centrada específicamente en la comprensión de código, no en prosa.

Ocho tipos de tarea, cuatro dimensiones (identificar una unidad de código, comprensión dentro de la unidad, relaciones entre unidades, documentación larga), nueve modelos de contexto largo. La conclusión, literalmente:

El rendimiento de todos los modelos examinados cae en picado en cuanto la longitud del código supera los 32.000 tokens — en marcado contraste con las ventanas de contexto anunciadas, de 128.000 a un millón.

Y el detalle es donde está el meollo: entre 64.000 y 128.000 tokens, el análisis de dependencias y relaciones cae prácticamente a cero. El modelo todavía «ve» el código, pero ya no entiende cómo se conecta cada cosa — justo lo que ibas a buscar a un código heredado.

La regla práctica que sale de ahí: no le des el repo, dale un hilo.

El sesgo de «mejor lo reescribo»

Hay una medición de 2026 dedicada justo a cuánto entiende un modelo la arquitectura de un repo desconocido. Las preguntas se sacaron de conversaciones reales entre desarrolladores, y la evaluación no fue con puntuación, sino con lista de comprobación.

Tiene dos conclusiones, y las dos importan.

La primera es el sesgo de edición: los modelos «proponen modificaciones de código de forma prematura en lugar de entender la arquitectura del repositorio existente». Preguntas y recibes un arreglo.

La segunda es todavía más insidiosa: hay «una brecha persistente entre la alta comprensibilidad y la corrección técnica basada en pruebas». En cristiano: la respuesta es clara, ordenada, segura de sí misma — y no está atada al código.

Por eso no hay que pedirle que «entienda el repo». Lo que recibes es un resumen que suena bien y cuya verificación cuesta más de lo que ahorró.

Lo que el modelo sabe — y de dónde lo sabe en realidad

Esta parte decide con qué puedes contar dentro de un código cerrado de empresa.

Un estudio de 2026 reunió 1.318 preguntas reales de desarrolladores con sus respuestas aceptadas de 134 proyectos de código abierto, y midió dos modelos potentes sobre ellas. Las puntuaciones base rondaron el 6,6 y el 7,0 sobre diez — dignas, pero no deslumbrantes.

El resultado decisivo, sin embargo, está en otro sitio. Cuando se prohibió a los modelos usar su conocimiento interno, su rendimiento empeoró. Y en las preguntas posteriores al corte de entrenamiento cayó en picado: de 6,59 a 5,44 en un modelo, de 6,97 a 5,97 en el otro. Los autores documentaron además reproducciones literales de respuestas de la comunidad.

O sea, el modelo rinde sobre todo en aquello que ya ha visto. En un repo cerrado, de empresa, nunca publicado, esa es exactamente la ventaja que falta.

El desglose también sirve: fuerte en preguntas de uso de API, flojo en configuración, integración y consultas. Por desgracia, en los sistemas heredados el dolor suele estar en esas tres últimas.

¿Cómo encuentra el código? Tres estrategias

Índice semántico. Corta los ficheros en trozos, los convierte en vectores y busca por significado. La ventaja es que una pregunta en lenguaje natural encuentra cosas aunque la palabra que usaste no aparezca en el código. La desventaja es que hay que mantener un índice aparte, que un cambio reciente solo se ve tras reindexar, y que el troceado puede partir partes que van juntas.

Descubrimiento por búsqueda. Sin índice: busca por patrón de fichero, luego por contenido, y luego lee el fichero. El fabricante de una de las grandes herramientas fue inusualmente franco al respecto: sus primeras versiones funcionaban con una base de datos vectorial, pero comprobaron que el descubrimiento por búsqueda suele funcionar mejor — y a ellos también les sorprendió.

Esto tiene un perfil de coste que conviene conocer: buscar por patrón de fichero sale prácticamente gratis, buscar por contenido es barato, pero leer el fichero entero cuesta entre 500 y 5.000 tokens por fichero. Quien da la orden de «léete la carpeta entera» está quemando su ventana de contexto.

Contexto completo. Lo mejor mientras quepa — pero es aquí donde choca con el límite de los 32.000 de arriba.

Una cita mal usada que conviene corregir: circula un estudio según el cual la búsqueda por palabras clave alcanza el 90 % del rendimiento de las soluciones vectoriales. Es cierto — pero se midió sobre preguntas y respuestas generales, no sobre código. Quien lo usa para justificar la decisión de las herramientas de programación se pasa de frenada.

El umbral de las 400.000 líneas

La medición propia de un fabricante examinó 1.281 ejecuciones evaluadas de agents en más de cuarenta repos grandes de código abierto, en nueve lenguajes. La conclusión: los agents que solo usan herramientas locales — búsqueda y lectura de ficheros — empiezan a atascarse de forma sistemática por encima de unas 400.000 líneas de código.

Un ejemplo concreto de la misma fuente: en un proyecto de 1,4 millones de líneas y 22.000 ficheros, sin herramienta de búsqueda de código no salió ninguna respuesta ni después de 6.000 segundos; con búsqueda indexada estuvo en 89 segundos, y con buena calidad. En una refactorización multifichero, el agent básico modificó dos ficheros de siete; el ampliado, los siete.

Y el detalle más útil: por debajo de 400.000 líneas, añadir la herramienta de inteligencia de código empeoró el resultado. Es decir, la solución pensada para un código grande es complicación innecesaria en uno pequeño.

(Medición de fabricante, sobre su propio producto, sin revisión por pares — el umbral de orden de magnitud sigue siendo utilizable.)

Una sorpresa: los comentarios a veces son ruido

Otra medición — 500 tareas de búsqueda de código, cincuenta repos, cinco lenguajes — analizó si el modelo encuentra la función buscada a partir de una descripción en lenguaje natural.

Su resultado colateral da que pensar: al quitar los comentarios, el rendimiento de los modelos mejoró (con la excepción de una única familia de modelos).

En el código heredado esto no sorprende. Un comentario de hace diez años, obsoleto y engañoso, no es ayuda sino ruido — y al modelo se lo puede despistar con él igual que a una persona.

La receta

1. NO LE PIDAS QUE "ENTIENDA EL REPO".
   Recibirás una respuesta segura, ordenada y sin atar al código.

2. PREGUNTA POR UN HILO, EN CONCRETO.
   "¿Cómo viaja una petición desde el endpoint /checkout hasta
    la base de datos? Enumera los ficheros y los números de línea."
   -> pedir ficheros y líneas es lo que ata la respuesta a pruebas

3. MANTÉN POR DEBAJO DE 32K TOKENS lo que deba entender de una vez.
   Un módulo, un flujo, una capa - no el conjunto entero.

4. LLEVA EL DESCUBRIMIENTO A UN SUBAGENT APARTE.
   Corre en su propia ventana de contexto y devuelve un resumen,
   así la sesión principal queda limpia. Un "echa un vistazo"
   sin contexto le hace leer cientos de ficheros.

5. USA EL HISTORIAL DE VERSIONES.
   "Repasa el historial de git de esta clase y resume cómo
    llegó a tener esta API." El mensaje de commit lleva una
    intención que en el código no está.

6. EN UN REPO GRANDE (más de 400.000 líneas) HACE FALTA
   NAVEGACIÓN POR SÍMBOLOS. En uno pequeño empeora - no la metas.

7. LO QUE HAYAS ENTENDIDO, ESCRÍBELO - en su sitio, y no todo.

¿Y el COBOL?

La conversación sobre código heredado acaba llegando aquí tarde o temprano, así que conviene decir con precisión cómo está el asunto.

Los productos de los grandes proveedores pasaron por un cambio de nombre a principios de 2026 — quien busque el nombre antiguo se topará con documentación obsoleta. Cifras de adopción o de resultados, en cambio, no publica ninguno.

La conclusión profesional más útil y citable de 2026: las herramientas de IA aceleran la fase de análisis y transformación del código, pero no abordan el alcance completo del programa, que es lo que decide si una migración sale bien.

Y la pieza concreta que falta: no hay herramienta de comprobación de equivalencia de comportamiento. Es decir, nada demuestra que el sistema nuevo haga realmente lo mismo que el viejo. En un entorno regulado, esa carencia bloquea.

La tesis es, por tanto: la IA aporta valor real en la fase de comprensión — mapa de dependencias, documentación, descubrimiento de código. El cuello de botella de una migración no es la traducción, sino la demostración. Con esto enlaza qué merece la pena transformar sin riesgo: lo desarrolla el post refactorizar sin romper nada , con la secuencia de comprobaciones.

Malentendidos típicos

• «La ventana de contexto es de un millón, o sea que el repo cabe.» Cabe, pero por encima de 32.000 tokens la comprensión de las relaciones se degrada, y entre 64.000 y 128.000 prácticamente desaparece.
• «Le pregunto cómo está montado el proyecto.» Está medido que el modelo propone un arreglo en su lugar, y que su respuesta es clara pero no está atada al código.
• «El modelo ya conoce este tipo de sistemas.» Conoce lo que ha visto. En las preguntas posteriores al corte de entrenamiento su puntuación baja un punto, y en un repo cerrado no tiene en qué apoyarse.
• «Le doy todo, comentarios incluidos.» En una medición, quitar los comentarios mejoró la tasa de acierto. El comentario obsoleto es ruido.
• «Hace falta un índice de búsqueda de código.» Por encima de 400.000 líneas, sí. Por debajo, según la medición, empeora.

Lo que conviene llevarse

A un código heredado no hay que hacérselo «entender» al modelo, sino hacerle seguir un hilo de punta a punta, con ficheros y números de línea. Mantén por debajo de treinta y dos mil tokens lo que deba abarcar de una vez, lleva el descubrimiento a un subagentaparte y usa el historial de versiones — en el mensaje de commit está la intención que al código le falta. El modelo es fuerte en lo que ya ha visto; en tu repo cerrado esa ventaja no existe.

Cómo conviene escribir lo que has entendido — y cuánto vale eso de verdad — lo cuenta el post documentación que sí vas a mantener , con los números; y por el lado de la comprobación, el post la red de seguridad de los tests lo lleva más lejos.