When AI Reads Your Code: code-review-graph Builds a Persistent Map for Repositories

You ask Cursor to refactor a function. It spends 30 seconds scanning the whole repo. You ask it to refactor the function next door. Another 30-second scan. Same repo, same structural information, rebuilt from scratch every time.

This is not an intelligence problem. It is a missing map problem.

tirth8205/code-review-graph solves this by building a persistent structural map of your codebase, so AI tools only read the slice they actually need.

The Problem: Goldfish-Memory AI Coding Tools

Current AI coding assistants (Cursor, Claude Code, Copilot) share a hidden cost: every conversation rebuilds its understanding of the codebase from zero.

A typical flow looks like this: you ask "where is this function called?" and the tool either greps the whole repo (slow and noisy) or uses vector retrieval to find similar text snippets (often missing precise call relationships). Either way, every conversation re-scans, and every scan stuffs results into the context window.

On a 100,000-line repository, a single AI conversation may burn 50,000 tokens just to "understand context." It is like walking into your office every morning and re-learning where the door, desk, and meeting room are.

The root cause is a granularity mismatch: AI tools work at file-and-line granularity, but structural information lives at function, call-relationship, and module-dependency granularity. Using the wrong granularity to understand code is like using a microscope to read a map: the magnification is fine, but you will never see the whole road.

The code-review-graph Approach: Build the Map First, Ask for Directions Later

The project follows a three-step strategy.

Step 1: Structured parsing with Tree-sitter. Tree-sitter is GitHub's open-source incremental parser that turns source code into a syntax tree in milliseconds. Instead of relying on language-specific LSPs (Language Server Protocol), code-review-graph uses Tree-sitter as a single pipeline for Python, TypeScript, Rust, Go, and more.

Step 2: Store the parse result as a graph. Not a file tree, not a symbol table, but a relational graph: function A calls function B, class C inherits class D, module E depends on module F. The graph lives in SQLite, persisted locally. When an AI tool next asks "who calls this function?" it queries the graph instead of rescanning.

Step 3: Expose the graph to AI tools via MCP. MCP (Model Context Protocol) is Anthropic's standard for letting AI tools access external data sources uniformly. code-review-graph implements an MCP server, so any MCP-compatible AI tool (Claude Code, Cursor, etc.) can query the code graph directly.

Why a Map Is Faster Than a Search

Traditional AI tools are search-driven: you ask a question, they search for relevant files, and they push the results into context. Every search starts from zero.

code-review-graph is map-driven: it pre-builds a structural map of the code, so questions become graph queries instead of text searches.

| Dimension | Search-driven | Map-driven | |----------|---------------|-----------| | First query | Full repo scan | Graph lookup (ms) | | Subsequent queries | Re-scan | Graph lookup (ms) | | Context consumption | 50k+ tokens | A few hundred tokens | | Call relationships | Fuzzy grep match | Exact graph edge | | Incremental update | None | Only changed parts |

The headline data point: SQLite graph queries typically return in 1-5 ms, while a full-repo grep on a 100k-line codebase takes 200-500 ms. The 100x speedup does not come from a faster engine; it comes from a smarter granularity.

This Is Not RAG

A fair question: isn't this just RAG (Retrieval-Augmented Generation) for code?

No. RAG uses vector retrieval to find *semantically similar* snippets, but call relationships are not captured by semantic similarity. Function A may call Function B even when their names, code, and topics are completely unrelated. The call is an exact structural fact.

RAG rests on the assumption that "semantically similar ≈ relevant." That assumption collapses in rule-based worlds. Euclid-MCP experiments have shown that a 480B-parameter model performs no better than an 8B model on 1,000-rule factual reasoning. Code call graphs are a rule-based world: A calls B is a fact, not a probability.

code-review-graph does not do semantic retrieval; it does structural queries. It answers "who calls this function, who does it call, and which modules does it depend on," not "which files are related to my question." Exact facts, no probabilities.

"Local-First" Is Not Decoration

code-review-graph is explicitly local-first: every byte lives in a local SQLite file. This is not just a privacy choice; it is a performance choice.

Cloud solutions such as Sourcegraph impose 100-500 ms latency. Local SQLite queries run in 1-5 ms. For AI coding tools, an extra 100 ms per query adds up to minutes across a working day. Local-first is not a privacy-friendly marketing slogan; it is a 100x engineering choice.

Conceptual Lineage: From Brute-Force Search to Structural Maps

code-review-graph's insight fits a broader conceptual lineage:

• Octopus RNA editing: DNA is pretrained, RNA computes at inference time. Change the working drawing, not the blueprint.
• Slime mold externalized memory: memory externalized in slime trails, no neurons required.
• Bird quantum magnetoreception: amplifier and sensor are separated. Division of labor beats unification.
• Euclid-MCP reasoning outsourcing: let the LLM be the poet, let Prolog be the accountant.
• code-review-graph structural maps: externalize code structure as a persistent map; AI tools query, they do not scan.

All five examples point to the same principle: the breakthrough is not doing the same thing harder, it is solving the problem on a different layer. AI tools do not need stronger search; they need a pre-built map.

Who Should Use It

• Cursor / Claude Code users: if your codebase exceeds 10,000 lines, per-conversation context scanning is already a significant cost. code-review-graph can cut that by an order of magnitude.
• MCP ecosystem participants: code-review-graph is a reference MCP implementation for code intelligence and is worth studying for its interface design.
• Codebase maintainers: even without AI tooling, the structural graph helps you understand dependencies in large codebases.

Limitations

• Only supports languages that Tree-sitter can parse: niche languages may be unsupported.
• Graph quality is bounded by Tree-sitter syntax trees: higher-level semantic relationships (e.g., design patterns) cannot be captured.
• Incremental updates are early-stage: incremental performance on large monorepos is not yet thoroughly validated.

Closing

The next breakthrough in AI coding tools will not come from larger models; it will come from better context engineering. code-review-graph upgrades "understanding code" from "search it again every time" to "query a persistent map." That matches how human developers actually work: you do not relearn your office layout every morning, you carry an internalized map.

A map is 100x faster than search, not because the map's engine is stronger, but because the map never has to be redrawn.

---

• GitHub: https://github.com/tirth8205/code-review-graph
• Website: https://code-review-graph.com
• MCP protocol: https://modelcontextprotocol.io