AI 辅助编程：代码更快，协作更弱——现代软件的巴别塔

AI 辅助编程加速产出，却侵蚀了保持大型系统一致性的共享思维模型

要点: AI 代理让开发者更快地提交代码且减少直接协作，但失去迫使团队在共同的架构语言上对齐的摩擦，导致一个巴别式的塔不断升高，而其底层设计正在崩塌。

原始类比：巴别塔作为协作模型

The essay draws on Bruegel’s The Tower of Babel to illustrate that the true power of a massive engineering effort is a shared language, not the bricks themselves. In the biblical story, God confounds language, halting construction because the workers can no longer coordinate. The author argues that AI‑assisted programming removes the need for that coordination: each developer can ask an agent to make a change, and the agent produces code that compiles and passes tests without the human ever learning the part of the system they modified.

“代理消除了大部分摩擦。我可以让代理添加 OAuth，你可以让它添加缓存……每一次改动在孤立情况下都可能是合理的……我们不一定需要相互交流，甚至不必获取原本因这次改动而必须学习的共享模型的那部分。”

为什么摩擦在大型代码库中重要

大型项目的瓶颈从来不只是个人写代码的速度。真正的瓶颈是理解的协作：

概念语言 – 对领域概念、不变量和所有权的共享定义。
隐式知识 – 存在于代码审查、对话以及解释变更习惯中的约定、失败模式预期和设计理由。
同步摩擦 – 阅读他人代码、提问、验证假设所需的努力。这种摩擦虽然有成本，却确保了知识在团队内部传播。

当代理消除这种摩擦时，知识转移的环节就消失了。塔仍在继续增长，但能够让人类共同推理的架构语言却在逐渐消失。

社区反应：认同、警惕与扩展

对协作丧失的共识 – 多位评论者呼应了核心论点。一位评论者指出，“自 2022 年 11 月 30 日起，一切变得……更复杂”（sixtyj），强调了 AI 工具普及后复杂性的快速升级。
无约束抽象的风险 – 用户警告说，代理可能在没有人工审查的情况下重写代码库的大量部分，导致“意大利面条代码”和隐藏的技术债务（softwaredoug、prymitive）。
缺失智慧 – HiPhish 警告称 AI 提供的是没有智慧的智能，暗示没有人类理解的塔在根本上是不安全的。
与历史模式的平行 – ssivark 将此论点与“Lisp 诅咒”相联系，后者因语言易用性而抑制协作，映射到今天的 AI 生成代码。
潜在缓解措施 – apinstein 描述了一个具体实验：使用 AI 维护三套独立的模式语言（业务、产品、技术），以保持共享的架构知识明确化。
管理类比 – JefferyRogers 观察到，AI 驱动的开发将工程师的角色转向管理，监督代理而非直接编写代码。
未来治理 – 多条评论（如 cadamsdotcom、pdp）提出了新范式——任务控制式监控、实时编排或全新学科，以恢复协作。

当今塔的样子

当前 AI 增强的开发工作流常常产生：

快速、孤立的变更 – 代理可以在几秒钟内添加功能、重构或微调 UI 颜色。
文档稀疏 – 解释按需生成，但很少整合进活跃的设计文档中。
分散的架构碎片 – 不同开发者（或代理）构建“局部特定”的解决方案，虽在本地可行，却缺乏统一的抽象。
延迟的失败 – 由于系统仍能编译且测试通过，团队可能在错误很久之后才注意到共享理解的侵蚀。

巴别式塔的风险

技术债务累积 – 缺乏共同模型，隐藏的假设变得脆弱，导致昂贵的改造。
集体智慧流失 – 团队可能忽视系统性故障模式、安全因素或性能瓶颈。
可维护性下降 – 未来工程师继承的代码库在语法上正确，却在语义上晦涩。
组织碎片化 – 正如文章所述，“能够让人类共同推理的架构语言消失”。

可能的对策

方法	如何解决问题	评论中的示例
显式模式语言	以结构化、可检索的格式对领域、产品和技术概念进行编码。	apinstein 的 AI 维护的模式语言。
任务控制监控	提供所有代理行为的共享实时视图，类似协作控制台。	cadamsdotcom 的编排隐喻。
强制代码审查	通过要求审查者理解并批准 AI 生成的更改，重新引入人为摩擦。	prymitive 对无约束重写的警告。
定期架构同步	安排专门会议以调和分歧的抽象并更新共享文档。	文章中原始的摩擦概念。
显式设计意图的工具	扩展 LLM，不仅生成代码，还生成设计理由和不变量。	正在进行的研究，未直接引用。

结论

AI 代理显著提升了个人开发者的生产力，但它们也绕过了历史上保持大型软件项目一致性的社会摩擦。由此产生的“塔”仍在不断升高，却因其基础语言的瓦解而面临隐藏的技术债务和集体智慧的流失。要在享受 AI 速度的同时不牺牲长期可维护性，团队必须有意识地重新引入协作机制——通过模式语言、共享监控和严格的审查流程——使塔建立在坚实、共享的架构基础上，而不是脆弱的、由孤立变更构成的巴别塔。

引用的关键点:

AI 消除协作摩擦，使代码可以在没有共享理解的情况下添加。
大型项目依赖于共同的架构语言，而不仅仅是个人的编码速度。
缺乏该语言时，代码库会变成一个巴别式的塔，虽然不断升高，却失去结构上的连贯性。
社区共识警示隐藏的技术债务、智慧的流失以及对新治理实践的需求。