Claude Code 团队如何进行代码审查

2026 年 10 月 16 日

Claude 此前曾表示，Claude 编写了 Claude Code 自身约 90% 的代码。那么，面对如此规模的代码产出，我们如何进行审查？现在还有人会读代码吗？如果出现故障，又由谁来发现？

本文介绍 Claude Code 团队的代码审查流程及其演进。从 6 月到 9 月，合并到 Claude Code 代码库的 Pull Request 数量增长超过一倍，而必须回滚的 Pull Request 占比下降超过 40%。

我们并没有取消审查。但我们把大部分阅读工作交给机器完成，围绕人类的时间和注意力进行优化，并大力投入于让错误能够被快速、轻松地撤销。

重新思考代码审查的目的

当 Agent 编写代码时，变更数量会迅速增加。今年，Anthropic 单体代码库中每天合入的变更数，已从 5 月约 2,500 项增长到 9 月超过 30,000 项。

Claude Code 位于独立于单体代码库之外的仓库中，但同样承受着巨大压力。当交付速度如此之快时，人工逐行审查代码变得极其困难，甚至几乎不可能。

代码审查有两项职责：

1. 在代码发布前发现并修复问题
2. 在团队内建立共享上下文和对代码库的理解

本文主要聚焦于发现和修复问题，但会在接近结尾时回到第二项职责。

我们认为，“是否有人读过代码？”并不是“这项变更可能出什么问题，以及应由哪种检查——自动化或人工——来发现它？”这一问题的精确替代指标。

提出这个问题，也改变了审查发生的时间点。过去，审查是道路尽头的一道关卡：编写代码、创建 PR、等待同事处理。

如今，审查持续进行，更像是在编写时运行的拼写检查。大多数变更在请求人工查看之前，至少已经由 Claude 审查和修复过一次。这会捕捉绝大多数常规错误，让团队将注意力留给更高层次的问题和更严格的审查。

稀缺资源：人类的时间和注意力

我们希望将人类的时间和注意力保留给只有人类能够解决的问题，并确保自动化检查能捕捉其余问题。按照我们当前的变更速度，人类仍有大量工作要做，团队几乎每天都会遇到新的、前所未有的挑战。

人类时间涵盖审查成本的两面：人们用于审查的时间，以及用于修复糟糕代码所造成故障的时间。如果减少前者，却只是让时间成本出现在后者，那么并没有帮助。

因此，目标是让 Claude Code 各仓库中的大多数 Pull Request——包括 CLI、桌面和 Web 应用以及移动应用——在最多一名人类参与的情况下合并；这名人类可以是作者本人，同时不增加回滚或事故数量。为衡量人类时间，我们跟踪每个 PR 的人工批准数（中位数和第 95 百分位数）、人工评论数量，以及 PR 等待人工处理的时间。回滚率和事故率则是护栏：如果它们上升，说明我们并未节省人类时间，只是把时间成本转移了。

一项变更的一生

一项典型变更从工程师的笔记本电脑（或 Slack 中的 Claude 会话）出发，会经过多层代码审查。

一项典型的 Claude Code 变更，从作者的机器到达用户手中：

• 创建 Pull Request 前：工作已验证
  • Claude 运行测试、构建和 linter；第二个 Agent 在全新上下文中审查 diff。
• 每个 Pull Request：必需的 CI
  • 执行 lint、类型检查、跨平台测试、构建和打包。任何失败都会阻止合并。
• Claude 代码审查
  • Agent 并行寻找 bug，验证器对每条发现进行投票，保留的问题按严重程度排序。
• 安全审查
  • 单独进行一次审查。任一审查中未解决的发现都会阻止合并。
• 基于风险的批准
  • 分类器设定等级：不需要人工、一人批准或两人批准。某些路径始终需要人工参与。
• 合并：合并队列
  • 在应用该变更后的最新 main 分支上再次运行检查。
• 合并后：通过 Feature Flag，先供内部使用
  • Anthropic 员工会在功能面向所有人之前先行使用。
• 渐进式发布
  • 先发布至 latest 渠道；stable 渠道随后跟进。
