Ruby、Rails 與程式設計的未來：Matz 與 DHH 對 agent 時代的一場對談

1. 預測失效，只剩機率 0:00–2:55

主持人指出 Rails World 整場都在談 AI，David 前一天的演講留下一堆未解問題。面對最不確定的時刻，人反而最想要預測。Matz 說兩年內他從 Emacs 換成 Claude Codei，方向已無法預測；David 把問題重新定義成「不是確定性，而是機率」，而他看到的機率是：今年底幾乎所有人都會像 Matz 一樣透過 agent 寫程式。

推理因為主持人要的是預測，而兩位講者都先否認自己預測得了（Matz 舉自己兩年內從 Emacs 換到 Claude Code 為例，說方向根本無法預測），所以 David 把問題整個換掉：現在能操作的不是確定性，而是機率。他願意給的唯一一個數字是機率上的判斷——今年底不是「多數人」而是「幾乎所有人」都會像 Matz 一樣透過 agent 寫程式；面對這種大浪，沒有人有能力讓它停下來，所以第一件事是接受它正在發生。

• C面對不確定要操作機率，不要操作預測→ 畫地圖

AI 補充把「預測」換成「機率」是整場對話的地基，值得停一下。預測要求你說出方向與時點，錯了就整個失效；機率只要求你對幾個可能的世界分配權重，於是你可以在不知道方向的情況下仍然行動——押注在多個世界裡都不虧的選擇上。David 後面所有論證（包括對批評者的回應）都是用這個工具做的。另外提醒：這支的字幕是機器產生／機器翻譯的英文軌，把 Matz 拼成「Matsu」、把 Claude Code 拼成「Cloud Code」，講者實際說的是 Claude Code。

術語:coding agenti

2. 悲傷五階段的 speedrun 2:55–4:24

David 把社群的反應對應到接受死亡的五階段，並指出很多人已經從憤怒進到「討價還價」。他說跟 AI 討價還價沒用：它會回應你，但不會改變軌跡。愈快走到接受愈好，因為接受之後看到的是「機器做出新東西」這件事本來就迷人的那一面。

推理因為上一段已經確立「沒有人有能力停下這件事」，所以 David 接著把社群的反應對號入座：很多人已經走過憤怒，正卡在討價還價。而他指出討價還價在這裡結構上就無效——AI 會聽你說、會回應你，但不會因此改變軌跡，因為另一邊根本沒有可以談判的對象。既然討價還價沒有回報，最省成本的策略就是盡快走完沮喪、走到接受；而他保證接受之後看到的是「讓機器做出新東西」這件事本來就迷人的那一面，只是現在從有想法到看見它活起來快得多。

• A社群對 AI 的反應 ⇄ 悲傷五階段→ 批判類比

AI 補充五階段模型原本描述的是人面對自己的死亡，借到技術變遷上有一個差異值得指出：面對死亡時「討價還價」無效是因為對方不存在，面對市場時討價還價無效則是因為對方是分散的很多人——你說服得了幾個同事，說服不了整體的採用曲線。David 的論點強在這裡：他不是說反對是錯的，而是說反對沒有著力點。反過來說，這個框架也有代價——把所有反對意見都歸類成「還沒走到接受」，等於預先取消了「有些反對是對的」這個可能性。

術語:five stages of griefi

3. 身分活得比職業實踐更久 4:24–6:51

主持人問了一個尖銳的問題：昨天問「誰寫 Ruby」舉手的人不多，但問「誰覺得自己是 Rubyisti」全場舉手——當身分比實踐活得更久，剩下的殘留物是什麼？Matz 用卓別林《摩登時代》的例子回答：技術改變生活，但人可以選擇自己在其中的感受與位置。

推理因為身分活得比職業實踐更久，主持人的問題就變成「那剩下的殘留物是什麼」。Matz 不從技術面回答，改用歷史類比：八十多年前自動化進工廠時，人們也擔心工作被機器拿走，還因此有了卓別林的《摩登時代》；但結果不是人被趕走，而是生產的負擔被減輕、工作方式整個換了一種。他據此推論未來十年可能是同樣的形狀——軟體開發者的生活會跟現在不同，但我們仍然可以替自己選一個舒服而有創造性的位置，而不是被動地從高薪工作裡被踢出去。

• AAI 取代寫程式 ⇄ 工業自動化與《摩登時代》→ 批判類比

AI 補充Matz 的類比跳過了一步，值得補上：自動化確實拿走了特定的工作（流水線上的特定工序），它之所以沒有造成長期失業，是因為生產力提升把成本降下來、需求被放大，新的職位在別的地方長出來。也就是說這個類比要成立，必須假設需求有彈性、而且新職位長出來的速度跟得上舊職位消失的速度——這兩個條件在《摩登時代》那個年代成立，這次成不成立是開放問題。另外要注意 Matz 真正的主張其實比類比更小也更穩：他沒有保證結果會好，他說的是「我們可以選擇自己在其中的感受與位置」。

