El presupuesto de contexto: cómo dejamos de hacer que nuestros agentes de IA leyeran el código entero

Pídele a un asistente de programación con IA que haga un cambio en un código real y observa lo que hace de verdad. Busca nombres de archivo. Hace grep de un símbolo. Abre un archivo de 400 líneas para usar doce. Abre tres archivos más para averiguar quién llama al primero. En algún punto de todo eso, escribe el cambio que le pediste.

La mayor parte de la factura se va en buscar, no en construir

Cada uno de esos pasos cuesta tokens, y el coste es peor de lo que parece. Las 388 líneas que el agente no necesitaba no desaparecen cuando encuentra las doce que buscaba: se quedan en la ventana de contexto durante el resto de la sesión, quitando espacio al trabajo real. En un monorepo de Kotlin Multiplatform con una app para Android, un cliente iOS y un backend compartido, un agente puede quemar la mayor parte de su ventana orientándose antes de cambiar una sola línea.

Probamos nuestras propias herramientas antes de cobrarle a nadie por el tiempo de usarlas. Esta es la parte del desarrollo asistido por IA que nadie enseña en la demo, y es la que decide si la herramienta es rentable en un proyecto real de cliente o solo en uno de juguete.

El problema es buscar leyendo

El bucle de exploración por defecto, buscar archivos, hacer grep, leer, repetir, tiene una propiedad que lo hace caro: su coste no tiene techo y se vuelve a pagar en cada sesión.

No tiene techo porque el agente no puede saber de antemano cuántos archivos coinciden ni cuánto ocupan. Vimos a un agente gastar 0,40 $ en tokens solo abriendo archivos para encontrar dónde se inicializaba una clave de API. Con un grafo, eso cuesta 0,01 $.

Se vuelve a pagar porque nada de ese trabajo persiste. La comprensión estructural que el agente construye en una conversación se tira a la basura cuando termina la sesión. La siguiente empieza de cero y hace grep hasta llegar a las mismas conclusiones.

Esa es la ineficiencia real. No que el modelo sea lento, sino que vuelve a deducir una y otra vez hechos sobre el código que no han cambiado.

Qué cambia un grafo de conocimiento

Empezamos a usar Graphify, una herramienta de código abierto que convierte un proyecto, código, documentación, esquemas SQL, configuraciones, PDFs, en un grafo de conocimiento consultable. Se registra como skill en Claude Code, Cursor, Copilot y Gemini CLI, de modo que el agente consulta el grafo en lugar de hacer grep sobre el sistema de archivos.

Lo que nos convenció fue el mecanismo. Importan cuatro propiedades:

• La estructura se extrae una vez, no se vuelve a deducir. El código se analiza con un AST de tree-sitter: determinista, sin modelo de por medio, nada sale de la máquina. La segunda sesión no repite la exploración de la primera.
• El coste de recuperación está acotado por diseño. Una consulta al grafo acepta un presupuesto explícito de tokens. El agente pregunta y recibe un recorrido limitado a ese tamaño, sin importar cuántos archivos habrían coincidido en una búsqueda de texto.
• «¿Qué se rompe si cambio esto?» se responde recorriendo, no leyendo: un recorrido inverso sobre las aristas del grafo. La alternativa es abrir el llamador del llamador, exactamente el patrón de lectura sin techo del que intentábamos escapar.
• Cada arista está etiquetada como extraída o inferida. Las conexiones leídas directamente del código se marcan aparte de las que la herramienta resolvió por su cuenta. Un agente que no distingue un hecho de una suposición refactorizará con total confianza sobre una suposición.

Cómo se compara con las alternativas

No lo adoptamos porque gane a todo. Lo adoptamos por una lectura honesta de dónde encaja:

• Grep y lectura de archivos: cero configuración, nunca desactualizado. Sigue siendo la herramienta correcta para preguntas rápidas y locales de un solo archivo.
• Indexación vectorial o RAG: muy buena en recuerdo difuso («encuéntrame algo parecido a esto»), pero devuelve fragmentos, no relaciones. No puede responder «qué depende de este módulo».
• Inteligencia de código alojada y LSPs (Sourcegraph, Serena y similares): geniales a escala, pero a menudo requieren enviar código a servidores externos o no soportan archivos que no sean de código, como PDFs y configuraciones. Buena parte de nuestro trabajo es código de cliente bajo acuerdo de confidencialidad. El análisis de código de Graphify se ejecuta en local y sin llamada a modelo, lo que significa que el parseo nunca sale de la máquina. Esa sola propiedad zanja la decisión para nosotros.

Dónde encaja en nuestra forma de trabajar

Trabajamos con una configuración multiagente: un orquestador que enruta el trabajo y agentes especialistas que poseen un carril cada uno. Los agentes de solo lectura, los que exploran, planifican y revisan, tienen las consultas al grafo como herramienta de exploración.

El efecto práctico es que un agente que planifica un cambio de arquitectura multiplataforma puede mapear el sistema sin cargar el sistema. Le pregunta al grafo qué conecta con qué, recibe una respuesta acotada y gasta el contexto que le queda en el problema de diseño real, no en arqueología del sistema de archivos.

El agente no lee más rápido. Lee menos.

Los límites, dichos con honestidad

Preferimos escribir esta parte a que la descubras tú:

• El grafo se desactualiza. Después de una refactorización importante hay que actualizarlo, o el agente está razonando sobre un código que ya no existe.
• El análisis de lo que no es código no es gratis. El parseo de código es local y determinista, pero los documentos y PDFs se analizan semánticamente: eso usa un modelo y cuesta tokens.
• Las aristas inferidas son inferencias. Marcado como incierto no equivale a correcto. Siguen requiriendo criterio.
• Hay un coste de configuración por repositorio. Pequeño, pero no nulo.

Una herramienta que reduce el gasto en tokens mientras introduce sobrecarga de mantenimiento es un intercambio, no una victoria gratis. Nos parece un buen intercambio para el tamaño de código con el que trabajamos.

Nuestro enfoque

Esta obsesión por la eficiencia de las herramientas es nuestra forma de trabajar en TRIUUM. Al mantener a nuestros agentes de IA enfocados en escribir código en lugar de buscarlo, construimos arquitecturas móviles y multiplataforma complejas más rápido y con menos horas facturables desperdiciadas en fricción. Si buscas un socio de ingeniería que entienda profundamente los flujos de trabajo de desarrollo modernos y respete tu presupuesto, hablemos.

Graphify es de código abierto, y merece veinte minutos de tu tiempo si tus agentes gastan más contexto encontrando código que cambiándolo: github.com/Graphify-Labs/graphify.