2025 年 2 月，Claude Code 以研究預覽版問世，那時 Anthropic 大部分工程師還是用傳統方式審程式碼。約一年四個月後，局面幾乎翻轉。
根據 Anthropic 在 2026 年 6 月 4 日發布的《When AI builds itself》報告，旗下工程師目前平均每季交付的程式碼量，約為 2021 至 2025 年平均值的 8 倍。
官方也提醒，程式碼行數偏重量而非品質，幾乎肯定高估實際生產力增幅；Fung 的核心觀察是，程式碼供給量暴增的同時，驗證端的工作量也同步暴增。
Claude Code與Cowork團隊工程負責人（Engineering Lead）Fiona Fung 近期接受 Lenny's Podcast 訪談，說出了一句讓整篇訪談框架瞬間清晰的話：「寫程式已不再是瓶頸，它反而拉高了任何人所能達成成就的上限。」
換句話說，以前工程師抱怨沒有足夠時間寫程式，現在的問題是：當程式碼的供給速度遠超過人類可以審核的速度，管理者要怎麼辦？
Fung的答案不是「多審一點」，而是重新設計整個驗證機制。
為什麼傳統 code review 在這個節奏下失靈
Fung 在訪談中提到，Claude Code 的 code review 功能甚至到 2025 年都不存在，當時最大的瓶頸之一就是人工程式碼審查。在每季產出 8 倍程式碼的情境下，要維持「每個 PR 都有資深工程師逐行審核」幾乎不可能。
一般人的直覺反應是擴增程式碼審查人力。但 Fung 指出，這忽略了另一個結構性變化：提交程式碼的不再只有工程師，PM 和設計師也在 Claude Code 的協助下提交功能。這意味著傳統「工程師審工程師」的人力配置邏輯本身就需要重寫。
她的解法有兩層。第一層是讓規格書（spec）進版本庫（repo），讓 Claude 自動比對程式碼是否符合最初設計目標。
她在訪談中把這個方式比喻為「測試驅動開發（TDD，Test-Driven Development）的進化版」，差別在於以前要工程師先寫測試（Fung 坦言這像「先吃花椰菜」，自己也一直拖），現在 Claude 可以幫忙生成測試，讓 TDD 的原則在實務中終於變得可行。
第二層是她所稱的「bad vs. sad」品質框架。
「bad vs. sad」：讓每個子團隊自訂品質紅線
Fung 在訪談中描述了這個框架的設計邏輯。
bad 指不可恢復的嚴重錯誤，例如程式崩潰（crash）或資料遺失；sad 指可以恢復但讓使用者不舒服的問題，例如畫面閃爍（flicker）。
關鍵在於：sad 累積到一定程度，會演變成 bad。
框架本身不算複雜，複雜的是落地方式。Fung 沒有替整個組織統一定義什麼叫做 bad 或 sad，而是讓各子團隊依照自己的產品表面自行決定。例如 CLI 介面的 bad 可能是程式崩潰，某個 UI 功能的 sad 可能是按鈕反應延遲超過某個閾值。每個子團隊建立自己的儀表板，追蹤各自定義的 bad/sad 事件趨勢。
這個設計解決了跨產品表面比較的困境。傳統做法是讓所有團隊追蹤相同的效能指標（例如頁面載入時間），但當你同時管理 CLI 工具、瀏覽器擴充套件和 Cowork 介面，這些數字根本無法放在同一把尺上量。
但重點是 bad/sad 框架讓不同性質的產品都能用相同語言（這個體驗是不可接受的，還是只是讓人不舒服？）回報品質狀況。
此外，Fung 的團隊還有一個她稱為「F-word dashboard」的指標（編按：指追蹤使用者對話中出現咒罵詞頻率的儀表板，作為衡量挫折感的代理指標），追蹤使用者在對話中出現咒罵詞的次數，作為衡量挫折感的另一個訊號。
Fung 在訪談中表示，這個做法是 2025 年 9 月由一位工程師提出。
管理工具本身也在被 AI 改寫
除了品質框架，Fung 分享了她作為管理者的日常工作如何被 Routines 功能改變。Fung 在訪談中表示，Routines 於 2026 年 4 月 14 日以研究預覽形式推出，讓使用者設定定時任務，由 Claude 在背景自動執行指定的代理任務。
Fung 的使用方式很具體：她在所有 repo 開了一個 Claude Code 遠端 session，這個 session 被授予存取所有 Slack 頻道和內部指標的權限。每天早上，Routines 會自動掃描回饋頻道，整理使用者問題主題，並產出可以直接審閱的 PR 草稿。過去她必須手動做的工作（每天早上喝咖啡、逐一掃描頻道），現在她醒來就有摘要和 PR 等著她。
她也把這個流程導入月度 1:1 管理會議。以前這類會議靠手動整理 bullet list，現在她開著 Claude Code session 開會，讓 Claude 即時分析這個月做了什麼、有沒有達到效果、用戶回饋有哪些主題。她在訪談中說，一年前這些洞察基本上是做不到的。
但 Fung 也坦承，當同時有 20 個代理在跑，脈絡切換（context switching）的認知負荷其實在增加，而不是減少。以前她會刻意排出「進入心流的時間」，現在她發現自己必須改成排出「消化非同步代理輸出的時間」。
菜鳥工程師怎麼教？
Fung 的管理框架在有既有工程背景的人身上相對有效，但她對新一代工程師的培養路徑感到不確定，這是她在訪談中少數直接表示「希望自己有水晶球」的問題之一。
她的觀察是：以前工程師透過親手寫程式累積對架構和底層的直覺判斷，這個過程是無法跳過的。現在新工程師可以不讀程式碼就直接提交功能，這個「理解層」要怎麼建立？她提出的可能方向是師徒制（fellowship 或 apprenticeship model），讓新進工程師在有資深人員陪伴下完成一定數量的實務工作。但她也說，這只是一個方向，不是答案。
她同時提到「trust but verify」是貫穿這整個轉型期的核心原則。模型很強，但仍然有需要深度人工判斷的區域，尤其是分散式系統等高複雜度場景。她在招募上的做法反映了這個判斷：現在只鎖定兩種人，一是有產品直覺的創造型工程師（creative builders with product sense），二是能負責驗證的深度系統專家（deep systems experts）。中間那些一般化角色，她認為已不是主要缺口。
AI 讓人人高效，但也讓人人變成「孤島」
最後一個值得關注的面向，與技術無關。Fung 在訪談中被問到什麼事情讓她睡不著覺？她的答案不是技術挑戰，而是文化維持。
她用一句話描述自己的噩夢：管理者說「都沒問題」，但背後其實已經很不妙，就像那個「管家在失火的房間裡安靜喝咖啡」的梗圖。
她的說法是：「文化是一個有生命、會呼吸的有機體，而不僅僅是掛在牆上的一張海報。」
團隊在快速成長下，多元觀點、一體感和「看到同伴跟不上時要等一等」的習慣，是最難保存的東西，也是她認為最重要的東西。
這個觀點背後有一個結構性的提醒。Fung 所描述的那套高效管理系統，讓個別工程師可以在幾乎不需要跨組溝通的情況下完成大量工作，這是效率的來源，但也是孤立感的來源。
她在訪談中提到，最近 Claude Code 團隊啟動了「programming lunches」，讓工程師帶著各自的 Claude session 一起吃飯工作，互相觀察對方怎麼用工具。這不是技術活動，是對抗孤立感的社交設計。
簡單來說，在高速增長中刻意放慢去觀察同事怎麼工作，需要的是管理者對「什麼東西不能自動化」有清醒的判斷。
資料來源：Lenny's Podcast — What happens after coding is solved? Fiona Fung（2026 年 6 月 21 日）
補充查證來源：Anthropic — When AI builds itself（2026 年 6 月 4 日）、Fortune — Anthropic engineering head Claude Code lonely experience（2026 年 6 月 23 日）
本文初稿為AI編撰，整理．編輯／李先泰
