Why we don't index your whole codebase

There is a genuine architectural fork in AI code review, and most marketing pages obscure which side a product is on.

One approach indexes your whole repository — a persistent graph of files, functions and dependencies, kept in sync as the code changes. The other builds context per review from the diff and the code it touches. Pullora does the second.

What indexing buys

Cross-file reasoning. If a pull request changes a function signature and three call sites elsewhere in the repository now break, a repository graph can see that. Per-review context often cannot, unless those call sites happen to be in files the diff touches.

That is a real capability and a real gap in our approach. We would rather name it than let you discover it.

What it costs

A persistent index means holding a derived copy of your codebase, keeping it fresh, and re-indexing on every push. That is meaningful infrastructure, meaningful cost, and a larger surface area for your source code to sit on someone else's servers.

Per-review context has none of those properties. We store findings and metadata, not copies of your repositories. Nothing needs to be re-indexed when you push, and there is no stale index to reason about.

Who each one suits

If you work in a large monorepo where a typical change ripples across modules, a repository graph will catch things we miss, and that is worth paying for.

If your pull requests are mostly self-contained — a feature in a few files, a bug fix, a refactor within a module — per-review context finds the same problems at a fraction of the cost, which is why our pricing looks the way it does.

Where this goes

Deep mode already reads related unchanged files as context, which narrows the gap on the cases where the relationship is discoverable from the diff. It is not the same as a graph and we do not claim it is.