AI coding agent 真正該降低的是維護成本

James Shore · 2026-05-10

原文連結： You Need AI That Reduces Maintenance Costs

摘要

• James Shore 的核心提醒很直接：AI coding agent 不能只是讓團隊更快產碼，還必須按比例降低後續維護成本。
• 如果 AI 讓團隊 2 倍速產出，但每份產出維護起來也更貴，短期速度提升會被後續 bug、設計債、依賴升級與 review 壓力吃掉。
• 他用一個簡化模型說明：每寫 1 個月程式，未來每年都會持續付維護成本；維護成本高低，最後會決定團隊真正能做多少新東西。
• 即使 AI 產生的 code 和人類寫的一樣好維護，只要產碼量變多，總維護量仍會上升；真正理想的 AI 應該讓每份 code 更容易維護。
• 對開發團隊來說，追求 coding speed 之外，也要同樣積極追求可讀性、設計品質、測試、重構與維護效率，否則只是把一次性的速度紅利換成長期鎖定。

· · ·

我直接說重點：你拿來寫 code 的 AI coding agent，必須降低你的維護成本。而且不是降低一點點而已。如果它讓你寫 code 快了 2 倍，那最好也讓你的維護成本砍半。如果它讓你產出快了 3 倍，那維護成本就得降到 1/3。否則你就慘了。你是在拿暫時的速度提升，換一段長期的苦役。

你想知道為什麼？好。那我們開車上路，進入那條黑暗的沙漠公路吧。

生產力是由維護成本決定的

你寫下的每一行 code 都得被維護：修 bug、清理、升級依賴等等。我不是在說新功能或功能強化，只是在說維護。你每花 1 個月寫 code，接下來 1 年都會花一些時間維護那些 code；再之後的每 1 年也都一樣。只要那些 code 還存在，這件事就會一直持續。

假設你找了大約 50 位開發者，問他們這些維護成本大概是多少。用一種叫作 Wisdom of the Crowd 的方法，你可以得到一個合理準確的答案。¹

¹ 你也可以自己做一場 wisdom-of-the-crowd 調查。不過事實上，具體數字不會改變這篇文章要講的整體重點。

你的那群受訪者可能會說：每寫 1 個月 code，接下來你會花：

• 第 1 年花 10 天在維護上；
• 之後每 1 年再花 5 天維護。

如果你是那種特別執著的人，你可能會花幾個小時做一份 spreadsheet，模擬這些估算會如何影響長期生產力。像這份 spreadsheet 一樣。

新專案的第 1 個月非常美好。你所有時間都拿來做很酷的新功能。

到了第 2 個月，就稍微沒那麼美好了。你的一小部分時間會拿去修 bug，或清掉第 1 個月留下的設計錯誤。第 3 個月，這個比例再多一點。第 4 個月、第 5 個月、第 6 個月，繼續累積下去。

最後，它就一點也不美好了。照這群人的維護估算來看，過了 2.5 年之後，你會有超過一半時間都花在維護上。過了 10 年，你幾乎做不了其他事。

如果把這群人的維護估算砍半，你可以多撐 3 年，才碰到 50% 這條線。如果把維護估算加倍，團隊不到 1 年就會跌破 50%。

教訓很清楚：如果你想要一個有生產力的團隊，就得專注在維護成本上。

所有模型都是錯的

這些數字聽起來像真的嗎？對我來說很像。在我的顧問職涯裡，我專門協助晚期新創，而它們遇到的問題幾乎都跟上面那張圖一模一樣。大約 5-9 年之後，它們會發現自己的團隊已經做不出什麼東西，然後就會找上我。

這些團隊沒有圖上看起來那麼糟。也許它們的維護成本比較低。又或者，這對我來說比較可能，它們的維護成本其實就是那麼糟，只是用別的方法把問題蓋過去了。也許它們會：

• 決定不要修每一個 bug，或不要升級每一個依賴；
• 團隊變慢時就加人，然後繼續加更多人，因為人永遠不夠；
• 乾脆全部砍掉，重寫一遍。

精確的維護數字當然有討論空間，但整個模型的方向是對的。如果你在這行待過一段時間，就會知道這張圖是真的。你看過生產力如何隨著時間融化掉。你身上也有那些疤。

這跟 AI 有什麼關係？

關係大了。

