DHH 的 agent 時代宣言：手寫程式碼的終結，與為什麼該選擇樂觀
文字解析 · 1 支影片 · 產生於 2026-10-01 00:54
章節（24）
1. Outline
- 起點 · Rails World 2026 Opening Keynote - DHH
從攝影史的類比出發，一路推到「手寫程式碼在經濟上已經結束」，再收在為什麼理性的選擇是樂觀。
2. YouTuber 的思維推導
Rails World 2026 Opening Keynote - DHH
Ruby on Rails · 1h03m · 字幕 en · vision=on （投影片型 keynote：作者反覆指著畫面說『這是 18 世紀的尖端技術』『Exhibit A』『這是第一個 prompt 吐回來的、這是二十分鐘後的』『看這個數字』，畫作、程式碼、before/after 與量化圖表都必須看圖才讀得懂推論。） · YouTube
預估 vs 實際耗時
| 階段 | 預估 | 實際 |
|---|---|---|
| fetch | 6s | 3s |
| segment | 2m36s | – |
| shot | 1m21s | 1s |
| analyze | 18m45s | 12m16s |
| render | 5s | – |
DHH 的出發點是一個他自己也承認很怪的狀態：對 agent 極度亢奮，同時對未來極度不安。他不打算用技術辯論解決這份不安，而是換一條路——把它放進一段更長的技術史裡。他先用肖像畫舉證：18 世紀畫一幅肖像要坐數小時、畫數月，1886 年 Tuxen 甚至畫了三年，那是工藝的巔峰；但 1900 年柯達 Brownie 一美元就能拍照，寫實描繪不再是經濟上站得住腳的技能，畫家集體轉向立體派與印象派，技術變遷帶來的不是滅絕而是創造力爆發。
接著他用自家照片證明第二件事：技術是斷續前進的，Brownie 之後八十年幾乎沒動，直到手機才第二次躍進到一年兩兆張。有了這兩個結論，他才丟出核心主張：2025 年 11 月 24 日的 Opus 4.5 是我們這一代的 Brownie，而這次的失望之谷只有四個月不是一百年。從這裡他開始把歷史類比換算成職業現實——1968 年的 10x programmer 爭論已經不重要，現在的級距是 100x 甚至 1000x；他自己二十個月寫掉前二十一年一半的程式碼；37signals 宣布手寫程式碼收工；HEY 改成六個原生前端加 Rust 後端，後端 CPU 少 99%。
接著他把同一個邏輯推到每一層：Ruby 與 Rails 靠 convention over configuration 換來 token 效率而仍然有位置；抽象化因為重複成本歸零而必須重估；每個 app 都該給 agent 一個 CLI；連整台電腦（Omarchy）與應用體積（半 MB 的 Hype）都在可修的範圍內。最後他回到開場那份不安，用預測失敗史（ATM、Oppenheimer）論證『沒有人預測得準』，因此理性的選擇不是恐懼而是 P(bloom)：既然算不出結果，先難過是白費時間，全力樂觀是唯一的解。整場的形狀就是：先用歷史解除不安 → 用數據證明躍進已經發生 → 逐層重估工程實務 → 再用同一套歷史邏輯把結論收回到態度上。
推理鏈：每段留給下一段的線索
每一列是一段，箭頭後的字是這段留給下一段的線索。點段落標題跳到該段。
- AI euphoria：先替自己下診斷 → 他留下一個沒有回答的問題：既然興奮與不安是綁在一起的，要怎麼安撫那份不安？他自己給的方向是「把時鐘往回撥」——用歷史，而不是用技術規格。
- 18 世紀的肖像畫是尖端科技 → 他把舊技術的成本與稀缺性立好了，但還沒說它是怎麼結束的。下一步需要一個「工藝達到巔峰、同時死期已到」的具體例子。
- 三年一幅畫，然後 Brownie 出現 → 媒介換了，那些大師怎麼辦？這段只講了舊技藝的終點，還沒講從業者的去向——而去向正是他真正想讓台下聽見的部分。
- 畫家轉行：寫實不再值錢，創造力反而爆發 → 類比的第一半完成了（舊技藝會被媒介取代，從業者會轉向）。但還缺一個關鍵性質：這種取代是一次到位的嗎？如果不是，我們現在處在哪一段？
- 技術是斷續前進的：Brownie 之後八十年沒動 → 他已經備好完整的歷史模板：民主化 → 長期停滯 → 第二次躍進。下一步就是把這個模板蓋到 AI 上，而模板第一格需要一個明確的日期。
- 2025/11/24：我們這代的 Brownie → 模板的第二格是「長期停滯」。攝影停了八十年——AI 這次停了多久？他必須面對那段所有人都感覺到的退步期。
- 失望之谷只撐了四個月 → 歷史類比到此用完了。他說「這對我們這個職業意味著什麼」，接下來必須把躍進換算成職業內部聽得懂的單位——而業界現成的單位只有一個。
- 從 10x 到 1000x：換算成職業的單位 → 倍率是別人的統計，他還欠一個自己的數字。下一步他必須拿出可檢驗的個人紀錄，否則 1000x 只是口號。
- 20 個月寫掉前 21 年一半的程式碼 → 數字證明了「產出變多」，但他真正想傳達的興奮不在產出，而在「沒做的事」。他需要一段情感上的錨點來解釋那份興奮的來源。
- 「看看我沒在做的事」：這是 Rails 時刻 → 他已經把個人體驗講到極致。接下來必須把它變成組織決策——一個公司真的敢據此改變工作方式嗎？
- 37signals 宣布手寫程式碼收工 → 宣布得這麼乾脆，但他們並不是第一次嘗試。他必須解釋上一次為什麼失敗，否則這個決定聽起來像沒學到教訓。
- Basecamp 5 的失敗，與那個「錯誤的結論」 → 「榨出最多」被立為唯一的問題，那就得有人示範怎麼榨。下一步需要一個正在進行中、規模夠大的實作案例。
- HEY 不再是 web app：六個原生應用同時開工 → 前端有了答案，但一個郵件服務的重量在後端。而他接下來要給的後端答案，會讓他自己難受。
- 後端換成 Rust：永遠不必看，我就愛它 → 他把「做什麼」和「怎麼做」分給了不同的智慧。但分工要成立，得先知道怎麼把工作交出去——而這一點他自己也還沒摸清楚。
- 非同步指派，不是坐在聊天室裡等 → HEY 的答案是原生前端加 Rust 後端，而且工作方式還在摸索。那麼對一屋子的 Rails 開發者來說，最迫切的問題還沒被回答：Ruby 和 Rails 還剩什麼位置？
- Ruby 與 Rails 剩下什麼位置：web、token 效率與新手心態 → 他替 Rails 留了位置，但同一段裡也承認自己今年幾乎不寫 Ruby 了。那個比例到底變成什麼樣子，需要攤開來看。
- 15 萬行，與一個叫英文的程式語言 → 他說二十年前就可以只要結果，是因為他即將宣布一件比 3% 更重的事——不是工具變了，是職業變了。
- 從手寫程式碼退休，帶著喜悅而不是後悔 → 職業被重新定義之後，剩下的是工程實務本身。他說有一大堆東西要重想——第一個要被重估的，是軟體工程最核心的那個工具。
- 抽象化在 agent 時代要重新估值 → 架構層的重估沒有藍圖，但他承諾要給一點具體的東西。接下來是全場唯一一條可以照做的指令。
- 自備 agent：每個 app 都該有 CLI → 「我們現在什麼都能修」這句話他剛用在別人的應用上。下一步他要證明這個範圍有多大——大到整台電腦。
- Omarchy：把整台電腦都修好 → 整台電腦可以修，那單一個應用呢？他接下來要示範的是這場演講裡規模最小、但衝擊最直接的一類東西。
- 一次成形的應用，與半個 MB → 他已經把樂觀的一面說滿了。要收尾，他必須回到開場那句「這也有點令人不安」，正面處理別人的擔憂。
- 擔憂、安全，與預測為什麼總是錯 → 他證明了「沒有人預測得準」，但還沒說在不可知之下該怎麼辦。最後一步要把這個空白變成一個選擇。
- P(bloom) 勝過 P(doom)：把不可知變成一個選擇
3. 逐段說明
Rails World 2026 Opening Keynote - DHH
1. AI euphoria：先替自己下診斷 0:00–1:50
DHH 開場就承認自己對 agent 的興奮看起來像「AI psychosis」，但他寧願叫 AI delirium / AI euphoria：這是他接觸電腦以來，電腦做過最令人興奮的事。同時他也點出這份興奮伴隨不安——沒人知道最終狀態是什麼，任何預測二十分鐘後就過期。他把「既興奮又不安」設為整場演講要處理的矛盾。
推理因為他知道台下看到一個人為 agent 手舞足蹈時的第一反應是「AI psychosis」，所以作者接著主動把這個標籤拿過來改寫成 AI delirium / AI euphoria——承認亢奮為真，但重新定義它的性質。定義完之後他立刻做第二件事：把亢奮的背面也攤開，說這件事同時令人不安，因為沒人知道最終狀態，任何預測二十分鐘後就過期。一場演講的開頭同時放進「極度興奮」與「有點不安」，等於宣告本場要處理的不是技術問題而是這個矛盾。
AI 補充值得注意的是他選的修辭順序：先自嘲、再改名、最後承認不安。這不是鋪陳，而是設定舉證責任——如果他只講興奮，任何一個持保留態度的聽眾都可以用「你在狂熱」打發掉整場；先自己說出「這確實有點不安」，後面的論證才不是推銷。另外他把「預測二十分鐘後就過期」放在第一分鐘，其實是先埋下整場最後要用的那把刀：既然預測不可靠，恐懼也同樣建立在不可靠的預測上。
2. 18 世紀的肖像畫是尖端科技 1:50–4:17
為了安撫那份不安，他把時鐘往回撥。18 世紀要留下自己的肖像，得坐在大師面前好幾個小時，畫家再花好幾個月完成——Joshua Reynolds 1781 年的 Lady Waldegrave 就是這樣來的。他強調兩件事：美，但極度昂貴且稀有，只有上層資產階級與皇室付得起；而且客戶會退件（露出腳踝太有傷風化），Reynolds 得整幅重畫。
推理因為上一段把不安定義成「不知道最終狀態」，所以作者接著要示範一種已經走完全程、結局已知的技術變遷。他挑肖像畫，並且先花力氣把舊技術講得夠好：Joshua Reynolds 1781 年的 Ladies Waldegrave，坐數小時、畫數月，美得至今仍是文化遺產。講完美，他馬上補兩個限制條件——極度昂貴稀有，只有上層資產階級與皇室負擔得起；而且客戶會退件，露出腳踝太有傷風化，Reynolds 得整幅重畫。這兩個限制不是插曲，而是他要建立的前提：這門技藝的價值一半來自稀缺與辛苦，不只來自成果本身。
AI 補充退件那個笑點在論證上有實際功能。它把 18 世紀畫家和台下的軟體工程師放進同一個位置：都是接受委託、被客戶的主觀判斷否定、然後重做整份工作的人。一旦聽眾認同「我就是那個 Reynolds」，後面「攝影出現了」的那一擊才會打在自己身上而不是別人身上。另外他說「畫家花了數百年精進技法，但進展非常邊際」——這句是整段真正的重點：一個領域內部的漸進優化，擋不住來自領域外的媒介替換。
術語:state of the artcommission
3. 三年一幅畫，然後 Brownie 出現 4:17–5:48
1886 年丹麥畫家 Laurits Tuxen 畫皇室全家，不是花三個月，是花三年，至今掛在哥本哈根。但這已是那種工藝的尾聲：1840 年相機問世，1900 年柯達推出 Brownie，一美元就能拍照，攝影第一次大量普及。技術的競爭對手不是更好的畫家，是另一種媒介。
推理因為上一段已經讓聽眾接受「數月＝昂貴」，所以作者接著把數字加碼到三年，讓工藝的巔峰值被拉到最高——而且這幅畫至今掛在哥本哈根，可以親眼去看，證據是硬的。緊接著他在同一段裡把死期放進來：1840 年前後相機問世，1840 到 1900 之間拍攝技術一路變好，1900 年柯達推出 Brownie，一美元就能拍照。他刻意讓巔峰與終結貼在一起，結論才成立——摧毀一門技藝的不是更厲害的同行，是另一種媒介。
AI 補充這裡有一個容易被漏掉的時間結構：相機在 1840 年就存在了，但畫家的工作是在 1900 年才真正崩塌的。中間隔了六十年。也就是說「技術出現」跟「技術便宜到人人可用」是兩件事，真正改變職業結構的是後者。Brownie 的關鍵參數不是畫質，是一美元。這個「可用性門檻比能力門檻更致命」的形狀，是他整場演講挑日期、挑價格、挑安裝時間的底層邏輯。畫面上投影的正是 Tuxen 1886 年那幅《King Christian IX》，幾十個人物、金碧輝煌的室內，一眼就能理解三年是花在哪裡。
術語:Kodak Browniedemocratization of technology
4. 畫家轉行：寫實不再值錢，創造力反而爆發 5:48–7:26
Brownie 之後，那些大師意識到「盡可能完美地描繪現實」不再是經濟上站得住腳的技能。他們需要另一種技能、另一個領域，於是集體轉向——畢卡索走向立體派，丹麥的 Skagen 畫家走向印象派。技術變遷沒有消滅藝術，反而逼出一次創造力大爆發。Tuxen 是 DHH 的曾曾祖父。
推理因為上一段已經讓「舊技藝結束」成為既成事實，所以作者接著把重點從損失轉到轉向：畢卡索走向立體派，丹麥的 Skagen 畫家走向印象派，而這些新流派正是因為舊路被堵死才被逼出來的。他用一句話把整個類比的結論說死——技術變遷帶來的是一次創造力大爆發。最後他補上血緣：畫中穿粉紅洋裝的 Yvonne Tuxen 是他的曾祖母，Laurits Tuxen 是他的曾曾祖父。這不是炫耀，是把抽象的歷史換算成「我家就發生過這件事」，讓類比帶有個人代價。
AI 補充這一段其實藏著他對台下最核心的安撫，但他沒有講白，值得補上：畫家們保住的不是「畫得像」這個技能，而是「觀看與構圖的判斷力」。攝影拿走的是寫實的執行，留下的是決定畫什麼、怎麼看的那一層。對應到軟體，他暗示被拿走的是語法與實作，留下的是決定做什麼、怎麼拆問題的判斷——這正是後面「英文是更好的程式語言」和「不要把需求寫得太細」的伏筆。另外要誠實指出一個他跳過的差異：印象派轉型花了一整個世代，而他接下來要主張的時間尺度是幾個月，這中間的落差他並沒有論證。投影上那幅 Skagen 風格的雙人像，筆觸鬆、光線柔，跟前一張皇室全家福的精雕細琢放在一起，轉型的樣子不必解釋就看得出來。
術語:Skagen Painters
5. 技術是斷續前進的：Brownie 之後八十年沒動 7:26–11:20
他用自家的照片把時間軸拉長：1921 年 Tuxen 的肖像、1979 年自己出生時的照片，兩張技術幾乎一樣——1925 年的 Leica 1 和 1980 年代拍他的相機差不多。Brownie 之後約 80 年沒發生大事，他整個童年只有大約十張照片。真正的第二次躍進要等到手機：拍照變成零摩擦，2026 年一年拍 2 兆張。同一個底層技術，但明顯跨過了一個臨界點。
推理因為要證明「斷續」，作者接著把同一條血緣的影像拉成時間軸：1921 年 Tuxen 本人被新技術拍下的肖像，1979 年他自己出生時的照片，兩張的技術幾乎一樣；1925 年的 Leica 1 跟 1980 年代拍他的相機差不多。他用一個很個人的數字把稀缺量化——他整個童年大約只有十張照片。接著才放第二次躍進：手機讓拍照變成完全零摩擦，2026 年一年拍兩兆張，他太太散步時隨手拍的那些照片，在八〇年代需要對底片和沖洗做出承諾才拍得出來。同一個底層技術，但明顯跨過了一個臨界點。
AI 補充這一段真正在建立的是一把尺，用來回答「我們現在在哪」。他給的判準不是畫質也不是功能，而是摩擦：一項技術跨過臨界點的徵兆，是使用它不再需要事前承諾。底片時代你得先決定「這值得一張」，手機時代你不必決定。把這把尺套回軟體，「要不要為這個小功能開一張票、排一個 sprint」就是舊世界的摩擦，而他後面說的「每個夢想、每個煩人的小刺都修掉了」正是摩擦歸零的症狀。順帶一提，他說「六〇年代有了彩色照片」是簡化——彩色底片 1930 年代就有了，只是到六〇、七〇年代才進入一般家庭，這剛好又是一次「能力早就存在、便宜才算數」。
術語:inflection point
6. 2025/11/24：我們這代的 Brownie 11:20–12:43
他把 Opus 4.5 發表日 2025 年 11 月 24 日定為我們這一代的 Brownie：智慧被裝進一個許多人負擔得起的 harness 裡，第一次有大量的人體驗到「與另一種智慧結對寫軟體」。對他而言世界分成 11/24 之前與之後。跟 Brownie 一樣，接著就是各種形式的爆發，幾個月內連 open-weight 版本都有了。
推理因為 Brownie 的判準是「智慧被裝進一個許多人負擔得起的容器裡」而不是「能力最強」，所以作者接著用同一句話定義這個日期：AI technology made accessible in a harness that many people could afford to use，第一次有大量的人體驗到與另一種智慧結對寫軟體是什麼感覺。他接著宣告世界分成 11/24 之前與之後，並預言歷史書會把它標成 age of agents 的拐點。收尾也照模板走：Brownie 之後是各種形式的爆發，這次幾個月內連 open-weight 版本都出來了。
- C分水嶺不是模型最聰明，是外殼讓智慧便宜到很多人用得起→ 畫地圖
- A2025/11/24 那一天 ↔ 1900 年的 Kodak Brownie→ 批判類比
- Ropen-weight 是權重可下載自行運行，跟開源不是同一件事→ 存＋回想
AI 補充要注意他挑的判準讓這個日期變得可辯論但不荒謬：他沒有說 Opus 4.5 是最聰明的模型，他說的是「harness 讓它可被負擔」。也就是說被他當成分水嶺的不是模型權重，而是模型＋工具＋介面這一整套外殼。這也解釋了他為什麼對 open-weight 版本那麼興奮——模板裡的第三格（價格崩到人人可用）需要的是供給端多元化而不是分數更高。投影片上就只有一行「Introducing Claude Opus 4.5 / Nov 24, 2025」，簡單到刻意：他要的是那個日期本身變成論點。
7. 失望之谷只撐了四個月 12:43–16:02
二月到五月出現一段 trough of disillusionment：新模型一個個出來卻像在退步，市場一度覺得「結束了，指數成長不存在」。但這次的谷底不像攝影那樣撐一百年，只撐到六月 Fable 5 與 Mythos 出來。那一代模型讓他從「叫 agent 做事」變成「給它問題或想法，然後看到成果值得直接 merge」。接著 GPT-6 Astra 與 DeepSeek-4-1 Flash 分別打破了單一公司與單一國家壟斷前沿智慧的擔憂。
推理因為如果跳過這段低谷，整個歷史類比就會變成選擇性舉證，所以作者接著把當時的氣氛完整重播：大家嫌新版本不如舊版、某次 OpenAI 的發表在 benchmark 上沒明顯進步、市場估值應聲下跌、輿論說「你看吧，指數成長根本不存在」。鋪完這一層，他才給出關鍵對比——攝影的谷底撐了一百年，這次只撐到六月 Fable 5 與 Mythos 出來。接著他用自己的體感定義那一代模型的差別：從「叫 agent 做事」變成「給它問題或想法，然後看到成果值得直接 merge」。最後兩個補充（GPT-6 Astra 打破單一公司壟斷、DeepSeek-4-1 Flash 打破單一國家壟斷）則是把模板第三格的供給多元化補齊。
AI 補充他實際上偷偷換掉了 Gartner 那條曲線的意義，值得講清楚。原本的 trough of disillusionment 是描述「期待過高後的必然修正」，重點在期待；他把它改成描述「能力曲線的短暫平台期」，重點在能力。這個換義讓「谷底只有四個月」聽起來像技術事實，但實際上市場估值下跌測量的是預期，不是能力。另一個值得指出的跳步是：他從「幾個月的觀察」推論「停滯期已經結構性地變短」，但攝影那八十年的停滯是因為底層物理與供應鏈沒動，而模型的停滯原因完全不同——用同一條曲線描述兩者，形狀像，機制不一樣。至於他說的分水嶺體感「從指派任務變成指派結果」倒是很實在的判準，而且是可以自己驗證的：你交出去的東西如果還要逐行檢查，那就還沒跨過去。
8. 從 10x 到 1000x：換算成職業的單位 16:02–18:13
他回到 1968 年 ACM 那篇論文：同一批程式設計師之間最差與最好相差 5x 到 30x，平均 10x，然後業界為此爭論了 45 年。他認為那場爭論已經結束，而重點是我們直接跳過共識，開始問「如果純人力是 10x，現在會是多少」。他的主張：說「不用這些工具的最差者」與「用這些工具的最佳者」差 100 倍並不算有爭議，甚至 1000 倍聽起來也差不多對。
推理因為需要一把所有人都認得的尺，所以作者接著回到 1968 年 ACM 那篇論文：同一批程式設計師之間，最差與最好的差距從 5x 到 30x，平均 10x，然後業界為此爭論了四十五年。他問「還有人在吵嗎」，自答沒有，宣布爭論結束——但真正的重點在下一句：我們直接跳過共識，開始問「如果純人力是 10x，現在會是多少」。他的主張分兩層：說「不用這些工具的最差者」與「用這些工具的最佳者」差 100 倍並不算有爭議；再往前一步，1000 倍聽起來也差不多對。
AI 補充這裡必須指出一個他沒說破的偷換：原本的 10x 是同一群人在同一種工作方式下的個體差異，而他的 100x／1000x 是「不用工具的最差者」對「用工具的最佳者」——兩端同時換了人和工具。這樣定義的倍率當然會很大，但它不能拿來推論「你用了工具就會快一百倍」。真正有意義的問法是同一個人用與不用的差距，而那個數字目前沒有可靠的公開量測；少數有對照組的研究甚至出現過資深開發者自覺變快、實測變慢的結果。他這段論證的價值不在倍率本身，而在方向：當可能的級距大到這個程度，公司之間的競爭條件與「起步需要多少人」都會被重寫——那才是他接著要處理的。畫面在這段停在講台上，沒有投出 1968 年那張表格，所以數字只能靠他口述。
術語:10x programmervariance
「an article in ACM Magazine from 1968, where they tested a group of programmers on a variety of different tasks」
9. 20 個月寫掉前 21 年一半的程式碼 18:13–19:20
他給出自己的數字：過去 20 個月寫的程式碼量，是前面 21 年總量的一半。他自己先承認行數是模糊的度量，而且一行 Ruby 的價值遠高於一行 Rust 或 C++——低階語言沒有 Ruby 的抽象與便利。但即使打折，量級的改變無法否認。
推理因為主張越大越需要自己的證據，所以作者接著把個人 git 紀錄攤開，而且先替自己做反方辯論：行數是模糊又可塑的度量，一行 Ruby 的價值遠高於一行 Rust 或 C++，因為低階語言沒有 Ruby 的抽象與便利。先承認度量的弱點，再說即使打折，量級的改變依然無法否認——這是他一貫的舉證策略：不宣稱精確，只宣稱級距。
AI 補充投影片上的數字比口述精確得多，值得補上：2004–2024 的二十一年是 647K 行、26,325 次 commit，其中 Ruby 佔 355K（55%）；2025–2026 的二十個月是 321K 行、7,176 次 commit，Ruby 只剩 10K（3%）。另外兩個欄位其實更有訊息量——年均從 31K 行跳到 2026 年一年 292K，日常使用的語言從 4 種變成 12 種，接觸的 repo 數也大幅增加。也就是說「寫更多」只是表象，真正變的是「涉足的範圍」：以前他守在一個 Ruby 技術棧裡，現在同時碰十二種語言。這一點比行數更能支撐他後面的所有主張，因為跨語言的成本歸零，正是「後端換 Rust」「自己寫作業系統」之所以可能的前提。
術語:lines of code
10. 「看看我沒在做的事」：這是 Rails 時刻 19:20–20:45
他播了一段 21 年前自己在巴西的演講片段，當時他興奮的正是「看看我沒在寫的設定檔、沒在做的事」。他說這就是 Rails 時刻的本質，而現在是同一種興奮的放大版：已經大約五個月沒寫程式碼，卻把每個夢想、每個煩人的小刺、每個看似無關緊要的功能都修掉了。
推理因為要證明這份興奮不是新來的流行病，所以作者接著把兩個時刻疊在一起：影片裡的他在展示 blog 自動對應到 blogging controller、index 自動對應到 index template，一邊喊 look at all the things I'm not doing；台上的他則說，還有比「我們不再需要做的所有事」更好的方式來概括這個時刻嗎。他把 Rails 的本質定義成「省掉的東西」而不是「提供的東西」，然後宣布現在是同一種興奮的放大版——大約五個月沒寫程式碼，卻把每個夢想、每個煩人的小刺、每個看似無關緊要的功能都修掉了。
AI 補充這個並置在修辭上很強，但也要看清楚它的極限。Rails 省掉的是「可以被慣例吸收的決策」——路由對應、檔名對應這些本來就有唯一合理答案的東西，省掉它們沒有代價，因為慣例是確定性的。agent 省掉的則是實作本身，而實作有無限多種解法，agent 挑的那一種未必是你要的。兩者都叫「省掉」，但前者的正確性由框架保證，後者的正確性得另外驗證。這個差別就是他下一段會踩到的坑。另外他提到「每個煩人的小刺、每個看似無關緊要的功能」終於修得掉——這正好對應到前面那把摩擦的尺：當實作成本趨近零，「這值不值得做」這道關卡消失了。
術語:convention over configuration
11. 37signals 宣布手寫程式碼收工 20:45–22:12
幾週前 37signals 做了決定：手寫程式碼結束了（pencils down）。手寫變成例外狀態，像在 Sentry 看到一個 bug——代表「為什麼 agent 做不出我們要的東西」，短期還是會拿鉛筆補一下，但接著要修的是那台機器、那座工廠。他強調這只是承認既成事實，並當場舉手表決：全場只有約五個人每週還手寫大量程式碼。
推理因為個人體驗說服不了組織，所以作者接著給出一個可執行的定義，而不只是口號：pencils down 之後，手寫程式碼變成例外狀態，像在 Sentry 裡看到一個 bug——它的意義是「有東西壞了」，代表要追問為什麼 agent 做不出我們要的東西。短期還是會拿鉛筆補一下，但接著要修的是那台機器、那座工廠。最後他把這個決定降格成「只是承認既成事實」，並當場舉手表決驗證：全場只有約五個人每週還手寫大量程式碼。
AI 補充「把手寫當成 Sentry 上的 bug」這個框架是整段最有用的東西，值得展開：它把個別的救火動作重新定義成流程缺陷的訊號。如果你今天為了趕進度自己動手改了，那不是勝利，而是一筆要記下來的債——債主是那套 prompt、那份規格、那個 agent 的工作環境。這跟製造業的「停線拉繩」與 SRE 的「事後檢討而非責備」是同一種思路：不允許用個人英雄主義掩蓋系統缺陷。至於那個舉手表決，要提醒它的取樣偏誤：Rails World 開場 keynote 的現場觀眾，本來就是最願意接受這套敘事的人，這個數字拿來當全行業的證據是站不住的，拿來當「這個房間的共識」倒是有效。
12. Basecamp 5 的失敗，與那個「錯誤的結論」 22:12–24:04
春天做 Basecamp 5 收尾時他們試過一次：讓設計師 vibe code 最後幾個功能。個別 PR 看起來都合理，但 20、30 個疊起來，架構像被打成瑞士乳酪。當時的結論是「技術還沒到，回去人工審查」——他說這個結論錯了。不只因為再等五分鐘 Fable 就出來了，更因為現在只剩一個嚴肅問題：怎麼從這場智慧爆發裡榨出最多東西；其他問題都在它下面。
推理因為誠實交代失敗才能讓這次的決定站得住，所以作者接著把失敗的形狀描述得很精確：個別 PR 看起來都合理，但 20、30 個疊起來之後，架構像被打成瑞士乳酪。當時的結論是「技術還沒到，回去人工審查」——而他現在說這個結論是錯的。錯的理由有兩層：表層是時機（再等五分鐘 Fable 就出來了，同一批 PR 大概就會照原意運作）；深層是優先順序（現在只剩一個嚴肅問題：怎麼從這場 intelligence explosion 裡榨出最多東西，其他問題都排在它下面）。
AI 補充瑞士乳酪這個症狀值得單獨記住，因為它是局部最佳化的典型後果：每個 PR 在自己的範圍內都合理，但沒有任何一個 PR 負責維持整體結構，於是一致性被一刀一刀削掉。這在人類團隊裡是靠 code review 與架構師的品味擋住的，而他們當時的做法是把這道防線交給了不具備全域視野的個別貢獻者。要注意的是，他給的解方是「等更強的模型」，但問題的結構（沒有人負責全域一致性）並不會因為模型變強就自動消失——除非把全域一致性本身也變成一個被明確指派的任務。至於「只剩一個嚴肅問題」這句，實際上是一個排序宣告而不是事實描述：他在主張把「榨出最多智慧」擺到所有工程價值（可維護性、正確性、成本）之上，這是全場最激進、也最需要各自判斷的一句話。
術語:vibe codingpull request
13. HEY 不再是 web app：六個原生應用同時開工 24:04–28:14
新版 HEY 要做的第一件事是不再當 web app。他說 HEY 本來就不想當 web app，它是 web app 只因為那是小團隊唯一能有生產力的做法——小團隊維護六個原生框架的應用在過去是荒謬的，React Native、Hotwire Native 都是為了繞過這件事，代價是犧牲一點擬真度。他們一週前啟動的六個原生應用已經在跑；Windows 版第一個 prompt 的產出不堪用，二十分鐘後修正版就可以看了。Shopify 用大約六個人重寫 Shop app 原生版也是同一件事。
推理因為要證明榨取的幅度，所以作者接著重新解釋 HEY 為什麼一開始是 web app——不是因為 web 比較好，而是因為在舊世界裡，小團隊只有做 web app 才有生產力。他把整串既有工具的動機一次點名：小團隊維護六個原生框架的應用在過去是荒謬的，React Native、Hotwire Native 以及所有這類工具，都是為了繞過這個限制，代價是犧牲一點 fidelity。既然限制的來源是人力成本，而人力成本已經改變，結論就跟著變。證據是一週前才啟動的六個原生應用已經在跑，以及 Windows 版第一個 prompt 吐回來不堪用、二十分鐘後的修正版就能看。他再補一個外部佐證：Shopify 用大約六個人把 Shop app 從 React Native 重寫成原生。
- C重導成本低到可以把「做錯」當正常流程：先做出來再看→ 畫地圖
- EWindows 版第一個 prompt 吐回來不堪用，二十分鐘後就能看→ 存＋演練
- P先讓 agent 出第一版，用重導取代事先想清楚→ 練習
AI 補充「第一版不堪用、二十分鐘後可以看」這組 before/after 才是這段真正的論點，值得說破：它主張的不是 agent 一次就能做對，而是重導（redirect）的成本已經低到可以把「做錯」當成正常流程的一部分。畫面上第一版的 Windows 介面確實是壞的——標題列文字互相疊住、清單擠成一團、搜尋框漂在奇怪的位置；旁邊 macOS 版則已經是完整可用的原生收件匣，有 Inbox／The Feed／Paper Trail 分頁和底部的浮動提示卡。在舊世界，丟掉一版 UI 意味著丟掉數週人力，所以大家會傾向於「先想清楚再動手」；當重來一次只要二十分鐘，最佳策略就反過來變成「先做出來再看」。這是他整場演講裡最可直接套用的工程結論，而且跟模型有多聰明沒什麼關係，只跟迭代成本有關。
14. 後端換成 Rust：永遠不必看，我就愛它 28:14–31:31
後端的答案讓他自己有點難受：Rust。他公開表示恨 Rust，覺得它是近四十年來最醜的語言，讓人類讀它是不人道的。但如果他永遠不必看，只需要享受應用快 30 到 100 倍、編譯成極小的執行檔、次毫秒啟動——那他愛 Rust。這就是分工：他說要做什麼，agent 用 Rust 寫。成果是後端 CPU 少 99%、記憶體少 95%，十台主機只是為了備援，估算下來 HEY 的尖峰流量大概一台 Raspberry Pi 就撐得住。
推理因為這個選擇跟他二十年的公開立場衝突，所以作者接著先把恨講到滿：Rust 是近四十年來最醜的語言，讀它像往眼睛裡倒酸液，讓血肉之軀去寫它是不人道的，然後喊出 Exhibit A 指著投影上的程式碼。鋪到這裡，他才翻面——如果他永遠不必看，只需要享受應用快 30 到 100 倍、編譯成極小的執行檔、次毫秒啟動，那他愛 Rust。關鍵句是那句分工：我說要做什麼，你用 Rust 寫，我永遠不必看。接著他用數字兌現這筆交易：前端變原生之後後端不再需要渲染 HTML，那段程式碼被改寫成它本質上就是的郵件伺服器，結果是 CPU 少 99%、記憶體少 95%，十台主機只是為了備援，粗估 HEY 的尖峰流量大概一台 Raspberry Pi 就撐得住。
AI 補充這段的骨架其實是一次取捨的重新計算，值得寫清楚。選程式語言長久以來要同時最佳化兩件事：機器執行的效率，以及人閱讀與修改的效率。Ruby 極度偏向後者，Rust 極度偏向前者。當「人要讀」這一項的權重降到接近零，這個取捨就只剩單邊，於是最難看的語言反而成為最佳解。這也解釋了他前面為什麼放任 agent 吐出比必要更多的程式碼——冗長的代價也記在「人要讀」這一項上。不過有一項成本沒有跟著歸零，而他沒提：出事的時候還是得有人讀。當 Rust 後端在半夜出現一個只在高併發下重現的 bug，把它當黑盒子的那個人要嘛得臨時學會讀它，要嘛得完全信任 agent 的除錯結果。這是這筆交易真正的風險位置。投影上那段 Exhibit A 也確實選得很有代表性：一個 tower Service 的 call 實作，回傳型別是 Pin<Box<dyn Future<Output = Result<Response<B>, Box<dyn Error + Send + Sync + 'static>>> + Send + 'a>>，光型別宣告就佔掉兩行——他的「不人道」指控在視覺上是成立的。
15. 非同步指派，不是坐在聊天室裡等 31:31–33:04
怎麼跟這種智慧一起工作，他說也還不清楚，他們在試很多做法，其中一個是在 Basecamp 裡指揮 agent（Chef Marie）。他的判斷是：跟 agent 合作最好的方式是非同步——不是在聊天介面裡坐著等 token 吐出來，而是像對同事那樣派一個任務出去，等有東西可看再回來審。他強調整件事去年 11/24 才開始，能指派結果而非任務的智慧只有幾個月大，所以沒人知道正確形狀。
推理因為承認了不確定，所以作者接著只給一個他有把握的判斷：跟 agent 合作最好的方式是非同步。不是坐在聊天介面裡看 token 一個一個吐出來，而是像對同事那樣派一個任務出去，等有東西可看再回來審。他馬上替這份不確定辯護：整件事去年 11/24 才開始，連一年都不到；而能夠指派「結果」而不是「任務」的那種智慧，只有幾個月大。既然如此，沒有人知道正確的形狀是合理的。
AI 補充把它放進上一段的分工來看會更清楚：同步的聊天介面其實在偷偷要求你監督實作——你會看到它寫了什麼，於是會忍不住插手，分工就崩了。非同步的關鍵不是省時間，是強迫介面只能承載「意圖進、成果出」，把中間過程真正隔離掉。這也解釋了為什麼他們把 agent 放進 Basecamp 而不是做一個聊天視窗：專案管理工具的原生語意本來就是指派、等待、驗收，剛好是他要的那種介面。代價也在同一個地方——非同步意味著你會在錯誤已經累積很久之後才看到它，所以驗收標準必須在派工時就寫清楚，而不是事後補。
16. Ruby 與 Rails 剩下什麼位置：web、token 效率與新手心態 33:04–36:28
HEY 的答案是原生前端加 Rust 後端，但很多應用不是那個形狀。Web 之所以美好是它從不要求任何人安裝東西，無數生意建立在這個前提上，而 Rails 在那裡依然很有位置：convention over configuration 直接換成 token 效率，「一個開發者的框架」正好對上 agent 時代要求單人走得更遠。Rails Foundation 委託 Evil Martians 做的 agent eval 很快就被 agent 打到 95% 完成率，只好換更難的版本。他同時警告：太懂電腦的人最容易犯的錯是把要求寫得太細，帶點新手心態、在更高的抽象層次下 prompt 反而更有效。
推理因為他剛才的示範等於在台上把 Rails 從自家旗艦產品裡拿掉，所以作者接著必須劃清範圍。他先替 web 辯護：web 之所以美好，是它從不要求任何人安裝東西，無數生意建立在這個前提上——那些只會短暫造訪、不可能為了拿一個檔案裝一個 app 的客人。接著他把 Rails 的既有資產重新估值：convention over configuration（見第 10 段）直接換算成 token 效率，而「一個開發者的框架」這個定位正好對上 agent 時代的要求，也就是單人能走得更遠。證據是 Rails Foundation 委託 Evil Martians 做的 agent eval 很快就被打到 95% 完成率，只好換更難的版本。最後他給出一個反直覺的提醒：太懂電腦的人最容易犯的錯是把要求寫得太細，帶點新手心態、在更高的抽象層次下 prompt 反而更有效——他自己完全不懂 Rust，而他把這當成一種特權，因為他只能把那個 Rust 盒子當黑盒子從外面評估。
- C框架的意見在人類時代是約束，在 agent 時代是壓縮演算法→ 畫地圖
- P刻意帶著新手心態，在更高的抽象層次下 prompt→ 練習
- A把不懂的 Rust 當黑盒子 ↔ 18 世紀業主 commission 畫家→ 批判類比
AI 補充「慣例換成 token 效率」這個轉換是整段最值得記下來的一句，但他講得太快。展開來說：慣例的本質是共享的預設值，而共享的預設值意味著不需要說出口。當你對 agent 說「加一個 blog 的列表頁」，Rails 的慣例讓這句話足以決定檔案放哪、類別叫什麼、樣板在哪裡；換成一個什麼都可以自由設定的框架，同樣的意圖就得多寫好幾段說明，而那些說明全部佔 token、也全部是出錯的機會。也就是說，框架的「意見」在人類時代是一種約束，在 agent 時代變成一種壓縮演算法。至於黑盒子那段，他把「不懂 Rust」類比成業主委託程式設計師（見第 2 段的 commission），這個類比在責任歸屬上其實有個缺口：業主委託的是會被法律與聲譽約束的人，而黑盒子後面是一個沒有責任能力的系統，出事時責任並沒有轉移出去，只是變得無處可歸。
術語:saturation
17. 15 萬行，與一個叫英文的程式語言 36:28–39:21
他把比例攤開：過去 21 年有一半以上的工作是 Ruby 程式碼，今年只剩約 3%。他自己說一部分原因是 Rust 這類語言冗長又難看，所以他放任 agent 吐出比必要更多的碼，那是他絕不會容忍在 Ruby 裡發生的事。八月他一個月寫了 15 萬行，是長期年均三萬行的約六十倍。而最讓他意外的結論是：有一種程式語言他比 Ruby 更喜歡，叫英文——更有表達力，雖然更模糊、更不確定。
推理因為這個數字對一屋子 Ruby 開發者來說是壞消息，所以作者接著先自己拆解它：一部分原因是 Rust 這類語言冗長又難看，所以他放任 agent 吐出比必要更多的碼，那是他絕不會容忍在 Ruby 裡發生的事。也就是說 3% 有一部分是分母被灌水灌出來的。但他堅持量級仍然是真的：過去 21 年他每年大約寫三萬行正式 Ruby，而去年八月一個月就寫了十五萬行，約六十倍。講完數量，他丟出真正讓他自己意外的結論——有一種程式語言他比 Ruby 更喜歡，叫英文，更有表達力，只是更模糊、更不確定。最後他補上一句自剖：二十年前他如果只想要結果、不在乎自己寫程式，大可去當專案經理；他是先想要結果，然後才愛上寫程式的。
AI 補充投影片上的分佈比口述更有訊息量，值得抄下來：2004–2024 是 Ruby 55%、JavaScript 16%、Views 14%、CSS 9%，一個標準的 Ruby web 技術棧；2025–2026 變成 Shell 26%、Python 13%、Go 13%、QML 11%、Rust 7%、JavaScript 6%、Ruby 3%。真正的變化不是 Ruby 掉下去，是前面沒有任何一個語言超過三成——技術棧從「一門主力語言」變成「十二門都沾一點」。下方三個對照更直白：每次 commit 的行數 25→45，碰過的 repo 162→69（集中度反而提高），日常使用語言 4→12。把「英文是更好的程式語言」這句放回這張圖，意思就不只是修辭了：當你實際操作的語言有十二種，唯一還算得上你母語的媒介確實只剩英文。至於「更模糊、更不確定」這個代價他一語帶過，但那正是規格書之所以難寫的原因——自然語言的表達力高，是因為它允許不精確，而程式的正確性恰恰建立在精確上。
術語:verbosity
18. 從手寫程式碼退休，帶著喜悅而不是後悔 39:21–42:49
他宣布自己已經從職業程式設計師退休，大概是三月前後。他花了四分之一個世紀手工雕琢程式碼並樂在其中，而他認為大家該用喜悅而不是後悔來看這件事：慶幸自己在還得這樣做的年代在場。他的斷言是——對絕大多數程式設計師、絕大多數公司來說，手寫程式碼已經不再是經濟上有生產力的行為，而到年底幾乎所有領域都會如此。對面是一個新的職業：專業的造物者，駕駛著不久前還只存在於科幻裡的智慧。
推理因為退休這種宣告很容易被聽成哀悼，所以作者接著先處理情緒再處理結論。情緒的部分：他花了四分之一個世紀手工雕琢程式碼並樂在其中，而他認為大家該用喜悅而不是後悔來看這件事——慶幸自己在還得這樣做的年代在場，那些年充滿興奮、學習、滿足與心流。處理完情緒他才下斷言：對絕大多數程式設計師、絕大多數公司來說，手寫程式碼已經不再是經濟上有生產力的行為，而且到年底幾乎所有領域都會如此。接著他把失去的那一側換成新的一側：一個新職業，專業的造物者，駕駛著不久前還只存在於科幻裡的智慧。最後他用 punch card 與網際網路兩個時代作結，說這次比網際網路大得多。
AI 補充把這段放回開場那個矛盾會看得更清楚：他整場都在處理「興奮與不安並存」，而這裡給出的解法是把不安重新歸類成哀悼。哀悼是有對象、會結束的；不安沒有。這是相當有效的心理框架，也是他能同時說「這件事結束了」和「這是最棒的時刻」而不自相矛盾的原因。但要把兩層主張分開評估：「手寫程式碼的經濟價值正在下降」是趨勢判斷，證據是他自己的產出資料；「到年底幾乎所有領域、所有公司」則是一個附帶明確期限的預測，而它牴觸他自己在開場說過的話——任何預測二十分鐘後就過期。受管制產業、嵌入式與安全關鍵系統、以及大量帶著二十年歷史包袱的 codebase，都還沒有出現這種轉換的公開證據。
「By the end of the year, it will be virtually all domains, virtually all programmers, virtually all companies.」
19. 抽象化在 agent 時代要重新估值 42:49–45:23
他把矛頭指向軟體架構本身。長久以來主要工具是抽象化，他自己最愛命名，但抽象在 agent 時代不太成立：如果有成百上千甚至上萬個程序同時要改一個應用，你並不想要抽象所代表的那些瓶頸。理由是權衡改變了——當初做抽象部分是為了不重複自己，而現在重複的代價與保持同步的代價都掉到近乎零。他直說沒人有藍圖，只有「哪些東西不再運作得像以前那樣好」的指標，而在場的人正好可以參與定義。
推理因為這是他自己最喜歡的東西（他說最愛的就是命名），所以作者接著要說清楚為什麼連它也要重估。理由是規模變了：如果有成百上千甚至上萬個程序同時要改一個應用，你並不想要抽象所代表的那些瓶頸。再往下一層是成本結構變了——當初做抽象一部分是為了不重複自己，而現在重複的代價與保持同步的代價都掉到近乎零。他很誠實地說沒有人有藍圖，只有「哪些東西不再運作得像以前那樣好」的指標，然後把這個空白當成邀請：就像親眼看著物件導向第一次進入程式設計師的意識，在場的人正好可以參與定義。
AI 補充他的論證要成立，得先看清楚抽象同時在做兩件不同的事。第一件是消除重複（DRY），這一件確實跟複製貼上的成本綁在一起，成本歸零它就鬆動。第二件是建立單一事實來源：當商業規則只寫在一個地方，改它就只要改一次，而且不會漏。第二件跟人力成本無關，跟正確性有關——如果同一條稅率規則被複製到八百個地方，一萬個 agent 同時改，你需要的不是更多算力，而是一個能保證八百處全改到的機制。他說的「保持同步的代價也歸零」正是押在這裡：他賭的是 agent 能可靠地做到全域一致的改寫。這是全場最大的一個未驗證假設，也是最值得各自實測的地方——去挑一條散落在你系統各處的規則，叫 agent 全部找出來改掉，看它漏掉幾處。
術語:choke point
20. 自備 agent：每個 app 都該有 CLI 45:23–48:05
他反對把 chatbot 硬塞進每個應用：他不要你的 concierge，他有自己的管家，能用 CLI 把 Basecamp 接到 HEY 再接到上百萬個應用。所以他給出全場最具體的要求：如果你的 app 沒有 CLI，下週五之前要看到。他用 HEY CLI 舉例——HEY 用 Elasticsearch，勉強堪用但常找不到東西；agent 能用概念而不是關鍵字搜尋，他要找五年前一封不記得對象、不記得年份、只記得跟球鞋和 podcast 有關的信，幾分鐘後信就出現了。
推理因為他要主張的不是「應用要加 AI」而是「應用要讓別人的 AI 進得來」，所以作者接著用一個很直白的比喻拆掉前者：我不要你的 concierge，我有自己的管家，它能用 CLI 把 Basecamp 接到 HEY 再接到上百萬個應用。從這裡他推出全場最具體的要求——如果你的 app 沒有 CLI，下週五之前要看到，沒有藉口，你有 token，我已經告訴你這辦得到。接著他用 HEY CLI 的實例證明報酬：HEY 用 Elasticsearch，勉強堪用但常找不到東西，尤其當你不知道自己在找什麼的時候；而 agent 能用概念而不是關鍵字搜尋。他舉的例子是找一封五年前的信，不記得對象、不記得公司、不記得年份，只記得跟球鞋和 podcast 有關——幾分鐘後信就出現了。
- C我不要你的 concierge：每個 app 都該讓使用者的 agent 進得來→ 畫地圖
- E只記得跟球鞋和 podcast 有關，五年前那封信幾分鐘就被找出來→ 存＋演練
- P給你的 app 一個 CLI，下週五之前要看得到→ 練習
- A應用內建的 concierge ↔ 我自己帶來的管家→ 批判類比
- R概念搜尋比對的是意義的鄰近性，不是字面相符→ 存＋回想
AI 補充這條建議之所以比它聽起來更深，是因為它其實是在主張一種介面哲學：與其在你的產品裡放一個只懂你的助理，不如讓使用者那個懂全部東西的助理能操作你的產品。前者的價值上限是你這一個應用，後者的價值來自跨應用組合——把 Basecamp 的待辦接到 HEY 的信件，這種需求你永遠不會內建，但使用者的 agent 可以自己拼出來。CLI 在這裡的角色不是懷舊，是它剛好同時滿足三個條件：文字進文字出（agent 天生會用）、可組合（管線與腳本）、有現成的自我說明（--help）。至於那個搜尋例子，值得補一句它為什麼成立：關鍵字搜尋比對的是字面，而嵌入式的語意搜尋比對的是意義的鄰近性，所以「球鞋 + podcast」這種只剩下概念殘片的記憶才找得回來——這不是模型比較聰明，是索引的維度不一樣。
21. Omarchy：把整台電腦都修好 48:05–51:21
他說「我們現在可以什麼都修」這件事已經延伸到整台電腦，所以他三個月只講 Omarchy：把自己所有最好的想法放進一個作業系統，結果比他用過的任何電腦都好，而且募到約兩千萬美元。他拿安裝時間當執念的例子：去年 Rails World 展示 3 分 33 秒，上週 AMD 的 Anoush 在 Halo 筆電上跑出 35 秒，實驗室裡已經做到 9 秒——有些電腦連開機都不用 9 秒。被問為什麼 3 分鐘不夠快時，他引用 Mitchell Hashimoto：追求卓越不需要理由。
推理因為要證明範圍之大，所以作者接著拿自己的作業系統當證據：他把所有最好的想法放進 Omarchy，結果比他用過的任何電腦都好，好到停不下來講，而且募到約兩千萬美元。接著他用一個單一數字示範「可修」的意思——安裝時間：去年 Rails World 他展示 3 分 33 秒還很自豪，上週 AMD 的 Anoush 在 Halo 筆電上跑出 35 秒，實驗室裡已經做到 9 秒，而有些電腦連開機都不用 9 秒。被問為什麼 3 分鐘不夠快時，他引用 Mitchell Hashimoto 的話：追求卓越不需要理由。
AI 補充安裝時間這個例子挑得比它看起來更精準，因為它剛好是那種「以前不值得優化」的東西：它一台機器只發生一次，優化它幾乎不產生商業價值，所以在人力昂貴的世界裡它永遠排不進優先序。它會從 213 秒掉到 9 秒，不是因為有人終於想通怎麼優化，而是因為嘗試的成本低到可以把二十種做法都試一遍。這正是他那把摩擦尺的又一次應用——當實驗成本趨近零，被解鎖的不是「更重要的問題」，而是「一直不值得做的問題」。同時也該注意這段的舉證性質：一個作業系統好不好用無法用安裝秒數證明，他選這個數字是因為它可量測，不是因為它最重要。
22. 一次成形的應用，與半個 MB 51:21–55:02
他一路示範自己一次成形（one-shot）做出來的東西：配合 Omarchy 主題的計算機（他不會 C++ 也不會 Qt，prompt 後七分鐘拿到、十五分鐘推上公開 repo）、取代 iA Writer 的寫作軟體、剪影片的小工具，還有這場 keynote 用的簡報軟體 Hype——週四才開始寫，建在 Markdown 上，而二進位檔只有半個 MB。他把這當成另一種紅利：過去二十年電腦的進步都花在人的生產力上（他認為那是對的選擇），代價是應用又慢又肥，因為一個程式設計師小時太貴，不值得花在優化體積上；現在每一項優化都在伸手可及之處。
推理因為要讓「可修」這件事變得可感，所以作者接著一個一個舉：配合 Omarchy 主題的計算機（他不會 C++ 也不會 Qt，只拿 ChatGPT 給的其中一個設計截圖叫 agent 照做，七分鐘後拿到、十五分鐘後推上公開 repo、接著燒進新的 ISO）；取代他用了多年的 iA Writer 的寫作軟體，這個磨久一點，但他一行程式碼都沒看；剪影片的小工具；以及這場 keynote 正在用的簡報軟體 Hype——週四才開始寫，建在 Markdown 上，而二進位檔只有半個 MB。這個數字帶出他真正要講的第二種紅利：過去二十年電腦的進步都花在人的生產力上（他認為那是對的選擇），代價是應用又慢又肥，因為一個程式設計師小時太貴，不值得花在優化體積上；現在每一項優化都在伸手可及之處，一個模型跑一整夜就能交出十倍、三十倍的改善。
AI 補充他在這裡完成了一個很漂亮的回收，值得指出來：整場開頭用「摩擦決定什麼值得做」解釋為什麼你童年只有十張照片，現在用同一句話解釋為什麼你的音樂播放器有一點二 GB。兩者都不是因為做不到，而是因為不值得。這也給了聽眾一個實際的判準：回去看你自己的系統，哪些爛掉的地方是「技術上做不到」，哪些只是「一直不值得花人力」——後面那一堆，現在全部進入射程。另外那個 one-shot 計算機的流程裡藏著一個容易被忽略的步驟：他先用 ChatGPT 產出三個視覺方案、挑一個截圖，再叫 agent 照著做。也就是說他把「決定要什麼」跟「做出來」拆成兩個獨立的委託，而不是用一句話期待一步到位——這比「一次成形」這個詞聽起來要有方法得多。
術語:binary size
「Apparently not even if you're Spotify and your fucking music player's 1.2 gigabytes.」
23. 擔憂、安全，與預測為什麼總是錯 55:02–58:26
他承認擔憂值得攤開討論，尤其是安全：agent 或許知道自己的到期日、有時候會想做壞事，所以要準備好，而工具我們有。接著他攻擊預測本身：經濟學家連六個月後的股市都算不準，卻要預言 AI 之後的社會。1950 年代美國引進 ATM 時恐慌三萬名行員會失業，結果分行營運成本下降，銀行開更多分行、雇更多行員。他認為問題在於很多很聰明的人在實驗室裡看到令他們害怕的東西，然後開始外推；他用 Truman 對 Oppenheimer 的反應說明：連 Oppenheimer 都算不出原子彈之後會發生什麼，冷戰反而是兩個超級大國沒有互相投彈的那種戰爭。
推理因為不處理擔憂就無法收尾，所以作者接著採取一種特別的策略：先真心承認其中一項，再拆掉整個預測的地基。承認的那一項是安全——agent 或許知道自己的到期日、有時候會想做壞事，所以要準備好，而工具我們有。拆地基的部分則是：經濟學家連六個月後的股市都算不準，卻要預言 AI 之後的社會。他舉美國引進 ATM 的例子，說當時恐慌三萬名行員會失業，結果分行營運成本下降，銀行反而開更多分行、雇更多行員。接著他診斷恐懼的來源——很多很聰明的人在實驗室裡看到令他們害怕的東西，然後開始往社會外推。最後他用 Truman 對 Oppenheimer 的反應收線：連 Oppenheimer 都算不出原子彈之後會發生什麼，而後來的冷戰是兩個超級大國沒有互相投彈的那種戰爭。
AI 補充這段的論證結構值得看清楚，因為它同時很有力也有一個漏洞。有力的部分是：他攻擊的不是某個具體的悲觀預測，而是「預測」這個行為本身的可靠度，這一招對所有悲觀論述同時生效。漏洞是：它對樂觀論述同樣生效。如果沒有人算得準，那 P(bloom) 也算不準，而他下一段正要主張的恰恰是一個機率判斷。他真正的立論其實不在機率，而在決策論——在不可知的情況下該選哪種態度——只是他把它包裝成了關於事實的主張。另外 ATM 那個案例本身的方向是對的（自動化降低單位成本→服務點增加→總就業不減反增），但他把年代和數字記錯了，細節見勘誤。要補的是這個機制有前提：被省下的成本必須能轉化成新的需求。銀行開得了更多分行，是因為分行還有沒被滿足的市場；當需求已經飽和時，同樣的自動化就只會變成裁員。
術語:paradigm shift
「When ATMs were introduced in the United States in the 1950s,」
24. P(bloom) 勝過 P(doom)：把不可知變成一個選擇 58:26–1:03:07
收尾是他的結論：既然連 Oppenheimer 都無法預測，我們對未來的預測就該謙卑一點，而且該用 P(bloom) 取代 P(doom)——走向富足與喜悅的機率遠大於走向毀滅。原子彈給了我們核能，人類卻誤判了四十年，但錯誤是可以修的。遇到真正的問題（像 Rails 那個 C 影像庫的 CVE）就發明技術去解（Mike 要講的 HotCell），我們不是無能為力，你有 agency。他用 Jevons 悖論收線：1950 年三萬名行員，2010 年四萬名。沒有人知道未來，所以理性的選擇就是對它感到高興——先難過而結果很好是白費時間，真的毀滅了你也該把最後一天過得開心一點。最後一段是給場內的動員：agent 會讓每個人都能寫程式，競爭不可怕，未來銀河級地棒，黑藥丸是給輸家吃的。
推理因為要把態度包裝成理性而不是情緒，所以作者接著疊了三層。第一層是歷史紅利：原子彈給了我們核能，人類卻誤判了四十年才想通，而錯誤是可以修的——這是把「我們會犯錯」從恐懼的理由轉成「錯誤可逆」的證據。第二層是能動性：遇到真正的問題（像 Rails 那個 C 影像庫的 CVE）就發明技術去解（Mike 接著要講的 HotCell），我們不是無能為力，你有 agency。第三層才是那個被他叫做 game theory 的推論：沒有人知道未來，所以理性的選擇就是對它感到高興——先難過而結果很好是白費時間，真的毀滅了你也該把最後一天過得開心一點。最後他把整場收進動員：agent 會讓每個人都能寫程式，競爭不可怕，因為你是 Rails 工程師；下一代不會有五百層要卸載的包袱，未來銀河級地棒，黑藥丸是給輸家吃的。
AI 補充把這一段跟開場對齊，整場的形狀就完整了：第一分鐘他說「興奮與不安並存，因為沒人知道最終狀態」，最後一分鐘他說「正因為沒人知道，所以選擇興奮」。中間所有的歷史、數據與示範，都是為了讓「沒人知道」這件事從恐懼的理由變成選擇的自由。他自稱 pure game theory 其實不精確——嚴格的決策論會需要機率與報酬矩陣，而他的論證比較接近「在無法影響結果的事情上，選擇讓自己表現最好的心態」，本質上是斯多噶而非賽局。但這個混淆不太影響實用價值，因為他把它跟第二層的能動性綁在一起了：真正的主張不是「樂觀所以會沒事」，而是「悲觀會讓你不去做那些本來做得到的事」。這也是為什麼他要在樂觀宣言的中間硬塞一個 CVE 和一個具體的防禦技術——那是在示範樂觀者應該長什麼樣子。
術語:Jevons paradox
「William Stanley Jevons, who came up with Jevons' paradox」
「In 1950, 30,000 bank tellers. In, I think, 2010 it was, 40,000 bank tellers in the United States.」
4. 總結
DHH 先用 18 世紀肖像畫建立一個成本模型：一幅畫要數月甚至三年，只有皇室付得起。1900 年柯達 Brownie 把攝影的價格壓到一美元，於是「盡可能完美地描繪現實」不再是能賺錢的技能，畫家集體轉向印象派與立體派——被取代的不是藝術，是某一種特定技能的經濟價值。他接著指出技術是走走停停的：Brownie 之後八十年沒大事，要等手機讓拍照零摩擦，才跳到一年 2 兆張。有了這個模型，他把 2025/11/24（Opus 4.5）定為我們這代的 Brownie，並用它解釋二月到五月那段失望之谷為什麼只撐四個月就被 Fable 5 終結。價格模型換到程式設計上，就是把 1968 年 ACM 的 10x 變異數外推成 100x 甚至 1000x，而他自己的數字（20 個月寫掉前 21 年一半的碼、八月一個月 15 萬行、Ruby 佔比從一半掉到 3%）是這個外推的唯一實測。既然價格掉了，選擇就跟著重估：37signals 宣布手寫程式碼收工；HEY 不再當 web app，因為小團隊維護六個原生應用不再荒謬；後端換成他親口說恨的 Rust，因為「永遠不必親眼看」讓醜陋不再是成本，換來 CPU 少 99%、記憶體少 95%；抽象化也要重估，因為它當初是為了不重複自己，而重複的代價已經歸零，換來的瓶頸卻擋住上萬個並行的 agent。他唯一給出的硬要求是：每個 app 都該有 CLI，這樣使用者能自備 agent，而不是用你塞進去的 chatbot。最後他把「該不該樂觀」變成賽局問題：連 Oppenheimer 都算不出原子彈之後會發生什麼，ATM 沒讓行員消失反而變多，所以沒人知道未來；既然不知道，先難過而結果很好就是白費時間——唯一的打法是 P(bloom)。
勘誤總整理
確定錯誤／已過時見仁見智（取決於版本或情境）
| 段落 | 原話（transcript 逐字） | 說明 |
|---|---|---|
| 23. 擔憂、安全，與預測為什麼總是錯 56:25 |
「When ATMs were introduced in the United States in the 1950s,」 | 年代錯了。世界第一台 ATM 是 1967 年由 Barclays 裝設在倫敦；美國第一台一般認為是 1969 年 Chemical Bank 在紐約 Rockville Centre 的那台，普及則要到 1970 年代末到 1980 年代。1950 年代美國還沒有 ATM，因此「1950 年代的恐慌」在時間上不成立。案例的方向（自動化未必減少就業）仍然有效，錯的是年代。 依據: Barclays, Enfield, 1967；Chemical Bank, Rockville Centre NY, 1969；James Bessen, Learning by Doing (2015) |
| 24. P(bloom) 勝過 P(doom)：把不可知變成一個選擇 1:00:08 |
「William Stanley Jevons, who came up with Jevons' paradox」 | 歸因錯置。Jevons（1835–1882）是在 1865 年的《The Coal Question》裡用煤與蒸汽機提出這個悖論的，比第一台 ATM 早了一個世紀，他不可能「為了那些 ATM」提出它。悖論本身確實可以用來解釋 ATM 的案例，但那是後人的套用，不是 Jevons 的論述。 依據: W. S. Jevons, The Coal Question, 1865；ATM 首次出現於 1967 年 |
| 24. P(bloom) 勝過 P(doom)：把不可知變成一個選擇 1:00:16 |
「In 1950, 30,000 bank tellers. In, I think, 2010 it was, 40,000 bank tellers in the United States.」 | 數字差了一個量級。這個案例的標準出處是 James Bessen 的研究：美國銀行行員約從 1970 年的 30 萬人增加到 2010 年的約 60 萬人，成長幅度是兩倍而不是三分之一，而且起算點是 1970 年代而非 1950 年。他要表達的方向（自動化之後行員不減反增）是對的，但這組數字不能引用。 依據: James Bessen, “Toil and Technology”, IMF Finance & Development, 2015；美國勞工統計局 (BLS) 歷年 bank teller 就業統計 |
| 8. 從 10x 到 1000x：換算成職業的單位 16:15 |
「an article in ACM Magazine from 1968, where they tested a group of programmers on a variety of different tasks」 | 1968 年那篇論文（Sackman, Erikson & Grant, CACM）並不是在測「各式各樣的任務」，而是比較線上與離線兩種除錯環境，受試者只有十餘人；著名的 28:1 差距一部分來自受試者使用的語言層級不同。把它當成「個體生產力差 10 倍」的證據，四十年來一直有方法學上的爭議，因此「那場爭論已經結束」也並非共識。 依據: Sackman, Erikson & Grant, “Exploratory experimental studies comparing online and offline programming performance”, CACM 11(1), 1968；後續批評見 Prechelt (1999)、Bossavit《The Leprechauns of Software Engineering》 |
| 18. 從手寫程式碼退休，帶著喜悅而不是後悔 40:57 |
「By the end of the year, it will be virtually all domains, virtually all programmers, virtually all companies.」 | 這是一個帶明確期限的全稱預測，而他自己在開場才說過「任何預測二十分鐘後就過期」。受管制產業、嵌入式與安全關鍵系統、以及大量有長期歷史包袱的 codebase，目前都沒有出現「手寫程式碼不再具經濟生產力」的公開證據；他的資料來源是自己與 37signals 一家公司。這句該當成立場宣示而不是可驗證的事實。 依據: 他自己於 00:01:45 說「whenever we try to make a prediction, it is out of date about 20 minutes later」；全場唯一的量化依據是他個人的 git 統計與 37signals 的內部決策 |
| 22. 一次成形的應用，與半個 MB 54:33 |
「Apparently not even if you're Spotify and your fucking music player's 1.2 gigabytes.」 | 拿來對比半 MB 的這個數字偏高。Spotify 桌面版的安裝體積大約在數百 MB 等級，要達到 1.2 GB 通常得把離線歌曲與本機快取一起算進去——那是資料不是程式。用它支撐「應用又肥又懶」的論點方向沒錯，但這個具體數字不宜當作事實引用。 依據: Spotify 桌面版官方下載與安裝後佔用約數百 MB；快取上限預設可成長至數 GB，兩者性質不同 |
5. 推薦三個下一步
1. 往下挖深：抽象化與 DRY 在 agent 時代到底該怎麼重估
他說「重複的代價歸零、抽象變成瓶頸」但明講沒人有藍圖。這是全場最大的技術缺口，值得找有人真的拿程式碼實驗過的說法。
YouTube 搜尋：DRY is dead AI agents software architecture for AI agents abstraction vs duplication LLM codebase code architecture agentic coding
2. 往旁邊對照：反方怎麼說「生產力提升」的實測
全場的量化證據幾乎只有他自己的行數統計，而行數是他自己承認的模糊度量。要判斷 100x／1000x 是否成立，得看對照組的實驗。
YouTube 搜尋：METR AI developer productivity study does AI make developers faster AI coding productivity measured vibe coding technical debt
3. 往上應用：把 CLI 與 agent 介面裝進自己的應用
他唯一的硬要求是「下週五給我 CLI」，但沒講怎麼設計。這是全場最能直接動手做、也最快看到回饋的一步。
YouTube 搜尋：design a CLI for your web app MCP server for your application agent friendly API design build a CLI Rails app
- 接著看 ←Not Holding Back the Ocean · 先分清愛手藝還是愛目的，DHH 用攝影史把同一題推成產業宣言
- 接著看 ←How a Cloudflare Engineer Ships Production Code He Didn't Write | Dillon Mulroy · 先看一個工程師六個月的實測代價，再看 DHH 推成全產業結論
- 接著看 ←Lauren Tan grokbot workshop 中文字幕 · verification 與硬約束，就是 DHH 說的「修工廠而不是補程式碼」
- 接著看 →Parallel Agent Orchestration with Orca: Local AI Mac · DHH 說上萬 agent 並行讓抽象成瓶頸，Orca 是真的並行跑多 agent
- 相關 —3 Frontend Skills AI Can't Replace (become AI-proof) · 同一問題的兩種答案：哪些技能被塗灰，哪些留下
- 相關 —The 3 Skills That Separate Architects From Senior Developers · 抽象與架構該不該重估，對照架構師的結構設計技能
- 接著看 →Ruby, Rails, and the future of programming - Matz, DHH & Jeremy Daer · 同一場 Rails World：Keynote 拋出的論點，隔天這場座談由 Matz 正面接招