DHH 的新程式寫作法：品味、AI 代理與軟體工藝的未來
📋 Brief
Ruby on Rails 創建者 DHH（David Heinemeier Hansson）與 The Pragmatic Engineer 的 Gergely Orosz 進行深度對話，探討他從 AI 懷疑論者到全面擁抱 AI 代理的心路歷程。影片涵蓋了 37 Signals 的產品哲學、設計與開發的融合、AI 如何讓資深工程師產能暴增、以及「我們可能已經過了程式設計師的巔峰期」這個大膽預測。
⏱️ 內容分段導航
| 時間段 | 內容摘要 |
|---|---|
| 00:00 - 06:30 | DHH 的最新專案：從 Omachi Linux 到 Ruby on Rails 的文藝復興 |
| 06:30 - 22:00 | 37 Signals 的產品哲學與設計師的角色定位 |
| 22:00 - 32:00 | 美學即真理：為什麼軟體必須美麗 |
| 32:00 - 44:00 | 從懷疑到轉變：為何自動補全是錯誤的 AI 使用方式 |
| 44:00 - 58:00 | Agent-first 工作流：Opus 4.5 的突破性時刻 |
| 58:00 - 70:00 | 資深 vs 初級工程師：誰從 AI 獲益最多 |
| 70:00 - 83:00 | 從 P1 優化到雙系統啟動：AI 如何擴展了野心邊界 |
| 83:00 - 95:00 | 峰值程式設計師與軟體工程師的未來 |
| 95:00 - 106:00 | 為什麼 DHH 繼續建造：對電腦的熱愛是永恆的驅動力 |
📖 詳細內容
01｜從 Linux 發行版到 Rails 的共同哲學
核心觀點： DHH 新建的 Omachi Linux 發行版在六個月內吸引了 400 位貢獻者和數萬名用戶，再次驗證了他的核心創業哲學：為自己打造最好的工具，世界上一定有 thousands 個和你一樣的人。Ruby on Rails 現在正迎來文藝復興，因為它是「token 效率最高」的 Web 開發框架，非常適合 AI 代理的工作流程。
重要原話：
「每當我打造出真正滿足自己需求的東西，世界上就會有數千個和我一樣的人。」
（原文：「Whenever I build something that really just hits the spot for me personally, there are thousands of others just like me.」）
個人感受： 這個「為自己建造」的哲學看似自私，實際上是最誠實的產品策略。比起試圖猜測市場需求，不如解決自己真實感受到的痛點。
延伸思考： Rails 的「token 效率」優勢是個有趣的反直覺現象——一個 20 年歷史的框架因為 AI 時代而獲得新生。
可參考的行動： 盤點你日常工作中最讓你煩躁的工具或流程，問自己：如果我要為自己打造一個替代方案，它會是什麼樣子？
02｜設計師是產品的核心而非附屬
核心觀點： 在 37 Signals，設計師不只是把規格變好看的人。他們同時扮演產品經理（決定應該建造什麼）、設計師（決定如何運作和呈現）以及前端工程師（實作 CSS、HTML 甚至 JavaScript）。這種三位一體的角色讓設計師直接「觸摸」材料，就像珠寶設計師必須了解黃金的特性一樣。
重要原話：
「37 Signals 的設計師不只是來把規格變好看。他們是來發現規格應該是什麼的。」
（原文：「Designers at 37 Signals are not just here to make a spec look pretty. They're here to find what the spec should be.」）
個人感受： 這種設計師定位與大多數公司的做法截然不同。讓設計師直接操作程式碼，才能讓他們真正理解「這個媒介想要什麼」。
延伸思考： AI 代理的出現讓設計師能更容易地實作自己的想法，這可能會推動整個行業朝 37 Signals 的方向演變。
可參考的行動： 如果你是設計師，嘗試學習基本的 CSS 和 HTML；如果你是工程師，嘗試參與產品決策的討論。跨領域的理解會讓你的產出更有品質。
03｜美學即真理
核心觀點： DHH 堅信「美學即真理」——當某個東西是美麗的，它很可能是正確的。這在數學和物理學中已經被驗證，在軟體開發中也同樣適用。被醜陋、遲鈍、不順暢的系統包圍是現代人焦慮的重要來源。Steve Jobs 之所以在意電路板的內部佈局，是因為在意細節的人也會在意用戶體驗的每個層面。
重要原話：
「我認為美學即真理。當某個東西是美麗的，它很可能是正確的。」
（原文：「I think aesthetics is truth. When something is beautiful, it's likely to be correct.」）
個人感受： 這段話讓我重新審視了自己對「程式碼美觀」的態度。過去我覺得那是錦上添花，但 DHH 說得對——追求美觀的過程本身就是在追求正確性。
延伸思考： Ruby 之所以吸引 DHH，正是因為它能產出「最美觀的程式碼」。語言的選擇不僅是工程決策，也是審美決策。
可參考的行動： 下次寫程式碼或製作文件時，刻意多花 10% 的時間讓它更整潔、更一致。觀察這個額外投入是否帶來了更好的理解或更少的錯誤。
04｜從自動補全到代理：AI 的正確使用方式
核心觀點： DHH 早期對 AI 的反感來自「自動補全」的使用方式——AI 不斷猜測你想寫什麼，像是一個不讓你把話說完的對話者。真正的突破來自兩件事：第一，agent harness（代理框架）的出現，讓 AI 能使用終端、網路和工具；第二，Opus 4.5 的發布，這是第一個能持續產出讓 DHH 願意合併的程式碼的模型。
重要原話：
「我覺得它很煩人……它不斷嘗試。這是你想說的嗎？這是你想說的嗎？你就像，閉嘴吧，我能不能先把一個想法講完？」
（原文：「I found it infuriating... You're constantly trying. Was this what you meant? Was this what you meant? You're like, shut the hell up. Can I just finish a thought?」）
個人感受： 我完全理解這個感受。Tab 鍵補全的 AI 就像一個過度熱心的助手，不斷打斷你的思路。Agent 模式則像是一個聰明的下屬，你交待任務，它自己去完成，你只負責審核結果。
延伸思考： FOMO（錯失恐懼症）在 AI 領域是毫無根據的。你可以跳過 MCP 等中間階段，直接用最新的工具。三週就能趕上。
可參考的行動： 如果你是開發者，找一個你一直想完成但沒時間的個人專案，用 agent 模式（如 Claude Code + Opus）試著完成它。親身體驗比任何論述都更有說服力。
05｜Agent-first 的日常工作
核心觀點： DHH 現在所有工作都從 agent 開始。他的開發佈局是：左邊 Neovim 編輯器，右上角跑 Gemini K25 的 Open Code，右下角跑 Opus 的 Claude Code。他從「code first」翻轉為「agent first」：agent 給出初稿，他審核並修改。最驚人的體驗是讓 Claude 審核 250 個 PR——90 分鐘處理了 100 個 PR，其中一半涉及他完全不了解的領域，Claude 的分析比他更聰明。
重要原話：
「這不像是在當 agent 的專案經理。更像是穿上一套超級機甲，突然間我不只有兩隻手臂，我有十二隻。」
（原文：「It's not like being a project manager for agents. It's more like stepping into this super mech suit where suddenly I don't just have two arms, I have 12.」）
個人感受： 「超級機甲」的比喻太精準了。AI 不是取代你，而是放大你的能力。前提是你有足夠的品味和判斷力來審核 agent 的產出。
延伸思考： 這也解釋了為什麼資深開發者受益最多——他們能判斷 agent 的產出品質，而初級開發者缺乏這個能力。
可參考的行動： 設定一個雙 agent 的工作環境：一個快速模型處理日常任務，一個強力模型處理難題。嘗試一週，記錄效率變化。
06｜資深工程師 vs 初級工程師的分歧
核心觀點： 37 Signals 內部最成功的 AI 加速來自最資深的人——他們能判斷 agent 產出的程式碼是否適合部署給數百萬用戶。Amazon 的內部分析也證實了這個問題：不能讓初級工程師在未經審查的情況下將 agent 生成的程式碼推上生產環境。資深工程師現在有 5-10 倍的產能提升，但初級工程師的角色變得更加不確定。
重要原話：
「大部分的好處都流向了最資深的開發者。」
（原文：「The bulk of the benefits are accruing to the most senior developers.」）
個人感受： 作為一個有經驗的開發者，這既令人興奮又令人不安。興奮的是產能暴增，不安的是整個行業的結構可能正在劇變。
延伸思考： 自動駕駛花了 10 年才從「承諾」到「實際比人類更好」，程式設計的類似躍遷可能也在某個拐點上。
可參考的行動： 如果你是有經驗的開發者，開始建立自己的 agent 工作流；如果你是初級開發者，專注於培養「判斷力」——理解架構、閱讀優秀程式碼、建立品味。
07｜AI 擴展了野心的邊界
核心觀點： AI 不只是讓你更快地做同樣的事，它讓你能做以前根本不會考慮的事。37 Signals 的 Jeremy 用幾天時間做了 P1 優化（將最快的 1% 請求再加速 10 倍），這是以前根本不會被批准的項目。DHH 也讓兩個 AI 模型來回辯論，制定了 Omachi 雙系統啟動的完整計畫。探索一個直覺的成本降低了千倍。
重要原話：
「突然間，探索一個直覺的成本下降了一千倍。」
（原文：「Suddenly the cost of exploring a hunch has just dropped by a thousandfold.」）
個人感受： 這可能是 AI 最深遠的影響——不是取代工作，而是讓我們敢於想像和嘗試以前不敢碰的項目。整個「能做的事」的餅正在爆炸性擴張。
延伸思考： 就像 Commodore 64 上的遊戲，硬體沒變但 20 年後的遊戲比最初的強大得多，因為人們不斷挖掘平台的潛力。即使 AI 模型不再進步，我們也有十年可以挖掘現有能力。
可參考的行動： 列出三個你一直想嘗試但覺得「成本太高」的專案想法，用 agent 花 30 分鐘做一個初步探索，看看結果是否出乎意料。
08｜峰值程式設計師與未來
核心觀點： DHH 認為我們可能已經過了「峰值程式設計師」——那個幾乎任何人只要願意花幾個月學習就能找到高薪工作的時代已經結束了。純粹的「實作能力」正在被 agent 取代，未來最有價值的是產品判斷力、品味、商業理解力和溝通能力。但最好的程式設計師比以往任何時候都更有價值，因為他們能最大化利用 AI 加速。
重要原話：
「如果你只想坐著寫程式，你必須達到 John Carmack 等級的好才能保留這個特權。」
（原文：「If you just want to sit and code, you have to be John Carmack levels of good to retain that privilege.」）
個人感受： 這是一個清醒但並不令人絕望的預測。程式設計的價值正在從「寫程式碼的能力」轉移到「判斷什麼程式碼值得寫的能力」。
延伸思考： 軟體開發作為「成本中心」的公司會最先感受到壓力，而軟體作為「核心產品」的公司反而會因為 AI 而加速發展。
可參考的行動： 審視你目前的技能組合中，有多少是「純實作」能力，有多少是「判斷力和品味」。刻意投入時間培養後者——閱讀優秀設計、理解商業邏輯、練習清晰溝通。
💎 精華收穫
DHH 的對話展現了一個資深技術領袖在 AI 變革中的完整心路歷程：從不喜歡自動補全的「煩人助手」，到將 agent 視為「超級機甲」的熱情擁抱者。他的核心觀點貫穿始終：品味和判斷力比實作能力更重要，美學的追求等同於對正確性的追求，而 AI 不是來取代你的——它是來放大你的。最重要的警告是：不要因為興奮而犧牲睡眠和健康，這不是限時特賣，AI 會一直在這裡，保持可持續的節奏才是長期贏家。