Spotify 如何在超過 2,000 萬行程式碼上運行 agents——對談 Niklas Gustavsson（第 1/2 段）

🧑‍🏫 Spotify 資深工程師 Niklas Gustavsson 分享：他自己怎麼從親手寫程式，變成同時指揮好幾個 AI 幫他寫。他也說明公司內部工具 Honk 怎麼一步步長出來。這支影片值得看，是因為它講的是在超過 2,000 萬行程式碼的大公司裡實際跑過的經驗，包括走過的彎路，不是空談。

• 00:10 主持人回憶，去年 9 月曾聽到「年底前大概沒人會再用 IDE」，當時覺得不可能
  ↳ 主持人回憶，去年 9 月聽到有人說「年底前大概沒人會再用 IDE」，當時覺得太誇張。IDE 是工程師寫程式、改程式用的專用編輯軟體。
• 00:10 Niklas 原本以為要兩年，結果兩個月後自己就不再使用 IDE，工作方式完全改變，是入行 30 年來沒見過的轉變
  ↳ Niklas 本來估計這要兩年，結果才兩個月，他自己就不開 IDE 了。他入行 30 年，沒看過工作方式變得這麼快、這麼徹底。
• 00:40 主持人表示，公司內部的感受和外部完全一樣，只是早了大約幾週
  ↳ 主持人說，他們公司內部感受到的變化跟外界一模一樣，只是早幾週體驗到而已。
• 00:40 Niklas 是分子生物學出身，研究所時期開始處理基因體定序產生的「大數據」，因此加強程式能力
  ↳ Niklas 本來念分子生物學。基因定序會產生大量資料，他研究所時為了處理這些資料，才認真把寫程式練起來。
• 01:10 原本只打算休一年的創作假，結果變成在業界工作將近 30 年
  ↳ 他原本只打算暫離學術界一年去業界試試，沒想到一待就是將近 30 年。
• 01:40 LLM 剛出現時，Spotify 很早就嘗試用它自動化程式碼修改，一開始非常辛苦
  ↳ LLM（大型語言模型，ChatGPT、Claude 這類 AI 背後的技術）一出現，Spotify 就試著用它自動改程式，但一開始非常卡。
• 01:40 後來摸索出 LLM、judge 等的用法，開始得到令人振奮的結果
  ↳ 後來他們摸出門道，例如加一個 judge，也就是另一個 LLM 專門檢查結果對不對。從那時起，成果才開始讓人興奮。
• 02:10 這些嘗試發生在 Claude 出現之前、大約 GPT 早期，當時的結果雖然不能解決所有問題，但讓人看到未來方向
  ↳ 當時 Claude 還沒出現，大概是 GPT 早期。那時的成果還解決不了所有問題，但已經看得出未來會往哪裡走。
• 02:10 模型從「聰明的自動完成」變成可以直接丟真實問題給它，不需要做那麼多操作面的工程
  ↳ 以前的模型比較像很聰明的自動補字，人要花很多工夫設計怎麼引導它。現在可以直接把真實問題丟給它處理。
• 02:40 以前模型大約寫出 70% 到 80% 的程式碼，他總得進 IDE 做最後修改；後來他完全不再自己改程式碼
  ↳ 以前模型大概寫七八成，剩下的他得自己打開 IDE 修。現在他已經完全不親手改程式碼，全部交給 AI。
• 03:10 他的用法很簡單：在終端機開多個 tmux session，工作時背景同時跑好幾個 agents
  ↳ 他的做法很簡單：在終端機（輸入指令的視窗）裡用 tmux（一個視窗開多個工作區的工具），讓好幾個 agent（會自己動手做事的 AI）同時在背景跑。
• 03:10 通常開 5 到 10 個分頁，並用分割面板，另開一個終端機看 diff 等資訊
  ↳ 他通常開 5 到 10 個分頁，每頁再切成幾塊。另外開一個終端機看 diff，也就是程式改了哪裡的前後對照。
• 03:40 他在一組 worktrees 上，配置了一個個 Claude session 與對應終端機組成的矩陣
  ↳ 他用 worktree，把同一份程式碼複製成幾個獨立的工作資料夾，彼此不干擾。每個資料夾配一個 Claude 和一個終端機，排成一整組。
• 03:40 Spotify 正逐步轉向一個非常大的統一 monorepo，但仍有數千個小型 polyrepo；他大多在 monorepo 工作
  ↳ repo 是存放程式碼的倉庫。Spotify 正把程式集中到一個超大 repo（monorepo），但還有幾千個分散的小 repo（polyrepo）。他大多在大的那個裡工作。
• 04:10 需要處理 polyrepo 時，他會在那裡另外開一個臨時的 Claude session
  ↳ 偶爾要改那些小 repo，他就在那邊臨時開一個 Claude 來處理，做完就收掉。
