DoorDash 讓每位員工都用上 Claude Code（第 2/2 段）

🧑‍🏫 這是 DoorDash 分享讓全公司使用 Claude Code 的後半段。Claude Code 是 Anthropic 的 AI 寫程式工具。這段講的不是工具怎麼操作，而是 AI 讓寫程式變快以後，團隊編制、審查流程、成效怎麼算、怎麼推廣都得重新想。想在自己的團隊或公司推 AI 的人，可以直接拿來參考。

• 12:35 學到的第一件事：小團隊能大幅加速，每個人負責一到數個領域，彼此不必花太多力氣協調
  ↳ 團隊小、每人各管一塊，就不用常常開會對齊。AI 讓一個人能負責的範圍變大，人跟人之間的協調反而最拖時間。
• 13:05 事先投資、把 code base 整理成對 agent 友善的狀態，是值得的
  ↳ code base 是一個產品的全部程式碼；agent 是會自己讀程式、動手修改的 AI。先把程式碼整理到 AI 容易看懂，後面能省下更多時間。
• 13:05 成功案例：一位 tech lead 把他在意的 50 多條架構原則寫成 markdown 檔放在 GitHub repo 裡，讓 agent 寫程式時可以參考，效果非常好
  ↳ tech lead 是帶頭的資深工程師。他把 50 多條寫程式的規矩寫成 markdown（一種簡單的純文字格式），放進 GitHub repo（存放程式碼的地方），AI 寫程式時就會照著做。
• 13:35 整個團隊統一使用同一套 skills 也很有幫助
  ↳ skills 是事先寫好、可以重複呼叫的做事步驟。全隊用同一套，AI 做事的方法就一致，不會每個人各搞一套。
• 13:35 例子：mobile 團隊做了 skills，能輕鬆開啟 simulator、測試特定流程，原本要工程師手動設定的麻煩事，變成呼叫一下就能在背景執行
  ↳ mobile 指手機 App；simulator 是在電腦上模擬手機的程式。以前開模擬器、點到要測的畫面都得手動設定，現在叫一下 AI 就會在背景自己跑。
• 14:08 遇到的挑戰：面向使用者的功能需要跨部門共識（設計要對齊、產品要確認解決的是對的問題），跟單純的平台改動或 code migration 不一樣
  ↳ code migration 是把舊程式搬到新架構。這類內部改動工程師自己決定就好，但使用者看得到的功能，要先跟設計、產品部門談好才能做。
• 14:08 product review、ship review、design review 等流程過去有其重要性，現在卻成了很大的摩擦點
  ↳ product review、ship review、design review 分別是審產品方向、上線前、設計的會議。以前用來把關品質，現在工程變快了，反而是等開會最花時間。
• 14:38 想吃到 AI 帶來的速度，不只是工程問題而是全公司的問題，跨部門主管也要一起改變工作方式
  ↳ 工程師再快，只要設計、產品、主管還照舊流程簽核，整體速度就不會變。所以其他部門的主管也得跟著改做法。
• 14:38 要能接受 product review 不照以前的方式進行，甚至重新思考是否還需要 product review
  ↳ 連「還要不要開審查會」都可以拿出來討論，不把舊流程當成理所當然。
• 14:38 過去工程師要花很多時間把設計做到 pixel perfect；現在工程師做到可用的狀態，再交給設計師自己完成 pixel perfect
  ↳ pixel perfect 是畫面的每個像素都跟設計稿一模一樣。現在工程師先做出能用的版本，最後的細節由設計師自己動手調。
• 15:09 大致觀察：團隊或個人越能自給自足，動得越快
  ↳ 越不需要等別人點頭或幫忙的人，做事越快。
• 15:09 推動的理念：少流程、少 design doc、少 review；設計師直接做 prototype、直接改 code
  ↳ design doc 是動工前寫的設計說明文件；prototype 是可以實際操作的雛型。設計師不再只畫圖交給工程師，而是自己做雛型、自己改程式。
• 15:39 有些流程有重要理由（例如合規），但可以問團隊：若要把時程縮短 3 倍，怎麼用 agents 自動化或加速？
  ↳ 合規（符合法規要求）這類流程不能省，但可以換個方式問：如果時程要縮成三分之一，哪些步驟能交給 agent 自動處理？
