内容
Agoda 最近发表了一项观察，指出尽管 AI 编码工具确实可量化地提升了单个开发者的产出，但在项目层面带来的速度提升却出人意料地有限，因为编码从来都不是真正的瓶颈。文章认为，瓶颈已经向上游转移到规格说明（specification）和验证（verification），因为这些环节需要人类判断。这一转变对工程团队应如何组织具有重要影响。
Agoda 的软件工程师 Leonardo Stern 将这一现象视为对 Fred Brooks 数十年前在《📚 没有银弹（No Silver Bullet）》中观点的重新发现：如果只提升开发生命周期中某一个环节的速度，那么对整体交付的收益会越来越小。
这一观察也与全行业的数据一致：Faros AI 的研究分析了 1,255 个团队中超过 10,000 名开发者的遥测数据，发现高 AI 采用率的团队完成的任务多了 21%，合并的拉取请求（PR）多了 98%，但 PR 审查时间却增加了 91%。这一指标与上述诊断相符：编码阶段的加速，会把压力转移到别处。
对 Stern 来说，更重要的启示在于，这种转变对团队结构意味着什么。传统上，小而专注的工程团队之所以被认为合理，部分建立在这样一种假设之上：编码是最重要的价值创造活动，而沟通则是妨碍编码的额外开销。
如果最高价值的工作变成了协作式规格定义和架构对齐，那么这套逻辑就会反转：沟通不再是需要被最小化的成本，它本身就是工作。小团队之所以更有优势，不是因为它们减少了协调，而是因为它们能更快达成共识。5 个人通常可以真正围绕目标意图和边界情况达成一致，而 15 个人往往做不到这一点。
软件工程的关键交付物正从编码转向规格说明与验证（来源）
Stern 提出了一个关于工程师如何看待 AI 生成代码的三分法。“白盒（white box）”模式要求人类逐行阅读并审查每一行代码，但当智能体每小时可以生成数千行代码时，这种方式无法扩展。“黑盒（black box）”或“氛围编程（vibe coding）”则是在几乎不做验证的情况下，直接发布 AI 生成的内容；这种方式虽然快，但对于服务大规模用户群的生产系统来说非常脆弱。
Stern 更推崇的是他称之为“灰盒（grey box）”的中间路径：让人类在两个真正关键的节点上承担责任——编写足够精确、能让智能体正确执行的规格说明，以及基于证据验证结果，而不是逐行检查实现。关键在于，他明确指出责任不会转移给 AI：引导智能体并批准合并请求的工程师，仍然要对最终上线的内容承担全部责任。
这种将评审从代码检查重新定义为证据评估的思路，与 Leigh Griffin 和 Ray Carroll 最近在 InfoQ 上关于规范驱动开发（Spec-Driven Development）一文中的架构形式主义观点相呼应。他们在文中主张，规格说明应成为系统可执行的“单一事实来源”（source of truth），而生成的代码则应被视为下游产物，可以随时重新生成。
人的权威正在从编写代码迁移到定义和治理意图（来源）
从工作流的角度出发，Stern 得出了一个相容的结论：高保真规格说明——其中包含可测试的验收标准、明确的边界情况，以及被记录下来的架构决策——正成为首要的工程交付物，而实现工作则越来越多地被委派出去。这两篇文章都指向同一个观察：人类的权威正在沿着抽象层级向上迁移——从编写代码，转向定义和治理意图。
关于作者
https://www.infoq.com/profile/Eran-Stiller/
Eran Stiller
Eran Stiller 是 Cartesian 驻澳大利亚墨尔本的首席软件架构师。作为一位经验丰富的软件架构师和 CTO，Eran 曾在多个业务领域设计、实现并评审过各种软件解决方案。Eran 在软件开发领域拥有多年经验，并且在公开演讲和社区贡献方面也有突出的履历。