Agentic Engineering 的下一步：2026 之後，工程師還需要寫 code 嗎？

這是「Agentic Engineering 實戰手冊」系列的最後一篇。上一篇：團隊導入

一年前 49%，現在 72%，明年呢？

一年前我開始 100% AI coding 的時候，SWE-bench Verified 的最高分是 49%。寫這篇文章的今天，最高分已經超過 72%。

一年之內進步了 23 個百分點。如果保持這個速度，2027 年就會接近 95%。

但別急著恐慌（或歡呼）。因為更嚴格的 SWE-bench Pro，最好的 model 也只拿到 ~23%。JetBrains 的 DPAI Arena 和 Stanford 的 Terminal-Bench 也顯示類似的模式——agent 在「乾淨的、有限範圍的」問題上進步飛速，在「混亂的、需要廣泛 context 的」真實世界問題上進步緩慢。

72% 跟 23% 之間的落差（Gartner 預測 40% 的 agentic AI 部署會在 2027 年前被取消）告訴我們一個重要的事實：agent 的「demo 能力」和「真實世界能力」之間，仍有巨大鴻溝。

這個鴻溝在縮小嗎？一定在。但以什麼速度，沒人知道。

我不打算做預測，那是 pundit 的工作。作為一個 practitioner，我更感興趣的是：不管 agent 的能力怎麼變，什麼是不變的？

2026 年，Agent 仍然不會做的事

經過一年的實戰，我整理出五件 agent 到今天為止仍然做不好、且短期內不太可能做好的事：

1. 釐清模糊的需求

「用戶反映登入流程太複雜。」

這句話背後可能意味著 20 種不同的改善方向。人類工程師會去找 PM 問、看 user research、在白板上畫 flow——然後形成一個具體的方案。

Agent 拿到這句話之後，會直接開始寫 code。寫出來的東西可能很完整，但解決的可能不是真正的問題。

Spec-Driven Development 可以緩解這個問題，但 spec 本身得由人來寫。把模糊需求變成精確 spec 的能力，是目前 agent 無法取代的。

2. 組織政治與跨團隊協調

「這個 API 改動需要後端團隊同意」、「那個 PM 特別在意 performance」、「QA 組長不喜歡我們用太多 mock」。

這些 organizational context 不在 codebase 裡，也不在任何文件裡，它們存在於人的關係和記憶中。Agent 沒辦法 navigate 這些。

3. 品味與審美判斷

「這個 UX 好嗎？」不是一個有標準答案的問題。

Agent 可以完美實現你 spec 裡描述的每一個細節。但如果你的 spec 沒有描述「這個按鈕在這裡感覺太擠」，agent 不會自己發現。

Design sense、產品直覺、「這個感覺不對」的第六感，這些目前完全是人類的領域。

4. 倫理和合規判斷

「這個功能收集了 PII，需要通知用戶嗎？」「我們的 AI feature 在歐盟受 AI Act 規範嗎？」「這個 dark pattern 在法律上可以但在道德上該不該用？」

Agent 可以幫你查法規、整理 compliance checklist，但最終的判斷——「我們做不做這件事」——必須是人做的。

5. 真正創新的架構設計

Agent 非常擅長 follow 既有的 patterns。你的 codebase 用了 MVC，它就會寫 MVC。你用了 event-driven，它就寫 event-driven。

但當你需要 break 既有的 pattern——因為 scale 需要、因為 paradigm shift、因為你發現了一種更好的方式——agent 幫不了你。它的 training data 是過去的 best practices，不是未來的。

不可取代的人類能力

把以上歸納為四種核心能力：

判斷力

知道什麼該做、什麼不該做。

Agent 可以做任何你叫它做的事。但「這件事值不值得做」、「做到什麼程度就夠了」、「這個 trade-off 怎麼取」，這些都是判斷力的範疇。

在 agentic workflow 裡，你做的每一個決策的價值都被放大了。因為 agent 會忠實地執行你的決策：好的決策會被高效執行，壞的決策也會。

品味

不是「能不能做」，而是「該不該這樣做」。

好的 API 設計、好的 UX、好的 code 結構，這些都需要 taste。Agent 可以在你給的 constraints 內找到最優解，但 constraints 的設計需要品味。

組織 Context

理解公司政治、團隊動態、stakeholder 的優先級。

Agent 不知道你的 CTO 最近在推 microservices、你的 PM 下個月要 demo 給投資人看、你的 QA 上週才因為沒 test 被 production bug 搞到加班。這些 context 決定了你該怎麼排優先級、怎麼溝通、怎麼取捨。

倫理決策

合規、隱私、安全的最終判斷。

這不是 agent 做不到，而是我們不應該讓 agent 做。涉及 ethics 的決策需要 accountability，而 accountability 只能由人來承擔。

技能衰退？還是技能轉型？

回到 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 就是清楚的溝通。這個技能也提升了。

淨結果

對有經驗的工程師來說，這是一個划算的交換：低價值的「打字型」技能衰退，高價值的「判斷型」技能增長。

