8.0
热点
AI SCORE
行业动态2026-08-14 20:32
AI让代码产出增加33%，但review等待时间暴增441%
dev.to · AI#AI编程#工程数据#工作流
Editor brief · 编辑速览
Faros基于22000开发者的两年遥测数据：AI使任务吞吐量提升33.7%、PR合并率提升16.2%，但PR处于review状态时间增加441.5%、无review直接合并的PR增加31.3%、事故率增加242.7%。
每个在衡量 AI 辅助开发的人都在报告同样形状的结果：产出上升了，而检查这些产出的成本上升得更多。我想走一遍这些数字，因为两者之间的差距比大多数团队已经调整到的幅度要大得多，然后再说说我在一个小团队内部看到的景象——在那里，我自己承担了大部分评审工作。
Faros AI 发布了一份工程报告，基于两年间来自超过 4000 个团队、22000 名开发者的遥测数据。不是关于 AI 感受如何的调查，而是同一个组织内部 AI 采用前后的工作流数据。
交付侧有所改善：
评审侧的变化却截然不同：
同一份报告中，有两个数字描述了当这种压力无处释放时会发生什么：
所以团队写得更好了，而评审者面前的队列比作者身后的队列增长得更快。其中一部分队列通过根本不评审来解决，而事故数字也随之而来。
Sonar 的《代码开发者现状调查》于 2026 年 1 月发布，涵盖超过 1100 名开发者，补充了人的那一半：
把前两个数字放在一起看，你就得到了问题的形状。几乎没有人信任输出，而他们中只有不到一半的人验证了它。信任差距并不会自动转化为评审工作。它转化为评审工作——只针对那些有纪律或有责任的人，而对其他所有人则转化为风险。
那个 38% 是我最有共鸣的数字。
当你亲自写代码时，思维模型是在过程中逐步建立的。等到最后一行就位时，你已经掌握了每一个决策背后的理由，包括那些你拒绝掉的方案。评审不是这样的。评审是从一个成品反向重建模型，没有被丢弃的分支，没有作者决定这个方案值得一做的那一刻。
这在同事的代码上就已经很昂贵了，而在模型的代码上更昂贵，因为模型均匀地产生看似合理的工作。同事会发出不确定的信号。他们的提交信息会留有余地，他们会留一条评论，他们会在不确定的地方 ping 你。而生成的代码到处都是同样自信的表面，所以评审者没有梯度可循，必须对每个部分给予同等程度的注意力。
再加上上下文切换。每天 67.4% 的 PR 上下文增量意味着中断不只是成倍增加，而是按照别人的时间表到来。自动化运行的工作仍然会回到你这里，而且是在你选择的时刻之外回来。每一次回来都要付出重新加载你已经放下的上下文的代价。
我主要靠自己构建一个产品，AI agent 承担着越来越大的机械工作份额。自动化吃掉了打字。它没有触及检查环节，反而让等待检查的东西成倍增加。
我仍然不能直接把模型的结果发到生产环境而不去看它。从来没有过一次这样做过让我感到安全。所以评审这一层始终存在，而这一天实际上就花在那里了。我使用 AI 编程工具已经很长时间了，但只有当单个完成项变成一组并行运行的自动化时，负载才变得明显。瓶颈不再是我写得有多快，而是我能为不是自己做的事情重建上下文有多快。
我没有一套干净的规则来解决这个问题。真正对我有帮助的事情都很朴素：
这些都关闭不了那个差距。只是把它移动了一点点。
行业对话仍然主要关注生成质量，假设更好的模型会减轻评审负担。遥测数据表明，评审负载不是当前模型质量的一个 bug，而是你为之承担责任的委托工作的一个结构性质。即使准确度很高，也必须有人承担责任，而承担责任意味着重建上下文。
这就是为什么 Faros 报告中的生产力数字和评审数字应该被作为一个结果来读，而不是两个。吞吐量提升了三分之一，评审时间提升了四倍多。如果你的规划捕获了第一个数字而没有捕获第二个，你的团队正在某个地方吸收这个差异：在高级工程师的晚间时光里，在没有人看过的合并里，或者在事故数量里。
你的评审时间实际上花在哪里了，你做了什么改变让它变得可以承受？
Sources: Faros AI, "The AI Engineering Report 2026: The Acceleration Whiplash" (telemetry from 22,000 developers across 4,000+ teams). Sonar, "State of Code Developer Survey 2026" (1,100+ developers, published January 8, 2026).