10 月 22 日同一天发布的三份报告，从不同角度给出了同一个结论：AI 编程智能体让代码量和评审工作量一起涨，但真正交付的价值没有同比例增加。
数字对不上
哈佛的一篇工作论文统计了 718 家企业、3 亿条工作事件：采用 AI 编程智能体后，代码行数增长 30%、提交增长 20%、拉取请求增长 23%，但 Jira 里 issue 与 Epic 的完成率没有统计显著变化。论文把落差主要归给评审——PR 从提交到合并的平均时长涨了 49%，被要求修改的比例接近翻倍，每个 PR 的评论数涨了 35%。
评审成了新的瓶颈
LinearB 基于 810 万个 PR 的基准更直白：AI 智能体提交的 PR 平均要等 17.6 小时才有人评审，是普通 PR（3.4 小时）的 5.25 倍；30 天内合并率 32.7%，普通 PR 是 84.4%。Faros AI 另一组来自 2.2 万名开发者的数据里，PR 评审中位时长涨了 441%。
代码质量的那笔账
同一批报告里，缺陷数与每 PR 事故率都在走高。LocalStack 的调查显示，65% 的团队代码产出至少翻倍，54% 反馈 AI 生成代码缺陷变多，约 40% 的 AI 生成代码从未进入生产。原因不神秘：模型不理解你们系统的约定与架构决策，写出来的东西「看着对」。
对企业意味着什么
- 别拿代码行数或 PR 数当生产力指标，那只是活动量，不是产出。
- 把评审容量当稀缺资源排期。评审人力不增加，AI 只会把队列拉得更长。
- 给 AI 生成的代码配独立的质量门禁：静态检查、单测覆盖、变更范围限制，缺一不可。
- 先从有测试兜底的模块开始用，别拿没有回归验证的老系统试刀。