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

🧑‍🏫 Spotify 的講者 Niklas 分享一家約 3,000 名工程師的公司，導入 AI 寫程式工具後發生的變化：大家寫得更快，但程式越多，要維護的也越多。影片的重點是他們怎麼用 Fleet Shift 和 Honk，把升級、換介面這類苦差事交給機器批次處理。如果你想知道 AI 在大公司裡除了幫忙寫新東西，還能怎麼省下人力，這支很值得看。

• 00:00 講者 Niklas 介紹 Spotify 如何因應 AI 轉型
  ↳ 講者 Niklas 在 Spotify 工作。這段是開場，預告要分享在 AI 改變寫程式的方式之後，Spotify 的組織和工具怎麼跟著調整。
• 00:32 Spotify 工程組織規模接近 3,000 名工程師，多年來持續優化開發者體驗，讓部署、交付變更越簡單越好
  ↳ Spotify 約有 3,000 名工程師。公司多年來投資「開發者體驗」，也就是讓工程師把改好的程式送上線時越順越好，少卡關、少手續。
• 01:03 程式庫混合 monorepo 與 polyrepo：後端是 4,000 萬行程式碼的 monorepo，另外還有數千個較小的 polyrepo
  ↳ monorepo 是把大量程式放進同一個大倉庫；polyrepo 是拆成很多小倉庫分開管。Spotify 兩種都有：後端是 4,000 萬行的大倉庫，另有數千個小倉庫。
• 01:40 內部常推出各種提升生產力的工具，但從沒看過像 AI 寫程式工具這麼快的採用速度
  ↳ 公司內部推新工具，通常要慢慢推廣、說服大家用。AI 寫程式工具卻是工程師自己搶著用，普及速度是他們從沒見過的。
• 02:10 現在超過 99% 的工程師每週都在用 AI 寫程式工具
  ↳ 幾乎每位工程師每週都在用，表示 AI 已經不是少數人嘗鮮的玩具，而是日常工作的基本配備。
• 02:10 最新一次的內部工程師問卷中，94% 的工程師表示 AI 工具讓他們更有生產力，自評生產力也創下新高
  ↳ 這是工程師自己填的問卷，反映的是主觀感受。不過 94% 覺得更有生產力，自評分數又創新高，至少代表大家普遍覺得做事變快了。
• 02:40 用 PR 頻率當作交付速度與交付量的代理指標，目前 PR 頻率增加 76%，而且數字還在持續上升
  ↳ PR（pull request）是「我改好一段程式，請審核後併入」的申請。PR 頻率增加 76%，他們拿它間接代表交付變快、變多，而且數字還在往上。
• 03:13 現在絕大多數出貨的 PR，都是由 AI agent 和開發者共同撰寫
  ↳ AI agent 指能自己連續完成多個步驟的 AI。現在大多數上線的改動，都是 AI 寫一部分、工程師檢查修改一部分，兩邊一起完成的。
• 03:13 PR 數量原本長期緩慢成長，到了 Opus 4.5 發布前後才出現跳升
  ↳ PR 數量原本多年來慢慢爬升，到較強的模型推出前後才突然跳一階。可見真正帶來轉折的，是模型能力跨過某個門檻。
• 03:48 程式碼也隨之爆炸性成長。其實在 AI 之前，他們就發現正式環境的程式碼成長速度遠快於工程師人數成長
  ↳ 他們在 AI 出現前就發現，程式碼增加的速度遠遠快過工程師人數增加。AI 讓程式寫得更快，這個落差只會越拉越大。
• 03:48 結果工程師花在維護既有程式碼的時間越來越多，能拿來開發新功能、為使用者創造價值的時間越來越少
  ↳ 程式寫出來就要有人照顧，就像房子蓋得越多，要修繕的地方越多。人手跟不上，時間被維護吃掉，做新功能的時間就被擠掉了。
• 04:22 於是 Spotify 開始盡量把維護工作自動化，例如版本升級、淘汰 API、修補資安漏洞這類無聊但必要的事
  ↳ API 是程式之間互相呼叫的介面。升級版本、淘汰舊介面、補資安漏洞，都是沒人想做、不做又會出事的工作，所以他們想交給自動化。
