經營一個 AI-native 的工程組織（第 1/2 段） ☕ Buy me a coffee

🧑‍🏫 這是 Claude Code 負責人 Fiona Fung 的演講前半段。她的重點是：AI 讓寫程式變得又快又便宜之後，卡住進度的地方換到別處，團隊很多老規矩也該跟著改。就算你不是工程師，只要你的工作也被 AI 加快了，她講的「以前有用的做法現在可能沒用」一樣用得上。

• 00:11 講者 Fiona Fung 負責 Claude Code 與 Cowie（字幕原文）的工程與產品，和 Boris、Cat 密切合作
  ↳ 講者 Fiona Fung 同時管 Claude Code（Anthropic 讓 AI 直接幫你寫程式的工具）和字幕寫作 Cowie 的產品，工程和產品兩邊都負責，平常跟 Boris、Cat 密切合作。
• 00:42 加入 Anthropic 之前，她在 Meta 和 Microsoft 帶過團隊，也把團隊帶大
  ↳ 她不是第一次帶團隊。之前在 Meta、Microsoft 當過主管，也把團隊從小帶到大，所以她是用過來人的角度在比較新舊做法。
• 01:13 演講分五個主題：瓶頸移動了、要改寫哪些團隊規範、怎麼推行、哪些訊號代表方向正確、她自己還沒解的問題與給聽眾的建議
  ↳ 整場分五段：先講卡住進度的地方換了，再講哪些團隊習慣要改、怎麼推動、怎麼判斷改對了，最後坦白她還沒想通的事，也給聽眾建議。
• 01:13 這份簡報大約一個月前做的，內容已經要改。例如當時還沒有 routines，連她自己的工作方式都不一樣
  ↳ 變化快到簡報一個月就過時。例如那時還沒有 routines（讓 Claude 定時自動做固定工作的功能），連她自己的工作方式都已經換了。
• 02:13 反覆出現的一句話：「以前對你有用的做法，現在可能不再有用」。她認為持續保持成長心態是很重要的能力
  ↳ 她一直提醒：過去讓你成功的方法，現在可能沒用了。所以最重要的不是某個技巧，是願意一直重新學、隨時調整做法的心態。
• 02:13 去年她剛開始 live coding 時，模型還會犯像「到處用常數」這種不好的工程習慣，現在能力已經強很多
  ↳ 一年前 AI 寫程式還會犯新手錯，像是把數字寫死、到處亂用常數。現在品質好很多，這正是團隊做法得跟著改的前提。
• 02:44 過去多年，工程人力和寫程式的產能是最貴的資源，waterfall、agile 等規劃流程都是圍繞這點設計的
  ↳ 以前工程師的時間最貴，所以 waterfall（先全部規劃好再照順序做）和 agile（分成短週期、邊做邊調整）這些方法，其實都是在想辦法省工程人力。
• 03:44 產業一直在調整：她做 Visual Studio 2005 時軟體要壓 CD-ROM（更早是軟碟），截止日很硬；後來能線上發佈，出貨方式也跟著改變
  ↳ 做法本來就會跟著環境變。以前軟體要壓成光碟出貨，截止日一過就改不了；後來能線上更新，出貨方式就整個改變。AI 是又一次這樣的轉變。
• 04:14 在 Claude Code 團隊，寫程式很少是慢的環節，而且產出量大幅增加
  ↳ 在她的團隊，「寫程式」已經很少是拖慢進度的那一步，產出的程式量也比以前多很多。
• 04:45 以前寫程式、寫測試、重構都很貴，重構還得跟產品工作搶時間排進度。現在這些都不再是瓶頸
  ↳ 以前寫程式、寫測試、refactoring（功能不變，只把程式整理乾淨）都很花工，整理還得跟新功能搶排程。現在這些都不再卡關了。
• 05:16 新的瓶頸轉到：驗證、審查（review）、跨職能夥伴、資安。常見的問題是「這段程式對嗎？誰來 review？」
  ↳ bottleneck（拖慢整體的環節）移到後面去了：確認程式對不對、有人檢查、跟其他部門配合、資安。大家常問的變成「這對嗎？誰來看？」
• 05:16 其他工程主管最常問她：人類怎麼跟得上 code review 的量
  ↳ AI 寫得飛快，但程式照理要有人檢查過才能上線。其他主管最常問她的就是：人看的速度怎麼追得上 AI 產出的速度？
