“In the loop, on the loop, or out of the loop?” — 2026 年 Thoughtworks 的工程師把這個問題提升成了架構決策。 兩篇 martinfowler.com 文章給出了截然不同但互補的框架：Kief Morris 用軟體工程迴圈分析人的正確位置；Dirk Lässig 用控制論把這個問題提升到管理科學層次。
Kief Morris 的迴圈框架：為什麼 “On the Loop” 才是對的
來源：Kief Morris（Thoughtworks），Humans and Agents in Software Engineering Loops，2026-03-04
Morris 把軟體交付描述為巢狀的反饋迴圈：
- Why Loop（為什麼迴圈）：人在想法和運作軟體之間反覆迭代的策略層——「我們在解決什麼問題？這個方向對嗎？」這個迴圈由人跑，因為人才是想要產出的那一方。
- How Loop（怎麼做迴圈）：中間工件（程式碼、測試、spec）的生成和精煉，包含多個子迴圈——這是 agent 可以接管的部分。
三種人的站位：
| 站位 | 行為 | 後果 |
|---|---|---|
| Out of the loop | 讓 agent 完全自主運作 | 品質螺旋下降、方向持續偏移 |
| In the loop | 親自修每個工件，或逐步指揮修正 | 消耗人力，扼殺 agent 的速度優勢 |
| On the loop（推薦） | 建立和管理讓 agent 工作的 harness | 人的精力用在系統設計，不是逐行監督 |
Morris 的核心論點：
「我們人類的正確位置，是建立和管理這個運作中的迴圈，而不是讓 agent 自己跑，也不是微管理每個產出。」
Agentic Flywheel（自我改進的飛輪）：
- 建立 harness（spec、品質檢查、工作流引導）
- 給 agent 豐富的效能訊號（測試、運維資料、用戶指標）
- 讓 agent 建議 harness 改進
- 對低風險建議進化到自動核准
→ 迴圈越跑越緊，harness 自我提升，人的監督從微觀轉向系統層次。
Dirk Lässig 的控制論框架：把 Agent 管理變成系統設計
來源：Dirk Lässig（Thoughtworks），Cybernetics and the “human-on-the-loop” in agentic coding，2026-04-20
Lässig 借用 1940–1970 年代的管理控制論（Cybernetics）為 on-the-loop 建立理論基礎：
- Norbert Wiener（1940s）：控制論基礎——研究複雜系統中的通訊與控制
- Stafford Beer 的 Viable System Model（1970s）：以五個遞歸控制系統組織複雜環境中的可行系統；被 Lässig 直接套用到 agentic 開發的組織設計
- Ross Ashby 的 Law of Requisite Variety：「只有多樣性才能吸收多樣性」——人必須在元層次（meta-level）匹配系統複雜度，而不是在操作層次
- Conant-Ashby 定理：有效的系統調節者必須對被調節的系統有足夠的模型
兩種主要的人類控制工具：
| 工具 | 方向 | 機制 |
|---|---|---|
| Attenuation（衰減） | 過濾多樣性、減少需要人處理的複雜度 | 儀表板、例外警報、聚合指標 |
| Amplification（放大） | 擴展人類影響力到整個系統 | 編碼化的政策、知識庫、分散式控制 |
三個具體實踐：
- Harness Engineering：在 agent 多樣性外圍建立結構化框架（與 Morris 和 Böckeler 的框架 互相交叉）
- Gemba / Go See：定期深入查看實際程式碼，驗證感測器準確性、更新心智模型——不能只看儀表板
- Double-Loop Learning：不只修正效能問題，也質疑底層假設本身（「我們的評估標準是否仍然正確？」）
Böckeler 的技能清單：什麼真的不能被取代
來源：Birgitta Böckeler（Thoughtworks），The role of developer skills in agentic coding，2025-03-25
Böckeler 用三個影響層次組織 agent 在哪裡容易出錯，反推出人必須保留的技能：
即時開發層（Time to Commit）
- 問題診斷與除錯（識別 agent 走進死胡同的時機）
- 「何時放棄 AI 方向」的技術判斷——不是感覺，是基於理解
團隊工作流層（Iteration Level）
- 理解增量交付模式
- 根因分析 vs 快速修補的區別（agent 偏向快速修補）
- 早期識別被誤解的需求——agent 不會主動質疑需求的正確性
長期可維護性層（Codebase Lifetime）
- 測試設計與測試放置的策略
- 程式碼模組化與可重用性
- 識別不必要的複雜度（agent 傾向加複雜度，不傾向減少）
- Design pattern 辨識和依賴結構
個人護欄：code review 紀律、判斷何時中斷 session、結對編程、對「看起來快得可疑的解法」保持懷疑。
組織護欄：Sonarqube / Codescene 的程式碼品質監控、pre-commit hooks、記錄「出錯日誌」（documented go-wrong logs）、自訂規則配置、建立心理安全的文化讓人不怕舉報 AI 問題。
主張 vs 可佐證
- 可佐證：Böckeler 的技能清單來自 Thoughtworks 工程師的直接觀察；Morris 和 Lässig 的框架都有明確的知識系譜（控制論有完整學術基礎）；「out of the loop 品質會螺旋下降」被多個 Thoughtworks 案例和 arXiv 研究印證（多 agent 錯誤放大效應）。
- 主張：Agentic Flywheel 的自我改進特性是預測性框架，目前缺乏公開的大規模實施數據；控制論框架（VSM）在 AI agent 管理的有效性是類比，未經系統性驗證；「哪些技能最先被取代」的時間線是工程意見，不是研究結論。
- 收斂結論：三個框架指向同一個結論：工程師的角色從「寫程式碼的人」演變為「設計和維護讓 AI 可靠工作之系統的人」。 這不是降級，是工程重心的轉移——從操作技能（coding）轉向系統設計技能（harness design, context curation, quality sensing）。
來源：
- Humans and Agents in Software Engineering Loops — Kief Morris (Thoughtworks), 2026-03-04
- Cybernetics and the “human-on-the-loop” in agentic coding — Dirk Lässig (Thoughtworks), 2026-04-20
- The role of developer skills in agentic coding — Birgitta Böckeler (Thoughtworks), 2025-03-25