從「寫 code 的人」到「管 agent 的人」：工程師的角色重新定義
這是「Agentic Engineering 實戰手冊」系列的第二篇。上一篇：Agentic Engineering 是什麼？
那個尷尬的瞬間：手寫 Code 反而更慢了
上個月專案趕進度，Claude Code 的 API 剛好在維護。我想說沒關係，我自己來。打開 VS Code，開始寫一個 CRUD endpoint。
寫了二十分鐘，我回頭看自己的 code——少了一個 null check、error handling 不完整、test 還沒寫。以前這些我閉著眼睛都能搞定的事，現在居然要停下來想。
更尷尬的是，API 恢復之後我把同一個任務交給 agent。七分鐘，完成了。code 比我手寫的更完整，test coverage 更高，連 API doc 都自動更新了。
那個瞬間我意識到兩件事：
第一，我的角色已經不知不覺地變了。我不再是「寫 code 的人」，我是「管寫 code 的 agent 的人」。
第二，這讓我非常不安。
IC 到 Agent Manager：日常的具體變化
如果你問我一年前的一天是怎麼過的，跟現在的一天是怎麼過的，差異大到像換了一份工作。下面是我自己的粗略估算，不是每個工程師都該照抄的比例。
一年前的時間分配（Agent 之前）：
| 活動 | 佔比 | 消耗的腦力 |
|---|---|---|
| 寫 code | 60% | 高（語法、邏輯、debug） |
| 讀 code / 理解系統 | 20% | 高 |
| 開會 / 溝通 | 15% | 中 |
| Code review | 5% | 中 |
現在的時間分配（Agent First）：
| 活動 | 佔比 | 消耗的腦力 |
|---|---|---|
| Review agent output | 35% | 高（判斷正確性、架構合理性） |
| 寫 spec / 定義需求 | 25% | 高（這直接決定 agent 產出品質） |
| 架構思考 / 設計決策 | 20% | 高 |
| 開會 / 溝通 | 15% | 中 |
| 手寫 code | 5% | 低（只在 agent 搞不定的時候） |
最大的變化不是「做什麼」，而是腦力花在哪裡。
以前我的腦力花在「怎麼實作」——這個 function 的邏輯怎麼寫、這個 edge case 怎麼處理、這個 SQL query 怎麼優化。
現在我的腦力花在「做什麼」和「對不對」——這個需求的邊界在哪、agent 的解法是不是最好的、這個架構決策三個月後會不會後悔。
用一個比喻：以前我是工地的砌磚師傅，現在我是工地的監工。我不再一塊一塊砌磚了，但我需要知道這面牆砌得直不直、用的材料對不對、整體結構穩不穩。
而且說實話，監工需要的專業能力不比砌磚師傅少，只是不一樣。
「我會不會變笨？」——技能衰退的焦慮
這個問題我想了很久。我身邊不少長期使用 coding agent 的工程師，也聊過類似的焦慮。
我在「Token 燒光焦慮」那篇文章裡聊過情緒面的掙扎，這篇想從能力面來誠實盤點。
確實衰退的能力：
- 語法記憶：我已經記不清 Go 的 error handling 語法細節了。以前手到擒來，現在得查。
- API 細節：某個 library 的某個 method 第三個參數是什麼？以前背得出來，現在完全不記得。
- 手寫 boilerplate 的速度：寫一個標準的 REST endpoint，以前 15 分鐘，現在可能要 25 分鐘。
- 某些 debug 直覺：以前看到某種 error pattern 會馬上聯想到可能的原因，現在這個反應變慢了。
這些衰退是真的。不否認。
但同時增長的能力：
- 架構判斷力：因為我不再被實作細節佔滿腦袋，我有更多腦力去思考系統設計。
- 需求分析力：寫了一年的 agent spec，我定義需求的精準度提升了至少一個等級。對人類同事描述需求時也變清楚了。
- Review 眼光：每天 review agent 產出的 code，我看 code 找問題的能力變強了，而且是跳脫式的——不是逐行看語法，而是看架構和邏輯。
- 系統性思維：管 agent 逼你想清楚整個工作流——什麼先做什麼後做、dependency 是什麼、怎麼驗證。這訓練了更好的系統性思維。
那淨結果呢？我覺得這像計算機的發明。計算機出現之後，人類的心算能力確實掉了。但數學有因此退步嗎？沒有。反而因為不用把腦力浪費在計算上，人們可以思考更高層次的數學問題。
同理，你不需要記住每個 API 的參數。但你需要知道這個架構設計合不合理——而後者比前者有價值得多。
新技能樹：2026 工程師該投資什麼
如果你接受了「角色已經變了」這個前提，下一個問題就是：那我該投資什麼技能？
判斷力 > 打字速度
以前面試考你 LeetCode，測的是你的實作能力。未來面試會越來越看你的判斷能力——給你一個 agent 寫的方案，你能不能看出問題在哪？
知道「什麼該做」變得更重要。Agent 可以提出實作與產品建議，但需求的取捨、風險的承擔，以及最後要不要上線，仍然要有人負責。
架構眼光 > 語法記憶
Agent 很會補語法，卻也可能自信地用錯版本或捏造 API。更麻煩的是，它通常不知道你們為什麼選 PostgreSQL、不選 MySQL，不知道 data model 背後的歷史包袱，也不知道那個看起來多餘的 middleware 其實是合規要求。
這些 context 是你的獨有價值。越深入理解系統和業務，你越能做出 agent 單靠 codebase 很難做好的取捨。
溝通力 > Coding 力
我常用一個不完美、但很好記的比喻：把 agent 當成一個能力很強、卻缺乏組織脈絡的新同事。
這個類比有用的地方在於：對方不笨，只是不知道你們的潛規則。你需要講清楚要做什麼、不要做什麼，以及怎樣才算做對。
你的 spec 品質 = agent 的產出品質。而寫好一份 spec，靠的是溝通能力，不是 coding 能力。
Shopify CEO Tobi Lütke 把這件事推到了組織層面。他在 2025 年 4 月公開內部 memo，把「反射性地使用 AI」列為基本期待，並要求團隊在增加人力與資源前，先說明為什麼不能用 AI 完成目標。
你不必同意這麼激進的政策，但它反映了一個現實：只會打開工具還不夠，團隊開始在意的是，誰能把 AI 納入可驗證、可負責的工作流。
不同階段，可以怎麼練
這個轉型不是所有人都從同一個起點出發。下面按年資分組只是方便討論；真正該看的是你對系統、業務與驗證方法熟不熟。
Junior（0-3 年）：先打基礎，再用 agent
最大風險：沒學會基礎就開始依賴 agent。
如果你從來沒手寫過一個完整的 REST API，你怎麼知道 agent 寫的 API 有沒有問題？你連 review 的能力都沒有。
建議策略：
- 先手寫，再用 agent 驗證。自己寫一遍，然後讓 agent 也寫一遍，比較差異。這是學習速度最快的方式。
- 把 agent 當 code review partner，不是 code writer。讓它幫你看你寫的 code 有沒有問題。
- 刻意練習 debug。Agent 可以幫你修 bug，但你需要理解 bug 為什麼會發生。
可以試的練習：挑一個小 feature 先自己拆解，再讓 agent 實作；最後逐段說明它的取捨與風險。重點不是禁用 AI，而是確認你真的看得懂。
Mid-level（3-7 年）：把經驗變成工作流
常見優勢：已經累積一些實作與除錯經驗，可以開始判斷 agent output 的品質。
這個階段很適合把腦中的判斷標準寫成 spec、測試與 review checklist。不過年資不是保證：如果對系統還不熟，仍然要縮小任務範圍。
建議策略：
- 逐步擴大 agent-first workflow。先從可回滾、可驗收的任務開始，再依實際結果增加自主程度。
- 練習寫 spec。把寫好 spec 當成跟寫好 code 一樣重要的技能。
- 開始學 context engineering。CLAUDE.md 怎麼寫、怎麼設計 agent 的工作環境。
每週練習：每個 task 都先寫 spec，然後交給 agent。review 的時候記錄「agent 做對了什麼」和「agent 做錯了什麼」。
Senior（7+ 年）：把判斷標準外顯化
常見優勢：累積多年的架構與業務判斷，較容易看出方案的長期代價。Agent 可以提供選項，但未必掌握團隊承擔過哪些事故、做過哪些取捨。
常見阻力不一定是抗拒 AI，也可能是現有系統風險高、知識沒有文件化，或工具還不符合公司的安全要求。這些顧慮很合理，做法不是硬推，而是先找低風險任務建立證據。
建議策略：
- 從你最頭痛的 task 開始。找一個你一直拖延沒做的 refactoring 或 migration，交給 agent 試試看。
- 保留人類負責的關卡。跨團隊架構決策、技術 roadmap、mentoring 與高風險變更，不應只看 agent 的建議就定案。
- 把你的經驗變成 agent 的 config。你知道的 coding conventions、架構原則、踩過的坑，寫進 CLAUDE.md。你的經驗不是被取代了，而是被放大了。
可以試的練習：在隔離的分支或 worktree，讓 agent 處理一個你熟悉的小任務，先不替它提示答案，但保留停止與修正的權力；最後比較它的路徑和你的做法。
Takeaway
-
角色轉換的關鍵不是學新工具，而是重新分配注意力。實作速度仍然重要，但需求邊界、驗證方法與風險判斷占比變高了。
-
有些能力可能因少用而變慢，架構判斷、需求分析與 review 也不會自動變強。這筆交換是否划算，取決於你有沒有刻意練習兩邊。
-
不同資歷不需要套同一張處方。共同原則只有三個：任務範圍要看得懂、結果要驗得出來、高風險動作要有人負責。