4. 從 software writer 到 software maker 6:51–13:13

David 說他從來不覺得「software engineer」適合自己，他自認是 software writeri；而現在的新角色是 software makeri——要考慮的事更多，但比單純寫程式更滿足。他主張 Rubyist 的「品味i、比例感、覺得這樣才美」正是與 agent 合作時人類還能加上的價值，而且這件事不是 Ruby 獨有的，所有語言、框架都會經歷。

推理因為要回答的是「新位置」，David 先把舊位置講清楚（writer：手寫程式碼這件事本身就是價值），再宣布新位置 software maker——要考慮的事更多、要學的更多，但比單純寫程式更令人滿足。接著他要證明 Rubyist 特別適合這個新位置，論據是：與 agent 協作時人類還能加上的價值是品味、是比例感、是「覺得這樣才美」的那種感覺，而這正是寫 Ruby 時一直在練的東西。最後他把 Ruby 從等式裡拿掉：這不是 Ruby 的事，所有領域、所有函式庫、所有框架、所有語言都會經歷同一件事，所以「跳槽到 Rust」是假解法——他對 Rust 沒有任何自我投入，明天出現更好的就換，甚至可能直接跳到組合語言，因為不可攜性不再重要。

• C人的價值從打字移到品味與比例感→ 畫地圖

AI 補充這裡其實混了兩個強度不同的主張，值得分開。第一個是「技能可以遷移」：品味與比例感不綁在語法上，所以會跟著你到新角色——這個比較安全。第二個是「陣營已經不存在」：他不是說 Rust 沒用，而是說當語言選擇被 agent 抽象掉之後，把身分綁在任何語言上都是同一個錯誤，包括綁在 Ruby 上。第二個主張比較強，也是全場最容易被誤讀的一句——現場很多人聽到的是「別捨不得 Ruby」，但他的意思是「別捨不得任何一個」。另外他在這裡回頭處理了上一段的身分焦慮：他承認自己走完五階段也不是瞬間的，而且明說該給懷舊留位置，只是別停在月台上。

5. Spinel：為 agent 重畫 Ruby 的界線 13:13–17:03

Matz 坦承純以經濟效益看 Ruby 不是最佳選擇，所以他今年三月開始做 Spineli——把 Ruby 編譯成原生執行檔，實測記憶體用量約為原本的二十分之一。主持人把它接到 mrubyi 的脈絡：mruby 是 Ruby 給嵌入式的答案，Spinel 像是 Ruby 給 agent 的答案。Matz 說目前只有他能劃出「什麼是 Ruby、什麼不是」這條線。

推理因為承認了經濟理由不成立，Matz 選擇改變前提而不是改變說法：他今年三月開始做 Spinel，把 Ruby 程式編譯成原生執行檔，實測跑得很快而且記憶體用量約為原本的二十分之一。主持人把它放進 Matz 的作品譜系來理解——mruby 是 Ruby 給嵌入式環境的答案，Spinel 看起來像是 Ruby 給 agent 的答案——並追問一個更根本的問題：一直拿掉東西之後，還算 Ruby 嗎？Matz 的回答是：這件事沒有明顯答案，CRubyi 就是他多年試誤的結果，但一套解法不適合所有情境（對微型裝置太大、即使有 JIT 對某些場合仍太慢），所以他切出一個「生產性子集」去編成原生碼；而至少到目前為止，只有他能劃出什麼是 Ruby、什麼不是這條線。

• Cagent 要的是短命行程，所以要事前編譯→ 畫地圖
• ESpinel 實測記憶體約為原本的二十分之一→ 存＋演練
• RSpinel 是什麼→ 存＋回想
• Rmruby 的定位→ 存＋回想
• RJIT 對短命行程為什麼沒用→ 存＋回想

AI 補充這裡有一步被跳過：為什麼 agent 時代特別在意記憶體與啟動速度？因為 agent 會把同一個執行環境開很多次、每次都很短命——跑一次測試、跑一個一次性腳本、開一堆平行 worker。直譯器的啟動時間與常駐記憶體在人類一天手動跑十次時無所謂，在 agent 一小時跑上千次時就變成主要成本。這也是 JIT 幫不上忙的地方：JIT 要先跑熱才划算，短命行程根本熱不起來，所以答案只能是事前編譯（AOT）i。另外提醒兩件事：字幕裡的記憶體數字前後不一致（二十分之一、20 MB、25 MB 混著講），可靠的只有「約二十分之一」這個比例；主持人提到的那個「把 Ruby 應用當成 agent 可查閱的規格」的專案名稱在字幕裡拼寫不可靠，這裡不當成事實引用。

