DHH 談 Basecamp 5、Vibe Coding 與 Rails 的未來

來源：YouTube 影片〈DHH: Basecamp 5, Vibe Coding, and the Future of Rails〉
頻道：Ruby on Rails（On Rails podcast，The Rails Foundation 製作）
主持：Robby Russell（Planet Argon）｜來賓：David Heinemeier Hansson（DHH，Rails 之父、37signals 共同擁有者）
發布：2026-06-12｜長度：約 60 分鐘｜連結：https://youtu.be/1JYTtAODjN8

摘要

這集 On Rails 在 37signals 推出 Basecamp 5 的同一週錄製。DHH 談了三條主線：（1）現代 Rails 的穩定性——後端 DSL（ActiveRecord）二十年幾乎沒變，今天寫的 model 檔放在 2013 年的程式碼旁毫無違和，churn（程式碼/技術的變動與汰換率）幾乎都集中在前端 JavaScript 生態；（2）AI／agentic 開發如何改變工作方式——DHH 公開反轉他「親手敲每一個字元」的立場，現在認為認真看待 AI 是「專業義務」，並讓設計師、PM 直接寫 code、用 git reset 廉價地探索更多想法；（3）Rails 的未來——ActionText 將換上基於 Meta Lexical 的新編輯器 Lexxy（podcast 自動字幕誤聽為「Lexi」）、原生 passkeys + magic links 認證，以及「from prompt to IPO」的新標語。貫穿全片的張力是：產出成本暴跌後，架構品味與 human-in-the-loop 的審核反而更關鍵。

一、為什麼 DHH 至今仍對 Rails 興奮

Ruby 這個語言本身：無論親手寫、還是看 agent 寫，Ruby 仍是他見過「最美的程式語言」，看想法在程式碼裡活過來是持續的滿足。
網際網路這個平台：最自由、無守門人的應用發佈平台。Ruby + internet 的組合，二十多年來他仍未厭倦。
站在「另一場運算革命（AI）的前夜」，他覺得跟以往一樣令人滿足。

後端穩定、前端高汰換（high churn）

名詞解釋｜churn：直譯「攪動／翻攪」，在軟體脈絡指程式碼或技術被打掉重寫、被新方案取代的頻率（變動率／汰換率）。高 churn＝一直換、一直重寫，學過的技能與寫過的程式碼「保值期」短；低 churn＝穩定長壽、學一次能用很久。

DHH 強調 Rails 的核心競爭力是後端的長期穩定（低 churn）：

你打開一個 20 年前的 Rails 後端，跟今天的相比，會發現驚人地眼熟。ActiveRecord 的 DSL 從一開始就維持住核心。

投資學習 ActiveRecord 的時間，可以「攤提超過二十年」——這在多數框架／JS 生態裡很罕見（很多生態是一個世代一個 cohort，舊應用就漂走了）。
反觀前端是高 churn：JavaScript 從 2009 起經歷劇烈汰換（jQuery → Webpacker → esbuild → no-build，React 起落），技能與程式碼很快過時要重寫。要幫 Rails 應用「碳定年」，最簡單就是看它的前端建置方式，而不是看 model 檔。

二、Basecamp 5：現代 Rails 讓什麼變可能

Basecamp 是「比 Rails 還早存在」的原始應用（2003 年開始）。Basecamp 5 建在「Basecamp 3 的底盤（chassis）」上——也就是 2013 年起的程式碼，做了 UI 大改版卻不必重寫後端。
37signals 同時維護新舊兩種極端：2003 年的初代 Basecamp 仍有數千付費客戶在用；同時也釋出全新 greenfield 應用 Fizzy（程式碼公開）。DHH 說把 Fizzy 跟 Basecamp 5 的 model 並排看，「其實沒差多少」——證明 Rails 成功橋接了「為既有大型應用維持穩定」與「讓新應用開發仍然愉快」這道鴻溝。
硬體紅利翻轉：開發機現在比雲端伺服器快。DHH 在本地 AMD 395（16 實體核心）跑完整個 Basecamp 5 測試套件約 60 秒，比雲端 20 顆資料中心級核心還快約一倍。這讓 CI／建置等輔助流程的複雜度大幅壓縮。
no-build：JavaScript 原生模組讓前端不再需要痛苦的建置管線（2015–2019 Webpacker 時代是「後端愉快、前端不愉快」）。

