写了40年代码的开发者说经验反而拖了AI使用后腿

懂程式，反而可能妨礙你用 AI：DHH 的 13 個月翻轉

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 回答「100%」，隨後立刻縮小範圍，許多程式設計師並不擅長產品管理。

把這句回答放回語境，就不能擴大成所有工程師的排名。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，只發生在經驗被拿來封住答案的時候。當經驗改用來定義問題、建立護欄與驗收結果，它就有了適合代理時代的新用途。