• 04:22 過去的做法是把遷移指引發給數百個團隊（例如升級 Java 版本），跨數千個元件做完一次通常要好幾個月
  ↳ migration（遷移）是把程式從舊做法搬到新做法，例如換 Java 版本。以前是發說明給幾百個團隊各自改，數千個元件全部改完要好幾個月。
• 04:58 當時的工程師問卷中，遷移（migration）是開發者最不滿的第一名
  ↳ 工程師最不滿的事第一名就是遷移。它會打斷手上的工作，又不會帶來新東西，這成了他們下決心解決的動機。
• 05:29 新構想是不再逐一處理元件，而是一次改動整批（fleet）元件。這套基礎設施叫 fleet management，底層系統叫 Fleet Shift
  ↳ fleet 原意是艦隊，這裡指一整批元件。fleet management 是一次對整批元件套用同一個改動，負責執行的底層系統叫 Fleet Shift。
• 05:59 這些 PR 絕大多數是自動合併（auto merge），流程中沒有人介入：自動化建立 PR、驗證 PR 可以安全合併，然後直接合併
  ↳ auto merge 是自動合併：系統自己開 PR、自己檢查改了不會出錯，然後直接併進去，全程沒有人審。前提是自動檢查要夠可靠。
• 05:59 每天都會交付數千個這類 PR。以上都是 AI 出現之前就有的做法
  ↳ 每天有數千個這種自動 PR 在跑。要注意的是，這整套自動化在 AI 出現前就已經存在，AI 是後來才加進來的。
• 06:36 這套方法很適合簡單的變更，例如改設定、升級 build file 裡的相依套件
  ↳ 簡單又有規律的改動最適合這套做法，例如改一個設定值，或在 build file（描述程式怎麼組裝、用哪些套件的檔案）裡調高套件版本。
• 06:36 遇到較複雜的變更（例如替換 API 呼叫）時，跨整批元件執行的腳本會變得極度複雜
  ↳ 像「把舊的 API 呼叫換成新的」這類要看上下文才能改的工作，要寫一支腳本全面處理，會變得非常複雜，難寫也難維護。
• 07:07 程式碼的 API 表面非常廣，同一件事有很多種寫法；腳本在數百萬行程式碼上跑，一定會碰到所有邊角案例（corner case）
  ↳ 同一件事有很多種寫法。腳本在幾百萬行程式上跑，一定會遇到各種罕見寫法，也就是 corner case（邊角案例），很容易處理不到。
• 07:07 這個現象被稱為 Hiram's law，來自一位 Google 工程師的發現
  ↳ 這個現象一般叫 Hyrum's law（字幕寫成 Hiram），出自一位 Google 工程師的觀察：規模夠大時，各種想不到的狀況都會出現，腳本躲不掉。
• 07:37 LLM 出現後，他們嘗試用 LLM 取代確定性（deterministic）腳本來改程式碼。在 Claude 這類工具出現前就開始嘗試
  ↳ LLM 是大型語言模型。deterministic 腳本照死規則改，同樣的輸入一定得到同樣的結果。他們改讓 LLM 讀懂程式再改，而且很早就開始嘗試。
• 07:37 一開始很困難，模型太笨，他們的做法也太笨。經過多次迭代後，他們摸索出模式，模型也變得更好
  ↳ 一開始效果很差。講者坦白說，一半是模型不夠聰明，一半是自己用法不對。反覆試了很多次，找到有效做法，同時模型也進步了。
• 08:07 最後做出了 Honk（Boris 在早上的 keynote 有提到），名字和圖示都很搞笑，但非常實用
  ↳ 最後做出內部工具 Honk，名字和圖示都很搞笑，但非常好用。當天早上 Boris 的 keynote（主題演講）也提到過它。
• 08:37 現在 Honk 底層是 Claude，使用 agent SDK，外面包著 Spotify 自己的 harness，放在 Kubernetes pod 裡，可以在雲端排程執行很多個
  ↳ 底層是 Claude 的 agent SDK（做 AI 助手的工具包），外面包一層自家的 harness（加規則的外框），放進 Kubernetes pod（雲端小容器），可以同時開很多個。
• 08:37 Honk 可以使用一組受信任的工具，驗證工具是其中之一，實際上還有更多工具
  ↳ Honk 不是什麼都能碰，只能用公司信任的一組工具。驗證工具是其中之一，用來檢查改完的程式有沒有壞掉，此外還有其他工具。