• 15:39 心態轉變：不需要每個人都是領域專家，反而應鼓勵大家在 code base 各處靈活移動
  ↳ 以前每個人守著自己專精的一小塊；現在有 AI 幫忙，公司鼓勵大家跨到不熟的區塊做事。
• 16:10 鼓勵 mobile 工程師往 full stack 發展，這件事比一年前容易許多
  ↳ full stack 是從使用者看到的畫面到後端伺服器都會做。以前手機工程師很難跨到後端，現在有 AI 幫忙，門檻低很多。
• 16:10 仍需要 iOS 等領域專家負責記憶體管理、latency、效能等架構問題，但人數可以少很多，由他們當把關者
  ↳ iOS 是 iPhone 的作業系統；latency 是反應延遲。記憶體、效能這類深入的問題還是需要專家，但只要少數人負責把關就夠了。
• 16:10 領域專家可以建 agents 自動檢查他們在意的事，或把架構原則寫進 MD 檔；其他人則當通才
  ↳ MD 檔就是 markdown 檔。專家把自己的經驗做成自動檢查工具或寫成規則文件，其他人當什麼都做一點的通才，靠這些規則避免出錯。
• 17:12 實驗團隊的組成：讓成員覺得可以放心實驗，並請工程或相關部門的高層（EVP 等級）直接贊助該 workstream，協助排除障礙
  ↳ EVP 是執行副總這類高層；workstream 是一條專案工作線。有高層直接撐腰，實驗團隊遇到卡關時才有人能拍板解決。
• 17:42 一開始行不通的做法：要人做實驗，卻讓他們維持原本工作的框架，結果很快就放棄
  ↳ 要人做實驗，卻還用原本的工作要求綁著他們，大家根本忙不過來，很快就退回舊的做法。
• 17:42 做法：除了給 token 預算，也請團隊向跨部門領導層提出「寫 code 以外」有哪些事卡住他們
  ↳ token 是 AI 計算用量的單位，token 預算就是使用 AI 的額度。除了給額度，也請團隊直接告訴主管：寫程式以外，哪些流程或簽核卡住他們。
• 18:12 還在摸索怎麼擴大規模；理想做法是把成功案例寫成書面文件分享給各主管，讓大家自然跟進
  ↳ 怎麼擴大到全公司還沒有標準答案。目前的想法是把成功經驗寫成文件給各主管看，讓他們看到效果後自己想跟進，而不是硬性規定。
• 18:12 過去限制因素是寫 code 的速度，它決定了交付速度、團隊編制、組織 review 流程和高層 check-in 的頻率
  ↳ 以前寫程式最慢，所以團隊要多少人、審查怎麼安排、高層多久追一次進度，都是配合這個速度設計的。
• 18:43 工程變快之後，一切都得重新思考；3 到 5 人的團隊能做的事多很多，若能讓他們快 3 到 5 倍，對組織來說會徹底改變局面
  ↳ 寫程式不再是瓶頸，整個組織的運作方式就得重想。3 到 5 人的小團隊如果快了 3 到 5 倍，就能做到以前大團隊才做得到的事。
• 19:13 ROI：旅程剛開始時盡量多給 token 讓大家實驗，現在比較著重 ROI
  ↳ ROI 是投資報酬率，也就是花的錢換回多少效益。一開始不太計較花費，讓大家盡量試；現在開始算這些 AI 費用值不值得。
• 19:13 工程的 ROI 比較好衡量：code throughput 不是完美指標、也可能被刷數字，但方向大致正確
  ↳ code throughput 是程式碼的產出量。量多不代表品質好，也可能有人灌數字，但大方向還是看得出有沒有變快。
• 19:13 同一個專案能用更少人更快完成，所以會希望現有人員盡量多用
  ↳ 同一個專案能用更少人、更快做完，所以公司希望現有員工盡量多用 AI。
• 19:43 知識工作還在早期；Cowork 除了整理 email 之外還有很多用途，目前只摸到皮毛
  ↳ 知識工作指業務、行銷、營運這類不寫程式的工作。Cowork 是 Claude 用來處理一般文書工作的工具，能做的不只整理信件，大家才剛開始摸索。