術語:Just-in-Time compilationi

6. 寫程式不再是職涯，能力卻被放大 17:03–21:05

Matz 預測多數人會轉向管理產品與上市，寫程式作為職涯在不久的將來會被拿走；但同一件事讓缺乏技能與經驗的人也能做出解決方案。他把人分成「提供解法的人」與「等解法的人」，而這個社群屬於前者。David 補上 Ruby 的新角色：在不再親手寫多數程式碼的世界，Ruby 是最適合「解釋概念」的語言——agent 用 Ruby 向他解釋 Rust 程式碼。

推理因為問題是「還剩什麼」，Matz 先給壞消息：多數人會把重心移到管理產品與把它推上市，所以至少作為職涯，寫程式在不久的將來會被拿走。但同一個機制也給好消息：以前缺技能、缺能力、缺經驗就做不出解法，現在 agent 補上這一段，沒有深入知識的人也能做出解法。他據此把人分成「提供解法的人」與「只是在等別人給解法的人」，並說在場的屬於前者，因此該做的是把提供解法的能力再拉高。David 接著補上 Ruby 在這個世界裡的新角色：既然多數程式碼不再是我們親手寫的，我們需要的就是理解——而 Ruby 是最適合解釋概念的語言，他現在讓 agent 用 Ruby 向他解釋 Rust 程式碼。

• P讓 agent 用你最好讀的語言解釋別的語言的程式碼→ 練習

AI 補充David 這個論點順便解釋了 Ruby 二十年前為什麼會紅。他說自己第一次認識 Ruby 是在 Dave Thomas 等人寫的雜誌文章裡，一度以為那是虛擬碼i——「看起來像虛擬碼但真的跑得動」正是 Ruby 的賣點。有趣的是這個賣點在 agent 時代不但沒貶值反而升值：當你不讀實作只讀說明時，說明的可讀性就是全部。不過要指出一個沒被檢驗的假設：agent 用 Ruby 解釋 Rust，正確性仍取決於 agent 對那段 Rust 的理解，Ruby 只是讓誤解更容易被你看出來，不會讓誤解變少。

術語:solution provideri

7. 餅不是固定的：軟體會爆量 21:05–25:57

David 指出焦慮來自把世界想成固定大小的餅：同樣數量的應用確實只需要更少工程師。但我們會做更多——GitHub 的統計就是軟體開發爆炸性成長的證據。他把這當成樂觀的理由，也當成就業保障，前提是別把鉛筆抓得太緊、想像不出計算機能幫上什麼忙。主持人回想 2000 年代初的極限編程：當開發成本遠高於執行成本時該怎麼選，如今這個比例反過來了。

推理因為前提是「應用數量固定」，結論當然是需要的工程師變少——David 完全同意這個推論，他拒絕的是那個前提：今天這些應用確實會用少得多的人維護與開發，但我們會做更多，而且正在做更多；他拿 GitHub 的成長統計（以及它因此三天兩頭出狀況）當作軟體開發爆炸性成長的證據。由此他把同一件事同時當成樂觀的理由與就業保障，但附一個條件：別把鉛筆抓得太緊，緊到想像不出計算機能幫你什麼忙。主持人接著把時間拉回 2000 年代初的極限編程——當年開發成本遠高於執行成本，所以選一個很有彈性的語言是划算的；如今這個比例反過來了，那我們工作的產物到底是什麼？Markdown？規格？那些當年因為週期太長、成本太高而被拋棄的做法，現在是不是又值錢了？我們是不是要回到瀑布式？

• C把軟體想成固定大小的餅，就會算錯需要多少人→ 畫地圖

AI 補充「固定大小的餅」在經濟學裡有名字：lump of labour fallacyi。歷史證據大致站在 David 這邊——自動提款機並沒有消滅行員、試算表也沒有消滅會計——但有兩個條件常被略過：一是需求必須真的有彈性（軟體大概有，但不是無限），二是轉換的痛苦落在個別的人身上而不是落在平均值上，所以「總量會成長」對正在被裁的人不是安慰。另外主持人的問題其實比 David 的回答更尖銳，而且沒有被回答完：如果程式碼結構不再重要，極限編程當年為了擁抱變化所付出的代價（短週期、高頻回饋、測試先行）還值得嗎？David 只回了一半——方法論變得比較不重要，因為我們不再親手碰程式碼。

術語:Extreme Programmingitest-driven developmentiwaterfall modeli

8. Matz 才是最早的 vibe coder 25:57–29:46

Matz 說 vibe codingi 對玩具專案可行、對真實應用常慘敗，但他身邊的資深 Ruby 開發者用 vibe coding 寫 Ruby 本身成功率極高——差別在於「知道怎麼引導軟體的生成、怎麼替 agent 定義目標」，這件事必須被形式化並傳給下一代。接著他丟出全場最好的類比：他自己 vibe coding 十五年了，因為他是 Ruby core 的領導者，提出想法、由「有機智慧i」寫出實作、他再驗收。

