> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2026-nian/w21-ruan-jian-gong-cheng-de-lin-jie-dian.md).

# W21-软件工程的临界点

上周看了 Google 工程师 Adam Bender 在 Google I/O 2026 上的一个演讲，[Software engineering at the tipping point](https://io.google/2026/explore/workshop-2)。这个演讲讨论的是 AI 对软件工程的冲击，以及在代码生成速度提升 10 倍甚至更高以后，原有软件生态会遇到什么临界点。

这个演讲让我重新想起《[Google 软件工程实践](https://abseil.io/resources/swe-book/html/toc.html)》这本书，也就是业内常说的 Flamingo book。这本书总结了 Google 二十多年软件工程实践的核心经验，包括 Monorepo、主干开发、大规模变更、代码评审、测试体系和工程文化。过去看这些内容，更多觉得是大厂工程体系的最佳实践。现在再看，会发现它讨论的其实不是某一个工具，而是软件如何在时间和规模两个维度下持续演进。

软件工程和编程最大的不同在这里。编程关注的是把代码写出来，解决眼前的问题。软件工程关注的是几年以后、几百个人之后，这套系统还能不能被理解、被修改、被验证、被安全地演进。代码写出来只是开始，真正难的是让代码长期留在一个可控的生态里。

Google 的很多实践，本质上是在构建一种共同命运。比如单体代码库让全公司共享同一套代码资产，主干开发让大家持续对齐在同一个版本上，大规模变更让底层库和安全问题可以被自动化地修复，代码评审和无指责复盘则把个人经验沉淀为组织能力。这背后不是简单的工具崇拜，而是一套社会技术系统。技术工具解决规模问题，工程文化解决协作问题。

Bender 这个演讲最有意思的地方，是把 AI 放到了这个软件生态里观察，而不是只讨论 AI 能不能写代码。AI 出现以后，软件工程的老问题没有消失，只是被放大了。DORA 有一个说法我很认同：[AI 是放大器](https://dora.dev/capabilities/user-centric-focus/)，它只放大幅度，不决定方向。如果一个团队的测试、架构、协作机制是健康的，AI 放大的是效率。如果这些基础本来就很脆弱，AI 放大的就是混乱。

过去一个人一天写几十行、几百行代码，很多问题暴露得慢。未来多个 Agent 同时改代码，代码生成速度可能提升十倍甚至百倍，工程体系就会更快逼近临界点。代码变便宜以后，低质量代码会更容易堆积，代码资产很快变成代码负债。构建和测试系统会承受更大的压力，原来能跑完的测试集，未来可能因为代码和依赖关系膨胀而变得不可承受。代码评审也会遇到吞吐量瓶颈，人类专家如果只能疲于 review AI 生成的大量变更，就很容易被迫降低标准。

更麻烦的是，多个 Agent 如果缺少全局约束，甚至可能相互修改对方的代码。一个 Agent 觉得应该这样重构，另一个 Agent 又把它改回去，最后形成一种“智能体编辑内战”。这听起来有点像玩笑，但在更高速度、更低成本的代码生产方式下，并不是完全不可能发生。工程系统一旦缺少清晰的抽象边界和反馈机制，混乱也会以更高速度自动化。

所以 AI 时代的软件工程，不能只盯着“怎么让 AI 多写代码”。写代码正在变得越来越便宜，真正稀缺的是系统约束、验证能力和架构判断。我们需要从管理一棵树，转向管理一片森林。以前我们关心单个函数、单个模块、单次 CR，未来更要关心整个软件生态的边界、反馈回路和演进秩序。

我觉得这里有几个方向值得团队提前准备。

第一，Token 和测试算力会成为新的工程资源，不应该被当作无限后台。

第二，验证策略要更智能，不能只依赖简单的全量测试和人工 review。

第三，系统要有更强的隔离能力，不能让实验性 AI 代码轻易污染核心链路。

第四，人要重新夺回系统理解能力。AI 最大的价值不只是帮我们写代码，而是帮我们理解复杂系统，生成动态架构图，推演依赖关系，分析二阶影响。

这也和我们最近讨论的 AI-Ready 工程很接近。AI-Ready 不是接入几个工具，也不是多写几条 prompt，而是让现有工程体系能够承受更高速度、更高并发、更高不确定性的生产方式。基础设施、代码规范、测试体系、文档、架构表达、评审机制，这些过去看起来偏“慢”的事情，在 AI 时代反而会变得更重要。

软件工程的原则没有变，变的是生产力水平和系统压力。越是代码生成变快，越要回到基本功。一个团队真正的竞争力，可能不再是能不能用 AI 写出更多代码，而是能不能设计出一个让 AI 安全参与、持续验证、可控演进的工程生态。