經營一個 AI-native 的工程組織（第 1/2 段）

🧑‍🏫 Claude Code 負責人 Fiona Fung 分享：AI 讓寫程式變得又快又便宜之後，團隊原本的規矩哪些該改、要怎麼改。你就算不是工程師也值得看，因為她講的「最慢的環節換了位置」和「先做出來再討論」，任何開始用 AI 工作的團隊都用得上。

• 00:19 講者 Fiona Fung 負責 Claude Code 與 Co-work 的工程和產品，之前在 Meta 和 Microsoft 建立並帶領過團隊
  ↳ 講者 Fiona Fung 負責 Claude Code 和 Co-work 的工程與產品。Claude Code 是 Anthropic 讓 AI 直接幫你寫程式的工具。她之前在 Meta、Microsoft 建立並帶領過團隊，有大公司的管理經驗。
• 00:49 這場演講有五個主題：瓶頸已經移動、因此要改寫的團隊規範、怎麼推行這些規範、證明方向正確的訊號，以及留給聽眾帶回團隊討論的題目
  ↳ 整場分五段：最慢的環節換了位置；所以團隊規矩要怎麼改；改了要怎麼推行；看哪些跡象能確定方向對了；最後留幾個問題，讓大家帶回團隊討論。
• 01:19 她最喜歡的一句話是「以前對你有用的，現在可能不再有用」；要保持 growth mindset，因為變化的速度一直在加快
  ↳ 意思是別把過去的成功經驗當成定律。growth mindset（成長型思維）指願意一直重新學、隨時調整做法。工具變得越來越快，死守舊方法最容易落後。
• 01:49 要定期檢視團隊規範和流程，問自己：它還有達到原本的目的嗎？
  ↳ 團隊規範就是大家習慣遵守的做事規矩。每條規矩當初都是為了解決某個問題，所以要定期問：那個問題還在嗎？這條規矩還幫得上忙嗎？
• 01:49 過去很多年，工程人力是昂貴的資源，大量規劃和審查都是為了保護這項資源，確保做的是對的東西
  ↳ 以前工程師的時間最貴，做錯方向的代價很高。所以開工前要開很多會、寫計畫、層層審核，目的就是別浪費這些人力。
• 02:20 這不是業界第一次遇到瓶頸轉移。2000 年代初她在 Microsoft 做 Visual Studio，當時還沒有雲端
  ↳ 她用親身經歷說明，卡住進度的環節本來就會隨技術改變。2000 年代初她在 Microsoft 做 Visual Studio（工程師寫程式用的軟體），那時還沒有雲端。
• 02:51 當年在一間伺服器機房建置 Visual Studio，每個人輪值一週 on call；build 是排隊進行，一次只能 merge 6 個 PR，測試失敗就得查是哪個 PR 造成的
  ↳ build 是把程式碼組成能跑的軟體；on call 是輪流待命處理狀況；PR 是提交給團隊合併的程式修改。當年要排隊組，一次只能併 6 個，測試出錯還得一個個查是哪個造成的。
• 03:21 有了雲端和 continuous build 之後，那個瓶頸就轉移了；現在要思考的是：寫程式不再是瓶頸時，會有什麼改變
  ↳ continuous build（持續建置）是程式一改就自動組起來、跑測試。有了雲端，機器不再稀缺，排隊問題就消失了。她要大家用同樣的眼光看現在：寫程式變快後，什麼會跟著變？
• 03:21 在 Claude Code 團隊，寫程式很少是慢的那一段，所以上游和下游的流程都得跟著調整
  ↳ 上游是動手前的規劃和討論，下游是寫完後的檢查和上線。中間寫程式這段變快了，前後如果還照舊，就會變成新的塞車點。
• 03:52 舊的瓶頸包括寫程式、寫測試、重構
  ↳ 過去最花時間的有三件事：寫程式本身；寫測試，也就是自動檢查程式對不對的程式；重構（refactoring），功能不變，但把程式整理得更好維護。
• 03:52 TDD 的做法是先寫測試並確認它會失敗，再修改程式，改完就已經有測試了
  ↳ TDD（測試驅動開發）的順序是先定好「驗收標準」，確認現在的程式過不了，再去改程式讓它通過。好處是改完的時候，檢查機制也一起做好了。
• 04:22 她以前覺得先寫測試像吃花椰菜，不太享受。改用 Claude 後，先寫測試、確認它失敗（證明測試真的有在測東西），再修 bug，結果 TDD 變得有趣多了
  ↳ 先寫測試很麻煩，她以前也是硬著頭皮做。現在交給 Claude 寫，她只要看到測試先失敗、修完後通過，就能確定真的修對了，這件事反而變得有趣。
