# Primero el mapa, después la revisión

Canonical source: https://maguyva.ai/es/blog/map-first-review-second

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-09-07 · Author: Maguyva Team

> Ancla al agente de código en un mapa del repo antes de que escriba. Deja que Greptile revise el pull request después. Un dúo complementario, no un reemplazo.

Dos trabajos distintos se sitúan a cada lado de un pull request. Antes de que el agente escriba, necesita un mapa del árbol que está a punto de cambiar. Después de que el agente abre un PR, algo debería leer ese cambio contra el resto del sistema y dejar comentarios sobre los que un humano pueda actuar.

Esos trabajos se parecen desde lejos porque ambos implican «entender la base de código». No son el mismo producto. Uno responde «¿dónde debería aterrizar este cambio?». El otro responde «¿qué rompió este diff que un linter línea por línea no verá?». Confundirlos produce un primer borrador peor y una revisión más ruidosa.

Este artículo es una guía de flujo de trabajo conjunto. Maguyva es el mapa que el agente consulta primero. Greptile es el agente de revisión que comenta el PR después. El dúo es complementario por construcción: Maguyva no revisa pull requests, y Greptile no reemplaza la capa de contexto que el agente usó para escribirlos.

## Por qué es útil esta división

Un agente de código que parte de priors de entrenamiento más unos cuantos archivos pegados inventará una ruta plausible y la editará. Ese es el fallo del archivo equivocado, y es un problema de recuperación. Maguyva es una capa de contexto de código MCP remota: recuperación semántica, estructural (AST), por grafo/dependencia y de texto, fusionada en resultados clasificados, más búsqueda de símbolos y recuperación de archivos. Las respuestas fundamentadas vuelven como `path/file.ext:line`, así que puedes rechazar un fallo antes de que exista un parche. La afirmación se mantiene modesta: menos ediciones alucinadas. El modelo todavía puede adivinar. El primer paso simplemente deja de ser una suposición.

Greptile es un agente de revisión de código con IA. En sus propias palabras, revisa automáticamente cada pull request con comprensión completa de la base de código, y posiciona eso frente a los linters tradicionales que verifican archivos de forma aislada en lugar del sistema entero. La configuración consiste en instalar la app de GitHub o GitLab y seleccionar repositorios. No hay ningún índice local que tengas que gestionar. El alojamiento es Greptile Cloud (declaran cumplimiento SOC 2 Tipo II, con un informe disponible bajo solicitud), con una opción autoalojada ofrecida a empresas.

Su propio flujo numerado es: conectar y construir un grafo de dependencias de cada función, clase y dependencia; en cada pull request, analizar el cambio usando ese grafo completo del repo y publicar hallazgos como comentarios del PR con correcciones sugeridas, en unos tres minutos; cada comentario puede pasar el problema a un agente de código que el equipo ya usa. También declaran leer comentarios humanos anteriores de PRs a lo largo del tiempo para aprender los estándares de código de un equipo y reducir sugerencias ruidosas. Su sistema de aprendizaje, según declaran, necesita entre 2 y 3 semanas para adaptarse.

Eso es revisión, no redacción. La fortaleza de Greptile es el contexto de grafo completo del repo sobre el cambio que ya aterrizó en un PR, seguido de un bucle cerrado que envía el hallazgo a Claude Code, Codex, Conductor, Cursor o Devin. La fortaleza de Maguyva es el mapa clasificado que el agente consultó antes de que ese cambio se escribiera. Usa ambos. No le pidas a ninguno de los dos que haga el trabajo del otro.

Una integración de producto de primera parte Maguyva–Greptile no está declarada. No la necesitas. Maguyva habla con el agente por MCP. Greptile habla con GitHub o GitLab a través de su app. Se encuentran en el pull request. Sin script de pegamento, sin cron que canalice una herramienta hacia la otra. El dúo prescinde de bash porque cada producto ya ocupa la superficie que le corresponde.

## Lo que esto no es

Esto no es un desmontaje de Greptile. No es una página de «cambia de revisor». Greptile se lanzó en Hacker News el 5 de marzo de 2024 como empresa de Y Combinator W24, y ese hilo es cómo mucha gente conoció el producto por primera vez. Si así fue como los encontraste, quédate con ellos. Esta página es la mitad delantera que falta en ese bucle: anclar al agente para que el PR que Greptile ve ya apunte a los archivos correctos.

Los materiales de marketing de Greptile encabezan con afirmaciones de velocidad de revisión y detección de bugs. Trátalas como afirmaciones propias de Greptile, no como cifras verificadas independientemente. Este borrador no las repite como hechos.

La cobertura de lenguajes es el mismo tipo de honestidad. Greptile enmarca su soporte como cobertura de todos los lenguajes de programación en lugar de una lista enumerada; no se indica una cifra precisa. Maguyva publica más de 279 lenguajes y tecnologías basadas en texto, con una división técnica (AST respaldado por parser frente a solo texto) en el sitio cuando la pregunta es técnica. Son productos distintos haciendo afirmaciones distintas. No los mezcles.

El precio de Greptile no se indica en las notas que este borrador puede usar. Existen planes de pago; consulta su página de precios. Maguyva cobra por espacio de trabajo, no por asiento. Los planes empiezan gratis. La [página de precios](/es/pricing) lista los niveles publicados si necesitas las cifras de espacio de trabajo.

## Flujo de trabajo

Tres etapas con nombre. Ejecútalas en este orden. No te saltes ninguna la primera vez que pruebes el dúo.