• 监控、向前修复或回滚
  • 作者和 On-call 人员负责监控；Feature Flag 可以快速关闭，损坏的构建会被回滚。

图 A 大部分流程是自动化的；人类注意力会被投入到风险所在之处。

逐层拆解

六层检查，以及位于其下方的回滚机制：

1. 验证中的问题
2. 必需的 CI
3. AI 审查
4. 安全审查
5. 人工批准
6. 合并队列 + Feature Flag
7. 快速回滚

图 B 每一层都能捕捉一些问题，也会遗漏另一些问题。只有极少数问题能穿过所有层，而回滚机制会处理其余问题。

1. 在其他人查看之前验证工作

如今，大部分审查发生在 PR 创建之前。我们给 Claude 提供可运行的验证方式——例如测试、构建，或可与设计稿进行对比的截图——并要求它展示输出结果，而不是仅仅声称工作已经完成。然后，由一个子 Agent 在全新的上下文中审查 diff。这两种习惯均来自我们的最佳实践指南。

在创建 PR 前，许多人还会运行一些内部技能：一个寻找 bug，一个简化 diff，另一个端到端检查行为。UI 变更还会根据我们的设计指南进行检查。

Claude Code 创建者 Boris Cherny 曾称，为 Claude 提供一种验证其自身工作的方式，可能是取得良好结果的最重要因素。他估计，这会让最终结果提升两到三倍，并写道：“不同领域的验证方式不同。它可以简单到运行一条 bash 命令，也可以是运行一套测试、在浏览器中测试应用，或者在手机模拟器中测试应用。”

当自动化审查器不断标记同一个问题时，我们会从源头修复它：在技能中修复、添加 lint 规则，或更新如下说明文件：

• CLAUDE.md 告诉 Claude 项目是什么：技术栈、约定、目标和非目标。每次审查都会加载它，因此在大型代码库中，我们会保持它简短，并从中链接到其他文档。审查器还会标记违反其中约定的代码，以及导致其内容过时的变更。
• REVIEW.md 由代码所有者编写，告诉审查器其负责区域中哪些内容重要。我们会单独检查审查器是否真的遵循这些规则。优秀的 REVIEW.md 很简短：它们说明该仓库中的失败形态是什么——文档的失败是“它在说谎”，配置的失败是“它错误路由”——限制吹毛求疵的数量，列出应跳过的路径，并要求提供文件和行号作为证据，而非根据名称猜测。它们还要求提供一份以数量开头的摘要，并在没有需要修复的问题时明确说明。

2. 每个 Pull Request 都进行 AI 审查

每个 Pull Request 都会在人工查看前获得一次 Claude 审查。它会结合整个仓库和 PR 声明的意图读取 diff，并询问：这项变更是否解决了问题、是否符合系统设计、是否破坏了其他内容？

对于 bug 修复，它会查找根本原因。公开版本 Code Review for Claude Code 现已面向 Team 和 Enterprise 套餐正式发布，/code-review 则可在本地运行一个较轻量的版本。

我们发布研究预览版后，获得实质性审查评论的内部 PR 占比从 16% 上升至 54%。绝大多数超过 1,000 行的 PR 会被发现问题，而大多数小型 PR 都能干净通过。管理员可以为每个仓库设置 Quick、Standard 或 Deep 模式。在漏掉一个 bug 的成本高于额外审查时间的场景中，Deep 模式是值得的。

在人工审查发现结果前，其他 Agent 会先验证这些结果。 多个 Agent 同时寻找 bug。随后，另一组 Agent 对每一项发现投票，只有足够多的 Agent 认定问题真实存在时，结果才会被发布。仅涉及样式、诊断或清理的发现会被丢弃。我们在自己的 PR 上对这些过滤器进行了 A/B 测试后才决定保留。最终保留的问题会以按严重程度排序的行内评论形式展示。每项发现都会标记为 Important、Nit 或 Pre-existing，因此并非由该 PR 引入的 bug 不会看起来像是作者的责任。

