本文整理自 Patrick Debois（DevOps 一詞的發起人，現任職於 Tessl）的演講：Coding Agents Don’t Scale Themselves. Neither Do Your Teams.。
這場演講刻意避開了大家最愛談的「怎麼把 agent 用得更好」，轉而回答一個更少人正面處理的問題：當 coding agent進入組織，團隊、平台和組織本身會發生什麼變化？
Debois 的切入點很有說服力。十多年前，他推 continuous delivery時，所有人都說這太瘋狂、在我們這裡行不通。今天他聽到一模一樣的話，只是對象換成了 dark factory（暗燈工廠：高度自動化、人幾乎不介入的軟體生產）。他認為這些話背後真正的訊號不是「技術做不到」，而是「我們還沒準備好」。
以下依照他的三個層次（團隊、平台、組織）整理論點，最後附上我的分析。
1. 起點：Dark factory 是組織問題，不是技術問題
Debois 的整場論述建立在一個前提上：假設你的組織終究會走向某種形式的自主運作（autonomous work）。
他承認現在的 conference 充滿了 loop（自動迭代迴圈）、harness（執行框架）、context engineering（情境工程）的優化技巧，這些都很好，但他的判斷是：這些終究會變成商品。 總有一天，某個 frontier lab會直接把這整套打包成服務賣給你。到那時候，「我們的 harness 比較厲害」不會是你的差異化。
所以真正該問的不是「怎麼讓 agent 更強」，而是當 agent 的能力變成基礎設施之後，你的組織準備好用它了嗎？
這裡他引用了 Conway’s law（康威定律）：組織結構與工具之間存在互相塑形的關係。導入 coding agent 不只是換工具，它會改變協作的動態、團隊的儀式、平台的責任，以及組織的授權方式。
2. 團隊層次（一）：工程師的身份危機，與「修系統不修 code」
2.1 「我們不是來寫 prompt 的」
主流敘事說開發者會變成 agent 的指揮者、編排者（conductor, orchestrator）。Debois 認為這個方向大致沒錯，但他親耳聽到很多工程師的反應是：我們沒有簽約做這件事。 寫更好的 prompt、寫更好的 spec——這不是工程師想要的工作，於是產生了認同上的摩擦。
Context engineering 的出現稍微緩解了這點：prompt 要測試、要評估、要分發、要優化，總算有一點工程味。但很多開發者還是覺得空虛。
真正的轉折發生在團隊開始做 harness 和 loop 的時候。突然間，一條新的技術路徑打開了：為 agent 建工具、幫 agent 加能力、用程式的方式約束 agent 的行為。那些原本覺得「這不是給我的」的工程師，一下子重新找回了認同感——他們有這方面的知識，他們做得來。
Debois 的觀察是：大家一直在談抽象化、抽象化、抽象化，但工藝（craft）其實在新的位置上長出了更多工程的空間。
2.2 善用懷疑者
有人問他：團隊裡那些對 AI 很懷疑的人怎麼辦？他的回答是，這些人正是最適合去改善 context和 harness 的人。
他們抱怨 vanilla coding agent（未經任何客製化的原生 agent）產出的品質很差？好，那就請他們把所有的知識放進 context 裡，讓結果變好。把那股不滿和懷疑，轉化成改善系統的動力。
2.3 最大的心態轉變
如果 Debois 現在要給一家公司的工程師一個建議，會是這句：停止修 agent 產出的 code，改為修產生 code 的系統。
他引用 Swyx 幾年前的說法：stop building the thing, build the thing that builds the thing。不管你用的是 context、harness 還是 loop，重點都是把思考層次從「這段 code 哪裡錯了」拉高到「系統為什麼會產出這樣的 code」。
很多人還停在自動補全與單次 prompt 的層次，這些人需要被推一把，進入系統思維。
2.4 工程實踐沒有過時
目標是把人的介入降到最低，但仍然要維持好的工程實踐。
一開始大家說 vibe coding（氛圍式寫程式）真棒，下個 prompt 就有結果。但現在我們看到的是，除了告訴 agent 做什麼，我們也在告訴它：請寫測試、請更新文件、請遵守規範——所有我們對好工程師的要求，現在都在對 agent 說。
如果團隊裡還有人用 YOLO 的方式亂衝，Debois 的建議很直接：叫他們停下來。工程實踐不只是為了讓人能維護系統，也是為了讓 agent 能持續變好。
3. 團隊層次（二）：儀式變質、team lead 的新角色、下游擠壓
3.1 Retro 和 planning 談的東西變了
在比較成熟的團隊裡，Debois 看到一個有趣的變化：儀式還在，但談的內容不一樣了。
- Retro：以前談「我們的 code 哪裡出了問題」，現在談「我們的系統哪裡出了問題」。典型的對話是：agent 一直在同一個地方撞牆，我們能不能修系統？這是 retro 要學到的東西。
- Planning：工作出現了明顯的分流。那些範圍定義得夠清楚的事，agent 可以直接接手，而且 harness 越好，能接的越多。剩下留給人的，是那些範圍還不清楚、需要團隊一起討論決定的事。
換句話說，planning 變成了一個分類動作：這些直接進 agent，這些要人開會談。
3.2 Team lead 要設定節奏
開發者有一條學習曲線：先學 prompting，再學寫 spec，然後是 context、harness、loop。整個產業也在走同一條路。
Debois 認為 team lead 的責任是在這條曲線上設定節奏與約束。例如明確宣告：「現在起停止手打 prompt，把 context 做成可重用的。」做到了，再推下一步。
他特別強調：「你們自己去摸索吧」這種做法是行不通的。團隊需要有人給出方向和節奏。
3.3 下游跟不上
當團隊的產出速度提升，第一個遇到問題的是下游：GTM（go-to-market，市場推廣）、業務、甚至使用者都跟不上。
所以 harness 不能只停在 coding。它必須延伸到下游的人，用自動化幫他們跟上節奏。同樣的問題也出現在上游——需求的輸入可能不夠快，餵不飽團隊，這條工作流也需要被接上。
4. 兩個指標：Human touches（人工介入次數） 與 Reuse（重用）
市面上有很多指標——token 用了多少、產出了多少——但 Debois 說他開始相信的只有兩個。
| 指標 | 衡量什麼 | 預期方向 | 它反映的是 |
|---|---|---|---|
| Human touches | 為了讓 agent 做對事情，人還需要介入幾次 | 持續下降 | context、harness、guideline 的品質 |
| Reuse | 一個改善被多少人、多少團隊重用 | 持續上升 | 從個人到共享系統的擴散程度 |
Human touches 很直覺：harness 越好、context 越完整、guideline 越清楚，人需要出手的次數就越少。
Reuse 則是他認為真正的乘數效應所在。他特別區分了兩種「乘數」：
- 不是「一個人變成 10x 工程師」的那種乘數。
- 而是「修一次，所有人都受益」的乘數——一個針對 agent 的優化，影響到組織裡每一個使用它的人。
這就是從 solo 走向 shared system 的意義。你可以從團隊內部開始：在同一個 repo 裡共享 context、一起打造 harness。但最終你會想把這件事擴散出去——而這就進入了平台團隊的領域。
5. 平台層次：Paved roads、registry、成本可見
5.1 平台團隊有了新功課
平台團隊是組織裡典型的「共享」單位，但 Debois 觀察到他們可能還沒意識到自己的角色正在擴大。他們習慣處理的是基礎設施、雲端、MCP gateway這類東西，而現在有一批新題目正在冒出來：
- Skill registry（技能註冊中心）：誰維護、怎麼發現、怎麼版本化
- 針對 context 的 eval系統：怎麼知道一份 context 是好是壞
- 專為 coding agent 設計的 guardrail
- Agent 的身份與權限（identity）
這些題目需要有人 own。但該是平台團隊，還是 developer experience團隊？平台團隊通常不做開發，DX 團隊又不擁有基礎設施。Debois 承認這中間需要某種混合，但他的底線很清楚：必須有一個 owner 在推動這件事，而不是每個團隊各自為政。
5.2 為什麼要 paved roads（鋪好的路）
理由很簡單：為什麼每個團隊都要重新發明「怎麼跟 agent 說明我們的認證系統」？這是共享元件，應該放進 registry。為什麼每個團隊都自己建 harness？如果大家用的是同一套 linter、同一套安全工具，那 harness 也是可重用的。
這和當年雲端平台的 paved path（標準化路徑） 是同一個邏輯：把共通的東西中央化，讓採用變成最省力的選擇。
5.3 避免 sprawl
但如果任何人都可以把東西丟上 repo，很快就會變成一團亂（sprawl，蔓生）：他有一個 skill、另一個人 fork 了一個類似的，我該用哪個？
解法是為每個領域指定 owner，而 owner 的責任包括：
- 讓它可測試
- 讓它模組化，別人可以擴充（例如擴充 context 或 harness）
- 做安全掃描
這和「我在組織裡隨手分享一個東西」是完全不同的等級。
5.4 共識很難，所以是目錄不是單一答案
Debois 坦承，要兩個開發團隊對「我們怎麼工作」達成共識，需要大量的溝通與協調——有時候感覺就像 tab vs. space 之爭。
所以實際的結果通常不是一條路，而是三、四條維護良好的 paved roads 組成的目錄。團隊可以從中挑選，也可以走自己的路——但那是用自己的預算。中央維護的那幾條，才是設計來讓採用變得容易的。
5.5 讓成本可見
如果團隊盲目地使用，他們不會知道代價。但如果把成本視覺化，他們就會有動機去優化。
舉例來說：如果能減少 agent 跑完一件事需要的迭代次數，那就是一個可執行的優化。但如果看不到迭代次數，只看到最終結果，就不會有人去做這件事。讓這些數字可見，是平台團隊的工作。
5.6 從 solo 到 multiplayer
總結這一段：Debois 主張組織應該從個人開發者，走向團隊共享的 context 與元件，再走向組織層級的 multiplayer system。乘數效應會在最後一層發生，因為改善會透過飛輪往多個方向擴散。
6. 組織層次：授權、招聘、支出、團隊規模
6.1 不要再辦 champions program 了
再往上一層，VP Engineering 會問：我要怎麼讓整個組織動起來？
Debois 說他可以預測你的組織會怎麼做：辦 hackathon、辦 lunch & learn、分享成功案例、開一個共用的 Slack channel、設 champions program（種子推手計畫）。他的評語是：這些都是通用的轉型劇本，換成 agile 轉型也是這樣做，換成 DevOps 轉型也是這樣做，跟 AI 沒有關係。
另一方面，我們也知道「買授權、辦教育、百花齊放」的策略是行不通的。
他主張的做法是：把 mandate（授權）給 team lead 和平台團隊，讓他們去做前面描述的那些事。這不是一個個人開發者能完成的事。
6.2 招聘：職稱沒有意義，用三關來看人
想從外部找人幫忙？Debois 說這是一團混亂。AI product engineer、deployed engineer、agentic engineer、AI engineer——這些新職稱什麼都不代表，因為沒有人真的在這件事上成熟。職稱頂多是個訊號，讓有意願的人看到你的職缺，但不是能力的驗證。
他從多數公司聽到的面試做法分成三關：
- 先看 AI 運用：給候選人一個練習，鼓勵他們盡全力用 AI 解題。能借多少力，就看多少。
- 再看工程判斷：通過之後做 walkthrough，請候選人解釋發生了什麼、為什麼這是好的做法。這一關考的是 taste（品味）和工程功力。
- 最後看協作：願不願意分享？開放還是獨行俠？這呼應了前面「可分享、可重用、工程等級」的整套思維。
他特別提醒：不要把這三項綁在一起貼上 junior或 senior的標籤。一個人可能在第一項很強、第二項需要 mentoring。你要找的不是念過 ML 的人，也不是 coding 專家，而是這三項的混合。
6.3 優化支出，不要封頂
VP 必須為這筆投資辯護。「我們買了 X 張授權」、「交付變快了」（難以證明）、「品質變好了」（也難以證明）——這些論述都很弱。
前面的兩個指標在這裡派上用場：你可以展示 human touches 的下降曲線、展示 reuse 的擴散程度。這比「有 AI vs. 沒有 AI 的生產力比較」好證明得多。
當有人說「廠商收費太離譜了，我們要限制支出」，Debois 說你的反射動作不該是封頂，而是優化支出：教大家挑對模型、給他們更好的 context 和 harness。這些做法本身就會讓成本下降。
6.4 團隊規模：還是回到三到五人
小團隊 vs. 大團隊的辯論一直存在。一人全包當然是終極夢想，但 Debois 算了一筆帳：
- 一個全能的人，通常還是要搭一個互補角色（PM、設計）
- 兩個人其中一個休假怎麼辦？需要備援，變三個
- 誰顧 production 和進來的 ticket？可以是同一批人，但會犧牲 feature 的速度
- 還要有一個 junior，讓他學什麼叫做好
所以他的結論是：我們還沒走到每個團隊只有一兩個人的程度。實驗很多，但現階段還是要持續投資在教育上。
7. Dim factory 與知識護城河
7.1 不是 dark，是 dim
Debois 在結尾把 dark factory 收斂成一個更務實的說法：dim factory（半暗燈工廠）。
不是所有 feature 都會自動化。你要決定的是：對哪些 feature，你願意承擔多少風險？這形成一個光譜，一端是事事微管理，另一端是全自動核准、相信一切都正確。你要在光譜上選一個位置，而不是非黑即白。
當你決定往自動化多走一點，就要在另外幾件事上多投資：
- Provenance（來源追溯）：誰改了這段 code
- Verifier（驗證器）：檢查這段 code 是不是真的有用
- Situational awareness（情境感知）：出事的時候，能不能快速掌握狀況
7.2 護城河（moat）是知識
既然 agent 的能力會商品化，差異化在哪裡？Debois 的答案是：你捕捉下來的知識。
那些你放進 skill、放進 context、放進 harness 的東西——你的業務脈絡、你對 agent 的約束方式——這才是別人拿不走的。
7.3 從 continuous delivery 到 continuous learning
對 Debois 來說，這把 continuous delivery 帶到了 continuous learning（持續學習）。
問題不再是「我們多久能部署一次」，而是「我們多快能把新東西換進來、把舊東西換出去」——這是你的反應能力。如果能持續改善這件事，最終的目標就不是讓整個系統更可靠，而是：在改動更多系統的同時，還能保持可靠。
8. 分析與評論
這場演講的價值，在於它刻意不談 agent 技術本身，而把焦點放在組織設計。以下是幾點觀察。
8.1 這是 DevOps 故事的重演——既是優點也是疑點
Debois 開場就用「當年大家說 continuous delivery 很瘋狂」來對照 dark factory。整場演講的骨架——paved roads、平台團隊、讓成本可見、別靠 champions program——幾乎是 DevOps 與平台工程劇本的直接移植，只是把「部署管線」換成了「context / harness / skill」。
這正是它有說服力的地方：這套劇本已經在雲端轉型上驗證過一次。但也留下一個可以質疑的點：agent 的非確定性，會不會讓這個類比出現裂縫？ 部署管線是確定性的，跑一百次結果一樣；agent 不是。同一份 context、同一套 harness，在不同的模型版本、不同的任務上表現可能差很多。這對 registry 的治理、對 eval 的設計，都是雲端時代沒有的新難題。Debois 點到了 eval 系統的需求，但沒有深談。
8.2 Conway’s law 被點名，但沒展開
他說工具和組織結構會互相塑形，但後面主要是從「平台中央化」的角度談。真正有趣的問題是：agent 會不會反過來改變團隊邊界該怎麼切？
如果 agent 能跨越原本需要多個團隊才能處理的技術棧，feature team的定義會不會改變？如果 planning 變成「清楚的進 agent、不清楚的留給人」，那團隊的 backlog本身是否該重新設計？這是最值得接續探討的方向，也是跟 LeSS 這類組織設計框架最有對話空間的地方。
8.3 兩個指標是最實用的帶走物，但要先定義
Human touches 和 reuse 比 token 消耗、比「有無 AI 的產出比較」都更能對焦在「系統有沒有變好」，而且天然對齊「修系統不修 code」的心態。這是整場最可操作的建議。
不過 human touches 的定義是模糊的：一次 code review算不算一次 touch？修改 spec 算不算？在 planning 階段把任務拆細算不算？實際落地之前，團隊必須先對「touch」達成共識，否則數字沒有意義。
8.4 對工程師身份危機的回應是少見的洞察
多數談 AI 轉型的內容假設工程師會順勢變成 orchestrator。Debois 誠實指出很多人不想，而他的解方不是說服，而是把工程能量導向「為 agent 建系統」。這對實際推動採用的人非常有用——它給了懷疑者一個有尊嚴的位置。
8.5 弱點：多數建議停在原則層
幾個地方只點到就過：
- 下游（PM、GTM、需求端）跟不上的問題，只說「harness 要延伸過去」，沒說怎麼延伸。
- 「誰 own 平台這件事」承認很難，但沒給出組織設計上的建議。
- Dim factory 的風險分級只是概念，沒有判斷標準。
這些留白一部分是演講時間限制，一部分也是他自己承認的：他正在建一個網站收集 agent enablement pattern，還在向聽眾徵求案例。換句話說，這是一份 playbook 的草稿，不是完成品。
9. 結語：帶走的三件事
Debois 自己說，如果只有一個 takeaway，那就是：贏的不會是 solo player，而是在每個層次都持續改善組織的人。
如果把整場演講壓縮成三句話：
- 修系統，不修 code。 把注意力從 agent 的產出，拉高到產出這些東西的 context、harness 和流程。這是個人層次的心態轉變，也是整場演講的地基。
- 量 human touches 和 reuse。 前者告訴你系統有沒有變好，後者告訴你改善有沒有擴散。別再比較「有 AI vs. 沒 AI」。
- 授權 team lead 和平台團隊。 百花齊放不會成功，champions program 是通用劇本。真正能讓改善擴散的，是有 mandate、有 owner 的中央化 paved roads。
最後一個提醒來自他的 dim factory：你不需要一次走到全自動。決定你願意承擔的風險、投資在追溯與驗證上，然後持續把知識沉澱進系統——那才是別人拿不走的東西。
來源：Patrick Debois，Coding Agents Don’t Scale Themselves. Neither Do Your Teams.，Tessl。
發表迴響