• 04:10 他一開始擔心在 monorepo 上用 agents，因為以前用過的一些工具有索引（indexing）等問題
  ↳ 他本來擔心 agent 應付不了超大 repo。以前有些工具要先建索引（indexing，像幫整座圖書館編目錄），規模一大就出問題。
• 04:40 結果 Claude 在這些 repo 裡表現很好，特別擅長參考 repo 裡的其他程式碼，找出解決當前問題的靈感
  ↳ 結果 Claude 在裡面表現很好，特別會去翻 repo 裡別人寫過的類似程式，拿來當解題參考。
• 05:10 5、6 年前 Spotify 發現，程式碼成長速度大約是工程師人數成長的 7 倍，要維護的程式碼越來越多
  ↳ 5、6 年前 Spotify 發現，程式碼增加的速度大約是工程師人數成長的 7 倍，每個人要顧的舊程式越來越多。
• 05:40 Spotify 想為使用者做的點子源源不絕，被維護工作拖住不是好事，所以開始盡量自動化維護
  ↳ Spotify 想做的新功能永遠做不完，人力被維護舊程式綁住很可惜，所以他們決定盡量把維護工作自動化。
• 05:40 維護工作多半很無聊，例如升級到最新版 Java、更新函式庫，或在整個 codebase 把一個 API 遷移到另一個 API
  ↳ 維護多半很瑣碎，例如把 Java（一種程式語言）升到新版、更新函式庫（別人寫好的現成程式模組），或把整個程式碼從一個 API（程式之間溝通的介面）換到另一個。
• 06:10 他們打造了名為 fleet management 的基礎設施：不再發遷移指南請各團隊手動改，而是直接修改整個 codebase
  ↳ 他們建了 fleet management 這套系統。以前是發遷移說明（migration，把舊寫法換成新寫法），請各團隊自己改；現在由系統直接幫所有程式一起改。
• 06:40 以前是數百個團隊在數千個元件上手動做同一件事，每次遷移要好幾個月，一年大約只能完成 10 次
  ↳ 以前幾百個團隊要在幾千個程式元件上重複做同一件事，一次遷移就拖好幾個月，一年頂多完成 10 次左右。
• 06:40 因此幾乎只能勉強跟上所用框架的支援版本
  ↳ 結果光是讓所用的框架（寫程式用的基礎工具組）停在還有官方支援的版本，就已經很吃力。
• 06:40 自動化後已合併數以百萬計的 PR，這些 PR 都靠確定性（deterministic）腳本來修改程式碼或設定
  ↳ 自動化之後，已經合併了數百萬個 PR（送審通過、併進正式程式的修改）。這些修改靠 deterministic 腳本：規則寫死，同樣的輸入一定得到同樣的結果。
• 07:10 他們很早就發現程式碼的 API 表面積非常大，所以能做的修改複雜度很快就碰到上限
  ↳ 但他們很快發現，API 表面積（API 能被呼叫的方式和組合）太大，寫死的規則能處理的修改很快就碰到天花板。
• 07:10 例如同一個 API 方法可能有五種呼叫方式，光是替換一個方法就很複雜
  ↳ 舉例來說，同一個功能可能有五種不同的呼叫寫法，光是換掉一個方法，每種寫法都得分別處理。
• 07:40 只用傳統靜態分析（如 AST 轉換）處理時，還需要追蹤變數與狀態，很混亂，每個遷移腳本都膨脹成數千行來處理各種邊界情況
  ↳ 傳統做法是 static analysis／AST 轉換：把程式拆成樹狀結構，再照規則修改。過程還要追蹤變數狀態，每支腳本都膨脹到幾千行，全在處理例外狀況。
• 07:40 這促使他們在早期 LLM 一出來時，就嘗試用 LLM 解決這個問題
  ↳ 正因為規則多到快失控，LLM 一出現，他們就想試試讓 AI 來處理這些五花八門的情況。
• 08:10 一開始效果不好：一是模型不夠好，二是做法太天真，直接把程式碼丟給模型要它一次改完
  ↳ 一開始不成功有兩個原因：當時的模型不夠強，做法也太單純，只是把整段程式丟給模型，要它一次改好。
• 08:10 後來模型變強、做法也進步：用 LLM 當評估者確認結果符合預期，並用不同方式拆解問題
  ↳ 後來模型變強，做法也改進了：多一個 LLM 當裁判檢查結果，並把大問題拆成小步驟處理。
• 08:40 經過多次迭代與許多內部 hack 後整合起來，成為現在的 Honk；最初並不是建立在 Claude 上
  ↳ 經過多輪修改和許多內部拼湊的做法，最後整合成現在的 Honk，也就是 Spotify 內部的 agent 工具。它一開始甚至不是用 Claude 做的。
