重點一：Spotify 的 AI 成果建立在多年工程底座上；程式碼、文件、責任歸屬與技術標準愈一致，代理愈容易產生符合公司環境的結果。
重點二：Boris Cherny 認為，代理要在缺少人類逐步監督時可靠工作，驗證迴路是關鍵；AI 並未降低測試與工程紀律的重要性。
重點三：當原型與 PR 大量增加，瓶頸從寫程式移向產品決策；企業必須把工程產出連回使用者價值，而不只計算生成了多少程式碼。
2025 年 9 月，Claude Code 負責人 Boris Cherny 曾告訴 Spotify 首席架構師暨工程副總裁 Niklas Gustavsson，開發者很快可能不再依賴 IDE（整合式開發環境）寫程式。當時 Gustavsson 覺得兩個月內發生這件事太過極端；到了年底，他發現自己的工作方式真的改變了。
這段對話點出 AI 程式開發最容易被低估的地方。改變不只是「模型幫忙多寫幾行程式碼」，而是企業如何開發、驗證與選擇產品的整套流程，都開始跟著移動。
據 Spotify 內部統計，目前超過 99% 的工程師每週使用 AI 程式開發工具，94% 回報生產力提升，PR（pull request，程式碼變更提案）頻率增加 76%。但 Boris 在訪談中追問的，不只是這些成長數字，而是 Honk 的架構、驗證機制、投資報酬率，以及當工程師以外的人也能建立原型，組織會如何改變。
從這場對談可以看出，Spotify 的經驗不是一則「導入 Claude 就能提高效率」的成功故事。它揭露了 AI 工程走向大規模應用後，企業必須面對的三個新問題。
為何 Spotify 能吃到 AI 紅利？答案藏在 AI 出現以前
Spotify 的後端 monorepo（將多個專案集中管理的單一程式碼庫）超過 2,000 萬行。Gustavsson 原本擔心，大型程式碼庫會讓代理搜尋或索引失效，實際使用後卻發現，Claude 會參考程式碼庫內既有的寫法；同一技術棧與設計模式愈一致，代理愈容易產生符合公司規範的結果。
相反地，Spotify 在架構較零散、同一問題有許多不同寫法的程式碼庫中，測得代理表現較差。這表示 AI 能否在企業裡發揮作用，並不只取決於模型有多聰明，也取決於企業是否能提供一致、可查詢的工作環境。
這套環境並不是為 AI 打造的。約 5、6 年前，Spotify 發現正式環境的程式碼成長速度是工程師人數成長速度的 7 倍。大量版本升級、API 遷移與弱點修補，開始排擠新功能開發。
Spotify 因而建立 Fleet Management（艦隊管理）與執行系統 Fleetshift，把分散在數千個元件的維護工作視為一個整體。截至 2026 年 6 月，這套系統已合併超過 250 萬個自動化維護 PR，大多數不需人工介入即可自動合併。這些是整體自動化成果，並非全由 AI 代理產生。
AI 真正接手的是規則式腳本難以處理的複雜修改。Spotify 的 Maven 相依套件更新腳本，曾因處理各種例外而膨脹到超過 2 萬行。大型語言模型成熟後，Spotify 才逐步把複雜程式碼修改交給背景代理 Honk；截至 2025 年 11 月，已有超過 1,500 個 Honk 產生的 PR 被團隊合併至正式環境。
這段歷史帶出的第一個洞察是：AI 不會讓過去的工程投資失效，反而會放大它們。 Spotify 先把元件、責任歸屬、文件、測試與部署流程整理成可查詢的系統，之後才有條件讓代理參與工作。
代理能不能放手做？關鍵不是信任，而是驗證
Boris 在訪談中把焦點放在 Honk 的驗證迴路。他認為，當代理要在沒有人類逐步監督的情況下拆解任務、修改程式並建立 PR，驗證是最重要的環節；企業常見的錯誤，則是低估建立這套迴路需要多少投資。
Honk 的早期版本曾嘗試把程式碼交給模型一次完成，結果並不理想。Spotify 後來拆解問題、加入模型評審，再隨模型與代理框架改善而調整架構。如今 Honk 以 Claude Agent SDK 運作，部署在 Kubernetes 環境中，可以呼叫可信任的工具，在 Linux、macOS 與 CI（持續整合）環境中執行建置與測試。
Backstage 內部開發者入口則提供另一層脈絡。代理可以查詢元件由誰負責、讀取文件，並依 Spotify 的「標準狀態」檢查技術與設計模式。當 Claude 採用不適合公司環境的寫法，lint（程式碼規範檢查）會立刻回報，讓它自行修正。
這意味著「代理自主」並不是模型本身的一項能力，而是整套工程系統共同產生的結果。測試愈完整、標準愈清楚、錯誤回饋愈快，人類才愈能放心退出每一次修改流程。
Spotify 過去由元件所屬團隊檢查每個 PR，因此部分測試可以依賴人工補位。開始自動合併變更後，公司反而必須提高測試自動化標準。AI 減少了部分人工操作，卻提高了組織對工程紀律的要求。
PR 增加 76% 後，真正的瓶頸移到哪裡？
如果寫程式不再是主要限制，企業接下來會卡在哪裡？Spotify 的答案是人類決策。
公司已建立內部原型工具與應用程式市集，讓工程師、設計師、產品經理甚至共同執行長，都能用自然語言把想法做成可操作原型。過去要排進工程團隊、等待數週或數月的構想，現在可能在一兩個小時內，就能用真實資料做出可供內部測試的版本。
這並不代表每個點子都值得正式開發。當實作成本下降，可被嘗試的構想反而暴增，組織要更頻繁地判斷：哪些問題值得解、哪些原型應該上線、哪些變更可以自動合併，以及人類判斷應該放在哪一個環節。
Boris 因此追問，Spotify 如何把 PR 頻率等工程指標，連回使用者價值與營收。Gustavsson 坦言，公司正在建立從 PR、部署、工作項目、A／B 測試到產品成果的連結，還沒有完成這套衡量方式。
這是比「工程師快了多少」更難回答的問題。PR 增加 76%，可以證明產出速度提高，卻不能單獨證明 Spotify 做出了更好的產品。 當程式開發能力不再稀缺，產品判斷、優先順序與驗證價值的能力，會成為新的限制。
Spotify 經驗能複製嗎？先別急著照抄工具
Spotify 的規模與工程成熟度並不典型。它早已擁有 Backstage、數千個有明確責任歸屬的軟體元件、大量自動化測試，以及多年累積的 Fleet Management 經驗。其他企業即使採用同一款模型，也未必能立即得到相同結果。
真正可複製的不是 Honk 或 Fleetshift 的名稱，而是導入順序：先讓程式碼與組織脈絡能被查詢，再建立可信任的驗證迴路，接著才擴大代理權限；最後，衡量標準也要從「產生多少程式碼」轉向「創造多少使用者價值」。
Boris 與 Gustavsson 的對談因此提供了一個更完整的 AI 工程框架。企業間的差距，可能不只來自誰率先使用更強的模型，而是誰能把自己的組織變成代理看得懂、改得動，也驗得過的系統。
資料來源：Boris Cherny 對談 Niklas Gustavsson、Anthropic：Boris Cherny 職稱資料、Spotify Engineering：Coding Is No Longer the Constraint、Spotify Engineering：Honk Part 1、Spotify Engineering：Fleet Management
本文初稿為 AI 編撰，整理．編輯／李先泰
