哈佛研究发现：AI 编程智能体生成代码量增加 30%，但软件产出并未增加

哈佛大学一项针对 700 多家公司工程活动的研究发现，AI 编程智能体显著提高了代码产出——代码行数增加 30%，提交次数增加 20%，拉取请求增加 23%——但已解决问题或大型任务的解决率并未出现统计学上的显著增长。原因在于人工代码审查吸收了这些增益：平均拉取请求审查时间上升 49%，需要修改的拉取请求比例几乎翻倍。

这项研究由哈佛大学研究员 Fiona Chen 和 James Stratton 完成，标题围绕 Jellyfish 分析数据展开，PDF 可在 fion.ac/jellyfish.pdf 获取。Ars Technica 的 Kyle Orland 于 2026 年 10 月 9 日以“AI 编程智能体生成更多代码，但并未生成更多软件”为题进行了报道，副标题为“研究发现编码效率提升被人工审查‘瓶颈’‘吸收’”。

研究数据涵盖 2021 年至 2026 年 3 月的 3 亿个工作事件

该研究基于 Jellyfish（一个衡量工程团队细粒度产出的平台）的聚合分析数据。据 Ars Technica 报道，该数据集包含 3 亿个单独的“工作事件”——提交、拉取请求及类似工件——以及问题管理软件数据，涵盖 2021 年至 2026 年 3 月期间 700 多家软件开发公司的 70 多万名员工。一位引用论文原文的评论者指出公司数量为 718 家。

为了确定 AI 工具进入各公司工作流程的时间，研究人员将直接测量的 AI 使用情况与 GitHub 活动分析相结合，区分了 AI 编程助手（主要自动补全由人类编写的代码）和 AI 编程智能体（根据提示自主编写并提交代码）。随后，他们对不同组织在不同时间点引入工具前后的关键变量进行了“双重差分”回归分析。

代码量大幅上升；交付的功能并未增加

原始产出效应显著且一致。Ars Technica 报道称，在公司引入 AI 编程智能体后：

• 生成的代码总行数增加 30%
• 总提交次数增加 20%
• 拉取请求增加 23%

研究人员发现，交付的工作量没有相应变化。在 Jira 等工具中跟踪的问题和大型任务的解决率（研究中作为整体软件功能的代理指标）在引入 AI 工具后没有发生统计学上的显著变化。研究人员还发现，在引入 AI 前后，Jira 跟踪的问题在规模或复杂性上没有“构成性转变”，这意味着解决率持平并非因为团队处理了更大或更难的工单。

代码审查是吸收生产力增益的瓶颈

研究将缺失的产出定位在审查阶段。引入 AI 编程智能体后：

• 平均审查流程时间（从拉取请求提交到合并）膨胀 49%
• 要求修改的拉取请求比例几乎翻倍
• 每个拉取请求的评论数量增加 35%
• 执行代码审查的员工比例上升 14%

按照论文的框架，编码阶段获得的任何效率都被“生产过程中的下游约束所吸收”，“代码审查过程显著延长，拉取请求更可能需要修订，审查者留下更多评论”。研究总结称，“几乎没有证据表明公司因采用这些工具而增加软件产出或减少就业”。

AI 代码审查尚未承担主要负荷

在所研究的大多数公司中，AI 辅助审查已存在，但处理的工作量占少数。截至 2026 年 3 月，80% 的被测量公司使用了某种形式的 AI 代码审查，但 AI 智能体仅负责所有审查评论的 23.3% 和所有拉取请求的 10.8%。人类仍然承担了绝大部分审查工作。

研究未发现显著的就业效应

通过查看 Jellyfish 数据中的活跃员工总数，并交叉引用同一批公司的 LinkedIn 数据，研究人员写道，他们“无法将显著的就业变化归因于 AI”。从事代码审查的员工比例增加 14% 是现有工作的重新分配，而非员工总数的净变化。

批评一：数据主要来自 2025 年，模型已过时

Hacker News 讨论中最常见的反对意见是，该研究描述的世界已经向前发展。评论者 jefftk 写道：

正如学术论文的标准做法，这是对研究时世界状态的描述。但随后需要时间撰写并发表，之后媒体将其作为时事报道。在这种情况下，我们看到的是 2025 年的图景。主要智能体结果涉及的模型主要是 Claude 3.5 到 Sonnet 4.5、GPT-4.1 到 GPT-5，以及 Gemini 2.5。而且论文的设计意味着你主要看到的是部署初期的效果，那时公司尚未建立良好的审查流程。

评论者 hyperpape 表示其主管分享了这篇论文，他提取了具体的基线数据以支持相同观点：基线为每员工月 5,017 行代码，估计增加 1,494 行；每月 5.34 个拉取请求，增加 1.22 个；平均代码审查时间基线为 7.03 天。他认为这些小幅百分比增长证实了数据过时，并另外批评了使用均值而非中位数：

如果你的平均拉取请求搁置 7 天，显然你并不关心交付任何东西，智能体也不会改变这一点。

批评二：“更多软件”以关闭的工单来衡量

评论者 dcre 直接指出了因变量：

