AI 讓開發變快，但決定團隊走多遠的，是「可被信任的速度」
最近讀了 Anthropic Institute 的〈When AI builds itself〉。文章談的是一個值得每個技術團隊認真看待的趨勢：AI 已經開始加速 AI 自身的研發，而軟體開發的工作型態，也正在被重新改寫。
幾個數字很有份量。Anthropic 提到，截至 2026 年 5 月，合併進其程式庫的程式碼有超過八成由 Claude 撰寫；2026 年第二季，典型工程師每天 merge 的程式碼量，約為 2024 年的 8 倍。值得一提的是，他們也誠實標註了限制——用程式碼行數衡量生產力本就會高估實質貢獻，工程師的自評也容易偏高，而這些曲線未必是指數，也可能是會趨緩的 S 曲線。
但即使保守地讀，我認為真正的重點都不是「AI 能寫多少 code」，而是軟體開發的瓶頸，正在移動。
過去我們衡量工程能力，問的多半是「誰比較會寫 code、誰比較熟 framework、誰能把功能做出來」。但當 AI 已經能快速產生程式碼、修改檔案、執行測試、分析錯誤，甚至獨立完成數小時的工程任務，團隊真正稀缺的能力會逐漸轉移到上游：誰能定義出正確的問題、寫出清楚的規格、設計可驗證的測試，以及判斷 AI 的產出是否真的可靠。
Anthropic 在文中點出一個很關鍵的觀察：當 AI 大量產生程式碼，human code review 反而會變成新的瓶頸。這在計算機架構裡叫 Amdahl’s law——你把某一段流程加速到極致，瓶頸不會消失，只會搬家。它套在組織上同樣成立，也正好呼應我在實務上看到的現象：AI 讓「產出」變便宜，卻讓「判斷」變昂貴。
最近我帶團隊把這套邏輯落實成一條開發主線：從 Example Mapping 釐清需求與邊界規則，到 OpenSpec 定義行為與驗收條件，再交給 Claude Code 依測試逐步實作，最後經過 code review、CI 與資安檢查把關。過程中我體會最深的一點是：真正決定 AI 產出品質的，往往不是模型本身，而是上游的規格夠不夠清楚。舉個例子，光是一個鏈上轉帳功能，我們在動手寫任何程式碼之前，就先拆出了三十幾張 Example Mapping，把正常與異常情境、各種邊界條件一一攤開。當規格與範例夠扎實，AI 幾乎能穩定跑在正確的軌道上；而那些卡關的地方，事後回頭看，幾乎都是「規格的缺口」，而不是「程式的 bug」。
不過，把這套方法真正導入一整個團隊，又是另一回事。我認為，這本質上是一個「結構問題」，而不是「工具問題」——把工具與方法準備好，只是起點，並不代表它們就會被用起來。要讓一套新的開發方式在團隊裡真正生根，通常需要四件事同時到位：一是對「為什麼」的認同，人若不打從心裡認同規格、測試與設計的價值，再好的工具也只會閒置；二是一個跑得起來的回饋迴圈，環境、資料庫與測試要能在手邊實際運作，TDD 才有「紅轉綠」的回饋，環境一旦卡住，整套方法就無從啟動；三是時間與動機，當「學新方法」被擺成「趕進度」的對立面，學習永遠會墊底；四是管理層的明確支持，讓它成為團隊的共同方針，而不是「某個人的提議」。這四件事缺一不可，而工具往往只是其中最容易給、也最常被誤以為是全部的那一塊。
有意思的是，這些其實都不是新觀念。Kent Beck 談測試、Eric Evans 談領域裡的共通語言、Ousterhout 談模組設計，講的都是同一件事：把複雜度管理好。AI 並沒有讓這些基本功過時，反而把「忽略它們的代價」放大了——而且來得更快、更明顯。
所以我越來越相信，技術團隊接下來真正該投資的，不只是 AI 工具本身，而是兩層能力：一層是「AI 時代的工程治理」——需求規格化、測試先行、agent workflow、code review 自動化、資安檢查、可觀測性、rollback 與知識沉澱；另一層，是讓這些能力能在團隊裡真正長出來的「組織條件」——時間、動機、共識，以及管理層的承諾。前者決定 AI 能不能跑在正確的軌道上，後者決定團隊能不能真的跟上。
如果說過去的軟體開發像手工雕刻，工程師一刀一刀把系統刻出來；那未來的開發，更像在經營一座高度自動化的工廠。機器可以很快，但設計圖、品管線、煞車系統與安全閘門，仍然得由人來負責。
文章後半談得更遠——一旦 AI 真的能遞迴式地打造自己的下一代，控制、對齊與全球協調都會成為更核心的課題。那是更長期的問題，但它提醒我們：速度從來不是終點。
AI 會讓開發變快；但真正決定一個團隊能走多遠的，是我們能不能把「快」，變成「可被信任的快」。
也想聽聽你的經驗：在你的組織裡，擋在 AI 開發導入前面的，究竟是工具本身，還是那些工具以外的條件？