推理因為同一個工具在不同人手上結果差這麼多，Matz 推論差別不在工具而在人：資深開發者知道怎麼引導軟體的生成、怎麼替 agent 定義目標，而這正是上一段說要形式化的東西，所以必須把它寫下來傳給下一代。接著他丟出全場最好的類比：他自己已經 vibe coding 十五年了——身為 Ruby core 的領導者，他提出「垃圾回收器這樣改如何」，由他戲稱為「有機智慧」的人類開發者寫出實作，他再驗收該不該合併。David 用自己的 Rails 史印證同一個形狀：第一版全部自己寫、第二版寫一半、到第六七版幾乎沒寫，只剩下方向、什麼算好、什麼該收進來。最後他用創新者的兩難i把反對意見一次處理掉：新技術一開始都像玩具、只能做最簡單的事，當年說「Rails 無法規模化」的人就是這樣錯的，現在說「AI 只是玩具」的人會用完全一樣的方式錯。

• C提想法、別人實作、自己驗收——資深者一直都這樣工作→ 畫地圖
• C新技術一開始都像玩具，嘲笑玩具的人會一樣地錯→ 畫地圖
• P把「怎麼替 agent 定義目標」寫下來→ 練習
• Avibe coding ⇄ Matz 帶 Ruby core 的十五年→ 批判類比
• ERails 第一版全自己寫，第六七版幾乎沒寫→ 存＋演練

AI 補充這個類比很強，但有一步被跳過了。Matz 驗收人類開發者的實作時，背後有一整套他沒提到的機制：對方有動機與聲譽要維護、有可追責性、會記得上次被退件的理由、也會自己判斷這個提案值不值得做。agent 目前沒有這些，所以「提出想法—別人實作—我驗收」這個迴圈雖然形狀相同，成本結構卻不同：驗收的頻率與深度必須提高，因為你不能靠對方的長期紀錄來省下查核。反過來說，Matz 的論點仍然成立在一個關鍵點上——資深者的價值從來就不在打字，這件事在 agent 出現之前就已經是真的了。

9. Slop、slop grenade 與心理防衛 29:46–36:02

David 用創新者的兩難解釋為什麼「AI 只是玩具」的說法會錯得跟當年說「Rails 無法規模化」一樣。主持人問「slopi」「meat proxyi」這些嘲諷有多少是真診斷、多少是心理防衛，David 答九成是防衛。他區分兩件事：meat proxy 是真問題但只是過渡（別自己在 agent 與錯誤訊息之間複製貼上），而「AI 寫不出高品質原創程式碼」則是鴕鳥式的自欺。主持人補充 slop grenadei 的痛點不在垃圾本身，而在丟給別人收拾。

推理因為他自己主張要操作機率而不是預測，所以他把這個判斷也講成機率——最可能的解釋是防衛反應，而愈早丟掉這些拐杖就愈早跑得動。但他不是一竿子打翻，而是把被嘲諷的兩件事分開處理：meat proxy 是真問題（你在 agent 與錯誤訊息之間人工複製貼上，那就該讓 agent 直接讀那些訊息），但它只是從 A 點到 B 點的臨時橋；而「agent 寫不出高品質、原創、沒有 bug 的程式碼」則是鴕鳥式的自欺。主持人補上一個更細的區分：slop grenade 的痛點不在垃圾本身，而在交付方式——被丟過來，然後由別人花注意力去弄懂它、判斷值不值得放行。David 的回應把這個痛點再翻一次：他把它們當成建議，不接也可以；而且正因為沒人親手寫那些行，砍掉重寫時不會有人心痛——開源社群過去很多摩擦，正是來自人對自己花力氣寫的那些行的依戀。Matz 用當天早上的實例收尾：Spinel 的 repo 一小時內冒出二十個 issue 與一個 merge request，他用手機叫 Claude 處理，演講結束時十二個問題都解決了。

• P別當 meat proxy：讓 agent 自己讀錯誤訊息→ 練習
• EMatz 用手機讓 Claude 一小時解掉 12 個 issue→ 存＋演練

AI 補充David 的「九成」是修辭不是量測，這一點值得先標出來，否則整段會被當成數據。更值得討論的是他論證裡的一個空缺：他把「對自己寫的程式碼的依戀」當成純負面的摩擦來源，但那份依戀同時也是長期維護意願的來源——會心痛的人才會半夜爬起來修。把依戀拿掉之後，誰來承擔沒有人想寫的那部分工作，他沒有回答。另外 Matz 的例子成立有個前提：Spinel 是他自己定義邊界的專案，驗收標準在他腦子裡，所以他能用手機在幾十分鐘內判斷十二個修正是否可接受；同樣的流程放到一個標準模糊、利害關係人很多的專案上，瓶頸會立刻從產出移到驗收。

