[AI 衝擊] DHH從拒絕AI到全面採用Agent開發

[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形容，完成一天工作後，就像剛從賽車裡爬出來一樣疲憊。