編輯 | 姜篇
DHH：「I have not written... any of the code.」
DHH：上線到 Quattro 的程式碼，沒有一行是我親手寫的。
說這句話的人，是 Ruby on Rails 之父 David Heinemeier Hansson，開發者更熟悉他的名字 DHH。
備註：David Heinemeier Hansson，開發者通常稱他為 DHH。他是 Ruby on Rails 創辦人、37signals 聯合創辦人兼 CTO。Rails 最初誕生於 Basecamp 的開發過程，後來被 GitHub、Shopify、Airbnb 等大量網際網路產品採用。
一年前，DHH 還不喜歡 AI 補全程式碼，也不願把聊天框嵌進編輯器。
但是在最近發布的 Lex Fridman 訪談中，他給出了完全不同的答案：Onmarchy Quattro 過去兩個月的新增程式碼，已經全部交給 Agent 完成。
緊接著，他講了一段經歷。
一批設計師藉助 AI 提交了大量 PR。單獨看，每個改動都有理由；合在一起，系統架構卻被改壞了。
程式碼生成越來越便宜之後，開發者面對的麻煩並沒有減少。它只是從「怎麼寫出來」，挪到了「誰來判斷、誰來驗收、誰為整體負責」。
以下內容根據 Lex Fridman 對 DHH 的訪談翻譯、整理。
DHH 談 Agent 承擔全部編碼
13個月，他從排斥 AI 走到了「Or 100」
Lex 提到，AI 寫程式碼的佔比已經從 5%、20% 一路走到 80%。DHH 立刻補了一句：
DHH：「Or 100.」
DHH：或者，百分之百。
這不是一句隨口誇張。
DHH 回憶，13 個月前的 AI 程式設計體驗讓他提不起興趣。自動補全打斷思路，聊天框需要人反覆搬運上下文。模型能幫忙，卻仍然像一個需要時刻盯著的助手。
Agent 改變了這套互動。
現在，他會把問題和一個大致方向交出去。Agent 自己讀取倉庫、尋找相關檔案、提出方案、修改程式碼、執行測試，再把結果拿回來。DHH 在訪談裡描述這種變化時，重點不在模型會寫多少語法，而在它開始接管完整任務。
過去，他需要先想清楚「準備怎麼實現」，再讓工具補幾行程式碼。現在，Agent 會反過來告訴他：這件事準備往哪裡走。
DHH 說 Agent 可以走到 100%
兩個月沒親手寫程式碼，他還在逐行審什麼
Onmarchy Quattro 是 DHH 近期投入最多的專案。他說，過去兩個月上線的程式碼沒有一行由他親手敲出。
這句話不是說「程式設計師不用寫程式碼了」。
DHH 沒有退出開發。他看過所有改動的整體形狀，涉及模型層和關鍵業務邏輯的部分，仍會逐行檢查。普通程式碼可以交給 Agent 跑，架構方向、資料約束和關鍵邊界沒有一起交出去。
他的工作台也隨之變化。Neovim 不再主要用來手寫程式碼，而是用來瀏覽專案、查看 diff、核對 Agent 做了什麼。
DHH 的做法可以概括成一句話：實現權可以下放，判斷權不能一起下放。
對普通團隊來說，這條邊界比「AI 能寫多少程式碼」更實用。資料庫模型、權限、計費、並發和資料遷移一旦出錯，測試通過也未必代表改動可以上線。Agent 可以給出實現，人仍要知道哪些地方值得逐行看。
每個 PR 都說得通，系統卻被改壞了
訪談裡最值得警惕的案例，來自 Basecamp 5。
設計團隊開始使用 Vibe Coding 後，提交 PR 的速度明顯加快。每一份 PR 拿出來，都能解釋它為什麼合理；問題出在這些改動之間沒有共同的架構約束。
DHH：這些改動合在一起，把系統架構毀掉了。
DHH 談 Vibe Coding 破壞架構
AI 程式設計很容易製造這種假象：局部完成得很快，整體債務卻在背後累積。
一個 Agent 改登入，一個 Agent 改快取，另一個 Agent 順手抽象公共元件。三個任務都通過測試，不代表它們採用了同一套邊界。重複邏輯、隱性依賴和風格分裂，往往要到後續迭代才會一起暴露。
DHH 沒有因此否定 Vibe Coding。他給出的處理方式很工程化：讓更多人獲得實現能力，同時把架構審查提到更靠前的位置。
過去，架構問題常在 Code Review 裡發現。Agent 並發工作以後，等 PR 全部生成再看已經太晚。任務拆分時就要寫清楚哪些模組不能碰、哪些抽象必須複用、資料如何流動，以及改動之間由誰統籌。
一個人同時跑 16 條 Agent 執行緒，開發者成了總排程
DHH：我最初用 tmux 管理並行 Agent，後來嫌切視窗、等通知太麻煩，又做了 Herdr。它把 tmux 會話和通知接在一起：某個 Agent 需要確認、完成任務或遇到錯誤時，再來叫人。
他的日常規模已經到了 4 到 5 台機器、約 16 條 Agent 執行緒同時執行。
DHH 談同時執行 16 條 Agent 執行緒
這套工作方式看上去很爽，新的瓶頸很快就冒了出來。
當 16 個 Agent 同時產出結果，人不可能逐個即時陪跑。開發者需要先判斷哪些任務可以並行，哪些改動會碰到同一片程式碼，哪些結果必須等前一個任務完成後才能繼續。
並發 Agent 最適合邊界獨立的任務：依賴升級、補測試、生成遷移腳本、清理重複程式碼、調查不同 Bug。涉及同一份狀態或同一套架構的工作，執行緒開得越多，衝突越難收拾。
管理 Agent 也不能只看「完成」通知。每條任務至少要帶回四樣東西：改動摘要、測試結果、風險點和回滾辦法。少任何一項，人都得重新鑽進倉庫補上下文。
別再比誰寫得多，程式碼行數已經失效
Agent 一天可以生成成千上萬行程式碼。繼續拿程式碼量評價工程師，只會鼓勵更多無效改動。
DHH：「lines of code is a stupid metric.」
DHH：程式碼行數是個愚蠢的指標。
DHH 談程式碼行數失去意義
DHH 隨後把評價標準拉回了產品：不要問寫了多少行，先問做出了什麼。
對開發團隊來說，這意味著績效和專案看板都要換口徑。
一個 Agent 生成 5000 行程式碼，最後沒有改善使用者體驗，也沒有降低故障率，這 5000 行只會增加維護成本。另一個工程師刪掉 300 行舊邏輯，讓發布速度提高一倍，價值反而更高。
更合適的指標包括：問題是否解決、變更是否可維護、線上指標是否改善、事故率是否下降、交付週期是否縮短。程式碼是實現這些結果的材料，不是結果本身。
機械式編碼受威脅，會做產品的人仍有機會
DHH 沒有迴避就業問題。如果明天必須重新找工作，他認為自己很難再靠「手寫程式碼」獲得過去那種報酬。這項工作他做了 25 年，如今模型已經能承擔其中越來越多的機械部分。
DHH：「the mechanical process is under threat.」
DHH：機械式編碼這道工序正在受到威脅。
DHH 談機械式編碼受到威脅
但他把「喜歡程式設計」拆成了兩件事。
如果一個人最享受的是手工敲出語法、記住 API 和親自完成每個實現細節，接下來的變化會很難適應。如果真正喜歡的是把東西做出來、解決問題、看著產品落地，Agent 反而讓這件事發生得更快。
DHH 自己就是例子。他早年愛寫程式碼，是因為程式碼能讓程式出現。後來，大型專案、漫長週期和維護工作沖淡了這種即時回饋。AI 讓他重新獲得了快速做出東西的感覺。
開發者的價值不會憑空消失，但會向任務上游和結果下游移動：前面要定義問題、選擇方案、約束邊界；後面要驗收結果、處理失敗、維護系統。
寫在最後
DHH 的轉變很有代表性。
一年前，他不喜歡 AI 補全；現在，他可以讓 Agent 承擔全部新增編碼，同時管理十幾條並行執行緒。但他沒有把軟體交給模型自治，反而把更多精力放在架構、審查和結果上。
手寫程式碼還沒到清零的時候。程式碼仍然要懂，關鍵邏輯仍然要看。只是當實現速度突然提高，開發者的難題已經換了：怎麼把問題講清楚，怎麼讓多個 Agent 沿著同一套架構工作，又怎麼在上線前發現那批「每個都合理、合起來卻危險」的改動。
Agent 可以把程式碼寫完。系統最後長成什麼樣，仍然需要有人負責。