让 AI 写代码，公司真的产出了更多软件吗？一份对超 700 家公司真实工程数据的分析给出了一个反直觉的答案：代码是多了，软件没多。哈佛的两位学者 Fiona Chen 和 James Stratton 用 Jellyfish 的工程团队聚合数据做研究，覆盖 3 亿个独立工作事件（commit、PR 等）、超过 70 万名员工的记录、700 多家软件公司，时间从 2021 年横跨到 2026 年 3 月。
引入 AI coding agent 之后，原始代码产出确实在起飞：公司总代码行数平均增加 30%，commit 数量增加 20%，pull request 增加 23%。但所有这些多出来的代码，并没有转化为公司层面的软件产出提升——Jira 这类工具跟踪的 Issue 和 Epic（也就是完整软件功能）的解决率，在引入 AI 工具后没有出现统计显著的变化，这些 issue 的规模和复杂度也没有发生可观测的『构成性转移』。
差距卡在 code review 上。研究者发现，一个 PR 从提交到被合入的平均审查时间，在引入 AI agent 后平均膨胀了 49%；要求改动（changes requested）的 PR 占比几乎翻倍，每条 PR 的评论数增加了 35%。AI 多出来的这些代码，大部分成了人类审查负担的增量。
作为回应，公司里参与 code review 的员工比例上升了 14%。而这些审查工作，AI 自己还没接手——截至 2026 年 3 月，虽然 80% 被调研的公司用了某种 AI 代码审查，但 AI agent 只写了 23.3% 的审查评论、只处理了 10.8% 的 PR，绝大多数审查还是人干的。
研究者还发现，没有证据表明 AI tooling 带来了显著的就业变化——把 Jellyfish 里的活跃员工总数和 LinkedIn 数据交叉比对后，无法把明显的雇佣变化归因于 AI。换句话说，效率提升发生在编码阶段，但被下游生产流程里的约束吸收掉了。
文章提醒这仍然是个新事物：研究数据截止到 2026 年 3 月，95% 的公司已经部署了 AI coding agent，但多数还在摸索什么时候、拿什么任务去用它们最合适。编码时间和审查时间的这种此消彼长，可能随着工程团队积累更多经验而改善。就眼下而言，让 AI 写代码是一把双刃剑——编码速度的提升，被同样增长的人类审查时间和工作量抵消掉了。这也是为什么我们值得怀疑：让 AI coding agent 真正跑起来的时间成本和经济代价，对大多数公司到底值不值。
来源：