PageRank in code review context

PageRank, the algorithm Larry Page and Sergey Brin published in 1998, treats the web as a directed graph where pages are nodes and hyperlinks are edges. The score for each page reflects how many high-ranked pages link to it, computed via iterated matrix multiplication until the values stabilize.

The result: a global importance ordering. Pages cited by many other important pages rank highest. The genius of PageRank wasn't the math (Markov chains were old); it was applying it to web-link structure to get a robust importance signal.

Personalized PageRank is a variant where the 'restart probability' biases toward a specific subset of nodes. Instead of asking 'what's globally important?', it asks 'what's important relative to THIS starting set?'

A codebase is naturally graph-shaped. Functions call other functions. Files import other files. Classes extend classes. Types reference types. Modules depend on modules. Every one of these relationships is a directed edge from a 'caller' (depends on) to a 'callee' (depended on).

Tools like tree-sitter let you extract these edges deterministically. The result is a symbol graph: 10k-100k nodes for a mid-sized repo, hundreds of thousands of edges. Plain graph data structures — exactly the substrate PageRank operates on.

When a PR touches a function called `validateUser()`, you want a code reviewer (AI or human) to also see the things `validateUser()` itself calls, the types it accepts, the conventions used by similar functions in the repo. That's the 'context' that turns a generic review into a repo-aware review.

Set the seed weight on the PR's changed symbols. Run personalized PageRank with a damping factor around 0.85 (standard) and a few iterations. The top-ranked 5-15 symbols are the ones structurally most relevant to the change — they get pulled into the LLM prompt at review time.

Crucially, this works without semantic understanding. PageRank doesn't care what the code MEANS. It cares about how it's connected. The result is fast (linear-ish in graph size), deterministic, and gives the same answer for the same code structure every time.

The 'standard' way to do context retrieval for AI is vector embeddings: chunk the code, embed each chunk, store in a vector database, retrieve top-k cosine-similar chunks at query time. Works well for documentation and FAQs.

It works less well for code for four reasons:

(1) Structural relationships are invisible to embeddings — two functions can be 'far apart' in embedding space but one literally calls the other.

(2) Chunking destroys context — a 200-line function split across chunks, the retrieved chunk might be the middle of a function, useless.

(3) Repo-specific vocabulary doesn't embed — internal helper names, project jargon — embeddings trained on general code don't 'understand' these.

(4) Re-embedding on every push is expensive: either you pay per-token continuously, or you let the index go stale.

PageRank fixes all four. It operates on the graph (1). Whole symbols are nodes, no chunking (2). Repo structure is intrinsic to the graph, not learned (3). Incremental updates are linear in changed edges (4).

LGTM's context indexer extracts the symbol graph via tree-sitter, then runs personalized PageRank with the PR's changed symbols as seeds at every review time. Damping is 0.85 with 30-50 iterations to convergence.

The top-ranked 5-15 symbols beyond the diff get their function bodies fetched (from GitHub, not from our DB) and attached to the relevant agent's prompt. The agent reasons about the change with access to the structurally-most-relevant context, not random embedding neighbors.

Cost: zero per-review. PageRank runs on our worker, not on tokens. The same graph that took 50 seconds to build at index time can be re-ranked in well under a second per review.