Hace apenas un año, cuando un coding agent necesitaba entender un proyecto, la estrategia era bastante simple.
Leer archivos.
Muchos archivos.
Mientras más contexto entrara en la ventana del modelo, mejor.
Ese enfoque funcionó… hasta que dejó de hacerlo.
Los repositorios crecieron.
Las ventanas de contexto también.
Pero apareció un problema nuevo.
El agente podía leer el código.
No necesariamente podía entenderlo.
Y ahí empieza el cambio más interesante que estamos viendo este año.
Los coding agents están dejando de depender de leer miles de archivos para empezar a consultar conocimiento estructurado.
No es una mejora incremental.
Es un cambio de arquitectura.
El problema del RAG para código
La primera generación de herramientas resolvía el problema mediante RAG.
El proceso era más o menos así:
Repositorio
↓
Embeddings
↓
Búsqueda vectorial
↓
Fragmentos relevantes
↓
LLM
Cuando el agente necesitaba saber cómo funcionaba una clase…
…buscaba algunos archivos similares y los agregaba al prompt.
Era una enorme mejora respecto a enviar el repositorio completo.
Pero seguía teniendo limitaciones.
Leer no significa comprender
Imaginemos una pregunta bastante común.
¿Dónde se calcula realmente el precio final de una orden?
La respuesta probablemente involucre:
-
varios archivos,
-
interfaces,
-
clases,
-
dependencias,
-
llamadas indirectas,
-
lógica distribuida.
Un RAG tradicional devuelve los archivos “parecidos”.
Pero no entiende que:
-
una función llama a otra,
-
un símbolo fue renombrado,
-
un módulo pertenece a otro dominio,
-
dos clases nunca aparecen juntas en el mismo archivo pero están íntimamente relacionadas.
Eso requiere una representación distinta.
Entra el Knowledge Graph
En lugar de preguntar:
“¿Qué archivos se parecen a este?”
el agente empieza a preguntar cosas mucho más interesantes.
Como por ejemplo:
“¿Qué funciones llaman a esta?”
o
“¿Quién es dueño de este módulo?”
o
“¿Qué cambios rompieron esta dependencia?”
Ya no consulta texto.
Consulta relaciones.
Repositorio
↓
Parser
↓
Knowledge Graph
↓
Consulta estructurada
↓
LLM
Y esa diferencia cambia completamente la calidad del contexto.
Ya empezamos a ver esta evolución
Lo interesante es que esto no viene de un único proyecto.
Varios repositorios muy distintos están convergiendo hacia la misma idea.
Context7
Cuando escribimos sobre Context7, la propuesta parecía simplemente “mejores documentos para agentes”.
Pero en realidad hace algo más importante.
Entrega información estructurada y versionada.
El agente deja de adivinar APIs leyendo documentación vieja.
Consulta una fuente organizada.
ctx
ctx ataca otro problema.
Meses de conversaciones con Claude Code, Cursor, Codex o Gemini CLI quedan guardados como transcripts.
Hasta ahora eso era texto muerto.
ctx los normaliza, los indexa en SQLite y permite consultarlos en milisegundos.
No vuelve a cargar miles de líneas.
Recupera exactamente el conocimiento necesario.
codebase-memory-mcp
Quizás el ejemplo más claro.
Construye un knowledge graph persistente del repositorio.
Funciones.
Símbolos.
Dependencias.
Relaciones.
Todo expuesto mediante MCP.
El agente ya no necesita recorrer el árbol completo del proyecto.
Consulta directamente el grafo.
Repowise
Repowise lleva la idea un paso más allá.
No solamente entiende el código.
También incorpora información que normalmente vive fuera del repositorio.
Por ejemplo:
-
ownership,
-
hotspots,
-
historial Git,
-
arquitectura,
-
documentación.
Es decir.
Empieza a representar conocimiento organizacional.
Orqenix
Y después aparece Orqenix.
Su foco principal no es el grafo.
Es el runtime.
Pero vuelve a aparecer el mismo patrón.
Memoria persistente.
Skills.
Plugins.
Aprendizaje.
Todo organizado como conocimiento reutilizable.
No como prompts gigantes.
Todos están resolviendo el mismo problema
Aunque parezcan herramientas distintas…
…en realidad responden exactamente a la misma pregunta.
¿Cómo evitamos volver a leer el mismo repositorio una y otra vez?
La respuesta empieza a ser:
No lo leamos.
Construyamos una representación mejor.
¿Qué gana el agente?
Muchísimo.
Menos tokens
En lugar de enviar veinte archivos…
consulta una relación.
Más velocidad
Una consulta estructurada tarda milisegundos.
Leer cientos de miles de tokens no.
Mejor precisión
Las relaciones entre símbolos sobreviven aunque cambie el formato del código.
Memoria real
El agente puede recordar:
-
decisiones,
-
patrones,
-
arquitectura,
-
workflows,
-
ownership,
sin volver a descubrirlos cada sesión.
¿Estamos viendo el reemplazo del RAG?
No exactamente.
Probablemente estemos viendo su evolución.
El RAG sigue siendo muy útil para:
-
documentación,
-
RFCs,
-
wikis,
-
tickets,
-
especificaciones.
Pero para entender un repositorio…
…cada vez parece más claro que un grafo de conocimiento ofrece una representación mucho más rica.
No reemplaza al RAG.
Lo complementa.
Y en muchos casos, lo supera.
El próximo paso
Creo que durante los próximos doce meses vamos a empezar a hablar mucho menos de ventanas de contexto.
Y mucho más de:
-
runtimes,
-
memoria,
-
grafos,
-
conocimiento estructurado,
-
MCP,
-
context engines.
La pregunta dejará de ser:
¿Cuántos millones de tokens soporta este modelo?
Y pasará a ser:
¿Qué sabe realmente sobre mi proyecto antes de empezar a leer archivos?
Esa diferencia es enorme.
Porque un agente inteligente no necesariamente es el que más lee.
Es el que mejor recuerda.
La tendencia
Si algo nos enseñaron Context7, ctx, codebase-memory-mcp, Repowise y Orqenix es que el futuro de los coding agents probablemente no pase por seguir ampliando la ventana de contexto indefinidamente.
Pasa por construir mejores representaciones del conocimiento.
Los humanos tampoco resolvemos un problema releyendo todo un repositorio cada mañana.
Recordamos relaciones.
Reconocemos patrones.
Sabemos dónde buscar.
Los agentes empiezan a hacer exactamente lo mismo.
Y creo que ese cambio va a ser mucho más importante que el próximo modelo con diez millones más de tokens de contexto.
Porque el verdadero objetivo nunca fue leer más.
Siempre fue entender mejor.