When AI Writes the Code, Review Becomes the Real Job

The bottleneck has moved, and the data agrees

For most of software history, writing code was the expensive part and review was the tax you paid on it. AI coding tools have flipped that ratio. Faros AI's AI Productivity Paradox report found that developers on high-AI-adoption teams complete 21% more tasks and merge 98% more pull requests, but PR review time rises 91%. At the company level, the link between AI adoption and key performance metrics disappears.

A Harvard working paper by Fiona Chen and James Stratton, covering 718 firms and not yet peer-reviewed, points the same way. According to ComplexDiscovery's coverage, engineers added about 30% more code after their firms adopted AI coding agents, yet finished work did not measurably rise, and getting code through review took 49% longer.

Practitioners feel it too. In a live poll of 440 attendees at GOTO Copenhagen, half named reviewing changes as their biggest friction point in the delivery cycle, and the same article cites a Sonar survey in which 38% of developers said reviewing AI code takes more work than reviewing a colleague's. If your team has started using AI assistants and your PR queue keeps growing, you are not doing it wrong. You are seeing the expected result of making one stage faster without redesigning the next one.

What the Claude Code team actually does

Anthropic's Claude Code team is an extreme case: Claude writes roughly 90% of Claude Code's own codebase, according to a daily.dev summary of the team's post. The interesting part is that they did not abandon review. They restructured it so that no single step has to catch everything.

Their post, How the Claude Code team does code review, describes six layers of checks with rollback underneath: problems found during verification, required CI, AI review, security review, human approval, and a merge queue plus feature flags. A caption in the post says each layer catches some problems and misses others. That sentence is the whole philosophy, and it is worth printing out for any team that still treats one human approval as the final safety net.

The early layers happen before a human is ever asked to look. Before a pull request is opened, Claude runs the tests, build and linter, and a second agent reviews the diff. After approval, the merge queue re-runs checks against the latest main with the change applied. Changes then ship behind a flag, get used internally by Anthropic employees first, and go to a 'latest' channel before reaching 'stable'.

Anthropic reports that merged PRs to Claude Code more than doubled between June and September while the share of reverted PRs fell by more than 40%, and that daily changes landing in its wider monorepo grew from about 2,500 in May to more than 30,000 in September, per the daily.dev summary. These are self-reported figures from a company that sells the tooling, so treat them as a direction rather than a benchmark for your own team.

• Pre-PR: tests, build, linter, plus a second agent reviewing the diff
• Required CI on every PR
• AI review focused on finding real defects
• Security review
• Human approval, scaled by risk
• Merge queue re-checks on latest main, then feature flags, internal use, and staged release channels
• Fast rollback underneath all of it

Who decides: splitting work between agents and people

The most important design choice is not technical. In Anthropic's commercial version of this process, Code Review for Claude Code, a review never approves or blocks a PR, and the check run never ends as a failure. The merge decision stays with the team. Agents read and report; people decide.

The team's diagram also separates automated steps from decisions a person makes, scaled by risk, and notes that some code paths always need a person, according to the original post. That is a sensible default for any organization. Decide in advance which areas (authentication, billing, data deletion, infrastructure permissions) get a mandatory human reviewer regardless of how confident the tooling is, and write that list down.

The AI side is built to reduce noise rather than maximize findings. The automated review flags findings that multiple voting agents have verified, and the product runs in stages: several agents examine the diff in parallel, a verification step filters false positives, and findings are deduplicated and ranked by severity before being posted. Anthropic told InfoQ that internally the share of PRs receiving substantive review comments rose from 16% to 54%, that engineers marked fewer than 1% of findings as incorrect, and that a typical review takes about 20 minutes.

The size data from the same InfoQ report is useful for anyone setting review norms. On PRs with more than 1,000 changed lines, 84% got findings, averaging 7.5 issues. On PRs under 50 lines, 31% did, averaging 0.5. Small PRs were always good practice; with AI generating code, they become a way to keep review load proportional.

The problems they ran into

The post is more useful because it admits what went wrong. The daily.dev summary lists three problems. First, review loops that never converge: one PR went through more than 50 rounds. When an agent writes code and another agent critiques it, both can keep going indefinitely, and nobody gets tired enough to say 'good enough'.

