26. April 2026

A Code Knowledge Graph for Review, Not Generation

The same graph that helps an agent write code can help a reviewer trust it. Almost nobody is using it that way.

Every AI coding tool I’ve looked at in the last eighteen months — including codemap now called symgraph— is built around the write side. Index the codebase, expose a semantic surface, hand the agent enough context to make a competent edit. The graph is plumbing for generation.

That’s the obvious application. It’s also the smaller half of the problem.

The harder, more valuable question is: given a diff, was this change safe? And the graph already knows.

There’s a reason the industry built the write-side first. It demos better. Watching an agent ship a feature is more legible than watching a reviewer not break production. Generation has a clear before/after. Review has counterfactuals.

Token economics nudged the same way. Generation pipelines justify their cost per call — a closed PR is a unit of output. Review pipelines have to argue for themselves on incidents that didn’t happen.

So the tooling stack got built read-to-write: parse the codebase, extract symbols, hand them to a model, generate a patch. Review got the leftovers — usually a second model pass over the same patch, with the same context the author had, hoping it spots what the author missed.

That’s not review. That’s a second draft.

Generation context answers: what is near this symbol?

Review context answers something different:

  • What invariants does this change cross?
  • What callers depend on the contract this PR just modified?
  • What tests should have caught a regression here, and did any of them change?
  • What trust boundaries moved?
  • What ownership does this code carry that the patch author may not have?

These are relational queries. They don’t live in the patch. They live in the graph around the patch.

A code knowledge graph — the kind symgraph builds — already encodes the edges review needs:

  • Call edges — who depends on the symbol that changed.
  • Type relationships — what shape contracts the change perturbs.
  • Module / ownership boundaries — what the change crosses.
  • Test → code coverage edges — which tests claim this surface.
  • Churn and recency — how stable the touched code has been.
  • Definition vs. reference asymmetry — symbols defined here but used everywhere else.

Review isn’t a different graph. It’s a different traversal.

Concrete things a review-mode knowledge graph surfaces that a patch-only review can’t:

  1. Public surface drift. Did this PR change the signature of a symbol with external callers, and were all of them updated?
  2. Coverage gap. Did the change touch code reachable only through tests that were deleted or skipped in the same PR?
  3. Cycle introduction. Did the new edges create a module-level cycle that wasn’t there before?
  4. Trust boundary widening. Did a function that previously only handled trusted input gain a path from a network or user-input source?
  5. Hot-but-thin areas. Did the change land in code with high churn and low test density — the codebase’s known soft spots?

None of these require the model to understand the change. They require the graph to describe the change in terms the model can reason about.

Drop a 400-line diff into a model and ask “is this safe?” and you get a confident, plausible answer that misses everything outside the diff window. The model reads patches linearly. It doesn’t know that the function being modified is called from twelve places, three of which assume an invariant the patch just relaxed.

The graph is what turns “review this patch” into “review this patch in the context of the seventeen edges it touches.”

This is the same insight that made symgraph useful for generation — agents are smarter when they’re given relational context instead of raw text. It applies just as cleanly the other direction.

Several plausible insertion points, in order of latency tolerance:

  • Pre-commit — fastest signal, narrowest scope. Cycle checks, trust-boundary checks, surface drift.
  • PR-time annotation — a comment on the PR that lists the graph-derived facts about the change before any reviewer reads it.
  • Reviewer IDE overlay — show the caller graph for every modified symbol inline.
  • Ultrareview-style pass — the agent gets the diff and the graph traversal, asked to reason about the relational facts rather than the textual ones.

The same graph powers all four. The difference is just where the query runs.

I want to take symgraph’s existing graph and bolt a review mode onto it — a CLI that takes a diff and emits the relational facts a reviewer (human or agent) would actually use. Not “here’s what changed,” but “here’s what changed and what it touches.”

If that lands well, the more interesting follow-up is feeding those facts back into the agent loop — closing the gap between the agent that wrote the code and the agent that reviews it, with a shared graph as the common substrate.

The write-side of agentic coding got a five-year head start. The read-side is wide open.