跳到正文
meng shao· @shao__meng · X·· 3 小时前AI 评分71
AI 导读

Addy Osmani 分享其团队在 Agent 时代重构代码审查的做法:当 Claude 编写了 Claude Code 约 90% 的代码、6 月到 9 月合并 PR 数量翻倍以上且回滚率下降超过 40% 时,瓶颈从写代码转向证明代码可用。

正文 · 原文

Addy Osmani 谈 Agent 时代代码审查的重构

Claude 编写了 Claude Code 约 90% 的代码,而在 6 月到 9 月间,团队合并的 PR 数量翻倍以上,回滚率反而下降了超过 40%,怎么做到的呢?

Osmani 认为:当 AI 生成代码的速度远超人类审查能力时,瓶颈从 “写代码”,转向了 “证明它能正常工作”。解决方法不再是让更多人逐行审代码,是构建一套多层的、快速确定性反馈的验证系统;正是这套系统让“90% AI 编写”从风险变成了优势。

几点关键做法

审查的重新定义。 审查的目的从“是否有人读过这段代码”变为“这个变更可能出什么问题,该由哪一层检查来抓”。审查不再是合并前的终点关卡,更像拼写检查;大多数变更在被人类看到之前,已经被 AI 审查并修复过至少一轮。

具体的分层流水线:
· PR 之前:Claude 运行测试、构建、linter,必须展示真实输出而非口头声称完成;另有一个全新上下文的 subagent 独立审查 diff。
· PR 上:必需 CI 阻塞合并;多个 AI 审查 agent 并行找 bug,由“验证者”投票过滤误报(内部 PR 获得实质性审查评论的比例从 16% 升至 54%);独立的安全审查流程。
· 风险分级审批:由分类器(而非作者本人)判定风险等级;低风险(文档、flag 后的增量改动)零人工,中风险一人,高风险(计费、自动更新等敏感路径)两人。AI 的审批永远不能占用人工名额。
· 合并之后:flag 灰度内部先行,出问题可不部署直接关闭;每周 on-call,事故复盘追问“哪一层本应拦住它”。

两个特别值得注意的工程细节:
1. 事故转化为 eval。收集历史上导致事故的 PR 作为每日评测集,AI 审查器的任何改动(提示词、工具、模型)都要在这个集合上跑分,分数不升就放弃。这把“审查质量”从主观感受变成了可度量的回归测试。
2. 强制审查收敛。一个 PR 曾一夜被 AI 审查了五十多轮;团队发现 59% 被反复标记的是早已存在的旧代码,于是设定三轮封顶、只审新增 diff 等规则。效果是一轮通过的 PR 从 65% 升至 78%。

人的角色如何变化
人类保留的决策是:做不做这个功能(方向与品味)、高风险代码的审批、会成为他人模板的架构决策、以及对证据的阅读和最终问责;"you land it, you own it"。工程师的工作从逐行阅读,转向评估风险、评估证据、决定方向。

Osmani 结语这句话我自己很喜欢,分享给大家
Let the agents do what they do best and let you focus on what makes you irreplaceable: judgement, direction, and ownership.

引用Addy Osmani@addyosmani
Give your agent a way to verify its work. This can dramatically improve the quality of output. With this process in place, Claude Code was able to write 90%+ of its code itself. When generating software at a faster rate than you can review it, the bottleneck shifts to proving that it works. @bcherny and team invested enough in verification, we've been able to move fast while maintaining stability. Code reviews aren't going away, but you need to think of it differently. One human reading through line-by-line is no longer going to work as a gate, it needs to evolve into a multi-layered verification system, built with fast deterministic feedback loops for your agents. This is where e2e tests, feature maps (as @poteto has been advocating), property tests and multi-agent adversarial reviews come in. These all provide opportunities to catch errors early and fix them before things get out of hand. You don't have enough eyeballs for the amount of code being written so your focus needs to be on product intent, risk assessment and evaluating evidence rather than reviewing code. Delegate the code checking work to your automated tests, scale your approvals based on risk, and turn your test failures into living evaluations. This approach helps maintain speed without losing reliability. Let the agents do what they do best and let you focus on what makes you irreplaceable: judgement, direction, and ownership. We tried to capture how we handle code review and verification in this writeup. Hopefully it's helpful.
在 X 查看被引用的帖子

来源:meng shao · x.com