AI 生產力陷阱：為什麼缺乏可維護性的速度只是債務陷阱
AI 編碼代理（AI coding agents）的承諾令人陶醉：產出翻倍、速度提升三倍，並大幅縮短從構思到實現所需的時間。對於許多團隊而言，看到功能以極速實現所帶來的即時多巴胺衝擊是令人難以抗拒的。然而，這種加速背後隱藏著一個數學陷阱。如果一個 AI 代理讓你寫程式碼的速度快了一倍，但該程式碼的維護難度也增加了一倍，那麼你並沒有提高生產力——你只是加速了墜入技術債的過程。
維護的數學邏輯
每一行程式碼都是一種負債。從程式碼提交（commit）的那一刻起，它就需要持續的維護：修復錯誤、升級依賴項、安全性修補以及一般的清理工作。這與增加新功能無關；這是為了保持現有軟體正常運作的基本成本。
考慮一個模型：每個月的開發活動都會為未來幾年產生特定數量的維護開銷。雖然確切的數字各異，但趨勢是普遍的：隨著程式碼庫（codebase）增長，花在「增值」工作（新功能）上的時間百分比必然會下降。最終，團隊會達到一個臨界點，屆時大部分的產能都會被單純維持現狀的工作所消耗。
當你引入一個能讓產出翻倍的 AI 代理時，你實際上是在讓你的負債表面積翻倍。如果 AI 生成的程式碼品質與人類寫的程式碼相當，你的未來維護負擔就翻倍了。如果 AI 生成的程式碼更不透明、缺乏連貫性，或者是在沒有經過嚴格審查的情況下直接推送，那麼這種負擔可能會翻四倍。
「加州旅館」效應
這會造成一個危險的循環。短期內，生產力會飆升。你交付更多、更快。但因為維護負擔的增長速度快於產出速度，這些收益會迅速被抵消。
最糟糕的是，這會造成一種「永久受僱」的狀態。如果你因為成本變得太高而決定停止使用 AI 代理，生產力的提升會瞬間消失，但累積的維護債務卻留了下來。你將面對一個龐大且複雜的程式碼庫，其維護成本比你從未使用過 AI 時還要昂貴。
反對觀點：AI 能解決維護問題嗎？
雖然「程式碼膨脹」的風險是真實存在的，但一些開發者認為 AI 實際上是維護疾病的解藥。
這場辯論通常分為兩派：
1. AI 作為維護加速器： 一些使用者報告說，AI 非常擅長處理維護中那些「摧毀靈魂」的部分。
"I think AI is great for the soul destroying boring stuff that makes me want to quit my job like wrapping legacy code in test cases," 一名開發者指出。
其他人則認為，AI 讓現代化舊專案、消除無用函式庫（dead libraries）以及自動化端到端測試變得更容易，有效地降低了舊系統的維護門檻。
2. AI 作為品質把關者： 有一種觀點認為，AI 的目標不應是最大化「每次提示詞（prompt）所更改的行數」，而應轉向降低未來變更的成本。
"I’d rather see agents default to smaller diffs, test scaffolding, and explicit assumptions than maximize lines changed per prompt," 另一位貢獻者建議。
永續 AI 整合策略
為了避免生產力陷阱，目標不應是「更快」地編碼，而應是「更便宜」地維護。如果一個 AI 代理讓你的產出翻倍，你必須找到一種方法，讓該產出的維護成本減半。
以下是幾種實用的策略：
- 強制重構（Mandatory Refactoring）： 將每一項 AI 生成的功能視為清理工作的機會。確保任何新功能或修復都在同一個 pull request 中附帶對周圍程式碼的相應重構。
- Focus 於測試架構（Test Scaffolding）： 利用 AI 建立強大且高覆蓋率的測試系統。當驗證正確性的成本很低時，AI 生成的退化（regressions）風險就會降低。
- 以人為本的審查（Human-Centric Review）： 抵制「LGTM」AI pull requests 的衝動。AI 程式碼看起來往往很正確，但乍看之下可能「難以理解（un-grok-able）」，從而增加人類維護者的長期認知負荷。
- 管理產出物（Artifact Management）： 要意識到 AI 代理產出的不僅僅是程式碼。如果沒有系統地組織管理，工作環境的「維護」——例如對話紀錄、規格草案以及生成的圖像——也會成為生產力的稅收。
結論
AI 編碼代理是強大的工具，但它們並非免費午餐。要確保 AI 能帶來淨生產力的提升，唯一的途徑是反轉傳統的焦點：停止追求「寫程式」的速度，開始追求「降低維護成本」。如果沒有刻意地降低維護成本，我們只是在用暫時的速度提升來換取一輩子的技術債。