這裡要提的 Spec‑Driven Development（SDD） 爭議，並不是這個方法論有問題，而是核心問題這 30 年來從未改變，這是一種結構性限制。
試想有一位架構師花了數個月，透過採用 Spec‑Driven Development（SDD）的方法論，嘗試搭建出一套系統，但結果卻非常諷刺：
- 所有 Spec 都完全正確、完全符合規格文檔
- AI 也照著規格完美實作
- 但成品完全不是他想要的
問題點不是於他寫錯 Spec，而是這份 Spec 包含了三種本質不同的東西：
- 他想達成的目標（Intent）
- 如何驗證是否達成（Validation）
- 他決定的技術方案（Implementation）
當這份文件包含了這麼多個面向的內容時，在時間的推進過程中，就會很可能其中一個假設改變，造成接下來 42 個決策全部失效。
之所以會造成這個問題，並不是 SDD 有問題，也不是他不如 Intent‑Driven Development，但大家忽略了一個長久以來的殘酷問題。
臨時補丁
SDD 想要解決的核心問題是：AI Agent 沒有上下文。
正是因為如果沒有上下文，AI 就不知道你想要達成的目標是什麼，預期的架構長怎麼樣，也不知道你想要避開那些坑，甚至不知道你心中的開發模式有哪些約定，所以它產出的程式碼就會變成局部合理，但整體是錯誤的。
因此有人提出了 SDD 的方法論，說：那我們就把上下文全部寫在 Spec 裡，讓 Agent 照著做。
這非常合理，因為這本質上是你補足了 AI 目前做不到的能力。
但發展到一定程度之後，AI 開始能自己讀懂整個程式庫、自己問問題、自己累積經驗，你還需要寫這些 Spec 嗎？或許不再需要了。
因此 SDD 像是專案起始時的一個臨時補丁，幫助你彌補 AI 的短板，但它似乎不是一個長久的解決方案。
之所以失敗
SDD 之所以失敗，其實跟 1995 年的失敗機制完全一樣。
為什麼大型專案的前置設計（Big Design Up Front）從 1995 年至今會反覆失敗，主要原因就是我們預期自己能完全瞭解設計的目標、要求和範圍。
這失敗造成了一次又一次昂貴的專案延期、交付錯誤，甚至完全交不出來，嚴重到催生了整個敏捷運動。
嚴格來說 SDD 達成了敏捷宣言中的第一項：通過早期和持續交付有價值的軟體來滿足客戶的需求。
但卻在敏捷宣言的第二項栽了跟斗：歡迎不斷變化的需求，即使是在後期開發中。
因為我們不可能在動手之前，就知道所有需要知道的事。
所以問題是不 SDD 寫得不好、寫得不夠完整，而是規格總是寫在實作之前，而理解卻永遠來自實作之後。
改變了什麼？
AI 確確實實的在開發過程造成巨變，真正核心的改變是：實作速度變快，而且是快的難以想像。
AI 沒改變什麼？我們仍然無法在開始前知道所有資訊。
這跟 1995 年的失敗機制一模一樣，到如今有改變嗎？沒有。
而且由於 AI 的開發速度的背後，產生了一個新的開發成本項：Token 成本。
SDD 有一個隱含假設，AI 能讓產出變便宜，因此錯了重來的成本就比較低，所以前置 Spec 可以寫更大、更完整。
但這樣其實比較便宜，事情反倒恰好相反。錯誤的 Spec 會造成更高的成本，因為 Agent 會照著錯誤 Spec 完整跑一遍，浪費 Token（全新的成本項），還浪費工程師審查時間（審查速度不會像生成速度那樣提升）。而這個錯誤的 Spec 可能並不是字面上的錯誤，而是來自於需求上的改變。
在這個循環中，AI 讓你更快發布，但也可能讓你更快發布錯誤。
以前看起來慢吞吞的流程，反而給了團隊一些一個自然的緩衝，在發布前發現問題的機會，現在這個緩衝正在消失。
值得探索的方向
SDD 在對的位置、對的時間，解決了對的問題，特別是在專案之初，我們將看見的全貌寫成 Spec，讓專案更容易啟動，但它並不是一個長久的解決方案。
我們可以在專案初期花大量時間來理解、定義、規劃，然後把這些內容寫成 Spec，讓 AI 照著做，但當 AI 的上下文能力提升到足以理解整個專案的全貌時，我們還需要這些 Spec 嗎？或許不再需要了。這時候基於 SDD 的開發流程就可以功成身退，轉身去面對另一個問題。
迭代。
在敏捷運動和 DevOps 的推動下，迭代已經成為軟體開發的主流模式，但當迭代的一方是 AI 時，人與 AI 之間「更短的反饋迴圈」應該長什麼樣？這才是開發者現在要去探索的真正核心問題。
參考資料：