Agoda 最近搞出了一篇文章，说的是虽然 AI 工具把单个人的编码效率给提上去了，可整个项目的进度，想让人眼睛一亮的地方却并不多。本来想着拿它来加速交付呢，结果发现根本没用上。作者 Eran Stiller 觉得，这事儿跟编码本身到底是不是瓶颈有关系。因为只要稍微留意下开发过程你就会发现，咱们常说的那些慢不是在敲代码那儿卡住了，真正的坎儿其实是在弄清楚需求和验证需求这两步上，这些事儿更多得靠人脑来判断。这个改变可是挺大的，直接把开发团队的组织方式都给颠覆了。 Leonardo Stern 是 Agoda 的软件工程师，他看了这篇文章觉得特别有道理，直接拿 Fred Brooks 那句话“没有银弹”来套——就是说不管你给哪个环节提速再多，要是别的地方跟不上，整体效果也会逐渐变弱。Faros AI 那边还有个研究数据也能说明问题，他们分析了一万多个开发者的数据发现：那些特别爱用 AI 的团队干活多了 21%，PR 合并也多了 98%，但这就意味着审查时间涨了 91%。这说明一个事儿：光是让编码变快只会把压力推到其他环节上。 Stern 觉得这个转变对团队结构的影响更关键。以前搞小团队逻辑很简单：因为大家觉得编码最值钱，而沟通反而是在拖后腿。可要是现在创造价值的活儿变成了一起讨论需求和定好架构怎么办？那原来的逻辑就完全反过来了：沟通不再是要省掉的东西，它就是干活的核心！小团队的好处不是少沟通，而是能更快达成一致。比如五个人的团队能真的把目标和边界都弄明白，十五个人的大团队就很难做到这点。软件工程现在把重点从写代码转向了定义需求和验证需求（来源） Stern 还把工程师跟 AI 生成代码的关系分成了三种样子。“白盒”模式就是工程师得一行一行地看代码，但 AI 一小时能生成几千行代码，这种模式根本没法用在大规模开发上。“黑盒”模式也就是随便把代码往服务器上一丢就不管了，虽然省事但太脆弱了。Stern 比较赞同中间那种叫“灰盒”的做法：人类只要在两个地方负责就行——写清楚需求规格让 AI 能看懂干活，然后拿证据验证结果对不对就行。“没必要逐行去检查那些实现细节。”关键是他说责任还是在人手里：指导 AI 并批准合并请求的工程师必须为最终成果负责。 这种把重点从检查代码转移到验证结果的思路跟 Leigh Griffin 和 Ray Carroll 最近在 InfoQ 上发的文章里提到的规范驱动开发挺像的。文章说规范说明应该是系统的事实来源代码只是下游可以重新生成的产物。人类主导权正从写代码向定义治理意图转移（来源）从工作流程的角度看，Stern 的结论也差不多：一份有测试标准、清晰场景和决策记录的规范说明书会变成主要的交付物，具体的干活会越来越多地交给别人去做。两篇文章都指向一个观点：人类主导权正在向抽象的上层走——从编写代码转向定义治理业务意图。