Claude Code Is 90% AI-Written. Here's the 7-Layer Code Review System That Keeps It From Collapsing

Anthropic says Claude writes about 90% of Claude Code's own code. From June to September, merged PRs more than doubled and reverts fell by over 40%.

Your first instinct is probably "sure." Mine too. But the write-up on how the team does code review hit the top of Hacker News for a reason: it's the first detailed look at what AI-generated code review at scale actually looks like. And some of it is genuinely good engineering.

Let's go through it, steal what works, and poke at what doesn't.

The core idea: stop asking "did a human read this?"

The old question was did a human read the diff? The new one is which check catches what could go wrong?

Review stops being a gate at PR time and becomes continuous, like a spellchecker running while you type. Humans are not removed. They're moved to where they add the most value.

The 7 layers

1. Pre-PR verification. The agent runs tests, build, and linters before opening a PR. A second agent reviews the diff in fresh context.
2. AI review on every PR. Multiple agents hunt for bugs in parallel, and a voting system confirms findings before anything is posted. Style nits and diagnostic-only comments are filtered. Findings are sorted: Important, Nit, Pre-existing.
3. Separate security review. Open findings block merge until fixed or dismissed with a written reason.
4. Automated checks. Lint, types, cross-platform tests, build. The PR template forces you to write how you tested and how to roll back.
5. Human approval scaled by risk. More below.
6. Merge queue. Re-runs everything against main with your change applied. New behavior ships behind flags to employees first, and the stable channel trails latest.
7. Fast rollback. Flags flip without a deploy. A weekly on-call rotation watches. Every incident review asks: which layer should have caught this?

That last question is the one to steal first.

Risk-tiered approvals (the best part)

Risk	Examples	Human approvals
Low	Docs, copy, internal features, additive flagged changes	None, if checks are green
Medium	Standard product changes, sensitive areas (caching, auto-updater, prompts)	One
High	Designated sensitive paths	Two

The rules around it matter more than the table:

• A classifier sets the tier, not the author. Authors lowball their own risk. Everyone does.
• Lighter paths are only for trusted authors.
• Agent approvals never count as human approvals.
• Whoever directs an agent counts as a required reviewer.
• An approval covers one specific commit. Push again and it's gone.

If you do nothing else, copy this. It's a CODEOWNERS file plus a branch protection rule plus a tiny classifier. A weekend of work.

CLAUDE.md and REVIEW.md

Two files do a lot of the lifting:

• CLAUDE.md: stack, conventions, goals and non-goals. The reviewer flags code that breaks conventions and docs that went stale.
• REVIEW.md: written by code owners, per area. The effective ones are short, define what "failure" means, list paths to skip, and demand specific file and line evidence instead of vibes.

A starter you can adapt:

# REVIEW.md (payments/)

## What a failure looks like
- Any code path that can charge a customer twice
- Missing idempotency key on retries
- Float math on money

## Skip
- generated/**, *.snap, migrations that only add nullable columns

## Reporting rules
- Cite file:line for every finding. No evidence, no comment.
- Do not repeat a finding already posted on this PR.

When a reviewer leaves the same comment three times, move it into REVIEW.md. That's the whole workflow.

The bug nobody warns you about: infinite review loops

When both author and reviewer are agents, they can ping-pong forever. One CLI PR went 50+ rounds overnight. The team found that 59% of repeated findings came from the original pass, not from new bugs. The reviewer just kept re-raising old stuff.

Fixes they shipped:

• After three rounds, the reviewer must ask the author to reconsider the approach.
• After the first passes, review only the new diff.
• Flag the class of bug so the author fixes every instance, not one line.
• Never repeat a finding already posted.

The numbers they report:

Metric	Before	After
PRs passing after one review/fix cycle	65%	78%
PRs needing 5+ rounds	8.9%	1.5%
Mean reviews to pass	2.08	1.32

If you run any bot reviewer, add a round cap today. It's five lines of config and it saves you tokens and sanity.

They treat the reviewer like a model you evaluate

This is the most underrated part. The team built an eval set from past incidents and reverts. Engineers confirm the real bug and where it lives. Every change to the reviewer (prompt, tools, model) is scored against the whole set, daily.

They also track what happens to comments: fixed, dismissed as wrong, flagged as intentional, or ignored. And they run the reviewer on known-clean PRs to measure false positives.

Most teams bolt an AI reviewer on, watch it get noisy, and mute it. Treat it like a classifier with a test set instead.

Where I think it gets shaky

The HN thread was not a victory lap, and the skepticism is fair:

• Security review dismissal. The process lets you close a finding "with a short reason." One commenter noted that dismissing a critical finding shouldn't skip AppSec. Worse, the open-source claude-code-security-review action says in its README that it is not hardened against prompt injection. A control that an attacker can talk out of firing is a weak control.
• Reverts down is not quality up. You can cut reverts while shipping more subtle vulnerabilities or UX churn. Several commenters pointed at constantly shifting UI and long-lived janky bugs as counter-evidence. Anecdotal, but it's the right question: what's the metric that would show the system failing?
• "You land it, you own it" works because changes are small, flagged, and reversible, with fast telemetry. That's a property of their setup, not a free lunch. A team shipping a mobile app with two-week release trains can't copy it as is.
• Line-by-line review still finds things. Plenty of people said they still catch duplicated code and overcomplicated architecture only by reading diffs. Honest tradeoff: those smells don't show up as reverts, they show up as a codebase nobody wants to touch in a year.

What to do this week

1. Write a short CLAUDE.md with the commands to build, test, lint. Make "run these before opening a PR" the default.
2. Add a REVIEW.md to your riskiest directory.
3. Define 3 risk tiers using paths, via CODEOWNERS. Don't let authors self-select.
4. Cap bot review rounds at three. Re-review diffs only.
5. After your next incident, ask "which layer should have caught this?" and add the case to an eval set.
6. Never let a bot approval satisfy a required human approval.

The takeaway

The interesting claim isn't "AI writes 90% of the code." It's that review is a system with layers, owners, and metrics, not a person reading a diff. Whether or not you let agents write your code, that framing is correct, and most teams are still running review as a vibe.

Source: How the Claude Code team does code review and the Hacker News discussion.

What does your team do when the author and the reviewer are both bots? Tell me in the comments.

Comments

[Sammi De Blas]

The fresh-context second reviewer is the part I would copy first: an in-context reviewer anchors on the author framing, and when the code is AI-written that framing is itself generated, so you are double-voting with the same model family. The weaker link in parallel-agent voting is correlation - N agents from one base model share blind spots, so a 3-1 vote can be three copies of the same miss; mixing at least one different model family into the quorum buys independence that raw vote count never does.