Second, noise. The team measures it by how authors respond to review comments. That is a smart, cheap metric: if authors routinely dismiss or ignore comments, the reviewer (human or AI) is producing noise, regardless of how technically correct each comment is. Preview users of the commercial product said much the same, asking for reviews that were quieter, sized to each change, and faster. The response was per-repository Quick, Standard or Deep review levels, a default focus on correctness bugs rather than formatting or test coverage, and tuning through REVIEW.md and CLAUDE.md files.

Third, and most interesting for culture: codebase knowledge now spreads through Claude-generated explainers rather than line-by-line reading of diffs. Code review used to double as the main way engineers learned how a system worked. If people stop reading diffs closely, that learning has to happen somewhere else, or you end up with a team that ships fast and understands less every quarter. Anthropic's answer is generated explanations. Whether that is enough for your team depends on how much tacit knowledge lives in your codebase and how much turnover you have.

Ownership does not end at merge

One line in the Claude Code post deserves more attention than the agent architecture. Accountability continues after merge: the author and the on-call engineer watch the change, flags can be turned off quickly, and broken builds get reverted, as described in the original post.

This answers a question many leaders are quietly worried about: if an AI wrote the code and another AI reviewed it, who owns the outage? In this model, the person who opened the PR does. The tool is an instrument, not a co-author with its own accountability. I think that is the only workable position. Teams that let ownership blur ('the agent wrote it') will see review quality drop, because nobody reads carefully code they do not feel responsible for.

It also shifts where rigor lives. When you can turn a flag off in seconds and revert a bad build without drama, you can afford a lighter human review on low-risk changes. When rollback is slow, manual, or politically painful, every review has to be heavier, and the bottleneck gets worse. Investment in rollback is investment in review throughput, even though it rarely shows up in review metrics.

What smaller teams can copy without Anthropic's tooling

Most companies do not have a monorepo landing tens of thousands of changes a day, an internal user base to dogfood every feature, or a fleet of review agents. Many of the underlying ideas still transfer, and several cost very little.

There are lighter tools available. Anthropic's original code review GitHub Action, which it describes as less thorough and less expensive than the managed product, remains open source, and Claude Code ships a /security-review command equivalent to its open-source security review action. Deriv, for example, built an automated security reviewer on Claude Code GitHub Actions that scans every PR when it is opened, synced or reopened and posts a structured review with severity, CWE classification and a suggested fix before any human sees it. Anthropic's own help center is clear that such automated security reviews should complement, not replace existing security practices and manual review.

The cultural practices matter more than the tools, though. Here is what I would adopt first, roughly in order of effort.

• Require the author (or their AI assistant) to run tests, build and linter before a PR exists. Humans should never be the first to discover a failing build.
• Write down the list of code paths that always need a named human reviewer, and keep it short enough that people respect it.
• Put a cap on review rounds. If a PR passes three or four rounds without converging, stop and talk instead of commenting again.
• Track how authors respond to review comments as a noise signal, for both AI and human reviewers.
• Keep PRs small. The InfoQ data shows large PRs attract many more findings, and humans review small ones faster.
• Ship risky changes behind flags and practice reverting, so post-merge accountability is real rather than theoretical.
• Keep a short review-norms file in each repository describing what reviewers should focus on and what to ignore.

Where caution is warranted

The Anthropic numbers come from Anthropic, about Anthropic's product, on a team that builds the very tool doing the writing. That does not make them wrong, but it does mean you should run your own baseline before and after any change. The Harvard paper is a working paper, and survey data is mixed: LeadDev's 2026 survey, as cited by David R. Longnecker, found 29% of engineers said reviews now take longer, 24% reported time savings, and 47% saw no change.

Buying an AI reviewer is also not the same as using one. Coverage of the Harvard paper reports that nearly 80% of sampled firms had used an AI code review tool by March 2026, yet only 23.3% of review comments came from AI and only 10.8% of pull requests received any AI-generated comment. Tools that sit unconfigured do not move the bottleneck.

And the code itself may need more scrutiny, not less. The same Longnecker post cites a CodeRabbit analysis of 470 open source PRs that found an average of 10.83 issues in AI-coauthored PRs versus 6.45 in presumed human-only ones. If your team is in a regulated environment, lacks feature flag infrastructure, or cannot roll back quickly, do not copy the lighter human review parts of the Claude Code model. Copy the layering and the ownership rules, and keep humans in the loop more heavily until your safety net below merge is real.