Agoda的工程团队花了不少时间推广AI编程工具，然后做了复盘。结论让人有点坐不住：
个人开发者效率提升了，但项目整体交付速度没怎么动。
这不是Agoda一家的问题。Faros AI整理了跨公司的数据，给出了一组扎心的数字：
高AI采用率的团队，PR合并量增加了98%，任务完成量增加了21%。但与此同时，PR的审查时间增加了91%。
产出多了，但Review变慢了。两个效应几乎互相抵消了。
真正的瓶颈是什么
Agoda工程团队的判断是：问题出在”编码从来就不是软件交付的主要瓶颈”这件事上。
AI补全让写代码变快了。但写代码只是流水线里的一个环节，它前面有需求分析、系统设计、技术方案对齐，它后面有Code Review、测试、集成、部署。
你把中间那个环节的速度提升三倍，不代表整条流水线快三倍。
当AI让代码产出量暴增，”消化这些代码”的能力反而成了新的卡点：
- 每个PR的代码量变大了（AI生成的代码往往不够精炼）
- Code Review要审查的东西更多了
- 但高级工程师的时间是有限的
瓶颈从”写代码慢”转移到了”审查代码慢”，实际交付节奏没有改善。
更深的问题：Specification
Agoda的工程师Leonardo Stern更进一步，他认为真正的稀缺资源上移了：不是Review，是Specification——把模糊的业务需求转化成清晰可执行的技术规格的能力。
以前，工程师花大量时间写代码，specification可以模糊一点，因为”写着写着就搞清楚了”。
现在，你把一个模糊的需求扔给AI，AI会生成”看起来能用”但方向跑偏的代码。然后你再回来改spec，AI再重新生成，反复几轮。表面上代码产出量很高，实际上在用代码试错，效率并不高。
高保真的需求规格说明，正在成为核心的工程交付物。不是代码本身，是”怎么描述要什么”。
Stern的「灰盒」方法
Stern提出了一个叫做「灰盒」的工作方式，介于两个极端之间：
- 白盒：每一行AI生成的代码都过一遍，你对实现细节完全负责
- 黑盒：AI写完直接上线，你对结果负责但不管过程
- 灰盒：在两个关键点介入——写精确的spec、验证结果是否符合spec
灰盒的核心逻辑是：你不需要理解AI用什么方法解决问题，但必须能明确说清楚”什么算解决了”，并且能验证它确实解决了。
这个方法的本质，是把工程师的时间和注意力集中在”AI最不擅长的部分”——定义意图和验证结果，而不是实现细节。
工程师角色在往哪儿走
传统的软件工程师角色假设里，”写好代码”是核心竞争力。
现在这个假设在动摇。当AI能写出质量尚可的代码，工程师的稀缺性来自哪里？
从Agoda这类公司的实践来看，答案在往这个方向走：
- 能把业务问题转化成精确技术规格的人
- 能设计有效验证方案的人
- 能判断AI产出的代码是否真正解决了正确问题的人
这不是”写代码的能力不重要了”——而是写代码的能力从稀缺资源变成了基础门槛，真正的区分度在更上游。
用Stern的话说：人类的权威正在从”写代码”向”定义意图”迁移。这是抽象层级的上移，不是技能的消失。
管理层该怎么看这件事
对工程管理者来说，Agoda的研究有一个直接的行动建议：不要用代码产出量来衡量AI的价值。
PR数量、代码行数、任务完成量，这些指标都会因为AI工具而变好看。但如果交付的功能没变多、没变快、质量没变好，这些数字就只是数字。
真正值得追踪的指标是：功能上线周期、线上缺陷率、从需求到交付的端到端时间。这些数字才能告诉你AI有没有真正帮到团队，还是只帮团队在GitHub上刷了数据。
下次有人拿PR合并量给你汇报AI工具的ROI，可以问一句：那Review时间呢？
参考来源：AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck（InfoQ）