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

🧑‍🏫 這是 Spotify 工程主管 Niklas Gustavsson 訪談的後半段。他說明 Spotify 怎麼在 AI 大量寫程式的情況下，一邊加快速度、一邊守住品質，也談到他們怎麼算 AI 的投資報酬，以及現在連高階主管都自己用 Claude 做可以操作的雛形。想知道大公司實際怎麼導入 AI，而不只是聽口號的人，很值得看。

• 13:05 過去團隊可以測試每個 PR，所以 post-test automation 有時會比較鬆散
  ↳ 以前每個 PR（pull request，工程師送出、等人審核後才合併的一包程式修改）都有人親自測過，所以合併之後的自動測試，有時就沒做得那麼嚴格。
• 13:05 開始對原始碼做 PR automation 後，他們必須改變團隊的預期：多數變更會自動 merge，團隊甚至看不到 PR
  ↳ 後來系統會自動產生程式修改，也就是 PR automation。大部分修改直接 merge（合併進正式程式碼），團隊連看都沒看到，大家得接受不是每筆都有人把關。
• 13:05 所以他們必須建立好很多的 test automation，確保所有軟體都承受得住這種自動化變更
  ↳ 既然沒有人逐筆檢查，就得靠大量 test automation（會自己跑的測試程式）來守門，確保每個軟體被自動修改之後，還是能正常運作。
• 13:35 這項投資現在很有幫助：用 agents 時也能沿用以前那套驗證機制
  ↳ 當年為了自動修改蓋的這套檢查機制，現在剛好能拿來檢查 agents（能自己分步驟完成任務的 AI）寫的程式，不用從頭再做一套。
• 13:35 「可靠度與品質 vs. 速度」是假的二分法。想更快，就要把 QA 做法自動化、寫成程式碼，不能只存在某人的腦中
  ↳ 很多人以為要快就得犧牲品質，他認為不是這樣。重點是把「怎麼檢查品質」寫成程式自動執行，而不是靠某位資深同事憑經驗記在腦子裡。
• 14:05 QA 做法可以做成 skill、MCP 之類 agent 能執行的形式，這才是讓團隊更快的關鍵
  ↳ QA（品質檢查）的做法可以包成 skill（給 AI 照著做的一套說明和工具）或 MCP（讓 AI 連接外部工具的標準介面）。AI 能自己跑檢查，團隊才真的快得起來。
• 14:05 主持人：工程生產力最後都取決於投資基礎設施，而不是工作更多小時
  ↳ 主持人的看法是：團隊要更有產能，靠的是把工具和流程這些底子打好，而不是叫大家加班。
• 14:05 Spotify 的品質指標維持持平，速度則大幅提升
  ↳ 結果是品質相關的數字沒有變差，出貨速度卻快了很多。這表示快和穩是可以同時做到的。
• 14:35 這不是免費的，前提是要先投資 test automation
  ↳ 但這個成果有前提：他們早就花力氣把自動測試做起來了。沒有這個底子就直接加速，很可能會出事。
• 14:35 他們會繼續投資可靠度實踐，其中有些做法也在這次轉型中改變。越想加快，就越要投資可靠度
  ↳ 他們會繼續投資讓系統穩定的做法，有些做法也因為 AI 做了調整。速度越快，出錯的影響就越大，所以越要把防錯機制做好。
• 15:06 Spotify 每天在 production 部署約 4.5 thousand 次，所以要有適當的實踐來確保上線品質
  ↳ deployment 是把新程式推上 production（使用者實際在用的正式環境）。Spotify 每天大約部署 4,500 次，所以每次上線都一定要有機制把關品質。
• 15:36 Spotify 一直在優化「從想法到 production」的時間：幾年前要數週或數月，現在大約一小時
  ↳ 從有個想法到真的上線給使用者用，幾年前要花幾週到幾個月，現在大約一小時就能做到。
• 15:36 他們想測試、探索很多想法，越快拿到回饋越好。回饋可能來自內部使用者，也可能來自外部使用者
  ↳ 他們想同時試很多點子，越早知道好不好越好。回饋可能來自公司內部的同事，也可能來自真實的使用者。
• 16:06 他們發現迭代越快，產品做得越好，也越快交到使用者手上
  ↳ 他們的經驗是：試得越快、改得越快，產品反而做得越好，使用者也越早用到。