每一项发现都必须得到回应。 你要么修复它，要么说明理由并解决讨论线程。通常 Agent 会在夜间接手修复，因此作者回来时，PR 可能已经完成了又一轮处理。

3. 可以阻止合并的安全审查

安全问题也会获得独立的自动化审查。只要 bug 审查或安全审查中存在任何未解决的发现，PR 就不能合并。你需要修复问题，或以简短理由关闭讨论线程；后者是清除误报的方式。

如果后续提交修复了问题，相应发现会自行清除。你可以通过开源安全审查 GitHub Action 或 /security-review 命令实现同样的机制。设置方法参见 Claude Code 中的自动化安全审查。

4. 阻断式自动化检查

常规项目包括：lint、类型检查、所有平台上的测试和构建。（我们曾在这篇文章中介绍如何为这种规模扩展 CI。）一个典型的 CLI Pull Request 可能会在任何人查看之前运行数十项检查。PR 模板要求说明如何测试该变更，以及如何撤销它。Claude 可以填写这些内容，但提出该变更需求的人必须对此确认负责。

5. 按风险扩展的人工批准

文档修复与自动更新器变更承载的风险不同，因此它们需要不同的审查。

风险	示例	人工批准数
低	文档、文案、仅内部使用的功能、位于 Feature Flag 后的增量变更	自动化审查和安全检查均通过后，无需人工批准
中	常规产品变更，以及缓存、自动更新器或系统提示词等敏感区域的变更	一人
高	风险最高的代码，以及一小部分始终需要两人批准的路径	两人

由变更而不是作者决定风险等级。 分类器会读取变更并选择其风险等级。第二个分类器会判断，即使该变更的等级表示无需人工，它是否仍需要另一人参与。某些路径始终需要人工参与，包括所有者列为敏感的内容以及任何 CI 工作流文件。

只有受信任作者才能走较轻量的路径。 只有位于仓库受信任列表中的作者——主要是拥有该仓库的团队成员——才能采用较轻量的流程。其他所有人都需要第二个人批准。Agent 的批准永远不能算作人工批准。自动化审查可以放行低风险变更，但不能填补需要人类参与的批准名额。

提出变更请求的人要对此负责。 对于由 Agent 编写的 PR，指挥 Agent 的人会被计为所需审查者之一，这与他们亲自输入代码时的规则相同。

一项批准只覆盖一个特定提交。 如果系统无法担保的新提交进入 PR，例如 Agent 推送的提交或有人手动解决的合并冲突，那么必须重新获得批准。

6. 合并队列、Feature Flag 和渐进式发布

合并队列会在应用变更后的 main 分支上重新运行每一项检查，因此两个分别通过检查的 PR 不会组合成一个损坏的 main。新行为通常会先通过 Feature Flag 向 Anthropic 员工发布，而我们的高频使用往往能在用户受到影响前暴露回归问题。公开版本会先发布到 latest 渠道，stable 渠道随后跟进。

7. 快速发现、快速回滚

仍然会有一些错误穿透所有防线，因此最后一层的重点是快速发现它们。Feature Flag 无需部署即可关闭。Claude Code 设有按周轮换的 On-call 值班机制，事故复盘会追问：本应由哪一层捕捉到这个问题？

发现一次有问题的合并，仍依赖作者和 On-call 人员，也依赖回滚和事故仪表盘。我们尚未建立能够在这些指标变化时自动收紧批准要求的熔断机制；这里的工程师希望，在更多代码进入零人工合并流程之前先具备这种机制。

一位同事表示，放慢速度确实会降低错误率，但主要是因为你做的一切都变少了。我们更愿意提升发现和修复问题的速度。

我们如何让审查器变得更好

我们的代码审查流程在一个持续改进的循环中不断演进。

任何事故现在都是一次评估。 团队收集了过去导致事故的 PR，以及其向前修复和回滚记录，并让熟悉相关代码的工程师确认每个 bug 及其所在位置。审查器每天都会针对这组案例运行。

我们的事故就是评估集

png

基于过去的事故和回滚构建，每天运行。