三、Rails World（9 月）可期待的兩件事

功能	內容	意義
Lexxy 編輯器進 ActionText	基於 Meta 的 Lexical 框架（驅動 Facebook、WhatsApp 的底層）打造，取代自家舊編輯器 Trix，但相容並可遷移（podcast 自動字幕誤聽為「Lexi」，正確名稱是 Lexxy）	補上 Trix 長年缺的表格與 Markdown 支援；富文字輸入是現代 web app 的 table stakes
原生 Passkeys + Magic Links	已有 open PR，把 passkey 的「JavaScript 微妙之舞」包成簡單 API，端到端整進 Rails	把認證的門檻「降到地板」，讓人不必再把登入外包給 SaaS

DHH 對 passkeys 改變了看法：原本擔心「iPhone 設了 passkey、換到 Windows PC 就登不進」的可用性問題；突破點是 passkey 配 magic link（隨時能用 email 登入）。他認為對多數應用，認證的「正確形狀」就是 magic links + passkeys，能擺脫社群登入更好。

四、Agentic 開發：DHH 的立場反轉

不急著把 agent「灌進框架混凝土」

MCP 曾被視為一切答案，後來「冰球滑向 CLI」，現在又談兩者並用。DHH 主張在最終形狀明朗前，不要急著替某種做法澆灌框架地基。
反例：若當初把預設 agents.md 內建進 Rails——隔了三個模型世代後，那檔案不只過時，還會「真的有害」。研究顯示：硬要叫 agent 用某種它本來就會的方式做事，反而把它變笨、用雜訊塞爆 context window、產出更糟的程式碼。

「親手敲每個字元」立場的反轉

DHH 一年前還在播客上說「我愛親手寫每一行，想為每個字元流汗」。現在他區分兩件事：

我仍想為每個字元的美學呈現流汗；但我反轉了「是否需要親手鑿出這段程式碼」。如果 agent 能產出和我親手寫一樣品質的程式碼，遊戲顯然已經變了。

他稱認真看待這場革命是每個程式設計師的「專業義務」——投入時間追上、在它驚豔你時興奮、別卡在「它只是鸚鵡、只是複讀」這類意識形態死胡同。他提到自己終於「吞下了 Tobi pill」（Shopify 的 Tobi 比他更早看見未來並在公司內強制要求重視 AI）。

Code as art：git reset 的廉價探索

DHH 把看實作比作看藝術品：要看過很多版本，才認得出「這個形狀我不喜歡」。
agent 加速讓探索變極廉價：「我不喜歡你做的——砰，git reset，沒了，而且我一點都不心疼把 1,000 行沖進馬桶。」
實作成本下降，讓人更敢跟著直覺與創意走，而不被沉重的實作成本嚇退。

五、組織與流程的改變

設計師／PM 直接寫 code

Basecamp 5 的一大工作流改變：設計師和 PM 現在能不經程式設計師中介，直接把想法變成可運作的軟體、驗證自己的直覺。

但真正 vibe-coded（沒被理解、甚至沒被細讀的程式碼）在多數情況下不會被 merge。

價值在於：「這該怎麼運作？這樣做好不好玩、對不對？」這些軟體裡最難的問題能更早被回答，不必先浪費工程師數週、數月。DHH 以自身經驗對照——早年花一兩週實作、很自豪，結果 Jason 一句「這行不通，要用另一種方式」就得砍掉，而人對自己投入心血的程式碼會「捨不得」。

Shape Up 的六週週期「顯得過時」

Shape Up 的六週 cycle，是因為當年 Basecamp 蓋一個大功能就是這個時間尺度。如今 DHH「很難想像還有什麼功能需要六週」——實作被大幅壓縮。但他警告：仍要顧品質，因為你也能在很短時間內毀掉精心構築的架構。

Agent 的弱點：不會「先讓改動變簡單」

引用 Kent Beck 的名言「make the change easy, then make the easy change」：

agent 樂於用最少 token、最快取悅你，可能寫 1,200 行去做一件「靠架構巧勁 Rails 只需 20 行」的事——傾向「bolt-on（硬接上去）」而非調整架構。

DHH 澄清：這其實是「不顧架構與風格的軟體開發」的老問題（人類也常把 codebase 變成一團爛泥），不是 agent 獨有。好 codebase 的長壽關鍵在於可塑、可扭轉的架構。

