夜雨聆风三个工程师同时让三个 Agent 改同一个系统：一个加 OAuth，一个做缓存，一个重写数据库层。每个改动都能编译，测试也全部通过，PR 说明写得条理清楚。项目看起来以前所未有的速度向前推进，直到某天团队发现：没有任何一个人能解释这些改动叠加之后，系统为什么仍然工作。
Flask、Jinja 创始人 Armin Ronacher 把这种状态比作一座仍在升高的巴别塔。传统故事里，人们失去共同语言后，工程会停止；AI 编程更诡异——共同理解已经消失，施工却仍能继续。
AI 编程最大的风险，未必是代码不能运行，而是代码继续运行，却逐渐失去能为它负责的人。
大型软件从来不只受限于打字速度
我们容易把软件开发理解成“把需求翻译成代码”，于是当 Agent 能更快写代码时，效率提升似乎顺理成章。但大型系统真正昂贵的部分，是多人长期协调同一套概念：边界在哪里，哪些不变量不能破坏，谁拥有哪个服务，为什么当年做出这个看似奇怪的设计。
这些知识很少完整写在文档里。它们散落在代码审查、架构争论、故障复盘、跨团队协商和老工程师的记忆中。过去，修改陌生模块很慢：你必须读代码、找负责人、解释方案、回答质疑。很多摩擦确实低效，但其中一部分承担了关键功能——它迫使个人模型与团队模型重新同步。
Agent 消除了大量摩擦。你不必理解存储层，也能让它完成迁移；不必找认证团队，也能让它接入 OAuth。局部看，这是能力民主化；整体看，每个人都可能绕过原本用于传播架构知识的交互。
为什么测试通过仍不够
测试验证的是已被表达出来的预期，而共享理解还包含大量没有被编码的约束：某个表不能在月底锁账时重建，某个 API 的延迟不能突然抖动，某个字段虽然标记可空，实际上承担了审计含义。
Agent 擅长在可观察边界内完成任务。如果需求、测试和监控没有覆盖隐性约束，它就会给出局部合理的改动。多个局部合理叠加，可能形成全局脆弱。更麻烦的是，AI 还能即时生成解释，让团队产生“需要时随时能看懂”的错觉；生成一段通顺说明，与建立可用于决策的共同心智模型，并不是一回事。
真正的理解不是能复述代码，而是能在事故发生前判断哪一处不能动。
测试能证明某些路径今天正确，却不能证明团队明天仍有能力安全地改变它。
“每个人都有翻译器”为什么反而更危险
巴别塔停工，是因为人们无法交流。AI 时代，每个人都带着一个不知疲倦的翻译器：它能解释任何角落，也能替你修改任何角落。于是“不再需要交流”取代了“无法交流”。
问题在于，翻译器服务的是当前提问者，而不是整个组织。它可能为产品经理生成一套解释，为后端工程师生成另一套解释，两套说法都足够合理，却没有经过共同确认。代码成为唯一事实来源，但代码规模又增长得远快于人类吸收速度。
这会改变技术债的形态。过去的技术债常表现为旧框架、重复代码和缺少测试；新的债务是认知债：系统还能运行，但理解它所需的上下文已经超出团队持有量。认知债不会立刻让构建失败，却会在故障恢复、架构迁移、安全审计和人员离职时集中收息。
团队该保留哪些“有价值的慢”
应对方式不是禁止 Agent，而是重新设计协作。第一，把架构意图变成可版本化资产：关键不变量、服务边界、数据所有权和拒绝过的方案，都应进入仓库，而不是留在聊天窗口。第二，评审不只看 diff，还要看系统模型发生了什么变化：新增了哪条依赖，谁获得了新权限，哪个团队需要更新认知。
第三，为高风险区域设置“必须有人讲清楚”的门槛。核心账务、身份、权限、数据删除等模块，合并者应能脱离 Agent 解释设计与失败模式。第四，限制并行改动的耦合半径。Agent 可以同时开很多 PR，但组织的理解带宽没有同步翻倍；对同一架构边界的并发修改必须主动收敛。
最后，把故障演练当作理解测试。随机关闭依赖、回滚一段 AI 改动、让非作者定位异常，比让模型再生成一份文档更能暴露认知缺口。
未来优秀的工程团队，不是让 Agent 写出最多代码，而是让代码增长速度始终不超过团队理解速度。
效率的上限，由共同语言决定
AI 确实让个人开发者变得更强，也让过去不值得做的重构变得可行。可软件工程不是一群超级个体的并行输出，而是一个组织对同一系统持续作出一致判断。模型提升了施工能力，却不会自动维护这种一致性。
一座楼可以在没有共同蓝图的情况下继续升高，直到第一次真正需要所有人同时理解它。
所以，评估 AI 编程收益时，除了统计提交数、交付周期和通过率，还应问三个问题：关键设计是否有人说得清？新同事能否形成正确心智模型？事故发生时，团队能否不依赖同一个 Agent 找回控制权？
代码写得更快之后，我们最该保护的，恰恰是那些让人彼此理解的过程。你所在的团队已经出现“代码越来越多、能讲清系统的人越来越少”的迹象了吗？