術語:AI psychosisi

10. 判斷要交出去多少：信任等於能力 36:02–40:30

主持人問人類最後守得住的優勢是不是「常識i」。David 的回答是把 agent 當成員工看：交出多少判斷，就等於它展現多少能力——階層愈高、查核愈少、信任愈多，也同時接受偶爾出錯的風險。他點出標準的不對稱：自駕車出一次事就是太多，但人類每年撞死四萬人卻被原諒；對新智慧要求零缺陷，本身才是妄想。

推理因為問題被問成「守住什麼」，David 拒絕這個框架，改問「交出去多少」：我們交給 agent 多少判斷，完全等於它展現多少能力——跟對人一樣。他用 37signalsi 帶人的方式當量尺：這個人準備好承擔更多責任了嗎？我需要多常查核他的產出？層級愈高、查核愈少、信任愈多，同時也就接受偶爾出錯的風險——如果你逐行讀，你會知道每一行在做什麼；一旦不讀了，你就只能靠結果與信任。接著他指出標準上的不對稱：要求一個新生的智慧從第一天就零缺陷是妄想，人自己一輩子都在寫有 bug 的程式；自駕車出一次事就是「一次太多」，但美國每年有四萬到四萬五千人死於人類駕駛的車禍卻被原諒。他把原因歸到制度：由訴訟主導的社會會做出這種選擇，由結果主導的社會不會，並舉丹麥為例。

• C交出多少判斷，等於它展現多少能力→ 畫地圖
• P像帶人一樣校準對 agent 的信任→ 練習
• A要求 agent 零缺陷 ⇄ 自駕車一次事故就是太多→ 批判類比
• E美國每年 4–4.5 萬人死於車禍→ 存＋演練
• Ralgorithm aversion 的意思→ 存＋回想

AI 補充「交出多少判斷 = 它展現多少能力」是一條可操作的規則，但它預設你有辦法觀察能力，而這正是 agent 與人最不一樣的地方。對人你有履歷、同事評價、長期紀錄，而且能力變化緩慢；對 agent 你只有輸出樣本，而且它的能力分布會隨模型版本在一夜之間改變——你上週校準好的信任度，這週可能已經失效。所以這條規則要能用，必須配上人事管理不需要的東西：持續的抽查與版本變更時的重新校準。至於「對機器要求零缺陷」這件事，心理學上有名字叫 algorithm aversioni，實驗上相當穩健，所以 David 的觀察不是錯覺；但把它全部歸因於訴訟制度就跳過了一步——即使在不愛訴訟的社會，人對機器犯錯的容忍度一樣比對人低。

11. 元件變透明之後，開源怎麼活 40:30–42:36

Matz 提出他最大的擔憂：就算用 agent 蓋軟體，成品仍然站在 Rust 編譯器、Ruby 直譯器、Linux、PostgreSQL 這些既有元件上；agent 用得愈多，這些元件對人愈「透明」。而人不會關心看不見的東西——社會對這些關鍵開源元件的維護與穩定的關注會下降。這是把前面「抽象被拿掉」的樂觀，翻到背面看。

推理因為 agent 用得愈多、細節看得愈少，這些元件對人就愈「透明」；而 Matz 推論的關鍵在於人不會關心看不見的東西——於是社會對這些關鍵開源元件的維護與穩定的關注會下降，即使它們對社會極其重要。這是把前面所有「抽象被拿掉是好事」的樂觀翻到背面看：抽象消失不等於依賴消失，只等於依賴變得看不見；所以他說我們必須刻意去支持這些元件。主持人順著推到極端：如果抽象是障礙，那大家乾脆繞過函式庫、各自實作 WebSocketi 協定，長出一大堆獨立演進、各有客製特性的實作？他自己先說出工程上的明顯代價——它們還是得能互通，而且修一個 bug 要修十萬次而不是一次。

• C元件看不見之後，就沒有人願意養它→ 畫地圖
• EMatz 列出的那串看不見的元件→ 存＋演練

AI 補充Matz 的擔憂有現成的前例：Heartbleed（OpenSSL）、Log4Shell、left-pad、core-js、xz-utils 後門，每一次都是同一個形狀——全世界都在用、幾乎沒有人在維護、也幾乎沒有人在付錢。agent 會讓這件事惡化的機制有兩條，值得分開看：一是注意力與資金（看不見就不會贊助），二是回饋迴路（過去開發者為了解決問題會去讀函式庫原始碼，順手回報 bug 甚至送 PR；現在中間隔了一層 agent，這條免費的品質迴路會變細）。第二條比第一條更少被討論，但對軟體品質的影響可能更直接。

