哈佛研究718家企业：AI写代码快了，整体交付没跟上

哈佛大学近日联合Jellyfish分析平台，对718家企业做了一项调研。结论是：AI编程助手和智能体确实能让代码产出变多，但完工工作量并没有跟着同步上涨。原因之一，是AI生成的代码把开发后期的工作量抬了上去，代码评审环节尤其明显。

这项研究的数据区间为2021年1月至2026年3月，涉及700余家企业、70万名员工，约3亿个工作事件。数据来自多个渠道：人力资源信息、代码版本控制系统、工单管理系统、谷歌日历等日程工具，还有GitHub Copilot、Cursor、Claude Code等生成式AI工具。

衡量编码产出，研究人员用了三项指标：新增代码行数、代码提交记录、合并请求。

从数据看，AI助手带来的编码提升幅度不大：代码行数涨12%，提交记录涨9%，合并请求涨5%，其中只有提交记录这一项具备统计显著性。AI智能体的表现则明显得多，三项指标分别增长30%、20%和23%。

论文作者用每名工程师每月解决的Jira工单数和大型需求数来衡量软件交付成果。工单被当作独立的工程任务单元，大型需求则对应规模更大的项目或功能。结果显示，编程助手没有让工单解决数量上升；AI智能体带来了12%的增长，但和代码行数30%的涨幅相比，差距不小。

为了弄清这个落差，研究团队把整个开发流程拆开来看。编码只是其中一环，前面还有功能与范围规划，后面还有代码评审、测试和部署。

团队根据Jellyfish数据推算了工时分配，又通过面向100名Prolific平台工程师的调研做了验证。结论是：工程师花在写代码上的时间只占30%至40%，其余时间都投在配套任务里。AI一旦把编码效率拉高，后面的配套任务就容易变成瓶颈。

数字摆出来更直观：合并请求的平均评审时长涨了49%，每条合并请求下的评论多了53%，需要返工修改的合并请求比例翻了一倍。参与代码评审的人占比同样上升14%，就算引入了AI辅助评审，局面也没变。作者还指出，合并请求相关工作量走高，没法拿单条合并请求体量增大来解释。

Reddit用户Prime_1在评论这项研究时表示：“每一行代码都是潜在风险”。用户markehammons顺着这个说法往下讲，点出了AI幻觉带来的额外风险：

合作对象不靠谱，风险就已经翻倍；而智能体比多数合作对象更不靠谱。它们可能毫无恶意，只是一门心思想把任务做完，却干出一堆离谱操作。

Reddit用户enigmamonkey则提出，故障平均恢复时长或许会越来越成为评估AI对软件开发影响的一项关键指标：

工程师写得越来越少、对自己交付的代码理解也越来越浅——照我的猜想，故障会更频繁，排查和修复也更费劲。代码库还在不断变大，而它变大是必然的。

Jellyfish是一家软件公司，提供衡量和分析软件工程绩效的平台。它接入了GitHub、Jira等工具的数据，帮助企业了解开发者生产力和软件交付情况。