一篇哈佛工作论文为常见的生产力说法提供了有益检验:借助 AI 写出更多代码,应该意味着交付更多软件。在使用 Jellyfish 工程分析平台的 718 家企业中,Fiona Chen 和 James Stratton 估计,采用编码代理之后,每名活跃员工的代码行数增加了 30%,提交次数增加了 20%,拉取请求增加了 23%。他们对已完成 Jira 问题和史诗任务的衡量没有显示统计显著的增长。论文当前版本日期为 2026 年 8 月 4 日;工作事件数据截至 2026 年 3 月。
这一差距对工程负责人很重要,因为拉取请求会进入审查、测试和可能修改的队列。同一项研究估计,采用代理后,从提交拉取请求到合并的经过时间增加了 49%。修改请求变得更常见,每个拉取请求的评论数也增加了。这些发现表明审查工作量更大,但并未说明每项由代理编写的修改都很差,也没有给出经过测量的缺陷率。
重大变化
- 变化内容:在这项企业层面的研究中,采用编码代理与编码活动大幅增加、拉取请求审查要求提高同时出现,但已解决问题或史诗任务没有统计显著的增长。
- 为何重要:代码行数、提交和拉取请求衡量的是进入生产流程的工作。已解决工作是更靠后的指标。若团队只按代码量评估代理,就可能忽视进入审查环节的负担。
- 关注事项:企业能否提高审查能力,以及后续数据是否显示已完成工作有所增加。这篇工作论文跟踪了截至 2026 年 3 月的早期采用情况,无法确定长期影响。
助手和代理产生了不同的估计结果
作者将助手与代理区分开来:助手会在开发者工作时提供代码建议;代理则可以接收更高层级的任务,并在开发者批准结果之前完成多个步骤。他们通过 GitHub Copilot 和 Cursor 商业许可证的激活情况衡量助手采用情况。对于代理,他们结合 Claude Code 使用数据,以及提交或拉取请求中的机器人账户、工具签名等信号。某些个人使用或未集成的工具可能无法被这些指标捕捉。代理估计值是相对于较早的助手采用时期,代理采用周边额外的关联;它并不代表每一位使用代理者的估计结果。
助手的结果较小:代码行数估计增加 12%,提交增加 9%,拉取请求增加 5%。在论文的主要估计中,只有提交这一结果具有统计显著性。代理采用在全部三项编码活动指标上都显示显著增长。提交记录一次代码更新;拉取请求则将修改提交审查。两者都不能证明功能已经到达用户手中。论文将已解决的 Jira 问题和较大的史诗任务作为后期产出指标,依据的是团队在审查、测试和部署后将工作标记为完成的跟踪流程。Jira 状态仍是交付情况的代理指标,而不是对用户实际收到内容的独立测量。
对于代理,已解决问题的估计增幅为每名员工每月 0.12 个,基线为 3.67,标准误为 0.17。该结果在统计上与零无法区分。史诗任务完成情况同样没有显著变化。作者报告称,其置信区间排除了研究期间问题完成量超过基线均值 12% 的增长。这一发现比“代理不会产出任何有用软件”更有限:仍可能存在适度增长,而且问题数量无法涵盖价值或质量的所有变化。作者使用预测任务时长指标检验问题规模是否变化,在样本中没有发现这种变化的证据。
更多工作进入审查环节
审查指标为产出差距提供了一种合理机制。采用代理后,论文估计从拉取请求提交到合并多花 3.45 天;基线为 7.03 天,增幅 49%。这是审查流程中的日历时间,并非对某人实际审查分钟数的计时。收到正式修改请求的拉取请求占比,相对于 13% 的基线约增加 12 个百分点;每项请求的评论数从 1.66 的基线增加 0.58,即增加 35%。每月审查过至少一个拉取请求的员工占比,相对于 29% 的基线约增加 4 个百分点,相对增幅为 14%。可比较的助手估计没有显示审查时长、修改请求或评论数显著增加。
仅凭这些元数据,论文无法判断审查者为何要求修改。更多提交可能使固定容量的审查队列承压;代码质量或审查标准变化也可能导致审查更严格。作者未发现拉取请求平均大小显著增加,这削弱了一种关于评论增多的简单解释。他们没有检查代码内容,也没有直接统计代理生成工作的缺陷。他们的两阶段生产模型解释了更快写代码以及每份草稿所需审查工作发生变化,如何共同限制已完成产出。该模型是对观察结果的解释,并非单独隔离任一机制的检验。
AI 审查工具也已在样本中普及:截至 2026 年 3 月,近 80% 的企业使用过一种此类工具。然而,论文将 23.3% 的审查评论归因于 AI,并发现 10.8% 的拉取请求至少含有一条 AI 评论。因此,采用审查工具并不意味着这些企业的审查已自动化。
研究设计能够说明什么
研究人员分析了 718 家同意参与的 Jellyfish 客户企业从 2021 年 1 月至 2026 年 3 月约 3 亿个工作事件,覆盖 725,938 名员工。他们使用分期双重差分设计,将企业采用助手或代理前后的结果,与较晚采用或尚未采用企业的结果进行比较。企业和日历月份控制变量处理了一些稳定差异和共同时间趋势。推断仍取决于这些企业在未采用情况下的发展路径是否具有可比性。规模较大的企业更早采用工具,未测量的变化也可能同时影响采用与工程工作。这是一项观察性研究,其估计不应被视为随机试验,也不应当作对所有软件团队的预测。
就业结果也需要同样谨慎。作者使用关联 LinkedIn 的总就业人数以及 Jellyfish 中的活跃员工衡量工程就业,无法将观察期内的显著变化归因于代理采用。这并不能说明经过更长时间调整后招聘会如何变化,也不能说明更广泛劳动力市场的情况。
BIG CHANGE 先前的报道探讨了另一项关于 AI 编码与可靠交付的工程案例。这项研究将视角扩展到多家企业,并分别衡量编码活动、审查和已解决工作。实际启示是,评估代理时应同时跟踪这些阶段:更快的初稿会改变下游等待处理的工作量,而这篇论文尚未显示已完成问题或项目相应增加。
来源与延伸阅读
- Fiona Chen 和 James Stratton,Artificial Intelligence in the Firm: Bottlenecks in Software Production:主要工作论文,当前版本日期为 2026 年 8 月 4 日。方法、图表和附录支持文中报告的估计及其限制;底层企业级数据为专有数据,且已汇总。
- Ars Technica 10 月 9 日的报道:引起人们关注该论文的同期独立报道。以上数值和方法论说法均已依据论文核查。
- BIG CHANGE 先前关于 AI 编码和 CI 的文章:对另一项工程案例的相关报道。它为交付问题提供背景,但不是本研究的后续报道。



