這篇導讀整理自 AI 101 的原始影片。影片取材自 DHH 第二次上 Lex Fridman Podcast 的談話：Rails 作者、37signals 共同創辦人 David Heinemeier Hansson，重新談他對 AI coding 的看法。
值得注意的是，這不是一個「AI 萬歲」的宣傳片。它有趣的地方在於，說話的人不是原本就站在 AI 浪潮中心的創業者，而是長期以工藝、簡潔、獨立思考聞名的工程師。DHH 的轉向因此更像一個症狀：當連最重視手寫程式手感的人，都開始把 AI agent 當成日常工作方式，我們討論的就不只是工具效率，而是「寫程式」這件事本身的位置變了。
010. 一個懷疑者把冷水喝回去｜DHH 的轉向為什麼有代表性
AI 101 在開頭用了很戲劇化的說法：DHH 十三個月前還在 Lex Fridman 的節目上對 AI 潑冷水，十三個月後回到同一張桌子，等於把那盆冷水自己喝回去。這種敘事當然有剪輯效果，但它抓到了一個真實張力：DHH 的身份讓他的轉向不容易被輕易歸類成追風口。
DHH 不是缺少工程能力的人，也不是一直靠抽象管理離程式碼很遠的人。他寫 Ruby on Rails，長期主張小團隊、簡單架構、反過度工程，對軟體工藝有很深的個人投入。因此他說 AI 改變了自己的寫程式方式，重量和一般「我用 AI 補 code 變快」不太一樣。
影片裡最關鍵的分界，不是模型又多聰明一點，而是 DHH 對自己角色的描述改變了。早期 coding assistant 像副駕，工程師仍然握方向盤；到了 agentic coding，他更像把目的地、問題和偏好說出來，系統開始提出路線、拆任務、寫程式，而人類主要負責選擇、監看、品味和驗收。
這不是工程師被完全拿掉，而是工程師從「每一行都親手加工」移到「判斷哪條路值得走」。這種轉移對老派工程師尤其刺耳，因為手寫程式不只是勞動，也是身份。DHH 的可貴之處，是他沒有把這種不舒服藏起來。他承認震動，也承認自己玩上癮。
021. GPS 隱喻｜從駕駛者到路線評估者
DHH 在訪談中用了 GPS 的比喻。早期 GPS 比紙本地圖方便，但你仍然要很專心，因為它可能把你帶到奇怪的地方；後來定位、路況和路線品質變好，使用者就逐漸不再盯著每一步，而是信任導航。
這個比喻適合描述 AI coding 的心理變化。剛開始用 AI 寫程式時，我們會盯著每一段 output，像看一個實習生有沒有亂來。它可能補錯 API、誤解架構、用不合 repo 風格的方式解題，因此人類必須一行行查。那時候 AI 是快一點的打字機，也是錯誤放大器。
但當模型、工具、上下文和測試迴圈一起成熟，體驗會變成另一種東西。人類不再只是問「這行 code 對不對」，而是問「這條實作路線是不是好」。agent 會探索 codebase、提出方案、修改檔案、跑測試、讀錯誤、再修。這時候工程師的注意力被重新配置：少一點機械輸入，多一點方向判斷。
這裡要保留一個重要界線。GPS 變好，不代表司機永遠不用負責；AI agent 變強，也不代表工程師可以把生產系統丟給模型自生自滅。DHH 的說法比較像是：在某些任務上，逐行手寫已經不再是主要瓶頸。真正稀缺的是問題定義、架構直覺、驗證方法和審美。
032. 手藝沒有消失，位置改變了｜25 年經驗變成品味與約束
影片最容易被誤讀的句子，是 DHH 近兩個月幾乎沒有親手寫出貨程式碼。這句話很有衝擊力，但它不等於「經驗不重要了」。恰恰相反，agent 越能產出大量程式碼，人類越需要知道什麼該留下、什麼該砍掉、什麼看似可行但會在半年後變成維護成本。
手藝在這裡從「手部動作」變成「判斷力」。一個寫了二十五年程式的人，不只會打字。他知道哪些 abstraction 太早，哪些 naming 會讓團隊誤會，哪些依賴會讓部署變脆，哪些測試能真的保護行為，哪些只是讓 CI 看起來綠。AI 可以生成候選方案，但這些判斷仍然來自長時間和系統相處的經驗。
所以更準確的說法不是「AI 拿走了手藝」，而是「AI 拿走了一部分手藝的表現形式」。過去好的工程師透過手寫 code 表達品味；現在品味也可以透過 prompt、review、測試設計、工具邊界和最後取捨表達。工具改變了手藝的媒介，但沒有取消手藝本身。
DHH 對 Ruby 的態度也能說明這點。他不是突然否定 Ruby，也不是說 Rails 的價值歸零。相反地，他把 Ruby 放進一種類似騎馬的比喻：有車可以代步，不代表騎馬沒有樂趣；只是騎馬不再是最快到達目的地的方法。寫 Ruby 仍然可以是美感、身份和快樂，但它可能不再是所有商業軟體開發中最有效率的核心動作。
這對工程文化會有影響。未來「親手寫」可能更像木工、黑膠、底片或復古遊戲開發：不是沒有價值，而是價值從生產效率轉向修養、樂趣、限制美學和深度理解。這不是壞事，但它要求工程師誠實面對：自己懷念的到底是解決問題，還是某種熟悉的自我形象。
043. Vibe coding 不是終點｜DHH 真正在談的是 agentic engineering
影片裡提到 vibe coding，很容易讓人以為重點是「用自然語言叫 AI 做 app」。但 DHH 的興奮其實不只在快速 prototype，而在 AI agent 開始能承接更長的工程迴圈。
vibe coding 的典型問題，是它很快做出表面，也很快讓人進入修補泥淖。你描述一個畫面，模型吐出一堆 code；你說哪裡壞了，它再補一堆；幾輪之後，產品看似前進，內部卻越來越難懂。這種模式適合探索，不適合當成長期工程方法。
agentic engineering 的差別，在於它不只生成，而是把生成放進流程。它要能讀現有系統、理解架構、產生計畫、用小步修改、跑測試、查錯誤、保留 decision record，必要時停下來問人。這些能力不是靠一句神奇 prompt 解決，而是靠工具鏈、repo context、測試文化和權限設計一起支撐。
DHH 的 GPS 隱喻在這裡再次有用。真正成熟的導航，不是單純畫出一條路，而是知道即時路況、替代路線、目的地限制和使用者偏好。成熟的 coding agent 也一樣：它需要知道這個 repo 的風格、部署方式、資料模型、測試邊界、不能碰的區域，以及人類在乎的品質。沒有這些，AI 只是在高速產生不確定性。
因此，這支影片對團隊最實用的啟發不是「大家都去 vibe code」，而是「把 agent 放進可驗證的工程流程」。如果你沒有測試、沒有清楚的架構說明、沒有 code review 標準，也沒有權限邊界，那 AI 只會把原本混亂的流程加速。反過來說，若團隊本來就重視小步提交、清楚介面和自動驗證，AI agent 會更快變成槓桿。
054. 英文變成新的程式語言｜但這不是英文能力的勝利
影片末段有一句很容易流傳的話：現在的語言是 English。這句話聽起來像老梗，但在 AI coding 裡確實有新的重量。當工程師透過自然語言描述需求、限制、風格、測試和取捨，自然語言就成了操作軟體系統的高階介面。
不過，把它理解成「英文好的人會贏」太表面。真正重要的不是英文，而是規格化思考。你能不能把模糊需求拆成可檢查的條件？你能不能描述想要的架構而不是只描述畫面？你能不能指出什麼叫做完成、什麼風險不能接受、哪些既有模式要延續？這些能力用中文也可以表達，只是目前模型和工程工具的共同語境仍然高度英文。
這會讓工程師的能力重心稍微往產品、設計和系統思考靠近。過去一個需求模糊的人，仍然可以靠長時間手寫慢慢摸出答案；現在 AI 會把模糊需求迅速放大成大量產物。需求越不清楚，產物越像幻覺的堆積。相反地，能把問題說清楚的人，會得到更穩定的 agent 協助。
所以「English as code」背後真正的變化，是人類意圖變得更接近可執行物。prompt 不只是聊天，而是設計 brief、任務規格、測試準則和審查清單的混合體。未來的工程師不一定更少寫 code，但會更常寫「讓 code 被正確生成、修改與驗證的語言」。
065. 最值得帶走的不是焦慮，而是重新分工
DHH 的轉向之所以讓人焦慮，是因為它碰到工程師最深的自我認同：如果連 Rails 之父都說自己不太手寫 code，那我們多年累積的手感還剩什麼？
比較健康的答案是：剩下更多，但形式不同。手感會轉成 review 的速度、拆任務的精準度、對架構壞味道的敏感、對產品取捨的直覺、對測試的要求，以及知道什麼時候該把 agent 停下來。AI 讓某些技能的市場價值下降，也讓另一些原本隱性的能力變得更明顯。
這也是為什麼 DHH 的案例不該被讀成「工程師完了」。它更像是在說，工程師如果只把自己定義成打字和記 API 的人，確實會被快速擠壓；但如果把自己定義成能把問題變成可靠系統的人，AI agent 反而可能擴大他的半徑。
最後，這支影片最有意思的地方，不是 DHH 從反對變支持，而是他沒有把懷舊和進步做成二選一。他可以承認手寫 Ruby 仍然快樂，也可以承認大部分商業開發正在被 agent 改寫。這種誠實比口號有用：你可以喜歡舊手藝，同時學會新的生產方式。
對正在寫軟體的人來說，真正的問題也許不是「AI 會不會拿走我的手藝」，而是「我的手藝能不能移到更高一層」。如果答案是可以，那麼從手寫工匠變成 agent 導航員，不一定是失去，也可能是下一種專業。