code-review-graph: Tu Agente Revisa Solo los 15 Archivos que Importan, no los 27.000
Tu asistente de IA es un gran reviewer con una memoria pésima. Le pedís que revise un pull request y hace lo único que sabe hacer: empezar a leer. Lee el archivo que cambiaste, después el que lo importa, después algunos más que cree que pueden estar relacionados, quemando tokens todo el camino — y aun así puede pasar por alto al caller que está tres saltos más allá y que tu cambio rompe en silencio.
code-review-graph da vuelta esa lógica. En lugar de dejar que el agente tantee tu repo archivo por archivo, le pone un mapa en la mano y le dice: estas son las funciones exactas que tu cambio puede romper, y nada más. En un monorepo de Next.js de más de 27.700 archivos, ese mapa reduce el review a unos 15 archivos. Esa es toda la idea, y le valió 24.3k stars en GitHub.
El problema no es el modelo, es el contexto
Todos vimos a un agente “leer el codebase” para revisar un diff de dos líneas. No es que sea tonto — simplemente no tiene un modelo persistente de tu proyecto. Cada tarea arranca de cero, así que vuelve a deducir la estructura que ya había resuelto ayer, y esa rededucción la pagás en tokens y en latencia. RAG ayuda un poco, pero la similitud semántica no es lo mismo que “esta función llama a aquella”. Un vector search te va a devolver contento el código que se lee parecido y va a pasar por alto el código que en realidad está conectado.
Lo que un reviewer necesita de verdad es el call graph: quién llama a esto, quién depende de esto, qué tests lo cubren. Es una pregunta estructural, no de similitud — y es exactamente lo que code-review-graph precalcula.
Cómo funciona
Tres piezas en movimiento, todas locales:
Parsing. Tree-sitter recorre tu código fuente y extrae funciones, clases, imports y relaciones de llamada en 24 lenguajes más notebooks de Jupyter/Databricks — Python, TypeScript, Go, Rust, Java, Kotlin, Swift, y una cola larga que baja hasta Zig, Julia y Nix.
El grafo. Las funciones se vuelven nodos, las llamadas se vuelven edges, y todo aterriza en un archivo SQLite plano bajo .code-review-graph/. Sin servidor, sin nube, nada sale de tu máquina. Cuando un archivo cambia, la herramienta traza hacia afuera a través de ese grafo — cada caller, cada dependiente, cada test afectado — y calcula el blast radius del cambio.
MCP. Expone 28 tools sobre el Model Context Protocol, así Claude Code, Cursor, Windsurf, Copilot y compañía pueden hacer preguntas puntuales — “dame el contexto mínimo para este diff” — en vez de leer a ciegas. El grafo se actualiza de forma incremental en cada commit o save, reparseando solo lo que cambió. Un proyecto de ~2.900 archivos se refresca en menos de dos segundos.
Los números, con honestidad
En seis repos open source reales (express, fastapi, flask, gin, httpx, nextjs), el autor midió una reducción promedio de tokens de 8.2×, que va desde un modesto 0.7× en cambios chicos de un solo archivo hasta 49× en el monorepo de Next.js. Así que no es magia en cada tarea — en un retoque de un archivo dentro de un package chico, el overhead de metadata del grafo te puede costar más que simplemente leer el archivo. El payoff aparece en los cambios multi-archivo y en los repos grandes, que es justo donde hoy duelen los reviews.
La parte que más respeto es cómo está calibrado el análisis de impacto. Reporta 100% de recall con un F1 de 0.54 y una precisión cercana a 0.38 — y esos números no son poco favorables por casualidad. La herramienta deliberadamente sobre-predice qué afecta un cambio. Prefiere pasarte unos archivos de más antes que perderse la única dependencia que se rompe en producción. Para una herramienta de review, ese es el sesgo correcto: una falsa alarma te cuesta una mirada, un impacto no detectado te cuesta un incidente.
Ponerlo a andar
pip install code-review-graph
code-review-graph install # autodetecta Claude Code, Cursor, Windsurf, Copilot, etc.
code-review-graph build # indexa tu repo
De ahí en adelante tenés reviews con score de riesgo que mapean un diff a las funciones que toca y a los gaps de tests que expone, una visualización interactiva en D3 del grafo, un daemon multi-repo que vigila varios proyectos a la vez, y exports a GraphML, Neo4j o un vault de Obsidian si querés meter mano vos mismo en la estructura. Licencia MIT, Python 3.10+, actualmente en v2.3.3.
Por qué esta, de todo el montón
Los knowledge graphs para agentes son una góndola llena hoy, y muchas de esas herramientas se quedan en “ayudar al agente a entender tu repo”. code-review-graph apunta a algo más acotado y más útil en el día a día: saber qué rompe tu cambio antes de que el agente diga una sola palabra al respecto. Blast radius en cada commit es una promesa distinta a la de contexto general, y es la que encaja limpio con cómo trabajamos de verdad — diffs chicos contra codebases grandes, donde el riesgo nunca es la línea que cambiaste sino aquello que te olvidaste que tocaba.
¿Vos ya sumaste un knowledge graph a tu flujo de review, o seguís dejando que el agente lea el repo entero en cada PR? Contanos con qué codebase lo probarías.