Coding 被 AI 解決之後，工程師在幹嘛？

> Meta Shift

---

2026 年初，Anthropic 對外公布了一個數字：他們的工程師平均每季交付的程式碼量，是 2021–2025 年同期的 8 倍（來源：Anthropic 官方 Twitter）。

這不是什麼 A/B test 的小數據，這是一整個組織的生產力數字。8x。

Fiona Fung 就是帶著這個數字在工作的人。她負責的是 Claude Code 跟 Cowork 兩個團隊，直接管到 Boris Cherny（Head of Claude Code）跟整個 engineering 和 PM 團隊。在這之前，她在 Microsoft 做了 11 年的 Visual Studio 和 TypeScript，然後去 Meta 從零建立 Facebook Marketplace（現在年 GMV 超過 1000 億美金），之後做了 Meta 第一副 AR 眼鏡，最後負責 Instagram 的 infrastructure、growth、integrity 和 safety。

工程師資歷超過 25 年。見過 IDE 進化、Web 爆炸、Mobile 爆炸、現在輪到 AI。

她最近在一個 podcast 裡被問了一個問題，聽起來很科幻但其實很切實際：Coding 被解決之後，工程師在幹什麼？

---

為什麼這個問題現在才被認真討論

要理解這個問題的重量，先要知道「coding 被解決」這個前提在說什麼。

這不是說 AI 可以寫出完美的程式碼，而是說 coding 本身不再是瓶頸。你有一個想法，你描述它，AI 實作它。整個「把想法變成跑得動的程式」這件事的阻力，已經從週計算變成小時計算，很快可能是分鐘計算。

Anthropic 那個 8x 的數字就是這個現實的具體投影。同樣的工程師、同樣的時間，產出是以前的 8 倍。這不是說大家多努力，而是說一整層的執行成本被壓縮了。

這個轉變在產業裡並不是第一次發生。當年 C 語言出現，組合語言工程師說完蛋了；後來高階語言出現，有人說 programmer 要失業；再後來 framework 爆炸，說不會用 jQuery 就沒工作。每次都是一樣的劇本：工具把一層執行工作自動化，工程師的位置往上移一層。

但這次有一個不一樣的地方：移動的速度。以前每次工具升級大概要十年才會真正滲透到整個產業。這次的週期明顯壓縮了。Claude Code 從公測到 8x 生產力，時間尺度是幾個季度。這代表工程師需要適應的時間窗口比以往短很多。

Fiona 在這個環境裡管理一個正在快速消費自己工具的團隊 — 她的工程師在用 Claude Code 寫 Claude Code。這個 meta 層面的反饋迴路，讓她對「coding 之後的工程師在做什麼」有非常直接的觀察。

---

她看到的轉折：剩下什麼工作

Fiona 的觀察是，當 coding 不再是瓶頸，工程師的工作開始往幾個方向集中。

第一個是 judgment — 判斷力。AI 可以生成 10 種解法，但它不知道哪個在你的產品脈絡裡是對的。這個判斷需要理解：使用者是誰、產品的方向是什麼、現在的 tech debt 狀況如何、三個月後的 roadmap 會怎麼走。這些 context 是 AI 讀不到的，就算讀到了，它也不知道怎麼做 trade-off。

她的團隊在 ship 8x 程式碼的同時，並沒有讓 review 流程消失。反而是 review 的性質改變了 — 從「這段 code 有沒有 bug」變成「這個方向選得對不對」。工程師在做的是更高層次的 editorial 工作，而不是行行看 syntax。

第二個是 context management。這是她點名說「目前還沒有人解決」的問題。當你同時有 10 個 AI agent 在幫你跑任務，你的認知負擔不是降低了，是換了一種形式。你要知道每個 agent 在做什麼、它做到哪裡了、它的結果對不對、它做的事有沒有跟別的 agent 衝突。

這個 context-switching 的問題，比以前的多工問題更複雜，因為 AI 的速度比人快，你沒辦法慢慢看，你要有能力快速判斷「這個輸出我信不信任」。這其實是一個全新的技能，目前沒有 playbook。