但我要誠實地說，這讓我偶爾感到不安。有時候同事問我一個 syntax 問題，我需要查一下才能回答，心裡會覺得「以前我是可以秒答的」。

這種不安是正常的。技能轉型的過程中，舊能力的衰退總是比新能力的增長更容易被察覺。但退一步看，一個擅長系統設計和需求分析、只是需要查 syntax 的工程師，比一個能背 API 參數但不擅長設計的工程師，在 agent 時代更有價值。

一份「防衰退」訓練計畫

不管你對未來怎麼看，以下的練習都不會浪費。它們同時鍛練「跟 agent 協作」和「agent 做不到的事」。

8 週循環計畫

Week 1-2：Context Engineering 練習

目標：讓你的 CLAUDE.md 的品質提升一個等級
練習：review 你的 CLAUDE.md，問自己「agent 重複犯的錯哪些可以靠加一條 rule 解決？」
副作用：練習精確溝通的能力

Week 3-4：Spec Writing 練習

目標：每個 task 都先寫 spec 再交給 agent
練習：用 Goal / Constraints / Verification 格式寫 spec
副作用：練習需求分析和拆解的能力

Week 5-6：Review 練習

目標：刻意練習找 agent code 裡的問題
練習：review agent 的 PR 時，記錄你找到的每一個問題，分類是「邏輯錯誤」還是「事實錯誤」
副作用：提升 code review 的效率和敏感度

Week 7-8：手寫練習

目標：保持基礎能力的手感
練習：每兩週選一個小功能，不用 agent，完全手寫
副作用：當 agent 出問題時你還有能力自己 debug

持續練習

每月一次架構設計：不用 agent，自己做一個系統的架構決策。可以是你正在做的專案的某個子系統。
每季一次 agent-free day：完全不用 agent 工作一天。感受差異，保持自信。

回到 Trust Paradox

Post 1 開頭提到的數據：80% 的開發者在用 AI agent，但只有 29% 信任它。

14 篇文章之後，我想我理解這個 paradox 了。

信任不是靠「AI 變得更好」來建立的，而是靠方法論來建立的。

你不信任 agent 是因為：

它會 hallucinate（→ 你建了品質保證流程）
它不懂你的專案（→ 你設計了 context engineering）
它會亂做（→ 你寫了 spec）
它可能搞壞東西（→ 你設了安全網）
它很貴（→ 你做了成本優化）

每一個不信任的理由，都有一個工程解法。

Agentic Engineering 不是盲目信任 AI，而是用工程方法建立有根據的信任。

這整個系列教的，就是這件事。

結語：工程師的黃金時代

我不知道 5 年後工程師還需不需要寫 code。老實說，沒有人知道。

但我知道一件事：2026 年的今天，是工程師有史以來能產出最多價值的時代。

一個人 + 一個 agent，可以做到以前需要一個小團隊才能做的事。一個需求 60 分鐘從 Prompt 到 Production。一個好的 spec 可以驅動一整個 feature。一份好的 CLAUDE.md 可以讓 agent 像一個了解你專案的 junior engineer 一樣工作。

Builder 的門檻比以前更低了。一個人可以建產品、發布、維護，不需要融資、不需要團隊。但這不代表工程師的價值降低了，恰恰相反，有 judgment 的工程師比以前更稀缺。

因為 agent 放大了一切：好的判斷被放大成高效的成果，壞的判斷也被放大成高效的災難。能做出好判斷的人，從來沒有像現在這麼有價值。

所以，如果你問我「工程師還需要寫 code 嗎？」

我的答案是：你需要的不是「寫 code」的能力，而是「知道該寫什麼 code」的能力。前者 agent 在取代，後者 agent 在放大。

14 篇下來，從 Agentic Engineering 是什麼到怎麼帶進團隊，我分享了一年 100% AI coding 的完整方法論。這不是一篇「AI 會改變世界」的泛泛之談。這是一個工程師的實戰紀錄——踩過的坑、找到的解法、建立的系統。

如果這個系列對你有幫助，它之後會整理成書。

不是因為我要賣書，而是因為我相信，工程師需要一份「agent 使用手冊」——不是工具教學，而是方法論。

這份手冊，就是你現在手上的這 14 篇。

Takeaway

Agent 在進步，但「demo 分數」跟「真實世界能力」之間仍有巨大鴻溝。SWE-bench Verified 72% vs SWE-bench Pro 23%，這個差距就是 Agentic Engineering 存在的意義——你是那個填補鴻溝的人。
不可取代的不是「會寫 code」，而是「知道該寫什麼 code」。判斷力、品味、組織 context、倫理決策——這些能力在 agent 時代的價值不減反增。
最好的防衰退策略不是抗拒 AI，而是讓 AI 替你做低價值的事，你專注在高價值的判斷上。8 週循環訓練計畫涵蓋了 context engineering、spec writing、code review、和手感維持——這些是不管 AI 怎麼發展都有用的能力。

這是「Agentic Engineering 實戰手冊」系列的最後一篇。 完整系列：系列目錄 如果這個系列對你有幫助，它之後會整理成書。敬請期待。