當 AI 開始寫程式，我們失去的可能不只是工作，而是對系統的「主權」
AI 輔助開發的效率令人驚艷，但當程式碼的生成速度遠超人類的理解速度，我們正在悄悄累積一種比技術負債更危險的「理解負債」。這不只是品質問題，更是關乎我們能否持續掌握自己創造的系統，避免在未來失去對程式碼庫的「主權」。
AI 輔助開發工具正從單次提示（prompting）走向自律迴圈（autonomous loops），這帶來驚人效率的同時，也引發一個更深層的治理挑戰。當程式碼的生成速度遠超過人類的閱讀與理解速度，我們累積的將不只是可償還的「技術負債」，而是一種不可逆的「理解負債」（comprehension debt）。長期來看，這將侵蝕我們對程式碼庫的整體掌控力，逐步喪失設計與維護的「主權」。這不是未來的科幻場景，而是當下就需要正視的工程與治理問題，關乎我們能否繼續掌握自己親手打造的數位世界。
為什麼 AI 的風險不在於單次犯錯？
過去幾年，我們對 AI 寫程式的擔憂，大多集中在它是否會產生臭蟲（bugs）、寫出不安全的程式碼，或是不符合特定需求。這些問題固然存在，但它們本質上仍屬於傳統軟體品質管理的範疇，可以透過測試、程式碼審查（code review）等既有流程來緩解。然而，真正的風險並非來自 AI 的單次失誤，而是它持續、高速、大量的「正確」貢獻。
我們需要區分兩種截然不同的「債務」：
- 技術負債（Technical Debt）：這是我們熟悉的概念，由 Ward Cunningham 首次提出。通常是為了快速交付而採取的權宜之計，例如不完美的架構或待重構的程式碼。團隊對此有共識，理論上只要投入時間和資源，就能「償還」這筆債務。
- 理解負債（Comprehension Debt）：這是一個更隱蔽、更危險的概念。當系統的複雜度，尤其是由 AI 自動生成的部分，其增長速度超越了任何單一開發者甚至整個團隊的認知負荷時，這種負債便開始累積。團隊成員或許能理解各自負責的局部，卻沒有人能掌握系統的全貌、最初的設計理由以及各模組間隱晦的交互關係。
技術負債是我們「知道但暫時不做」的問題，而理解負債是我們「根本不知道我們不知道」的黑洞。一旦累積到臨界點，償還便無從談起，因為我們連問題出在哪、該如何修復的「理解力」本身都已喪失。這意味著我們失去了對自己創造的系統的掌控權，也就是「程式碼庫主權」（codebase sovereignty）。
AI 從助手變自律工人：迴圈工程如何加速「理解負債」？
理解負債的加速累積，源於開發範式的轉變。我們正從「人類提示、AI 回應」的單向互動，轉向設計「迴圈工程」（Loop Engineering）的模式。這個詞彙因 Anthropic 的 Claude Code 專案負責人 Boris Cherny 的一句話而廣為人知：「我的工作是編寫迴圈（My job is to write loops.）。」
這背後的意義是，開發者的角色不再是反覆輸入提示的勞工，而是設計一個個小型、自律的程式迴圈，由這些迴圈來指示 AI 執行任務、驗證結果，並將成果傳遞給下一個迴圈。
這種模式極大地釋放了生產力。根據 GitHub 的數據，在某些程式語言中，GitHub Copilot 已經貢獻了高達 46% 的新程式碼。當數個甚至數十個這樣的自律迴圈同時運作，程式碼庫將以指數級速度膨脹。人類的閱讀和理解速度根本無法跟上。幾個月後，一個新加入的工程師（甚至當初的設計者）將面對一個龐大、陌生、缺乏統一設計哲學，卻又能正常運行的「黑盒子」。他不知道為何某段程式碼要那樣寫，也不知道修改它會觸發什麼意想不到的連鎖反應。
如何治理不可逆的「理解負債」？
面對這個挑戰，單純禁止使用 AI 或強化傳統的程式碼審查是無效的。前者不切實際，後者則遠遠跟不上生成的速度。我們需要的，是一套新的治理框架，將重心從「管理程式碼的產出」轉向「維護系統的理解」。
這需要我們在幾個層面上做出改變：
- 強化架構性審查（Architectural Review）：人類的審查精力應該從逐行檢查 AI 生成的程式碼，提升到審查這些程式碼對系統整體架構的影響。我們的問題應該是：「這個由 AI 生成的模組，是否符合我們預定的架構原則？它是否引入了新的、未被管理的依賴？」
- 投資於「理解」的工具：我們需要開發或導入新工具，來應對急遽下降的軟體可理解性（program comprehension）。這些工具能自動化生成系統的即時架構圖、追蹤數據流、標示出高風險的耦合區域，並將 AI 的設計決策過程視覺化。
- 建立「設計理由」的知識庫：我們應該要求 AI 在生成程式碼的同時，也必須產出對應的「設計理由」（design rationale）。這包括它做了哪些權衡、拒絕了哪些替代方案、以及這段程式碼的預期生命週期。這些元數據與程式碼本身同等重要，是未來維護者的地圖與指南針。正如學術研究所強調的，保留設計脈絡對於長期軟體演化至關重要。
最終，人類工程師的角色將徹底轉變。我們不再是砌磚的工人，而是城市的規劃師、建築法規的制定者與品質的稽核員。AI 負責執行與建造，而我們負責確保這座城市不會在我們失去理解的狀況下，悄悄變成一座我們無法居住、無法修復的迷宮。
延伸閱讀
- Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions (arXiv)
- Ward Explains Debt Metaphor (C2 Wiki)
- GitHub Copilot is generally available to all developers (GitHub Blog)
- Program comprehension and software maintenance (ResearchGate)
- A field study of design rationale in a mature software project (ACM Digital Library)
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。