假設你的團隊剛開始使用 Rock Lobster，這套最新最強的 agentic coding framework，然後它讓你的 code 產出加倍。太棒了。只是產出的 code 稍微比較難懂，你的團隊也被 pull requests 淹沒，而且你也許、差不多、其實沒有真的在按下 approve 前把 code 讀完。像是完全沒有。也許只是偶爾在無聊會議裡瞄一下，然後覺得這樣應該夠了吧。LGTM，先合再說。

於是你現在 1 個月做出 2 個月的工作量。再假設，每「1 個月」產出所需的維護成本也加倍了。那麼下個月的維護成本就變成 4 倍。

啊。

大概在你開始使用 Rock Lobster 5 個月後，你的生產力會掉回原點。再過幾個月，它甚至會比你從來沒有碰過 Rock Lobster 還差。

我不是說你的 AI 一定會讓維護成本加倍，也不是說它一定會讓生產力加倍。這是一個極端例子。但就算 AI 產生的 code 和人類寫的 code 一樣容易維護，那些生產力提升也不會持久。

停用工具，不代表離開成本

² 因為既有維護成本還是會留下來。

Agents 很貴，而且只會越來越貴。等到你的 agent 已經不划算時，你也許會決定省點錢，回到老派寫 code 的方式。像原始人一樣，用自己的手指慢慢打。

哈，笑話在這裡。當你停止使用 agent，所有生產力收益都會消失，但新增的維護成本不會消失。只要那些 code 還在，你就會被困在一個比從未使用 agent 更低的生產力狀態裡。

回頭路的數學

只有在 LLM 能降低維護成本時，這筆帳才算得過去，而且降低幅度必須剛好是它增加 code 產出的反比。如果你產出變成 2 倍，但維護那些產出的成本也變成 2 倍，2 乘以 2，代表維護成本變成 4 倍。如果你產出變成 2 倍，但維護成本只是持平，2 乘以 1，代表總維護成本仍然變成 2 倍。

你真正需要的是反轉生產力倍率。如果你正在產出 2 倍多的 code，那些 code 的維護成本就需要只有原本的一半。如果你產出 3 倍多的 code，維護成本就需要只有原本的 1/3。

這才是成功的祕密：得到所有好處，但不被鎖死。

這頭野獸殺得掉嗎？

我不知道。以我閱讀那些最優質新聞來源的經驗來看，coding agents 會增加維護成本。有些人確實說，這些工具幫助他們更理解大型系統。但我們需要的，是大幅降低成本，而且是非常大幅。這點我還沒看到。剛好相反。

這是一個問題。這個模型並不是現實的完美再現，但整體訊息是對的：你需要能降低維護成本的 AI，而且降低幅度要和它帶來的產碼速度相稱。否則你就慘了。你是在拿暫時的速度提升，換一段長期的苦役。

所以，請繼續追求 coding speed 的改善。但也要花同樣多的力氣，追求維護成本的改善。否則，你也會被困在那間看似迷人的旅館裡。

那看起來很美，也很容易讓人留下來。

這篇不是反 AI rant，雖然讀起來可能有點像。還有其他槓桿可以拉，例如讓 AI 提升維護本身的生產力，即使它沒有讓 code 本身變得更好維護。我鼓勵你複製那份 spreadsheet，玩玩模型裡所有槓桿，看看把假設改成符合你真實狀況時，結果會怎麼變。

· · ·

延伸評論：AI 寫得越快，越要問誰來付維護帳單

這篇文章有價值的地方，是把 AI coding 的討論從「產出速度」拉回「生命週期成本」。很多團隊評估 agent 時，會自然地看它能不能更快開 feature、補 test、改 UI、解 issue；但真正決定團隊能不能長期變快的，往往是它有沒有降低後續理解、修改、除錯、review、升級與重構的成本。

更麻煩的是，AI 的速度紅利很容易在短期被看見，維護帳單卻會延後出現。這讓團隊很容易誤判：本月多 merge 了 30% PR，看起來像生產力提升；半年後 review queue 變厚、bug triage 變久、大家不敢動某些模組，才發現其實只是把成本往未來搬。

對真的在做 agent workflow 的人來說，比較成熟的指標不是「今天 agent 寫了多少 code」，而是「這些 code 讓未來更容易改，還是更難改」。如果 AI 能主動補上設計理由、縮小 diff、維持測試與文件、清掉死角、把重構拆成可 review 的步驟，那它才有機會成為維護成本的下降因素。否則它只是更快的債務印鈔機。