code-review-graph: Your Agent Reviews Only the 15 Files That Matter, Not 27,000
Your AI assistant is a great reviewer with terrible memory. You ask it to review a pull request and it does the only thing it knows how to do: start reading. It reads the file you changed, then the one that imports it, then a few more it thinks might be related, burning tokens all the way — and it can still miss the caller three jumps further out that your change silently breaks.
code-review-graph flips that logic on its head. Instead of letting the agent fumble through your repo file by file, it puts a map in its hand and says: these are the exact functions your change could break, and nothing else. In a Next.js monorepo with over 27,700 files, that map shrinks the review down to about 15 files. That’s the whole idea, and it’s worth 24.3k stars on GitHub.
The problem isn’t the model, it’s the context
We’ve all watched an agent “read the codebase” to review a two-line diff. It’s not that it’s dumb — it just doesn’t have a persistent model of your project. Every task starts from zero, so it re-derives the structure it already figured out yesterday, and you pay for that re-derivation in tokens and latency. RAG helps a bit, but semantic similarity isn’t the same as “this function calls that one.” A vector search will happily hand you back code that reads similar and sail right past the code that’s actually connected.
What a reviewer really needs is the call graph: who calls this, who depends on this, what tests cover it. It’s a structural question, not a similarity one — and that’s exactly what code-review-graph precomputes.
How it works
Three pieces in motion, all local:
Parsing. Tree-sitter walks your source code and pulls out functions, classes, imports, and call relationships in 24 languages plus Jupyter/Databricks notebooks — Python, TypeScript, Go, Rust, Java, Kotlin, Swift, and a long tail down to Zig, Julia, and Nix.
The graph. Functions become nodes, calls become edges, and everything lands in a flat SQLite file under .code-review-graph/. No server, no cloud, nothing leaves your machine. When a file changes, the tool traces outward through that graph — every caller, every dependent, every affected test — and calculates the blast radius of your change.
MCP. Exposes 28 tools over the Model Context Protocol, so Claude Code, Cursor, Windsurf, Copilot, and friends can ask pointed questions — “give me the minimum context for this diff” — instead of reading blind. The graph updates incrementally on every commit or save, re-parsing only what changed. A project with ~2,900 files refreshes in under two seconds.
The numbers, honestly
Across six real open source repos (express, fastapi, flask, gin, httpx, nextjs), the author measured an average token reduction of 8.2×, ranging from a modest 0.7× on small single-file changes to 49× in the Next.js monorepo. So it’s not magic on every task — on a tweak to one file in a small package, the overhead of graph metadata can cost you more than just reading the file. The payoff shows up on multi-file changes and in large repos, which is exactly where reviews hurt today.
What I respect most is how the impact analysis is calibrated. It reports 100% recall with an F1 of 0.54 and precision near 0.38 — and those numbers aren’t accidentally unfavorable. The tool deliberately over-predicts what a change affects. It’d rather give you a few extra files than miss the one dependency that breaks in production. For a review tool, that’s the right bias: a false alarm costs you a look, a missed impact costs you an incident.
Getting it running
pip install code-review-graph
code-review-graph install # auto-detects Claude Code, Cursor, Windsurf, Copilot, etc.
code-review-graph build # indexes your repo
From there you get reviews with risk scores that map a diff to the functions it touches and the test gaps it exposes, an interactive D3 visualization of the graph, a multi-repo daemon that watches several projects at once, and exports to GraphML, Neo4j, or an Obsidian vault if you want to dig into the structure yourself. MIT licensed, Python 3.10+, currently at v2.3.3.
Why this one, out of the bunch
Knowledge graphs for agents are a crowded shelf these days, and plenty of those tools stop at “helping the agent understand your repo.” code-review-graph aims at something narrower and more useful in the day-to-day: knowing what your change breaks before the agent says a single word about it. Blast radius on every commit is a different promise than general context, and it fits clean with how we actually work — small diffs against huge codebases, where the risk is never the line you changed but the thing you forgot it touched.
Have you already wired a knowledge graph into your review flow, or do you still let the agent read the whole repo on every PR? Tell us what codebase you’d test it on.