寫程式不再是瓶頸，
團隊還剩什麼工作？

Fiona Fung 帶 Claude Code 與 Cowork 團隊。她在 Lenny's Podcast 裡談的不是「工程師會不會消失」，而是 AI 把 coding 的天花板拉高後，團隊要把哪些能力補成系統。

LENNY'S PODCAST × ARTICLE EXPERIENCE

SCROLL
PART 1

AI-native 團隊不是少寫 code，而是換了瓶頸

Fiona 提到 Anthropic 工程師平均每季交付的 code，比 2025 年高出 8 倍。這個數字真正重要的地方，不是工程師突然變成八個人，而是「把想法變成可執行改動」這段摩擦下降了。

過去團隊常把問題卡在工程頻寬：這個功能太難、這個改動要等人、這個需求先排進 roadmap。Claude Code 這類工具把第一層瓶頸移走後，問題變成：你知道要做什麼嗎？你有足夠好的規格嗎？你能判斷它做得對不對嗎？

8×
產出上限被拉高
Fiona 在節目裡提到團隊 code 交付量的變化。
async
工作變成非同步
從單次 prompt 走向 routines 與多代理流程。
verify
驗證成為核心
速度越快，越需要明確框架判斷什麼叫做對。

Fiona 自己的管理方式也跟著改變。她讓 Claude Code remote session 進到團隊 repo，能看工作進度、Slack 回饋與指標。她每天早上不只是讀回饋，而是讓 routine 幫她監看特定訊號，必要時產生 prompts 或 PR。

PART 2

管理的中心，從分派任務變成建立驗證迴路

當 AI 可以大量生成 code，code review 的瓶頸會立刻浮現。Fiona 的答案不是把人類 reviewer 全部拿掉，而是把「什麼叫做好」寫成模型能檢查、團隊能更新、專家能補位的框架。

AI-native 團隊的驗證迴路
1. 規格進 repo把產品、內容、品質標準寫成可引用的文件，而不是口頭共識。
2. 模型先檢查Claude 很擅長依框架驗證，尤其是明確列出的規則與反例。
3. 專家補深水區系統、架構、安全等地方仍需要深度 subject matter expertise。
4. 回饋再更新規格不能變成古蹟。它要跟 code、產品與使用者回饋一起變動。

所以她現在找兩種人：有產品感的 creative builders，以及能處理硬問題的 deep systems experts。前者把點子推進到可見的產品；後者負責那些模型還不能只靠自信通過的地方。

AI 不是讓團隊不需要專家，而是讓專家更集中處理「信任但必須驗證」的部分。沒有規格、沒有測試、沒有品質語言的團隊，會先被自己的速度淹沒。

PART 3

下一個差距，是野心與主動性

節目裡有一段很清楚：以前聽到一個功能想法，工程師可能先想到「這很複雜」。現在第一反應變成「可以試」。工具降低了實作成本，團隊反而更需要判斷：什麼值得試？試到什麼程度？成功訊號是什麼？

Fiona 認為能適應的人，通常有 growth mindset。這不是勵志詞，而是很具體的工作習慣：承認過去讓你成功的方法，可能不再適用；願意重新學習；願意把原本熟悉的流程拆掉。

HIGH AGENCY
主動提出解法
看到問題時，不等著被分派。帶著想法、原型與取捨進討論。
HIGH ACCOUNTABILITY
也承擔後果
速度不是免責。AI-native 團隊更需要明確 owner、指標與品質標準。

她還給出一個很實用的管理動作：給團隊明確許可，殺掉不再服務目標的流程。她剛加入時嘗試六個月 roadmap，後來改成更接近 just-in-time 的月度規劃。AI 讓「做東西」更快，長週期計畫若只是維持儀式，就會變成噪音。

PART 4

從 token-maxing 走向 ROI，品質要分清楚 bad 與 sad

Fiona 觀察到一個 vibe shift：早期大家先盡量花 token、探索上限；現在開始問成本、回報、品質和影響。lines of code 只能描述 throughput，不能代表使用者價值，也不能代表系統真的更好。

她提到「bad vs. sad」的品質框架。bad 是不可恢復、會造成嚴重問題的錯誤；sad 是痛點、挫折、但使用者仍可恢復的體驗。把兩者分開，團隊才知道哪裡要拉最高警戒，哪裡要持續減少摩擦。

BAD
不可恢復的錯
安全、資料、核心流程錯誤。這類問題需要更早偵測、更強驗證與人類專家介入。
SAD
可恢復但痛苦
流程卡、體驗差、結果不夠貼近需求。這類問題適合用回饋 channel 與 routines 持續掃描。

這也是為什麼她強調 proactive quality。AI 讓 PR 變多後，團隊不能等最後才問「好不好」。關鍵體驗要有指標，重要工作流要有趨勢，品質語言要能被模型、人類 reviewer 與產品團隊共同使用。

PART 5

角色邊界變模糊，文化反而更重要

Fiona 認為接下來被改變的不只工程。PM、data science、design 等 coding-adjacent roles 都會移動。PM 有想法時，不一定只能排隊等工程頻寬；資料與設計流程也會逐步被自動化與代理化。

但她沒有把未來說成人人都不必理解底層。她提醒新進工程師仍要 double-click 自己依賴的 layer。Boris Cherny 早期手寫 Claude Code，累積了 codebase 知識；後來即使不再手寫每一段，仍能判斷模型產出的方向。這種理解目前還不能省掉。

她也要求 manager 一開始先當 IC，之後也要保留部分 player-coach 工作。理由很直白：工具、流程與產品都變太快，只用管理報表理解團隊，會離現場太遠。

她最擔心的不是某個功能做不出來，而是團隊快速長大時，還能不能保留開放辯論、彼此補位、一起過終點線的文化。

「Coding is no longer the bottleneck.
It's lifted the ceiling of what anyone is able to do.」

程式碼產量只是表層。真正的變化，是團隊要重新定義什麼叫做會做事。

如果 coding 被解掉，
你會先補哪個瓶頸？

選完之後，分享你的團隊判斷

你的觀點

想看更深入的對談？

Lenny's Podcast 原訪談包含 Fiona Fung 對 Claude Code、Cowork、routines、管理節奏與團隊文化的完整脈絡。

閱讀完整文章 →