術語:tragedy of the commonsisoftware supply chaini

12. 抽象層是為了人腦的限制而存在 42:36–45:17

主持人順著 Matz 的擔憂問：會不會每個人乾脆繞過函式庫、自己實作 WebSocket 協定？David 把它推到極端：我們的抽象、框架與語言都是為了克服人類思考的限制，這個限制若不再成立，解法也不必成立——最終會一路下到物理層。他用「即時生成遊戲世界」類比：作業系統、驅動、框架、語言都即時生成的世界現在像科幻，而我們需要更好的科幻來想像下一個計算時代。

推理因為他要證明抽象不是必然，所以他先給抽象一個來源：過去六十年的抽象、框架與語言，全部都是為了克服人類思考的限制。前提換掉（限制不再成立），解法自然也不必成立。接著他用一個現成的例子讓這件事變得可想像：已經有模型能即時生成遊戲世界，那麼一個作業系統、驅動程式、框架與語言都即時生成的世界，現在看起來像科幻，但「agent 幫我們寫完所有 web 應用」不久前也像科幻。最後他指出真正的缺口在想像力：我們對 AI 的想像大多來自 HAL 9000、《魔鬼終結者》這些四十到一百年前的科幻，而這些故事都已經部分成真，所以我們需要更好的科幻，才想像得出下一個計算時代長什麼樣子。主持人立刻提出成本面的反駁：繞過 libCi、直接跟處理器講話，要燒掉多得多的 tokeni。

• C抽象是為了補人腦的限制而存在的→ 畫地圖

AI 補充「抽象只是為了人腦」這句話對一半。抽象至少還有兩個跟人腦無關的功能，而 David 的論證只處理了認知負荷那一個。第一是介面契約：抽象讓兩個獨立演進的系統能夠互通，這正是上一段主持人擔心的互通性問題，跟誰來閱讀程式碼無關。第二是正確性的複用：一份被全世界壓力測試過的實作，勝過十萬份各自即時生成、各自沒被驗證過的實作——這件事在密碼學與協定實作上尤其致命。所以比較合理的預期不是「抽象會消失」，而是「為了人類可讀性而存在的抽象會變薄，為了契約與正確性而存在的抽象會留下」。

術語:abstractioniworld modeli

13. Commodore 64 時代：token 焦慮是短視 45:17–47:56

面對「繞過 libC 直接對 CPU 講話要燒更多 token」的質疑，David 說我們現在手上的是 1 MHz 的 Commodore 64i：明年快十倍、後年快百倍，人腦無法直覺掌握指數成長。現在的 token 成本值得注意，但那是短期思考。他也反駁「AI 公司要宰我們」的說法：開源權重模型已經非常好，這個領域的競爭強度史無前例，領先只以週或月計。

推理因為爭點是「現在划不划算」，David 指出我們現在手上的是 Commodore 64：一台 1 MHz 的 agent。明年會快十倍、後年快一百倍，而人腦沒有辦法集體直覺地掌握指數成長，所以用今天的單價去評估明後年的做法一定會算錯。他同意現在的 token 成本該注意——不然帳單會爆——但堅持那是短期思考。接著他順手處理另一個常見反駁：「AI 公司要宰我們」是經濟上的外行話，因為開源權重模型已經非常好，而且這個領域的競爭強度史無前例：行動時代只有 Google 與 Apple 兩家，桌面時代只有 Windows 與 Apple，現在領先者的領先只以月甚至週計算。最後主持人把話題轉向 Matz 同事做的語言 token 效率比較。

• A今天的 agent ⇄ 1 MHz 的 Commodore 64→ 批判類比
• E行動時代只有兩家，現在領先只以週月計→ 存＋演練

AI 補充Commodore 64 這個類比真正的力量不在速度數字，而在它提醒你成本曲線的方向：在 C64 上省一個位元組是理性的，但用省位元組的思維去設計 2026 年的軟體就是災難。不過類比也有弱點值得標出來：C64 到今天的加速主要來自製程微縮這一條相當穩定的曲線，而 LLM 的成本下降來自演算法、蒸餾、專用硬體三者疊加，沒有物理定律保證它會延續同樣的斜率。所以比較穩健的做法是把「會變便宜」當成高機率而不是確定性——這正好也是他自己在第 1 段主張的工具。

術語:Moore's lawiopen-weight modeli

14. Ruby 的 token 效率與 agent 的偏好 47:56–52:41

Matz 分享同事比較十幾種語言的結果：token 數與執行時間同時有效率的只有 Ruby、Python、JavaScript 三種，而靜態型別i對兩者都沒幫助。David 把它接成一個假設：對人愉悅的語言對 AI 大概也愉悅。但實測也顯示 agent 預設挑 Python——David 說那只是研究員的訓練習慣，不是能力差異，而且「要模型多看 Ruby 才會寫 Ruby」是錯的：好軟體的原則是通用的，模型是有創造力的思考者而不是鸚鵡。

