Diff-scoped code review cannot evaluate what depends on the changed lines because its input stops at the diff, while repo-aware review can, because it queries indexed call graphs and cross-file relationships.
TL;DR
The diff-scoped vs repo-aware code review question turns on what the reviewer reads, because its input determines which defect classes it can reach. A change can be correct on every line it touches and still break a service in another repository, because the caller was never in front of the reviewer.
A pull request (PR) renames the customer_ref field to customer_id in a billing service's response, updates every reference inside that repository, and passes its unit tests. An automated reviewer finds nothing wrong with the changed lines and approves it. Two hours after merge, the invoicing service in a second repository starts writing null customer records because it still deserializes customer_ref. Every changed line was correct, and the defect lived in a caller that never entered the reviewer's input.
Platform owners and engineering leaders running multi-repo or multi-service estates meet this pattern whenever review scope ends at the patch boundary. A producer service has consumers in separate repositories, and a merge ships hours before anyone reads the consumer that depends on it. This guide explains what a diff-scoped reviewer receives, why that input cannot contain a caller in another service, what a repo-aware reviewer reaches through a context engine, and when each scope is correct. Despite the vs in the title, the two things compared here are review scopes, and no product is named as a winner.
How Diff-Scoped vs Repo-Aware Code Review Differs
What a reviewer receives bounds what it can conclude.
- Diff-scoped input: The reviewer receives the raw git diff with changed hunks and their few lines of surrounding context, plus the pull request title and description.
- Repo-aware input: The reviewer receives those same inputs plus an index of symbols. It can query call graphs that encode cross-file relationships during the review.
In the SWE-PRBench preprint, the diff-only configuration is that list plus a short generated summary of the changes, all inside a 2,000-token budget. Review scope is therefore a property of the reviewer's input, and model quality cannot restore what the input omits.
Why a Clean Review Still Breaks a Downstream Caller
A clean review breaks a downstream caller when the change is internally valid at the changed lines and the code that depends on those lines sits outside the reviewer's input. A renamed or removed field updates cleanly inside the producer's repository while a service in another repository keeps deserializing the old name. A return type narrowed from a list to a single object compiles in the producer while a caller that unpacks the first element fails. A client timeout dropped from 30 seconds to 5 leaves a second service that sized its retry budget around the old value timing out under yesterday's load. An error path that returns a 400 in place of a 503 stops a retry policy keyed on 5xx codes from retrying. A migration that drops a column ahead of the code reading it fails between the schema step and the application step.
The migration case has run at scale. On August 5, 2025, a GitHub migration dropped a column from the pull request table while the object-relational mapper (ORM) still referenced it. GitHub's availability report puts peak impact at about 4% of all web and REST API traffic, and the same failure recurred three weeks later against the Copilot table.
Producer-side regression testing does not close the gap either. Across 381 popular packages, one npm ecosystem study found that regression testing cannot detect 19% of the breaking changes maintainers had already documented.
The Defects Diff-Scoped Review Structurally Cannot See
Diff-scoped review cannot see any defect whose evidence lives in code the patch did not touch. In an ICSE 2024 study of C and C++ open-source projects, 24.3% of vulnerabilities were interprocedural. They spanned an average of 2.8 call layers between where the bug triggers and where it eventually gets patched.
The five below differ in where that evidence sits.
- Cross-service dependency breaks: A renamed field or narrowed type is valid in the producer and invalid in a consumer that lives in another repository.
- Shared authorization and middleware changes: A permission check edited in one middleware file is correct for the route in the diff and wrong for the other routes that import it.
- Global invariants: Where a convention such as every write passing through an audit logger holds across files, a new write path in the diff can violate it without any changed line looking wrong.
- Architectural drift: A change reintroduces a pattern the codebase retired, where the only record of that retirement sits in code the diff never touches.
- Duplicate abstractions: A new helper duplicates one that already exists three directories away, and the duplicate reads as clean code in isolation.
Recall and precision describe the two failure directions. Recall is the share of real defects a reviewer reports, and precision is the share of its reports that are real defects. A reviewer whose input excludes the caller has a recall ceiling on every category above that no threshold, prompt, or model swap raises. Tuning moves precision; only widening the input moves that ceiling, which is why the case for recall-first review begins with what the reviewer reads. On diff-only input, SWE-PRBench's eight frontier models found between 15% and 31% of the issues human reviewers had flagged. Widening the context made every one of them worse. That held even when the extra code arrived as resolved call and import structure.
The Granularity Spectrum From Hunk to Repository
Any reviewer sits somewhere on a scale from a single hunk to every indexed repository, and what it can read fixes its position. The rows below name what each level reads and what that buys.
| Scope Level | What the Reviewer Reads | Defect Classes It Can Reach | Operational Requirement | Cost and Latency Per Review |
|---|---|---|---|---|
| Hunk | Changed lines plus a few context lines; PR title and description | Syntax, local logic, style, secrets in the patch | No repository index | Lowest; fits an inline gate on every push |
| File | Every changed file in full, plus the diff | Adds intra-file misuse: wrong argument order, unhandled same-file branch | No repository index | Rises with changed-file size; still inline |
| Single repository | Diff plus retrieved symbols, callers, tests, and definitions from the same repository | Adds intra-repository callers, shared middleware, repository conventions, duplicate abstractions | Requires repository retrieval | Retrieval cost per review, plus index upkeep |
| Multi-repository | Diff plus call graphs and dependency relationships across every indexed repository | Adds cross-service contract breaks, downstream default and error-path dependencies, migration ordering | Requires cross-repository retrieval and a current index | Highest; index staleness becomes a correctness risk |
Teams can configure most tools to operate on more than one row, and an index that has fallen behind moves a tool down the scale without changing a setting.
Why Reviewers Retrieve Instead of Reading Everything
Reviewers retrieve a slice of the repository because no model call can ingest a multi-service estate on every pull request, which makes scope an engineering choice under a budget. Retrieval strategies widen scope inside that budget by following the code's own structure, a far cheaper move than reading more of the repository. Cosmos, Augment Code's unified cloud agents platform, is available on all paid plans, and its review Experts run against an indexed repository rather than against a patch, so a caller in another indexed repository falls inside the reviewer's input.
No single retrieval mechanism is enough on its own, so production systems stack several.
- Code-graph traversal: The reviewer follows call and dependency edges outward from the changed symbols. In one preprint, a graph-based repository memory needed about a tenth of the tokens an exploring agent used, and answered at 83% quality against the agent's 92%.
- Diff-sensitive indexing: The index hashes files and reprocesses only what changed since the last commit.
- Syntax-aware chunking: In a chunking paper accepted to EMNLP 2025 Findings, splitting code along abstract syntax tree (AST) boundaries rather than at fixed line counts raised Recall@5 by 4.3 points on RepoEval.
- Pruning and ranking: The reviewer drops retrieved code that scores low against the changed symbols before the model call.
Widening the context helps only if the reviewer can still find things inside it. In AACR-Bench, a preprint whose issue set is mostly AI-generated and expert-verified, non-agent retrieval lost recall as the required context moved from diff to file to repository. Agent frameworks that retrieved on demand held their recall across all three levels, starting well below where non-agent methods started at diff level.
When Diff-Scoped Review Is the Right Choice
Diff-scoped review is the right choice when a change's dependencies live inside the patch and the team needs a verdict inside the pull request's own latency budget. A diff-scoped finding names a changed line, so the author can act on it inside the pull request. Google's AutoCommenter filters comments on unchanged lines because developers typically do not act on unchanged code. That filter cut the share of changed files flagged from 6% to 1.3%, before the team accepted more comments to regain coverage. A diff-scoped reviewer needs no indexing infrastructure, and it pays for that by never seeing code outside the patch.
Repo-aware review has costs of its own. On Anthropic's own testing, one review with its multi-agent review tool takes around 20 minutes and costs $15 to $25, both scaling with pull request size. A Cosmos Expert reviewing against an index only earns that cost where the index is worth maintaining, and a single-service codebase with no external consumers does not need one. An index also goes stale. Meta calls its own Glean index perpetually out of date, perhaps by many hours, and in C++ a modified header forces reprocessing of every source file that depends on it.
A current index is no guarantee the right file comes back. In an agent retrieval preprint, logged agents never opened a single gold file on 27% to 35% of the retrieval samples. A repo-aware finding can point at a caller that requires a change in another repository, outside the author's open PR.
Contributors optimize for pull request latency, while platform teams and executives weigh cross-service incident exposure against review cost.
- Individual contributor: Diff-scoped review suffices for a change confined to one repository.
- Platform or DevOps team: Diff-scoped review is the inline gate, with a repo-aware pass on changes to shared contracts, migrations, defaults, and error paths.
- Engineering manager: Diff-scoped review clears routine PRs from the senior-engineer queue.
- Executive buyer: A multi-service estate weighs the per-review bill against the incident cost of a missed cross-service break.
The four are looking at one tradeoff on four time horizons, which is why a single estate-wide verdict rarely fits all of them.
What a Reviewer Needs to Read to Catch Cross-Service Breaks
A reviewer catches a cross-service break when its input includes the call graph around the changed symbols, the interfaces of the services that consume them, the shared contracts such as schemas and protocol definitions, and the cross-repository relationships that connect a producer to its consumers. Without that last input, a reviewer can see that a symbol changed and still not see who was holding it.
Cosmos assigns that work to Experts, each configured for one job. Deep Reviewer reads the diff, checks changed files against repository guidance, and posts inline findings for objective issues, with no chat loop to drive it. Risk Analyzer runs when a pull request opens or is marked ready, auto-approves what it judges low-risk, and sends the rest to a human with a note naming what needs attention, such as architecture, security, rollout, tests, or product behavior. That triage is the scope decision, taken once per change while the cost of the wider pass is still avoidable.
Every Cosmos Expert runs against an indexed repository, and the index is the Context Engine, which maps call graphs and dependency relationships across hundreds of thousands of files. Augment Code Review uses the same map from inside a pull request. Reading the complete diff plus the entire repository lets it raise breaking changes, API compatibility, and integration issues that the patch alone gives no evidence for. Where a repository already carries AGENTS.md or CLAUDE.md, it discovers and applies them as review guidelines, so the conventions a reviewer checks against live beside the code they govern.
Match scope to the risk of the change. Gate cosmetic and single-repository edits with diff-scoped review and let them merge on its verdict. Route changes that rename a field, narrow a type, alter a default, change an error path, or ship a migration to a repo-aware pass, whether that is a Cosmos Expert or a review running against the same index. Before you trust a repo-aware verdict, confirm the index reflects the current main branch of every repository the change can reach; an index that missed last night's merges reviews against an older state of the codebase.
- Treating scope as a model-quality problem: Widen the input first, then judge the model.
- Trusting a stale index: Check the index timestamp against the latest merge before you act on a cross-repository finding.
- Ignoring findings outside the open PR: File a finding about a consumer elsewhere as an issue on that repository, and link it from the PR.
- Running the wider pass on trivial edits: Paying repository retrieval on a copy change buys nothing the diff-scoped gate did not already catch.
The wider pass pays off in recall on cross-service defect categories. A recall-versus-precision comparison reports the two separately for each tool, because one composite score hides which of them moved.
What to Do Next
The tradeoff is the speed of a diff-scoped gate against the cross-service coverage of a repo-aware pass, and neither wins across an estate, because the two scopes reach different defect classes. Pull the last ten production incidents that trace to a merged change and classify each by where the breaking dependency lived: inside the diff, elsewhere in the same repository, in another service, or in a shared contract repository. If most sit inside the diff, keep the diff-scoped gate and stop paying for repository passes on those PRs. If several sit in another service, define the change shapes that produced them, such as field renames and migrations, and route only those shapes to a repo-aware pass with a current index.
Frequently Asked Questions
Related Reading
Written by
Molisha Shah
Molisha is an early GTM and Customer Champion at Augment Code, where she focuses on helping developers understand and adopt modern AI coding practices. She writes about clean code principles, agentic development environments, and how teams are restructuring their workflows around AI agents. She holds a degree in Business and Cognitive Science from UC Berkeley.