不知不覺來到了最後一天。在這段時間研究 AI Coding 的過程中，發現了一篇很有趣的文章：《Is Design Dead?》。

有趣的是，這篇 26 年前的文章，討論的問題竟然跟現在 AI Coding 的情境非常相似。

Is Design Dead?

2000 年，Martin Fowler 發表了 Is Design Dead?。

當時 Software Engineering 正在經歷一場方法論的衝突：Traditional Software Engineering vs. Extreme Programming（XP）。

雙方對 Upfront Architecture Design 有很大的分歧。

傳統 Software Engineering 傾向在 Coding 前先做好 Architecture Design，避免未來修改的成本太高。

但激進的 XP 支持者，例如 Kent Beck、Ron Jeffries，則認為應該盡量減少 Upfront Design。與其預先猜測未來的需求，不如先實作當前需要的功能，相信後續能透過持續 Refactoring 讓 Design 演化。

這是否像極了現在使用 Coding Agent 的情境？

兩種極端的開發模式：

1. God Spec First：先與 Coding Agent 討論出一份完整的 God Spec，產生萬行以上的 TODO，試圖在 Implementation 前定義所有細節。
2. Prompt and Fix：完全不討論 Design，先叫 AI 生成一版，AI 寫 Tests、AI 解 Bugs，等到架構改不動了，再叫 AI Refactor。

而這兩者分別面臨不同的問題。

前者 假設我們能夠預先掌握足夠完整的 Requirements，但 Software Development 本身就是不斷探索與迭代的過程，很難真的存在一份永遠正確的 God Spec。

後者 則優先追求眼前的 Development Speed，但如果持續累積臨時性的 Design Decisions，最後可能導致 Cost of Change 越來越高。

而 Fowler 當時想探討的核心問題之一，正是 Cost of Change。

他提出了另一種思維：與其試圖預測所有未來的變更，為什麼不直接降低變更本身的成本？

這也是 Evolutionary Design 的核心思想：Design 不需要在 Implementation 前完全確定，而是可以隨著 Requirements 與對系統的理解持續演化。

另外，Fowler 也沒有完全認同激進的 XP 觀點。
有些 Architecture Decisions 一旦做下去，未來可能很難逆轉。因此，他認為仍然需要適當的 Upfront Design，而不是相信所有架構問題都能在未來透過 Refactoring 解決。

但這也讓我想到一個問題：

既然現在有 AI Coding Agent，當 Codebase 變得難以修改時，直接叫 AI Refactor 不就好了？那還需要 Design 嗎？

Why Is AI Refactoring Still Hard?

2026 年 ICML 有一篇論文：CodeTaste: Can LLMs Generate Human-Level Code Refactorings?。

研究發現，當 Refactoring 的目標已經明確定義時，Coding Agent 的表現相對較好。

但如果只給 Agent 一個需要改善的 Code 範圍，讓它自行找出應該如何 Refactor，就比較難找到與人類開發者一致的 Refactoring Decisions。

但這就有兩個不同的問題需要提出：

1. When to Refactor? 如何判斷什麼時候值得進行 Refactoring？
2. How to Refactor? Agent 如何理解整個 Repository、Business Domain，進而決定合理的 Architecture Boundaries？

尤其第二點，並不是給 Agent 更大的 Context Window 就一定能解決。

因為正確的 Architecture Boundary 不只取決於目前的 Code，還包括未來可能發生的 Changes、Business Constraints，以及各種 Design Trade-offs。

AI 能夠執行 Refactoring，不代表它就能自動做出正確的 Design Decisions。

即使未來 AI 能夠解決這些問題，也只是 Design 被自動化，而不是 Design 不再重要。

Evolutionary Design in the AI Era

回到現今 AI 時代的 Software Engineering，Fowler 當初的核心觀念依然適用：持續控制 Cost of Change，讓 Software 能夠隨著需求演化。

只不過，Coding Agent 的出現改變了其中一部分的成本結構，也讓我們需要重新思考如何實踐 Evolutionary Design。

Fowler 當初強調三種讓 Evolutionary Design 成為可行策略的 Engineering Practices：

• Automated Testing：快速偵測修改是否破壞既有行為。
• Continuous Integration：降低整合成本，持續驗證系統。
• Refactoring：持續改善內部設計，避免複雜度不斷累積。

現在透過 Coding Agent，這些工作的執行成本都有機會進一步降低。

從產生 Tests、分析 CI Failures，到協助進行 Refactoring，都可以減少大量重複性的手動工作。

這也代表我們可以用更低的成本進行 Implementation、Validation，再根據實際結果調整 Design。

但我認為，在 AI Coding 的情境下，還有另外兩個需要特別注意的維度。

Understanding & Ownership / Explicitness & Consistency

1. Understanding & Ownership

即使 Code 是 AI 寫的，Engineer 仍然需要理解自己正在維護的 System。

現在我們可以花幾分鐘讓 Coding Agent 完成原本需要數小時的 Implementation。

但 Code Generation 的速度提升，不代表我們對系統的理解也同步提升。

如果每次增加 Feature 都直接交給 Agent，而 Engineer 對系統的理解始終停留在幾個版本之前，長期下來可能會發生一個問題：

我們越來越依賴 AI 修改系統，卻越來越難判斷 AI 修改的方向是否正確。

