When AI Writes and Reviews the Code - Ryan Rich

Anthropic now says Claude writes more than 80% of the code merged into its production codebase. That figure was in the low single digits when Claude Code launched in February 2025. Other agents increasingly handle the reviews, which means humans read far less of the output line by line than they once did.

Meanwhile, nearly every SOC 2 or ISO 27001 program still contains some version of the same sentence: “changes are reviewed and approved by a second qualified individual before deployment.”

The control language no longer describes the work.

The control that broke

For a decade, pull request approval has been the standard evidence for change management. One engineer opens a PR, another comments or clicks approve, and the platform records a tidy artifact with two names on it. Auditors like it because it is easy to read: there is a timestamp, an approver, and a clear before and after.

Now the artifact often records a ritual instead of a review. If an agent wrote the code and a fleet of agents reviewed it, the human “approval” is either missing or ceremonial. The control may still pass an audit, but it no longer means what everyone agreed it meant.

That leaves you with theater or a finding. Engineers rubber-stamp diffs they did not read so the evidence keeps appearing, or an auditor discovers midway through an engagement that the “second reviewer” has not actually reviewed anything in months. Theater corrodes the program from within. A finding usually leads to hurried, awkward remediation. It is better to redesign the control before either happens.

What code review was ever for

To replace the control, we need to be honest about what it did. Peer review bundled five jobs into one GitHub click:

Defect detection: catching bugs before they reach production.

Intent verification: confirming the change solves the right problem.

Independence: a second party with no authorship bias looking at the work.

Knowledge transfer: a second human who now understands the change.

Accountability: a name attached to the approval.

Defect detection, usually the first justification people offer, was always the weakest of the five. Humans skim large diffs. Anyone who has approved a 2,000-line PR knows they did not trace every branch. Review effectiveness drops sharply once a diff reaches a few hundred lines. Auditors did not accept PR approval because it caught bugs reliably. They accepted it because the approval gave them legible evidence of the other four functions, especially independence and accountability.

The question, then, is where those five functions live now. They still matter, but the diff is no longer where we should look for them.

Agents ate both sides of the review

Agents now write code and tests, while other agents review the pull request. Specialized tools scan for logic errors, security vulnerabilities, and regressions. They sort findings by severity and automatically merge changes that clear the required gates.

The economics explain why. Automated correctness checks became cheaper and better while human attention stayed fixed. Asking a senior engineer to read a 2,000-line, agent-written diff adds little assurance and consumes a scarce resource: senior judgment. Line-by-line review of machine output is an expensive way to catch very few bugs.

Review did not disappear. Verification of the work product became automated, and human attention moved to the decisions above the diff. Instead of asking whether the agent wrote the code correctly, people spend more time asking whether it is building the right thing under the right rules. Anthropic describes the change in similar terms: less attention on whether Claude did the work right, and more on whether Claude is doing the right work.

The independence problem nobody is naming

The obvious objection is that the same model writing and reviewing code amounts to one mind checking its own work. The writer and reviewer would share the same blind spots. That risk is real, but models are not deterministic. They do not produce the same kind of answer regardless of their instructions. “Ship this feature” and “find the flaw that gets this rolled back” create different work. The goal, context, scaffolding, and sampling all change, so the two runs can fail in different places.

What matters is how closely the writer’s and reviewer’s failures are correlated. You can reduce that correlation in three ways:

Give the roles different goals. The writer tries to make the change work; the reviewer tries to break it. The second pass should be adversarial, not polite.

Start the reviewer with a clean context. It should not inherit the writer’s rationalizations or the half-built mental model that produced the bug. Looking only at the diff and the spec helps it see mistakes the writer missed.

Use author-independent tooling. Property tests, contract tests, fuzzers, static analysis, and execution should sit outside the writing agent’s...