• 16:06 不是每個想法都能一小時上線，很多需要大量研究；但能快速得到確認非常重要，agents 也是這個循環的一部分
  ↳ 當然不是每件事都能一小時搞定，很多事得先花時間研究。但能很快確認方向對不對非常關鍵，AI agents 也是加快這個循環的一環。
• 16:36 Spotify 工程組織約有 2,900 名 engineers
  ↳ Spotify 的工程部門大約有 2,900 位工程師，所以這些做法是在很大的規模下運作的。
• 16:36 ROI 初期很容易衡量，訊號很明確：PR rate 提升超過 75%，可以直接歸因於 AI 工具
  ↳ ROI（投資報酬率，也就是花出去的換回多少）一開始很好算：用了 AI 工具之後，PR 數量增加超過 75%，而且能明確歸功於 AI。
• 17:06 目前約 73% 的 PR 直接和 AI 建立有關
  ↳ 目前他們大約 73% 的 PR，都和 AI 產生的程式直接有關。
• 17:06 他們也想把這些指標連結到使用者價值與營收
  ↳ 光是 PR 變多還不夠。他們想進一步知道，這些產出有沒有真的讓使用者覺得更有價值，也讓公司多賺錢。
• 17:37 做法：把 PR、deployments 等產出連結到 work items（計畫中的工作），再連結 AB testing，看出 PR 對使用者價值的貢獻。這些連結目前還在建
  ↳ 做法是把 PR 和上線紀錄對回 work items（事先排定要做的工作），再接上 AB testing（把兩個版本給不同使用者、比較成效），就能看出各自的貢獻。這條串連還在建。
• 18:08 主持人：以前 developer productivity 的大勝大概是幾個百分點，還要夠幸運才量得到；現在的改善人人看得見，但工程師仍然想衡量
  ↳ 主持人說，以前提升工程效率，能進步幾個百分點就算大勝，還不一定量得出來。現在進步大到人人有感，但工程師還是想用數字來證明。
• 18:38 隨著成熟度提高、成本改善，大家對 ROI 估算準確度的期望也跟著提高，他們正在改進衡量方式
  ↳ 隨著工具越來越成熟、成本也改善了，大家不再滿足於粗略估計，要求 ROI 算得更準，所以他們也在改進衡量的方法。
• 18:38 衡量分兩部分：生產力提升了多少，以及得到這個提升要花多少成本
  ↳ 衡量分成兩半：一是產能到底多了多少，二是為了這些產能，花了多少錢和資源。
• 19:08 主持人：現在改善動輒數十甚至數百個百分點，會想用花了多少 tokens、多少小時、得到什麼產出來解釋
  ↳ 主持人說，現在的進步常常是幾十甚至幾百個百分點，大家會想算清楚花了多少 tokens（AI 計算用量的單位，通常照這個計費）、多少人力時數，換到什麼成果。
• 19:39 給 CTO 與工程主管的建議：投資核心能力，例如 test automation 與 verification
  ↳ 給技術主管的建議：先把基本功做好，例如自動測試和 verification（確認程式做的事情是對的那套檢查）。
• 19:39 另一項是 standardization：讓 codebase、工具、frameworks 更一致
  ↳ 另一項是 standardization（標準化）：讓 codebase（公司全部的程式碼）、工具和 frameworks（寫程式用的現成骨架）盡量用同一套做法。
• 19:39 這些投資原本是為了簡化工作、讓人更有生產力，結果同樣很適用於 agents
  ↳ 這些投資原本是為了讓人工作更輕鬆、更有效率，結果發現對 AI agents 一樣好用。
• 20:09 Claude 會從 mono repository 的其他程式碼找靈感；如果同一件事有 10 種做法，Claude 會更困惑。越一致，agents 表現越好
  ↳ Claude 會參考 mono repository（全公司程式碼都放在同一個大倉庫）裡別人的寫法。同一件事有十種寫法，它就不知道該學哪個；寫法越一致，它做得越好。
• 20:09 最重要的建議：不要忽略這類投資，以前的良好工程實踐在新世界依然適用
  ↳ 最重要的一句：別因為有了 AI 就跳過這些基本功，過去好的工程習慣，現在一樣重要。
• 20:40 codebase 裡多了一個新角色，樣貌可能不同，但基本原則一樣適用，至少在 Spotify 的環境是如此
  ↳ 程式碼裡多了 AI 這個新成員，工作的樣子會變，但好的原則照樣適用，至少在 Spotify 是這樣。