• 08:40 Honk 是隧道盡頭的第一道光，讓他們確認這個問題真的能解決
  ↳ Honk 讓他們第一次確定，用 AI 大規模自動改程式這件事真的做得到。
• 09:10 Honk 迭代過很多次，現在發布的叫 V2，但他說實際上大概是 V8，只是沒記錄迭代次數
  ↳ Honk 改版過很多次，現在對外叫 V2。但他說實際上大概已經是第 8 版，只是沒人記版本號。
• 09:10 Honk 起初用於自動化程式碼修改，以及在所有 repo 間排程與協調；工程師很快發現它也能用在別處，例如在 Slack 提到它，請它代辦任務
  ↳ Honk 原本用來自動改程式，並安排、協調所有 repo 的修改。後來工程師發現，在 Slack 裡標記它，就能請它代辦各種事。
• 09:40 如今 Honk 已成為 Spotify 內部普遍使用的工具，建構在 agent SDK 上
  ↳ 現在 Honk 已經是 Spotify 內部普遍在用的工具，底層是 agent SDK，也就是用來打造 AI agent 的現成開發套件。
• 09:40 Honk 以前有 judge，後來移除了，因為 agent 和模型已經好到不再需要 judge
  ↳ Honk 以前有 judge 這道檢查關卡，後來拿掉了，因為 agent 和模型本身已經夠可靠，不需要另外把關。
• 10:10 在 Honk 早期版本中 judge 非常重要，讓驗證請求的成功率從約 20%–30% 提升到約 80%（他說若沒記錯）
  ↳ 在早期版本裡 judge 非常關鍵，讓驗證成功的請求比例從約兩三成拉到約八成（他說印象中是這樣）。
• 10:40 Honk 架構相當簡單：一個在 Kubernetes pod 裡運行的 agent SDK，並可使用一組工具
  ↳ Honk 的架構很簡單：agent SDK 跑在 Kubernetes pod 裡，再配上一組工具。Kubernetes 是管理大量伺服器程式的系統，pod 是其中一個獨立執行單位。
• 10:40 V2 以前，工具是一組預先定義、信任可提供給 agent 的工具；V2 開放使用者自行加入工具，agent 可以使用任何內部工具
  ↳ V2 之前，agent 只能用公司事先挑好、信得過的工具。V2 開放使用者自己加工具，agent 可以用任何內部工具。
• 11:10 最重要的工具之一是執行驗證，也就是跑 CI build，並可在 Linux 與 macOS 上執行
  ↳ 最重要的工具之一是驗證，也就是跑 CI build：每次改完就自動把程式組起來，檢查能不能正常運作。它在 Linux 和 macOS 上都能跑。
• 11:10 macOS 特別重要，因為 iOS 開發都需要在 macOS 上 build
  ↳ macOS 特別重要，因為 iOS app 一定要在 Mac 上才能 build（把程式組成能執行的 app）。
• 11:40 它也能跑相關測試；他們有結合模擬器與 Claude 的案例，自動化從 Figma 設計直接做到 UI 實作
  ↳ Honk 也能跑相關測試。他們有個案例把手機模擬器和 Claude 接起來，從 Figma（設計師畫介面的工具）的設計稿一路自動做出實際畫面。
• 11:40 也用這種方式把 iOS app 移植成 TV app
  ↳ 他們也用同樣的方法，把 iOS 上的 app 改做成電視版 app。
• 12:10 在閉環開發中，agent 拿到任務後可能要拆解，並在沒有人參與的情況下完成大量工作，所以驗證最重要
  ↳ 閉環開發是指 agent 接到任務後自己拆解、自己做完，中間沒有人把關（沒有 human in the loop）。所以怎麼確認它做對，才是最重要的事。
• 12:10 常見錯誤是企業在驗證機制上投資不夠；Niklas 同意，也說 Spotify 同樣如此
  ↳ 主持人指出，企業常犯的錯是在驗證機制上投資太少。Niklas 同意，也承認 Spotify 一樣有這個問題。
• 12:10 Spotify 為此做的主要工程實踐改變之一，是加強測試自動化
  ↳ 為此，Spotify 在工程做法上的一大調整，就是加強 test automation：先寫好檢查程式，每次修改都自動跑一遍。
• 12:40 codebase 分成數千個元件，每個都有明確擁有者，由特定團隊全權負責，通常也是該團隊設計、實作和管理
  ↳ Spotify 的程式拆成幾千個元件，每個元件都有明確負責的團隊，通常也是那個團隊自己設計、寫出來並管理。
• 12:40 在投資 fleet management 之前，團隊會知道合併進自己 codebase 的每一個修改
  ↳ 在導入 fleet management 之前，每個團隊都清楚知道，有哪些修改被併進了自己負責的程式。

根據 Niklas 的說法，Honk 早期版本的 judge 讓驗證請求的成功率出現什麼變化？