Anthropic 把更多代码审查交给 AI，Bun 11 天完成 53.5 万行 Rust 迁移

Anthropic 将代码审查和测试更多交给 AI 完成，官方称每位工程师产出提升 200%；Bun 使用 Anthropic 的 Fable 在 11 天内并行迁移 535,496 行代码到 Rust，展示了 AI 在大型重写与验证环节的实际效果与成本可控性。

据 The Pragmatic Engineer 7 月 28 日发布的 How building software is changing at Anthropic，Anthropic 内部的软件工程正在明显向 AI 倾斜：更多代码审查和测试由 AI 完成，而 Bun 创始人 Jarred Sumner 也借助 Anthropic 的 Fable，在 11 天内把 Bun 从 Zig 迁移到 Rust。两篇报道和两家公司的公开博客合在一起，勾勒出一个越来越清晰的趋势：软件团队正在把“写代码”的重心，推向“验证代码”和“编排代码”。

关键信息
– Anthropic 的官方产品页 Bringing Code Review to Claude Code 说，过去一年 Anthropic 每位工程师的代码产出增长了 200%。
– Bun 官方博客 Rewriting Bun in Rust 写到，这次迁移覆盖 535,496 行 Zig 代码，使用 64 个并行 agent，API 价格下 token 成本约为 165,000 美元。
– Jarred Sumner 估计，如果纯靠人工，这项工作大约需要 3 名对代码库有完整上下文的工程师投入 1 年。
– Anthropic 这套代码审查系统已产品化：官方称它会在每个 PR 上派出一组 agent，平均审查约 20 分钟，且大 PR 更容易发现问题。

Anthropic 不是“少写代码”，而是“更早审代码”

The Pragmatic Engineer 的文章写道，Anthropic 内部并没有放弃传统工程纪律。相反，PRD、规划、团队对齐这些前 AI 时代的做法仍然存在，只是实现环节更依赖 AI。报道提到，在一些项目里，验证甚至比实现更耗时；代码审查和测试也越来越多地交给模型完成。

Anthropic 的官方产品更新则给出了更具体的数据。它称，Code Review 能把多 agent 审查嵌入到 PR 流程中，16% 的 PR 过去会得到实质性评论，如今这一比例提升到 54%。对大于 1,000 行的大改动，84% 会被发现问题；对小于 50 行的 PR，这一比例降到 31%。这些数据说明，AI 在这里不是“写点辅助代码”这么简单，而是被放到了质量闸门的位置。

这和 AIFlux 之前关于 微软实测：别为 agents 重写你的 CLI 的观察有相似之处：真正面向 agent 的系统，往往不是把接口简单改成“更像 AI”，而是保留足够稳健的约束，让模型在可控边界内工作。

Bun 的 11 天迁移，把“AI 重写大工程”变成了可计算问题

Bun 的案例之所以引发关注，是因为它把抽象的“AI 迁移代码”变成了可量化的工程项目。Sumner 在官方博客中说，这次迁移并不是一句“把 Bun 重写成 Rust”就完成的，而是先做了约 3 小时的规划，再写出一份 600 行左右的迁移指南，随后用多个 agent 并行推进，反复做对抗式审查和编译修复。

他还提到，自己用的是 Anthropic 的 pre-release 版 Claude Fable 5。Bun 官方给出的结论很直接：如果按传统方式做，这类迁移往往会拖成一年的大项目；借助 AI，整个过程被压缩到 11 天。

这类案例也呼应了微软在 Agent Framework 的 harness 加上四项扩展能力 中展示的方向：把技能、受控 Shell、CodeAct 和 background agents 模块化，让系统更适合并行分工，而不是把所有工作塞进单一上下文。

为什么这会改变软件工程组织方式

如果 AI 能把大规模迁移、重复修复和初步审查的成本打下来，工程师的角色就会更靠近架构设计、规则制定和验证。换句话说，团队不一定会因为 AI 而“少做工程”，但会更少把时间花在机械性搬运上。

不过，这并不意味着验证成本消失了。OpenAI 近期对编码基准的审计——OpenAI：剖析编码评测中的噪声——提醒人们：当测试、题目和评分本身有噪声时，模型速度越快，越需要严肃的质检机制。

从 Anthropic 到 Bun，这组案例更像是在说同一件事：AI 并没有让软件工程变得“不要人”，而是让人的工作重心从键盘前移到了流程设计、上下文组织和结果验证上。未来更重要的，可能不再是谁能最快写出代码，而是谁能更稳定地让代码被审、被测、被证明可用。