Spec-Driven Development: The Waterfall Strikes Back
SSD 當道，我也花了不少錢，這篇在講 SDD的文章不錯，整理參考，推薦原文。
SSD 這套做法其實有點像把 Waterfall 的精神重新包一次裝，在開發之前先讓 LLM 產出一堆規格文件，需求、設計、任務列表，全都用 Markdown 寫好，再把這些交給 Coding Agent（Claude Code、Cursor、Copilot 都算）接著跑。
看起來很有結構，但實際用起來問題不少：
第一，文件量大到荒謬。
一個加日期的小功能，能被生出 1,000 多行 Markdown。工程師真正花最多時間不是開發，而是讀那些過度詳盡的 spec，還要找錯漏。第二，本質是「無上下文」的搜尋行為。
SDD 在讀程式碼的能力上跟 coding agent 沒差多少，常常找不到該動的函式，最後還是要人工審核。第三，流程虛有其表。
所謂的「User Story」寫法根本不對，設計文件充滿重複內容，甚至會生成「先寫一版 code 來當 spec」這種奇怪情況。導致最後你要 review 兩次：一次審規格中的 code，一次審實際產出的 code。第四，隨著 codebase 長大，它越來越無用。
SDD 很適合從零開始，但只要專案一長，這些 spec 的價值就變得有限，因為模型很難真的吃進整個系統的脈絡。
作者的觀點我蠻認同的，SDD 的前提是在想一件其實不太健康的事，也就是能不能讓開發者退出開發？
用大量前置規格「指揮」 AI，讓模型只要照著文件寫。但大家都知道，Big Design Up Front 已經被證明在現實世界裡常常失敗，因為軟體開發就是一個高度不確定的探索過程，不是寫好藍圖就能排除不確定性。
相較之下，作者提出的替代方案其實很接地氣：
將問題拆小，用自然語言快速試錯，一次只推進一個最「風險最高」的假設，像 Lean Startup 那樣增量實驗，讓 coding agent 幫你以小步快跑的方式前進。
這種做法沒有包裝，也沒有很炫的名詞（有些人叫 vibe coding），但實務上反而比較貼近工程師平常的思考節奏。作者展示了他只靠 Claude Code，沒有寫任何規格，10 小時內做出一個可用的 3D sculpting tool，靠的就是不斷修、加、測、再調整。
我覺得這篇文章真正的重點不在「SDD vs Agile」，而是提醒我們：
別急著把 AI 當成需要嚴密規範的外包工程師，更有效的方式，是把它當成能快速試驗的搭檔。
SDD 讓 LLM 回到像是在跑 PM 制度：先寫完所有文件，再允許你動工；Natural Language Development（作者給的名稱）則更符合現代工程文化：小步試錯、快速收斂、讓「上下文 + 人的判斷」一直在循環裡。
SDD 對 coding agent 的想像，就像把內燃機鎖在火車頭裡；我們現在應該在蓋的是汽車、飛機和其他長得不像火車的東西。
作者：早八晚十