资历倒置：为什么当 Agent 加速时，你的资深工程师反而变慢了

你的团队采用编程 Agent 的那个季度，发生了两件没人会放在同一张幻灯片上的事情。吞吐量上升了 —— 更多的 PR、更多的合并代码、更多的工单被关闭。然而，你最资深的三位工程师却变慢了。这种慢不是因为偷懒，而是因为“溺水”。他们自己的提交量枯竭了，日历被评审任务填满，一对一面谈的主旋律也从“这是我交付的内容”变成了“我花了一整周时间在帮别人排障”。

这就是“资历倒挂”。那些本该通过 AI 获得更多杠杆效应的人，反而被它埋没了。这既不是动力问题，也不是工具差距，而是 Agent 改变工作形态后的结构性后果：它们让生成变得廉价，而让验证变得昂贵。验证正是你无法交给初级人员或其他 Agent 的那一项任务。

数据很快就印证了这些轶事。METR 在 2025 年的一项随机对照试验中，让经验丰富的开源开发者在他们已经贡献多年的仓库中执行任务。结果发现，使用 AI 工具让他们变慢了 19% —— 尽管这些开发者事先预测会提速 24%，事后也依然认为自己变快了。这种认知偏差就是整个故事的缩影：工作感觉更快了，因为打字变快了；但真正制约交付的部分 —— 判断输出是否正确 —— 却变得更繁重，并转移到了更少的人手中。

生成变廉价，验证变昂贵

在软件历史的大部分时间里，编写代码和评审代码的成本大致处于同一量级。一份花了一天时间编写的代码变更，大约需要一小时来评审，这个比例维持得很好，以至于评审从未成为瓶颈。但 Agent 打破了这个比例。

当一个 Agent 能在四分钟内生成一个 600 行的 PR 时，生成变更的成本几乎坍缩为零。但信任该变更的成本却完全没有下降 —— 如果非要说的话，它反而上升了，因为输出在语法上非常整洁，这掩盖了缺陷。Agent 生成代码的失败模式并不是 Linter 能捕获的拼写错误或缺失的分号，而是对需求的误解、看似合理实则错误的边缘案例处理，以及逻辑上正确解决了与你设定的问题略有偏差的问题。看起来正确但微妙错误的代码是评审成本最高的东西，因为没有任何表面信号能标记它。你必须重构意图，并逐行对照实现进行检查。

相关的遥测数据非常残酷。追踪数千名开发者的工程智能平台报告称，在 AI 采用率较高的情况下，平均 PR 规模增长了一半以上，首次评审时间（time-to-first-review）攀升了约 157%，而评审的中位耗时攀升了 400% 以上。团队合并的 PR 数量几乎翻倍，而每次变更的评审时间却急剧膨胀。分析中有一个令人难忘的定义：资深工程师已经变成了“产品模糊性的验证层” —— 他们正在进行“产品考古”，重构原本的意图，而不是验证已经构建的内容。

为什么压力落在了无法分担的人身上

这就是让它成为“倒挂”而不仅仅是瓶颈的原因。生成工作可以分摊到整个团队以及 Agent 本身 —— 每个人都能产出更多。但捕捉微妙错误的工作只有一项任职资格：在特定代码库中深耕多年所形成的模式识别能力。这无法分摊。

评审 Agent PR 的初级工程师可以确认测试通过、风格匹配。但他们通常无法察觉到，Agent 添加的缓存层在生产环境的并发下会因为竞态条件悄悄提供过期数据，或者看似“等效”的重构改变了事务边界。这种判断力正是你聘请 Staff Engineer 的原因，也是再多的 Agent 吞吐量也无法缓解的压力。因此，随着看起来合理的代码量增加，唯有资深人员才能负责任地批准的代码比例也随之上升 —— 这一切都涌向了那三个相同的收件箱。

你无法通过增加另一个 Agent 来评审第一个 Agent 的代码来解决这个问题。第二个模型可以捕捉一类机械性问题，部署它是有价值的。但让 LLM 成为衡量这项变更对你的系统是否安全的最终仲裁者，只会复制你试图逃避的那个问题：一个自信、流畅的判决，背后却没有可负责的判断。责任最终止于一个理解爆炸半径的人类，而那个人定义上就是资深人员。

其结果是一种在吞吐量仪表盘上不可见的“税收”。你的速度图表看起来很棒 —— 更多的 PR，更多的合并。它们没显示的是，感知到的加速正不断被隐藏的验证成本所抵消，而该成本正在消耗一项稀缺且不可替代的预算：资深工程师的注意力。2025 年的 DORA 研究从另一个角度得出了相同的结论 —— AI 不会修复团队，它只会放大团队原本的样子。如果你的评审流程已经是制约因素，Agent 只是在火上浇油。

二阶伤害

加载中…