• 04:52 她說 Claude 等於把 TDD 的「稅」拿掉了，這是她的一個 aha moment
  ↳ 「稅」是為了把事做好得多付的麻煩。TDD 好但累，Claude 把累的部分扛走、好處留下。她因此發現，很多本來嫌麻煩的好習慣，現在沒理由不做了。
• 04:52 以前的大型重構或架構整理總要爭論什麼時候做，因為得犧牲做產品的時間；有了 Claude，重構也不再是瓶頸
  ↳ 重構就像大掃除，做了對以後有好處，但當下會佔掉開發新功能的時間，所以常被拖延。現在 AI 很快就能做完，不用再為了排時間爭論。
• 05:22 新瓶頸一：驗證（verification）。產出大增，更要注意正確性；角色界線變模糊、提交變更的人變多，也要讓每個人對自己的變更有信心
  ↳ verification（驗證）是確認改動真的正確。AI 讓產出暴增，更要顧正確性。加上非工程師也開始改程式，每個人都得有辦法確認自己改的東西沒問題。
• 05:22 新瓶頸二：誰來 review；新瓶頸三：怎麼維護。產出量大增，維護成本也要一併考慮
  ↳ review（審查）是請別人檢查你改的內容。程式量暴增後，光是要看完就成了問題。而且每行程式寫出來都要長期照顧，寫得越多，以後維護越吃力。
• 05:52 有些舊流程會「悄悄失效」。流程原本是為了解決問題而設的，但大家常忘了回頭檢查它是否還需要
  ↳ 「悄悄失效」是指流程還在跑，但它要解決的問題早就不在了，只剩拖慢速度的效果。因為沒人回頭檢查，大家往往不會發現。
• 06:22 需要重新思考的面向：規劃規範、code ownership、code review、團隊組成、知識分享
  ↳ code ownership 是規定哪段程式歸誰負責。她點出五個要重想的地方：怎麼規劃、程式歸誰管、怎麼審查、團隊由哪些人組成、知識怎麼在團隊裡流通。
• 06:22 現在幾乎所有 Claude Code 的 commit 都是 Claude co-author 的；她說最近幾個月沒看過任何一個不是
  ↳ commit 是一次正式存進去的程式修改，co-author 是共同作者。意思是團隊幾乎每一筆修改都有 Claude 參與，AI 已經是日常工作的一部分，不是偶爾試用。
• 06:52 角色界線變模糊，團隊正在思考要加碼哪些技能；另一個問題是：當文件不再是 source of truth 時會怎樣
  ↳ source of truth 是「最後以哪份資料為準」。以前以文件為準，現在程式改太快，文件常跟不上。工程、產品、設計的分工也變模糊，團隊正在想要加強哪些能力。
• 06:52 改寫過的團隊規範：code review（Cat 早上介紹的 Claude Code code review 是重要工具）、onboarding、規劃、招募、組織形狀
  ↳ 她列出已經改寫的規矩：程式審查（搭配同場 Cat 介紹的 Claude Code 自動審查功能）、onboarding（帶新人上手）、規劃、招募，以及組織的形狀。
• 07:22 組織形狀：希望組織更敏捷、更扁平，Claude Code 的每位 manager 一開始都是先當 IC
  ↳ IC（individual contributor）是自己動手做事、不帶人的成員。組織扁平代表層級少、決定得快。每個主管都先當 IC，就能真的懂第一線的工作。
• 07:52 技術爭論改成「code wins」：building is cheap, arguing is expensive（動手做很便宜，爭論很昂貴）
  ↳ 以前意見不同會先開會辯論，因為真的做出來很花工夫。現在做一個版本比開會吵還省事，所以乾脆直接做出來，看成品決定。
• 08:22 例子：她和 Boris 對重構方法有不同看法。她沒有拉 Boris 去白板討論，而是用 Claude 產生三個版本的 PR，拿來討論實作方式和對同事的影響
  ↳ 她和同事 Boris 對怎麼重構程式看法不同。她沒拉人到白板前爭論，而是請 Claude 做出三種版本，直接比較哪種寫法好、哪種對同事的影響最小。
• 08:22 有想法就先做 prototype，實際 dogfood 試用看看
  ↳ prototype（原型）是很快做出來的簡易版；dogfood 指自己團隊先當使用者，實際用自家產品。有點子就先做出來自己用用看，比光用想的準。
• 08:52 過去對 prototype 有兩派看法：一派認為能快速做出骨架、感受產品；另一派擔心 prototype 偷工減料，大家捨不得丟，最後把撐不住規模的東西直接上線
  ↳ 支持的人覺得原型能讓人很快摸到產品的手感。反對的人擔心原型做得草率，大家又捨不得丟，最後直接拿去上線，用的人一多就撐不住。
