# How Top Teams Review AI-Written Code > Source: > Published: 2026-10-27 17:32:54+00:00 Your engineers now open more pull requests than anyone on the team can read. **That’s the hidden bill of AI coding**, and it rarely shows up in the demo. This week Addy Osmani posted how the Claude Code team handles it. [His X Article](https://x.com/addyosmani/status/2114604912520921136) has **more than 2 million views and 31,000 bookmarks so far**. The full write-up, by Addy, Morgan Westlee Lunt and Qing Wang, lives on [Claude’s developer blog](https://claude.dev/blog/solving-code-review-at-anthropic/), and it’s the most practical thing I’ve read on the topic this year. Start with the numbers. [According to the post](https://claude.dev/blog/solving-code-review-at-anthropic/), Claude writes **about 90% of Claude Code’s own code**. In Anthropic’s monorepo, changes landing per day went from **about 2,500 in May to more than 30,000 in September**. Their AI code review process keeps review in place and moves most of the reading to machines. Humans get pointed at the risky stuff. And the team spends real effort on making any mistake fast to undo. I paired it with the best research I could find on AI code quality and review time. What you get here is the general playbook for any team where agents write a growing share of the code, plus a 30-day plan to copy it at a startup. Paid subscribers also get **the AI Code Review Kit**: review rules, 5 reviewer subagents, GitHub workflows, a PR template, a human checklist and a metrics script, ready to drop into a repo. ## Key Takeaways 1. **Review is the new bottleneck.** Across 1,255 teams,[Faros AI](https://www.faros.ai/blog/ai-software-engineering) found that when teams move to high AI adoption, they merge**98% more pull requests** , while time in review rises**91%** . 2. **AI-written code needs a closer read in specific places.** In[CodeRabbit’s study of 470 pull requests](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report) , AI co-authored changes carried**about 1.7 times as many issues** as human-only ones. 3. **One gate became six layers of checks, with rollback under them.** On the Claude Code team,[merged PRs more than doubled while the revert share fell by over 40%](https://claude.dev/blog/solving-code-review-at-anthropic/) . 4. **Risk sets how many people approve.** A docs fix can merge on automated checks alone, while the riskiest code needs two people.**A bot’s approval never counts as a person’s.** 5. **Treat the AI reviewer like a product.** Score it against your past incidents, and cap its rounds.[One of their PRs ran more than fifty review rounds overnight](https://claude.dev/blog/solving-code-review-at-anthropic/) before anyone stopped it. ## Table of Contents 1. Why Code Review Became the Bottleneck 2. What Changes When AI Writes the Code 3. How the Claude Code Team Reviews Code 4. Who Approves What: Risk Tiers 5. How to Make an AI Reviewer Worth Reading 6. What Humans Still Own 7. The 30-Day Rollout 8. The AI Code Review Kit ## 1. Why Code Review Became the Bottleneck Code review used to be cheap. In [Google’s 2018 case study](https://www.ifi.uzh.ch/dam/jcr:d3de75f7-1464-4463-a539-dde7714f0035/icse2018seip.pdf) of its own process, **the median change touched 24 lines** and the median review wrapped up in under 4 hours. Google’s [public review guide](https://google.github.io/eng-practices/review/reviewer/speed.html) still treats one business day as the longest a reviewer should take to respond. That rhythm assumed humans typed the code. AI changed the inputs. ### More code, same reviewers [Faros AI](https://www.faros.ai/blog/ai-software-engineering) pulled telemetry from more than 10,000 developers on 1,255 teams and compared each team’s lowest and highest AI-adoption quarters. When teams moved to high AI adoption, merged pull requests went up **98%**, average PR size went up **154%** and time in review went up **91%** ([Faros AI](https://www.faros.ai/blog/ai-software-engineering)). Tasks completed rose 21% and bugs per developer rose 9% in the same data ([Faros AI](https://www.faros.ai/blog/ai-software-engineering)). Company-wide delivery metrics like lead time and change failure rate stayed flat. **The extra output just piled up in front of reviewers.** Google’s [2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) surveyed nearly 5,000 technology professionals and lands in the same spot. **90% of respondents use AI at work** ([DORA](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)). AI adoption now goes with higher delivery throughput, and it still goes with lower delivery stability. ### Even Anthropic hit the wall Anthropic says [code output per engineer grew 200% in a year](https://claude.com/resources/articles/code-review). Before it built its own reviewer, **only 16% of its internal pull requests got substantive review comments** ([Anthropic](https://claude.com/resources/articles/code-review)). Here’s how I’d put it to a board. Your AI bill bought you more pull requests. **Whether it bought you more shipped product depends on everything between “PR opened” and “running in production”.** ## 2. What Changes When AI Writes the Code Volume alone would be manageable. The trouble is that AI-written code tends to break in a few predictable places. ### More issues per pull request [CodeRabbit](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report) ran its reviewer over 470 open-source pull requests, 320 of them AI co-authored and 150 human-only. The AI ones averaged **10.83 issues per PR, against 6.45** for the human ones ([CodeRabbit](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)). Break it down by category and logic errors show up **1.75 times as often** ([The Register](https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263)). Across all security findings the ratio is 1.57 times ([The Register](https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263)), and up to 2.74 times for specific issue types ([CodeRabbit](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)). In [The Register’s coverage](https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263), the 2.74x case is XSS. Error-handling gaps show up nearly 2 times as often, formatting problems 2.66 times and readability issues **more than 3 times** ([CodeRabbit](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)). Keep the source in mind. CodeRabbit sells AI code review, and it guessed authorship from signals in each PR, so some of the “human-only” changes probably had AI help. ### Duplicated code is rising [GitClear](https://www.gitclear.com/ai_assistant_code_quality_2025_research) analyzed 211 million changed lines. **Duplicated blocks of five or more lines rose about eightfold in 2024**, and refactoring fell from about 25% of changed lines in 2021 to under 10% in 2024 ([GitClear](https://www.gitclear.com/ai_assistant_code_quality_2025_research)). If you review one thing first, check whether the new helper already exists somewhere. ### “It feels done” is weak evidence [METR’s early-2025 trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) found 16 experienced open-source developers took **19% longer** with AI tools, while believing AI had sped them up by about 20%. METR has since said that result is out of date. Its [February 2026 update](https://metr.org/blog/2026-02-24-uplift-update/) on late-2025 tools points to a speedup instead: an estimated 18% for returning developers and 4% for new ones. METR also calls that data unreliable, because developers who expected big AI gains increasingly opted out or held back tasks, so the true speedup is probably higher ([METR](https://metr.org/blog/2026-02-24-uplift-update/)). My takeaway for review: **people misjudge their own AI speed in both directions**, so ask for proof the code ran. The reviewer’s job shifts. Machines handle syntax and style well. **Humans should spend their minutes on intent, fit with the system, duplication and proof that the code actually ran.** ## 3. How the Claude Code Team Reviews Code Credit where it’s due: this section summarizes the post by [Addy Osmani, Morgan Westlee Lunt and Qing Wang](https://claude.dev/blog/solving-code-review-at-anthropic/). The framing and the startup lessons are mine. ### They rewrote the question Review has always had two purposes. It catches bugs before users do, and it spreads knowledge of the codebase. For the bug-catching part, the team dropped the old test of whether a human read every line. **Their test is which check, human or machine, is best placed to catch what could go wrong with this specific change** ([claude.dev](https://claude.dev/blog/solving-code-review-at-anthropic/)). That pulled review forward in time. They describe it as working [“more like spellcheck while you write”](https://claude.dev/blog/solving-code-review-at-anthropic/). By the time a person looks, Claude has usually reviewed and fixed the change at least once. ### They measure human time The target: most PRs merge with **at most one human involved, and that human can be the author**. Reverts and incidents must hold flat ([claude.dev](https://claude.dev/blog/solving-code-review-at-anthropic/)). The dashboard tracks human approvals per PR at the median and the 95th percentile, plus human comments and how long a PR sits waiting on a person. **Reverts and incidents are the guardrail.** If they climb, you saved review time by spending it on firefighting. ### 6 layers of checks, with rollback under them The post’s own diagram shows six layers of checks sitting on top of a rollback safety net ([claude.dev](https://claude.dev/blog/solving-code-review-at-anthropic/)). Here they are, in my words: 1. **Prove it works before the PR.** Claude must run something, a test suite or a screenshot against the design, and show the output. Then a fresh subagent reads the diff. Boris Cherny, who created Claude Code, says this feedback loop will[“2-3x the quality of the final result”](https://x.com/bcherny/status/2007179832300581177) . 2. **An AI reviewer on every PR.** Several agents hunt bugs in parallel, and a separate group votes before anything gets posted. Every finding carries a tag (Important, Nit or Pre-existing) so authors stop getting blamed for old bugs. 3. **Security review with teeth.** Open bug or security findings block the merge until someone fixes them or closes them with a reason. 4. **CI that blocks.** Lint, types, tests on every platform and a build. The PR template makes you write how you tested and how to undo the change. 5. **Human approval sized to risk.** Zero, one or two people, depending on the change. Section 4 covers it. 6. **Merge queue, flags and staged release.** Every check reruns against main with the change applied. New behavior goes to Anthropic staff first, then to a`latest` channel, with`stable` trailing behind. **Under all six sits fast detection and rollback.** Flags switch off without a deploy, a weekly on-call rotation watches, and each incident review asks which layer should have caught the problem ([claude.dev](https://claude.dev/blog/solving-code-review-at-anthropic/)). My favorite line in the post comes from a colleague of the authors: slowing down lowers your error rate [“but mostly because you’re doing less of everything”](https://claude.dev/blog/solving-code-review-at-anthropic/). **The team bet on getting faster at spotting and fixing problems.** I think that’s the right bet for any startup. ## 4. Who Approves What: Risk Tiers This is the piece most startups can copy fastest. **It’s a written policy plus a few GitHub settings.** The Claude Code team uses three tiers ([claude.dev](https://claude.dev/blog/solving-code-review-at-anthropic/)): 1. **Low** , like docs, copy, internal-only features and additive changes behind a flag: zero human approvals once automated review and security checks pass. 2. **Medium** , like ordinary product work and sensitive spots such as caching, the auto-updater or system prompts: one person. 3. **High** , the riskiest code plus a short list of paths that always need two people: two people. The rules around the table do most of the work: - **The change picks the tier.** A classifier reads the diff and assigns it, and a second one asks whether this particular change deserves another reviewer anyway. CI workflow files always get a person. - **Fast lanes are for trusted authors.** Only people on a repo’s trusted list, mostly the owning team, get the lighter paths. - **A bot’s approval never fills a human slot.** AI can clear a low-risk change. That’s the ceiling. - **Whoever prompted the agent owns the PR.** They count as one of the required reviewers. - **An approval covers one commit.** A new agent push, or a merge conflict resolved by hand, means approving again. At a 10-person engineering team, **those five rules map almost one to one onto a CODEOWNERS file and GitHub branch protection.** You could have them live by Friday. That’s the system. The paid half shows how to run it on your own repo: tuning an AI reviewer so people actually read it, and a week-by-week rollout with the numbers to track. It comes with **the AI Code Review Kit**, a zip you drop into any GitHub repository: - `REVIEW.md` **and** `CLAUDE.md` **templates** , plus**5 reviewer subagents** and a`/pre-pr-review` skill - **3 GitHub Actions workflows** , including AI review with a 3-round cap and diff-only re-review - **A PR template, risk tiers, CODEOWNERS and branch-protection settings** - **A human reviewer checklist, an incident eval template and a metrics script** for approvals per PR, wait time and revert share