Lenny's Podcast 這次訪談 Fiona Fung，我覺得最有用的地方，不是又多一個「AI 讓工程師更有效率」的案例，而是她把 AI 原生工程團隊的管理問題講得很具體。
Fiona 現在在 Anthropic 帶 Claude Code 和 Claude Cowork 相關團隊。訪談一開始提到一個很令人印象深刻的數字，Anthropic 工程師平均每季產出的 code，大約是 2021 到 2025 年期間的 8 倍。這個數字很容易被拿來當生產力指標，但如果只停在這裡，反而會錯過比較重要的部分。
當 coding 本身不再是最稀缺的環節，瓶頸會移到別的地方。
以前工程組織最常卡在寫 code 的人力不夠。需求排隊、spec 排隊、review 排隊、測試排隊，最後大家都會說工程 bandwidth 不夠。AI coding agent 進來以後，寫 code 這件事的成本大幅度降低，很多原本不值得做的小改動、實驗、內部工具、修 bug，突然都變得可以做。但這不代表組織自動變快。新的瓶頸會出現在 review、驗證、產品判斷、品質定義、跨團隊同步，以及 manager 是否真的看得懂現在正在發生什麼。
Fiona 講到她自己的管理方式時，這點很明顯。她不是只把 Claude Code 當成更好的工具。她會讓 Claude Code 開 remote session，跨 repo、Slack channel、metrics 去整理某個人的關注的領域、最近作出的的產品、收到的反饋、使用者反應、市場 impact，然後用這些資料來做 1on1 面談前的準備。
這個用法對我來說很有啟發。AI 在這裡已經不只是單純代寫 PR，而是讓 manager 比較有機會追上團隊實際工作的速度。當一個團隊裡很多人同時用 agent 做事，傳統靠週會、狀態更新、少數幾個 dashboard 來掌握進度，很快就會不夠用。管理者需要新的觀測機制，不只是系統觀測機制，而是工作觀測機制。
她也提到 routine 的用法。以前早上可能是看幾個 feedback channel、喝咖啡、整理今天要看的東西。現在 routine 可以先幫她整理 feedback、找出需要注意的地方，有時甚至先產出 PR 讓她 review。這代表很多管理工作會從「我親自收集資訊」變成「我設計好問題，讓 agent 先幫我收斂資訊，再由我判斷」。
這件事延伸到 code review 也一樣。
Claude Code Reviews 是 Anthropic 內部後來才多出來的能力，因為當 code 產出大幅增加，人類 reviewer 會變成瓶頸。Fiona 的說法不是讓 AI 全面取代 review，而是把 review 分層。某些重複性、規格型、可驗證的部分，可以交給 AI 先做。某些需要深度 domain knowledge 思考、判斷的地方，仍然要靠人。
這裡的重點不是「AI review 準不準」這麼簡單，而是團隊能不能把好品質寫清楚。她提到，如果 repo 裡有清楚的 spec、framework、標準，Claude 就比較能判斷什麼是好的結果。換句話說，文件、測試、架構原則，不再只是給新人看的 onboarding 材料，也會變成 agent 工作時的重要上下文。而這會改變很多工程實務的價值排序。
以前大家都知道 TDD 好，但很多團隊做不起來，因為寫測試的成本太高，時間壓力一來就先犧牲。當 Claude 可以先幫你寫測試，再用測試帶出實作，TDD 的實務門檻就低很多。這不是因為大家突然更有紀律，而是因為原本最痛的成本被降低了。
招募的部分也很值得分享。
Fiona 講到她現在會看兩種人。一種是很有 product sense 的 builder，能自己想出方向、做出東西、反覆調整，並且對最後的產品體驗負責。另一種是很深的系統專家，能處理模型、架構、效能、安全、複雜平台這些難題。
這跟過去很多公司只用職能切分人才很不一樣。AI 讓更多人可以跨到原本不熟的工作區域，PM 可以更像 builder，designer 可以更接近 prototype，engineer 也必須更懂產品。可是深度專業沒有消失。越是關鍵的底層問題，越需要真正知道細節的人做驗證。
她用的原則是 trust but verify。我覺得這句話很適合描述現在的工程管理。你必須信任 AI 讓更多事情開始動起來，但你不能把判斷責任外包出去。越是用得重，越需要清楚知道哪些地方可以自動化，哪些地方一定要人做最後判斷。
訪談裡另一個我覺得實用的分享，是她談 metrics 的態度。
8 倍的代碼產出聽起來很強，但她也很清楚說，程式碼數量不是完美指標。有些工作本來就會產生大量 code，例如 library migration 或 framework 變更。有些高價值工作反而不會留下很多 code。PR 停留時間也一樣有用，但仍然不完整。
所以她更在意的是指標有沒有服務當下的問題。當團隊開始用 AI 以後，指標也要跟著調整，否則很容易只看到大家在做甚麼，卻看不到真正的進展。
她提到一個品質框架，我覺得非常適合拿回團隊內部討論。Anthropic 會區分 bad experience 和 sad experience。
Bad experience 是很嚴重、不可接受、可能讓使用者失去工作成果的問題，例如 CLI crash 或資料遺失。Sad experience 則是可恢復，但體驗很差的問題，例如畫面閃爍、等待太久、流程卡住。這種分類讓品質討論不只是看 bug 數，而是回到使用者到底遇到什麼狀況，以及哪些問題不應該被當成一般 bug 排隊處理。
我喜歡這個框架，因為它把品質從抽象的 dashboard 拉回產品體驗。AI coding agent 會讓改動速度變快，如果沒有一套共同的品質語言，團隊很容易在更高速度下累積更多使用者不舒服的細節。
這次訪談裡也有一個比較少被討論，但我覺得很重要的面向，就是 AI 原生工作方式的副作用。
Fiona 說，當大家越來越常跟 agent 一起工作，工程工作可能會變得更孤單。Claude Code 團隊後來甚至開始安排 pair-wise programming lunch，讓大家分享自己怎麼用 Claude Code 和 Cowork。這不是為了形式上的 team building，而是因為每個人跟 agent 協作的方式差異很大，這些 tacit knowledge 如果不被交換，很難自然擴散。
另一個副作用是 context switching。當你可以同時讓很多 agent 在背景工作，表面上產能提高了，但你也會得到更多待 review、待確認、待接續的工作。你要記得每個 agent 在做什麼、卡在哪裡、哪個結果可信、哪個需要重來。這會把人的工作從 單純執行變成指揮協作，但指揮協作本身也會變成新的負擔。
所以我不覺得 AI 原生工程團隊只是「大家都買 coding agent 帳號」這麼簡單。
真正要改的是整個工作系統。你需要更清楚的 spec，讓 agent 有足夠上下文。你需要更好的測試，讓產出的 code 可以被快速驗證。你需要新的 review 分層，避免人類 reviewer 被大量 PR 淹沒。你需要新的管理機制，讓管理者能看見更快流動的工作。你也需要新的團隊儀式，讓人和人之間的學習不要被人和 agent 的互動取代。
Fiona 最後談到她最擔心的不是某個產品或工程挑戰，而是文化能不能在快速擴張時維持。這點我覺得很真實。AI 會把很多個人的執行能力放大，但組織能不能承接這些能力，靠的還是共同標準、互相信任、願意爭論、願意在快到終點時回頭看誰需要支援。
很多公司接下來都會說自己是 AI-first 或 AI-native。這些口號不難講，工具也不難買。比較難的是回答幾個更具體的問題。
- 我們的 spec 是否清楚到 agent 可以使用？
- 我們的測試是否足夠快，能支撐更高頻率的改動？
- 我們的 review 流程是否知道哪些交給 AI，哪些必須由人判斷？
- 我們的 manager 是否看得見 agent 協作後的真實工作狀態？
- 我們的團隊是否還有足夠的共同學習，而不是每個人各自和自己的 agent 工作？
這才是我覺得 Fiona 這次訪談最值得帶走的重點。AI 讓寫 code 變得便宜，接下來稀缺的會是判斷、驗證、品質語言、組織節奏，以及文化本身。
工具會讓個人更強，但最後能不能變成團隊能力，還是要看組織怎麼設計工作。
來源：Lenny's Podcast, “Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)”, YouTube, https://www.youtube.com/watch?v=Ybrl4FYM57c 。Lenny’s Newsletter episode page and transcript, https://www.lennysnewsletter.com/p/building-the-most-ai-pilled-engineering 。Anthropic 官方 X 貼文提到工程師每季平均產出約 8 倍 code, https://x.com/AnthropicAI/status/2062568864240836995 。
沒有留言:
張貼留言