AI Code Review That Speeds You Up Instead of Doubling Your Reading

It's 9 a.m. Slack shows seven pull requests waiting for my review. I can't start my own work until they're done, because the team is waiting on me. Every PR already has an AI review. Sounds like help. In practice, I read the code, and then seven reports in seven different shapes.

By my own estimate, that kind of AI review made me 10–15% faster at best. Then I gave every PR one fixed report format, and my reviews got two to three times faster. In this article you'll see that format, why each part is there, and how I read a PR with it.

Code review is the new bottleneck

Before coding agents, I reviewed two to four PRs a day. Now it's five to nine, and the number keeps growing.

Anthropic just showed where this goes. In May 2026, its monorepo averaged around 2,500 merged changes a day. By September, it was over 30,000 a day: twelve times more in four months (Anthropic Engineering). Agents produce changes so fast that git itself became their bottleneck, and they replaced it with their own source control.

Changes merged per day in the Anthropic monorepo, January to September 2026: from under 1,000 a day to a peak of 30,401 on September 9. Source: Anthropic Engineering

Most teams are far from that scale. But the direction is the same for everyone: more changes than any human can read line by line.

You can't skip review. Without it, you lose control of your codebase, and your quality gate is gone. So you review everything, and there is much more of it than before. If review doesn't get faster, it becomes the main thing that slows your product down.

Why AI code review doesn't make you faster

Before AI, a careful review looked like this. Open the ticket. Read the description. Open the code in your IDE and click through the references. That is still the best review you can do. But at nine PRs a day, there's no time for it.

So you open the first PR and read the agent's report. The agent writes it free-form, so its shape depends on the PR and on the agent's mood that day. You kind of understand it. But a couple of details are unclear. What did it mean? Where is that in the code? And how far can you trust this PR? The report doesn't say.

So you read the whole code anyway. You check every comment the AI reviewer left, and you're not always sure what those mean either. One review takes as long as before. It only gets faster if you get lazy and skip checks.

The agent finds real things. But every report has a new shape, so every report is a new puzzle. That's where the 2–3x speedup you expected gets lost.

Agentic code review is the new CI

CI automates the checks you used to run by hand: tests, lint, build. Agentic code review automates the reading. The agent studies the business logic and how the system will behave after the merge. Then it returns a report of the decisions only a human can make: Was this change intended? Is it an accident? Is it a regression?

You stop digging through implementation details. You make business decisions instead.

Here is the case that sold me on this. One of my repos sends emails to real potential clients through automated workflows. A PR added a database migration. In the diff, it looked harmless. The reviewer read the migration and the worker code and traced what would happen after the merge: the outreach worker would send every client in the database one more email, an exact copy of the last one they got.

I would not have seen that in the code. I saw it because the report put it in front of me as a Blocker. You can revert a migration. You can't unsend an email.

The report: decisions first, details after

To get this, you don't need a new tool. The report format is one section of your review skill or prompt, and the agent reads the ticket linked in the PR to know what the PR should do. A good report answers six questions in its header, before any details:

• What should this PR do?
• Does it really do it?
• How well does it fit our requirements, standards and coding culture?
• How good are the tests?
• Where are the weak spots, and what could be simpler?
• What does the agent advise to fix, and how critical is each item?

A review report: the header with verdict, confidence, scores and issue counts is read in seconds; the detail sections below are read only where needed

This is what the header looked like for the email PR, shortened:

## Review: Migrate outreach history
 
**Verdict:** Request changes (the migration re-sends the last email to every lead)
 