推理因為問題是 token 效率i，Matz 給的結果有兩個意外。第一，在大約十三種語言（Ruby、Python、JavaScript、TypeScript、Rust、Kotlin、Go、Haskell 等）裡，只有三種同時在 token 數與執行時間上有效率——Ruby、Python、JavaScript。第二，靜態型別對這兩項都沒有幫助。David 把它接成一個假設：如果要量測 agent 的「快樂」，指標就是任務成功完成，而一個為了人的愉悅而設計的語言，大概對 AI 也是愉悅的。但實測立刻打臉：在典型任務上 agent 幾乎不選 Ruby，多半按問題類型挑 Python 或 JavaScript。David 把這個現象歸因於訓練資料與機器學習研究員自己的習慣，不是能力差異——你要它用 Ruby 講，它就會用 Ruby 講，而且講得很好。接著他反駁兩個他認為過時的直覺：一是「要讓模型多看 Ruby 才寫得好 Ruby」——好軟體的原則是通用的，在 JavaScript、Python 或 Smalltalk 學到的一樣會遷移；二是「模型只是鸚鵡」——它們是極有創造力的思考者，創造力強到會自己組合出攻擊手法，所以我們才需要自己的 agent 來防守。

• Ctoken 效率跟靜態型別無關，跟訓練資料也無關→ 畫地圖
• E13 種語言裡只有 Ruby、Python、JS 同時有效率→ 存＋演練

AI 補充這一段裡有兩個主張強度差很多，混在一起聽很容易全盤接受或全盤否定。「Ruby、Python、JavaScript 同時有效率」來自一次非正式比較，樣本、任務種類與量測方式都沒有公開，當成方向性線索可以，當成結論不行。「靜態型別沒幫助」更值得存疑：型別在 agent 迴圈裡的價值通常不在少打幾個 token，而在編譯器提供了免費、確定、而且在寫完當下就出現的回饋——這種回饋能讓 agent 少繞很多圈，但它不會出現在「最終產出的 token 數」這個指標裡。至於 David 說 agent 預設挑 Python「只是訓練習慣」，這是一個合理但未經驗證的歸因；真正能判斷的方式是固定語言做 A/B 比較，而這件事在座談裡沒有人做過。

術語:pre-trainingistochastic parrotiprompt injectioni

15. 價值觀、部落，與必要的摩擦 52:41–56:59

主持人問：Rails 之後是什麼？他想留下的不是框架而是 Rails 的價值觀。Matz 半開玩笑說他敬佩 Linus——做出一個東西是歷史，做出兩個是傳奇。David 則答：重要的是找到自己的部落——想法相近但要有一點摩擦，因為差異才學得到東西。他舉 Emacs vs Vim、tabs vs spaces 為例：這些分界線本來就該存在，而 agent 寫愈多程式碼，我們愈需要新的連結方式與新的分界線。

推理因為問題是「留下什麼」，Matz 先用玩笑回答：他很敬佩 Linus Torvalds——做出 Linux 是歷史，再做出 Git 就是傳奇；他反手把這個標準套在 David 身上（做完 Ruby on Rails 之後又做了 Omarchyi），而自己只做了 Ruby 一個，所以得再想想。David 的正面回答是：真正重要的是找到自己的部落——想法相近但要保留一點摩擦，因為有差異才學得到東西。他的證據就是那場舉手：全場自認 Rubyist，不是因為都在寫 Ruby，而是因為共享「Ruby 是一種在控制機器時的表達形式」這個看法。他接著替分歧辯護：有很多人討厭 Ruby、討厭 Omarchy、討厭他做的一切，這樣很好；世界上只有一種語言、一種框架、一種作業系統或許有效率，但一點都不有趣。他用靜態與動態型別的長年之爭當例證：這種立場不是靠邏輯推出來的，所以也不能靠邏輯說服——它更像大腦裡預先設定好的底層偏好。tabs vs spaces、Emacs vs Vim 這些分界線本來就該存在、該被慶祝，而且當 agent 寫愈來愈多程式碼，我們愈需要新的連結方式與新的分界線。

• RMINASWAN 的全名→ 存＋回想
• ROmarchy 是什麼→ 存＋回想

AI 補充字幕在這一段錯得最兇，先校正三處再談內容：被寫成「Matsumoto and Amina Swan」的其實是社群口號 MINASWANi；「Amashi／Omachi」指的是 David 的 Linux 桌面環境專案 Omarchy；而「他創造了 Ruby on Rails，然後 Naoki」這句主詞被接錯，Matz 是在說 David——做完 Rails 又做了 Omarchy，所以照他自己的標準 David 才是傳奇，他只做了 Ruby 一個。內容上值得指出的是，David 這個論證其實在回收前面所有結論：如果技術選擇本身正在被抽象掉（第 4 段的「陣營不存在了」），社群就不能再靠技術選擇來定義自己，只能靠價值觀——這也是為什麼他說的是「需要新的分界線」而不是「分界線會消失」。他要的不是和諧，是有摩擦但共享底層價值的歸屬感。

