Originally published at mnemehq.com
Code review is the last human gate before code enters a shared codebase. For most of engineering history, that gate was sufficient. The volume of code a human engineer could write in a day was bounded by the same biology that bounded a reviewer’s capacity to read it. The ratio of production to review held.
Generative AI broke that ratio.
An engineer working with a capable coding assistant does not produce incrementally more code. They produce categorically more code — ten times, in many observed cases, with trajectories suggesting that multiplier will keep moving. The code review process was not designed for this. It is a linear process applied to what is now an exponential input, and the resulting gap is not a workflow problem. It is an architectural one.
The math that does not work
Code review has a throughput ceiling. A careful reviewer, attending to logic, correctness, security, and style, can review somewhere between 200 and 400 lines of meaningful code per hour before quality degrades. This is not a number that improves much with practice or tooling — it is a cognitive limit. The reviewer must build a mental model of what the code is doing, hold that model against what it should be doing, and identify where they diverge.
That ceiling is per reviewer, per hour. It does not scale horizontally without adding reviewers. And reviewers are not cheap — the senior engineer doing the review is the same engineer who could be building something else.
Now put an AI coding assistant in the picture. The same senior engineer who previously produced 200 lines of thoughtful code per day is now shepherding an AI that can generate 2,000 lines in the same period. The engineer’s review capacity has not changed. The production rate has moved by an order of magnitude. The pipeline now looks like a highway merging into a country lane.
What happens when review can’t keep up
Teams respond to this mismatch in predictable ways, none of them good.
Review becomes a formality. Reviewers approve PRs they have not fully read. The approval signal — the thing that was supposed to mean “a human examined this and it is correct” — begins to mean “a human clicked this button.” The signal degrades faster than the team notices, because each individual approval still looks like an approval.
Review focuses on style over substance. It is faster to comment on naming conventions than to trace a logic path through five files. Review that cannot keep up with volume self-selects toward the things that are fast to check, systematically deprioritizing the things that actually matter — architecture, security boundaries, correctness under edge cases.
Batch sizes grow. Teams attempt to compensate for review bottlenecks by batching changes. Instead of reviewing 50-line PRs daily, they review 500-line PRs weekly. Larger diffs are reviewed worse, not better — the reviewer’s mental model degrades faster, and the risk surface in any individual review grows while the quality of attention per line falls.
The codebase drifts. Architecture decisions made in ADR-014 were reviewed carefully six months ago. The AI-generated PR touching the same service was reviewed for five minutes and approved. The accumulated drift between “what we decided” and “what the codebase actually is” grows silently, invisibly, until something breaks in a way that is expensive to diagnose.
Why shifting review left does not fully solve it
The conventional response to review bottlenecks is to shift quality checks earlier — into linting, type checking, automated tests, and pre-commit hooks. Shift left. Catch it before it reaches review. This is correct advice and teams should do it.
It does not solve the architectural compliance problem.
Linters enforce syntax and style. Type checkers enforce interface contracts. Tests enforce functional behavior. None of these enforce architectural decisions: which libraries are approved for use in which services, which patterns are prohibited in which contexts, which teams own which boundaries and what the rules are for crossing them.
An AI model that has been told “do not use library X in the payments service” will generate code that does not use library X — until it does, because a different session, a different context window, a different temperature setting, a different model version produces an output that violates the rule. No linter will catch this unless someone wrote a custom lint rule for this specific decision. And the set of architectural decisions in a production codebase grows faster than the set of custom lint rules anyone has time to write.
The problem is enforcement, not detection
Most teams frame this as a detection problem: how do we find violations faster? Better diff summaries. AI-assisted review. Automated PR descriptions. All of these make the reviewer’s job easier. None of them change the fact that enforcement still depends on a human catching the violation before merge.
In a world where code review throughput is a hard ceiling and AI generation volume is accelerating past it, relying on humans to catch architectural violations at review time is building on a foundation that is actively shrinking relative to the load placed on it.
The correct frame is enforcement, not detection. A constraint that needs to be enforced at review time — because it cannot be enforced anywhere else — will be enforced inconsistently as volume grows. A constraint that is enforced before the code is generated, or hard-rejected before it reaches the reviewer, is enforceable regardless of volume.
What enforcement before review looks like
Enforcement before review requires a governance layer that operates at generation time, not review time. The model generating the code needs to know — deterministically, not probabilistically — which architectural constraints apply to the current file, service, and context. Not as instructions in a prompt that can be overridden by other instructions. As a resolver that computes the applicable constraint set before generation begins and enforces it after generation ends.
This is shift-left applied to architectural governance, not just to style and syntax. It means the reviewer is no longer the last line of defense against constraint violations. It means the reviewer can focus on what review is actually good at: logic, design, intent, readability. The things that require human judgment and are not going to be replaced by a rule engine.
The window for getting this right
The teams that are under the most pressure from AI-generated code volume right now are the teams that adopted AI coding tools earliest. They are also the teams building the most. They are discovering the review bottleneck at exactly the moment when their AI-generated codebase is too large to fix cheaply.
The teams that have not adopted AI tools aggressively yet have a window. Build the governance layer before the volume arrives. The enforcement infrastructure is easier to put in place when the codebase is still manageable than after the drift has compounded for eighteen months.
Code review cannot scale with AI output. The solution is not to make code review faster. The solution is to enforce architectural constraints at the layer where they can actually be enforced — before the code reaches the reviewer, and before the reviewer becomes the bottleneck between engineering velocity and codebase integrity.
Read this article in full at mnemehq.com/insights/why-code-review-cannot-scale-with-ai-output/