• 09:23 有了 Claude，prototype 是很好的起點，能快速迭代學習，也能更快把 prototype 擴展成 production
  ↳ production 是正式給用戶用的版本。現在原型做得快、改得也快，能邊做邊學；要補強成正式版，也比以前省力很多，所以兩派的擔心都變小了。
• 09:23 Claude Code 團隊減少了深入的規劃與 design doc，大部分討論都在 PR 或 prototype 上進行，因為寫程式不再是瓶頸
  ↳ design doc 是動工前寫的詳細設計文件。既然寫程式很快，與其花時間寫文件再討論，不如直接拿實際的程式修改或原型來討論，更具體也更快。
• 09:54 要加碼的是驗證：人力變多，更要重視怎麼驗證品質，她稱之為 shift left
  ↳ AI 等於多了很多人手，產出變多，省下的力氣要拿來把關品質。shift left（左移）就是把檢查提早：把流程想成由左往右，越左邊越前面，越早發現越好修。
• 10:24 比客戶先踩到 bug 更好的是她自己先踩到；比她先踩到更好的，是用自動化在更靠近源頭的地方抓到。團隊持續 shift left、擴大自動化
  ↳ 問題越晚發現代價越高。被用戶踩到最糟，她自己先踩到好一點，最好是程式一寫好就被自動化檢查攔下，不用靠人碰運氣。
• 10:24 「這是誰改的？」過去常被問。她建議先釐清背後真正的目的：找 regression 的來源、找人回答問題，還是想了解脈絡？再看看 Claude 能不能幫忙
  ↳ regression 是原本正常的功能被新修改弄壞。與其追問「是誰改的」，不如先想你真正要的是什麼：找出壞掉的原因、找人問問題，還是想了解來龍去脈？再看 Claude 能不能代勞。
• 10:55 她設了一個 routine，每天早上自動彙整各個回饋管道的意見，幫她找出主題，讓她邊喝咖啡邊看（Cat 早上也介紹了 routines）
  ↳ routine 是設定好時間、自動定期執行的 AI 任務。她讓 Claude 每天早上整理各個管道收到的意見、歸納出幾個主題，她喝咖啡時就能掌握狀況。
• 11:27 「怎麼跟上 code review？」在推出 Claude Code code review 之前常被問；這個工具幫團隊跟上寫程式的產出量
  ↳ 程式產出暴增後，人工審查一度成了最大的卡關點，常有人問怎麼看得完。Claude Code 的自動審查功能推出後，審查速度才跟得上寫程式的速度。
• 11:27 Claude 擅長的 review 項目：style 和 lint、明顯的 bug
  ↳ style 是寫法和格式有沒有統一；lint 是用工具自動抓格式問題和常見小錯。這類有明確規則的檢查，還有一看就知道的錯誤，很適合交給 Claude。
• 11:27 如果有 spec，建議把 spec check in 到 codebase，因為 Claude 很擅長檢查是否偏離 spec（spec drift）
  ↳ spec（規格）是說明東西該做成什麼樣子的文件，check in 是把它存進程式碼庫。規格和程式放在一起，Claude 就能比對實作有沒有慢慢偏離規格，這就是 spec drift。
• 11:57 code review 仍需要 human in the loop：法務審查、跟風險容忍度有關的事（尤其是 trust boundaries，要 trust but verify），以及產品判斷與品味
  ↳ human in the loop 指關鍵環節要有人把關。trust boundaries 是系統決定信任誰、信任哪些資料的界線，出錯就有安全風險。法律、風險和產品品味仍要人判斷：可以信任，但要查證。
• 12:27 設計師說那一點也不像雪人，反而像 Mr. Peanut（美國花生品牌的吉祥物）。她同意，這說明人的 product sense 很重要
  ↳ Mr. Peanut 是美國一個花生品牌的吉祥物，一顆戴高帽的花生。AI 能把東西做出來，但好不好看、像不像，還是要靠有眼光的人判斷，這就是 product sense（產品直覺）。
• 12:59 角色界線變模糊、Claude 在增強人的能力，她在工程上專注兩種人才輪廓，第一種是有 product sense 的 creative builder（本段到此結束）
  ↳ 既然 AI 在放大每個人的能力、分工又變模糊，她在工程團隊看重兩種人才。第一種是 creative builder：有產品直覺、能自己動手把想法做出來的人。第二種在下一段。

講者和 Boris 對重構方法有不同意見時，最後是怎麼進行技術討論的？