🏁 Review at agent volume 0:00
The setup: we talk constantly about building with agents and almost never about the communication around them — how a team reviews code, decides what merges, and manages a load that agents made trivial to produce.
Two data points establish the scale. Anthropic's Claude Code team reportedly can no longer use ordinary Git and GitHub workflows for part of their process because they slow things down. Theo's own team gets as many as 800 pull requests filed in a day against T3 Code, with three people.
The source is Anthropic's own write-up — "How the Claude Code team does code review" by Addy Osmani, Morgan Westlee Lunt and Qing Wang, published 15 October 2026. Theo reads it live for the first time, which is why the video is a genuine reaction rather than a summary.
📊 The numbers that frame it 3:20
| Metric | Anthropic's figure |
|---|---|
| Share of Claude Code written by Claude | ~90% (the article's own caveat: "about 90 percent") |
| Changes landing per day in Anthropic's monorepo | ~2,500 in May → more than 30,000 in September |
| Merged PRs to Claude Code's repo, June → September | More than doubled |
| Share of merged PRs that had to be reverted | Fell by more than 40% |
🎯 "Did a human read it" is a bad proxy 6:43
The article's central argument: "did a human read the code?" is an imprecise proxy for the real question — what could go wrong with this change, and which check, automated or human, is the right one to catch it?
His supporting example is the best possible one: a bug in LLVM that broke safe Rust for ten years, in one of the most carefully read codebases in the world, reviewed by the smartest engineers available.
The practical consequence is that review moved earlier: from a gate at the end to something closer to spellcheck while you write. Most changes are reviewed and fixed by Claude at least once before a human is asked to look.
⏳ Time, attention, and energy 9:08
Anthropic's framing: human time and attention are the scarce resource, so preserve them for the problems only humans can solve while automated checks catch the rest. Human time covers both sides of the cost — reviewing, and fixing what bad code breaks. Cutting the first doesn't help if the time reappears in the second.
Theo adds a distinction the article does not make: energy is not time. Some tasks cost more energy than time, and keeping humans away from work that feels "painful and slow and miserable" is a separate optimisation from keeping them away from work that takes minutes.
| Cost | What it looks like | Reduced by |
|---|---|---|
| Review time | Reading a diff closely | Agents filtering before a human is asked |
| Repair time | Fixing what bad code broke | Higher recall, faster rollback |
| Waiting time | Author waits → reviewer waits → author pushes → reviewer waits again | The real bottleneck, in his view: more of the cycle is spent in the gaps than the work |
| Human energy | Draining, tedious verification | Moving the misery to a machine |
The stated goal is precise and worth copying as a metric: most PRs should merge with at most one human in the loop — who can be the author — with no increase in reverts or incidents. Measured by human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Revert and incident rates are the guardrail: if they rise, the time was not saved, it was moved.
🧱 The life of a change 11:14
Six layers, then recovery underneath them. The design intent is that no single gate has to be perfect.
| Stage | What runs | Blocks merge? |
|---|---|---|
| Before the PR | Claude runs tests, build, linter; a second agent reviews the diff in fresh context | No — but it removes routine faults |
| Required CI | Lint, types, tests across platforms, build and packaging | Yes, red blocks |
| Claude code review | Parallel bug hunters, verifier agents voting on findings, survivors ranked by severity | Findings must be answered |
| Security review | A separate pass for security issues | Open findings from either review block |
| Risk-based approval | A classifier picks the tier: no person, one, or two | Depends on tier |
| Merge queue | Checks re-run on latest main with the change applied | Yes |
| After merge | Behind a flag, internal first, gradual release, watch → fix forward or roll back | Recovery |
✅ Before the PR: verification 15:34
"Most review now happens before a PR exists." Give Claude something it can run — tests, a build, a screenshot to compare against the design — and ask it to show the output instead of saying it's done. Then a subagent reviews the diff with fresh context. Both habits come from Anthropic's published best-practices guide, and before opening a PR many engineers run internal skills: one hunts for bugs, one simplifies the diff, one checks behaviour end to end. UI changes are checked against design guidelines.
Boris Cherny, who created Claude Code, is quoted calling this probably the most important thing for good results — with an estimate that it makes the final result two to three times better.
What he actually built for T3 OS: each thread gets its own desktop workspace, so an agent can spin up the Electron dev server, record a video of the change working, and attach it to the PR. During development, fake model selections with pre-baked events let an agent run a full end-to-end test without burning tokens beyond the visualisation.
🔧 Fix at the source, in that order 17:36
This is the section where the video stops summarising and starts arguing, and it is the most useful disagreement in it. Anthropic documents three guidance files: CLAUDE.md (stack, conventions, goals and non-goals), REVIEW.md (written by code owners: what matters in their part of the tree, what failure looks like — "for docs it's it lies, for config it's it misroutes", a cap on nits, paths to skip), and the skill files.
| Layer | Fix | When |
|---|---|---|
| 1. The codebase | Improve the architecture so the mistake is harder to make — not by spraying comments | Always first |
| 2. Static analysis | Linters, type checks, rules that fail the build | Second |
| 3. Prose | CLAUDE.md, REVIEW.md, skills | Only after the first two failed |
His framing of the ideal codebase: a brilliant engineer who has worked in thousands of codebases but never in yours, who does not care about status and will do tedious work all day without complaining. If you had already set your repo up for a new teammate, this transition should be easy.
🤖 AI review on every PR 19:17
Each PR gets a Claude review before a person looks. It reads the diff against the whole repo and the PR's stated intent, and asks whether the change solves the problem, fits the system, or breaks something else. On a bug fix it looks for the root cause.
| Mechanism | Detail |
|---|---|
| Multiple finders | Several agents hunt for bugs in parallel |
| Verifiers vote | A separate group votes on each finding; only findings with enough agreement are posted |
| Style filtered out | Findings about style, diagnostics or cleanup are dropped |
| Filters are tested | They A/B-tested these filters on their own PRs before keeping them |
| Severity tags | important, nit, or pre-existing — so a bug the PR didn't introduce isn't blamed on the author |
| Must be answered | Every surviving finding is fixed or resolved with a reason; often an agent picks it up overnight |
| Effort levels | Admins set each repo to Quick, Standard or Deep; Deep pays off where one missed bug costs more than the review time |
| Adoption signal | At the research preview, the share of internal PRs getting substantive review comments went from 16% to 54% |
💸 Why he won't tell you to buy it 20:04
The public product (Code Review for Claude Code) is generally available on Team and Enterprise plans; /code-review runs a lighter version locally. Theo's stance is blunt and, to his credit, against his own commercial interest in being agreeable: it is "way, way, way too expensive for most real-world cases", especially at the shipping rate the same article recommends.
His substitute is a council of models: his code gets reviewed by three models from three different families, running locally on his own subscription, and he reports it matching or beating the packaged product — with the decisive advantage that it runs on a real computer and can spin the code up to check.
🔒 Security review that blocks 22:42
Security gets its own automated pass, and a PR cannot merge while any finding from the bug review or the security review is still open. Findings are cleared by fixing them, or by closing the thread with a short reason — which is also how false positives are dismissed. If a later commit fixes the issue, the finding clears itself.
The same pattern is reproducible outside Anthropic with open-source security review actions, or a /security-review command.
🎚 Risk tiers and trusted authors 23:17
| Tier | Human requirement |
|---|---|
| Low | None — merge when green |
| Medium | One person looks |
| High | At least two people |
| Always | Anything owners listed as sensitive, and any CI workflow file |
Three rules do the real work, and all three are about not letting automation launder responsibility:
- The change sets the tier, not the author. A classifier reads the change; a second classifier asks whether this particular change needs another person even when its tier says it doesn't.
- Only trusted authors get the light paths — mostly the team that owns the repo. Everyone else needs a second approver.
- An agent's approval never counts as a person's. Automated review can clear a low-risk change; it cannot fill a slot that calls for a human.
Two more details worth copying: approvals only cover specific commits, so a new agent push or a hand-resolved merge invalidates the approval and restarts it. And whoever prompted the change is on the hook — "you can't blame the agent if you prompted it."
🔬 Incidents become evals 26:24
The team's improvement loop for the reviewer itself:
| Practice | How it works |
|---|---|
| Any incident becomes an eval | Past PRs that caused incidents (with their fix-forwards and reverts) are collected; engineers who know the code confirm each bug and where it lived; the reviewer runs against that set daily |
| Noise is measured by behaviour | Every reviewer comment is categorised by what the author did: fixed it, said it was wrong, said the behaviour was intentional, or ignored it |
| False-positive probes | The reviewer also runs on PRs known to be clean, counting how often it suggests a harmful change |
| Stated priority | Catching real bugs first, cutting reviewer rounds second |
🌀 The convergence crisis 27:42
The most valuable section of the article, and the one most teams will hit: an agent author and an agent reviewer can keep each other busy forever. Anthropic reports one CLI PR that went through more than fifty rounds of review and fixes overnight before the author stopped it.
Then the diagnostic that makes it concrete: when they 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. The reviewer was not finding new bugs; it was finding a few more old ones each round. They had made it worse themselves by getting used to running several rounds by default.
| Fix | Effect |
|---|---|
| Round cap: after three rounds the reviewer asks the author to step back and reconsider the approach | Breaks the loop at the point where iteration stops being useful |
| Diff-only re-review after the first few passes | Stops re-reading the whole thing |
| Flag the class of bug, not the line | Author fixes every instance instead of the one it found |
| Never repeat a finding already posted | Removes the loop's favourite move |
| Nightly review of existing code | Finds old bugs on a schedule instead of inside a PR |
The results, on internal PRs before and after the convergence work:
| Metric | Before | After |
|---|---|---|
| Pass after one review-and-fix round | 65% | 78% |
| Need five or more rounds | 8.9% | 1.5% |
| Mean reviews to pass | 2.08 | 1.32 |
🧑⚖️ Where humans stay 30:30
| Human job | Why it can't be automated away |
|---|---|
| Deciding whether the thing is worth building | Direction, taste and scope |
| Reviewing risky code | Billing, auto-updater, CI workflows |
| Reviewing architecture | It sets patterns that others copy |
| Reading the evidence | Test output, commands that ran, what they returned, screenshots, findings |
| Owning the outcome | Whoever opened the PR owns it, regardless of who wrote the code |
| Outside changes | One team that declared its review bottleneck solved still keeps human review for changes from outside the team — "should we even do this?" |
And the test he offers for when to demand a real review: if you can't say what the checks would miss, ask for a real review rather than a quick approval.
🧠 Sharing context without reading diffs 32:00
Review's second job — building shared understanding — is the one this process quietly breaks, and Anthropic says plainly that they have no formal replacement. Nobody on the team keeps a complete mental model of Claude Code in their head.
The substitute they use: ask Claude to write an explainer for exactly the slice you need, minutes-long and reflecting the code as it stands now. Some engineers have it build a visual artefact that teaches the module the way that particular person learns. Theo's version: paste the PR into T3 Code and ask what is changing, why, and where the risk is.
🙋 "You land it, you own it" 34:41
If you land a small or medium change and something still goes wrong, the norm is that you fix it. Five things keep that from being punishing:
- Changes are small, so they are easy to review, debug and revert.
- Everything is reversible — flags turn off without a deploy.
- Blast radius sets the bar — expensive code gets more people and more checks.
- Regressions surface fast through telemetry and internal use.
- Ownership is not blame. It means you have the best understanding, so you are the right person to fix it.
And on changing direction: agents make starting cheap, so some work shouldn't land at all. Since code is fast to write, closing a PR doesn't feel like a loss. The trick is to raise a different direction in the thread early, not as a blocking comment on a finished PR.
🧾 The adoption checklist 35:55
| Phase | Do this |
|---|---|
| Before the PR | Give the agent checks it can run and ways to verify its work; run review and security skills locally; fix the code first; then tune REVIEW.md for the comments that keep repeating |
| Every PR | Require CI; put how-to-test, risk, and how-to-undo into the PR template; add an AI reviewer; require every review thread resolved before merge |
| Matching effort to risk | Quick pass on routine changes, deep pass where a missed bug is expensive; cap review rounds; write down risk tiers |
| Approval | Risk based on the change, not the author; lighter paths only for trusted authors; code owners and branch protection on billing, CI and release flows; never let a bot's approval replace a human's |
| After merge | Merge queue, feature flags, internal use first, staged releases, one-step rollback |
| Improvement | Turn incidents and reverts into eval sets; rescore the reviewer whenever prompts, tools or models change |
➡️ Where this is going 39:01
At launch, the product line was that approving a PR is still a human call — the product posts findings, not approvals. Their own repos are going further: owners decide which low-risk changes merge on automated checks alone, and that line keeps moving.
| Position | Statement |
|---|---|
| Anthropic | A weekly on-call rotation; incident reviews ask which layer should have caught the issue. Explicitly missing: circuit breakers that tighten approval when revert and incident numbers move — engineers want them before more code moves to zero-human merges. |
| Theo | Already doing a bit of zero-human merging for easy bug fixes — which is how a colleague lands ~400 PRs a day. Disagrees with prose-first fixes: fix the code, then the check, then maybe the guidance. |
| Both | The alternative to all of this — slowing down — lowers your error rate mostly because you're doing less of everything. Better to get faster at noticing and fixing than to prevent by abstaining. |
🛠 What T3 Code does differently 29:58
Throughout, he compares his own three-person team's practice with Anthropic's. The differences are as instructive as the agreements:
| Practice | Anthropic | T3 Code |
|---|---|---|
| PR load | 30,000+ changes/day in the monorepo | Up to 800 PRs/day claimed; ~half merge, the rest are closed or reshaped |
| Merge queue | Yes, checks re-run on latest main | No — "we've broken main enough times"; avoided so far |
| Review bots | Claude review + verifiers + security pass | Council of three model families, run locally |
| Convergence control | Round cap, no repeats, class-of-bug flagging | Per-reviewer 1–10 score with a bar; short circuits still being added |
| Verification | Tests, build, screenshots, design guidelines | Per-thread desktop, recorded video of the change working, fake model selections for token-free end-to-end runs |
| Zero-human merges | Owners decide for low-risk changes; circuit breakers pending | Some, for easy bug fixes |
✅ Claims checked
| Claim | Verdict | Evidence |
|---|---|---|
| Source article exists, by Addy Osmani, Morgan Westlee Lunt and Qing Wang | Correct | claude.dev blog, "How the Claude Code team does code review", published 15 Oct 2026, 14 min read |
| ~90% of Claude Code written by Claude | Correct | Article: "Claude writes about 90 percent of Claude Code's own code" |
| Monorepo changes: ~2,500/day in May → 30,000+/day in September | Correct | Article, "Rethinking the purpose of code review" |
| Merged PRs more than doubled June→September while revert share fell >40% | Correct | Article, opening paragraph |
| Goal: most PRs merge with at most one human in the loop, no rise in reverts or incidents | Correct | Article states the goal verbatim; tracks approvals per PR (median and p95), comments, wait time |
| Six layers, ending in merge queue, flags, gradual release, watch/fix-forward/rollback | Correct | Article's "life of a change" diagram and text |
| Substantive review comments on internal PRs rose 16% → 54% at the research preview | Correct | Article; most PRs over 1,000 lines get findings, most small ones come back clean |
Finders + verifier votes + severity tags (important/nit/pre-existing); must be answered | Correct | Article; style/diagnostic/cleanup findings dropped, filters A/B tested |
| Security findings block merge until fixed or resolved with a reason | Correct | Article, layer 3 |
| Risk tiers: no person / one / two; change sets the tier; agent approval never counts as a person's | Correct | Article, "Where humans stay in the loop"; sensitive paths and CI workflow files always need a person |
| Incidents become evals, run daily; noise measured by author response | Correct | Article, "How we make the reviewer better" |
| One CLI PR ran more than fifty review rounds overnight | Correct | Article: "more than fifty rounds… overnight before its author stopped it" |
| ~60% of flagged code was pre-existing since the first pass | Rounded up | Article says about 59% |
| Convergence results: 65%→78% pass in one round; 8.9%→1.5% needing 5+; mean 2.08→1.32 | Correct | Article figure; the video's "13% increase" is 13 percentage points, not 13% |
| Round cap at three rounds, then step back and reconsider | Correct | Article, convergence list |
| No circuit breakers yet to tighten approval when rates move | Correct — their own admission | Article: engineers want them before more code moves to zero-human merges |
| Explainers replace diff-reading for shared context | Correct | Article: "we don't have a formal process for this"; ask Claude for an explainer of the slice you need |
| Sponsor claim: 85% of web APIs can't be reached with plain HTTP | Sponsor's figure | Paid segment; not verified, and excluded from this article's argument |
| Theo's T3 Code figures: 800 PRs/day, ~400/day colleague, 80,000-line PR over four days | His own, unverifiable | T3 Code repo is MIT and public (~49,900 stars at time of writing), but no PR-rate data is published |
Basis note. Built from the full 42:14 transcript, then verified line by line against the primary article on claude.dev (which the video is reading live — so most of its "claims" are the article's own numbers, not independent assertions). Three figures were corrected: 59% not 60%, 13 percentage points not 13%, and the pre-existing-code diagnostic is a first-pass comparison, not a per-round trend. Sponsor material is excluded; Theo's own workflow figures are labelled as practitioner claims.
🔑 Key takeaways
- "Did a human read it?" is the wrong question. The right one: what could go wrong with this change, and which check — automated or human — catches that class of failure?
- Both humans and agents are lossy; the difference is stamina. The reviewer that finds the subtle bug is the one that will check again without getting bored.
- The metric is one human per PR — as the author — with no rise in reverts or incidents. Revert and incident rates are the guardrail; if they rise, you moved the time, you didn't save it.
- Layers beat gates. Six checks where each catches a different class, plus rollback underneath, tolerate imperfection better than one perfect reviewer.
- Layers also multiply instruction. Watch for the 50-line PR that becomes 2,000 lines because an agent obeyed every reviewer.
- Verification before review is the biggest lever. Give the agent something it can run and make it show the output instead of claiming success.
- Fix at the source, in order: the codebase, then static analysis, then prose files.
REVIEW.mdis a last resort that people reach for first. - Review must converge. After three rounds, stop and reconsider the approach; never repeat a posted finding; flag the class of bug, not the line.
- Convergence is measurable and it works: one-round passes 65%→78%, five-plus-round PRs 8.9%→1.5%, mean rounds 2.08→1.32.
- Noise costs more when the author is an agent — a nit that costs a human two seconds costs a pipeline another commit and another round.
- An agent's approval must never fill a human slot, and the risky tier must follow the change, not the author.
- Incidents should become evals — confirm each bug with an engineer who knows the code, keep the set, run the reviewer against it daily.
- Circuit breakers are the missing piece. Nobody has automated the "tighten approvals when revert rates move" step, and that is the guardrail the whole model leans on.
- Ask for explainers, not diff-reading, when sharing context. An explainer of the module you are about to change beats reading a one-line change.
- Cross-family review is cheap and underrated; three models from three families disagree in ways one vendor's reviewer cannot.
🔗 Resources
- The source video — Theo (t3.gg), "How Claude Fixes Its Own Code", 42:14, 6 November 2026
- The primary source — "How the Claude Code team does code review", Addy Osmani, Morgan Westlee Lunt and Qing Wang, 15 October 2026
- pingdotgg/t3code — the MIT-licensed repo at the centre of the comparison