AI编程代理多写30%代码，软件产出为何原地踏步

AI编程代理正在大量生成代码，但一项覆盖700多家企业的研究揭示了一个出人意料的事实：写得多，并不等于交付得多。

代码量暴涨背后的数字

据Ars Technica报道的一项哈佛研究，AI编程代理让代码行数增加了30%，提交（commits）上升20%，拉取请求（pull requests）增长23%。从这些指标看，AI似乎显著提升了开发效率。

但真正衡量软件产出的指标——完成的功能数量——几乎纹丝不动。这意味着团队确实在更快地「写」，却没有更快地「交付」。

提交（commits）与拉取请求（pull requests） 是衡量软件开发活动的两个基础指标。提交指开发者将本地代码改动记录到版本库（如 Git）的一次操作，粒度较细，可能只包含几行修改；拉取请求则是开发者请求将某个分支的改动合并进主干的正式提案，通常包含多次提交，并触发代码审查、自动化测试等流程。两者数量上升说明“动作”变多，但并不直接等同于“价值”增加——一个功能可能由数十次提交和多个拉取请求构成，也可能因返工而反复产生提交。因此，研究中“提交+20%、拉取请求+23%”与“完成功能数几乎不变”的背离，正是用活动指标替代产出指标时容易产生的统计幻觉。

瓶颈转移：代码审查成为新堵点

问题的核心在于代码审查环节。研究发现，审查时间激增49%，变更请求几乎翻倍，每个拉取请求的评论数上升35%。

为了应对审查压力，企业增加了14%的审查人员，但这并没有从根本上解决问题。AI生成的代码需要人工逐行把关，原本用于写代码的时间节省，被下游的审查负担抵消掉了。

这是一个典型的瓶颈转移现象：AI加速了上游的代码生产，却把压力集中到了下游的质量控制环节。

瓶颈转移（bottleneck shift） 源自约束理论（Theory of Constraints）：任何系统中总有一个环节决定整体吞吐量，局部加速非瓶颈环节不会提升系统产出，只会让在制品在瓶颈前堆积。在软件交付流水线中，编写、审查、测试、部署构成串行链条；当 AI 把编写速度提升 30% 时，审查环节若未同步扩容或自动化，就会成为新的约束点，表现为审查队列变长、审查时间上升 49%、变更请求翻倍。这也解释了为何增加 14% 审查人员收效有限——若审查仍以人工逐行阅读为主，人力扩充的边际收益会迅速递减，除非改变审查方式本身（如分级审查、自动化静态检查前置）。

为什么AI没能接管审查？

研究给出了一个关键数据：AI只处理了23.3%的审查评论，绝大多数检查工作仍然由人类完成。

这说明当前的AI编程工具在「生成」和「验证」之间存在明显的能力落差。模型可以快速产出代码，但在判断代码是否正确、是否符合团队规范、是否引入隐患方面，人类仍然是主力。审查本身需要上下文理解、业务判断和责任归属，这些恰恰是AI难以独立承担的。

AI 代码审查 通常指利用大语言模型或专用静态分析工具对拉取请求进行自动检查，包括风格一致性、潜在缺陷、安全漏洞等。当前这类工具的能力边界在于：它们擅长模式匹配和常见错误识别，却难以完成需要业务上下文、架构意图和责任归属的判断。例如，一段代码是否符合某个未写入文档的业务规则、是否会在特定并发场景下出错，往往需要了解需求背景的工程师拍板。此外，审查还承担着知识传递和团队规范维护的社会功能，AI 无法替代人际间的设计讨论。因此研究中“AI 仅处理 23.3% 的审查评论”并不意外——剩余部分恰恰是审查中最需要人类判断力的高价值环节。

对团队和就业的实际影响

研究没有发现软件产出显著增加的证据，同样也没有发现就业岗位因此减少的迹象。这与一些「AI取代程序员」的叙事形成对照。更准确的图景是：AI改变了工作分配，把人力从编写推向了审查和决策，但整体交付节奏受限于人工把关的环节。

对于工程团队而言，这项研究提示了一个务实的方向：如果只投资代码生成工具而不改造审查流程，效率收益会在下游被稀释。真正需要优化的是评审机制、自动化测试覆盖以及人机协作的分工设计。

AI让写代码变快了，但让软件真正上线，仍然是另一回事。

完成的功能数量（features completed） 是比代码行数、提交数更贴近交付价值的产出指标，通常以用户故事或需求项为单位统计。它之所以在研究中“纹丝不动”，是因为功能交付需要经过编写、审查、测试、集成等完整链条，任一环节的吞吐量受限都会拖累整体。这也说明评估 AI 编程工具的投资回报时，不能只看生成侧的效率数据，而应追踪从需求到上线的端到端周期时间（cycle time）和在制品数量（WIP）。若审查与测试环节未被改造，生成侧提速只会转化为更大的排队队列，而非更快的交付。