📈 The number that started it 0:00
The video's opening statistic is the one everyone quotes, and it is accurate to the source article:
Two things make that number remarkable. First, Claude writes about 90% of Claude Code's own code, so this is a team reviewing machine output at machine speed. Second, they did not get there by removing review. They moved most of the reading to machines, optimised for human time and attention, and invested in making mistakes cheap to undo.
🔍 Why review became the bottleneck 0:45
The video's framing — agents call a task done, then you use what they built and find half of it missing — is the everyday version of the problem. In Anthropic's monorepo the structural version is blunter: changes landing per day went from about 2,500 in May to more than 30,000 in September. At that rate, line-by-line human review is not difficult, it is impossible.
What they changed first was the question. Instead of "did a human read the code?", they ask "what could go wrong with this change, and which check — automated or human — is the right one to catch it?" That reframing also changed when review happens: continuously, like spellcheck while you write, rather than as a gate at the end. By the time a person looks at a change, Claude has already reviewed and fixed it at least once.
🧱 Anthropic's seven layers 2:41
The article's central diagram is not one gate but a stack of layers, each catching what the previous missed, with rollback underneath all of them. This is the part the video compresses hardest, and it is the part worth understanding before copying any single piece of it.
| # | Layer | What it does |
|---|---|---|
| 1 | Verified before anyone looks | Claude runs something that proves the work (tests, build, screenshot against design) and shows the output instead of saying "done". A subagent then reviews the diff with fresh context. |
| 2 | AI review on every PR | Claude reads the diff against the whole repo and the PR's intent. Findings are verified by other agents, filtered, then posted as inline comments tagged Important, Nit or Pre-existing. |
| 3 | Blocking security review | A PR cannot merge while any bug or security finding is open; you fix it or close the thread with a reason. |
| 4 | Automated checks | Lint, type checks, tests on every platform, build — dozens of checks on a typical CLI PR. The PR template asks how it was tested and how to undo it. |
| 5 | Human approval, scaled by risk | Low: none required once automated checks are green. Medium: one person. High: two. |
| 6 | Merge queue, flags, staged release | Checks re-run against main with the change applied; new behaviour ships behind a flag internally first, then latest, then stable. |
| 7 | Fast detection and rollback | Flags turn off without a deploy; weekly on-call; every incident asks which layer should have caught it. |
✅ Layer 1: prove it, don't claim it 2:42
The most important habit, and the one the video builds its first skill around: give Claude something it can run, and ask it to show the output. Boris Cherny, who created Claude Code, has called this probably the most important thing for getting good results, estimating it makes the final result two to three times better: "Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator."
Anthropic's own pre-PR habits: give Claude tests, a build or a design to compare against; have a subagent review the diff with fresh context; run internal skills that hunt bugs, simplify the diff and check behaviour end to end; check UI changes against design guidelines.
Two instructional files do the load-bearing work, and they are different jobs. CLAUDE.md tells Claude what the project is — stack, conventions, goals and non-goals — and stays short, pointing at deeper docs. REVIEW.md is written by code owners and tells the reviewer what matters in their part of the code. The good ones "say what failure looks like in that repo (for docs it's 'it lies', for config it's 'it misroutes'), cap the nits, list paths to skip, and ask for a file and line as evidence instead of a guess from a name."
🤖 Layers 2–3: AI review that can block 5:42
Every PR gets a Claude review before a person sees it. The public product is Code Review for Claude Code, generally available on Team and Enterprise plans, and /code-review runs a lighter version locally — which is what most people can actually use today, and what the video demonstrates.
The numbers behind the claim that this works: when Anthropic launched the research preview, the share of internal PRs receiving substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings; most small ones come back clean. Repos are set to Quick, Standard or Deep, and Deep is worth it where one missed bug costs more than the extra review time.
- Findings are verified before they reach a human. Several agents look for bugs in parallel; a separate group votes on each finding, and it is only posted if enough agree it is real.
- Style, diagnostics and cleanup findings are dropped — filters A/B tested on Anthropic's own PRs.
- Every finding must be answered: fix it, or resolve the thread with a reason. Often an agent picks up the fix overnight.
- Security can block. Nothing merges while a bug or security finding is open; the open-source equivalent is the security-review GitHub Action or
/security-review.
/code-review plus your rules — which is still useful, but it is the lighter version, and the video says so rather than implying everyone gets the enterprise product.
📝 REVIEW.md, and the local bridge 6:27
Anthropic's reviewer reads REVIEW.md because it is built to. The video's practical observation is that in a local Claude Code session the file is not loaded by default, so it recommends putting the rules in their own file and linking that file from CLAUDE.md, so every session — including the one where you run /code-review — reads them.
That specific mechanics claim is the creator's own finding rather than something the article states; it is a sensible workaround and easy to verify in your own setup, so treat it as advice, not as documentation.
| What belongs in REVIEW.md, according to Anthropic |
|---|
| What failure looks like in this repo — "it lies" for docs, "it misroutes" for config |
| A cap on nits, so the reviewer stops producing noise |
| Paths to skip entirely |
| Evidence requirements: a file and line, not a guess from a symbol name |
| A summary that starts with a count, and says plainly when there is nothing to fix |
The article adds a detail that turns REVIEW.md from documentation into a feedback loop: they check separately whether the reviewer actually follows it. A rules file nobody measures is a wish.
🔁 The loop: builder, verifier, reviewer 7:21
The video's main construction — and its clearest original contribution — is a review loop implemented as a Claude Code skill: an orchestrator (the main agent) runs three subagents, each in a fresh context window, so they cannot simply agree with the builder's reasoning.
| Role | Job | Why it must be separate |
|---|---|---|
| Builder | Builds the feature from the requirements document the eval skill wrote | It is the one that will rationalise its own choices |
| Verifier | Checks the app against the evals and marks each pass or fail | Mechanical, evidence-based — the evals are the contract |
| Reviewer | Looks for what the evals missed, using the rules in REVIEW.md | Fresh context means it reads the code as a stranger |
| Orchestrator | Runs the rounds, keeps state.md with the round number and what is still failing, asks you when it hits a decision it cannot make | The loop needs a memory and a stop condition |
The rationale the video gives for the separate reviewer is the same one Anthropic's article gives in different words: an agent that made every decision in a change tends to agree with itself. The loop stops when all evals pass and the review finds nothing new.
🛑 Making the loop converge 11:40
This is the most valuable section of the video, because it is the part everyone building these loops gets wrong. An agent author and an agent reviewer can keep each other busy indefinitely: one CLI pull request went through more than fifty rounds overnight before its author stopped it. When the team ran git blame on what the reviewer kept flagging, about 59% of it was code that had been there since the reviewer's first pass — it was not finding new bugs each round, it was finding the same old ones more slowly.
Anthropic's fix is three rules, and the video reproduces them accurately:
- A round cap. After three rounds the reviewer stops listing findings and asks the author to step back and reconsider the approach.
- Diff-only re-review after the first few passes, and no repeats of findings already posted.
- Flag the class of bug, so the author fixes every instance rather than the one line the reviewer found.
The video adapts rather than copies: its own loop is capped at five rounds, because each of its rounds does more work (build, verify every eval in the browser, then review the code), and it stops early if the same problem survives two rounds of fixes. They also note the practical sting — every round spends your plan's limits.
🧠 Learned rules: fix it at the source 9:55
When the reviewer keeps flagging the same thing, Anthropic does not fix the instance — it fixes the instruction: in the skill, in a lint rule, or in CLAUDE.md / REVIEW.md. That is the difference between a review loop that converges and one that re-litigates the same mistake every session.
The video implements this as a "rules learned over time" section at the bottom of REVIEW.md: when a review misses a bug that later shows up, a rule goes in; when a review keeps flagging something that turns out not to be a real problem, a rule goes in too. The loop matches a repeated problem to the earlier round and suggests a one-line rule, only adding it with your approval. The human-approval step is the important half — an unreviewed rule file is just prompt drift with extra steps.
⚖️ Risk tiers and who approves 10:41
Anthropic's rule is that the change sets the tier, not the author. A classifier reads the change and picks its risk tier; a second classifier asks whether this particular change needs another person even when its tier says it does not.
| Risk | Examples | Human approvals |
|---|---|---|
| Low | Docs, copy, internal-only features, additive changes behind a flag | None, once automated review and security checks are green |
| Medium | Ordinary product changes; sensitive areas like caching, the auto-updater, system prompts | One person |
| High | Highest-risk code, plus paths that always need two people (CI workflows, auth, billing, installers) | Two people |
- Trusted authors get the lighter paths — mostly the team that owns the repo. Everyone else needs a second person.
- An agent's approval never counts as a person's. Automated review can clear a low-risk change, but it cannot fill a slot that calls for a human.
- Whoever prompted the change is a required reviewer — the same as if they had typed the code.
- An approval covers one commit. New commits the system cannot vouch for (an agent push, a hand-resolved merge) require approval again.
The video replaces the classifier with a single question anyone can answer before building: what happens to a customer if this feature breaks? Cosmetic damage is low; broken but recoverable is medium; lost money, locked-out accounts or exposed data is high, and gets stricter evals. It is a good teaching simplification — just don't mistake it for Anthropic's mechanism, which is automated, per-change, and has a second classifier on top.
🚪 What still gets through 13:19
Both sources agree that some mistakes will pass every layer, so the last layer is about catching them fast rather than pretending they won't happen. Anthropic's version: flags turn off without a deploy, there is a weekly on-call rotation, and every incident review asks which layer should have caught this. They also admit what they do not have yet — circuit breakers that tighten approval when revert or incident rates move.
The video's addition is a first-time-user agent: a subagent that never saw the app being built, blocked from reading the source code (with a hook that also blocks the terminal workaround), using the live app against a temporary database, reporting everywhere a new user could get stuck. It is a sensible analogue of Anthropic's "use the product yourself every day" — and it fixes the obvious flaw in that advice, which is that you already know how the feature works.
For undo, both point at the same thing: small changes, feature flags, staged releases and one-step rollback. The video's version is a branch per feature plus a "fix a bug" skill that reproduces the bug, checks whether its guess about the cause was right, then fixes it. Anthropic's version is a merge queue, internal-first release and revert culture — plus the norm that makes it work: you land it, you own it.
👤 Where humans stay in the loop
If machines do most of the reading, what is left for people? Anthropic's list is short and worth memorising:
- Deciding whether to build it. Direction, taste and scope — "should we even do this?"
- Reviewing risky code: billing, the auto-updater, CI workflows.
- Reviewing architecture that sets a pattern others will copy.
- Reading the evidence. Test output, the command that ran and what it returned, a screenshot, the reviewer's findings. If you cannot say what the checks would miss, ask for a real review rather than a quick approval.
- Owning the outcome. A person is accountable for every change that ships, whoever typed it.
The article also addresses the second job of code review — spreading understanding — with unusual honesty: nobody on the team keeps a complete mental model of Claude Code, and they don't think anyone needs to. When someone wants to understand a slice of the codebase, they ask Claude to write an explainer for exactly that slice, or to build a small artefact that visualises it. A one-line copy change teaches you almost nothing; an explainer for the module you are about to change teaches you a lot.
🛠 What to adopt on Monday
Anthropic's own adoption list, condensed — most of it does not require the enterprise product:
| Stage | Do this |
|---|---|
| Before the PR | Give the agent checks it can run, listed in a short CLAUDE.md, plus hooks that run formatters and linters. Run /code-review and /security-review locally, or a fresh-context subagent review. Add REVIEW.md and move repeated comments into it. |
| On every PR | Require CI. Add "Testing", "Risk" and "How to revert" to the PR template. Add an AI reviewer on one repo, tune REVIEW.md for a few weeks, then widen. Require every review thread resolved before merge. |
| Approval | Write down risk tiers, set from the change not the author; start strict and loosen with evidence. Use CODEOWNERS and branch protection so auth, billing, CI, release workflows and installers always need a person. Never let a bot's approval replace a required human; dismiss approvals on new commits. |
| Merge and after | Merge queue, feature flags, internal use first, staged releases, one-step rollback. Turn incidents and reverts into an eval set. Measure human time with revert and incident rates as the guardrail. |
If you only do one thing, do the smallest version of layer 1: stop accepting "done" without an artefact — a test run, a build, a screenshot — that you can look at. Every other layer assumes that habit exists.
✅ Claims checked
| Claim in the video | Verdict | Evidence |
|---|---|---|
| "More than twice as many changes, and the share they had to undo dropped by over 40%" | Verified | Article: June–September, merged PRs to Claude Code's repo "more than doubled" while the reverted share "fell by more than 40 percent" |
| Changes to review went from ~2,500 to 30,000+ in four months | Verified | Article: 2,500/day in May → 30,000+/day in September (Anthropic's monorepo) |
| Claude writes about 90% of Claude Code's code | Verified (article, not video) | Article opening line |
| Boris Cherny says giving Claude a way to verify its work is the most important thing | Verified | Quoted in the article, including the 2–3× estimate |
The full review agent is Team/Enterprise only; the lighter /code-review runs locally | Verified | Article: "Code Review for Claude Code… generally available on Team and Enterprise plans, and /code-review runs a lighter version locally" |
| Substantive review comments rose sharply after the research preview | Verified (article) | 16% → 54% of internal PRs with substantive comments |
| One change went 50+ rounds overnight; ~59% of flagged code predated the first pass | Verified | Article: "more than fifty rounds… overnight"; "about 59%" since the reviewer's first pass |
| Three convergence rules: round cap, diff-only re-review, flag the class of bug | Verified | Article's "Review has to converge" section |
| Risk tiers: none / one / two human approvals | Verified | Article's risk table |
| Anthropic added the three rules because of complaints about token limits | Creator's inference | The article attributes it to noise, convergence and over-use of default multi-round review — not to token budgets |
REVIEW.md is not read by default; link it from CLAUDE.md | Creator's finding | Not stated in the article; plausible for local /code-review and easy to confirm in your own repo |
| Risk triage by asking "what happens to a customer if this breaks?" | Creator's adaptation | Anthropic uses automated classifiers per change; the question is a teaching simplification |
Builder / verifier / reviewer loop with fresh contexts, state.md, five-round cap | Creator's construction | The orchestrator design is the video's own; the convergence rules it borrows are Anthropic's |
| First-time-user agent blocked from reading the code | Creator's construction | Not in the article; a fair analogue of Anthropic's "use the product yourself every day" |
| The skills shown are available in AI Labs Pro | Paid self-promo | The channel's own community — flagged, and not linked here |
Transcript notes. The auto-captions mangle several names, corrected here against the article: "Boris Churnney" → Boris Cherny, "AIBS Pro" → AI Labs Pro, "clawed code"/"cloud code" → Claude Code, "sub aents" → subagents, "RD.md" → the per-feature requirements document. The video's chapter markers stop at 9:55 in the description although the process continues to 15:58.
🔑 Key takeaways
- The headline result is real and narrow: merged PRs to Claude Code's repo more than doubled between June and September while the reverted share fell by over 40% — with review moved to machines, not removed.
- The reframing is the actual innovation. "Did a human read the code?" became "what could go wrong, and which check catches it?" — which is why review now runs continuously instead of as a gate at the end.
- Seven layers, not one gate: pre-PR verification, AI review, blocking security review, CI, risk-scaled human approval, merge queue and flags, fast rollback. Copying one layer in isolation copies the weakest part.
- Verification is the highest-leverage habit. Give the agent something to run — tests, a build, a screenshot — and make it show the output instead of saying "done".
- REVIEW.md is where review policy lives, and the good ones are short: what failure looks like in that repo, a nit cap, skipped paths, file-and-line evidence, and a summary that starts with a count.
- AI review is now measured like a product: 16% → 54% of internal PRs getting substantive comments, findings voted on by other agents, noise tracked by how authors respond to each comment.
- Loops must converge. Fifty rounds overnight and 59% of flagged code predating the first pass is the failure mode; a round cap, diff-only re-review and class-level bug flags are the fix.
- Risk sets the human cost, not the author: none / one / two approvals, a classifier picks the tier, a second classifier asks whether this change needs a person anyway, and an agent's approval never counts as a human's.
- Whoever prompted the change owns it — "you land it, you own it" — and an approval covers exactly one commit.
- Some bugs will always land. The last layer is fast detection and one-step rollback — flags, staged releases, weekly on-call, and every incident asking which layer should have caught it.
🔗 Resources & links
The source
- How the Claude Code team does code review — Addy Osmani, Morgan Westlee Lunt, Qing Wang, 15 October 2026, 14 min. The article this video is built on, and the better read.
- Building agents: when to fold subagents into your main agent loop — relevant if you build the loop: fewer agents, more skills, and evals with ten golden examples
Claude Code review features referenced
/code-review(local, lighter) and/security-reviewin Claude Code; Code Review for Claude Code on Team and Enterprise plans- Automated security review: the security-review GitHub Action, and the docs on setting it up
- Claude Code documentation —
CLAUDE.md, hooks, skills and subagents