打开网易新闻 查看精彩图片

Agoda 最近发了篇文章，说了一件反直觉的事：AI 编码工具确实让单个程序员写得更快了，但整个项目反而没快多少。

这就像给流水线上某个工位装了机械臂，结果发现卡壳的地方根本不在那儿。编码从来都不是真正的瓶颈，现在压力跑到了上游——需求定义和验证环节。这些地方机器替不了，只能靠人拍板。

Agoda 工程师 Leonardo Stern 把这称为 Fred Brooks"没有银弹"预言的又一次应验：只给开发流程的某个环节加速，整体效率的提升会越来越边际。

全行业数据也在佐证这一点。Faros AI 分析了 1255 个团队、上万名开发者的数据：重度用 AI 的团队完成任务量多了 21%，提交的 PR 多了 98%，但 PR 评审时间暴涨 91%。编码越快，堵在后面的东西越多。

打开网易新闻 查看精彩图片

Stern 认为这件事对团队结构的冲击比想象中大。以前推崇小团队，逻辑是"编码最有价值，沟通是成本"。但如果最有价值的工作变成了协作定义需求、对齐架构，这套逻辑就彻底翻过来了——沟通不是开销，沟通就是干活本身。五人团队的优势不是人少事少，而是能在目标意图和边界场景上真正达成共识。十五人？通常做不到。

Stern 把工程师对待 AI 代码的态度分成三档。"白盒"是逐行审阅，但智能体一小时能吐几千行，人眼根本看不过来。"黑盒"是所谓的"氛围编码"，几乎不验证直接上线，效率高得吓人，但服务千万用户的系统经不起这么玩。

他选的是中间路线，叫"灰盒"：人只盯两个环节——写清楚需求规格，让智能体能准确执行；用证据验证结果，而不是死磕实现细节。关键是责任没转移，指导 AI 并点合并的工程师，对最终交付负全责。

这种从"审代码"转向"验结果"的思路，和 Leigh Griffin、Ray Carroll 最近在 InfoQ 聊的规范驱动开发对上了：规格说明才是系统的事实来源，代码只是下游可重新生成的产物。

两份材料指向同一个趋势：人的主战场正在往抽象层上游迁，从写代码变成定义和治理业务意图。以后工程师的核心交付物，可能是一份带验收标准、边界场景和架构决策记录的高保真规格书，而实现本身，越来越多地交给别的东西去干。