AI并未将瓶颈从编码转移到代码审查

许多人认为AI已经将软件开发的瓶颈从编码转移到了代码审查，但这一观点并不准确。事实上，编码从来不是瓶颈，代码审查也并非真正的约束。真正的瓶颈在于部署批次——大量已审查的变更堆积在等待部署的队列中。

一个简单的测试可以揭示真相：你的应用程序或服务有多少已通过代码审查但尚未部署和启用的变更？如果答案是没有或只有一个，那你的情况可能是个例外。但大多数情况下，这个数字超过一个，说明瓶颈在其他地方。我们的研究显示，一半的团队有2到10个变更堆积在批次中，四分之一有11到50个。超过90%的团队以批次而非单次变更的方式交付。

“编码从来不是瓶颈，现在也不是代码审查。”这一数字暴露了行业范围内的可见性差距。人们相信Claude Code、Cursor和GitHub Copilot将瓶颈从编码转移到了代码审查，但这忽略了审查之后发生的一切。这不是个人的失败，而是整个行业的误解。

我们如此习惯于批次工作，以至于它看起来像是理所当然的。它长满了苔藓，与周围的山丘难以区分。当你寻找加速软件交付的方法时，你不会看到它，因为它看起来不像一个问题，而是像事情一直以来的样子。

AI洪水涌入批次时会发生什么？编写代码是更长价值流中的一小部分，该价值流从机会开始，到用户获得所需价值结束。AI在某些领域比其他领域更有帮助，而端到端的收益取决于你是否注意到工作积累的领域。GitLab的2026年AI问责报告发现，85%的受访者同意AI已将瓶颈从编写代码转移到代码审查。然而，从部署批次可以看出，这些人中有92%可能是错误的，因为如果审查后有积累，说明代码审查不是瓶颈。加速审查只会让真正的瓶颈更严重。

这并不是说编码速度的提高不会给代码审查带来压力。Faros AI对10,000名开发者的研究发现，AI采用率高的团队合并的拉取请求增加了98%，但审查时间增加了91%，平均拉取请求大小增加了154%。Cursor自身的研究也发现，公司在使用其编码代理后合并的拉取请求增加了39%。然而，更快地批准变更只有在变更随后顺利流向生产环境时才有效。在大多数情况下，它只是进入等待进一步处理的队列，如测试和部署。如果提高通过审查阶段的变更速度和规模，压力就会转移到真正的瓶颈。

代码审查看起来像是一个约束，只是因为它有一个可见的队列，而下游队列因其在行业中的普遍接受而被隐藏。你的管道的任务是将变更送到生产环境供用户使用，而不是将它们收集在“待部署”队列中。随着所有未发布变更的积累，风险也随之增加。

批次是路标。询问批次大小问题，你会发现真正约束价值流的是什么：一个手动验证步骤、一个繁琐的变更审批或发布列车流程，或者没有简单的部署方式。不是编码，不是代码审查。很可能在AI计划之前你就已经在以批次方式工作。AI的引入会增大批次大小，这可能带来问题。提高代码审查吞吐量并不能解决问题，它只是更快地将变更移到瓶颈处。

利用真正的约束来设定整个价值流的节奏，将帮助你投资解决正确的问题。如果回顾会议未能产生显著改进，你很可能会错过批次问题。这就是为什么一些AI计划成功而另一些失败的原因。

研究也忽略了这一点。关于AI影响的研究是有用的，但像许多研究一样，它们在代码合并处停止。它们考察开放的拉取请求、合并的拉取请求和审查花费的时间。没有一项研究询问变更在审查后等待了多久，或者有多少变更被捆绑在一起才有人在生产环境中看到它们。没有这个数字，你就无法找到真正的约束。

投资AI来加速编码之后，你可能会想修复代码审查，或者完全放弃代码审查。如果你以批次方式交付，这两者对于快速消除风险或向用户交付价值都无济于事。你的组织抵制修复批次问题的原因才是你需要解决的真正问题。