1. 事故或回滚： 某项变更导致了故障。
2. 专家核验案例： 专家确认 bug 的存在；每次事故都会为集合增加一个案例。
3. 修改审查器： 调整其提示词、工具或模型。
4. 每日评估运行： 针对每个案例进行评分。
5. 分数提升？保留；否则丢弃。 然后继续进行下一项变更。

We've said before that Claude writes about 90 percent of Claude Code's own code. So how do we review code at the volume we produce it? Does anyone read code anymore? And if something breaks, who catches it?

This post covers the code review flow on the Claude Code team and how it has evolved. From June to September, merged pull requests to Claude Code's codebase more than doubled while the share that had to be reverted fell by more than 40 percent.

We didn't remove review. But we did move most of the reading to machines, optimized for human time and attention, and invested heavily in making it fast and easy to undo mistakes.

RETHINKING THE PURPOSE OF CODE REVIEW

When agents write code, the number of changes goes up, fast. In Anthropic's monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September this year.

Claude Code lives in its own repository, separate from the monorepo, but it's seeing a lot of pressure too. When you are shipping this fast, manual, line-by-line code review is incredibly difficult if not impossible.

Code review does two jobs:

1. Find and fix issues before they ship
2. Build shared context and codebase understanding across the team

This article mainly focuses on finding and fixing issues, but we will come back to the second job near the end.

We think "did a human read the code?" is an imprecise proxy for "what could go wrong with this change, and which check—automated or human—is the right one to catch it?"

Asking that question also changed when review happens. Before, review was a gate at the end of the road: write the code, open a PR, wait for your colleague.

Now, review runs continuously, more like spellcheck while you write. Most changes have been reviewed and fixed by Claude at least once before a human is asked to look. This catches most routine mistakes, and saves team attention for higher-level questions and scrutiny.

THE SCARCE RESOURCE: HUMAN TIME AND ATTENTION

We want to preserve human time and attention for issues only humans can solve and make sure automated checks catch the rest. At our current rate of change, there is still an incredible amount of work for humans to do, and our team encounters new and novel challenges almost daily.

Human time covers both sides of review's cost: the time people spend reviewing, and the time they spend fixing what bad code breaks. Cutting the first doesn't help if the time just shows up in the second.

So the goal is that most pull requests in the Claude Code repos (the CLI, the desktop and web apps, and the mobile apps) merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. To measure human time, we track 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, we haven't saved human time, we've only moved it.

THE LIFE OF A CHANGE

A typical change, from an engineer's laptop (or a Claude session in Slack), goes through multiple layers of code review.

A typical Claude Code change, from the author's machine to users

BEFORE THE PULL REQUEST The work is verified Claude runs the tests, build and linter; a second agent reviews the diff in a fresh context ON EVERY PULL REQUEST Required CI Lint, types, tests across platforms, build and packaging. Red blocks the merge Claude code review Agents hunt for bugs in parallel, verifiers vote on each finding, survivors ranked by severity Security review A separate pass. Open findings from either review block the merge Risk-based approval A classifier sets the tier: no person, one, or two. Some paths always need a person MERGING Merge queue Checks run again on the latest main with the change applied AFTER THE MERGE Behind a flag, used internally first Anthropic employees run it before it reaches everyone Gradual release The latest channel first; the stable channel trails it Watch, fix forward or roll back The author and on-call watch; flags turn off quickly, broken builds get reverted automated a person decides, scaled by risk recovery BEFORE THE PULL REQUEST The work is verified Claude runs the tests, build and linter; a second agent reviews the diff in a fresh context ON EVERY PULL REQUEST Required CI Lint, types, tests across platforms, build and packaging. Red blocks the merge Claude code review Agents hunt for bugs in parallel, verifiers vote on each finding, survivors ranked by severity Security review A separate pass. Open findings from either review block the merge Risk-based approval A classifier sets the tier: no person, one, or two. Some paths always need a person MERGING Merge queue Checks run again on the latest main with the change applied AFTER THE MERGE Behind a flag, used internally first Anthropic employees run it before it reaches everyone Gradual release The latest channel first; the stable channel trails it Watch, fix forward or roll back The author and on-call watch; flags turn off quickly, broken builds get reverted automated a person decides, scaled by risk recovery

