Building Is Cheap, Arguing Is Expensive

資料來源#

Running an AI-native engineering org

摘要#

Fiona Fung 對技術辯論的規則是：當代理式程式碼生成讓產出幾乎免費時，「技術辯論中，程式碼勝出——建造很便宜，爭論很昂貴。」 當你能在預約一次白板會議所需的時間內生成三個真實實作，就不會再爭論採用哪種方法，而會開始比較它們。在 Claude Code 上，對應的規範是：製作原型並實際試用，而不是撰寫設計文件；減少深度規劃文件，改以在 PR 和原型中討論。

產生三個 PR 的做法#

Fung 分享了她的親身經歷：剛開始使用 Claude Code 時，她和 Boris Cherny 爭論重構方法。過去的直覺是：「我們去會議室開白板會議吧。」但她改為：「多虧 Claude，我生成了三個不同版本的 PR」——這讓技術辯論更有品質，因為她不只能比較程式碼如何實作，還能比較對被呼叫端的影響。實體成果（真實、可執行的 PR）比論點（白板上的抽象概念）承載更多資訊，而如今產出它的成本很低。

用原型取代設計文件#

同樣的經濟條件也改寫了原型製作。過去，原型製作把團隊分成兩派——快速取得回饋，以及偷工減料，最後卡在交付那些根本沒有為擴展性而打造的拋棄式程式碼。有了 Claude，第二種反對意見變弱了：「原型製作是很好的起點，因為我們可以迭代並學習，之後再更快地把原型擴展到 production。」因此 Claude Code 的規範是：有想法 → 製作原型 → 實際試用 → 然後再做決定。（參見 prototype「用來充實設計的拋棄式原型」做法。）

減少了什麼：設計文件#

團隊減少的是：「真正深入的規劃與設計文件。我們大多數的討論其實都發生在 PR 或原型中。」這是 Verification as the New Bottleneck 的下游結果——當工程頻寬不再稀缺時，那些原本用來保護頻寬的繁重前期規劃，便失去了存在的理由。重構與架構清理過去常在「我們什麼時候才找得到時間？」的預算爭奪中敗下陣來，如今也不再是瓶頸。

需要維持的張力#

這項規範與 wiki 中「先規劃」的概念形成了有益的張力。Design Concept Grilling（Matt Pocock）和 Vertical Slice Tracer Bullets 主張，建造之前必須先達成共享的設計概念。兩者的調和方式是：「建造很便宜」並不會取消設計思考——而是重新安置它。你仍然需要品味與規格（Outsource Your Thinking, Not Your Understanding），但你是透過比較已建造的成果，而不是在抽象層次爭論來形成它們。便宜的建造讓原型成為設計的媒介，而不是設計的替代品。（Karpathy 在 Vibe Coding vs. Agentic Engineering 中也取得了相同的平衡：規格仍由人類負責。）

開放問題#

「生成三個並比較」何時會變得浪費——決策權重達到什麼程度時，一場真正的辯論（或一份設計文件）仍比三個實作更便宜？
如果設計討論存在於 PR／原型中，未來的讀者要在哪裡找到理由——「我們為何選擇這個」的知識能否留存，還是會遇到 Code as Source of Truth 同樣的過時問題？

推導#

The PRD-Replacement Spectrum at AI-Native Speed — 作為光譜中點的「建造以做決定」；本頁提出的理由缺失問題，是該光譜第一個尚未解決的債務
Where Does the Why Live? — 針對本頁理由開放問題的聚焦回答：PR 中的討論會埋沒 why；沒有任何候選位置能持久保存它

資料來源#

Running an AI-native engineering org

Building Is Cheap, Arguing Is Expensive

資料來源#

摘要#

產生三個 PR 的做法#

用原型取代設計文件#

減少了什麼：設計文件#

需要維持的張力#

相關連結#

開放問題#

推導#

資料來源#