700家企业实测AI编程代理：代码量暴增30%，产出为何纹丝不动

代码写得更多了，软件却没多出来

过去两年，AI编程代理（AI coding agents）被反复包装成软件行业的"超能力"——给个指令，它自己写代码、提交合并请求，几乎不需要人插手。按照这个逻辑，企业应该很快就能交付更多软件才对。但一项覆盖700多家软件公司的研究给出了截然相反的答案：代码量确实涨了，可真正完成的工作几乎没有变化。

这项研究由哈佛大学的Fiona Shen和James Stratton完成，数据来自工程效能分析公司Jellyfish，覆盖2021年至2026年3月、超过2000名工程师、约3亿条工作事件，样本规模在同类研究中相当少见。研究者采用了"企业自身前后对比"的设计：同一家公司采用AI代理之前产出什么，采用之后又产出什么。

结果呈现出一种割裂感。采用代理后，代码行数平均上升30%，提交（commits）增加20%，拉取请求（pull requests）增加23%——表面看一片繁荣。但当研究者转向Jira中记录的任务、故事和史诗（epics），也就是"有人要求做、有人确认做完"的那些工作项时，任务完成率没有出现统计上显著的变化。

他们还专门排查了一种可能的解释：企业是不是把任务拆得更小更简单了？答案是否定的，任务记录的规模和复杂度都没有明显改变。代码成倍增长，软件交付却原地踏步。

AI编程代理（AI coding agents） 指能够接收自然语言指令、自主完成编写代码、修改文件、提交合并请求等任务的AI系统，代表产品包括基于大语言模型构建的编程助手（如GitHub Copilot的代理模式、Cursor的Agent功能、Devin等）。与传统代码补全工具不同，代理具备多步骤规划和工具调用能力，可在较少人工干预下完成端到端的开发任务。这类工具在2023年后快速进入企业开发流程，被寄予大幅提升软件交付效率的期望，也因此成为评估AI对生产力实际影响的关键研究对象。

瓶颈不在键盘，在评审台

多出来的代码去哪了？论文用一句话点破了机制："效率增益被生产过程下游的约束吸收了。"换句话说，写代码从来不是唯一的难关，问题出在代码写完之后。

最明显的堵点是代码评审。研究观察到，引入代理后评审环节反而变长了：拉取请求需要更多轮修改，评审者留下的评论更多，有研究摘要提到单个PR的评审时间上升约49%。这个数字不难理解——如果代码量涨了30%，就得有人去读、去理解、去判断这30%到底对不对。而写代码的机器不会累、不会烦，也不会考虑评审者有没有时间。

用一个比喻来说：往瓶子里灌水的速度再快，流出来的量取决于最窄的瓶颈。AI把上游产能放大了，下游的人类判断力却没有同步扩容。理解需求、决定做什么、审查是否可靠、与现有系统集成——这些环节依然依赖人的判断，而它们才是真正的限速环节。

这也解释了为什么"AI让程序员失业"和"AI让软件供给爆炸"这两个流行叙事同时站不住脚。研究并没有说AI没用，它说的是：写代码的成本降下来之后，价值重心会从"写得更快"转向"审得更好"，从"生产更多"转向"决定不生产什么"。

代码评审（Code Review） 是软件开发中的质量把关环节：开发者提交拉取请求（PR）后，由其他工程师逐行阅读代码、提出修改意见、确认逻辑正确性与系统兼容性，通过后才能合并入主干。它通常包括多轮往返修改，是保证代码可维护性和安全性的核心机制。评审的效率高度依赖评审者的时间与认知带宽——评审者必须理解代码意图、判断潜在风险，这一过程难以完全自动化。当上游代码产出激增时，评审队列积压、评审时间延长，往往成为限制整体交付速度的结构性瓶颈。

用AI审查AI写的代码，问题解决了吗？

一个顺理成章的应对思路是：既然评审是瓶颈，那就用AI来评审。目前确实有相当比例的代码评审由AI参与完成，但按研究引用的说法，这仍被视为少数情形。

这就引出一个不太舒服的问题：如果一段代码由AI写出、又由另一个AI审查，人类的判断力究竟在哪个环节介入？如果两个模型共享相似的盲区，评审可能变成一种形式上的确认，而非真正的把关。研究没有给出定论，但它把这个问题摆到了台面上——在追求吞吐量的组织里，这个问题很容易被忽略。

说个细节，这项发现与不少一线开发者的体感是吻合的：AI生成的代码看起来漂亮，但合并前的返工、解释和争论反而变多了。生产力工具的收益，往往被组织流程的摩擦悄悄吃掉。

结论之前，先说清楚限制

把这项研究当成定论之前，有几条边界需要交代清楚。

首先，这是一份工作论文（working paper），尚未经过正式的同侪评审。其次，数据截止到2026年3月，而这类技术几个月就会变一轮，结论的保质期有限。第三，研究呈现的是企业层面的平均值，完全可能存在某些团队把代理用得很好、另一些团队几乎无感的情况。第四，Jira是衡量"完成工作"的合理指标，但并不完美——有些工作不记录在Jira里，有些记录方式本身就有偏差。另外要说明的是，"没有统计显著变化"不等于"零变化"。

还有一个利益相关的细节：Jellyfish本身销售工程效能分析工具。这不意味着数据有问题，但读者心里应该有一杆秤。

工作论文（Working Paper） 是学术研究中在正式同行评审之前公开流通的论文形式，通常发布于SSRN、arXiv等预印本平台或机构工作论文系列。其特点是研究方法和初步结论已经成形，但尚未经过独立专家匿名评审，可能存在方法缺陷、数据问题或结论偏差。工作论文常被引用以快速传播新发现，但读者应将其视为"待验证的初步结果"而非定论。在AI这类快速演进领域，工作论文的结论尤其需要结合后续同行评审版本和复现研究来综合判断。

真正的问题换了

回到最初的设想：给企业一个能多写30%代码的超能力，结果软件交付纹丝不动。意外之处不在于"AI没用"，而在于瓶颈从来就不在写代码这一环。

行业花了很多年相信软件的问题就是写代码太慢。现在代码几乎免费了，人们才开始看清：真正稀缺的是理解、信任和批准的能力。问题不再是"机器能写多少代码"，而是"一个人能读懂、敢信任、愿批准多少代码"。至少目前，这个答案没有变。

对企业的实际启示也相当具体：引入AI编程代理时，如果只盯着代码产出指标，很容易制造出一堆等待评审的库存。真正该同步扩容的，是评审能力、需求澄清和集成流程——那些AI暂时替不了的人类判断环节。