• 05:47 產生大量程式碼變容易了，所以也要考慮後續的維護成本
  ↳ 程式變得很容易生出來，可是每一行之後都要有人維護、修 bug。寫得越多，以後要顧的東西就越多，不能只看產量。
• 05:47 流程會「悄悄失效」：流程很少自己消失，大家只會一層一層往上疊
  ↳ 流程很少自己消失，只會一層一層往上加。很多規定早就沒有意義了，卻沒人拿掉，就這樣默默拖慢大家。
• 06:19 例子：某團隊有太多 SLA（例如 P0 bug SLA），多到得替 SLA 排優先順序，她因此覺得該開始精簡流程
  ↳ SLA 是「某類問題要在多久內處理完」的承諾，P0 bug 通常指最緊急的問題。規定多到還得排哪條先守，就代表流程該精簡了。
• 06:50 可能失效的流程包括：規劃規範（以前因為寫程式貴，事前規劃花很多時間）和程式碼歸屬（誰寫的、誰負責）
  ↳ 以前寫程式很貴，所以動手前要花很多時間規劃，也會清楚劃分「誰寫的、誰負責」。這兩件事到了 AI 時代都可能不再適用。
• 06:50 也包括 code review 和團隊組成：角色界線變模糊，她的非工程夥伴也都在 ship code
  ↳ code review（寫好的程式先給別人檢查）和團隊分工也在變。職位界線越來越模糊，她身邊的非工程夥伴現在也會自己送程式上線。
• 07:21 知識分享和新人 onboarding 的做法，也是 Claude Code 團隊觀察到正在改變的地方
  ↳ 新人怎麼上手、團隊怎麼互相分享知識，她的團隊也觀察到這些做法正在改變。
• 07:51 Claude Code 團隊改寫的規範：code review（哪些真的需要人類判斷）、onboarding、規劃、招募、組織形態
  ↳ 她的團隊實際改寫了五塊規矩：哪些 review 真的需要人判斷、新人上手、規劃、招人，還有組織怎麼編。
• 07:51 組織形態是她「最愛的辛辣話題」。她在 Anthropic 提出想法時，有位招募夥伴覺得她瘋了
  ↳ 她對組織該怎麼編有很大膽的想法，大膽到公司的招募同事聽了覺得她瘋了。這一段還沒講具體內容。
• 08:21 規劃做得少很多，改採她所謂的 JIT planning。當初寫的六個月 roadmap 大約只撐三個月，過完新年很多事就變了
  ↳ 規劃少了很多，改成她說的 JIT planning（需要時才規劃）。她寫過六個月的 roadmap（未來幾個月的計畫表），三個月後就不管用了。
• 08:51 原則是在對的時間做剛好份量的規劃，因為原型和程式碼生成已經不像以前那樣是瓶頸
  ↳ JIT 本來是指程式跑到那一步才即時編譯。她借這個詞表示：既然做原型很便宜，就不必事先想透，到了該做的時候規劃剛好夠用的量就好。
• 08:51 技術爭論時，程式碼說了算。她剛加入時想做重構，和 Boris 對做法有不同意見
  ↳ 技術上有歧見時，不比誰比較會講，直接把東西做出來比較。她剛加入時想整理一段程式，做法就跟 Boris 不同。
• 09:23 她原本想拉 Boris 去白板討論，後來改成直接生成討論中的三個方案，做成三個 PR
  ↳ 以前會拉人去白板前畫圖討論。她改成讓 Claude 把三種做法都寫出來，各做成一個 PR（pull request，一包送給別人審的程式修改）。
• 09:23 有 Claude 生成三個版本，雙方不只能比較 API 的實作，還能看到對所有呼叫端的影響
  ↳ 三個版本擺在一起，除了比做法本身，還能看到每個改動會牽動程式裡其他哪些地方，比空口討論具體得多。
• 09:54 蓋東西便宜、爭論昂貴，所以更需要建立團隊對齊的文化
  ↳ 做東西變便宜了，花時間爭論反而最貴。所以團隊更需要一套「大家怎麼一起做決定」的共識。
• 09:54 不能變成「最後 check in 的人贏」，例如熬夜送 PR，或設 routine 來搶最後一句話，這絕對不行
  ↳ 不能變成誰最後送出誰就贏，例如熬夜偷送修改，或設自動任務搶著蓋掉別人的版本。這不叫意見一致，是搶地盤，她說絕對不行。
