AI Code Review Context: Why Diff-Only Reviewers Miss Real Bugs

The bug that was invisible in the diff

Here is a pull request any reviewer would approve: it renames a config field, updates the three call sites the IDE found, adjusts the tests, everything green. The bug is not in the diff. It is in a service two directories away that reads the same field by string key from a parsed YAML file — a call site no rename tool sees. The diff is flawless; the change is broken.

Every experienced engineer has shipped a version of this bug, and it illustrates the structural weakness of most AI code review: the unit of review is the diff, but the unit of correctness is the system. A reviewer that sees only the patch can judge style, spot local logic errors, and catch obvious security smells. What it cannot do is tell you that the code you changed disagrees with the code you did not.

What “context” actually means

Context in code review is not one thing. It is a stack of widening circles, and each circle catches a class of bug the previous one cannot:

• The diff. Enough for syntax-level and single-function issues: off-by-one errors, inverted conditions, obvious injection patterns, a leaked secret.
• The full files being changed. Reveals how the changed function is used elsewhere in the same file, which invariants the surrounding code assumes, and whether the new branch contradicts one of them.
• The repository. Call sites, shared types, sibling implementations of the same interface, existing utilities the PR just reimplemented, and the conventions the team actually follows rather than the ones in the style guide.
• The organization. Other services that consume this API, the contract the mobile app depends on, the migration policy, the incident from last quarter that explains why this timeout is deliberately conservative.

Most of the complaints teams have about AI reviewers — wrong comments, guessed assumptions, confident nonsense about code that exists three files away — are context failures, not intelligence failures. We covered the noise half of this in our post on false positives; this post is about the misses.

The failure modes of diff-only review

Broken callers. A changed function signature, a narrowed return type, a new thrown error: the diff shows the change, the damage lives at the call sites. Without repository context the reviewer cannot enumerate them, so it either stays silent or guesses.

Violated invariants. Code frequently depends on facts that are enforced elsewhere — “this list is always sorted”, “this value is validated at the boundary”. A patch can silently break the enforcement while every line of the patch looks correct.

Reinvented wheels. The fifty-line helper in the PR already exists in lib/utils, with better edge-case handling. Diff-only reviewers approve the duplicate because they have never seen the original. The codebase grows a second, subtly different truth.

Convention drift. Every team has patterns that are policy in practice: how errors are wrapped, how feature flags are checked, which logger is used where. None of it is visible in a patch, so a reviewer without project context reviews against generic best practice instead of your practice.

How review tools add context — and what it costs

The industry has converged on a few mechanisms. Retrieval and code search pull related files into the review prompt on demand. Full-repository indexing builds an embedding or symbol map ahead of time so the reviewer can look up call sites and definitions. Project instructions let teams write their conventions down once and inject them into every review. Agentic reviewers go furthest: they navigate the repository during the review, opening files the way a human reviewer follows a hunch.

All of it helps, and all of it costs. More context means more tokens per review, slower reviews, and — for indexing approaches — a copy of your codebase living in someone else's infrastructure, which is exactly the concern that pushes teams toward self-hosted deployment in the first place. Context is not free; it is a budget you spend.

Spending the context budget where it pays

That framing suggests the practical answer. Not every pull request deserves the same depth: a lockfile bump needs no repository traversal, while a change to the auth module justifies the most capable model you have, primed with every relevant file. Treating review depth as a routing decision — rather than a global setting — is how teams keep quality where it matters without paying deep-review prices on every dependabot PR.

This is the philosophy PURA is built around: pull requests are routed to the right model with the right budget based on rules you control — by repository, by team, by author, by the kind of change. High-risk paths get depth; mechanical changes get speed. Project instructions carry your conventions into every review, and because PURA is self-hosted with your own keys, the context you feed the reviewer never leaves your infrastructure. Our rollout playbook covers how teams introduce this incrementally.

What to ask of any reviewer you evaluate

• Can it see beyond the patch — full files, call sites, related modules?
• Can you feed it your conventions once, instead of correcting it forever?
• Where does the context live, and does that satisfy your security team?
• Can you vary review depth by risk, or is every PR reviewed identically?
• When it comments on code outside the diff, does it cite what it saw — or is it guessing?

The diff is where review happens, but it was never where correctness lives. The reviewers worth keeping — human or machine — are the ones that read the code around the change before judging the change. Demand the same from the AI you put on your pull requests.