FIG A Most of the path is automated; a person's attention goes where the risk is

LAYER BY LAYER

Six layers of checks, with rollback under them

problems in verification required CI AI review security review human approval merge queue + flags fast rollback problems in verification required CI AI review security review human approval merge queue + flags fast rollback

FIG B Each layer catches some problems and misses others. Few get through all of them, and rollback handles the rest.

1. The work is verified before anyone else looks

Most review now happens before a PR exists. We give Claude something it can run—like tests, a build or 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 our best-practices guide.

Before opening a PR, many of us also run a few internal skills: one hunts for bugs, one simplifies the diff, and one checks the behavior end to end. UI changes also get checked against our design guidelines.

Boris Cherny, who created Claude Code, has called giving Claude a way to verify its work probably the most important thing for getting good results. He estimates it makes the final result two to three times better, and writes, "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."

When the automated reviewer keeps flagging the same thing, we fix it at the source: in the skill, with a lint rule, or with updates to instructional files such as:

• CLAUDE.md tells Claude what the project is: the stack, the conventions, the goals and the non-goals. Every review loads it, so in a large codebase we keep it short and point to other docs from there. The reviewer also flags code that breaks a convention in it, and changes that make a line in it out of date.
• REVIEW.md, written by code owners, tells the reviewer what matters in their part of the code. We check separately whether the reviewer actually follows it. The good ones are short. They 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. They also ask for a summary that starts with a count and says plainly when there's nothing to fix.

2. AI review on every pull request

Every pull request gets a Claude review before a person looks. It reads the diff against the whole repo and the PR's stated intent, and asks: does the change solve its problem, fit the system, or break something else?

On a bug fix, it looks for the root cause. The public version, Code Review for Claude Code, is now generally available on Team and Enterprise plans, and /code-review runs a lighter version locally.

When we launched the research preview, the share of internal PRs getting substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings, and most small ones come back clean. Admins set each repo to Quick, Standard, or Deep. Deep is worth it where one missed bug costs more than the extra review time.

Findings get verified by other agents before humans review them. Several agents look for bugs at the same time. Then a separate group votes on each finding, and it only gets posted if enough of them agree it's real. Findings that are only about style, diagnostics, or cleanup get dropped. We A/B tested those filters on our own PRs before keeping them. What's left shows up as inline comments sorted by severity. Each is tagged Important, Nit, or Pre-existing, so a bug the PR didn't introduce doesn't look like the author's fault.

Every finding has to be answered. You either fix it or resolve the thread with a reason. Often an agent picks up the fix overnight, so the author comes back to a PR that's already been through another round.

3. Security review that can block

Security gets its own automated review too. A PR can't merge while any finding from the bug review or the security review is still open. You either fix it or close the thread with a short reason, which is how you clear a false positive.

If a later commit fixes the issue, the finding clears on its own. You can set up the same thing with the open-source security review GitHub Action or the /security-review command. Setup is covered in automated security reviews in Claude Code.

4. Automated checks that block

The usual: lint, type checks, tests on every platform, and a build. (We wrote about scaling CI for this volume here.) A typical CLI pull request may run dozens of checks before anyone looks at it. The PR template asks how the change was tested and how to undo it. Claude can fill that in, but the person who asked for the change signs off on it.

5. Human approval, scaled by risk

A docs fix and an auto-updater change carry different risk, so they get different review.

Risk	Examples	Human approvals
Low	Docs, copy, internal-only features, additive changes behind a flag	None required once automated review and security checks are green
Medium	Ordinary product changes, and changes to sensitive areas such as caching, the auto-updater, or system prompts	One person
High	The highest-risk code, plus a small set of paths that always need two people	Two people

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 doesn't. Some paths always need a person, anything owners have listed as sensitive and any CI workflow file.

Only trusted authors get the lighter paths. Only authors on the repo's trusted list get the lighter paths, mostly the team that owns it. Everyone else needs a second person to approve. An agent's approval never counts as a person's, either. Automated review can clear a low-risk change, but it can't fill a slot that calls for a human.

