Anthropic 的一篇新博客给出了几组数字：工程师交付的代码量增加了 8 倍，其中 80% 由 Claude 编写，CI 任务在六个月内增长了 25 倍，测试量增长了 10 倍。

这组数据被一位作者当作案例研究来解读，核心不是"AI 写了多少代码"，而是当生产代码的产出速度被拉高之后，验证环节会发生什么。

瓶颈换了位置

Thariq 在最近的一次采访中给出了一个判断：你应该拥有比以前多约 100 倍的测试代码。他的理由是，瓶颈正在从"生产代码"转向"验证代码"。

把这句话和上面的数字放在一起看，逻辑就清楚了。当写代码这件事本身变快，卡住交付的就不再是写，而是确认这些代码到底对不对。测试量增长 10 倍、CI 任务增长 25 倍，都是这个转移的结果。

正方：验证必须跟着放大

支持这一判断的一方，依据是交付量的变化。代码量增加 8 倍、其中 80% 由 Claude 编写，意味着人工逐行审阅的路径已经走不通。要维持同样的可信度，验证的规模只能同步放大，测试代码的数量级提升是必然选择。

反方：规模本身就是新问题

另一方的疑问在于，测试量增长 10 倍、CI 任务增长 25 倍之后，管理这些验证本身就成了负担。测试跑得越多，需要维护的用例、需要判断的失败、需要分流的任务就越多。验证不是免费的，它自己也会变成一条需要被管理的流水线。

我的判断

两边的分歧其实不在"要不要更多测试"，而在"多出来的测试由谁来管"。素材给出的答案是：这篇博客本身就是管理这种规模验证的一个很好的案例研究。

换句话说，问题已经从"AI 能不能写代码"变成了"当 AI 写了 80% 的代码，你用什么方式确认它没写错"。测试量增长 10 倍只是这个问题的表面读数，真正被改变的是工程流程里验证环节的权重。