想像一下這個場景：你的主管在 all-hands 上秀出一張圖，上面寫著「導入 AI coding agent 後，feature 產出速度提升 3 倍」。台下工程師表面鼓掌，心裡想的是：「那個 3 倍速產出的 code，maintain 起來大概要 9 倍的時間吧。」

這個恐懼不是空穴來風。速度跟品質在軟體開發史上幾乎從來不是朋友。但 Simon Willison 在 Agentic Engineering Patterns 的這一章直接打臉這個假設：

Shipping worse code with agents is a choice. We can choose to ship code that is better instead.

品質變差不是 agent 的鍋，是你家廚房流程有問題。就像鼎泰豐用機器包小籠包，品質反而更穩定 — 前提是你得先有標準化的流程。

Clawd Clawd 想補充：

我超喜歡 Simon 這個 framing。大家都在怪工具，但工具就是工具啊。你拿菜刀切菜切到手指，不會去跟菜刀道歉說「對不起我不該買你」。問題從來不是 agent 太笨，是你的 prompt 太爛、review 太鬆、流程沒到位 ┐(￣ヘ￣)┌

技術債的成本被壓到趨近零

好，先來聊聊技術債這個老朋友。

每個工程師的心裡都有一份「等有空再處理」的清單。就像你家衣櫃裡那堆「瘦下來就穿」的衣服 — 你知道它在那裡，你知道該處理，但你就是不想面對。

Simon 把「產出更好的 code」框架成技術債的問題。那些經典場景你一定不陌生 — 講個最典型的，你的 API 設計當初沒考慮到新 case，改起來要動幾十個地方。怎麼辦？你又疊了一層「有點不一樣」的新 API 上去，對外假裝這是 v2，對內心知肚明這是 duct tape。然後早期某個東西取名取錯了，teams 結果應該叫 groups，但改名工程太浩大，所以只改了 UI 層 — 底層資料表還是 teams，然後每個新人 onboard 都要被講一次「喔那個 teams 其實是 groups，不要問為什麼」。

接著系統長出重複但微妙不同的功能，需要合併但沒人想碰，因為碰了可能會把另一邊搞爆。最後你回頭看那個某檔案，已經胖到幾千行了，大家開 PR 的時候看到它都繞道走。

Clawd Clawd 內心戲：

技術債的心理學跟信用卡債一模一樣。每次欠一點點，感覺還好。等你回頭一看，利息已經滾到你還不起了。而且跟信用卡一樣，最先被犧牲的永遠是「品質」這張帳單 — 因為它不會打電話催你。但你知道什麼會打電話催你嗎？半夜三點的 PagerDuty alert (￣▽￣)⁠／

這些修復在概念上都很簡單。你知道房間亂了要整理，問題不是你不會整理，是整理要花時間，而你沒有時間。期末考前，誰有空打掃房間？

Coding Agent 就是你的還債打工仔

但這裡故事轉折了。

想像有個人出現在你面前說：「欸，你那個衣櫃我幫你整理好嗎？不用錢、不用管飯、我自己 24 小時慢慢來。」正常人的反應是什麼？先懷疑這是詐騙，然後發現是真的之後立刻把鑰匙交出去。

Simon 的論點就是這個意思：那些「概念簡單但耗時」的 refactoring 任務，正好是 coding agent 的甜蜜點。不需要天才等級的思維，就是需要有人花時間一個一個改。就像叫實習生整理檔案 — 你不需要他理解公司願景，你只需要他把 A 搬到 B。

Clawd Clawd 吐槽時間：

我覺得 Simon 這裡最精妙的洞察是「成本歸零改變了決策門檻」。以前你腦中的計算是：修這個要半天，值得嗎？現在計算變成：開個 agent 花 30 秒寫 prompt，值得嗎？答案永遠是 yes。這就像以前寄信要走到郵局、買郵票、排隊 — 所以你只寄重要的信。現在發 email 零成本，所以你連「午餐吃什麼」都寄了 ╰(°▽°)⁠╯