### 1. Contexto de Maguyva

Indexa un repositorio que ya conozcas. Conecta el cliente MCP en el que ya escribes — Claude Code, Cursor, Codex CLI, VS Code, Windsurf, u otro cliente compatible con MCP. Maguyva tiene guías de configuración para 24 clientes MCP documentados y puede conectarse a otros clientes que soporten la configuración MCP estándar.

Haz una pregunta que puedas evaluar antes de que nadie escriba una línea. «¿Dónde se gestiona la expiración de sesión, y qué la llama?» es un mejor primer movimiento que «arregla la autenticación». Exige citas. Abre los resultados `file.ext:line`. Sigue el símbolo. Confirma la dependencia que estás a punto de tocar.

Maguyva expone 11 herramientas MCP de cara al cliente en búsqueda, símbolos, análisis de dependencias, recuperación de archivos, contexto de repositorio y flujos de trabajo utilitarios deterministas. Cuatro modos de recuperación se fusionan en resultados clasificados; `find_symbol` es una herramienta separada cuando ya conoces el nombre. Los [docs](/es/docs) describen el camino más corto: empezar gratis, indexar un repo que ya conoces, conectar el cliente, luego hacer una pregunta que puedas verificar.

Los snapshots llevan marca de tiempo, así que el agente puede saber qué versión del árbol está leyendo. El límite honesto es el trabajo local no sincronizado. Si la edición solo existe en un árbol de trabajo y no se ha subido, el mapa alojado todavía no la contiene. Los archivos de instrucciones (`CLAUDE.md`, `AGENTS.md`) siguen teniendo su lugar aquí, para convenciones y lo que no hay que tocar. No son un mapa vivo. Úsalos para el comportamiento. Usa Maguyva para los hechos.

No dejes que el agente abra un PR antes de que las citas sobrevivan al contacto con el repo. Esa barrera es todo el sentido de esta etapa.

### 2. PR del agente

El mismo agente ahora escribe el cambio en el cliente por el que ya pagas. Maguyva no es un editor ni un revisor. El agente sigue produciendo el diff. Sigues abriendo el pull request en GitHub o GitLab como ya lo haces.

Lo que debería ser distinto es el primer archivo. El PR debería nombrar el handler que realmente implementa el comportamiento, el llamador que se romperá, y la prueba que fallará si el cambio está mal. Si se saltó la etapa 1, la etapa 3 gastará sus comentarios en un cambio que aterrizó en el paquete equivocado. Greptile puede seguir encontrando problemas sistémicos. No debería tener que recuperarse además de una ruta alucinada.

Mantén el PR acotado. Un primer archivo fundamentado no es licencia para reescribir el módulo. El dúo complementario funciona cuando el agente hizo un trabajo con un mapa, y luego le pidió a un revisor que hiciera otro trabajo sobre un diff acotado.

### 3. Revisión de Greptile

Greptile ya está conectado al repositorio a través de la app de GitHub o GitLab. En el nuevo pull request analiza el cambio usando el grafo completo del repo que construyó y publica hallazgos como comentarios con correcciones sugeridas. Sus propios materiales sitúan ese pase en unos tres minutos.

Lee los comentarios como leerías a un compañero cuidadoso: abre la ubicación citada, decide si el hallazgo es real, luego actúa. Donde Greptile ofrece «Fix with your Agent», envía el problema — rutas de archivo, números de línea, código sugerido — a Claude Code, Codex, Conductor, Cursor o Devin. «Fix All» envía todos los problemas de la revisión de una vez. También ofrecen un MCP de Greptile y un plugin de Claude Code para ese traspaso. Maguyva no está en esa lista de destinos nombrados; esa ausencia no es un problema. Maguyva ya hizo su trabajo en la etapa 1. El agente de código que escribió el PR es el que debería recibir la carga útil de corrección.

Espera ruido durante las primeras 2 a 3 semanas mientras el sistema de aprendizaje de Greptile se adapta a los comentarios que tu equipo realmente deja. Ese es su calendario declarado, no un defecto en el dúo. La revisión humana sigue en el bucle. Greptile es el primer pase automatizado, no el botón de fusión.

Si un comentario de Greptile señala un archivo que el agente nunca consultó en la etapa 1, esa es una señal útil. O el mapa se perdió un llamador, o el agente se saltó una cita. Corrige el borrador contra el comentario. No desactives al revisor.

## Cómo mantener honesto el complemento

- Maguyva primero, siempre. Una revisión de un PR con el archivo equivocado sigue siendo una revisión del archivo equivocado.
- Greptile después, siempre. Un borrador bien citado igual necesita una lectura del diff a escala del sistema entero.
- No le pidas a Maguyva que publique comentarios en PRs. No lo hace.
- No le pidas a Greptile que sea la primera capa de recuperación del agente mientras todavía está eligiendo una ruta. Ese no es el trabajo para el que está cableada su app de GitHub o GitLab.
- No inventes un pipeline de bash que los «sincronice». El PR es la interfaz.
- Verifica ambos lados de forma independiente. Indexa un repo que ya conoces. Haz una pregunta que puedas verificar. Luego abre un PR pequeño y lee lo que Greptile realmente comenta.

El bucle es ordinario una vez que se nombra. Primero el mapa. Luego el PR del agente. Luego la revisión. Cada producto se queda en el lado del pull request en el que es bueno.

`// map first. review second. in that order.`