AI generates code faster than teams can review it. How smaller diffs, machine pre-review, and risk-based triage keep review quality from collapsing.
Generating code used to be the slow part of shipping software. A coding agent now produces a working implementation, a matching test suite, and a migration script in the time it takes a reviewer to finish reading the ticket. That flips the constraint. A team's ability to ship safely no longer depends on how fast it can write code. It depends on how fast it can verify code it did not write, line by line, is worth trusting. Review was already the stage where most defects were supposed to be caught before production. At AI speed, it is also the stage most likely to break first.
The naive response, review everything exactly as carefully as before, does not scale, because reviewer attention is fixed while diff volume is not. The naive alternative, wave changes through faster to keep pace, trades a bottleneck for a risk that shows up later and costs more. Neither is the real fix. The fix is redesigning review around the constraint that actually changed: smaller units of work, a machine pass that catches what does not need a human, prioritization by what a change can actually break, and human attention spent only where a human is the one thing that can make the call.
Why Review Becomes the Bottleneck at AI Speed
A reviewer looking at hand-written code carries an implicit budget: the author spent hours or days producing the change, so a review that takes twenty minutes is proportionate to the effort behind it. That ratio collapses when an agent produces the same diff in ninety seconds. Diff volume grows to match generation speed, but the number of qualified reviewers and the hours in their day do not move at all. Any team running AI coding assistants at real scale hits this within weeks: pull requests pile up, turnaround stretches from hours to days, and the backlog itself becomes pressure to skim rather than read.
- Diff volume grows with model throughput, not headcount, so a backlog is the default outcome, not an edge case.
- Reviewers under time pressure scrutinize what looks obviously wrong and skim what looks plausible, which is exactly backwards for AI-generated code, since most of it looks plausible.
- A merged pull request is not proof of correctness. It is proof someone approved it under whatever time pressure existed that day.
- Skipped or rushed review does not remove risk. It moves the point of discovery from code review to a production incident.
Smaller Diffs: The Oldest Lever, Still the Best One
This is not a problem AI coding assistants invented. A widely cited SmartBear study of a Cisco Systems engineering team measured how review size and pace affect defect discovery, and found that reviewing more than roughly 200 to 400 lines of code in one sitting, or reviewing faster than about 500 lines per hour, measurably lowered the rate at which reviewers actually found defects. Reviewing for more than about 60 minutes at a stretch showed the same drop-off. Within those bounds, a review of 200 to 400 lines caught 70 to 90 percent of the defects present in the change. The finding predates AI code generation by close to two decades, and it still applies, because it describes a limit on human attention, not a limit on how the code got written.
Sources: SmartBear: Best Practices for Peer Code Review (Cisco Systems study)
That ceiling does not move because a model wrote the diff instead of a person. If anything it argues for a harder cap, since a model can produce a 1,500-line, multi-file change in one shot with none of the natural pauses a human author would hit while typing it out by hand. Enforcing small units of work, one behavior change per pull request, tests included in the same diff, migrations separated from the feature they support, keeps every individual review inside the range where a human reviewer's judgment is still reliable, regardless of how fast the code arrived.
Cap generated diffs at review-sized chunks before they are opened for review, not after. Asking an agent to implement "the smallest change that satisfies this spec, split into separate commits per concern" produces reviewable units by construction, instead of relying on a reviewer to request a split after the fact.
Machine Pre-Review: Let an Independent Agent Go First
Not every defect needs a human to find it. Style violations, missing null checks, unused variables, inconsistencies with existing codebase conventions, and known anti-patterns are exactly the class of finding a second, independent model can catch reliably, before a human ever opens the diff. The requirement is independence: the same model reviewing its own output shares the assumptions that produced the bugs in the first place, so it tends to approve what it already wrote. A separate agent, with no stake in the code's authorship, applies a colder read and hands the human stage a smaller, higher-signal diff.
This is not a replacement for human review, it is a filter in front of it. The machine pass triages: mechanical issues get fixed or flagged automatically, and genuinely ambiguous findings, the ones that need judgment about intent rather than pattern-matching against a known defect list, get escalated with the machine's notes attached instead of a blank diff. Carrying that context forward matters as much as the first pass itself. A pre-review agent that starts from zero every session re-flags decisions the team already settled last week. A persistent memory layer like MemX is built for exactly that gap, keeping prior review decisions and settled patterns available across sessions instead of forcing every pre-review pass to relitigate them.
The goal of machine pre-review is not fewer human reviews. It is human reviews that only contain the questions a machine cannot answer.
Prioritize by Risk, Not by Arrival Order
Reviewing pull requests in the order they arrive treats a typo fix and a change to the authentication flow as equally urgent, which was never true. At AI speed, treating them as equal just guarantees the wrong one waits. Triage by blast radius before triage by timestamp: a change touching auth, payment handling, data access controls, or anything parsing external input needs a human's full attention regardless of how small the diff looks. A change confined to internal tooling, test-only code, or documentation can tolerate a lighter pass, or ride entirely on the machine pre-review, without materially raising risk.
- High priority: auth and session handling, payment and billing logic, data access and permission checks, anything parsing untrusted input.
- Medium priority: core business logic changes, database schema or migration changes, changes to shared libraries other services depend on.
- Low priority: internal tooling, test-only changes, documentation, formatting and lint-only diffs, dependency bumps with no code changes.
- Risk-based triage is a routing decision, not a skip decision. Low-priority changes still get reviewed, just by the machine pass by default, unless something in the diff trips a higher tier.
Reserve Human Attention for Intent and Security
A model can tell you whether code compiles, matches the style guide, and resembles patterns it has seen before. It cannot reliably tell you whether the code solves the problem the business actually has, or whether a locally reasonable design choice opens a security gap three layers away from the diff under review. Those two questions, does this match intent, and what does this expose, are the ones worth a human's limited time, and they are also the ones a coding assistant is least equipped to answer about its own output.
This reframes what "reviewing code" means once volume stops being the constraint. A human reviewer at AI speed spends less time reading for syntax and more time asking whether the spec was interpreted correctly, whether the change introduces a new trust boundary, and whether the tests exercise the behavior that actually matters instead of the behavior that is easiest to assert on. A checklist built specifically for AI-generated code keeps that judgment consistent across reviewers and across a backlog that never fully empties, and splitting the remaining human review across independent reviewers with separate mandates, correctness, security, architecture, catches more than one generalist pass ever will, even once volume is already thinned by triage.
Traditional Review vs. AI-Speed Review
The shift is not a new tool bolted onto the old process. It changes what each stage of review is actually responsible for.
| Dimension | Traditional review | Review at AI speed |
|---|---|---|
| Diff size | Bounded by how much a human writes in a sitting, often already under a few hundred lines | Bounded only by model throughput; multi-file diffs of 1,000+ lines are common without a forcing function |
| First pass | A human reads the whole diff cold | An independent agent flags mechanical issues first; the human opens an already-triaged diff |
| Prioritization | Reviewed roughly in the order pull requests arrive | Ordered by blast radius: auth, data, and external-input paths go first |
| What blocks merge | Reviewer judgment on the day, inconsistent across people and workload | A fixed rule: critical findings block, minor ones do not |
| Reviewer's job | Catch everything: syntax, style, logic, security, and intent in one pass | Catch what only a human can: does this solve the right problem, is it safe to expose |
| Failure mode | Reviewer fatigue on long diffs quietly lowers the bar | Volume outruns review bandwidth unless diff size and triage are enforced, not just encouraged |
Frequently asked questions
01Does machine pre-review just add another AI system to trust blindly?
No, it changes what gets trusted and for what. The pre-review agent is independent of the one that wrote the code, its findings are mechanical and checkable against known patterns, and anything it cannot resolve gets escalated to a human rather than silently approved. The trust boundary sits on the escalation rule, not on the agent's judgment alone.
02How small should a diff actually be to stay in the reviewable range?
The Cisco study's range, roughly 200 to 400 lines reviewed at under about 500 lines an hour, is a reasonable target for AI-generated diffs too, though the more durable rule is one behavior change per pull request. A 150-line diff that bundles three unrelated changes is harder to review well than a 350-line diff that does one thing.
03Won't risk-based triage mean low-priority bugs never get caught?
Low priority does not mean unreviewed, it means reviewed by the machine pass by default instead of a human. Anything the machine pass flags as ambiguous, or anything touching a higher-risk path even indirectly, escalates. The goal is spending scarce human attention where a human's judgment is the only thing that can catch the defect.
04Where does this fit into a broader AI coding workflow?
It is one piece of a larger process. TLM Forge applies the same idea, a spec audit before code, independent review of both plan and diff, a convergence gate that blocks on critical findings, across a feature's entire lifecycle, not just the code review step. See how it works for the full sequence.