AI is helping engineers write more code. But someone (or something) still has to review it.

We’re seeing reports of engineering teams merging up to four times as many PRs as they did two years ago, and those PRs are getting bigger. LinearB’s analysis of 8.1 million PRs found AI-assisted PRs are roughly 2.6 times larger than unassisted ones at the 75th percentile. Meanwhile, median review time has climbed from 33 minutes to 77 minutes. More code is getting written, but more of it is waiting for approval.

Adding another coding agent won’t fix that.

There are several ways to reduce the human effort in review without giving up much quality: keep PRs small, review the spec before the agent writes the code, let automated checks handle the mechanical work, ask for proof that a change works, and point reviewers at the parts of a change that need their attention.

This post focuses on a lever that comes before all of those: deciding which changes need human review in the first place. Most teams still treat a typo fix, a dependency update, and a change to authentication as variations of the same review process. They aren’t. The risks are different, and the review requirements should be too.

Give every PR the review it deserves

We need to start treating code review as a risk management problem, rather than a universal requirement that every change passes through in the same way.

Consider a small UI fix or a documentation change in a well-understood part of your application. If your automated tests pass, an AI reviewer doesn’t identify any issues, and the change doesn’t touch anything sensitive, do you really need an engineer to stop what they’re doing and approve it?

Probably not.

Now consider a change to billing logic, authentication, or a database migration. Even if it’s only five lines of code, I’d want someone who understands that system to look at it carefully. I’d also want to know that we have appropriate tests and a reasonable plan to roll it back if something goes wrong.

There’s a lot of work in between those two extremes. Everyday application changes where an engineer should still review the intent, behavior, and tests, but probably doesn’t need to scrutinize every line of code that an agent generated.

Traffic light risk assessments are essentially the approach I’d recommend: establish a fast track for low-risk changes, keep a normal review process for changes requiring engineering judgment, and apply more rigorous reviews to sensitive parts of the system.

Of course, the important part is defining what qualifies for each category. You don’t want an AI reviewer making that decision entirely on its own. Set hard boundaries around protected files, change size, test results, and other risk factors. The AI can identify additional concerns, but it shouldn’t be allowed to override those boundaries.

This isn’t theoretical

A few engineering teams are already putting versions of this into practice.

Will Larson recently wrote about how Imprint introduced a small-change policy that allows certain PRs to bypass traditional human review. They established a 1,000-line ceiling, restrictions on sensitive code, required clean AI review results, and made sure the author had experience with the affected service. About 10% of PRs initially qualified.

PostHog has taken a similar approach with its automated reviewer, StampHog. Their policy limits eligible changes to 500 lines across 20 files, excludes protected areas, and requires the AI reviewer to find no serious problems. In their published account, the agent provided the final approval on roughly a third of merged PRs.

Rewind has reported around 40% auto-approval in its early results. One detail I particularly like about their implementation is that they use a policy engine to determine which parts of the codebase require human review. The model can raise concerns, but it can’t decide to relax those requirements.

These numbers aren’t directly comparable, and I wouldn’t suggest that everyone should be targeting 30% or 40% automated approvals. Different applications have different risk profiles.

But there is a common theme worth paying attention to: deterministic rules establish what’s safe to automate, AI operates within those rules, and engineers focus on the changes that actually need their expertise.

Approval and shipping are different decisions

This is especially important for AI-generated code. A bot approving a PR doesn’t mean a bot should merge it. Rewind separates those permissions and still requires a human to merge agent-authored PRs.

Your policy should explicitly define who can author, approve, merge, and release each type of change. Without that separation, “AI-approved” can become an excuse for removing human accountability.

Start small. Measure both speed and safety.

Pick one well-understood repository and define the protected areas. Set the fast-track criteria. Then run the policy in shadow mode, where automation recommends decisions but humans still approve.

Before expanding, look at four things:

  • Review latency: Are PRs spending less time waiting?
  • Eligibility: How many changes actually meet the fast-track rules?
  • Safety: Are reverts, escaped defects, or incidents increasing?
  • Accuracy: Where did the automated reviewer disagree with humans, and who was right?

Give someone ownership of the policy and the authority to shut off automated approvals.

Review isn’t only about catching bugs. It’s also how engineers learn a codebase and catch architectural drift. If you remove routine reviews, make room for that learning elsewhere, through periodic reviews of related changes, for example.

The goal isn’t necessarily to maximize the percentage of PRs approved by AI. It’s to make better use of engineering judgment, letting low-risk changes move faster while helping engineers focus on the specific parts of a change that need their attention.

Reading list

  • Speeding up code review with small-change (Will Larson, October 2026) — The strongest practitioner anchor: Imprint’s eligibility rules, enforcement through CI, early 10% qualification rate, and the distinction between reviewing individual diffs and preserving organizational learning.
  • Review is the bottleneck now: How we let AI approve pull requests (safely) (Dave North, Rewind, June 2026) — The most detailed implementation account: specialist reviewers, deterministic policy enforcement, protected paths, shadow-mode calibration, audit evidence, and early results, with useful caveats about sample size and PR mix.
  • Stop being the code review bottleneck (Jina Yoon, PostHog, July 2026) — A concrete example of bounded auto-approval: StampHog’s size limits, deny list, escalation behavior, and fail-closed rule that the LLM cannot relax deterministic safeguards.
  • Everything We Talked About at O11yDay London 2026 (Ken Rimple, Honeycomb, October 2026) — Read Rebecca Murphey’s section, “Your AI Problem Is Your 2016 Problems Dressed in a Trenchcoat.” It provides Honeycomb’s 25% machine-only review goal and connects the review queue to flow efficiency and the theory of constraints.
  • The code review is dead; long live the code review (Cecilia Geraldo, Thoughtworks, June 2026) — A useful counterweight to the automation stories: the mechanics of line-by-line review may change, but shared understanding, mentorship, and technical rigor still need an explicit home.