AI 还没取代程序员，先让开发工具扛不住了

过去，我们嫌写代码慢。现在开始遇到另一种烦恼：代码来得太快，后面的系统接不住。

Anthropic 在 2026 年 10 月 13 日披露，其每日合并的代码变更从 5 月约 2500 次，增长到 9 月超过 3 万次。为了应对这种规模，公司将内部单体代码仓库迁移到了自研版本控制系统 Scion。

这个消息很容易被压缩成一句“Git 要过时了”。但 Anthropic 自己也强调，Scion 面向特殊的大规模负载，并不适合作为通用的 Git 替代品。

更值得关注的是，软件生产的节奏变了。

想象十名工程师同时工作。他们需要理解需求、写代码、调试，提交之间有自然的间隔。换成大量并行工作的 Agent，拉取仓库、保存修改、运行测试，都可能密集发生。

而一次代码变更，往往会触发更多工作：自动构建、代码扫描、测试和审查。代码写得越快，这些环节要承接的请求就越多。

写代码的速度提高十倍，交付速度未必也能提高十倍。

就像一家餐厅添了十台自动炒菜机，出餐口还是那么宽，打包台还是那么大。菜做得更快，接下来暴露出来的就是排队。

GitHub 也在 10 月介绍了面向 Agent 工作负载的 Git 基础设施重建。它列出的压力包括持续增长的写入、争用同一主干的合并，以及一次推送引发的大量读取。

对普通团队来说，这并不意味着明天就该换掉 Git。更实际的动作，是重新看看一次修改从提交到上线，时间到底花在哪里。

如果大部分时间耗在重复测试，就研究如何减少无效执行；如果耗在审查等待，就控制变更大小、明确负责人；如果经常出现合并冲突，就检查任务拆分和并行方式。

这些事情没有换一个更强的模型那么醒目，却可能直接决定团队能否获得真正的提速。

还有一个容易忽略的问题：AI 增加的产量，是否都值得进入这条流水线？不必要的重构、重复的修复、过大的改动，同样会消耗测试和审核资源。

当生成能力不再稀缺，让有价值的修改顺利到达用户手里，就更值得投入。

下一次评估 AI 编程工具时，除了问它多久写完代码，也可以多问一句：这次修改，多久才能可靠地上线？