• 10:24 Claude Code 團隊大幅減少「寫 code 前先寫 design doc」的儀式。不過某些團隊和情境（例如非同步討論）design doc 仍然重要
  ↳ design doc 是動手前先寫的設計說明文件。她的團隊大多省掉了；但有些團隊，或大家不同時在線、要靠文件溝通時，還是需要。
• 10:54 Claude Code 多數討論用 PR 取代文件，團隊口號是「有想法就去做原型」
  ↳ 大部分討論直接拿 PR 來談，不另外寫文件。團隊口號是「有想法就先做原型」，看得到、摸得到的東西比文字好討論。
• 10:54 產品審查也做得不多，因為環境變化很快。做法是先做原型、讓大量內部員工（ants）試用，再釋出給外部使用者收回饋
  ↳ 產品審查會也很少開，因為變化太快。做法是先做原型，給大量內部員工（字幕稱 ants）試用，再開放給外部使用者、收回饋。
• 11:24 加碼投入的是驗證：產出量不同了，也出現新的出錯方式，要想辦法規模化
  ↳ 省下的力氣改投在驗證上：程式量暴增，也出現以前沒有的出錯方式，要想辦法讓檢查跟得上這個規模。
• 11:24 Shift left：用更多自動化在更接近源頭的地方抓到 bug，而不是等使用者發現
  ↳ shift left 的意思是把抓錯的時間點往前移：靠自動化在程式剛寫好時就抓到 bug，不要等使用者踩到才發現。
• 11:54 角色模糊後（例如設計師也在送 code），要讓每個人不分角色，對自己送出的變更都更有信心
  ↳ 連設計師都在送程式了，所以要讓每個人不管什麼職位，送出修改前都能更有把握自己沒弄壞東西。
• 11:54 她自己的例子：修了 resume 相關的 bug，隔天在 Boris 的討論串看到有人回報 bug，當下心一沉
  ↳ 她自己也遇過：修了一個跟 resume 功能有關的 bug，隔天就在 Boris 的討論串看到有人回報 bug，當下心一沉。
• 12:25 所有 PR 都有 Claude 協助，所以「這是誰改的？」變成有點奇怪的問題
  ↳ 每個 PR 都有 Claude 參與，「這是誰改的？」就變得很難回答：算按下送出的人，還是算 Claude？
• 12:25 建議 double click，想清楚真正要問的是什麼：誰造成 regression（不是要究責）、找專家回答客戶問題，還是想了解脈絡
  ↳ double click 就是再往下想一層：你問「誰改的」，其實是想找出哪次修改把東西弄壞（regression，不是要究責），還是要找懂的人回答客戶，或是想了解來龍去脈？
• 12:56 想清楚真正的問題後，再看看能不能自動化
  ↳ 真正要問的是什麼想清楚了，常會發現這件事可以交給自動化，不用每次都找人問。
• 12:56 例子：她以前每天早上配咖啡，手動讓 Claude 摘要客戶回饋頻道，現在改用 routines 自動設定好
  ↳ 她以前每天早上邊喝咖啡，邊手動叫 Claude 整理客戶回饋頻道的重點；現在用 routines 設定好，每天自動整理。
• 13:27 程式碼歸屬變得比較模糊，但可以追問真正要回答的問題，再看 Claude 能怎麼幫忙
  ↳ code ownership（程式歸誰負責）是變模糊了，但做法一樣：先問清楚你真正想知道什麼，再看 Claude 能幫上哪一段。
• 13:57 Code review 方面，團隊大量使用 Claude code review（Kat 在今早 keynote 講過）
  ↳ code review 的部分，團隊大量讓 Claude 來做。Kat 在當天早上的主題演講已經講過這塊。
• 13:57 值得思考的是哪裡可以高度信任 Claude、哪裡仍需要人類。Claude 也很擅長照看（babysitting）PR
  ↳ 該想的是：哪些檢查可以放心交給 Claude、哪些一定要人來判斷。她也說 Claude 很會 babysitting PR（字面是「顧 PR」，字幕沒再細講）。

Fiona 剛加入 Claude Code 團隊時，和 Boris 對重構方式有不同意見，她最後怎麼處理？