寫程式不再是瓶頸：Spotify 如何把開發者體驗擴展到團隊與 agent（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這段講 Spotify 怎麼讓 AI agent 在自家程式碼裡做得更好：統一技術、用 Backstage 集中管理、用自動檢查規範寫法，並量測所有環節。更值得看的是後半，講者發現寫程式已經不是卡點，真正的卡點變成人要做的決定。

• 13:50 換個主題：談 Spotify 怎麼優化 codebase，讓 agent 在他們的程式碼裡盡可能發揮效果
  ↳ 話題轉到：Spotify 怎麼整理自家的 codebase（公司所有程式碼的總和），讓 agent（能自己動手完成任務的 AI 助手）在裡面發揮得更好。
• 14:20 講者在 Spotify 待了 15 年。公司在他加入前就有這個信念：用的技術越少，速度越快
  ↳ 講者在 Spotify 待了 15 年。公司在他加入前就相信：用的技術越少、越統一，團隊反而跑得越快。這個想法比 AI 出現還早。
• 14:20 理由一：對一組技術非常熟、是深度專家，就能在上面做出更好的東西
  ↳ 第一個原因：只用少數幾套技術，大家就能真正鑽深、變成專家，做出來的東西品質自然比較好。
• 14:20 理由二：幫團隊省掉許多小決策，不用每做一樣東西都重新選技術，現成的技術組合通常就能解決問題
  ↳ 第二個原因：省掉一堆「這次要用哪個工具」的小決定。現成的技術組合通常就夠用，不用每做一樣東西都重新研究、重新挑。
• 14:51 理由三：比較好協作。別隊的元件跟自己的長得差不多，就容易貢獻；元件搬家或開發者換團隊時，環境看起來也差不多
  ↳ 第三個原因：好合作。別隊的東西跟自己的長得差不多，要幫忙改很容易；系統換人管或人換團隊時，也不用重新適應環境。
• 15:22 Spotify 典型的後端服務都很像：技術堆疊相同、design patterns 相近。多年來一直在推動更標準化的堆疊，減少不必要的變異
  ↳ 所以 Spotify 的後端服務都用同一套技術組合（standardized stack），design patterns（常用的程式結構寫法）也相近。多年來他們一直在減少各做各的情況。
• 15:52 仍保留一定程度的變異，用來實驗、評估新技術，但要有意識地做，不能隨便來
  ↳ 這不代表完全不准碰新東西。他們還是留空間試新技術，但要刻意、有計畫地試，不能每個人想用什麼就用什麼。
• 15:52 如果 Claude 能參考大量而且大致一致的程式碼，表現會更好；在比較碎片化的 codebase 裡，實際看得到 Claude 表現變差
  ↳ 關鍵在這裡：Claude 看得到大量寫法一致的程式碼，表現就比較好；在東拼西湊、風格很亂的程式碼裡，他們實際看到 Claude 變差。
• 16:26 Backstage 是 Spotify 的開發者入口網站，提供 single pane of glass。以前開發者大約要用 100 種工具（看部署、CI、A-B test 等），很混亂，而且都不太好用
  ↳ Backstage 是 Spotify 給工程師用的入口網站，主打 single pane of glass，也就是一個入口看全部。以前看部署、測試、A-B test 要切換約 100 種工具，又亂又難用。
• 17:02 Backstage 起源於一份軟體目錄（catalog）：production 上有數千個元件，要能知道每個元件的擁有者；發生 incident 時要 page 擁有團隊，以前連擁有者是誰都查不到
  ↳ 它一開始只是一份軟體目錄（catalog），記錄線上數千個元件各歸誰管。出事（incident）時要 page（緊急呼叫）負責的團隊，以前常常連該找誰都查不到。
• 17:36 多年下來，Backstage 圍繞這些元件長出很多工具。現在人類開發者要對軟體元件做任何操作，都在 Backstage 裡完成
  ↳ 後來圍繞這份目錄長出越來越多工具。現在工程師要對任何一個元件做事，都是進 Backstage 處理，不用再到處找。
• 17:36 這對 agent 一樣有用：這些功能以 MCP 或 command line tools 的形式開放給 agent，Claude 可以查某個東西的擁有者，需要時到 Slack ping 該團隊發問
  ↳ agent 也用得到。這些功能透過 MCP（讓 AI 接上外部工具的標準做法）或指令列工具開放給它，Claude 能自己查某個元件歸誰管，必要時直接到 Slack 問那個團隊。