六、規模化的副作用：更多 PR、更多不穩定

野心水位上升：生產力暴增後，會去做以前「不值得做」的專案。例：團隊的 Jeremy 去優化「最快的 1% 請求」（把 floor 從幾毫秒降到 sub-1ms）——單筆無感，但乘上數百萬筆就影響基礎設施成本。
自駕車類比：agent 仍會「撞車」，但頻率遠低於人類。問題是數量——從一週 5 個 PR 變 50 個，就算出包率減半，系統承受的不穩定總量仍上升。「某些系統在導入 AI 後變得更不可靠」，不是因為 AI 是更差的程式設計師，而是因為它太快、能做的事太多、出事機會也更多。
可靠度要看階段：37signals 很在意 uptime（Basecamp 4 近三月 100% 無停機）；但 DHH 認為多數新創不該追求 100%——該優先更快達到 product-market fit。

DHH 也坦言自己的經驗有偏誤：37signals 的 codebase 都已有既定模式（established patterns），agent 在其上能做好工作；「把 agent 丟進一個爛泥 codebase 會如何，我其實沒什麼經驗、不知道」。但他確定：在有架構的 codebase 上，agent 能做很好的工作——前提是仍需合格人類在 loop 裡審核。

七、Rails 作為「第一個 app」的家：from prompt to IPO

DHH 把 Rails 標語從「from hello world to IPO」改為「from prompt to IPO」。
他看到一整類應用（過去由 Microsoft Access、FileMaker Pro、Excel 服務的非程式設計師需求）可以被 vibe coding 接手——「指揮開發的人從不看程式碼」。
臨界性光譜（criticality spectrum）：他不會 vibe code 下一個銀行 app，但有一大類應用的臨界性低到「無所謂」。半年前大家擔心 agent「把密碼設成 admin、洩漏 API key」，現在少聽到了——模型變聰明，而且從 AI 進化到 agent（有工具、能跑測試與 linter），所以連幻覺也很少進到 PR。
Rails 的歷史優勢就是壓平學習曲線、內建安全防護，讓新手（生物學家、音樂家轉行）不會犯最蠢的錯——這和 agent 的 on-ramp 高度相似。DHH 要 Rails 保持「平」，而不是「先爬 200 公尺高牆才准進伊甸園」的高姿態。
他歡迎 agent 為 Rails 本身貢獻功能（仍需核心／committer 團隊審核），稱這是「我接觸電腦 40 年來最令人興奮的事」。

八、收尾：少擔心末日，回到對電腦的熱愛

Rails 開發者該少花時間擔心什麼？世界末日、氣候歇斯底里、AI 會殺光我們——這些要發生與否，不會因你擔心而改變，你沒有左右它的力量。把目光聚焦在進步、未來、所有該讓你興奮的事；聚焦在你對電腦的熱愛、Ruby 的美、Rails 的生產力。我們活在 500 個維度上最好的時代。

重點速覽

flowchart TD
    A["Basecamp 5 上線\n（建在 2013 Basecamp 3 底盤）"] --> B["後端穩定\nActiveRecord DSL 20 年不變"]
    A --> C["前端革新\nno-build / Lexxy 編輯器 / passkeys"]
    D["AI / Agentic 開發"] --> E["DHH 立場反轉\n親手敲字 → 專業義務擁抱 AI"]
    D --> F["流程壓縮\nShape Up 六週週期過時"]
    D --> G["風險\n更多 PR = 更多不穩定\n需架構品味 + 人類審核"]
    E --> H["from prompt to IPO\nvibe coding 服務低臨界性應用"]
    F --> H
    G --> H

三個記憶點

穩定是資產：Rails 後端 20 年穩定（低 churn），讓學習投資能攤提數十年；churn（變動／汰換）集中在前端。
立場反轉：DHH 從「親手寫每個字元」轉為「認真用 AI 是專業義務」，但堅持美學與架構品味、堅持 human-in-the-loop 審核。
臨界性決定做法：低臨界應用可放手 vibe code（from prompt to IPO）；高臨界系統仍需合格人類把關。

來源連結

影片：https://youtu.be/1JYTtAODjN8
On Rails podcast（The Rails Foundation）
Fizzy（37signals 公開 greenfield 應用程式碼）

分類：tech｜標籤：rails, dhh, basecamp, vibe-coding, ai-agent, ruby, shape-up