AI 编程智能体写出更多代码，却没有交付更多软件

长期以来，业界默认一条朴素的推论：只要 AI 编程助手和编程智能体能把代码写得更快，软件的产出就会按比例增加，企业甚至可以据此精简工程团队。Ars Technica 报道的一项新研究却给这条推论泼了冷水。哈佛大学的研究者 Fiona Chen 与 James Stratton 分析了数百家公司的真实工程数据，结论是：几乎没有证据表明采用这些工具的企业提高了软件产出或减少了雇员。换句话说，代码确实变多了，但软件并没有因此变多。 这项研究的数据基础相当扎实。它使用了工程度量公司 Jellyfish 汇总的分析数据，涵盖约 3 亿个「工作事件」，例如提交和拉取请求，并结合议题管理软件的记录，覆盖超过 700 家软件开发企业、70 余万名员工，时间跨度从 2021 年到 2026 年 3 月。研究者既用了直接测得的 AI 使用情况，也通过分析 GitHub 上的活动，判断每家公司究竟从何时开始引入工具。他们还区分了两类产品：一类是辅助补全、代码主要仍由人撰写的 AI 编程助手，另一类是根据提示自主编写并提交代码的 AI 编程智能体。在此基础上，他们采用「差分之差」回归，比较各公司在引入工具前后的关键变量变化。这种设计的价值在于，它把时间趋势和公司之间的固有差异拆开，比简单对比用户与非用户更接近因果判断。

真正有意思的是研究对原因的解释。作者认为，编码阶段获得的任何效率提升，都被生产流程下游的约束「吸收」了，而最突出的约束就是人工代码评审。数据显示，随着 AI 的引入，代码评审所需的时间明显拉长，拉取请求更容易被要求修改，评审者留下的评论也更多。这与每一位程序员的亲身体验吻合：AI 生成的代码看上去能够运行，但没有人敢不加检查地信任它，于是正确性的核验成本从作者一端转移到了评审者一端。生产线上一个环节被大幅加速，而相邻环节的产能没有变化，整条产线的吞吐量就由最慢的那一环决定。这正是制约理论中的老道理，只不过这次的瓶颈从「写」变成了「读」。 对行业而言，这一发现有几层含义。第一，单纯以生成代码的行数、提交数或工具采用率来衡量 AI 的价值，很可能产生误导，因为这些指标恰好处在流程中被放大的那一端。第二，企业若希望真正兑现生产力红利，就不能只采购更强的生成工具，还要同步投资评审环节：更好的自动化测试、静态分析、规范约束，以及能够辅助评审而不是只会生成的智能体。第三，「AI 让工程团队缩编」的叙事缺少数据支持，至少在研究覆盖的时间窗口内，雇佣规模并没有出现明显下降。需要强调的是，这并不等于 AI 没有价值，研究所说的是公司层面的产出与雇佣指标没有可见变化，而不是个别任务上的速度没有提升。

从工程管理的角度看，这一结果还揭示了一个常被忽视的事实：软件交付是一条由需求、设计、编码、评审、测试、发布和运维串联起来的链条，编码只是其中一环，而且往往不是耗时最长的一环。当 AI 把这一环的成本压得很低时，原本被掩盖的下游问题就会暴露出来。评审者需要理解不是自己写的代码，需要判断它与既有架构是否一致，需要确认边界条件是否被覆盖，这些工作依赖上下文与经验，很难随着模型变强而自动消失。更棘手的是，生成越快，积压的待评审改动就越多，评审者的注意力成为稀缺资源，质量把关反而可能因疲劳而松动。因此，团队在引入智能体的同时，需要重新设计工作方式：限制单次改动的体量，要求智能体附带测试与变更说明，把可自动判定的检查前移到提交之前，让人类评审者把精力留给真正需要判断力的部分。

这一发现也为工具厂商提出了新的课题。过去几年，竞争的焦点集中在谁的模型写得更准、谁的智能体能独立完成更长的任务，评价标准多半是基准测试的通过率。然而，如果企业层面的产出并未随之改善，那么下一阶段的差异化就很可能来自「可审查性」：智能体能否把改动拆成易于理解的小块，能否解释自己为何这样修改，能否主动给出可复现的验证证据。对采购方来说，更合理的问题不再是「它能写多少代码」，而是「它交付的代码需要多少人工时间才能放心合并」。 当然，这类研究也有局限。数据截止于 2026 年 3 月，而模型和智能体的能力、企业的工作流程都在快速演进，评审瓶颈未必是永久性的。如果未来的智能体能够生成更小、更易验证的改动，或者能够附带可检验的测试与证据，评审成本有可能下降。同样，软件产出的度量本身就困难，提交和拉取请求只是代理指标，并不能完全反映交付给用户的价值。但无论如何，这项研究提醒我们：在智能体时代，真正稀缺的不再是写出代码的能力，而是以可接受的成本确认代码正确的能力。谁能把验证环节做得更快、更可靠，谁才更有可能把「更多代码」变成「更多软件」。