How I Review AI-Written Code Without Slowing Down

When an agent can produce a working pull request in the time it takes to make coffee, the slow part of shipping is no longer writing code. It is reading it. This post is the system I use to keep review thorough where it matters and fast everywhere else.

Why has code review become the bottleneck?

Because AI raised the volume and size of changes while human reading speed stayed the same. Faros AI's AI Productivity Paradox report, based on telemetry from over 10,000 developers across 1,255 teams, found that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, but PR review time rose 91% and average PR size grew 154%. The report calls human approval "a critical bottleneck."

Reading has hard limits. SmartBear's code review guidance, based on its study of a Cisco programming team, recommends reviewing no more than 200 to 400 lines at a time, reports that a review of that size over 60 to 90 minutes should find 70 to 90% of defects, and notes a significant drop in defect density at rates faster than 500 lines per hour. Those figures come from a vendor's study and are best treated as guidelines, but the direction is clear: you cannot read faster to keep up. You have to read less, and choose better what you read.

I covered the specific mistakes AI code tends to make in the almost-right problem. This post is about the process around them: how to decide how hard to look.

How do you decide how deeply to review each change?

Tier every change by what it could break, not by how big it is or who wrote it. I use three lanes, and the lane is decided before I open the diff, from the files touched and the task description.

Two rules keep the tiers honest. A change takes the lane of its riskiest file, so a styling tweak that also edits a permission check is red. And anything I cannot classify quickly is amber at minimum, because "I'm not sure what this touches" is itself a risk signal.

The point of the green lane is not to be careless. It is to free attention for red. If every change gets a red-lane read, reviewers tire, and tired reviewers skim exactly the changes that needed care.

Why should you read the tests before the code?

Because the tests tell you what the change claims to do, and that is the fastest way to judge whether the code does it. When I open an AI-written pull request, I read in this order:

• The task or spec. What was asked. If there is no written definition of done, the review starts with writing one. I described the format in spec-driven development.
• The evidence. The command the agent ran and its output. No evidence, no review.
• The test names. Do they cover the edge cases in the spec, such as empty input, the unauthorised user or the duplicate request?
• The assertions. A test that only checks a function "returns something" proves very little. I look for assertions that would fail if the behaviour were wrong.
• Then the code. By now I know what it is supposed to do, so I am checking it against something rather than reading it cold.

For green-lane changes, steps 1 to 3 plus a skim are often enough, because the checks already ran. For red-lane changes, the tests are where I start, not where I stop. Getting agents to produce that evidence reliably is the subject of give the agent a way to check its work.

How do you get diffs that are quick to review?

Ask for smaller changes and make the author, human or agent, explain them. Google's engineering practices guide says "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large," and that it is easier for a reviewer "to find five minutes several times to review small CLs than to set aside a 30 minute block to review one large CL." It also recommends keeping refactoring in a separate change from features and bug fixes, and shipping tests with the logic they cover.

Agents are good at following these rules if you put them in the task. My standing instructions for any agent opening a pull request:

• One purpose per pull request. A refactor and a feature are two pull requests, even if the agent did both in one session.
• Commits in a readable order. Preparation first, then the change, then tests, so the history reads like an explanation.
• A description that a reviewer can check: what changed, why, what was deliberately left out, the riskiest part of the change and the command output that proves it works.
• Flag anything surprising. A new dependency, a changed default or a deleted test goes at the top of the description, not buried in the diff.

SmartBear's guidance makes the same point about authors: it recommends that authors annotate their code before the review, and notes they often find extra errors themselves while doing it. An agent can write that annotation in seconds, so there is no reason to accept a pull request without one.

Where does an AI reviewer help, and where doesn't it?

An AI reviewer is useful as a first pass with a narrow brief, not as the final word. The Claude Code best practices describe a read-only reviewer subagent, limited to Read, Grep and Glob, that compares changed files against the spec and reports only gaps that affect correctness. The same page warns: "A reviewer that's asked to find problems will always find something," and says fixing every finding leaves you with extra abstraction layers and tests for cases that cannot happen. That is why its example prompt ends with "skip style".

Where an AI reviewer earns its place in my process:

• Spec coverage in the amber lane. Is every requirement implemented, and does every listed edge case have a test?
• A fresh pair of eyes. A session that did not watch the code being written is not swayed by the reasoning behind it.
• Summaries of large but mechanical changes, such as a rename across many files, so I know which parts to sample.

Where it does not replace me: anything in the red lane, and any judgement about whether the change was the right thing to build at all. When agents work in parallel, as in running parallel AI agents on one codebase, the AI reviewer helps keep up with the volume, but every branch still meets a human before it merges.

How do you keep the review system honest over time?

Make the red lane enforced, not remembered, and adjust the tiers when something slips through. On GitHub, a CODEOWNERS file automatically requests a review from the owners of the files a pull request touches, and the "Require review from Code Owners" branch protection option makes that approval mandatory. Listing auth, billing and migration paths there means a red-lane change cannot merge on a green-lane skim, however tired the team is.

Three habits keep the rest calibrated:

• Sample the green lane. Now and then, read a green-lane change properly. If it held a real problem, the tier rules need tightening.
• Re-tier after incidents. When a bug reaches production, ask which lane its change was in, and whether that lane was right.
• Watch review time, not just merge count. If pull requests wait days for review, the fix is smaller changes and clearer lanes, not faster skimming.

Work with me

I build full-stack products and AI agent systems with review built into the workflow: risk tiers, enforced owners for sensitive paths and agents that show their evidence. See full-stack development and AI agent development, or browse my work and book a scoping call.