[AI 衝擊] DHH從拒絕AI到全面採用Agent開發
摘要：DHH以Omarchy實證AI Agent如何重塑程式開發、開源協作與工程師角色。
內容:
13個月前，Ruby on Rails創始人、37Signals技術長大衛・海涅邁爾・漢森（David Heinemeier Hansson，DHH），還在播客上公開表示對AI寫程式碼不太感興趣。13個月後，他坐在同一個位置，告訴主持人自己已經連續兩個月沒有親手寫過任何一行程式碼。
2026年8月，DHH第二次做客Lex Fridman的播客，進行了一場超過5小時的長談。他帶著一台預裝自研Omarchy作業系統的戴爾筆記型電腦，現場展示不到一分鐘便能從開機完成安裝並進入桌面的過程。
節目錄製後，他還宣布成立OmaCom基金會。Shopify、Stripe、Dell、Block等科技業領袖共同出資，總額達1,000萬美元，目標是推動Linux桌面真正普及。
九個月內，發生數十年的進步
DHH引用列寧的一句話作為開場：「有些十年什麼都沒發生，有些幾週卻發生了數十年的事情。」在他看來，過去九個月，AI領域就經歷了數十年的進步。
最初，AI對他而言只是查詢資料與補全程式碼的工具，並沒有從根本上改變工作方式。真正的轉折點是2025年11月24日，Anthropic發布Opus 4.5。
DHH安排了幾項任務後發現，AI輸出的品質已經不可思議地接近自己的水準。他認為變化分成兩層：第一層是模型變得更聰明；第二層，也是更關鍵的變化，是AI取得了使用工具的能力，能操作電腦、執行任務並檢查自己的成果。
他甚至表示，即使Opus 4.5是最後一個模型，自己也已經心滿意足，足夠再使用20年。
然而，進步並未停止。2026年初春，Subagent出現，一項任務可以拆成八個子任務同步執行，速度提升5至10倍。到了夏天，Opus 5、Fable、GPT-So等模型陸續出現，使用者只需要描述問題，Agent便能自行規劃解決路線。
DHH將這項轉變總結為：以前是告訴Agent該往哪裡走，現在只需要告訴Agent自己遇到了什麼問題。
Omarchy：沒有手寫發布程式碼的系統
DHH用來證明這種轉變的核心案例，就是基於Arch Linux打造的桌面發行版Omarchy。
Omarchy Bootstrap版本的開發週期為三個月。在此期間，DHH沒有親手撰寫任何一行正式發布的程式碼，所有程式碼均由Agent生成，他主要負責審查整體品質與方向。
例如，他想要一款極簡的Markdown編輯器，便要求Agent使用C++和Qt開發。20分鐘後，AI完成第一個版本；兩天內，他就拋棄原本使用的Taper。此後，他的文章都改用這款名為Oma Write的編輯器撰寫，但他從未閱讀過其中任何一行C++原始碼。
另一個案例是，某個Python函式庫的資源占用過高。DHH要求Fable製作Rust版本，45分鐘後便完成，啟動時間從86毫秒降至2毫秒，執行檔大小僅約3MB。
整個過程中，他沒有查看任何一行Rust程式碼，而是直接讓Agent建立儲存庫、發布套件、提交程式碼與合併請求。
DHH也藉此進行模型橫向測試。Fable最快，約45分鐘完成，但成本約550美元；GPT-So約需1.5小時，成本約46美元；Grok 4.6約55美元；DeepSeek V3 Pro約23美元；Kimi K3也成功完成任務。
GPT Luna則未能完成，甚至試圖抄襲既有實作；DeepSeek V3 Flash也無法自主循環完成工作。雖然Fable最快，但其他模型只花約十分之一的成本也能交付成果。經過後續兩輪最佳化，最終Rust版本的速度比原本Python版本快了46倍。
大型軟體為何還沒有明顯加速？
Lex Fridman觀察到，大型軟體似乎尚未因AI而顯著加速迭代。DHH從三個層面回應這個問題。
第一是「人」。大型組織的主要阻力往往不是實作，而是人員怠慢、溝通與協調。若要取得10倍、100倍甚至1,000倍的生產力提升，就必須直接與Agent互動，不能在中間再加入另一個人，因為人類的溝通速度太慢。
第二是「想法」。多數組織真正缺乏的是願景與品味，而不是編碼能力。微軟擁有近乎無限的程式設計資源，卻不代表一定能產出令人心動的軟體。
第三是「時間」。這種程度的AI能力才出現約半年，人類歷史上幾乎沒有任何技術進展得比AI更快，因此現在就嫌它改變得太慢，並不合理。
Vibe Coding仍可能破壞架構
DHH也坦承，37Signals曾讓設計師直接使用Agent撰寫程式碼。單獨檢視每個PR時似乎都沒有問題，但合併後卻破壞了整體系統架構，最後不得不由工程師手動清理。
因此，他認為在既有的大型程式碼庫中進行Vibe Coding，若要維持架構完整性，目前仍然需要程式設計師參與。
不過他也反問：「如果有人批評Vibe Coding產出的都是垃圾，那麼你看過普通程式設計師的產出嗎？其實很多也同樣是垃圾。」
AI正在引發開源世界的宗教改革
DHH將AI對開源社群的衝擊，比喻為馬丁・路德發起的宗教改革。
過去，開源軟體宣稱所有人都能貢獻程式碼，但實際上只有少數具備高技術能力、宛如「祭司階層」的人能真正參與。現在，AI Agent正在拆除這道門檻。
在Omarchy約三個月的開發期間，DHH合併了超過1,000個PR，其中許多來自非傳統程式設計師。
對於維護者抱怨AI產生大量低品質PR，他並不認同。經營開源專案25年來，他看過成千上萬名程式設計師的成果，發現多數人提交的PR原本就不理想：不寫測試、不提供關鍵資訊，也不檢查自己的工作。相較之下，Agent反而更常完成這些基本要求。
他甚至表示，自己現在更願意收到Agent撰寫的PR，不僅品質可能更好，拒絕時也沒有太大的心理負擔。
如今，他不再親自審查每一個PR。Agent會先進行審查、淘汰品質不佳的內容，再把真正值得由人類判斷的「珍珠」呈現出來。在他看來，開源工作中的大量苦差事正以驚人的速度消失，留下最精華的創造與決策部分。
好想法不一定只來自人類
當Lex追問「真正的好想法是否最終仍然來自人類」時，DHH表示自己過去也這麼認為，但現在已不再確定。
他已經看過模型提出好到令自己自愧不如的想法。那些仍堅持Agent只是「鸚鵡」的人，很可能忽略了過去六至九個月的巨大進展。
至於這種工作方式究竟該叫什麼，DHH非常討厭「Agent Engineering」這個詞，認為它已經成為行銷用語。他對「Vibe Coding」也有所保留，覺得它聽起來像2000年代初期下載現成PHP腳本直接使用的「腳本小子」。
在他的定義中，如果完全不查看實作，確實可稱為Vibe Coding；若仍會審查實作、架構與品質，那就是另一種工作模式。
程式設計知識有時反而成為限制
Lex認為，擁有程式設計經驗的人應該更擅長使用Agent。DHH只同意一半。
他認為，在某個階段，知道太多程式設計知識反而可能成為劣勢，因為程式設計師會要求Agent按照自己的既定方法工作。當模型已經進步到只需描述問題、不必規定解決路徑時，Agent反而可能提出比程式設計師預想更好的方案。
他也提到CLAUDE.md等指令檔案。過去，人們會撰寫很長的指令來微調Agent，但Claude Code團隊後來將Opus 5的系統提示詞縮減約80%，因為過度規定反而可能損害表現。
這就像不懂程式設計的主管不斷指手畫腳，最終只會讓程式碼變得更差。DHH認為，好的軟體是在實際使用過程中逐步被發現的，而不是在規格書中一次設計完成。
從單執行緒轉向多機、多Agent並行
DHH自己的工作環境，也已經從單執行緒轉變為多台機器、多個Agent同步執行。
他最初使用Tmux，後來轉向名為Heather的工具，由系統通知哪個Agent已經完成任務。之後，他購買GL.iNet Comet設備，將閒置的Mini PC全部連線，並透過Tailscale建立虛擬區域網路，讓自己能隨時從手機連接馬里布與哥本哈根辦公室的電腦。
目前，他大約可以同時執行16個工作執行緒。相較一年前每小時約20行程式碼的產出，現在已能達到每小時數百行。
他的日常流程，是在Heather中執行Claude Code、Codex與OpenCode，再以Opus或Fable撰寫程式碼，並交由其他高階模型交叉審查。最近他也開始使用Grok進行審查；推送至GitHub後，再由Copilot檢查一次。
他表示，Copilot現在確實有所進步。過去標記出的問題多半沒有價值，如今已經能找到真正的缺陷。
不過，這種多執行緒、多Agent並行的工作方式也非常消耗腦力。DHH形容，完成一天工作後，就像剛從賽車裡爬出來一樣疲憊。