**Confidence:** 🔴 1/5 (does what the task asks · one-way door: emails can't be unsent · blast radius: every lead in the database)
 
| Criterion       | Score  | Why                                                                        |
|-----------------|--------|----------------------------------------------------------------------------|
| Functionality   | 🟡 4/5 | The new history works for new leads.                                       |
| Regression risk | 🔴 1/5 | After the migration, the worker sends every lead a copy of its last email. |
| Architecture    | 🟢 5/5 | Follows the service layer and migration conventions.                       |
| Tests           | 🟡 3/5 | Cover the new table, not what the worker does with old rows.               |
| Consistency     | 🟢 5/5 | Matches the existing naming.                                               |
 
**Issues found:** Blocker 1 · Major 0 · Minor 2

Five seconds, and you know this PR must not be merged, why, and where to look.

Verdict and confidence

The verdict is the reviewer's advice: approve or request changes. Confidence is a score from 1 to 5:

• 🔴 1: must not merge. It misses the task, causes critical issues, or destroys data you can't restore.
• 🟢 5: focused, does what the task asks, risky parts verified, no new issues.

Confidence also weighs merge danger. Is the change a two-way door, where git revert undoes it? Or a one-way door: changed data, a new schema, anything sent outside? The idea comes from Jeff Bezos's 2015 letter to shareholders. Add the blast radius: how many rows, flows or users the change touches. A two-way door with a small blast radius needs a light look. A one-way door needs a hard one.

Scores with a reason

One score per area: functionality, regression risk, architecture, tests, consistency. Each has one or two sentences on why it isn't a 5. The score tells you how bad it is. The reason tells you where to look.

Issue counts

One line: Blocker · Major · Minor. You know the size of the problem before you read a single finding.

Details, only where needed

Below the header, the sections are always the same and always in the same order. What this PR does: for a feature, how it works; for a bug fix, what the bug was and whether the fix can cause new ones. Then every finding with its file and line, the fix, and what happens if you don't fix it. Then repo-specific risks and the tests: can they actually fail? (Three kinds of tests can't; see the FAQ.)

What was not verified

The last section I always read. It lists what the agent couldn't check but matters: a migration it didn't run, a real webhook response, call volume. These are exactly the things I check myself.

How I read a PR now

1. The header, all of it. It takes 5–7 seconds, because the shape never changes.
2. Confidence 5: a light look at the structure, and I approve.
3. Below 5: I go straight to the spots the agent flagged. Minors too: are they really minor, or underestimated?
4. Not verified: I check those myself. This list is what keeps a fast review honest.

I don't read the whole code anymore. I look at the overall structure and the flagged spots. And because every header shows the state of the PR, I choose the order: the hardest PRs first, or the clean ones first to unblock people quickly.

How I read a PR: header, then flagged spots, then the Not verified list

Keep the shape stable

Your brain learns one shape and then reads it without effort. Change the shape every week, and you're back to puzzles.

I changed my report seven or eight times. What you think matters and what matters after real mistakes are different things. The version in this article has stayed the same for the last few months, on every repo I work in.

Does the reviewer miss things? Rarely. I accept that, because most changes are two-way doors. If I merge a PR with a missed issue and it's easy to revert, nothing terrible happens. And the door is named in the header in plain words, so a wrong call there is easy to spot. Bezos makes the same point in that letter: a heavy process for reversible decisions only makes you slow. Fearing one mistake and spending twice the time on every PR is the worse deal.

One warning: don't copy my report blindly. It works for me and my team after we discussed it. Everyone has their own preferences, attention span and review culture. Adapt it once, then keep it stable.

The author reads the report first

In my team, the same reviewer runs on the author's local changes before the PR is opened. So the author gets the same report, in the same shape. A fixed shape helps the author as much as the reviewer: they see faster and more clearly what to fix before anyone else sees the PR.

Get the report format

The report format and a full example report are in the Agentic Code Review Blueprint. It also has the interview prompt that builds a review skill for your repo. The report is section 7 of that skill. I explained the skill in the previous article of this series.

👉 Get the Agentic Code Review Blueprint

Next in this series: the whole review process that saves my attention, from a readiness gate before the PR to a retro that turns repeated comments into rules.

FAQ

Should I auto-approve PRs with a high confidence score?

It depends on the project. On some projects it can work. On others, for example where a merge can change data or contact users, it never will.

Which tests does the report flag as useless?

Three kinds. Tests that restate the implementation, like expect(LIMIT).toBe(280). Tests that break on a rename or a reorder but not on a real bug. And tests that can't fail because the risky part is mocked away.

Does this work with Claude Code and Codex?

Yes. The format lives in a review skill in .agents/skills/, which every agent can read. Here is how to share one setup across Claude Code, Codex and Cursor.

Does the reviewer fix the issues itself?

No. It reports and advises; the author decides what to fix. The one exception is the author running it on their own changes before opening the PR. Then fixing right away is the point.

Where does the report go on GitHub?

One review per PR: the report is the review body, and each finding is an inline comment on its line. With the GitHub reviews API the agent posts both in one call, so you get the header first and the details next to the code.

What else should the reviewer check?

Beyond the scores, I ask it a few direct questions. Can we roll back safely, or is there a feature flag? Are there logs, metrics and alerts for the new path? Any N+1 queries or slow code on a hot path? Secrets or personal data in logs? A new dependency: license, maintenance, size? New env or config changes for the deploy? Scope creep or dead code? Edge cases, error handling, idempotency, concurrency?