<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/how-the-claude-code-team-does-code-review-nfpdtqijj" -->

---
title: How the Claude Code team does code review | daily.dev
description: Anthropic's Claude Code team details how they review code at the volume AI agents produce it, with Claude writing roughly 90% of Claude Code's own codebase....
canonical: https://daily.dev/posts/how-the-claude-code-team-does-code-review-nfpdtqijj
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: How the Claude Code team does code review | daily.dev
og:description: Anthropic's Claude Code team details how they review code at the volume AI agents produce it, with Claude writing roughly 90% of Claude Code's own codebase....
og:url: https://daily.dev/posts/how-the-claude-code-team-does-code-review-nfpdtqijj
og:image: https://api.daily.dev/og/posts/NFPDTqIJJ.png
og:image:alt: How the Claude Code team does code review
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# How the Claude Code team does code review

**[ClaudeDevs](https://daily.dev/sources/claudedevs)** · 14 min read · 0 upvotes · 0 comments

## Summary

Anthropic's Claude Code team details how they review code at the volume AI agents produce it, with Claude writing roughly 90% of Claude Code's own codebase. Rather than removing review, the team shifted most reading to automated agents, running continuous review (verification, subagent diffs, internal skills) before a PR even exists, followed by an automated Claude review that flags findings verified by multiple voting agents, plus separate security review. A risk-tiering system determines how many human approvals (0, 1, or 2) a change needs based on classifiers, trusted-author lists, and sensitive paths, with the goal of minimizing human review time without raising reverts or incidents. From June to September, merged PRs more than doubled while revert rates fell over 40%. The team also discusses handling review loops that don't converge (one PR hit 50+ rounds), measuring noise via how authors respond to comments, and how codebase knowledge now spreads through Claude-generated explainers instead of line-by-line diff reading.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://claude.dev/blog/solving-code-review-at-anthropic>

## Questions this post answers

### How much did merged pull requests and revert rates change at Anthropic after scaling agent-written code review?

Merged pull requests to Claude Code's codebase more than doubled between June and September, while the share of PRs that had to be reverted fell by more than 40 percent. Separately, in Anthropic's broader monorepo, changes landing per day grew from about 2,500 in May to more than 30,000 in September, driving the need for automated, tiered review instead of manual line-by-line review.

_Teams scaling agent-generated code can compare real adoption metrics like these on daily.dev before redesigning their own review process._

### How does Claude Code's team decide how many human approvals a pull request needs?

A classifier reads the change and assigns it a risk tier: low-risk changes like docs or flagged additive features need no human approval once automated and security checks pass, medium-risk changes (ordinary product changes, caching, auto-updater, system prompts) need one human approval, and high-risk code or sensitive paths need two. A second classifier can still require a human even if the tier says otherwise, and only trusted authors get the lighter paths.

_Engineers designing approval policies for AI-written PRs can use examples like this risk-tiering model found via daily.dev._

### What did Anthropic find when they investigated why Claude Code's automated reviewer kept flagging issues across many review rounds?

Running git blame on repeatedly flagged code showed that about 59 percent of it was code that had existed since the reviewer's first pass, meaning the reviewer was mostly finding a few more old bugs each round rather than new ones. One CLI pull request went through more than fifty rounds of review and fixes overnight before its author stopped it, prompting the team to track rounds-to-pass and curb unnecessary re-review.

_Developers tuning AI code review loops to avoid runaway review cycles can find process breakdowns like this via daily.dev._

## Community take

How the wider developer community reacted, aggregated from 2 discussions and 166 comments across hackernews (as of 2026-10-17).

**TL;DR:** The discussion is dominated by skepticism toward the post's framing, with heavy debate over whether 30,000 daily changes represent real engineering progress or just inflated, low-value churn, alongside broader worries about code quality, maintainability, and Anthropic's profitability claims.

**Sentiment:** 10% positive · 25% mixed · 65% skeptical

**The case for**

- A few commenters find automated/AI-driven review genuinely useful for catching duplication and speeding up their own workflows.
- Some argue large legacy codebases were already too big for any single human to fully understand, so this isn't categorically new.
- Setting up custom AI-based review pipelines (e.g. via GitHub Actions) is seen as cheap and effective by a few who tried it.

**The pushback**

- Many are skeptical that 30,000 changes/day is a meaningful or impressive metric, comparing it to trivially inflating commit counts.
- Commenters worry AI-generated code accumulates duplicated logic, reinvented wheels, and entangled complexity that tests don't catch.
- Concern that no human (or even the AI itself) will be able to debug catastrophic failures once codebases grow beyond anyone's mental model.
- Several dispute Anthropic's profitability claims, arguing the 'adjusted operating income' figures exclude major costs.
- Some feel the piece is marketing/FOMO messaging rather than a substantive engineering account.
- Worry that reduced line-by-line review lowers software quality and that end users bear the cost of bugs and regressions.

**By community**

- hackernews (heated): A large, contentious thread split between those defending AI-driven review/high change volume as progress and those arguing it signals churn, declining code quality, and questionable business metrics.

**Hottest debate:** Whether high-volume AI-generated changes (30k/day) represent real productivity or are a meaningless/inflated metric masking churn and declining code quality.

**Open questions**

- Does removing line-by-line human review actually increase long-term defect rates and maintainability risk, or do automated checks sufficiently substitute for it?
- Who or what is responsible for writing the remaining ~10% of code, and why does that gap exist?
- How sustainable is the cost structure of automated AI code review at scale, given per-review costs and uncertain profitability?
- Can automated verification scale the way manufacturing QA does, given code's inherent variability versus repeated manufactured parts?

**Highlights**

> That’s a category error. Software isn’t stamping out the same part again and again; if it were review would be simple. Analogies often mislead. Of course Anthropic would love you to think you are heading towards that future so we have to bear in mind their livelihood depends on LLMs being the future of work and 30k changes a day being normal. But why would we want 30k changes a day in a given product, what possible justification could there be?
> — [grey-area on hackernews · 1 comments](https://news.ycombinator.com/item?id=50124578)

> > have the LLM focus and summarize a slice of the system when they need to know about it or ask for it. But.... That's not knowledge? That's just search a la google? And thus seems to be subject to the same problems where the quality of your search dictates the quality of your knowledge that you surface at any given time? This is the crux.  Take pause, because hidden here is a sea-change in our fundamental trust model of software... There is no longer anyone to turn to if this system breaks by, eg, having a critical bug that no one can figure out.  No causal model in anyone's head that can be appealed to, to slowly and methodically debug.  By design, the system is too large for that, and everything hinges on Claude itself being able to find and understand the right slice of the system in any situation.  As long as that very new invariant holds, everything will be all right.  If it fails catastrophically, there is no recovery.  You are the owner of a recovered alien spacecraft with tech you have no hope of understanding. The new trust model is: We trust Claude to always understand the system enough to debug anything or make any reasonable change we could want.  The risk might be worth the reward.  But it's worth explicitly laying out the deal we're making. Tbf, it's worth pointing that many large legacy systems already work like that, with "Claude" replaced by "whoever happens to be maintaining it this year".
> — [jonahx on hackernews · 2 comments](https://news.ycombinator.com/item?id=50125128)

> Personal experience: AI tends to add new wheels for a new feature in a large codebase, because finding, understanding, and generalizing the existing code to integrate a new feature will likely break existing features, cost more effort (and token) to implement and test. Human reviewers also tend to like these code since they are clean, easy to review, and get the job done, especially when they are not familiar with existing codebase. The issue is that wheels like these accumulate in the codebase, and they inevitably entangle. When an upstream specification changes, when a new feature that works with many existing features are introduced, all these wheels need to be revisited, and in many cases they are not because the new test cases do not cover all the paths. The code base got larger and more complex, and contains more bugs than the unit tests can cover, especially when unit tests are often "bent" to fit the wrong behavior unnoticed.
> — [bpeng2000 on hackernews](https://news.ycombinator.com/item?id=50124256)

> I, too, can write and merge 30000 changes per day. Even 300000 if I've up to. Of course, just like "line of code" is a worthless metric, "change merge per day" is;   for i in {1..10000000}   do     echo "I am working !" >> README.md     git add README.md     git commit -s -m "feat: working with AI"   done (automerged PR, JOB IS DONE)
> — [JackSlateur on hackernews](https://news.ycombinator.com/item?id=50123490)

> I really like those videos too, but a very big difference is, in manufacturing QA, the system outputs a very high number of copies of a very small number of possible types, so spot checks work fine from an operations research point of view, as the variance in output has a known upper bound. For code, I think things go in the opposite direction: the system outputs artifacts that are all different among themselves (even more so now that we no longer distribute software via physical copies. Well, bits are always physical, but I mean we no longer ship floppies/CDs/DVDs). That said, at least in my experience, code review has never been a direct part of factory-line-type QA. That QA is typically done by treating software as a black box and just verifying that it complies with a spec (often times based on a very loose definition of "spec" ...), and this is something that works equally well regardless of whether a human or a machine wrote the software. The type of QA that is done (among other things) by code reviews is checking whether the software's design is such that it will be economically feasible to maintain and extend it, for example. The one part the code reviews takes a part of (but is in no way error-free) and that you just can't do with black-box testing (or it is much harder to do) is to look for things like backdoors. As our industry moves more towards "agents write software and tests validate that it works," I think a lot about "Reflections on Trusting Trust" and the new and wide attack surface added by people no longer reading the code shipped on their behalf.
> — [fipar on hackernews](https://news.ycombinator.com/item?id=50124611)

**Source threads**

- [hackernews](https://news.ycombinator.com/item?id=50122951) · 152 points · 162 comments
- [hackernews](https://news.ycombinator.com/item?id=50116568) · 2 points · 4 comments

## Similar posts on daily.dev

- [AI Code Review Bottleneck 2026: Why PRs Are Stuck in Review](https://daily.dev/posts/ai-code-review-bottleneck-2026-why-prs-are-stuck-in-review-o7qcycgq0) · Alex CloudStar · 2 upvotes · 1 comments
- [Agentic Code Review](https://daily.dev/posts/agentic-code-review-0ue8fcsa1) · Addy Osmani · 146 upvotes · 14 comments
- [Automate Your Code Reviews: Welcome to the Post-AI Era of Software Development.](https://daily.dev/posts/automate-your-code-reviews-welcome-to-the-post-ai-era-of-software-development--9qd0ky8y4) · ITNEXT · 0 upvotes · 0 comments

---

Tags: [#ai-agents](https://daily.dev/tags/ai-agents), [#cicd](https://daily.dev/tags/cicd), [#claude-code](https://daily.dev/tags/claude-code), [#code-review](https://daily.dev/tags/code-review)

[View this post on daily.dev](https://daily.dev/posts/how-the-claude-code-team-does-code-review-nfpdtqijj)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"How the Claude Code team does code review","url":"https://daily.dev/posts/how-the-claude-code-team-does-code-review-nfpdtqijj","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/how-the-claude-code-team-does-code-review-nfpdtqijj"},"datePublished":"2026-10-16T01:02:49.426Z","dateModified":"2026-10-17T00:22:54.758Z","description":"Anthropic's Claude Code team details how they review code at the volume AI agents produce it, with Claude writing roughly 90% of Claude Code's own codebase....","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/162ef3fcedacb300cb0d8decffb5fe28?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/162ef3fcedacb300cb0d8decffb5fe28?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"ClaudeDevs","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"ClaudeDevs","logo":"https://media.daily.dev/image/upload/s--wBREB-hc--/f_auto,q_auto/v1787418470/logos/claudedevs?_a=BAMAMicg0","url":"https://daily.dev/sources/claudedevs"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/how-the-claude-code-team-does-code-review-nfpdtqijj","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"ai-agents,cicd,claude-code,code-review","timeRequired":"PT14M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"ClaudeDevs","item":"https://daily.dev/sources/claudedevs"},{"@type":"ListItem","position":3,"name":"How the Claude Code team does code review"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/how-the-claude-code-team-does-code-review-nfpdtqijj#faq","mainEntity":[{"@type":"Question","name":"How much did merged pull requests and revert rates change at Anthropic after scaling agent-written code review?","acceptedAnswer":{"@type":"Answer","text":"Merged pull requests to Claude Code's codebase more than doubled between June and September, while the share of PRs that had to be reverted fell by more than 40 percent. Separately, in Anthropic's broader monorepo, changes landing per day grew from about 2,500 in May to more than 30,000 in September, driving the need for automated, tiered review instead of manual line-by-line review. Teams scaling agent-generated code can compare real adoption metrics like these on daily.dev before redesigning their own review process."}},{"@type":"Question","name":"How does Claude Code's team decide how many human approvals a pull request needs?","acceptedAnswer":{"@type":"Answer","text":"A classifier reads the change and assigns it a risk tier: low-risk changes like docs or flagged additive features need no human approval once automated and security checks pass, medium-risk changes (ordinary product changes, caching, auto-updater, system prompts) need one human approval, and high-risk code or sensitive paths need two. A second classifier can still require a human even if the tier says otherwise, and only trusted authors get the lighter paths. Engineers designing approval policies for AI-written PRs can use examples like this risk-tiering model found via daily.dev."}},{"@type":"Question","name":"What did Anthropic find when they investigated why Claude Code's automated reviewer kept flagging issues across many review rounds?","acceptedAnswer":{"@type":"Answer","text":"Running git blame on repeatedly flagged code showed that about 59 percent of it was code that had existed since the reviewer's first pass, meaning the reviewer was mostly finding a few more old bugs each round rather than new ones. One CLI pull request went through more than fifty rounds of review and fixes overnight before its author stopped it, prompting the team to track rounds-to-pass and curb unnecessary re-review. Developers tuning AI code review loops to avoid runaway review cycles can find process breakdowns like this via daily.dev."}}]}
```

