Ingeniería de contexto para agentes de código con IA: por qué las ventanas más grandes no bastan
Por qué una ventana de un millón de tokens no arregla a los agentes de código y cómo los presupuestos de tokens, los grafos del repositorio y la memoria por capas les dan el contexto correcto en lugar de más contexto.
Las ventanas de contexto más grandes no arreglaron a los agentes de código
Lo que frena a los asistentes de código con IA ya no es la inteligencia. El punto débil es cómo guardan, recuperan y conectan la información a lo largo de toda una base de código.
Cuando llegaron las ventanas de un millón de tokens, la promesa sonaba redonda: por fin el modelo puede abarcar todo su repositorio. Quien haya puesto a ChatGPT (Codex), Cursor, Claude Code o Gemini (Antigravity) a trabajar en un proyecto real sabe cómo acaba. Pide arreglar un bug en AuthService.ts y el modelo se olvida de un helper que está a veinte archivos de distancia. Añade una ruta nueva de la API y escribe código contra una versión antigua de la interfaz. La ventana es enorme y la respuesta sigue estando mal.
El modelo no es demasiado pequeño. El contexto está mal gestionado.
El presupuesto de tokens importa más que el límite de tokens
Una ventana de contexto es un techo, no una memoria que se pueda llenar a placer. Un repositorio de producción de tamaño medio contiene muchas cosas a la vez:
- código fuente repartido en cientos de archivos
- diffs de git de cambios en curso
- trazas de pila y logs
- documentación de la API
- archivos de configuración
- READMEs y notas de arquitectura
Meterlo todo en el prompt es caro y casi siempre inútil. Compárelo con la RAM de un sistema operativo: un portátil con 32 GB no carga todo el disco en memoria solo porque podría.
Los agentes de código se comportan igual y gestionan un presupuesto de tokens. La pregunta deja de ser qué cabe y pasa a ser qué merece los tokens.
Qué tiene prioridad
En lo más alto de la lista está el archivo que se está editando, junto con los cambios recientes de git, las dependencias que importa y las funciones implicadas en el error. Al final quedan la documentación sin relación, los logs antiguos, los módulos sin uso y los rincones lejanos del repositorio.
Decidir qué llega al modelo, en lugar de limitarse a ampliar la ventana, es lo que se ha empezado a llamar ingeniería de contexto.
Por qué los proyectos grandes producen más alucinaciones
Las alucinaciones al programar rara vez son aleatorias. Normalmente el modelo recibió solo un fragmento del panorama. Tome esta secuencia. Primero se carga UserService.ts:
`UserService.ts` is loaded.
Después, PermissionManager.ts nunca llega a entrar:
`PermissionManager.ts` is not loaded.
Por último, el modelo rellena el hueco con una lógica de permisos inventada:
The model invents permission logic.
Desde la posición del modelo, la información ausente se ve exactamente igual que la información que no existe. La investigación sobre contexto largo añade un segundo problema: a los modelos les cuesta aprovechar detalles relevantes enterrados en medio de un prompt muy largo, un efecto llamado Lost in the Middle. Así que las ventanas más grandes suavizan algunos fallos, pero no eliminan los errores de recuperación.
Piense en el repositorio como un grafo
Este modelo mental cambia la forma de abordar el problema. Un repositorio no es un montón de archivos, es un grafo. Los nodos son las piezas con significado: archivos, clases, funciones, APIs y modelos de base de datos. Las aristas son relaciones como importaciones, llamadas a funciones, herencia y flujo de datos.
Ahora dele al agente una tarea como "arregla el timeout de autenticación". No necesita leer 400 archivos. Recorre el grafo y recoge el vecindario en torno a la autenticación, lo que cuesta mucho menos que cargarlo todo.
Siga las dependencias, no solo las palabras clave
La generación aumentada por recuperación clásica busca fragmentos semánticamente cercanos a la consulta. Eso ayuda, pero el código tiene una estructura que la prosa no tiene. Un pipeline mejor funciona así:
User query -> Semantic search finds relevant functions -> Graph traversal expands connected dependencies -> Context optimizer compresses everything into the token budget
Así, en lugar de fragmentos aislados, el agente recibe contexto conectado. Es la idea central de la recuperación basada en grafos, como GraphRAG de Microsoft. Tenga en cuenta que GraphRAG es una arquitectura de investigación y nadie ha confirmado que funcione dentro de asistentes de código comerciales.
Un historial de chat no es memoria
Un error habitual es tratar el historial de la conversación como memoria. En realidad, los agentes de código mantienen tres capas:
- Contexto de trabajo: el prompt actual y los archivos activos
- Ventana deslizante: la conversación y las ediciones recientes
- Memoria de recuperación: conocimiento del repositorio que se trae bajo demanda
Por eso Cursor o ChatGPT (Codex) pueden mantener una sesión larga de programación sin llevar en el prompt todos los mensajes anteriores. Recuperan lo relevante cuando hace falta en lugar de reproducir la conversación entera. Las implementaciones varían entre productos, pero el diseño por capas es un patrón común en los agentes modernos.
Cómo es un pipeline de contexto
El futuro no son ventanas infinitas, sino pipelines mejores. Un motor de contexto podría hacer lo siguiente:
- Convertir el repositorio en un AST.
- Construir a partir de él grafos de dependencias y de llamadas.
- Crear embeddings para que funcione la búsqueda semántica.
- Empezar por los nodos que coinciden y expandirse hacia fuera siguiendo las dependencias.
- Comprimir lo recuperado antes de enviarlo al LLM.
Una búsqueda en anchura puede reunir las dependencias cercanas, y la centralidad del grafo o una clasificación al estilo PageRank puede destacar los archivos con más influencia. Así que construirlo requiere al menos tanta ingeniería de software corriente como trabajo con modelos.
Leer los tokens correctos
La carrera hacia ventanas más grandes importa, pero no será toda la respuesta. Un asistente no mejora por leer más tokens, sino por leer los correctos en el momento oportuno. Ese es el paso de la ingeniería de prompts a la ingeniería de contexto, y si los agentes van a construir software de producción, tratar los repositorios como grafos y no como archivos de texto gigantes podría acabar siendo una de las ideas de arquitectura más importantes para la próxima generación de asistentes.
Dónde leer más
- Artículo de investigación sobre las debilidades de los prompts largos, Lost in the Middle (ACL 2024): https://aclanthology.org/2024.tacl-1.9/
- Documentación de Microsoft GraphRAG: https://microsoft.github.io/graphrag/
- Repositorio de GraphRAG en GitHub: https://github.com/microsoft/graphrag
- El artículo original de RAG, NeurIPS 2020: https://arxiv.org/abs/2005.11401
- Building Effective AI Agents: https://www.anthropic.com/engineering/building-effective-agents