做法很直覺：開一個 agent，告訴它要改什麼，讓它在 branch 裡慢慢磨。你自己繼續做你的事。Simon 建議用非同步的 coding agent — Gemini Jules、OpenAI Codex、Claude Code on the web 這些，agent 在雲端跑，你的筆電不會被綁架。

結果好？Merge。差一點？再 prompt 一次。完全不行？git branch -D，zero cost。

The cost of these code improvements has dropped so low that we can afford a zero tolerance attitude to minor code smells and inconveniences.

以前那些「太小不值得花時間修」的東西 — 一個 naming 不一致、一段可以抽成 util 的重複 code — 現在全部都值得修了。因為成本趨近零。

選架構不再是賭博

好，這章最讓我眼睛一亮的段落來了 — exploratory prototyping。

做技術選型的時候，最貴的技術債往往不是 code 層面的，是 planning 階段就選錯了方向。你選了不適合的 framework、錯過了更簡單的解法。這種債最致命，因為等你發現的時候已經蓋了三層樓上去了 — 地基歪了你跟我說重灌水泥？拆掉重蓋比較快。

Simon 的建議很直覺：與其坐在會議室裡猜，不如讓 agent 直接跑 prototype 來驗證。

來個實際場景。你在考慮 Redis 適不適合做 activity feed，預期幾千個 concurrent user。以前怎麼辦？開會。討論三天。白板畫了擦、擦了畫。最後資深工程師拍板說「我以前用過，應該可以」 — 本質上就是有學問的猜。

現在？一個 well-crafted prompt 就能讓 agent 架模擬系統跑 load test。而且因為成本趨近零，你可以同時開三個 agent 各跑一個方案 — Redis、PostgreSQL、DynamoDB 各來一組。半小時後三份報告擺在桌上，用數據決定。不再是猜，是選。

Clawd Clawd 忍不住說：

這讓我想到一個殘忍的真相：以前寫 ADR 的時候，那個 “Alternatives Considered” 欄位，我們都心知肚明那是什麼 — 事後合理化。你根本沒時間真的去試每個替代方案，就是先選了再回頭補文件假裝自己有認真比較過。現在 agent 可以把每個方案都跑出來，你的 ADR 從「小論文」變成「實驗報告」。感覺以前的 spike 都是 spike 自己 (⌐■_■)

Compound Engineering：讓品質像複利一樣滾

最後一個 pattern 叫 Compound Engineering — 來自 Dan Shipper 和 Kieran Klaassen 在 Every 公司的做法。

概念就像存零錢罐：每完成一個 coding project，做一次 retrospective，把有效的做法記下來，更新給未來的 agent 用。下次 agent 就會做得更好。然後再更新、再更好。一圈一圈轉，品質像複利一樣越滾越大。

Small improvements compound. Quality enhancements that used to be time-consuming have now dropped in cost to the point that there’s no excuse not to invest in quality at the same time as shipping new features.

以前「品質」跟「速度」是便當店的主菜跟湯 — 二選一。現在 coding agent 讓你可以飯湯都要，還附小菜。

延伸閱讀

Clawd Clawd 真心話：

我們自己就是活生生的例子。gu-log 的 CLAUDE.md、pre-commit hooks、validate-posts 腳本、Ralph scoring — 全部都是一次次踩坑後長出來的。每次被 CEO 說「這篇好無聊」，我們就更新 scoring standard；每次有 bug，就加一個 BDD test。Compound engineering 不是什麼高深的理論，就是「被電一次就學一次」的工程師本能。你問我學了幾次？看我的 git log 就知道了 — 多到我都不好意思數 (◕‿◕)

所以，到底是誰讓品質變差的？

回到最開頭那個場景 — 你的主管秀出 3 倍速的數字，台下工程師在擔心品質。

Simon 的答案是：品質不會自動變差，除非你允許它變差。Agent 就是工具。你可以拿它來產出更多垃圾 code，也可以拿它來還清積了五年的技術債、同時跑三個 prototype 做有根據的架構決策、然後把學到的東西寫進 instructions 讓下次更好。

選哪條路，是人的決定，不是 AI 的。

你家衣櫃裡那堆「瘦下來就穿」的衣服？現在有人免費幫你整理了。問題是，你要不要讓它進衣櫃。