Bun 的 Rust 重写，像一场突然放大的 code review。
11 天，6,778 个 commit，diff 超过 100 万行。高峰时，Claude 每分钟写出约 1,300 行代码。按 API 价格折算，pre-merge 阶段大约花掉 16.5 万美元。
这些数字很容易抢走注意力。
但 Bun 作者真正停下来的地方，是另一个问题：这么大的 PR，怎么确认它还能被合并？
审查压力的来源
Bun 不是普通业务项目。它是 JavaScript runtime，里面有 bundler、package manager、test runner、Node API 兼容层、HTTP、TLS、SQLite 等一整套长期运行的系统。
这次迁移也不是简单翻译语法。
Zig 里的释放时机、异常路径、边界值，在 Rust 里都可能变成另一种行为。编译通过，只能说明它能运行；行为等价，还需要另外证明。
Bun 官方列过几个 review 抓到的问题：异步 close 后的 use-after-free，负数时间戳拆分错误，unwrap_or 提前求值导致 panic。它们都不像语法错误那样醒目，更像迁移后的细小错位。
验证系统的重心
Bun 没有让 Claude 写完以后交给人类逐行读。
他们把迁移拆成 workflow：生成 porting guide，分析 lifetime，迁移文件，修编译错误，跑测试，做重构。实现 Claude 只负责写，另外的 adversarial reviewer 在独立上下文里专门找错。
人类仍然在场，但位置变了。
人不再逐行审 100 万行代码，而是看测试是否独立、reviewer 是否隔离、错误有没有反馈回生成流程、最终风险有没有人签字。
这才是 Bun 这次真正有价值的地方。
它告诉团队的重点已经不在“AI 可以写很多代码”。这件事已经发生了。
下一步要建设的，是一套能审查生成物的系统。代码会越来越快，信任只能一层一层建。