• 21:10 Niklas 一直很喜歡解程式問題，空閒時會做 competitive programming，也曾擔心這些改變會徹底改變工作方式
  ↳ Niklas 很愛解程式難題，空閒時還會做 competitive programming（程式解題競賽），所以一度擔心 AI 會把他喜歡的工作方式整個改掉。
• 21:41 現在他有五個 agents 在背景工作，和它們互動的方式跟一兩年前很不同
  ↳ 現在他同時讓五個 agents 在背景幫他做事，跟它們配合的方式，和一兩年前很不一樣。
• 21:41 他發現自己想錯了：他熱愛的是解決問題，至於用什麼方式解，對他並不是最重要的
  ↳ 後來他發現自己想錯了：他真正喜歡的是把問題解決掉，至於是不是一行一行親手寫，其實沒那麼重要。
• 22:14 給工程師的建議：這個轉變因人而異，但要專注在自己有能力解決的問題類型上
  ↳ 他給工程師的建議：每個人適應的方式不同，但要把心力放在自己有能力解決的那類問題上。
• 22:14 現在他能從工作中得到更多價值，也能解決以前解不了的問題
  ↳ 有了 AI，他覺得工作更有收穫，也能處理以前解決不了的問題。
• 22:14 以前要花數天或數週才看懂的 codebase，現在能直接跳進去做出貢獻
  ↳ 以前接手一套陌生的程式碼，要花幾天到幾週才看得懂；現在可以直接進去動手，很快就做出貢獻。
• 22:46 每個人情況不同，但值得多實驗，找到自己喜歡的工具用法
  ↳ 每個人情況不一樣，值得多試幾種用法，找到自己用起來順手、也喜歡的方式。
• 22:46 主持人：Claude 在背景實作，他就把時間拿去想下一步、和客戶聊，也做了比預期更多的 prototyping（外部產品與內部自動化都有）
  ↳ 主持人分享，Claude 在背景寫程式的時候，他就去想下一步、和客戶聊。他也比預期做了更多 prototype（可以實際操作的雛形），對外產品和內部自動化都有。
• 23:16 Spotify 特別大力投資 prototyping，對象包含工程師與非工程師
  ↳ Spotify 特別投資在讓大家做 prototype 這件事上，對象不只是工程師，也包括不會寫程式的人。
• 23:16 Claude 這類工具讓人發現：任何人都能用自然語言描述想法，再請 Claude 實作
  ↳ 像 Claude 這類工具讓大家發現：任何人只要用平常說話的方式描述想法，就能請 Claude 把它做出來。
• 23:47 包括非工程師在內，大家開始在真正的（相當複雜的）app 裡嘗試，也看到了可行的跡象
  ↳ 連非工程師都開始在真正、相當複雜的 app 上動手嘗試，而且看得出來這條路走得通。
• 23:47 幾個月前，Spotify 開始建立讓這件事變簡單的基礎設施
  ↳ 幾個月前，Spotify 開始搭建一套基礎設施，讓大家做 prototype 更容易。
• 24:17 現在可以很容易地在 mobile apps 和 backend 建立完整的 prototype
  ↳ 現在要在手機 app 和 backend（使用者看不到、在伺服器上跑的後台）做出完整的 prototype，都很容易。
• 24:17 還有一個內部 prototype app store，可以分享 prototype，也能在自己的 app 裡試用別人的 prototype
  ↳ 他們還有一個內部的 prototype app store，大家可以把作品放上去分享，別人也能直接在自己的 app 裡試用。
• 24:49 以前要動用一群工程師才能實現的想法，現在一兩小時內就有可運作的 prototype，可以帶著真實資料分享給別人看
  ↳ 以前一個點子要動用一群工程師才做得出來；現在一兩小時就有能動的雛形，還能用真實資料展示給別人看。
• 24:49 這種事一年前無法想像，現在每天都在做
  ↳ 這在一年前根本無法想像，現在卻是每天都在發生的事。
• 25:19 現在人人都在做 prototype，連一位 co-CEO 都在 app store 上有 prototype，也有多位高階主管做出不錯的 prototype
  ↳ 現在幾乎人人都在做 prototype，連一位共同執行長都在那個 app store 上放了作品，好幾位高階主管也做出不錯的東西。
• 25:49 主管有工程團隊，但團隊忙別的事；現在主管能自己更快試做，在一天內測試想法，而不是花數週或數月
  ↳ 主管雖然有工程團隊，但團隊有別的事要忙。現在主管能自己動手，一天內就能測試點子，不用等上幾週甚至幾個月。

根據影片，Spotify 每天在 production 大約部署幾次？