很多主管最近都有同一個疑惑：團隊裡最強、平常最愛嘗鮮的工程師，為什麼反而不肯全面交給 AI coding agent？
Thoughtworks 的 CTO Rachel Laycock 在 2026 年 10 月寫了一篇文章回答這個問題。她的結論很簡單：
他們不是怕 AI，是太清楚「做出來」跟「在 production 上跑得穩」是兩回事。
這篇文章把她的觀點拆成六個重點，帶你快速看懂。
一、他們怕的，不是你以為的那些
常見的解釋有兩種：「他們捨不得寫程式」、「他們怕工作被取代」。作者承認這對部分人成立，但她認為背後還有更深的原因。
先釐清一件事：這些人並不排斥用 AI 輔助寫程式。他們遲疑的是把方向盤整個交出去，讓 agent 自己跑完全程。
資深工程師看到 agent 產出的程式，腦中會自動跳出一串問題：
- 行為真的對嗎？
- 模組邊界劃得對嗎？
- 明年還改得動嗎？
- 出事時會發生什麼？
- 別的團隊接得住嗎？
這些問題背後，是一個更大的問題：現在線上幾乎所有系統，都是人手打造的。用 agent 蓋出來的系統，還沒有人跟它「長期相處」過。 既然沒有經驗，就無從判斷該信任它到什麼程度。
作者也提到，她常把同一個難題拿去問 AI，也問資深同事。對於真正棘手的問題，人的回答通常更有用——因為他們會質疑前提，會認出十年前踩過的坑。這種用事故換來的判斷力，正是遲疑的工程師想保護的東西。
二、一場「不准人寫程式」的實驗
Thoughtworks 歐洲區 CTO Giles Alexander 找來資深工程師、基礎設施顧問和產品人員，花一週做一個航空公司系統。規則只有一條：所有程式都由 agent 寫，人一行都不碰。
實驗的目的不是證明「一週做得完」，而是觀察：當 agent 包辦所有程式碼，人的工作會變成什麼樣子？（結果完成約 80%，做過專案的人都懂這個數字代表什麼。）
三個有趣的發現：
- 約 2/3 的時間在白板前。 釐清領域、劃分邊界、擬定 agent 看得懂的計畫。人下班了，agent 還在繼續產出。
- 約 1/3 的時間在打造 harness。 也就是圍繞 agent 的回饋機制：測試、契約、架構檢查、交付管線。每學到一點東西，就把它寫回 harness，讓下一輪 agent 做得更對。
- 提交最多功能程式碼的，是產品人員。 不是工程師。
看到這裡，你可能已經開始想重組團隊了。先別急，故事還沒完。
三、系統能跑，build 卻一直是紅的
這是全文最關鍵的轉折。應用程式確實跑得起來，但 CI 經常亮紅燈。換句話說：又是一個「在我電腦上可以跑」的故事。
為什麼這很嚴重？
- 紅燈本來是警報。 它的意思是：停下來、查原因、修好它。
- 紅燈太常亮，大家就麻痺了。 真的出事時，沒人注意得到。
- 檢查不可信，綠燈也失去意義。 你無法從綠燈得到任何安心。
這正是持續整合（CI）推了 25 年想消除的不確定性。
而且不只是這個實驗如此。作者引用 Google 的 DORA 2025 研究：AI 採用程度越高，交付吞吐量越高，但交付穩定性越低。做得更快，也壞得更多。
為什麼會紅？團隊還沒有定論，可能的原因包括：
- 太多 agent 同時工作，互相踩到對方的修改
- 系統還不夠模組化，agent 無法各自負責不同區塊
- 變更進來的速度，超過檢查跑完的速度
這也引發了幾個值得每個團隊思考的問題：
- 測試和程式都是 agent 一起生的，人也不再逐行閱讀，TDD 還扮演什麼角色？
- 驗收測試、契約測試、系統邊界檢查，放在哪裡最能建立信心，又不會太脆弱？
- 放 agent 出去前，要先做多少設計？
- 很多團隊開始把整個 Epic 丟給 agent，而不是一個個 Story。開發是快了，但 CI 管線接得住這麼大的批次嗎？
作者的判斷是：在 agentic 時代，持續交付與 DevOps 很可能迎來一波重新思考。
四、這不是初級雪道，是沒有地圖的野地
作者用滑雪來比喻。
小孩學滑雪，常常一點都不怕就衝下坡。就像從沒把系統放上 production、也沒在半夜三點接過 on-call 的新手。
成年後才學滑雪的人則不同。他們也想滑，但會先想到「摔斷腿怎麼辦」。資深工程師就是這種人。
但 Martin Fowler 看完草稿後，指出這個比喻有個破綻：
| 初級雪道 | Agentic 開發 | |
|---|---|---|
| 前人經驗 | 無數人安全滑到底 | 幾乎沒人走完全程 |
| 該學什麼 | 教練很清楚 | 還沒人知道 |
| 回饋速度 | 很快，摔了就知道 | 很慢，甚至沒有 |
所以更準確的比喻是：穿越一片沒人畫過地圖的野地。
一個大量由 agent 打造的系統到底可不可靠，要等它在 production 跑一陣子、改過幾輪之後才會知道。一句話：蓋好了，不等於能在 production 上運作。
這也是為什麼作者反對主管把這些工程師貼上「不好奇」、「落後者」的標籤。他們不是在大家都會滑的初級道上發抖的新手，而是在未知地形前問「路線對不對」的人。
該做的不是叫他們少擔心一點，而是讓他們加入畫地圖的那支隊伍。
不過作者也很公平地提醒：經驗也可能讓人太依戀熟悉的做法。有些在「整理過的雪道」上學到的技巧，到了野地未必管用。
五、主管與工程師，各有一份功課
作者最後把挑戰丟給雙方。
給主管：
- 分辨清楚：哪些是「有價值的顧慮」，哪些是「單純抵抗改變」
- 給實驗真正的空間：時間，以及允許做錯
- 不要用「agent 產出了多少程式碼」來衡量成功
給工程師：
- 把你的經驗帶進實驗裡，而不是站在場外
- 準備好接受：有些你深信的假設，可能已經不成立
有些熟悉的實踐會變得更重要，有些則需要換一種形狀。而且，沒有人會先把地圖交到你手上。
六、五句話帶走
- 資深工程師不是怕 AI，而是不敢放開方向盤。
- 用 agent 蓋的系統，還沒有人長期維運過，信任無從建立。
- 人的工作重心，正從鍵盤移向白板與 harness。
- 能跑不等於能上線：CI 紅燈與 DORA 數據都在提醒我們，穩定性正在流失。
- 謹慎不是障礙，而是畫地圖最需要的能力。
帶著你的謹慎出發吧。
原文：Rachel Laycock，Why are good developers so wary of agentic development?，martinfowler.com，2026 年 10 月 29 日。
發佈留言