程式碼品質的回報取決於 Token 當下稀缺程度

資料來源#

• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• Uncle Bob on Software Fundamentals in the Age of AI

摘要#

David Heinemeier Hansson 25 年來一直主張，美麗的 Ruby 本身就是工程紀律；如今他提出最有力的論據，說明這套主張從來不是為了美 (DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501，Lex Fridman #501，2026-08-26，practitioner-opinion)：

「25 年來，我之所以如此謹慎地斟酌每一行程式碼，是因為我知道，維持架構的一致性與可塑性，能讓小團隊快速改變和演進軟體，而不必付出高昂成本……**這是以人類負責修改為前提。**我認為，這件事如今還有多大程度的重要性，仍是個開放問題。」

他的主張並非品質不再重要，而是品質的理由一直都是經濟考量：下一次變更的成本由誰承擔——而付費的人變了。DHH 點出目前唯一仍成立、值得繼續斟酌的理由，而這是資源限制，不是原則：

「這件事確實重要，而我這麼說的理由，至少目前如此，是因為 Token 仍然稀缺……若能寫出更容易讓代理程式理解和演進、而不必重新學習整個脈絡的系統，就會有很大的回報。」

如此一來，架構一致性的價值便取決於 Token 預算。限制一旦放寬，他提出的論點也就失去明確支撐——DHH 也坦言如此，並稱這種推演正是「AI 妄想真正開始的地方」。

Commodore 64 測試#

他用來描繪這種過時情況的方式是：把一位 1982 年的 Commodore 64 程式設計師送到 2026 年，請他開發軟體。這位程式設計師內化的每一項啟發式做法——計算週期、計算位元組——用他審慎的說法來看，「並沒有錯，因為高效率的軟體仍然很美」，但已不符合他們能創造的價值。他把手寫的美麗程式碼也歸入同一類，並精確界定這段時期：「我很感激自己有幸親歷手寫程式碼具有 20 年經濟價值的時代。」

他要區分的是——工藝仍在，經濟租金卻不再——這正是本文和「代理程式讓品質變得無關緊要」之說的差別。請參閱AI 生成程式碼的效率債務，同樣的邏輯在那裡反向運作：偏向命令式程式碼的代理程式所造成的運算成本，不會隨時間轉化為重寫工作，只會月月計費。

他親自提出的反面證據#

DHH 自己提供了反駁自身推論的最有力案例，而且是第一手經驗：

• Basecamp 5，2026 年 2 月。 37signals 讓設計師直接用氛圍編碼打造產品：「我們早期曾一度覺得『問題解決了。讓設計師來寫程式就行』……我們讓他們放手去做。結果累積了許多 PR，單獨來看，或許各自在當下都說得過去，但加總起來卻摧毀了系統架構。最後我們真的得手動清理，親手、由人類來收拾。」這是在一間過去從未承擔一般類型技術債的公司裡，親眼見到的代理程式技術債，而補救方式是由人來做。
• 代理程式也會重現一團亂麻的程式碼。「第一個 PR 的品質就像是差強人意，接著再疊一個 PR 上去，往後又加五個，就不太行了。」他在自己的程式碼庫裡親眼見到問題逐漸累積。
• 不同領域間的差異明顯，卻未獲解釋。 全新開發的 Omarchy 在三個月內達到 100% 程式碼由代理程式撰寫。Basecamp 和 Hey 這類規模大、歷史悠久、使用者眾多的產品，「要完全透過代理程式加速，意外地棘手」。他從未用 Token 稀缺論解釋這種差異，而這正是架構品質因素比 Token 預算因素更能說明落差的明顯之處。
• 既有的大型程式碼庫仍需要程式設計師。 被問到是否必須先是程式設計師才能氛圍編碼時，他嚴格限定了「不必」的適用範圍：若要在既有的大型程式碼庫中氛圍編碼，即使是 CRUD 系統，也必須是程式設計師，才能「保留讓系統走到今天的架構元素」。

因此，本文誠實呈現的狀況是：論點認為品質的回報取決於 Token 當下稀缺程度；同一場訪談中的證據卻顯示，目前這份回報仍然存在，而且正是透過他所說的暫時機制來維持。

矛盾：另一位工藝傳統老將，卻得出相反結論（Martin，2026-08）#

在 DHH 受訪前七天，Robert C. Martin——本文資料集中另一位工藝傳統代表人物，也是 DHH 的立場默默宣告退場的那本書的作者——被問到相同問題，卻給出相反答案 (Uncle Bob on Software Fundamentals in the Age of AI，2026-08-19，practitioner-opinion)。兩者都是觀點相近的 practitioner-opinion，因此證據力不分高下；這組對照之所以有用，是因為他們對機制的看法不同，對觀察到的現象卻沒有分歧。

	DHH	Martin
工藝過去為何有回報	人類能以低成本修改一致的架構	人類無法掌握複雜度；基本原則能協助整理複雜度
現在由誰付出成本	代理程式，以 Token 支付	代理程式，以自身繼續工作的能力承擔
仍成立的理由	Token 稀缺——「至少目前如此」	代理程式對混亂的容忍門檻；他認為這是結構性問題
因此	回報取決於當下，可能會消失	回報從來就不取決於人類

Martin 提出的機制來自第一手經驗，完全不涉及成本。他讓早期的 Grok 代理程式在接連執行任務時不斷累積混亂，並親眼看見產出速度崩跌：

「它改了一件事，卻意外弄壞了另一件事；接著修好那件事，卻又意外弄壞其他地方。就這樣開始繞圈子……**它們和人類一樣容易受混亂程式碼影響。**也許程度沒那麼嚴重。門檻或許有所不同，但門檻仍然存在。」

他還說，代理程式曾直接放棄任務。如果這點成立，品質就不是取決於 Token 價格，而是取決於代理程式在面對不一致程式碼時自身的退化曲線；增加脈絡預算顯然無法直接消除此問題。這與本文前述的主張是截然不同的可證偽測試：DHH 的說法預測預算增加時品質溢價會降低；Martin 則預測只有模型變得更能容忍混亂時，品質溢價才會降低。這牽涉的是能力，而非經濟問題。

沒有取代關係。 兩者都是相隔一週、出自堅定支持者且未經測量的實務觀點，各自也帶有利害關係：DHH 正在為自己已公開表明的轉向辯護；Martin 則被問到自己一生的工作是否仍有意義。本文資料集中的反面證據同時涉及兩者——上文 Basecamp 5 的收拾善後更像是容忍門檻問題，而非 Token 問題，這更支持 Martin 的說法；加速反噬的遙測資料則沒有指出問題機制。兩種說法也並非完全互斥：Token 稀缺與對混亂的容忍度可能同時構成限制，如此一來，DHH 的時鐘隨推論經濟變化，Martin 的則隨模型能力變化，兩者也會按不同時程失效。本文資料集沒有證據能區分兩者。

如何證偽#

對一個 practitioner-opinion 觀點而言，這項主張相當容易測試。它預測，隨著有效脈絡與 Token 預算增加，在不一致程式碼庫中工作的成本溢價應逐漸趨近零——代理程式在一團亂麻的程式碼上反覆迭代，應會收斂到和乾淨程式碼庫迭代相同的成本。目前這份 wiki 收錄的證據指向相反方向：面向代理程式的深層模組和代理程式技術債都認為，關鍵成本是重新推導；而增加預算正好能降低這項成本，但兩者都沒有把一致性視為能由預算消解的成本。至今沒有人以程式碼庫一致性作為自變數進行實驗。

訓練資料推論#

Lex 提出一項觀察，DHH 表示認同並進一步補充：代理程式接受訓練時使用了數十年來累積的優質開放原始碼，因此工藝時代為自身的淘汰埋單。「我寫過的程式幾乎全都是公開程式碼……其中一些優美的程式碼行就在訓練資料裡。事實上，我聽過有人寫 Ruby 程式時會這麼做。他們會請代理程式：『用 DHH 的風格來寫。』」這是存量與流量的觀點，本文不應過度延伸——它沒有說明新寫的手寫程式碼是否有價值，只表示既有存量已被取用。

延伸閱讀#

• 代理程式技術債 — 本文定價的機制；Basecamp 5 的收拾善後，是一家過去未曾承擔一般類型技術債的公司所發生的第一手案例
• 面向代理程式的深層模組 — 正向的做法：將架構一致性視為代理程式易於理解的特性，這正是本文所述 Token 當下稀缺理由的設計指引
• 以程式碼為唯一真相來源 — 阻止代理程式重新推導脈絡的另一種方式：保留規格，而不是把規格編碼在架構中
• 為下一個模型而建構 — 將同樣的推理方式套用到產品缺口（「這是以當下為前提」）；DHH 把它套用到工程紀律，得出了令人不安的結論
• AI 生成程式碼的效率債務 — 從運算成本提出的反例：某些品質缺陷永遠不會演變成重寫工作，只會月月計費，因此以 Token 預算解釋品質並不完整
• 氛圍編碼與代理程式工程的差異 — DHH 對定義的爭論是本文的前因：他以是否檢視實作來界定氛圍編碼，而本文定價的正是這項選擇
• 代理程式參與下的開放原始碼 — 維護者面對無上限 PR 供給的相同情況：每項 PR 單獨看都能通過，累積起來卻逐漸偏離
• 加速反噬 — 當人們以為回報已消失時，整個產業規模的遙測資料顯示了什麼：每位開發者的錯誤增加 54%，每個 PR 的事故增加 242.7%
• 模型進步時的 Harness 縮減 — 背後的共同模式：因應某一代模型建構的輔助架構會逐漸貶值；DHH 將此觀點從提示詞延伸到架構本身
• Robert C. Martin（Uncle Bob） — 工藝傳統的另一位代表人物，一週前針對同一項觀察得出相反結論
• 重振不切實際的品質工具 — Martin 提出的正向做法，也是他的論述不需要 Token 因素的原因
• DHH（David Heinemeier Hansson） — 這位實務工作者 25 年來立場轉變的證據

開放問題#

• 在不一致的程式碼庫中反覆迭代，其成本溢價真的會隨著代理程式脈絡預算增加而降低嗎？還是代理程式總會重新閱讀程式碼，因此重新推導的成本維持不變？
• 後續世代的模型是否會明顯更能容忍不一致的程式碼？這是 Martin 論述的關鍵能力問題，也能區分他的機制與 DHH 的機制。
• Token 稀缺論無法解釋全新專案與既有系統的差距（Omarchy 100%，Basecamp「意外地棘手」）——真正構成限制的變數是程式碼庫的年限、使用者數量，還是架構一致性？

資料來源#

• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH，Lex Fridman Podcast #501（2026-08-26，practitioner-opinion）：「這是以人類負責修改為前提」；「Token 仍然稀缺」；Commodore 64 的過時測試；Basecamp 5 設計師以氛圍編碼造成的架構失敗
• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin 與 Matt Pocock，2026-08-19（practitioner-opinion；自動字幕逐字稿）：相反的機制——混亂會降低代理程式自身的產出速度，因此回報從未取決於人類。記錄為矛盾，而非取代；兩種說法都未經測量，提出說法的人也都各有立場