懂程式，反而可能妨礙你用 AI：DHH 的 13 個月翻轉
Ruby on Rails 創造者 DHH 在 13 個月內，從親手雕琢程式碼轉向管理約 16 個並行代理任務。他改變的不是技術標準，而是經驗放置的位置。
David Heinemeier Hansson 自述跟電腦打了約 40 年交道，也親手寫了約 25 年程式。到了 2026 年，他卻在 Lex Fridman 面前承認，這份經驗一度讓他吃虧。
「有一段時間，我其實覺得自己懂得太多程式設計，反而成了負擔。」DHH 說，他會指示 AI 代理（AI agent）完全照自己的方法實作，代理也確實做得很好。
這讓他用 AI 更快地重做自己原本就會做的事，也限制了代理自行找路的空間。
這句話容易被剪成「工程師不如外行」，訪談的完整語境卻窄得多。DHH 談的是自己的工作方式，以及一小段能力快速變化的時間。
程式知識沒有失效，失效的是把每一步都先替代理決定好的習慣。
這位 Ruby on Rails 的創造者，長年把簡潔、可讀、容易修改的程式碼視為一門手藝。當主要實作者逐漸從人換成代理，他開始重新計算，自己幾十年累積的經驗應該放在哪一層。
13 個月，兩種工作方式
兩次訪談之間，約隔了 13 個月，DHH 卻形容它們像發生在不同時代。2025 年的訪談裡，他花了很大篇幅談 Ruby 的美感、程式設計者的幸福，以及親手把概念壓縮成漂亮程式碼的樂趣。
當時的 AI，對他比較像一名效率更高的助手。它可以回答問題、查找資料、陪他討論，仍沒有改變他和電腦之間的情感連結。
他依舊親手雕琢程式碼，AI 只是站在旁邊加快原有流程。
約 13 個月後，Lex 一開場便問他，這段期間究竟發生了什麼。DHH 從對 AI 寫程式的能力持保留，轉成讓代理大量參與實作，而且轉變並非來自某句宣傳口號。
他真的把代理放進工作，讓它們操作工具、檢查成果，再把可以交付的程式碼帶回來。
DHH 並非突然否定自己過去的信念，他先看到工具跨過一道可用門檻，接著才重寫自己的工作方式。這段順序，讓他的轉變比「AI 將改變一切」多了一層可以檢驗的細節。
2025 年 11 月 24 日，成了他的分界線
DHH 把 2025 年 11 月 24 日視為個人分界點，那天也是 Anthropic 正式發布 Claude Opus 4.5 的日期。他記得自己大約在 26 日試用，交給模型幾項任務，發現輸出品質「驚人地接近」自己會寫出的版本。
他記得自己往椅背一靠，腦中浮出一句話，「剛才到底發生了什麼？」依照他的描述，變化未必只來自模型變聰明。代理已經能操作電腦、呼叫工具、檢查自己的成果，把能力轉成一段端到端的工作流程。
在此以前，他使用 AI 的方式仍以加速為主。人決定目的地、路線和施工方法，代理負責跑得更快。
Opus 4.5 之後，他開始願意合併代理寫出的程式碼，也能從過程看出它大致沿著合理方向前進。
這是 DHH 的個人分界線，並非整個軟體產業共同選出的紀念日。模型是否在那一天跨過門檻，每個人的答案也會不同。
工具能力一旦改變，舊流程卻可能不會立刻跟著更新。
面對新工具時，人很容易把它塞進熟悉職位。把代理當成速度更快的初階工程師，就會交給它詳細工單，再逐步指定檔案、函式和實作方法。
這能產生短期效率，也可能把代理的新能力關在舊流程裡。
專業，怎麼變成路徑依賴
DHH 把自己的轉變分成兩個階段，第一階段由他指定做法。他利用多年經驗，把自己會走的路完整描述給代理，這種工作方式也很有生產力。
此時，代理的價值是更快抵達同一個答案。
到了下一個階段，他發現自己可以只描述問題與預期結果，讓代理提出實作路徑。有些任務裡，這種做法會得到比程式設計師預先指定路線更好的方案。
他也承認，自己晚了一點才跟上這個變化。
若借用產品決策的說法，這種風險可以理解成過早收斂。熟悉某套技術的人，看到問題時通常已經浮出一條解法。
他知道要改哪個模組、呼叫哪個函式、如何拆分資料，提示也會自然寫成實作步驟。
代理收到這些步驟後，會努力完成被交代的路線。它可能看不到另一個更短的實作，也沒有理由挑戰提問者的前提。
結果可以很正確，解法空間卻在第一行提示裡就被縮小。
這不表示規格應該永遠模糊，安全要求、相容條件、效能門檻與不可觸碰的範圍，仍要清楚寫出來。Lex 在訪談裡也提出反駁，良好的系統設計、嚴謹思考、驗證與安全測試，依然需要技術理解。
他逐漸放掉的，是把「目標」和「方法」綁在一起。他傾向先讓代理做出一個可以操作的版本，再透過使用發現需求。
這個做法延續敏捷開發的想法，人往往要看到、摸到一個產品，才知道自己需要的是什麼。
程式經驗仍然有用，只是位置往上移了一層。它可以用來界定限制、辨認風險、比較架構、設計驗收，也可以在高風險領域深入閱讀實作。
若把經驗全用來逐步遙控代理，仍能提高生產力，卻可能錯過代理自行規劃路徑的額外價值。
「軟體就是產品管理」
Lex 接著把問題推得更遠，他問，是否存在某些問題，程式設計師使用代理的表現會比非程式設計師差。DHH 回答「百分之百」，隨後立刻縮小範圍，許多程式設計師並不擅長產品管理。
把這句回答放回語境，就不能擴大成所有工程師的排名。DHH 指的是某些人、某些問題，也說相關能力並未平均分布在所有程式設計師身上。
他列出的能力，包括產品該做什麼、要為誰服務、體驗如何呈現、優先順序怎麼排，以及第一版應該包含哪些內容。
當代理接手大量實作，人必須先回答這些產品問題。使用者的痛點若定義錯了，代理可以非常有效率地完成一個沒有人需要的產品。
第一版範圍若失控，更多產出也只會帶來更多檢查與重做。
DHH 還提到比較方案差異，人不一定能憑空寫出完美方案，卻很擅長從少量選項中挑出偏好的版本。讓代理提出 3 個方向，再比較它們的取捨，可能比一開始寫出一份鉅細靡遺的規格更接近實際使用。
對創業者來說，可以嘗試的產品比以前更多。不會寫程式，已經不必然等於無法做出可用軟體。
然而，使用者為什麼願意改變習慣、哪個痛點值得解、什麼功能應該先捨棄，仍沒有因為生成速度變快而自動出現。
對開發者來說，產品判斷也不再只是產品經理的工作。當代理可以產出更多程式碼，能否把模糊需求轉成可驗證目標，會直接決定這些產出的價值。
會寫程式仍是一項優勢，前提是別讓這項優勢遮住了問題本身。
漂亮程式碼，仍然算得出經濟價值
DHH 過去強調漂亮程式碼，背後除了美感，也有實際的維護成本考量。架構一致、容易理解的系統，讓小團隊能持續修改軟體，降低新增功能時破壞其他部分的風險。
如果未來主要由代理修改程式碼，這筆投資的回報可能下降。DHH 在訪談裡說，他仍會仔細看 Ruby 程式碼的細節，只是這份仔細帶來的經濟回報正在快速遞減。
這個問題仍未有定論，也不能用來宣告品質已經不重要。
他也給出明確但書，目前的詞元（token）、上下文和預算仍然有限。架構混亂會迫使代理重新理解更多內容，也會讓下一次修改變貴。
第一個普通的變更堆上幾次修改後，很容易形成難以維護的混亂架構。
因此，漂亮程式碼沒有突然失去作用。清楚的架構可以減少代理重新理解上下文的成本，衡量方式也跟著改變。
可預測的結構、明確的邊界與容易測試的設計，仍能節省後續迭代成本，只是人未必還要親手雕琢每一行。
回到實際工作，DHH 也沒有完全停止閱讀實作。他說，在某些領域，檢查完整程式碼仍然能帶來價值；另一些實驗則刻意當成黑箱，只從使用者角度測試成果。
這種分級，遠比「以後不用懂技術」更接近他的真實工作方式。
訪談裡也有一場不順利的實驗，37signals 曾讓設計師直接使用代理替 Basecamp 5 寫功能。個別程式碼變更一度看似合理，累積起來卻破壞了系統架構，最後仍由人手清理。
DHH 說，那是 2026 年 2 月的經驗，工具後來已有變化。這個反例仍顯示，大型既有系統的技術脈絡不能輕易省略。
約 16 個並行任務，人的注意力成了瓶頸
工作方式改變後，DHH 的桌面也跟著變了。依照他在訪談中的自述，他會讓約 4 到 5 台電腦同時運作，維持大約 16 個並行代理任務。
代理跑得越快，他能同時管理的任務反而越少。
這組數字是受訪者自陳，不能當成經過外部驗證的產能指標。DHH 自己也提醒，用程式碼行數衡量成果是愚蠢的。
產出很多，沒有回答究竟做出了什麼，也沒有證明成果可以交付。
他的 Neovim 還在，角色已從主要施工現場變成專案瀏覽器。他用它查看變更與周邊脈絡，也會讓不同模型交叉審查。
代理負責產出之後，人要處理的工作變成分派、回應、比較、否決與驗收。
這套配置揭露了下一個限制，運算可以擴充，人的注意力很難同步增加。約 16 個任務都可能回來要求決策，速度越快，切換成本越高。
團隊缺的，可能從「誰能把它寫出來」移向「誰能及時判斷這是不是該做的東西」。
經驗，開始用在另一個位置
DHH 的 13 個月翻轉，沒有給所有開發者一張通用處方。它比較像一場高強度的個人實驗，展示當實作能力突然變便宜，舊專業會如何重新分工。
開發者可以保留系統理解，把提示的重心移到目標、限制與驗證。產品工作者可以利用更低的實作門檻，快速做出少量方案，接著承擔選擇與取捨。
創業者可以增加試驗數量，也要更早停止方向錯誤的產品。
影片最後，DHH 說自己仍然使用 Neovim，只是現在已經不太寫程式了。從這些做法可以歸納，那約 25 年的實作經驗沒有被清空，它仍在他判斷架構、看出異常、要求品質和選擇方向時運作。
懂程式可能妨礙你用 AI，只發生在經驗被拿來封住答案的時候。當經驗改用來定義問題、建立護欄與驗收結果，它就有了適合代理時代的新用途。