• 19:43 例子：業務團隊要替數萬家商家做 QBR，手動工作很多，若能用 AI 簡化並讓結果更準確、一致，會非常有用
  ↳ QBR 是每季的業務檢討報告。要替幾萬家店家各做一份，靠人工整理很累、品質也不一致；交給 AI 能省時間，結果也更準確、一致。
• 20:14 知識工作 ROI 的兩個看法之一：拉高基準線，看每個人在共通任務上省下多少時間
  ↳ 第一種算法：看每個人在人人都會做的日常工作上省了多少時間，等於把所有人的基本效率一起拉高。
• 20:14 之二（可能影響更大）：以部門或領域為單位，找出可以自動化的特定 workflow，讓部門運作效率大幅提升
  ↳ 第二種算法可能影響更大：挑某個部門特有的一整套工作流程（workflow），整套自動化，讓整個部門的運作效率大幅提升。
• 20:44 工程衡量的是 code throughput 和交付速度；終極成功指標是客戶更快看到產品上線、更快拿到價值，不只是 code 被 merge
  ↳ merge 是把寫好的程式合併進正式版本。程式合進去還不算成功，要客戶真的更快用到新功能、得到好處才算。
• 21:14 知識工作還在摸索、依領域而定；以 DoorDash 的規模，每個人就算只提升 10% 生產力也很可觀
  ↳ 非工程工作怎麼衡量還沒有定論，每個部門也不一樣。但 DoorDash 規模很大，每個人只要進步一成，加起來就很可觀。
• 21:44 由上而下指定要自動化哪個 workflow，可能挑錯流程或挑錯人；給大家自由實驗，才會發現原本不知道的瓶頸
  ↳ 由上而下直接指定要自動化哪件事，可能挑錯流程或挑錯人。讓大家自由試，才會發現原本不知道的卡點。
• 21:44 內部在各領域（業務、行銷、營運、客服）找出「AI champions」：那些自發、利用空閒時間大量使用這些工具的人
  ↳ AI champions 是各部門裡自己愛用 AI、連空閒時間都在研究的人。公司找出他們，當成推廣 AI 的種子。
• 22:15 請 champions 找出領域內的痛點，用 agents 簡化 workflow，或做一套共用 skills 讓同事也能更有效率
  ↳ 請這些人找出部門裡最麻煩的工作，用 agent 簡化流程，或做成共用的 skills，讓同事直接拿去用。
• 22:45 怎麼找到適合的人：先把工具交給大家，看誰自然上手；這些人很興奮，會主動在 Slack 頻道等地方分享
  ↳ 不用刻意挑人，先讓所有人都能用，會用的人自然會冒出來。他們很興奮，會主動在 Slack（公司內部通訊軟體）分享心得。
• 23:15 找 champion 不難，特別是非技術端；技術端則是自然出現 power users
  ↳ 非技術部門的熱衷者很好找；工程部門則會自然出現 power users，也就是用得特別深、特別多的重度使用者。
• 23:45 給工程領導者的建議：自己先用 AI，才能帶動團隊，也能體會工程師改變工作方式時的焦慮和壓力
  ↳ 主管自己不用 AI，就帶不動團隊，也很難體會工程師改變工作方式時的不安和壓力。
• 23:45 對工程師來說這有點像身分認同危機，很多人對自己寫的 code 有工匠情感，但需要放下一些
  ↳ 很多工程師把親手寫出好程式當成自己的價值。現在要改成讓 AI 寫、自己負責把關，心理上需要調適。
• 24:15 鼓勵大家分享書面文件，這是大規模傳播經驗最可擴展的方法，而且這些文件 agents 也能讀
  ↳ 把經驗寫成文件，比一個一個口頭教更容易大範圍傳開；而且這些文件 AI 也讀得懂，可以直接當成工作參考。
• 24:15 給新鮮人的建議：保持好奇，多玩這些工具
  ↳ 給新鮮人的建議很簡單：保持好奇，多動手玩這些 AI 工具。
• 24:45 DoorDash 期待從小就習慣這種工作模式的新鮮人，能用意想不到的方式運用技術
  ↳ 一開始工作就習慣跟 AI 合作的新人沒有舊習慣包袱，可能想出前輩想不到的用法。

根據影片，DoorDash 一位 tech lead 怎麼讓 agent 在寫程式時遵守架構原則？