1h03m
Ruby, Rails, and the future of programming - Matz, DHH & Jeremy Daer
Ruby on Rails
4 天前 · 17 段 · YouTube
9/9十個階段都做完了
Ruby、Rails 與程式設計的未來：Matz 與 DHH 對 agent 時代的一場對談
- 用機率取代預測：不知道方向也能行動，押在多個世界都不虧的選擇上
- 人的價值從打字移到品味、比例感與驗收判斷
- vibe coding 不是新東西：資深者一直是提案、別人實作、自己驗收
- agent 要短命行程，所以 JIT 幫不上忙，只能事前編譯（Spinel）
- 抽象消失不等於依賴消失，只等於依賴變得看不見——開源會更難養
術語：
Claude Code coding agent five stages of grief Rubyist software writer software maker taste Spinel …共 47 個接著看 →How a Cloudflare Engineer Ships Production Code He Didn't Write | Dillon Mulroy · 座談談完信任與驗收的原則，這站是實際怎麼出不是自己寫的 production code
確定錯誤／已過時見仁見智（取決於版本或情境）
| 段落 | 原話（transcript 逐字） | 說明 |
|---|---|---|
| 6. 寫程式不再是職涯，能力卻被放大 17:41 |
「as a career, it will be taken away from us in the fairly near future」 | 這是預測而不是已發生的事實，而且 Matz 在同一段裡自己給了限定條件：他說的是多數人會轉向產品與上市，也就是「以親手寫程式碼為主要價值的職位」會縮小，不等於軟體工程職缺消失。把這句話當成既定事實會做出錯誤的職涯決定；合理的讀法是把它當成一個機率判斷，並注意「不久的將來」沒有定義時間範圍。 依據: Rails World 2026 座談現場發言，未提出任何就業資料佐證 |
| 9. Slop、slop grenade 與心理防衛 31:17 |
「The idea that agents cannot write high-quality, original code without bugs is simply a delusion at this point.」 | 這句話把兩個強度差很多的主張綁在一起：「agent 寫得出高品質程式碼」（有相當多證據）與「寫得出沒有 bug 的原創程式碼」（沒有證據支持，而且人也做不到）。David 自己在下一段就承認 agent 會犯錯，所以他真正的意思應該是「不比人差」而不是字面上的「沒有 bug」。把這句照字面採信，會低估驗收與測試仍然必要的程度。 依據: 同一場座談稍後 David 自述「sometimes an agent will make a mistake」 |
| 10. 判斷要交出去多少：信任等於能力 38:33 |
「There are no health compensation claims in Denmark.」 | 字面上不成立：丹麥有全國性的無過失病人補償制度（Patienterstatningen），病人每年提出大量補償申請並獲得理賠。比較接近事實的說法是「丹麥不透過訴訟解決醫療損害」——賠償存在，只是不走法院。這句話在字幕裡還經過機器翻譯，講者原話可能就是「沒有醫療訴訟」；不論如何，用它來支持「有些社會完全不追究」是站不住的，真正成立的論點是制度設計會改變追究的方式與成本。 依據: 丹麥 Patienterstatningen（病人補償協會）自 1992 年起依 Patient Insurance Act 運作 |
| 10. 判斷要交出去多少：信任等於能力 38:52 |
「is about eight times safer than the average person」 | 「自駕約比一般人安全八倍」沒有公認的來源。目前公開資料多半來自業者自行發布、且限定在特定城市與天候的營運範圍內，比較基準（是否含高速公路、是否只算有人受傷的事故、每百萬英里還是每小時）一換，倍數就會大幅變動。方向上「在其營運範圍內比人類安全」有證據支持，但「八倍」應視為他個人引用的粗略數字而非定論。 依據: 講者自述「according to my data」，現場未指明來源 |
| 13. Commodore 64 時代：token 焦慮是短視 45:29 |
「next year we'll have an agent that works 10 times faster, and the year after that, 100 times faster」 | 這是一個具體到可以被證偽的預測，但沒有任何依據被提出。「快十倍」本身也沒有定義：是每秒 token 數、同樣任務的完成時間、還是單位成本？過去兩年單位 token 成本確實大幅下降，但那來自模型尺寸、蒸餾與硬體三者疊加，不是一條可外推的曲線。把它當成修辭上的方向（會明顯變快變便宜）合理，當成規劃數字不合理。 依據: 現場未提出任何效能或價格資料 |
| 13. Commodore 64 時代：token 焦慮是短視 46:40 |
「Anthropic and OpenAI may be leading, but their lead is measured in months, if not weeks.」 | 在公開的能力評測上，前沿模型之間的差距確實常在數個月內被追上，這部分有支持。但「以週計」通常只在單一評測分數上成立，若把資本支出、專用硬體取得、長期記憶與工具整合等一起算，實際落差比分數差距大。這句話是用來支撐「不必擔心被宰」的論點，讀的時候要分清楚是「模型分數的落差」還是「整體產品與成本結構的落差」。 依據: 現場未引用任何評測或市場資料 |
| 14. Ruby 的 token 效率與 agent 的偏好 47:52 |
「static typing doesn't help with either token efficiency or time efficiency」 | 這個結論來自一次非正式的語言比較，樣本與方法都沒有公開，而且量測的是「最終程式碼」的 token 數與執行時間，不是「agent 完成任務所花的總 token 與總時間」。靜態型別在 agent 迴圈裡的主要價值是編譯器提供的即時、確定性回饋，能減少來回嘗試的次數——這一項不在被測指標裡。所以合理的讀法是「型別不會讓最終產物更省」，不能推論成「型別對 agent 沒有價值」。 依據: Matz 自述為同事對約 13 種語言的比較，現場未說明任務集與量測方式 |
![Senior Frontend Interview 2026 🎉 | Javascript 🎯 (Mock) [Most Asked Questions]](https://i.ytimg.com/vi/ySdaBhXbH9U/mqdefault.jpg)
