现在使用AI写代码，已经不是什么新鲜事了。

以前一个功能需要花半天写完，现在把需求交给Claude Code、Codex或其他AI Agent，可能几十分钟就能生成代码。

但一个很现实的问题出现了：

程序员写代码越来越快，团队的软件交付效率真的提高了吗？

最近，哈佛大学一项研究给出了一个耐人寻味的结果：

AI Agent让代码产出增加了30%，但最终完成的软件工作量并没有出现统计上显著的增长。

更反常识的是，代码审查耗时反而增加了49%。

这背后隐藏着AI编程时代一个非常重要的问题。

01. 一项覆盖718家企业的研究

这项研究名为《Artificial Intelligence in the Firm: Bottlenecks in Software Production》。

研究人员Fiona Chen和James Stratton分析了718家企业、超过70万名员工、约3亿条工程活动记录。

数据覆盖2021年至2026年3月，包括GitHub提交、Pull Request和Jira任务等。

研究发现，企业引入AI Coding Agent之后：

• 代码行数增加30%
• Commit数量增加20%
• Pull Request数量增加23%
• PR审查至合并的平均耗时增加49%
• 每个PR的Review评论增加35%

这些数字证明，AI确实显著提高了代码生产速度。

但到了软件交付环节，情况却完全不同。

研究人员通过Jira Issue和Epic的完成情况衡量软件产出，发现它们的完成率并没有统计上显著的提升。

需要说明的是，这不意味着软件交付绝对没有增长，更不能说明AI编程毫无价值。

它真正揭示的是：代码生产效率的提升，并不会自动转化为整个团队的交付效率。

02. 为什么代码越多，Review反而越慢？

软件开发从来不只是写代码。

一个完整的功能，通常需要经历：

需求分析、技术设计、编码、Code Review、测试、集成、发布。

AI Agent主要加速了其中的编码环节。

但其他环节并不会因为代码生成速度提高，就自动获得同等程度的效率提升。

假设一个团队原来每天提交10个PR，Reviewer能够当天处理完。

现在引入AI Agent，每天提交的PR增加到15个。

如果代码审查能力没有同步提升，PR就会开始排队。

而且，AI生成的代码并不代表一定符合项目要求。

它可能正常编译、通过部分测试，却仍然存在业务逻辑错误、架构不一致、重复实现或潜在的安全问题。

Reviewer必须花时间理解这些代码为什么存在、是否满足需求、会不会影响其他功能。

研究还发现，需要修改的PR比例接近翻倍。

这意味着大量编码阶段节省下来的时间，可能又被消耗在后续的Review和返工中。

当代码生产速度超过代码验证能力，新的瓶颈就产生了。

03. AI编程真正需要优化的是整个交付链路

在我看来，这项研究对技术团队最大的启示，是应该重新设计AI参与软件开发的方式。

过去我们习惯这样使用AI：

给出需求，让Agent直接写代码，写完之后再由人工检查。

这种方式虽然简单，但很容易把所有不确定性集中到Code Review阶段。

更合理的方向，是把验证环节前移。

例如，可以尝试一套基于Spec、TDD和独立Review的Agent工作流。

首先，让Agent分析需求，形成明确的Spec，包含业务规则、边界条件和验收标准。

其次，把Spec拆分成小粒度Ticket，每个Ticket拥有清晰的完成条件。

然后，通过TDD先建立测试，再让Agent实现功能。

完成之后，再使用独立的Review Agent检查代码质量、架构规范、安全风险以及与Spec的一致性。

最后由人工重点审核关键逻辑和高风险变更。

这里有一个重要区别：

传统AI编程关注Agent能生成多少代码，而工程化AI编程更关注Agent能交付多少经过验证的变更。

当然，这并不意味着增加几个Agent就一定能解决问题。

如果自动生成的测试本身不可靠，或者Review Agent只会重复确认编码Agent的结论，仍然可能产生虚假的安全感。

AI验证同样需要独立性、可追溯性和必要的人工把关。

04. Tech Lead应该重新定义AI提效指标

很多团队评估AI编程效果，喜欢看几个数字：

开发者使用率提高多少？生成了多少行代码？每天完成了多少个PR？

这些指标可以反映AI工具的使用情况，却不一定代表真正的工程价值。

对于技术管理者，我认为更应该关注四个指标。

第一，Lead Time。

一个Story从开始开发到实际交付，需要多长时间？

第二，Review Time。

PR从提交到合并需要多久？等待时间是否越来越长？

第三，返工率。

代码是否频繁因为需求偏差、架构问题或测试失败而反复修改？

第四，缺陷逃逸率。

功能上线之后，有多少问题没有在开发和测试阶段被发现？

这些指标结合起来，才能更完整地判断AI到底是在提高交付效率，还是仅仅把工作压力转移给了下游。

尤其对于拥有多个模块、多个开发团队的大型App项目，局部代码生成速度往往不是最终交付的唯一决定因素。

05. AI编程的下一阶段，比拼什么？

过去，AI编程工具的竞争重点主要是模型能力。

谁写代码更快，谁能处理更大的代码仓库，谁能连续执行更多任务。

但当代码生成越来越容易，真正稀缺的能力也会发生变化。

需求能否被准确理解？

生成的代码能否被有效验证？

多个Agent能否可靠协作？

最终变更能否安全地集成进现有系统？

这些问题，可能比单纯提升代码生成速度更重要。

我认为，未来优秀的AI开发工作流，会越来越重视Spec、自动化测试、代码审查和工程约束。

对于程序员来说，理解系统、设计验证机制和判断代码质量的能力，也不会因为AI会写代码而失去价值。

AI可以让代码生产变得廉价，但让代码可靠地进入生产环境，依然需要完整的工程能力。

这或许才是这项研究最值得我们思考的地方。