這不代表需要逐行閱讀每一段 AI 產生的 Code。

而是至少需要理解：

• Architecture：系統的主要 Components 與 Dependencies 是什麼？
• Boundaries：不同 Modules 各自負責什麼？為什麼這樣切分？
• Invariants：哪些 Business Rules 與 System Constraints 不能被破壞？
• Trade-offs：當初為什麼做出這些 Design Decisions？

否則，當 Coding Agent 提議 Extract Service、引入 Abstraction，甚至重新切分 Module Boundaries 時，我們又該如何判斷這個 Refactoring 是否合理？

AI 可以協助我們理解 Codebase，但不應該因為 Implementation 被自動化，就放棄對整個 System 的理解與責任。

2. Explicitness & Consistency

另一個更重要的事情，是讓系統中重要的 Design Intent 與 Constraints 變得明確且一致。

傳統 Software Development 中，有些重要資訊可能只存在於某個 Engineer 的腦袋裡。

例如：

• 為什麼這兩個 Modules 不能直接互相依賴？
• 為什麼某個 API 必須維持 Backward Compatibility？
• 為什麼這段 Business Logic 不能移到另一個 Service？

人類工程師可能透過長期合作、Code Review 或口頭溝通理解這些背景。

但 Coding Agent 不一定擁有相同的 Context。

如果 Design Decisions 沒有被明確記錄，Agent 可能只能從現有 Code 推測原本的設計意圖。

而當 Documentation、Implementation 與 Tests 之間存在互相矛盾的資訊時，Agent 也需要自行判斷哪個才是正確的。

這些都可能增加 Agent 理解與修改系統的成本。

所以在 AI 時代更需要重視 codebase quality，不限但包含：

• 明確定義 API、Data Schema 與 Module Interfaces
• 紀錄重要的 Architecture Decisions 原因
• 確保 Documentation 與現有 Implementation 同步，避免過期或互相矛盾的資訊、
• 透過 rule-base 規則，將重要的限制轉換成可驗證的條件 e.g., linter, type checker, test, ...

Explicitness 不是要求在 Coding 前寫出所有細節，而是讓目前已知且重要的資訊足夠明確，並且隨著系統演化持續更新。

這也呼應了 Evolutionary Design 的精神。

不需要預先設計所有未來可能發生的事情，但對於已經做出的設計決策，應該讓它們容易被理解、驗證與修改。

Keeping the Cost of Change Low

把這些放在一起，AI 時代下(我2026年認為)的 Evolutionary Design，不只是加速原本的 Testing、CI 和 Refactoring。

還需要透過 Understanding 與 Explicitness，確保 Engineer 與 Coding Agent 都能在足夠的 Context 下持續演化系統。

我們在 Code Generation 的維度上，確實已經大幅加速。但也正因如此，更容易忽略長期的 Cost of Change。

今天花幾分鐘就能產生數千行 Code，不代表明天也能花幾分鐘安全地修改這些 Code。

AI reduces the cost of writing code, but not necessarily the cost of changing code.

如果每次增加 Feature，都讓系統產生更多 Coupling、更多隱藏的 Dependencies，即使 Coding Agent 越來越強，整體開發效率仍然可能隨時間下降。

AI 時代的 Evolutionary Design，不是完全放棄 Upfront Design，也不是嘗試事先定義完美的 God Spec。
而是利用 AI 加速 Implementation、Testing 與 Refactoring，同時持續維護系統的 Changeability。

Fowler 在文章中還有一個我覺得很重要的章節：The Will to Design。

即使團隊已經具備 Testing、CI 和 Refactoring 的能力，如果沒有人持續關注並改善 Design Quality，Evolutionary Design 仍然可能失敗。

而 26 年後，我認為這個問題依然存在。

只是現在我們不僅需要思考如何讓 Software 容易被人類修改，也需要思考如何讓 Coding Agents 更容易理解、修改與驗證整個系統。

AI 讓我們能更快地寫出 Software，但 Software Engineering 真正需要持續優化的，仍然是軟體隨時間演化的成本。

Software engineering is programming integrated over time. -- Titus Winters

後記

感謝主辦方們今年又舉辦了鐵人30這個活動，讓我又再次的挑戰了自己，也再次的學到了很多東西。

從不理解一筆 mr 為啥能被 review 到破頭，到現在被同事詢問是否有強迫症，我是覺得我成長了XD

另外今年想選這個主題最主要的原因是：

1. 在現今時代，軟體工程有感的被忽視了
2. 嘗試把 software engineering 存在腦中的模糊 mindset，系統性的寫出來
3. 怕自己 brain rot

另外也不得不感慨 AI 進步的速度，去年還在純手寫選綽詞。今年只要先擬好每篇想表達的章節與內容草稿，AI refine 後就變得完整很多。

欸欸 另外我前面有幾篇自覺沒有表達得很清楚，需要再 refine，大家再給我一點時間QQ. (2026-10-13)
更新完成會放上時間戳 -> ()

References

1. Martin Fowler — Is Design Dead? (2000, revised 2004)
2. Titus Winters — Software Engineering at Google, Chapter 1
3. CodeTaste: Can LLMs Generate Human-Level Code Refactorings? (ICML 2026)