You add three AI-generated features to the sprint. Each arrives as a pull request. The code compiles, passes tests, and looks reasonable on first read. Now the team has to evaluate whether each change is architecturally sound, consistent with the repository's conventions, and safe to ship.
The agent solved the implementation problem. The review problem is still yours.
Adding an AI code reviewer to this pipeline doesn't eliminate the bottleneck. It adds a tool to a process with a structural problem. Here's what that problem is, and what actually addresses it.
AI increased code output. Review capacity stayed flat.
A preprint studying Microsoft's early 2026 rollout of Claude Code and GitHub Copilot CLI estimated that engineers who adopted the tools merged approximately 24% more pull requests than a comparable non-adopting group.
The authors are careful about what this means: merged pull request count is not equivalent to value delivered, and the causal estimate carries uncertainty. But the operational implication is real. Teams using AI coding agents are generating more code changes that require evaluation before they land in the main branch.
Senior engineers don't have 24% more review hours. A team's capacity for judgment—for determining whether a change belongs in the codebase—is not as elastic as its capacity for generating code. When AI agents accelerate implementation, the constraint moves to verification. Review becomes the bottleneck.
AI review is useful, but it remains probabilistic
The obvious response is to add AI to the review side. If AI can write code, it should be able to review it.
AI review does find real problems. But its detection rate against the issues that human reviewers actually flag is lower than tool announcements suggest.
SWE-PRBench, a benchmark measuring AI code review quality against real pull request feedback, evaluated eight frontier models and found they detected between 15% and 31% of human-flagged issues when reviewing just the diff. The models that performed better on code generation did not consistently perform better on code review.
More counterintuitive is the context finding. Adding execution data, test output, and broader repository context—exactly the kind of enrichment that should help a model understand what changed—caused consistent performance degradation across all eight models. A structured 2,000-token diff-with-summary prompt outperformed a 2,500-token prompt enriched with additional context. The mechanism appears to be attention dilution: as input grows, detection of specific issues falls.
A separate benchmark, c-CRAB, evaluated four code review agents—PR-agent, Devin, Claude Code, and Codex—and found that together they addressed approximately 40% of the benchmark tasks. The authors note a further complication: agents often flag different issues than human reviewers, which means the overlap with what a human would have caught is smaller than the 40% figure implies.
None of this makes AI review tools ineffective. They surface obvious issues, reduce noise on straightforward problems, and cut the time reviewers spend on common patterns. The problem is a specific category of check where AI review is particularly inefficient: constraints that shouldn't require inference at all.
Not every review question requires judgment
Two fundamentally different types of problems reach code review, and treating them the same way wastes the resource that can't be scaled.
The first type requires judgment: whether an abstraction reflects the domain correctly, whether a design decision will hold as requirements change, whether the implementation matches product intent rather than just the specification. These questions belong in review. They require the kind of contextual reasoning that reviewers provide.
The second type has a definite answer: whether a handler is importing a database client directly, whether a UI component bypasses the service layer, whether a route that requires authentication has the middleware attached, whether a prohibited package appears in a dependency that will reach production. These questions also reach review—but the reviewer isn't making a judgment call. They're detecting something a check could have caught before the PR was opened.
Sending the second type to an AI reviewer still costs time and introduces uncertainty. The AI has to reason probabilistically about something that has a deterministic answer. A static check just looks for the pattern and reports whether it's there.
Instruction files describe intent. They don't enforce it.
Teams that use AI coding agents often add architecture rules to CLAUDE.md, AGENTS.md, or Cursor's rules files. The expectation is that the agent reads the rule and complies.
The agent does read the rule. Compliance is not guaranteed.
Instruction files shape the agent's behavior probabilistically. They give the model context about how the repository is organized and what conventions the team follows. That context influences the output—it doesn't constrain it. When the immediate task pressure pushes toward a simpler solution that crosses an architectural boundary, the instruction recedes in the model's effective reasoning.
Why AI Coding Agents Cause Architecture Drift covers the mechanism in detail. The short version: instructions are input, not enforcement. A constraint is something the output has to satisfy before it merges. An instruction is something the model considers while generating.
The same limitation applies to AI review. A probabilistic check of the generated output still leaves room for a violation to slip through.
Move deterministic checks before review
The structural fix is to separate what requires judgment from what doesn't, and to move the deterministic checks earlier in the pipeline.
AI agent writes code
↓
Deterministic architecture checks
(layer boundaries, forbidden imports, required patterns)
↓
Tests and security scans
↓
AI-assisted review
(ambiguous issues, design questions, non-obvious patterns)
↓
Human judgment
(tradeoffs, intent, risk acceptance)
The checks in the second step need to be correct and fast, not sophisticated. A check that rejects a PR when a UI component imports a database client is binary: either the import is there or it isn't. No probabilistic reasoning is required.
Building these checks runs into a practical limitation: expressing repository-specific architecture rules in a form that a static tool can execute. Standard linters handle syntax and style. They can't express "handlers in this repository may not call repository functions directly" or "this particular package is prohibited in production code."
When building the rule engine in Unbx, we let users describe architecture constraints in natural language and generated executable Tree-sitter queries from those descriptions. The generation worked in most cases—but we found that a syntactically valid query isn't necessarily a correct one.
One generated query was designed to detect a specific import path we wanted to prohibit. The query compiled and ran without errors. When applied to a real codebase, it also flagged log messages and constants that contained the same string—because the query matched interpreted_string_literal nodes without constraining them to import declaration context. The rule was wrong in a way that wasn't visible from reading it.
This led us to add canary validation after every rule generation step. For each rule, we generate a minimal code sample containing the targeted violation, run the rule against it, and confirm at least one detection. We also generate a sample that uses similar patterns without violating the rule and confirm no false positive. If either check fails, the rule goes back for regeneration.
The implication extends beyond any particular tool: generating architecture checks with an LLM produces artifacts that are themselves probabilistic. The generated rule is not automatically correct just because it compiled. Verification of the check is as necessary as verification of the code the check is meant to catch.
What stays human
None of this is an argument for automating review. The goal is to remove from the human review path the decisions that don't require human judgment.
What belongs at the human judgment stage:
- Whether a design decision will hold as the product changes
- Whether the implementation reflects intent, not just the specification
- Whether a tradeoff is acceptable given the team's current situation
- Whether the code will be comprehensible to the next person who has to modify it
- Whether an architectural exception is warranted in this specific case
These questions produce value from a reviewer's experience and context in a way that a static check or a probabilistic model can't reliably replace. Protecting review capacity for these questions means moving the tractable ones earlier.
The bottleneck moved to review when AI agents accelerated implementation. Moving deterministic checks earlier shifts part of that load out of review. It doesn't eliminate human judgment. It recalibrates where judgment is actually needed.
The goal isn't to automate every review comment. It's to stop spending human judgment on rules the repository already knows.