第三個是溝通和定義問題的能力。在 coding 不是瓶頸之後，工程師跟 PM、設計師、stakeholder 之間的界線會更模糊。Fiona 在 Anthropic 已經觀察到這個現象 — roles are blurring。一個能清楚定義問題、描述 requirements、跟 AI 協作實作、然後評估結果的人，比一個只會寫 code 的人更有價值。

她用 Claude 的「routines」功能舉了個例子。她設定了一些固定的 routine 讓 Claude 定期幫她處理管理上的雜事，把一些認知上的重複工作外包出去。這讓她可以把精力放在真正需要人類判斷的地方。但這背後的前提是：你要知道什麼事情值得外包、什麼事情不行。這個判斷本身是一個 meta-skill，而且目前 AI 不會幫你做。

---

Meta 判讀：這是 Meta Shift，不是 Patch Note

我來幫這件事貼個標籤。

這不是「AI 讓工程師更有效率」這種 Patch Note 等級的事。效率提升本來就一直在發生，每個工具世代都在發生，這沒什麼好大驚小怪的。

這是 Meta Shift，因為它改變的是「工程師」這個職位的定義本身。

最近比較接近的歷史類比，我覺得是當年的 DBA（Database Administrator）。在 1990 年代，DBA 是一個高度專業的角色，你需要深懂 SQL 優化、index 策略、query plan。後來 ORM 出現、managed database 服務出現，這個角色沒有消失，但它的工作重心移了 — 從「我要懂怎麼寫 SQL」變成「我要知道什麼時候不能用 ORM、什麼時候要手動優化」。

工程師現在的位置，跟那時候的 DBA 很像。Coding 本身的執行層正在被自動化，但「知道什麼時候要做什麼、知道結果對不對、知道系統的邊界在哪裡」這件事，還是需要人。

Fiona 說她最擔心的事情之一，是 AI 可能讓工程師喪失某些底層的直覺。如果你從來沒有從零 debug 過一個複雜的 production issue，你怎麼知道 AI 給你的解法哪裡有問題？這個「擔心」很真實，我覺得她說的不是杞人憂天，而是一個確實值得被認真面對的 risk。

類比到電競：你可以靠 coach 給你 draft 建議，但如果你對遊戲的 fundamental 沒有感覺，你就沒辦法在 in-game 做出對的 adjustment。AI 是一個非常強的 coach，但你自己的 game sense 還是要有。

---

對工程師來說，這代表什麼

老實說，我覺得現在很多工程師在面對這個問題的時候，要嘛過度恐慌（我要失業了），要嘛過度樂觀（AI 只是工具，我還是核心）。兩個都有點偏。

如果是我，我會注意以下幾件事：

要繼續碰底層，不能全部外包給 AI。不是說要回去用 assembly language，而是你要定期做一些不靠 AI 輔助的 debug、架構設計、performance 分析。讓那個直覺保持活著。

開始練習「定義問題」這件事。現在很多工程師的弱點是溝通和問題拆解，因為以前不太需要這個，code 自己說話就好。但在 AI 主導執行的世界裡，你定義問題的精確度直接決定 AI 輸出的品質。這個技能投資 return 很高。

不要等 context-switching 問題被別人解決。Fiona 說這是目前最大的未解問題之一。但與其等工具出現，不如現在就開始摸索自己的工作流 — 你怎麼追蹤多個 agent 的狀態？你怎麼決定信任哪個輸出？你的 review cadence 是什麼？這些都是需要個人摸索的，沒有標準答案。

Coding 被解決之後，工程師這個職位還在。但它在做的事情，已經不完全是 coding 了。

延伸閱讀

• OpenAI Codex 負責人說：PM 和工程師的邊界正在消失
• Anthropic 工程師親自示範 Claude Cowork — 大公司如何用自家 AI 寫程式
• 數據打臉了 — AI 非但沒殺死工程師職缺，反而讓它變成最抗跌的工作