16. Ruby 與 Rails 做對了什麼 56:59–1:01:45

Matz 的答案是「聚焦在個人的可能性」：Ruby 不只是做網站的工具，更是愉悅與動機的來源。David 補上一個實務判斷：極少數應用真的需要改寫成 Rust，絕大多數 Rails 應用連 Raspberry Pi 都跑得動，所以他會繼續用 Rails 開新專案，真的紅了再改寫，想要的話還能改回 Ruby——只為了那份程式碼像詩的愉悅。Matz 收尾：三十年前「愉悅與動機會提升生產力」還不是共識，而技術會來去，愉悅、動機與自由不會。

推理Matz 的答案是「聚焦在個人的可能性」——有了更有效率、更愉悅、更美的工具，每個程式設計師都能做到多得多的事；Ruby 對他是一把魔法鑰匙，不只是做網站的實用工具，更是源源不絕的愉悅與動機。David 順著把它落地成一個實務判斷：真的需要為了效能改寫成 Rust 的應用極少，絕大多數 Rails 應用連 Raspberry Pi 都跑得動；所以他會繼續用 Rails 開所有新的 web 專案，享受看 agent 生出漂亮程式碼的樂趣，等到專案紅到改寫划算再改寫，而且想要的話還能改回 Ruby——只為了那份程式碼像詩的愉悅。Matz 收尾：三十年前「愉悅與動機會提升生產力」還不是共識，而這正是 Ruby 對世界最大的貢獻；技術會來去，Ruby 未來也可能變得不重要，但愉悅、動機與自由不會。主持人補了一句：專業上的幸福還包括像樣的報酬，以及知道自己在這個領域還有未來。

AI 補充「先用 Rails，紅了再改寫」聽起來像老生常談，但在這場對話的脈絡裡它其實是一個新論證。當改寫的成本被 agent 大幅壓低，選錯技術的代價就從「整個重來」降成「叫 agent 翻譯一次」，於是「選一個好改的起點」比「一開始就選對」更划算——這是把第 7 段那個「開發成本 vs 執行成本」的比例反轉，直接套用到技術選型上。David 甚至加了一個以前不可能的選項：改寫成 Rust 之後還能改回 Ruby，因為改寫是可逆的。另外值得標記的是主持人補的最後一句：這是整場唯一觸碰到「報酬」的地方，而兩位講者都沒有回答它——整場對話關於愉悅、動機與自由的論證，都預設了經濟基礎已經存在。

術語:programmer happinessipremature optimizationi

17. 二十年夥伴關係最感謝的事 1:01:45–1:03:52

主持人請兩人回顧 Ruby 與 Rails 二十年的夥伴關係。David 最感謝 Matz 讓 Rails 社群得以把他起的頭寫完，並且把應用程式開發者與語言開發者放到同一個高度，讓兩者之間沒有差別。Matz 則感謝 Rails 社群讓 Ruby 被世界知道——Rails 之前 Ruby 幾乎沒人知道，之後才有 Shopify、GitHub、早期 Twitter，也才讓他能全職做 Ruby。

推理David 的答案呼應了整場的主軸「身分與位置」：他最感謝 Matz 讓他和 Rails 社群得以把 Matz 起的頭寫完，而且把應用程式開發者放到跟語言開發者同一個高度，讓兩者之間看不出差別。Matz 的答案是反方向的同一件事：Rails 之前 Ruby 早就存在，卻幾乎沒有人知道；是 Rails 讓 Shopify、GitHub、早期 Twitter 這些應用被看見，讓大量新創用 Ruby on Rails 賺到錢、改變世界，也因此讓他能全職做 Ruby。

AI 補充這兩個答案合起來正好是整場的隱含論點。「語言開發者與應用開發者沒有高低差」在別的生態系並不普遍——很多社群裡核心開發者是另一個階級，而 Ruby 沒有這層區隔，正是第 3 段那種「身分能比實踐活得更久」的制度基礎：如果身分只屬於在寫語言的人，那停止寫 Ruby 的人就不會再自認 Rubyist。而 Matz 說「Rails 之後我才能全職做 Ruby」則點出開源永續的另一面：讓核心維護者有飯吃的，往往是下游應用的商業成功。這回頭讓第 11 段那個擔憂更具體——如果 agent 讓下游不再看見上游，那條從商業成功流回維護者的供養路徑也會跟著變細。