• 18:10 規模變大後，Backstage 讓他們能掌握所有進行中的事情，同時也是推動標準化的手段
  ↳ 公司規模變大後，靠 Backstage 才看得到所有正在進行的事。它同時也是推動大家採用同一套做法的工具。
• 18:46 technology radar（字幕作 technology range radar）：列出所有可用技術和它們的狀態，例如推薦使用或不推薦使用
  ↳ technology radar 是一張技術清單，標出每項技術目前的狀態，例如「推薦用」或「不建議用」，讓人挑技術前先查一下。
• 18:46 golden state：針對特定類型的元件（例如某類後端服務、某類 iOS view）列出推薦的技術與實務做法
  ↳ golden state 更具體：針對某一類東西，例如某種後端服務或某種 iOS 畫面，直接列出建議用哪些技術、照哪些做法寫。
• 19:19 Backstage 裡有個叫 sound check 的 UI，讓團隊自我評估。舉例：某元件有一項要求是「定義有效的 owner」
  ↳ sound check 是 Backstage 裡的自我檢查畫面，團隊可以看自己的元件有沒有達標，例如「有沒有登記一個有效的負責人」。
• 19:49 這些做法推動了好幾年，讓 codebase 一致很多，也為現在的 AI 打好基礎
  ↳ 這些規範推了好幾年，原本是為了人而做，結果讓程式碼變得一致很多，剛好成了現在導入 AI 的地基。
• 19:49 再結合靜態分析和 linting，把規範做成 codebase 裡的檢查。Claude 工作時能立刻知道自己有沒有用對技術和 design patterns
  ↳ 再加上靜態分析和 linting（不執行程式，自動掃描有沒有違反規則），把規範變成自動檢查。Claude 一寫偏，馬上就知道該改用哪種技術和寫法。
• 20:19 例子：Claude 如果用了對 Spotify 基礎設施不理想的方式呼叫 gRPC，lint 系統會給回饋讓它修正；講者常看到 Claude 跑這些 lint 檢查並自我修正
  ↳ 舉例來說，gRPC 是服務之間互相呼叫的一種方式。Claude 如果用了不適合 Spotify 系統的呼叫法，lint 會跳出提醒。講者常看到 Claude 自己跑檢查、自己改好。
• 20:49 總結一：有了 agent，對扎實工程實務的需求並沒有消失，跟以前一樣重要
  ↳ 第一個結論：有了 agent，不代表可以不管工程基本功。測試、規範、檢查這些扎實的做法，跟以前一樣重要。
• 20:49 Boris 當天早上提到驗證（verification），他們完全同意。程式碼有完善測試，而且 agent 能呼叫這些測試（本機跑的 Claude，或 Honk 搭配驗證工具），agent 就能更自主、做出更好的解法
  ↳ 他們同意當天早上 Boris 講的驗證（verification），也就是讓 agent 自己跑測試確認對不對。測試寫得完善、agent 又能自己去跑，它就能更獨立，解法也更好。
• 21:21 總結二：codebase 保持一致，並明確定義開發者和 agent 該怎麼做，至少在 Spotify 的經驗裡，agent 會表現好很多
  ↳ 第二個結論：程式碼保持一致，再把「人和 agent 該怎麼做」寫清楚，至少在 Spotify 的經驗裡，agent 的表現明顯好很多。
• 21:53 總結三：盡量量測開發者體驗的每個面向，所有基礎設施和 PR 都有 instrument；這場演講展示的部分數字就來自這些資料
  ↳ 第三個結論：開發體驗的每個環節都盡量量化。所有系統和 PR（提交程式修改、請人審核合併的申請）都有 instrumentation（埋點記錄數據），演講裡的數字就是這樣來的。
• 22:23 總結四：人類判斷跟以前一樣重要，速度變快後甚至更重要，但要找出該把它用在哪裡
  ↳ 第四個結論：人的判斷沒有變得不重要，速度變快後反而更關鍵。難的是想清楚，要把人的判斷用在哪些環節。