• 09:07 驗證時，Honk 可以在 CI 環境跑 build。因為客戶端跑在很多種作業系統上，能跨多個作業系統跑 build 對他們很重要
  ↳ CI（持續整合）是程式一改就自動組裝、測試的環境。Spotify 的 App 要在多種作業系統上跑，所以 Honk 能在多個系統上跑 build 來驗證，這點很重要。
• 09:37 Honk 整合進 fleet management：Fleet Shift 負責在數千個 repo 間排程與協調變更，Honk 在中間負責實際改程式碼
  ↳ repo 就是一個程式碼倉庫。兩者的分工是：Fleet Shift 管要改哪些倉庫、什麼時候改、進度如何，Honk 負責實際打開程式動手改。
• 09:37 示範案例是一個針對 39 個 repo 的小型遷移，負責的團隊可以看到建立了多少 PR、合併了多少、多少個在 CI 失敗需要處理
  ↳ 示範裡有一個團隊要改 39 個倉庫。畫面上看得到開了幾個 PR、合併了幾個、幾個沒通過 CI 要有人處理，像一張進度看板。
• 10:08 節省的時間很可觀：過去需要數百個團隊花數週到數月的遷移，現在一位工程師幾天就能完成
  ↳ 以前要幾百個團隊各花幾週到幾個月的事，現在一位工程師幾天就能搞定，省下的是整個組織的人力時間。
• 10:39 後端主要跑在 Java/JVM 上，最近一次 Java 遷移用這些工具只花了 3 天
  ↳ JVM 是執行 Java 程式的環境。Spotify 的後端大多用 Java，最近一次 Java 升級靠這套工具只花了 3 天。
• 10:39 Spotify 透過 Backstage 開發者入口網站提供商業方案，把這套能力當作產品提供給其他公司
  ↳ Backstage 是 Spotify 做的開發者入口網站，把公司內的服務和工具集中在一起。他們透過它的商業方案，把這套能力當成產品賣給其他公司。
• 11:10 開發者很快就想到可以從 Slack 呼叫 Honk：在 Slack 對話中 @ Honk，它就會去處理，最後帶著 PR 回來
  ↳ Slack 是公司常用的聊天工具。工程師在對話裡 @Honk 交代一件事，它就去改程式，改完帶著 PR 回來，像在群組裡請同事幫忙。
• 11:42 黑客週（Hack Week）期間發布了 Honk V2 alpha。名稱雖然是 V2，但講者說實際上大概是第 8 版
  ↳ Hack Week（黑客週）是公司讓員工集中做實驗專案的一週。那週推出了 Honk V2 alpha（早期試用版）。講者說名字叫 V2，其實大概是第 8 版了。
• 12:14 Honk V2 走向讓開發者更互動式地使用，並整合進內部的 agent 協作工具 Chirp，可以同時執行、協調大量 agent session
  ↳ V2 讓工程師可以邊做邊和 AI 來回互動。它接上內部工具 Chirp，可以同時開很多個 agent session（一次 AI 工作對話），並統一調度。
• 12:14 講者說 Chirp 類似 Claude Agents 或 Agent Deck，但功能更多，而且整合進 Spotify 的基礎設施，可以用 Chirp 排程 Honk 任務
  ↳ 講者拿 Claude Agents、Agent Deck 這類工具來比，說 Chirp 功能更多，又接上了 Spotify 的內部系統，可以直接用它安排 Honk 的任務。
• 12:45 可以和其他開發者共用 agent session、一起提供回饋與想法，講者比喻成「Claude 版的 Google Docs」
  ↳ 同一個 AI 工作對話可以讓好幾個人一起進來看、一起給意見，就像大家同時編輯一份 Google 文件，只是對象換成 Claude。
• 13:15 session 可以歸到共用的專案（project）底下，團隊在專案裡開多個 Honk session 朝同一個目標協作；任何裝置都能使用
  ↳ 多個 session 可以放在同一個 project（專案）底下，團隊各開幾個 Honk 朝同一個目標分頭做，而且任何裝置都能使用。
• 13:45 講者個人最期待的是這些多人協作（multiplayer）功能
  ↳ multiplayer（多人協作）原本是遊戲用語，這裡指多人一起使用同一個 AI 工作。講者最期待這點，代表他認為下一步是團隊和 AI 一起合作。

根據演講，Spotify 最近一次 Java 遷移用 Honk 等工具花了多久？