看了 Dex Horthy (HumanLayer) 在 AI Engineer 的演講 No Vibes Allowed: Solving Hard Problems in Complex Codebases，蠻有料的一場。Dex 就是去年提出 12-Factor Agents 的那位，也算是早期推廣「Context Engineering」概念的人之一。這次他聚焦在一個很實際的痛點: AI 寫程式在 greenfield 很好用，但遇到複雜的 brownfield codebase 就會產生大量 slop(低品質程式碼)，怎麼辦?

以下是影片轉成逐字稿的全文: ihower.tw/watch/no_vibes_allowed…

以下是重點整理:

1. 問題: AI 寫程式的 Slop 危機

他引用了一份針對 10 萬名開發者的調查: 大部分人用 AI 寫程式時，都在做大量的返工(rework)和程式碼翻攪(codebase churn)。看起來產出量變大了，但很多其實是在修上週 AI 吐出來的 slop。

如果是 greenfield 專案(像是做個小 dashboard)，AI 表現很好。但如果是十年歷史的 brownfield codebase，那就… 沒那麼好了。

這跟很多工程師的體感蠻一致的: 太多 slop、技術債工廠、對複雜任務效果不佳。但 Dex 說他們三人團隊花了八週，找到了方法做到 2-3 倍的產出提升而且品質不打折，還因此在 Hacker News 上爆紅。

2. Context 就是一切

Dex 強調一個核心觀念: LLM 是「無狀態」的(stateless)。影響輸出品質的唯一因素，就是你塞進 context window 的東西。Better tokens in, better tokens out。

每一輪工具呼叫，模型都在從上百個正確和錯誤的下一步中做選擇，而決定因素只有 context window 裡的內容。所以要針對四個維度優化 context:

  • 正確性(Correctness): 不能有錯誤資訊 — 這是最致命的
  • 完整性(Completeness): 不能缺少關鍵資訊
  • 大小(Size): 不能塞太多噪音
  • 軌跡(Trajectory): 對話的方向感

其中「軌跡」這個概念蠻有意思的: 如果你一直罵 AI 做錯，AI 看到的對話模式就是「做錯 → 被罵 → 做錯 → 被罵」，那它下一步最可能的 token 就是… 再做錯一次讓你繼續罵。所以與其一直糾正，不如開一個乾淨的 context 重新來過。

3. 「笨蛋區」(The Dumb Zone) 概念

Jeff Huntley 對 coding agent 做了大量研究，結論很簡單: context window 用得越多，結果就越差。

Dex 據此提出了一個「笨蛋區」(Dumb Zone) 的概念: 當 context window 用量超過大約 40% 的時候，模型表現就會明顯下降。

如果你裝了一堆 MCP server 在 coding agent 裡面，光是那些工具定義就把 context 塞到笨蛋區了，那你做什麼事情都不會有好結果。小編覺得這個觀察蠻關鍵的，很多人一直在加 MCP 工具但效果越來越差，根本原因可能就是 context 膨脹。

4. 刻意壓縮(Intentional Compaction)

解法就是「刻意壓縮」: 不管對話進行得順不順利，你都可以讓 agent 把目前的 context 壓縮成一個 markdown 檔案，review 過後再開一個新的 context 接著做。

什麼東西佔 context? 找檔案、理解程式碼流程、編輯檔案、測試和建構的輸出，還有那些 MCP 塞進來的大量 JSON 和 UID…

一份好的壓縮紀錄長這樣: 精確記錄目前在處理什麼、相關的檔案和行號、具體的問題描述。這樣新的 context window 不用重新搜尋和理解 codebase，可以直接接手工作。

5. Sub-agent 的正確用法: 控制 Context

Dex 特別強調: sub-agent 不是用來擬人化角色的(frontend agent、backend agent、QA agent 之類的，拜託別再這樣了)。Sub-agent 是用來「控制 context」的。

具體做法是: 當你要了解一個大型 codebase 的某個部分怎麼運作時，fork 出一個新的 context window 去做搜尋和閱讀，然後只把一段精簡的結論回傳給主 agent。

這樣主 agent 的 context 保持乾淨，不會被大量搜尋過程汙染，可以直接讀一個檔案就開始做事。

6. Research → Plan → Implement (RPI) 工作流

基於以上所有原則，Dex 團隊發展出「Research → Plan → Implement」的三階段工作流，整個流程都圍繞著一件事: 持續保持 context window 在「聰明區」。

🔹 Research 階段: 理解系統怎麼運作、找到對的檔案、保持客觀。用 sub-agent 去做垂直切片式的 codebase 探索，產出一份研究文件。

🔹 Plan 階段: 列出精確的步驟，包含具體的檔名、行號、甚至程式碼片段。計畫要具體到「全世界最笨的模型也不太可能搞砸」的程度。

🔹 Implement 階段: 照著計畫執行，保持 context 最小化。因為計畫已經夠具體了，實作反而是最沒壓力的部分。

7. 實戰驗證: 30 萬行 Rust Codebase

Dex 拿一個 30 萬行的 Rust codebase(程式語言 BAML)來實測: 先做 research，第一輪的 research 是爛的就丟掉重做，然後建立有 research 和沒 research 的 plan 做比較。結果? CTO 隔天看到 PR 覺得沒問題，直接準備合進下一版。

更極端的測試: 他們花了七個小時，對 BAML 提交了 35,000 行程式碼，估算相當於一到兩週的人工工作量。

但也有失敗案例 — 他們試著移除 Parquet Java 的 Hadoop 依賴，結果踩了一堆坑，最後不得不回到白板前面，由人類自己想清楚架構該怎麼拼。這帶出了他整場演講的核心訊息:

