Agoda 近期发布的一篇观察文章指出，尽管 AI 编码工具确实提高了个人开发者的产出效率，但在项目层面的整体开发速度提升却远不如预期。究其原因，编码本身从来都不是真正的瓶颈。文章认为，开发瓶颈已向上游转移至需求定义与需求验证环节，因为这些领域更依赖人工判断。这一转变对工程团队的组织架构将产生重大影响。
Agoda 软件工程师 Leonardo Stern 将这一现象视为对 Fred Brooks 数十年前经典论断“没有银弹”（No Silver Bullet）的重新印证——仅对开发生命周期中的单一环节进行提速，对整体交付效率的提升会逐渐递减。
这一观察与全行业数据相吻合：Faros AI 的一项研究分析了来自 1255 个团队、逾万名开发者的遥测数据，结果显示，高度采用 AI 的团队完成的任务量增加了 21%，合并的拉取请求（PR）增加了 98%，但 PR 评审时间却增加了 91%。这一数据与“编码阶段加速会将压力转移到其他环节”的结论一致。
对 Stern 而言，这一转变给团队结构带来的启示更为重要。传统上要求组建精简高效的工程团队，部分逻辑是建立在“编码是最具价值的活动，而沟通是制约效率的成本”这一假设之上。
如果创造最高价值的工作转变为协作式的需求定义与架构对齐，那么原有的逻辑便会彻底反转：沟通不再是要尽量减少的开销，沟通本身就是核心工作。小团队的优势不在于减少协调，而在于更快达成共识。五人团队可以真正在目标意图与边界场景上达成共识，而十五人规模的团队通常难以做到这一点。
软件工程关键交付物从编码向需求定义和验证的转变（来源）
Stern 将工程师与 AI 生成代码的关系归纳为三种姿态。“白盒”模式要求工程师阅读并评审每一行代码，但在智能体每小时可生成数千行代码的情况下，这种模式难以规模化。“黑盒”模式，或称“氛围编码”（Vibe Coding），即对 AI 生成的代码几乎不做验证就直接上线，虽然效率高，但对于服务大规模用户的生产系统来说过于脆弱。
Stern 倾向于一种中间路径，他称之为“灰盒”模式：人类只需在两个关键环节承担责任——编写足够精确的需求规格，让智能体能够准确执行，以及根据证据验证结果，而非逐行检查实现细节。至关重要的是，他明确指出责任并未转移给 AI：指导智能体并批准合并请求的工程师仍对最终交付的成果承担全部责任。
这种将评审重心从代码重新定义为结果验证的思路与 Leigh Griffin 和 Ray Carroll 近期在 InfoQ 发表的关于规范驱动开发的文章中提到的架构形式主义相呼应。文中提出，规范说明应作为系统可执行的事实来源，而生成的代码应被视为下游可重新生成的产物。
人类主导权正从编写代码向定义和治理意图迁移（来源）
从工作流程角度，Stern 得出了一致的结论：一份包含可测试验收标准、清晰边界场景与归档架构决策的高保真规范说明书将成为主要的工程交付物，而具体实现工作则会越来越多地被委托出去。两篇文章共同指向一个观点：人类主导权正在向抽象层级的上游迁移——从编写代码转向定义与治理业务意图。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
查看英文原文：https://www.infoq.com/news/2026/03/agoda-ai-code-bottleneck/