Whoever prompted the change is on the hook for it. On an agent-written PR, the person directing the agent counts as one of the required reviewers, the same as if they'd typed the code themselves.

An approval covers one specific commit. If new commits land that the system can't vouch for, like an agent's push or a merge someone resolved by hand, the approval has to be given again.

6. Merge queue, flags and a gradual release

The merge queue re-runs every check against main with the change applied, so two PRs that pass separately can't combine into a broken main. New behavior usually ships behind a flag to Anthropic employees first, and our heavy use often surfaces regressions before users do. Public releases go to the latest channel first. The stable channel trails it.

7. Fast detection, fast rollback

Some mistakes will still get through, so the last layer is about catching them fast. Flags turn off without a deploy. Claude Code has a weekly on-call rotation, and incident reviews ask which layer should have caught the issue.

Noticing a bad merge still depends on the author and on-call as well as the revert and incident dashboards. We don't yet have circuit breakers that tighten approval when those numbers move; engineers here want them before more code moves to zero-human merges.

One colleague said slowing down does lower your error rate, but mostly because you're doing less of everything. We'd rather get faster at noticing and fixing problems.

HOW WE MAKE THE REVIEWER BETTER

Our code review process is constantly improving in a loop.

Any incidents are now an eval. The team collected past PRs that caused incidents, with their fix-forwards and reverts, and had engineers who know that code confirm each bug and where it lived. The reviewer runs against that set daily.

Our incidents are the eval

png

Built from past incidents and reverts, run every day

Incident or revert a change that broke something Expert-checked case experts confirm the bug Added to the set each incident adds a case Change the reviewer its prompts, tools or model Daily eval run scored against every case Score went up? keep it; if not, drop it next change Incident or revert a change that broke something Expert-checked case experts confirm the bug Added to the set each incident adds a case Daily eval run scored against every case Score went up? keep it; if not, drop it Change the reviewer its prompts, tools or model

FIG C The eval grows with every incident, and every change to the reviewer is scored against all of it.

We measure noise by watching what people do with the comments. It's easy to catch more bugs if you don't mind flagging a lot of non-bugs, so we need a check on that. We sort every comment the reviewer leaves by how the person on the PR responded: they fixed it, said it was wrong, said the behavior was intentional, or decided it didn't matter. We also run the reviewer on PRs we know are clean and count how often it reports something that would have led someone to make a harmful change. Our priority, written down, is catching real bugs first and cutting review rounds second.

Noise costs more when the author is an agent. A person can wave off a nit in seconds. An agent fixes it, which means another commit and another round of review.

Review has to converge. An agent author and an agent reviewer can keep each other busy indefinitely. One CLI PR went through more than fifty rounds of review and fixes overnight before its author stopped it.

When we 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 rarely finding new bugs, it was finding a few more old ones each round.

We made it worse ourselves. We'd gotten used to running several rounds by default, since each pass catches something new. This can be worthwhile on a risky change, but not on every PR. The team now tracks rounds-to-pass alongside recall, and changed re-review:

• A round cap. After three rounds, the reviewer asks the author to step back and reconsider the approach.
• Diff-only re-review after the first few passes.
• Flag the class of bug, so the author fixes every instance, not one line.
• No repeats of findings already posted.

Review agents also run nightly over existing code, helping us catch old bugs before they show up somewhere else.

Internal pull requests, before and after the convergence changes

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 before after the convergence work 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 before after the convergence work

FIG D Fewer review rounds per internal pull request after the convergence changes

WHERE HUMANS STAY IN THE LOOP

Pulling a senior engineer out of deep work to catch a routine mistake costs far more than an automated review. At Anthropic, our jobs have moved from reading every diff to the decisions machines are bad at:

• Should we build this at all? Direction, taste and scope. One team that declared its review bottleneck solved still kept human review for changes from outside the team, so someone asks "should we even do this?"
• Risky code such as billing, the auto-updater and CI workflows.
• 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 can't 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.