• 22:23 PR 頻率上升的另一面是要 review 的 PR 多了 76%；目前開發者最常見的回饋之一就是要 review 的 PR 實在太多
  ↳ 代價是 PR 變多，要 review（人工審核）的量也多了 76%。工程師現在最常反映的問題之一，就是要審的東西多到審不完。
• 23:01 不會每個 PR 都由人 review：已經開始自動核准一些他們認為夠安全、不需人工 review 就能 merge 的 PR，把人力集中在真正重要的地方
  ↳ 所以不再每個 PR 都由人看。判斷夠安全的就 auto-approving（自動核准）直接合併，把人的注意力留給真正重要的修改。
• 23:31 之後會持續摸索哪裡需要人類判斷，呼叫 agent 之前和之後都會有
  ↳ 接下來會繼續找出哪些地方非得有人把關，可能是在交代 agent 做事之前先定方向，也可能是做完之後檢查結果。
• 23:31 總結五：寫程式已經不太是瓶頸。以前產品開發流程主要在等開發者實作功能（早期驗證或上線），這是公司的主要瓶頸之一，現在開始減少，但還沒完全消除
  ↳ 第五個結論：寫程式已經不太是 bottleneck（卡點）。以前做產品常卡在等工程師把功能做出來，現在這種等待變少了，但還沒完全消失。
• 24:01 Spotify 的點子多到永遠做不完，所以要驗證哪些點子合理，其中一種方法是做原型；以前原型很貴，得先說服一群開發者幫你做
  ↳ Spotify 的點子多到做不完，得先驗證哪些值得做，做 prototype（能實際試用的簡易版本）就是一種方法。以前做原型很貴，得先說服一群工程師幫你做。
• 24:37 Claude（字幕作 Cloud）和 agent 讓任何人都能直接在實際的 production codebase 裡做原型
  ↳ 現在有了 Claude 和 agent，任何人都能直接在真正上線的程式碼上做原型，不用另外搭一套假的。
• 25:12 做法：在 client monorepo 開啟 Claude，透過他們做好的一組 skills 和基礎設施，用 prompt 讓 Claude 做出想試的功能
  ↳ 做法是在 client monorepo（把 App 端程式碼放在同一個倉庫）裡打開 Claude，搭配他們做好的一組 skills（預先準備好的能力包）和基礎設施，用文字描述想試的功能。
• 25:12 做完會拿到一個 app，可以裝在自己的裝置上測試，也能分享給 Spotify 內部的人，實際感受這個點子用起來如何
  ↳ 做完會得到一個真的 App，可以裝到自己的裝置上試用，也能分享給公司同事，大家實際用過再判斷點子好不好。
• 25:48 原型製作從原本可能要好幾天或好幾週，縮短到只要幾分鐘；做原型的人包括他們其中一位 CEO
  ↳ 做原型從好幾天、甚至好幾週，縮短到只要幾分鐘。動手做原型的人裡，還包括他們其中一位 CEO。
• 25:48 上線用的 production 開發也是同樣情況，但這會讓限制轉移到別的地方
  ↳ 做正式上線的功能也同樣變快了。但這不代表從此一路暢通，卡點只是換到別的地方。
• 26:20 瓶頸轉移到產品開發的其他環節，尤其是需要人類決策的地方，例如決定要 ship 什麼給使用者、要探索哪些點子
  ↳ 新的卡點在需要人拍板的環節，例如要把哪些功能推給使用者、哪些點子值得繼續探索。
• 26:20 以前受限於開發速度，不用做那麼多決策；限制解除後，需要更好、更有效的決策方式
  ↳ 以前工程速度慢，一次能做的事有限，自然不用做太多決定。現在做得快了，決策也得更好、更有效率才跟得上。
• 26:50 他們正在調整規劃工作和做決策的方式，目前還在持續學習、做實驗
  ↳ 他們正在調整規劃工作和做決定的方式，目前還在邊試邊學，沒有定案的標準答案。
• 26:50 講者認為大約六個月後，他們打造產品的方式會跟以前非常不同
  ↳ 講者預估大約半年後，他們打造產品的方式會跟以前非常不同。
• 27:20 結尾：想試用 Fleet Shift 和 Home（字幕原文）的話可以去看看
  ↳ 最後講者邀大家去試 Fleet Shift 和 Home。這兩個名稱照字幕原文，影片在這段沒有說明它們是什麼。

講者提到 PR 頻率上升帶來的副作用是什麼？