When review time plateaus, nobody is reading
Salesforce's engineering blog published something in January that deserves more attention than it got. A team there tracked what happened to code review after AI-assisted coding took hold. Code volume rose roughly 30%. Pull requests regularly crossed 20 files and 1,000 lines of change. Review latency climbed quarter over quarter. Their account, Scaling Code Reviews: Adapting to a Surge in AI-Generated Code, is the clearest measured description I have read of what actually breaks when agents start writing a large share of the diff.
Then came the number that matters. For the largest pull requests, review time stopped climbing and started falling. That slowdown was not efficiency. The reviewers had stopped meaningfully engaging with the changes.
That single detail is the real story of AI code volume. The problem was never that there was too much code to read. It was that the way teams were reading it stopped working, and the metric they were watching told them the opposite of what was happening.
The file-by-file model breaks in predictable ways
Most review workflows assume a reviewer can reconstruct what a change means by scanning a diff. That assumption holds when changes are small and incremental. Under AI-generated load, the Salesforce authors describe, it breaks in four ways.
First, AI pull requests lose conceptual coherence. A single change may span backend logic, configuration, tests, and a user-facing component in one diff. The narrative structure that a human author would preserve is gone. A reviewer trying to understand a refactor of authentication finds it mixed with an unrelated config update and a new API, and has to infer purpose from disconnected fragments.
Second, cognitive load grows faster than file count. Reviewers spend more time navigating files than reasoning about behavior. Context switching replaces analysis, and review goes mechanical. A reviewer who is mostly tabbing between diffs is not evaluating anything; they are just keeping the review green.
Third, the incentives invert. When the effort a thorough review would require exceeds the value a reviewer sees in it, they default to surface validation or approval. That is a systems failure, not a failure of the individual reviewer. The workflow stops upholding its own design guarantee. Approving a large risky change partway through is how vulnerabilities and architectural regressions slip past, not because anyone was careless but because the process no longer supported the reasoning.
Fourth, there is no proactive risk filter. In a manual-only model the reviewer is the only thing standing between a trivial typo and a bad architectural decision. Without tooling to surface likely problem areas first, the human is unaugmented exactly when the volume is highest.
Reconstructing intent instead of reviewing diffs
Salesforce's response was an internal system called Prizm. Its core move is worth reading even if you never touch their stack: it stopped reviewing diffs as flat text and started reconstructing what the developer was trying to accomplish.
The implementation is described in the post. The system uses token-aware chunking so structural boundaries like files, functions, and modules stay intact during analysis. It builds higher-order abstractions progressively, grouping related changes by dependency, file overlap, and conceptual similarity. Backend logic and its corresponding UI update get reviewed together even though they sit in different files. Context is pulled from work items, previous pull requests, historical defects, and codebase patterns, then surfaced with progressive disclosure so reviewers only see what is relevant to the change in front of them.
The result is that reviewers get the second set of eyes that a 1,000-line diff cannot provide on its own. Related fragments are merged, so the changed areas line up with intent. That rearchitecture matters more than any single review tool, because it addresses the mechanism of the failure rather than adding more opinions to the queue.
What engineering teams are doing about scale now
Salesforce is one measured account of a team rearchitecting review. The pattern across the current vendor landscape and the engineering writeups is consistent. You keep the human as the decision maker, you change what the human is shown, and you add a layer in front of the reviewer that does the mechanical triage. That is the difference between a review tool that adds another opinion to the pile and one that changes what the reviewer actually has to read.
The two mainstream approaches on GitHub show the split. One is manual and per-PR: as GitHub's docs on using Copilot code review describe, you request a review from Copilot the way you would a human, it labels comments High, Medium, or Low, and by default it leaves a comment rather than an approval. The other is embedded triage: a tool that merges related changes and decides what a human should look at before the human opens the first file.
The vendor listicles on this exact question are a useful baseline, and they are also the reason the gap exists. A page like DeepSource's 7 Best AI Code Review Tools for 2026 ranks the popular hosted agents by demo depth and installation count. That kind of ranking tells you which tool is most visible, not which one relieves scrutiny. The engineering-first accounts answer the question the listicles cannot: does this change what a reviewer reads, or just how many alerts they ignore?
On the tooling itself, the current "best AI code review tools for GitHub" landscape is mostly two shapes. There are the agents that attach to a repo and comment on each PR, like GitHub Copilot Code Review, CodeRabbit, and Qodo. Then there are the tools that are deliberately model-agnostic and BYOK, built to sit in the reviewer's existing workflow rather than replace it. Kodus is that second shape: an open-source peer to the hosted agents, with a free Community tier that runs your own model and a Teams tier for hosted BYOK, so a team that already reviews through GitHub keeps that workflow and gets the triage layer on top.
The metric that catches a broken review process
I have written before on an adjacent angle, what an agent PR costs when it never merges. The Salesforce post contains the practical lesson on the other side of the coin, and it is not to buy a faster review bot. It is to watch the right metric. If your cycle time is climbing while review time flattens, you are not keeping up. You are skipping.
Set that expectation before you evaluate any tool. Ask whether it merges related changes conceptually, whether it surfaces context from prior work, whether it explains why it flags something. A review agent that names a risk and shows its reasoning is doing more than one that adds a comment to every file. On a 1,000-line AI change, the tool that tells you where to look is worth more than the tool that looks everywhere and says nothing useful.
Top comments (0)