注意，他们将“更多软件”定义为“关闭更多工单”。你怎么看都行。他们辩称这是一个好的衡量标准，因为工单范围没有增加。值得考虑你是否相信这捕捉到了他们声称的内容。由于编码智能体而编写的额外测试是否体现在你的工作工单中？

批评三：样本恰恰排除了最可能受益的团队

由于数据集来自使用 Jellyfish 并产生可测量工作事件足迹的公司，几位评论者认为该研究在结构上遗漏了独立开发者、小型初创公司和个人项目。评论者 dolebirchwood 写道：

那么所有其他不使用 Jellyfish 的人构建的软件呢？那些没有同样运营瓶颈、确实比大型竞争对手构建更多的小公司呢？那些在没有 AI 的情况下永远不会创业、现在却开始创业并构建软件的独立创始人呢？

评论者 joshheitzman 给出了一个具体例子——一个名为 FluxImp 的项目，他们用 Kilo Code 启动，后来变得自我修改，主要在私有服务器上使用 Mercurial 开发，因此“GitHub 活动很少”。他补充说，“所有关于非软件工程师构建对自己有用的小型软件的故事，似乎也不太可能产生易于研究的足迹。”

评论者 KumaBear 更简短地表达了同样观点：“自制个人使用软件肯定激增了。我从未想过有时间做的项目现在都成为可能。”评论者 juliendorra 将这一时刻比作 HyperCard，描述了有限范围个人软件的繁荣——设计师为每个项目构建工具，开发者制作艺术软件，超级用户请求插件和自定义工作流。

批评四：瓶颈可能是组织性的，而非认知性的

几位评论者认为代码审查从来不是真正的约束。评论者 blauditore 提出了赛车类比：引擎最终会超过轮胎，因此超级燃料只能带来边际圈速提升。评论者 gchamonlive 表示沟通是软件生产中最难的部分，并且“软件生产已成为语言学的姊妹领域，比以往更甚”。评论者 jmward01 认为瓶颈在于团队以清晰愿景和正确下一步发展产品的能力，并且“我们行业的流程很糟糕”，这与 AI 无关。

评论者 forgotaccount3 指出规划仪式而非审查，描述了故事编写得足够精确，以至于“我们不妨将其复制到 AI 智能体中让它实现”，然后由于故事点和冲刺容量限制，在待办事项中搁置两周。

从业者对研究结果是否符合自身经验存在分歧

一些评论者报告称该研究符合他们的工作生活。Ars Technica 的员工精选，来自用户 metavirus，直言不讳：

我被迫在工作中使用 AI，这绝对 10000% 真实。大量劣质代码进入池子，数十人需要筛选、过滤糟粕，然后最终闭上眼睛发布到生产环境，因为现在我们有新的 SLA，以免被视为进展的瓶颈。

评论者 PacificSpecific 报告称一位朋友离职，因为 80% 的工作是审查 Claude 提交的代码。评论者 atleastoptimal 描述了新审查负荷的算术：“我现在每天‘审查’10,000 行代码，而不是 1,000 行。我的大脑并没有快 10 倍。”

其他人则报告相反情况。评论者 keithnz 表示他们的团队正在产出更多软件，并且更有雄心，归功于在规范、架构、编码、性能和测试指导方面的大量前期投入。评论者 tdhz77 写道：“自从 AI 出现以来，我创建了更完整的软件。这是一个疯狂的想法。”评论者 mrieck 认为，测试、审查和细化现在花费更多时间，正是因为生产的软件量更大，初创公司现在可以验证大约 10 倍于以前的事情。

为什么代码审查即使自动化也不会消失

评论者 zmmmmm 提出了问责制论点，这与代码质量不同：

自动化审查将有助于确保代码按预期运行，但不会确保意图是正确的。如果推动变更的人告诉 AI 这是预期结果，那么插入后门、绕过测试、在设计决策上“作弊”以更快完成工作的员工将不会被识别。

他们总结说，持久的保护是“一个愿意以自己的声誉冒险说‘我理解这个变更并批准它’的人”。

评论者 staminade 预测了审查文化变革首先出现的地方：不是成熟团队，而是“从一开始就采用无人工审查政策并在成熟过程中保持的初创公司”，这在当前研究中基本不可见。如果这些公司显著加快交付速度，staminade 认为，行业其他部分将被迫跟进。

研究未解决的问题

论文测量的是已经具备工程分析能力的公司，时间窗口截至 2026 年 3 月，使用 Jira 问题解决率作为已交付软件的定义。它没有测量个人项目、独立创始人或完全取代拉取请求工作流的团队。它还捕捉了智能体编码的早期部署阶段，当时大多数组织尚未确定 AI 生成代码的审查实践。

正如 Ars Technica 指出的，研究中 95% 的公司截至数据截止日期已实施 AI 编程智能体，且智能体能力此后持续变化。研究记录的“编码时间与审查时间”权衡可能会随着团队学习何时将问题交给智能体以及何时不交给而改变。目前，测量结果是双刃剑：更快的代码生成被人类审查时间和精力的相应增加所抵消。