> 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-hant/2026/w21-the-inflection-point-of-software-engineering.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 安全參與、持續驗證、可控演進的工程生態。