Where a person decides

png

Five decisions stay with people; checks run everywhere else

Should we build it? Risky code Architecture Reading the evidence Owning the outcome automated checks run all the way around an automated check a person decides Should we build it? Risky code Architecture Reading the evidence Owning the outcome an automated check a person decides

FIG E People moved from reading every diff to the decisions machines are bad at

SHARING CONTEXT ACROSS THE TEAM

Code review's second job has always been to spread codebase understanding. Reading a teammate's diff is how you learn what changed and how the pieces fit. If machines do most of the reading, how does anyone learn the code?

We don't have a formal process for this. Nobody on the team keeps a complete mental model of Claude Code in their head, and we don't think anyone needs to. When someone wants to understand a part of the codebase, they ask Claude to write an explainer for exactly that slice. It takes minutes and reflects the code as it is today.

Some of us go a step further and have Claude build a small artifact that visualizes that part of the code and teaches it the way that person likes to learn.

If the goal is to spend human attention well, this beats reading trivial diffs line by line. A one-line copy change teaches you almost nothing. An explainer for the module you're about to change teaches you a lot. Our culture of defaulting to working on open Slack channels helps too, since you see what others are building while they build it.

"YOU LAND IT, YOU OWN IT"

If you land a small or medium change and something still goes wrong, it's a team norm that you usually fix it. A few things keep this from going badly:

• Changes are small, so they're easy to review, debug and revert.
• Everything is reversible. Flags, reverts and staged releases undo most mistakes in minutes.
• Blast radius sets the bar. Expensive code gets more people and more checks.
• Regressions surface fast through telemetry and internal use.
• It isn't blame. Owning a fix means you have the most context; incident reviews look at the system.

Ownership is also shared. Much of the team works in open channels where anyone can see what others are building, pick up a thread, or point a Claude at a gap, and feedback comes from people who don't own the code too. That openness is a big part of how quality stays high without a gate on every line.

WHEN WE CHANGE DIRECTION

Agents make it cheap to start things, so some work shouldn't land. Usually someone in the channel asks why, points at an earlier decision, or suggests a simpler route, and the author closes or reshapes the PR.

Since the code was fast to write, closing the 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.

HOW YOU CAN ADOPT THIS PROCESS

Most of the pieces to do this with your team exist today.

Before the pull request

• Give your 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 a REVIEW.md, and move repeated review comments into it.

On every pull request

• Require CI, and add "Testing", "Risk" and "How to revert" to your PR template.
• Add an AI reviewer (Code Review for Claude Code, or the Claude Code GitHub Action) on one repo, tune REVIEW.md for a few weeks, then widen.
• Add automated security review, and require every review thread resolved before merge.
• Match review effort to risk: a quick pass on routine changes, a deep one where a missed bug is expensive (Quick, Standard or Deep in Code Review).
• Cap review rounds; after the first few, re-review only the new diff.

Approval

• Write down risk tiers, set from the change rather than the author; start strict and loosen with evidence.
• Keep the lighter approval paths for authors you trust.
• Use CODEOWNERS and branch protection so auth, billing, CI and release workflows, and installers always need a person.
• Never let a bot's approval replace a required human's; dismiss approvals on new commits.

Merge and after

• Use a merge queue, feature flags, internal use first, staged releases and one-step rollback.
• Turn incidents and reverts into an eval set, and rescore the reviewer whenever its prompts, tools or model change.
• Measure human time, with revert and incident rates as the guardrail.

WHERE THIS IS GOING

Code Review's announcement said approving a pull request is still a human call; the product posts findings, not approvals. Our own repos go further, letting owners decide which low-risk changes merge on automated checks alone, and that line keeps moving.

When a review misses something, we ask what the model didn't have in front of it and put the fix into a CLAUDE.md, a skill or a new check. The goal hasn't changed: less human time per change, and no more reverts than before.

If your team lets agents open pull requests, we'd like to hear which checks you've automated, which still need a person, and what you think we have wrong.

With thanks to Emma Webb, Michael Segner and Amie Rotherham for their reviews.