How to Review AI-Written Code: Four Stages from Writing to Release

You can't read every line fast enough when an agent can produce thousands of them in minutes. Skipping review feels wrong, but reading only the “important” parts can miss a problem hiding somewhere ordinary. How should you review AI-generated code?

In an October 15, 2026 account, Addy Osmani, Morgan Westlee Lunt and Qing Wang described the Claude Code team's approach. The team reported that Claude wrote about 90% of Claude Code's own code. Its answer to the review problem reached beyond the diff: review and release were part of the same process.

First, Follow a Change All the Way to Release

Code goes toward a main branch, often called main or master. A pull request, or PR, proposes the merge; checks and the required reviews happen before it lands. Release follows the merge. That gives us four useful stages: before the PR, during the PR, at merge and after merge. This is a way to group the team's account, rather than a claim that its official process contains only four checks.

1. Before the PR: Self-Verification, Then a Fresh Reviewer

First, give the coding agent a way to verify the product. That might mean running the program, opening the webpage, taking a screenshot or interacting with the application. The important part is that it can check what it built, with output you can inspect.

Second, review the code's quality and fit with the architecture. Use a fresh agent for this pass. The author has its working assumptions in context; another agent can receive the goal and the diff without that whole history. It gets a separate view of the change, rather than simply asking the author to reassure itself that its approach was right.

2. During the PR: Four Parts of the Review

Group the work here into CI, AI review, security review and approval scaled by risk. Much of the checking is automated, while human sign-off and responsibility still have their place.

CI: Run the checks that don't need an AI judgment: lint, type checks, tests across platforms and a build. Put repeatable automatic checks into the pipeline.

AI review: Find issues, filter them and resolve what remains. The reviewer asks whether the change achieves its goal, fits the existing system and breaks something elsewhere. Rules filter out low-value style or cleanup comments. Remaining findings are tagged Important, Nit or Pre-existing. Each needs an answer: fix it, or close the thread with a reason. Open findings can block the PR.

Three ways to improve that review. First, test it against real bugs. The team turns incidents into evaluation cases built from the responsible PR and its fixes or reverts. The basic question is whether the reviewer finds the known issue: one for a find, zero for a miss is a simple way to express that baseline. When prompts, tools or models change, score the same cases again. That gives improvements something more concrete to stand on than “the comments looked sensible.”

Second, measure the noise. Finding more bugs isn't enough if developers spend their time sorting through low-value comments. The team groups responses into four categories: fixed, said to be wrong, intentional behavior and not worth changing. Those responses help measure the burden of review; an intentional behavior or a dismissed comment isn't automatically a proven false positive. They also run the reviewer on PRs regarded as clean and look for findings that could push someone toward a harmful edit. Tuning needs to account for that cost too.

Third, let the review finish. One PR in the team's account went through more than fifty rounds overnight. A reviewer can keep finding old issues, while the author can keep failing to fix what was meant. Their changes included four rules: after three rounds, step back and reconsider the approach; after the first few passes, review only the new diff; identify the whole class of a repeated bug at once; and don't repeat findings already posted. The team reported fewer review rounds after those changes.

Security review: Give security its own automated pass. Findings from the bug or security review must be addressed or closed with a reason before merging.

Risk-based approval: A copy edit and a billing change need different attention. In the reported policy, trusted authors can take a low-risk change through with automated and security checks green, subject to exceptions for sensitive paths and CI workflows. Medium-risk work—ordinary product changes, caching, the auto-updater or system prompts—needs one person; the highest-risk changes and designated paths need two. Authors outside the trusted list need a second person. An agent's approval cannot fill a human slot, and the person directing an agent-written change can count as a reviewer. Approval covers a particular commit; later changes that the system can't vouch for require approval again.

3. At Merge: Test against the Latest Main

A merge queue checks each waiting PR against the latest main branch with that change applied. Two PRs may pass separately and fail together; testing the combination can catch that before it lands and send the change back to its author. The queue helps protect main by testing what will actually be combined.

4. After Merge: Flags, Gradual Release and Rollback

Merged code still has to reach users. Three pieces matter here.

Feature flags: New behavior usually starts behind a flag enabled for Anthropic employees. Their daily use can surface problems before the feature is opened more broadly.

Gradual release: In the team's account, public versions go to latest first, with stable following later. That separates early exposure from the more conservative channel.

Observation and rollback: If a flagged feature causes trouble, turning off the flag can be the fastest response. If that isn't enough, a revert or rebuilt version can take the faulty change back out.

How Many Gates Does a Bug Have to Pass?

CI, AI review, security, risk-based approval, the merge queue, flags, staged release and rollback form successive defenses. None catches everything. Together, they give different kinds of mistakes more than one chance to be found or contained. Many checks can run automatically, but people still sign off on the change, notice failures and own the response. The aim is to spend less human attention on routine checking without simply moving that cost into incidents afterward.

The Five Jobs People Still Need to Do

Human attention goes to five jobs: decide what should be built, including direction, taste and scope; review risky changes, such as billing, the auto-updater and CI; review architecture, because a pattern can be copied throughout a codebase; read the evidence, from test output and executed commands to screenshots and the reviewer's findings; and own the outcome. An AI may write the code, but someone remains responsible for shipping it.

Keep Attention for the Decisions That Matter

This case challenges the idea that code is good simply because someone typed it by hand. As agents take on more implementation, the harder question becomes how to review the work and decide whether it is good enough to ship.

The team's reported result was more than a doubling of merged PRs from June to September 2026, while the share requiring reverts fell by more than 40%. That is its account of the period, not an isolated measurement of what AI alone caused.

The division of work is the point: agents carry out implementation and checks; people decide what is worth building, which architecture should guide it and who takes responsibility when it goes wrong. People steer the work, and agents execute it.

So the opening question reaches beyond a review technique. How do you spend a limited supply of human attention on the most consequential parts of the work? This process may keep changing as models improve. Its direction is useful to consider: automate what can be checked, and preserve people's time for the decisions that most need them.