A pull request review asks whether one change is safe to merge. A whole-repository review asks what is wrong with the codebase now.
Those jobs need different inputs, schedules and results. A tool that says it “understands the whole repository” may still review only pull-request changes. It uses other files as context, but it does not report every old problem it can find.
That difference is useful. Without it, every pull request would inherit years of unrelated findings.
What pull request review covers
A pull request review starts with a defined change. The reviewer knows which lines are new, which lines were removed and who plans to merge them.
The review can ask focused questions:
- Does this change break an existing caller?
- Does a new query enforce the same access rule as nearby queries?
- Does the new error path retry or fail as intended?
- Do the tests cover the changed behavior?
- Does a schema change remain compatible during deployment?
The result has a clear owner. The author can fix the code, explain the choice or dismiss the comment before merge.
Pull request review also has a natural time limit. Feedback must arrive while the change is active. A finding that appears two days after merge is an incident lead, not review feedback.
What whole-repository review covers
A whole-repository review scans the default branch or another fixed revision. It looks for problems that do not depend on a current pull request.
Useful jobs include:
- finding old authorization checks that differ across services
- locating deprecated API use
- finding error paths with no tests
- checking whether a new engineering rule is already violated
- mapping duplicate code before a migration
- finding public functions with no owner or documentation
- preparing a security or reliability audit
The result is usually a backlog, not a merge decision. Someone must group duplicate findings, rank risk and decide which code deserves a change.
Repository scans need tight scope. “Find every bug” produces weak results because the model has no definition of failure. “Find handlers that read workspace data without checking workspace membership” gives it a contract to test.
Repository context and repository review are different jobs
The terms are easy to mix up.
A repository-aware pull request reviewer can search the whole codebase for evidence. It still comments on risks created by the current change.
For example, a pull request changes this function:
export async function getInvoice(invoiceId: string) {
return db.invoice.findUnique({ where: { id: invoiceId } })
}The diff does not show whether invoices belong to workspaces. A repository-aware reviewer can inspect the model, callers and nearby queries. It may find that every other invoice query also filters by workspaceId.
That context supports a pull request finding. A separate repository scan would look for older access bugs in every invoice function.
The examples in why diff-only code review misses bugs show why this context matters.
Why a whole-repository scan is harder
The search space is large
A repository can contain application code, generated clients, fixtures, migrations, vendored files and old experiments. Sending all of it to one model call is expensive and often impossible.
Review systems usually index code, split it into units and retrieve parts for each question. The quality of that retrieval affects the answer as much as the model does.
Old code has less context
A pull request has a description, author and review thread. Old code may have none of those. The reviewer can see what the code does, but not why the team accepted a trade-off three years ago.
Findings have no automatic owner
A pull request comment goes to the author. A repository finding may point into a service with no active maintainer. Without an owner and deadline, the result becomes another ignored report.
Duplicate findings grow fast
One shared mistake can appear in fifty call sites. Posting fifty tickets hides the root cause. A repository scan should group related results and point to the shared rule or helper that needs repair.
When to use pull request review
Use pull request review for normal delivery work:
- every change needs a first pass
- feedback must reach the author quickly
- findings should refer to changed behavior
- the team wants to stop new defects before merge
- branch rules and CI already define a merge process
This should be the default for most teams. It gives the reviewer a narrow question and a clear place to return the answer.
The GitHub pull request review workflow explains how to combine it with CI and human approval.
When to use whole-repository review
Use a repository scan for a named audit or migration:
- a new security rule must be applied to old code
- the team plans to remove a deprecated library
- an incident exposed a repeated failure pattern
- a merger or compliance review needs an inventory
- a platform team wants to measure one rule across many services
Write the rule before the scan. Include examples of a violation and a safe case. Exclude generated and vendored paths. Limit the first run to one service or package.
A practical combined process
The two review types work well together.
- Run a focused repository scan for one known risk.
- Group and confirm the findings with service owners.
- Fix the existing violations in small pull requests.
- Turn the confirmed pattern into a review rule.
- Run that rule on future pull requests so the problem does not return.
Suppose an incident shows that webhook handlers acknowledge work before the database transaction commits. A repository scan can find the old handlers with the same order. After the team fixes them, a pull request rule can check new handlers for the pattern.
The repository scan pays down the old risk. Pull request review keeps it from growing again.
How to evaluate a whole-repository reviewer
Do not judge it by the length of the report. Start with ten confirmed problems that exist in the repository and ten similar files that are safe.
Measure:
- confirmed problems found
- safe files flagged
- duplicate findings
- evidence shown for each claim
- cost and scan time
- time needed to assign and check the results
Check whether the tool can limit a scan by path, language, owner and rule. Check whether it saves the exact revision it reviewed. A report becomes hard to verify after the default branch changes.
For pull request tools, use the same test on historical changes. The AI code review tools for GitHub comparison gives a small evaluation plan.
Scopy uses repository-wide context during pull request review. It follows changes into related code and verifies candidate findings before it posts them. Its current product focuses on pull requests rather than general repository audits. That scope keeps each comment tied to a change and an author.