Agentic Engineering 的下一步：2026 之後，工程師還需要寫 code 嗎？
這是「Agentic Engineering 實戰手冊」系列第十四篇。上一篇：團隊導入。後面還有兩篇實戰補充。
Benchmark 進步很快，但不能畫直線預測明年
SWE-bench Verified 的成績曾在一年內快速上升，這件事是真的；問題是 leaderboard 會隨模型、harness、工具與提交規則改變，不能把兩個時間點連成直線，再預測 2027 年會到 95%。
另一個常被引用的比較，是 Scale 在 2025 年 9 月推出 SWE-bench Pro時，頂尖系統在 Verified 已超過 70%，在 Pro 約 23%。這是不同資料集與評測環境的歷史快照，不是今天的即時成績，也不能直接相減成「真實能力差 49%」。
Benchmark 能告訴我們模型在特定題目、工具與規則下的表現，不能單獨回答你的 repo 是否安全可用。Gartner 對 2027 年底超過 40% agentic AI 專案可能取消的預測，談的也是成本、價值與風控，不是 benchmark 正確率。
我不打算做預測，那是 pundit 的工作。作為一個 practitioner，我更感興趣的是：不管 agent 的能力怎麼變，什麼是不變的？
2026 年，哪些事仍要有人負責
經過一年的實戰，我整理出五類不該因 agent 變強就放棄人類 ownership 的工作。Agent 可以參與，甚至做得很好；但責任不能跟著 prompt 一起丟出去。
1. 釐清模糊的需求
「用戶反映登入流程太複雜。」
這句話背後可能意味著 20 種不同的改善方向。人類工程師會去找 PM 問、看 user research、在白板上畫 flow——然後形成一個具體的方案。
Agent 可能追問、整理假設或提出多個方向，也可能直接選一個解釋開始寫。關鍵是有人要確認：它解決的是使用者問題，還是只把句子翻成 code。
Spec-Driven Development 可以緩解這個問題。Spec 可由 agent 起草，但了解使用者與業務的人要確認假設、範圍與驗收。
2. 組織政治與跨團隊協調
「這個 API 改動需要後端團隊同意」、「那個 PM 特別在意 performance」、「QA 組長不喜歡我們用太多 mock」。
有些 organizational context 能被文件化，也能讓 agent 協助整理；但利害關係、承諾與衝突需要當事人溝通，不能只靠模型替團隊協調。
3. 品味與審美判斷
「這個 UX 好嗎？」不是一個有標準答案的問題。
Agent 可以完美實現你 spec 裡描述的每一個細節。但如果你的 spec 沒有描述「這個按鈕在這裡感覺太擠」，agent 不會自己發現。
Agent 可以產生設計選項、做 heuristic review，甚至從使用數據找問題；產品 owner 仍要選擇哪種體驗符合品牌、使用者與當下限制，並為結果負責。
4. 倫理和合規判斷
「這個功能收集了 PII，需要通知用戶嗎？」 「我們的 AI feature 在歐盟受 AI Act 規範嗎？」 「這個 dark pattern 在法律上可以但在道德上該不該用？」
Agent 可以幫你找來源、整理 checklist，但法律、合規與倫理的高風險判斷要由具備職責與專業的人確認。模型不能承擔 accountability。
5. 真正創新的架構設計
Agent 非常擅長 follow 既有的 patterns。你的 codebase 用了 MVC，它就會寫 MVC。你用了 event-driven，它就寫 event-driven。
Agent 也能提出新穎組合或反駁既有 pattern；難的是判斷新方案是否真能在你的限制下成立。創意可以共同產生，架構決策與後果仍要有人承擔。
仍需由人承擔的能力與責任
把以上歸納為四種核心能力：
判斷力
知道什麼該做、什麼不該做。
Agent 可以執行很多事，也可以提供取捨建議；「這件事值不值得做」、「做到什麼程度就夠了」、「誰承擔風險」仍需要負責人決定。
在 agentic workflow 裡，你做的每一個決策的價值都被放大了。因為 agent 會忠實地執行你的決策：好的決策會被高效執行，壞的決策也會。
品味
不是「能不能做」，而是「該不該這樣做」。
好的 API 設計、UX 與 code 結構都需要 taste。Agent 可以在 constraints 內提出方案，但沒有一個客觀的「最優解」保證；constraints 怎麼定、哪個方案符合產品語境，仍需要品味與使用者回饋。
組織 Context
理解公司政治、團隊動態、stakeholder 的優先級。
除非你主動提供，agent 不會知道 CTO 最近在推 microservices、PM 下個月要 demo 給投資人看，或 QA 上週才因為測試不足而處理 production bug。這些組織 context 會直接影響優先級、溝通與取捨。
倫理決策
合規、隱私、安全的最終判斷。
這不只關乎能力，而是 accountability。涉及 ethics 的決策可以有 agent 輔助研究，但責任要落在明確的人與組織流程上。
技能衰退？還是技能轉型？
回到 Post 2 討論過的身份認同議題：用了一年 agent，我的技能有什麼變化？
衰退的能力
- 語法記憶：我已經忘記很多 API 的具體參數了。以前能憑記憶寫出完整的
Array.reduce，現在常常要想一下。 - 手寫 boilerplate 的速度：以前 30 分鐘能寫完一個 CRUD endpoint，現在手寫可能要 45 分鐘（因為不常練了）。
- 某些 debug 直覺：以前看到 error message 就大概知道是什麼問題。現在我傾向先丟給 agent，而不是自己分析。
增長的能力
- 系統設計能力：因為 agent 處理了 implementation 細節，我花更多時間想架構、想 trade-off。設計能力反而變強了。
- 需求分析能力：寫 spec 寫多了，分析和拆解需求的能力提升了。
- Review 眼光：看了一年 agent 的 code，我對 hallucination pattern 的敏感度提高了很多。
- 溝通表達能力：寫好的 spec 就是清楚的溝通。這個技能也提升了。
淨結果
對我而言，目前是划算的交換：部分手寫速度下降，需求拆解與 review 經驗增加。這兩者都只是個人觀察；使用 agent 不會自動把省下的時間變成更好的判斷力。
但我要誠實地說，這讓我偶爾感到不安。有時候同事問我一個 syntax 問題，我需要查一下才能回答，心裡會覺得「以前我是可以秒答的」。
這種不安很正常。退一步看，查 syntax 並不可恥；同樣地，維持足夠的實作與除錯能力也很重要，否則你連 agent 的錯都看不出來。兩邊不必互相貶低。
一份「防衰退」訓練計畫
不管你對未來怎麼看，以下的練習都不會浪費。它們同時鍛練「跟 agent 協作」和「agent 做不到的事」。
8 週循環計畫
Week 1-2：Context Engineering 練習
- 目標：讓你的 CLAUDE.md 的品質提升一個等級
- 練習：review 你的 CLAUDE.md，問自己「agent 重複犯的錯哪些可以靠加一條 rule 解決？」
- 副作用：練習精確溝通的能力
Week 3-4：Spec Writing 練習
- 目標：挑中型以上 task，先寫 spec 再交給 agent；小 typo 不必儀式化
- 練習：用 Goal / Constraints / Verification 格式寫 spec
- 副作用：練習需求分析和拆解的能力
Week 5-6：Review 練習
- 目標：刻意練習找 agent code 裡的問題
- 練習：review agent 的 PR 時，記錄你找到的每一個問題，分類是「邏輯錯誤」還是「事實錯誤」
- 副作用：提升 code review 的效率和敏感度
Week 7-8：理解與除錯練習
- 目標：保持基礎能力的手感
- 練習：每兩週選一個小功能，先自己拆解與除錯；是否完全不用 agent，可依你的學習目標決定
- 副作用：當 agent 出問題時你還有能力自己 debug
持續練習
- 每月一次架構設計：先獨立寫出方案與 trade-off，再請 agent 挑戰假設；避免第一步就被它的框架錨定。
- 定期做能力抽查：挑一段你必須能自行維護的 code，確認自己仍能解釋、測試與 debug；不必為了儀式感硬排 agent-free day。
信任不是一個百分比
第一篇已經修正了一個常見誤讀：90% 的受訪者使用 AI，不等於 90% 在用 coding agent；我也找不到足以支持「只有 29% 信任」的同口徑官方數據。
真正有用的問題不是「你信 agent 幾分」，而是「你願意在什麼條件下，把哪一類任務交給它」。例如：
- 它會 hallucinate（→ 你建了 品質保證流程）
- 它不懂你的專案（→ 你設計了 context engineering）
- 它會亂做（→ 你寫了 spec）
- 它可能搞壞東西（→ 你設了 安全網）
- 它很貴（→ 你做了 成本優化）
這些風險可以用工程方法降低，但不能全部消除。法規、產品方向、供應商故障與未知未知，仍需要人與組織承擔。
Agentic Engineering 不是盲目信任 AI，而是用工程方法建立有根據的信任。
這整個系列教的，就是這件事。
結語：工程師的工作正在重新分配
我不知道 5 年後工程師還需不需要寫 code。老實說，沒有人知道。
我能確定的是，2026 年的工程師可以把更多實作、探索與驗證工作交給工具。對範圍清楚的小型任務，個人確實能做得比以前快；但 60 分鐘案例只是單次紀錄，不能拿來推論「一個人等於一個團隊」。營運、使用者研究、資安與長期維護也不會因 code 產生變快就消失。
Builder 的起步門檻降低了，交付可靠產品的門檻沒有消失。一份好的 spec與 CLAUDE.md能減少 agent 猜測，卻仍需要人 review、測試與做取捨。
Agent 會放大決策的執行速度：方向對時更快看到成果，方向錯時也更快擴大返工。這就是為什麼判斷與護欄變重要，而不是因為人類突然「不可取代」。
所以，如果你問我「工程師還需要寫 code 嗎？」
我的答案是：還需要。你不一定要親手輸入每一行，但必須保有讀懂、修改、測試與除錯的能力，同時知道為什麼要寫、寫到哪裡、出了事誰負責。
前 14 篇從 Agentic Engineering 是什麼 談到 怎麼帶進團隊；後面兩篇再用 TaiwanSalary 與 agent loop 補上實際案例。它們不是放諸四海皆準的方法論，而是我一年使用經驗、官方資料與幾次失敗整理出的工作手冊。
如果這個系列對你有幫助，它之後會整理成書。
不是因為我要賣書，而是因為我相信，工程師需要一份「agent 使用手冊」——不是工具教學，而是方法論。
這份手冊，目前就是這 16 篇。
Takeaway
-
Benchmark 要看資料集、harness 與時間點。Verified 超過 70%、Pro 約 23% 是 2025 年發布時的跨資料集快照，不是今天可直接相減的能力差。
-
需要保留的是 ownership。Agent 可以參與需求、設計、協調與研究，但判斷、品味、組織承諾與倫理責任要有明確的人承擔。
-
防衰退不是固定排一天禁用 AI。定期確認自己仍能解釋、測試與 debug，再用 context、spec 與 review 練習把 agent 納入可靠流程。
