Agent 把「能不能做」變快後，問題回到「該不該做」
Lex Fridman 在 Podcast #501 開場時，把 DHH 過去一年對 AI 的轉變稱為從懷疑到投入；訪談逐段記錄的是一種更具體的工作改變：人不再總是指定每個實作步驟，而是描述問題、判斷結果，並決定哪一條路值得投入。訪談逐字稿，00:02:56
這不代表工程只剩下寫 prompt。DHH 在訪談裡把早期 Agent 使用經驗說成「人仍在駕駛座」：人指定目標、指引查找位置、審閱產出；但他認為較新的模型與 harness 已讓自己能先說明模糊問題，再由 Agent 提出路徑。00:10:37–00:12:09 但這個速度經驗不能直接搬到所有團隊。Omarchy 是 DHH 自己定義成功條件的新專案，能移植的不是「每個人都應該達到 100% Agent 產出」，而是把實作速度提高後，決策品質、邊界與驗證會比打字速度更早成為限制。
DHH 對「vibe coding」的區分，其實是責任分配
DHH 不喜歡「agentic engineering」成為行銷標籤，也把 vibe coding 定義為：告訴 Agent 做出軟體、卻不看實作；相對地，程式設計仍包含理解迴圈、條件與變數等基本原理。00:49:09–00:51:05 這個說法不必被當成職稱資格考，它比較有用的地方在於指出責任沒有消失。
當人不讀每一行程式碼，仍要能回答三件事：
- 結果是什麼？使用者能看到的行為、資料正確性、效能或可用性要如何觀察。
- 哪些約束不能被 Agent 自行改寫？包括資料模型、公開 API、權限、成本上限與既有架構的邊界。
- 誰有權接受風險？測試綠燈不等於產品可發布；涉及不可逆資料、資安或對外承諾時，仍需要明確的責任人。
這三題讓「讓 Agent 做」從一個工具選擇，變成可交付的工程決策。若答案是「不知道」，把任務切小、先做可逆實驗，通常比增加更多 Agent 更合理。
Omarchy 是速度實驗，不是桌面環境教學
Omarchy 很適合當案例，因為它不是抽象 demo。DHH 在訪談中說，Quattro 最近兩個月的程式碼沒有由他手寫；他仍檢視系統 model layer 的關鍵行，卻沒有逐一閱讀部分 UI 與輔助程式碼。00:15:14–00:16:44 訪談也提到，Omarchy 的外掛機制與提供給 Agent 的 skills，讓使用者能把需求做成可分享的延伸。00:47:26–00:48:23
這個案例的重點不是「任何團隊都該把 OS 交給 Agent」，而是 DHH 把產品方向保持在單一且具體的目標：他稱之為打造理想電腦，並讓 AI 的探索集中服務這個結果。約 00:41:00 當取捨有中心，Agent 產生的選項才有尺度可判斷；沒有中心時，快速產生只會快速累積分岔。
Omarchy 的技術棧、安裝方式與系統級 Agent 整合，已在站內的 Omarchy 全景解析 詳談。本文只取其工程意義：高速迭代需要一個能拒絕不相關功能、能判定品質的產品觀點。
小團隊的優勢不是人少，而是訊號不用層層轉譯
在談既有大型產品時，DHH 提出一個值得檢驗的觀察：人開始協作後，瓶頸常常是溝通頻寬，而不是實作；層層 shaping 與核准會耗掉速度。00:18:44–00:20:46 他也提到 37signals 早期讓設計師直接以 Agent 開發，曾累積許多單獨合理、合在一起卻破壞系統架構的 PR，最後得由人手清理。00:16:44–00:17:38
這正好校正「人越少越好」的誤讀。小團隊真正節省的是轉譯：提需求的人離使用情境近，做取捨的人能直接看到結果，修改的人也聽得到同一套優先順序。但架構守門人、驗證與發布責任不會因此自動出現。若每個人都能平行產 PR，卻沒有人維護共同的資料模型、設計語言與刪除權，Agent 只是把協調債務加速送達。
37signals 在 2026 年 8 月的 REWORK #199 到 #201，依序以即席問答、和巨頭競爭與「單向門」談創業與決策；官方節目索引把 #201 的摘要寫成：少數真正不可逆的決策，才值得長時間審議。REWORK #199（8 月 12 日）、REWORK #200（8 月 19 日）、REWORK #201（8 月 26 日） 這個脈絡可轉成很實際的 Agent 規則：把可逆工作交給快速迴圈，把不可逆工作留給明確的人類決策點。
一個「讓使用者能匯出報表」的需求，可以看出訊號轉譯的成本。若它依序經過客服、PM、設計師、工程師與審查者，每次交接都可能遺失不同細節：報表給誰看、允許多慢、要不要保留歷史版本、哪些欄位涉及權限。最後每個人都完成了自己收到的局部任務，產品卻可能交付一個沒有人真正想要的匯出功能。小團隊的優勢是這些人可以直接對話，把判斷留在同一條短路徑上；前提是有人有權把模糊需求退回去問清楚。
Agent 產生的架構債長什麼樣
DHH 提到 37signals 曾讓設計師直接用 Agent 開發，結果累積許多單獨看來合理、合在一起卻破壞架構的 PR。00:16:44–00:17:38 這不是「Agent 寫錯一行」的問題，而是多個局部最佳解沒有共同的邊界。每個 diff 都能通過自己的測試，衝突卻發生在 diff 彼此之間，所以一般逐檔 code review 很容易漏掉。
| 架構債的形狀 | 為什麼局部 review 看不出來 | 需要誰或什麼來攔截 |
|---|---|---|
| 同一資料被新增第二條存取路徑 | 新路徑的測試是綠的，舊路徑也沒有壞 | 指定共同資料模型的 owner，新增邊界前先查現有入口 |
| Agent 各自發明元件與命名 | 每個頁面都能渲染，操作語意卻逐漸分裂 | 維護設計語言與 API 命名的 owner，拒絕同義的新抽象 |
| 遺留路由、旗標與相容分支沒人刪 | 功能仍能工作，刪除責任被下一張卡掩蓋 | 建立有 owner 的刪除任務，沒有期限就不算完成 |
因此，平行開很多 Agent 工作前，先指定少數不能漂移的共享語言：資料模型、權限規則、對外命名與刪除責任。這些東西不是要人手寫完每個檔案，而是要在 Agent 開始前有人能回答「這個變更應該接在哪裡」。同一週內若多人同時改同一個架構邊界，就把它合併成一個有人負責的任務，避免把協調債拆散到十個 PR 裡。
用「決策門」取代無限審查
不是每個 PR 都需要更多會議，但每個高風險變更都該在正確位置停下。可把工作分成三種門：
| 決策類型 | 例子 | Agent 可以先做什麼 | 人必須判斷什麼 |
|---|---|---|---|
| 可逆 | 文案、內部工具 UI、可刪除的測試資料 | 實作、執行檢查、提出 diff | 是否達成使用情境 |
| 可回滾但有成本 | 資料 migration、相依套件升級 | 做 dry-run、整理影響與 rollback | 時機、風險是否可接受 |
| 難以回復 | 對外 API、權限模型、刪除真實資料 | 蒐集證據、產生方案與驗證計畫 | 是否採用，以及誰承擔後果 |
這張表不是流程框架，而是一個停止規則。它避免兩個極端：一是讓人審查每個微小實作細節，二是因為 Agent 看似可靠便把所有寫入權限打開。站內的 Coding Agent 不是自動駕駛 可延伸閱讀權限與證據如何對應；AI-native SDLC：超越程式碼生成 則把這些 gate 放回 plan、build、review 與 deploy 的全程。
把決策門寫成 Agent 看得懂的任務卡
決策門若只存在於人的口頭共識，Agent 仍會把它當成未宣告的偏好。把門檻寫進任務卡，至少要包含四件事：允許修改的路徑、不可做的動作、外部驗證器，以及失敗時如何回復。下面這張卡可以直接放進 issue 或 Agent 的初始上下文，再依專案改名：
task: "新增報表匯出，不改變既有權限語意"
reversibility: "rollbackable-with-cost"
allowed_paths:
- "src/features/reports/**"
- "tests/reports/**"
forbidden_actions:
- "修改公開 API 回應格式"
- "直接寫入 production 資料"
verifier: "pnpm test -- reports"
rollback: "移除 migration 2026_09_05_reports_export，還原 feature flag"
human_gate: "資料 migration 與權限變更須由報表 owner 審核"
receipt:
- "git diff --stat"
- "check-output"
- "changed-boundaries"這張卡的價值不在 YAML 格式，而在於把「完成」從程式碼存在改成證據存在。Agent 交付時應一併回傳 diff、檢查輸出與變更邊界；如果任務碰到公開 API、資料權限或真實資料刪除，就在計畫與證據完成後停止，等待指定的人類責任人決定。這是具名的停止規則，不是再加一層無限審查。
這個結論在什麼情況下不成立
「先清楚決策，再放大 Agent」不是萬用公式，至少有三種情況需要先處理前提：
- 約束沒有被寫下來。如果權限、資料保留期或相容性只存在某位資深工程師的記憶裡，Agent 沒有可查的邊界，速度只會放大猜測。先把約束變成測試、schema 或任務卡。
- 驗證成本高於實作成本。分散式一致性、付款、刪除真實資料等工作，可能幾分鐘就能產生程式碼，卻需要數天才能證明安全。這時瓶頸不是模型速度，而是可觀測性、回滾能力與領域審查。
- 沒有人能拒絕功能。團隊若只有「提出需求」的人，沒有對產品方向與長期維護負責的人，任何決策門最後都會變成勾選表。先指定能說不的 owner，再增加平行工作量。
這些反例不會推翻 Agent，而是提醒我們：要加速的對象必須是已經能被觀察和負責的工作。若連成功條件都無法說清楚，先增加產出量只會讓返工更快。
下一步：先讓決策變清楚
DHH 的訪談並沒有保證每個程式庫都能 100% 自動化。他自己也承認，在已有大量使用者、規模較大的 Basecamp 與 HEY 上，完整的 Agent 加速更棘手。00:15:43–00:16:44 因此可操作的起點不是挑最新模型，而是挑一個可逆任務，先寫下成果、不可碰的邊界、外部驗證器，以及最後拍板的人。
Agent 最適合放大已經存在的清楚判斷。它能縮短從想法到可測試結果的距離，卻不能替團隊決定什麼值得長期維護。下一個可執行的動作，是挑一個可回滾任務，寫出上面的任務卡，指定 verifier 與 human gate，再比較 Agent 交付前後的返工次數。DHH 的 Omarchy 經驗與 REWORK 的小團隊觀點放在一起看，真正稀缺的能力或許不是發出更多指令，而是讓每一次快速產出都回到同一個產品方向，並在需要時果斷說「不做」。
Rails World 2026 的演講把這個轉變帶到 37signals 的實際工作流與 HEY 新架構；我另從 Rails、原生 App 與 Rust 的選擇，整理了停止手寫之後工程責任如何改變。