Dar a un agente de IA el contexto de un repositorio grande sin indexador local

Un repositorio grande no cabe en una ventana de contexto, y si alguna vez has apuntado un indexador de portátil a un monorepo real, sabes que ahí tampoco cabe cómodamente — la RAM se dispara, el primer índice tarda una hora, y tu agente sigue empezando la siguiente sesión adivinando qué archivos importan.

La respuesta habitual es ejecutar un indexador junto al editor, y para un repo que cabe cómodamente en una sola máquina, es una buena respuesta. Si tu monorepo ya se indexa rápido en Cursor y ese es el único sitio donde necesitas el mapa, este artículo no tiene nada que añadir — sáltatelo.

Este artículo trata del otro caso — cuando un agente necesita un mapa consultable de un repo grande, y no quieres ejecutar un indexador local para conseguirlo.

Cuándo un indexador local es la herramienta equivocada

Un índice local asume que el código vive en la máquina que lo consulta, y a la escala real de un monorepo esa suposición se tensa incluso dentro de un solo editor. El repo es sencillamente más grande de lo que quieres mantener caliente en un portátil: trabajas en un paquete mientras el radio de impacto vive tres directorios más allá, y un primer índice en frío de un árbol de dos millones de líneas no es algo que quieras sufrir dos veces — ni en tu máquina, ni en un runner de CI que nunca clonó el árbol antes. O un compañero debería poder consultar el mismo mapa que tú, sin esperar a que su propia máquina se abra paso por el mismo índice.

Nada de esto es razón para desechar un buen indexador de editor. Es razón para tener también un mapa alojado que cualquiera de tus agentes pueda consultar por MCP.

Y el problema de escala va más allá de «demasiados archivos para pegar». En un árbol grande, la pregunta interesante casi nunca es «muéstrame este archivo» — es qué archivo, qué símbolo, qué llamadores, qué pruebas. Un agente que empieza listando src/ y leyendo los tres primeros resultados fallará alegremente el handler en apps/api y el cliente generado en packages/sdk. Lo que necesitas es una recuperación construida desde todo el árbol, luego clasificada, luego citada.

Qué significa realmente «contexto de un repo grande»

Volcar archivos en el prompt no es contexto — es una copia más pequeña y peor del árbol. Lo que tu agente realmente necesita es hacer preguntas y recibir respuestas citadas de vuelta: dónde está definido este símbolo y quién lo llama, qué depende del módulo que estoy a punto de cambiar, qué archivo de prueba cubre este comportamiento, y cómo se ve el árbol ahora, no el trimestre pasado.

Esas respuestas tienen que venir de un índice construido a partir de tu repo en lugar de la memoria del modelo sobre repos de otras personas, y el índice tiene que vivir en algún lugar distinto de la ventana de contexto del agente. Para este problema, también debería vivir en algún lugar distinto de tu portátil.

Otra cosa que los archivos de instrucciones no pueden hacer por ti: CLAUDE.md y AGENTS.md son el lugar correcto para las convenciones y el comportamiento, pero no son un mapa vivo, clasificado y consultable de un árbol de dos millones de líneas. Usa las reglas para el comportamiento; usa la inteligencia del repo para los hechos.

Construir el mapa en la nube, consultarlo desde cualquier cliente

Maguyva es una capa de contexto de código MCP remota. Conectas GitHub, eliges tus repositorios, y te marchas mientras los pipelines en la nube analizan el árbol, construyen los símbolos y las aristas del grafo, y mantienen un mapa clasificado — sin indexador local, nunca.

Cuando subes código, los archivos cambiados se analizan de forma incremental, y las capas de grafo y clasificación se reconstruyen según un calendario: diario en el plan gratuito, cada hora en los de pago. Cada snapshot lleva marca de tiempo, así que tu agente puede saber qué versión del árbol está leyendo. El límite honesto aquí es el trabajo local no sincronizado — una edición que solo existe en tu árbol de trabajo, nunca subida, aún no está en el mapa alojado.

Luego conectas el cliente que ya uses añadiendo una clave de API a su configuración MCP. Hay guías de configuración para 24 clientes MCP documentados, y cualquier otro cliente compatible con MCP que soporte la configuración estándar también puede conectarse. Si Cursor es donde vives, la página de Cursor recorre ese camino; el mismo servidor responde a Claude Code, VS Code, Windsurf, Codex CLI y el resto.

No cambias de editor. Le das a tu agente una superficie de herramientas — 11 herramientas MCP en búsqueda, símbolos, análisis de dependencias, recuperación de archivos y contexto de repositorio — con cobertura de más de 279 lenguajes y tecnologías basadas en texto, lo cual importa más de lo que crees en un monorepo que dejó de ser un solo lenguaje hace años.

Las respuestas vuelven fundamentadas, como rutas de archivo con números de línea. La recuperación semántica, estructural, por grafo y de texto se fusionan en resultados clasificados, de modo que una pregunta como «qué depende de parseConfig» no te da ni un volcado de grep ni un solo fragmento semántico, sino el puñado de lugares que realmente importan.

Una guía concreta

No empieces indexando toda la empresa. Este es el camino que funciona:

1. Elige un repositorio que ya conozcas bien — un paquete que puedas evaluar a mano vale más que el árbol más grande que tengas.
2. Empieza gratis: 3 repos, 50k líneas indexadas, las 11 herramientas, sin cuota mensual de consultas. Si tu repo representativo es más grande, la página de precios lista los niveles de espacio de trabajo ($0, $19, $49, $149) por huella indexada — no por número de asientos.
3. Conecta GitHub y espera a que termine el primer índice. No estás compilando nada localmente.
4. Conecta el cliente MCP — unas pocas líneas de configuración. Maguyva es un servidor MCP remoto, así que no hay plugins, ni extensiones, ni un segundo editor que adoptar.
5. Haz una pregunta que puedas verificar. «¿Qué depende de parseConfig?» o «¿Dónde se gestiona la expiración de sesión de inicio?» Luego abre los resultados citados file.ext:line y compáralos con el árbol que tienes delante.
6. Solo después de que las citas sobrevivan a ese contacto dejas que el agente edite.

Si el primer repo encaja bien y tu árbol es grande, sube el espacio de trabajo para que coincida con tus líneas indexadas y la cadencia de reconstrucción. Humanos y agentes comparten el mismo recuento de usuarios — Maguyva cobra por espacio de trabajo, no por asiento — así que añadir un tercer agente al bucle no te cuesta nada.

La prueba de activación es la misma que recomiendan los docs para cualquier primera ejecución: indexar un repo que ya conoces, hacer una pregunta que puedas verificar. Un repo grande no cambia la prueba; solo hace que un primer archivo equivocado salga más caro.

Qué vigilar una vez conectado

Vigila tres cosas. Frescura: los planes de pago se reconstruyen cada hora, los gratuitos a diario, y el trabajo local no subido no estará en el mapa — ese es el trato que aceptas. Alcance: indexa un conjunto representativo de repos, no cada fork archivado; el nivel gratuito está deliberadamente dimensionado para averiguar si las respuestas merecen la pena conservarse. Y verificación: un mapa de repo grande que no pueda citar rutas y números de línea es solo un motor de adivinanzas más lento, así que haz que tu agente muestre la ubicación antes de entregar el parche.

Luego ejecuta la misma prueba que ejecutarías en un repo pequeño. Indexa un repo que ya conoces. Haz una pregunta que puedas verificar. Si el mapa es real, tu agente deja de empezar desde un árbol frío.

// no laptop got hot building this map.