8. 不要外包思考

AI 不能取代思考，它只能放大你已經做過(或沒做過)的思考。

一行錯誤的 code 就是一行錯誤的 code。但一行錯誤的 plan，可能導致一百行錯誤的 code。而一行錯誤的 research(對系統運作的誤解)，會讓整個下游全部歪掉。

所以人類的精力應該集中在最高槓桿的地方: review research 和 plan 的品質，而不是去讀每一行生成的 code。沒有完美的 prompt，也沒有銀彈 — 整個流程是建立在你會認真讀 plan、跟 agent 來回確認的前提上。

他也特別提醒: 小心那些幫你產出一堆 markdown 文件讓你「感覺很好」的工具，它們可能只是在製造虛假的安全感。

9. On-Demand 壓縮上下文 vs 靜態文件

Dex 用了一個很棒的類比: 記得電影《乙乙 Memento》嗎? 主角每次醒來都沒有記憶，必須讀自己身上的刺青才知道自己是誰、該做什麼。AI Agent 也是一樣 — 如果你不幫它做好 onboarding，它就會開始自己編故事。

很多團隊的做法是在 repo 裡放一堆 onboarding 文件給 agent 讀。但問題是: codebase 越大，這些文件要不就太長(把 context 塞到笨蛋區)，要不就資訊不足。

更根本的問題是: 這些文件會過期。Dex 秀了一張蠻有趣的圖 — 在實際程式碼、函式名稱、註解、和文件這四層中，「謊言密度」隨著離原始碼越遠而越高。你可以把更新文件變成流程的一部分，但老實說你可能不會真的去做。

他們更偏好的做法是「隨需壓縮上下文」(on-demand compressed context): 每次開始一個任務時，用 sub-agent 對 codebase 做垂直切片式的探索，產出一份基於實際程式碼的研究文件。壓縮的是「真相」(compressing truth)，而不是可能過期的文件。

10. Planning 是槓桿: 心智對齊(Mental Alignment)

Dex 問了一個好問題: code review 的目的是什麼? 不只是找 bug，更重要的是讓團隊所有人對 codebase 的變化方向保持一致 — 也就是「心智對齊」(mental alignment)。

當團隊產出 2-3 倍的 code 時，不可能每一行都仔細讀。但如果有好的 plan，技術主管可以讀 plan 來掌握系統演進的方向和原因，在問題還沒寫成 code 之前就攔下來。

Mitchell 的做法很聰明 — 把 AI 對話的完整過程附在 PR 上，讓 reviewer 不只看到「一堆綠色的 diff」，而是看到思考的路徑和每一步的驗證。這帶著 reviewer 走過一段旅程，是傳統 GitHub PR 做不到的。

Plan 的長度有個 sweet spot: 越長越可靠但越難讀，越短越好讀但可能不夠精確。每個團隊和 codebase 要找到自己的平衡點。

11. Spec-Driven Dev 的語意擴散(Semantic Diffusion)

Dex 引用了 Martin Fowler 2006 年提出的「語意擴散」(semantic diffusion)概念: 一個好的術語被提出後，因為太多人各自解讀，最終變得毫無意義。

「Agent」經歷過這個過程(是人? 是微服務? 是 chatbot? 是 workflow?)，而「Spec-Driven Dev」也正在經歷。有人覺得是寫更好的 prompt，有人覺得是 PRD，有人覺得是 verifiable feedback loops，有人只是在寫 markdown，甚至有人拿來指開源套件的文件…

真正重要的不是名詞，而是背後的原則: 壓縮(compaction)和 context engineering，保持在「聰明區」工作。

12. 不是每個任務都需要完整 RPI

Dex 畫了一個蠻實用的光譜圖: 任務的複雜度決定你需要多少 context engineering。

  • 改個按鈕顏色? 直接跟 agent 講就好
  • 小功能? 簡單 plan 就夠了
  • 跨多個 repo 的中型功能? 做一輪 research 再建 plan
  • 最複雜的任務? 完整的 RPI 流程，可能還要多輪迭代

怎麼知道該用多少 context engineering? 靠練習。你會搞錯，會高估也會低估，但這需要累積經驗。他特別建議: 選一個工具，認真練。不要在 Claude、Codex、Cursor 之間跳來跳去，先把一個用到精通。

13. 下一步: 團隊適應才是真正的難題

Dex 認為 coding agent 的技術面遲早會被商品化，真正的挑戰是: 你的團隊和工作流程要怎麼適應一個 99% 的程式碼都是 AI 寫的世界?

他觀察到一個正在擴大的裂痕: 資深工程師不太採用 AI(覺得沒快多少)、中階工程師大量使用(填補技能落差)、然後資深工程師越來越討厭 AI(因為每週都在清理 Cursor 產出的 slop)。這不是 AI 的錯，也不是中階工程師的錯 — 是文化變革的問題，需要從上層推動。

這場演講最有價值的地方在於它非常「接地氣」— 不是在講 AI 多厲害，而是承認 AI 寫程式會產生 slop，然後給出一套系統性的解法。核心觀念就是: LLM 是 stateless 的，context 品質決定一切，所以整個工作流都要圍繞著 context management 來設計。

「不要外包思考」這句話蠻值得記住的。AI 最大的風險不是寫出爛 code，而是讓人以為可以不用動腦了。Research → Plan → Implement 的價值，正是在於它把人類的注意力導向最高槓桿的環節 — 確認理解對了系統、方向對了，然後才讓 AI 去執行。