The short version
- Route pull requests by what they touch, before review starts. Not by who wrote them, and not by whether AI was involved - you can't verify that answer, so you can't gate on it.
- Cap review size at 400 changed lines. Reviewers find the most defects under 200 lines, and detection falls off past 400 (SmartBear/Cisco, 2,500 reviews across 3.2 million lines).
- Cap review sessions at 60 minutes. Detection rates plummet after that, which means your reviewer's week is a fixed budget, not a stretchable one.
- Make the author annotate every non-obvious change before a human reads it. Author-prepared reviews showed far lower defect densities in the Cisco data, and the mechanism is that annotating forces the author to actually read what they're submitting.
- Name one human author of record per PR. An AI tool is not an author, cannot hold accountability, and "the model wrote it" is not a postmortem finding.
- The full standard is at the bottom. Copy it, fill in the four blanks, put it in your repo.
The bottleneck didn't disappear, it moved into your review queue
The bottleneck moved into your review queue, and there is now direct evidence of the move. A team of researchers tracked 802 developers across 196,212 pull requests at a company that mandated doubling merged PRs per engineer. It worked. Throughput hit 2.09 times the pre-mandate baseline by April 2026. But look at what happened underneath, in the authors' own words: "per-reviewer load roughly doubled and automated review overtook human review, while merge and revert rates held steady."
That second clause is the whole story. The team doubled its output. The reading did not double. It got reassigned to machines.
This fits what DORA found across nearly 5,000 technology professionals in its 2025 report: AI adoption now correlates positively with delivery throughput, and it still correlates negatively with delivery stability. Google's framing is the one worth stealing. "AI doesn't fix a team; it amplifies what's already there." If your review process was informally held together by two people who read everything, AI didn't break that. It made it obvious.
Two honest caveats, because this post is going to ask you to change how your team works and you should know how firm the ground is. The 802-developer study is one company, and the authors are careful about it: adoption wasn't randomly assigned, so they read their own evidence as "strongly implicating an adoption-and-use channel rather than as exact causal attribution." And "merge and revert rates held steady" is genuinely good news that cuts against the alarmist version of this argument. Nothing fell over. I'm not going to tell you AI is burying your team in broken code, because that company's data says it didn't.
What the data says is narrower and more useful. The constraint relocated onto your senior engineers, and nobody decided that it should.
Your reviewers have a measured ceiling, and AI didn't raise it
Your reviewers have a ceiling, it was measured 20 years ago, and no model release has moved it. In 2006, Smart Bear Software finished a 10-month study of 2,500 code reviews covering 3.2 million lines of code written by 50 developers in Cisco's MeetingPlace group. Smart Bear called it the largest case study ever done on lightweight code review. Its conclusions read like a spec sheet for human attention:
| What they measured | What they found |
|---|---|
| Lines per review | "LOC under review should be under 200, not to exceed 400. Anything larger overwhelms reviewers and defects are not uncovered" |
| Session length | "Total review time should be less than 60 minutes, not to exceed 90. Defect detection rates plummet after that time" |
| Reading speed | "Inspection rates less than 300 LOC/hour result in best defect detection. Rates under 500 are still good" |
| Effectiveness by size | No review larger than 250 lines produced more than 37 defects per 1,000 lines. Reviews under 200 lines found several times the average |
| Baseline yield | 32 defects per 1,000 lines on average, and 61% of reviews found nothing at all |
Here's the part I want to be precise about, because it's an inference and not a finding. Cisco's numbers describe humans reading human-written code in 2006. Nobody has re-run that study on Claude Code output, and I won't pretend the 2006 constants transfer cleanly. But they measure a property of the reader, not of the author. A person wears out after 60 minutes of reading code because of how people read, not because of who typed it. That's the claim, and it's the one thing in this post you should push back on hardest if you disagree.
Now put the AI-era numbers next to it, and notice they don't say what you'd expect.
Median PR size grew from 44 lines to 72 lines between July 2025 and June 2026 in DX's data. Jellyfish, working with OpenAI across 500-plus companies, found that going from zero to full AI adoption moved a PR from 74.8 additions to 88.4, an 18.2% increase. Those two figures disagree in magnitude and measure slightly different things, and I'd rather show you that than pick the scarier one. The direction is consistent. The size of the effect is contested.
But 72 lines is not a problem. 88 lines is not a problem. Both sit comfortably inside the band where Cisco's reviewers were most effective. Your median pull request is fine.
The volume isn't. Jellyfish measured PR throughput 113% higher at full adoption. The 802-developer study measured per-reviewer load roughly doubling. Nothing about any individual review got meaningfully harder, and the reviewer's week roughly doubled anyway.
That reframes the problem. If each review is bounded at 60 minutes and 300 lines an hour, and the number of reviews doubles, you cannot fix this inside the review. There is no version of "read more carefully" that absorbs a doubling. The only lever that moves is which pull requests get the senior hour, and that decision happens before anyone opens the diff.
That is where the gate sits now.
Where the gate actually sits
The gate sits at routing, before review starts, and it keys on what the change touches. Not on who wrote it. This is the single change that separates a team with a standard from a team with a backlog and a bad feeling.
Start with what doesn't work, because it's the first thing everyone tries: gating on whether AI wrote the code. It fails on mechanics. You cannot verify the answer. DX's own 51.9% AI-authored figure is self-reported, and DX flags that it's likely biased in both directions. Your engineers aren't lying to you. They genuinely don't have a clean line between a completion they accepted, a block they edited, and a function they wrote after reading a suggestion. A rule keyed to an unanswerable question is theatre, and your team will work out it's theatre within a sprint.
Blast radius is different. It's a property of the diff, it's visible in the file paths, and a script can read it. Route on that.
Three tiers, keyed to what a change can reach:
- Tier 1 is anything touching auth, authorization, payments, personal data, data deletion, schema migrations, public API contracts, or infrastructure. A named senior reviews it. The size cap is hard. Automated review may comment and may not approve.
- Tier 2 is everything else that runs in production. One human reviewer, any engineer. The size cap is soft, and the reviewer can return an oversized PR unread.
- Tier 3 is tests, docs, comments, lockfiles, dependency bumps inside a minor version, and generated code with a checked-in generator. Automation approves it. You spot-check a random sample weekly.
The routing is the gate. Everything else in the standard is enforcement.
One objection worth taking seriously, because I hear it every time: shouldn't I just train the team to validate their own AI output and skip the bureaucracy? Partly, yes, and it's a real answer. I wrote the practitioner's version of that discipline for the individual engineer, and it works. But it doesn't compose. Ten engineers each validating to their own standard produce ten standards. Personal discipline is a per-engineer fix for a per-engineer problem, and review load isn't a per-engineer problem. It's a queue problem, and queues need routing rules rather than better intentions.
The Cisco data hands you the other mechanism, and it's the one I'd fight for if you only adopted one line of this post. Authors who annotated their changes before review had far lower defect densities. Smart Bear's reading: "Authors who prepare the review with annotations and explanations have far fewer defects than those that do not. We presume the cause to be that authors are forced to self-review the code."
Forced to self-review. That's the phrase. Requiring an engineer to write down what a hunk does and why they chose that approach makes them read it, which is exactly the step that generating code skips. It costs the author four minutes and it's the cheapest quality mechanism in this post. It also has a catch, and I'll get to it.
Who's accountable when AI-generated code causes an incident
The human who opened the pull request is accountable. Not the model, not the vendor, not the reviewer who approved it, and not "the tooling". One name, and it's the name on the PR.
This isn't a moral position, it's an operational one. Accountability has to land somewhere a decision can be changed. A model cannot be asked why it did that, cannot be trained by the postmortem, and cannot carry the fix. Every functioning incident process routes to a person who can answer questions and act on the answer. AI doesn't change the shape of that. It adds a plausible-sounding place to put the blame, and if you let that stick, you've built a system where nobody is responsible for production.
So say it once, in writing: "an AI tool generated it" describes how a change was produced. It does not describe who is answerable for it. It can appear in a postmortem as a contributing factor. It is never the owner.
The reviewer is a second signature, not a transfer. When your senior approves a Tier 1 change, they're attesting they read it and it looked right to them. That's real and it's worth something. It does not move accountability off the author, and a team that thinks it does will produce authors who submit code they haven't read on the theory that review will catch it. In the Cisco data, 61% of reviews uncovered no defects at all. Some of those changes were genuinely clean, and I won't pretend otherwise. But a gate that comes back empty three times in five is not something you can throw unread code at and expect to be caught, and AI didn't make it one.
The review standard, ready to copy
Here's the standard. Fill in the four blanks, put it in your repo as REVIEW_STANDARD.md, and link it from your PR template. It's free, it's yours, and it works whether or not you ever talk to me.
# Code review standard - AI-assisted changes
Version 1.0 | Owner: <name> | Next review: <date, 90 days out>
## 1. Scope
Applies to every pull request against <repos>, regardless of how the code was
produced.
## 2. Author of record
Every PR has exactly one human author of record: the person who opens it.
The author of record is accountable for the change in review, in incident
response, and in postmortem.
"An AI tool wrote it" is not a defence. It may appear in a postmortem as a
contributing factor. It is never the owner.
## 3. Disclosure
Label a PR `ai-assisted` if a model produced code you did not type.
Disclosure sets the author-preparation requirement in section 5. It does not
change accountability (section 2), does not route the PR (section 4), and
never blocks a merge on its own.
We do not audit this label. It is a prompt for you, not a test of you.
## 4. Routing by blast radius
Route by what the change can reach. Not by who wrote it. Not by whether AI
was involved. Routing is automated off file paths where possible.
Tier 1: auth, authorization, payments, personal data, data deletion, schema
migrations, public API contracts, infrastructure and IaC, and
anything reachable from production without a further gate.
Tier 2: everything else that runs in production.
Tier 3: tests, docs, comments, lockfiles, dependency bumps within a minor
version, generated code with a checked-in generator.
A PR that mixes tiers is a Tier 1 PR until it is split.
## 5. Requirements by tier
Tier 1
- Reviewer: a named person from <tier-1 reviewer list>. Not "anyone free".
- Author preparation: required, always. Before requesting review, comment
inline on every non-obvious hunk stating what it does and why this
approach.
- Size cap: 400 changed lines, hard. Over the cap, split it or book a
walkthrough (section 7).
- Automated review may comment. It may not approve.
Tier 2
- Reviewer: one engineer.
- Author preparation: required on `ai-assisted` PRs.
- Size cap: 400 changed lines, soft. Over the cap, the reviewer may return
it unread.
Tier 3
- Automated review approves.
- <role> spot-checks a random sample weekly.
## 6. Reviewer rights
A reviewer may return any PR unread, with no further justification, if:
- it exceeds the size cap for its tier, or
- it mixes a Tier 1 change with unrelated changes, or
- the author cannot answer a question about code they submitted.
Returning a PR unread is a correct action. It is never held against the
reviewer, and it is never escalated as obstruction.
## 7. When the cap genuinely cannot be met
Some changes do not split. For those, book a 30 to 60 minute walkthrough
with the named reviewer and record the decision in the PR.
Do not approve a 2,000-line Tier 1 PR asynchronously. Nobody reads those.
The approval is a signature on an unread document, and it makes the record
worse than having no review at all, because now it looks reviewed.
## 8. Review budget
Each reviewer's review time is capped at <N> hours per week. It is protected
work, not overflow, and it appears in planning.
Sessions run 60 minutes maximum. Detection falls off after that.
If the Tier 1 queue exceeds the budget two weeks running, that is a staffing
signal and goes to <role>. It is not a request for anyone to try harder.
## 9. What automated review is for
Automated review decides the classes it can actually decide: syntax, types,
lint, known-vulnerable dependencies, test execution, and coverage deltas.
It is not evidence that a change is correct, in scope, or wanted.
Automated approval is never sufficient on Tier 1.
## 10. Ownership
Owner: <name>. Reviewed every 90 days.
Changes to the Tier 1 path list need sign-off from <role>.
Four blanks: the owner, the repos, the Tier 1 reviewer list, and the weekly budget. If you can't fill in the Tier 1 reviewer list, you've just found the actual problem, and it isn't a process problem.
What this standard costs you
This standard costs you Tier 1 speed, some real splitting work, and it comes with one mechanism that might be fooling you. Any standard-setting post that skips this section is selling something.
Tier 1 gets slower. That's not a side effect, it's the function. You're buying attention on the changes that can take down production, and you pay for it in merge latency on maybe 10% of your PRs. If that trade looks bad to you, don't adopt the standard, because you'd be taking the paperwork without the benefit.
Splitting is real work, and AI-generated changes resist it. A model asked for a feature writes the feature, wired end to end, in one shot. Cutting that into a 400-line Tier 1 core and three Tier 3 satellites is a manual job the tool actively works against. Budget for it. It's the most-complained-about line in the standard and I don't have a trick that removes it.
Now the part that should worry you, because it worried Smart Bear enough that they published it against their own recommendation. Author preparation correlates with low defect density. There are two explanations, and they point in opposite directions. The first is the one I've been selling: annotating forces the author to self-review, so they find their own bugs before the reviewer arrives. The second is that "prepping disables the reviewer's capacity for criticism", and so, in their words, "the reason defect density is low for an author-prepared review is not because the author pre-fixed defects, but rather because the reviewers aren't looking hard enough."
If the second explanation is right, annotation makes your reviews look cleaner without making your code better. Smart Bear judged the first more tenable and I agree with them, but "I agree with them" is not evidence, so here's how you check it on your own team. Watch two numbers together: defects found in review, and defects that escape to production. If in-review defects fall after you adopt author preparation and escaped defects fall too, you're in the first explanation and it's working. If in-review defects fall and escaped defects hold steady or climb, you're in the second, your reviewers have been lulled, and you should drop the annotation requirement on Tier 1 and watch whether it recovers.
The same discipline applies to the headline finding in this post. That company's per-reviewer load doubled and automated review overtook human review while merge and revert rates held steady. One reading is that automation absorbed the load and everything's fine. The other is that merge rate and revert rate are not defect rates, and they were never going to catch a slow decline in review quality. Both readings fit the data. Whether your version worked is a measurement question with its own method, and it isn't one you can answer by looking at your PR dashboard and feeling good about the throughput line.
Tools, resources, and next steps
The standard above is the deliverable and it costs nothing. Two things it can't do for you, and both trace back to the same constraint.
The first is that this standard asks more of your seniors, not less. Tier 1 review with a real size cap and a named reviewer is a bigger ask than "someone approve this". If your Tier 1 reviewer list has one name on it, the standard has correctly identified a staffing gap and cannot fill it. Getting a senior engineer outside your team to read actual Tier 1 code is one way to find out whether your bar is where you think it is, and MentorCruise's work review sessions are 45 minutes at $119, which is cheap next to the incident that finds the gap for you.
The second is the demand side. Every Tier 1 PR that arrives at 900 lines with no annotations is a review-budget problem created upstream, at the moment an engineer prompted for a feature instead of a change. That's a habit, and habits move with training rather than policy. Our Claude Code workshops start at $250 for a two-hour session and run to $900 for a full day.
Neither is required for the standard to work. If you take the artifact, fill in the blanks, and never speak to us again, the post did its job.
For the individual engineers on your team who want the personal discipline underneath all of this, the validation playbook is written for them rather than for you.
FAQs
How many lines should a pull request be?
Under 200, and never over 400. Smart Bear's Cisco study found reviews under 200 lines produced several times the average defect-detection rate, and no review larger than 250 lines produced more than 37 defects per 1,000 lines. Their published guidance puts it at "no more than 200 to 400 lines of code (LOC) at a time". Those numbers were measured on human-written code in 2006, and they describe the reader's limits rather than the author's, which is why they still hold.
Should engineers have to disclose which PRs are AI-assisted?
Yes, but not for the reason most teams think. Disclosure is useless as a gate, because nobody can reliably say where a suggestion ended and their edit began, and the self-reported figures in the research carry that same weakness. It's useful as a trigger: label the PR, and the label tells you to annotate your changes before review. Never route on the label, never audit it, and never let it change who's accountable.
Can automated code review replace human reviewers on AI-generated code?
Not on anything with real blast radius. Automation decides the classes it can actually decide, which is syntax, types, lint, vulnerable dependencies, and whether the tests ran. It cannot tell you whether a change is in scope, matches what the team meant, or is wanted at all. That gap is exactly where AI output lands: in the 2025 Stack Overflow Developer Survey, 66% of developers said their biggest frustration was "AI solutions that are almost right, but not quite", and 45.2% said debugging AI-generated code takes longer. Almost-right code passes every check a machine can run.
Our review queue is growing faster than we can read it. Do we hire, or fix the process?
Fix the routing first, because it's cheaper and you can do it this week. Most teams have never separated the changes that can take down production from the changes that can't, so their seniors spend attention uniformly on a queue that isn't uniform. Route by blast radius, and a large share of the queue stops needing a senior at all. If your Tier 1 queue still exceeds your review budget two weeks after that, the routing was never the problem and you have a staffing answer with evidence attached.
What does an outside reviewer catch that your own team won't?
The things your team has collectively stopped seeing. Every team converges on shared assumptions about what "normal" code looks like, and reviewers inside that consensus don't flag what everyone already accepts, which is the failure mode Smart Bear worried about with author preparation, one level up. An outside senior reading a Tier 1 PR has no stake in your conventions and no memory of why you did it that way in 2024. That's the value, and it's also why it's uncomfortable.
