How the Claude Code team reviews code written by AI
pull request
A proposed code change sent for checking before it joins the main project.
rollback
Returning software to an earlier version after a problem.
risk tier
A level that decides how much review a change needs.
What happened
Anthropic published a detailed account of its Claude Code review process on October 15, 2026. The company says Claude writes about 90% of Claude Code’s own code. From June to September, merged pull requests more than doubled. The share that needed a revert fell by more than 40%. Across Anthropic’s larger shared codebase, daily changes rose from about 2,500 in May to more than 30,000 in September. These are internal figures reported by the company, not an outside audit. The process is described in Anthropic’s engineering post.
Why review had to change
AI agents can create changes faster than people can read them line by line. Code review has two jobs: finding problems before release, and helping engineers understand the codebase. Anthropic says the better question is not whether a person read every line. It is which automated or human check can catch the risks in a change.
That idea moves review earlier. Before a pull request exists, Claude can run tests, builds, or screenshot comparisons. A fresh-context subagent then reviews the difference. Every pull request also receives an AI bug review that considers the whole repository and the change’s stated purpose. Security review can block a merge. Standard linting, type checks, tests, and builds add more gates. Other agents verify review findings, and only findings judged real enough appear for people.
Where humans remain
Human attention is assigned by a risk tier. Low-risk changes, such as documentation edits, may need no human approval after automated checks pass. Medium-risk changes need one person. High-risk changes need two. The change determines the tier, not the author. A second classifier can require another person even when the first tier is light. An AI approval never fills a human approval slot.
People still decide whether a change should exist, whether its architecture is sound, and whether sensitive areas deserve deeper review. The team names billing, the auto-updater, CI workflows, system prompts, and broad architectural patterns as examples. People also read the evidence: test results, commands, screenshots, and review findings. Whoever directs an agent is accountable for the shipped result.
How the team limits failure
The process uses a merge queue, feature flags, staged releases, and rollback. New behavior can reach employees before the public. The latest release channel moves first, while the stable channel follows. Incidents and reverts become evaluation cases for the reviewer. The team also measures noisy findings, because an agent can waste time by fixing harmless complaints.
Review itself can loop. One pull request went through more than 50 rounds of review and fixes overnight. When the team checked repeated findings, about 59% concerned code that had already existed during the reviewer’s first pass. It added a round cap after three rounds, then focused later reviews on the new diff.
What is confirmed, and what remains open
The post clearly documents Anthropic’s internal design: machines handle much routine checking, while people concentrate on direction, evidence, high-risk code, and ownership. It also says the team watches human approvals, comments, waiting time, revert rates, and incident rates.
The post does not independently prove that the process works elsewhere. It does not provide a full comparison of incident severity, all metric definitions, or results from smaller teams with fewer models and resources. It also leaves an open question about how engineers retain deep code understanding when machines do most routine reading.
Hacker News attention and what to watch next
The post received 472 points and 468 comments on Hacker News. Those numbers show community attention. They do not prove that Anthropic’s claims are correct. The next useful signals are whether incidents and reverts stay controlled, whether human waiting time truly falls, and how far low-risk changes can move toward automated merging without weakening accountability.
AI checks the routine code, while people handle the risky choices
📰 Full story: How the Claude Code team reviews code written by AI
The Claude Code team split code review between machines and people.
Claude Code
Anthropic’s AI tool for writing computer instructions.
pull request
A proposed change sent to others for checking.
rollback
Going back to an earlier version after a problem.
💡 The gist
- Claude writes about 90% of Claude Code’s code.
- Machines check routine changes before people review them.
- People decide what is risky and what should ship.
Anthropic is the AI company that makes Claude. Its Claude Code team explained its code review process. The company says Claude writes about 90% of Claude Code’s code.
From June to September, merged changes more than doubled. The share that needed a reversion fell by more than 40%. A reversion means undoing a change. In Anthropic’s large shared codebase, daily changes rose from about 2,500 in May to over 30,000 in September.
AI can create changes faster than people can read every line. So the team checks work continuously. Before a pull request exists, Claude can run tests, builds, or screenshot comparisons. Another AI then reviews the new difference. Each pull request gets bug and security checks. Security findings can stop a merge.
Several agents check review findings. This helps remove complaints that are only about style. It also reduces false alarms. Still, automated review does not replace people everywhere.
The team uses risk levels. Low-risk changes, like documentation, may need no human approval. Medium-risk changes need one person. High-risk changes need two people. An AI approval never counts as human approval.
People answer harder questions. Should the team build this? Is the design sensible? Could this affect billing, updates, or build systems? People also read the evidence from tests and other checks. The person who directs an AI remains responsible for the result.
The team uses feature flags, staged releases, and rollback. These tools help it stop new behavior or return to an earlier version. Review can also run too long. One pull request went through more than 50 rounds. The team later capped rounds and focused new reviews on new code.
The post received 472 points and 468 comments on Hacker News. That shows attention, not proof. Anthropic’s numbers also come from its own report. We still do not know whether smaller teams would get the same results.
💬 Why are people worried about AI writing code so fast?
The comments disagree about whether faster AI coding is worth the risks. The numbers and bug stories are commenters’ interpretations or self-reports, not independently checked results.
- The article says Claude writes about 90% of the code and describes 30,000 changes. Some commenters read 30,000 as a daily figure, but small automated changes can make the number large without meaning there are many valuable features.
- Some people think the whole process should move faster if AI can do the work faster. Others say users need a stable product that does not break old behavior, not just more frequent releases.
- One user reported that unrestricted AI coding produced software that worked but was hard to maintain. Adding a new feature later broke an older feature.
- It may be unsafe to let an AI dismiss important security warnings by itself. Commenters also worried that the security tool was not prepared for prompt injection, meaning misleading instructions aimed at the AI.
- A safer process suggested by commenters uses tests, logs, running the app, checking the original goals, and reviewing the work before and after it is made. One user said an AI reread 10,000 project messages in a few minutes.
growing digest at 468 comments (revision 1). We fetched 300 comments and sampled 120 across the thread. These are HN users’ reports, not independently verified facts.
Who checks the code when AI writes lots of it?
📰 Full story: How the Claude Code team reviews code written by AI
Anthropic, the company behind Claude, shared its checking plan.
Anthropic
The company that makes Claude.
Claude Code
An AI helper that writes computer instructions.
Claude Code is Anthropic’s helper for writing computer instructions. It writes about nine out of ten lines for itself.
That makes many new changes. People cannot read every line quickly. First, Claude checks its work. It runs tests to see if things work. Another AI looks for mistakes.
People then check the important parts. Small changes may need no person. Bigger changes need one or two people. An AI’s yes does not replace a person’s yes.
If something goes wrong, the team can go back. From June to September, changes more than doubled. The team had to undo fewer changes by more than 40 percent.
The story got 472 points and 468 comments on Hacker News. Those numbers show attention. They do not prove the story is true. We do not know if other teams get the same results.
💬 Fast AI code is not always good software
The comments discuss both the usefulness and the danger of letting AI make lots of code. The numbers and bug reports come from users or commenters.
- The article says AI writes about 90% of the code and mentions 30,000 changes. That number may mean one day, but many tiny changes can make any number look big.
- AI can make something that works but is hard to fix later. One user reported that adding a new feature broke an old one. Some commenters said steady, reliable software matters more than speed.
- People should still test the software, run it, and check important safety warnings. They worried about letting AI fix everything when humans no longer understand how the system works.
growing digest at 468 comments (revision 1). We fetched 300 comments and sampled 120 across the thread. These are HN users’ reports, not independently verified facts.
💬 What the discussion says about AI-scale coding and code review
The comments debate the Claude Code team’s AI-centered development and review process described in the article, focusing on how to measure change volume, speed versus stability, security, and maintainability. All numbers, performance claims, and bug reports below are commenters’ interpretations or user self-reports, not independently verified facts.
growing digest at 468 comments (revision 1). We fetched 300 comments and sampled 120 across the thread. These are HN users’ reports, not independently verified facts.