2 月 12 日，Spotify 共同 CEO Gustav Söderström 在財報電話會議上說了一句話：「我們最好的工程師，自從 12 月以來就沒有寫過一行程式碼了。」
他接著補充，AI 大幅提升了公司的編碼與部署速度，2025 年全年公司發布了 50 多項新功能。
這句話迅速傳開，在開發者社群中引發極大反響——有人興奮、有人恐懼，也有人說這不可能是真的。
我認為值得仔細看看 Spotify 的具體做法。
他們在使用什麼：Honk 系統
Spotify 內部有一套名為 Honk 的系統，這是他們將 Claude 與一套工作流程整合在一起的工具。
用法大致如下：
一位工程師在手機上打開 Slack，發送一條訊息給 Honk：
把 iOS App 裡的 xxx 功能修一下，重現步驟是 xxxx
或者：給用戶推送的郵件增加一個 xxx 功能
Honk 接到任務之後：
- 呼叫 Claude 理解需求、生成程式碼
- 自動建置、執行測試
- 打包成一個新版本的 App
- 把結果推送回 Slack
工程師在到辦公室之前，就能在手機上看到完成的版本，確認沒問題就直接合併到正式環境。
這與 Vibe Coding 的區別
很多人把這類工作方式稱為 vibe coding——感覺上說幾句話就能產出程式碼。
Spotify 的做法更接近工業化流程：有明確的需求、有測試覆蓋、有審查確認、有部署管道。工程師並非隨意振動，他們在做架構決策、需求定義、品質把關——只是把敲鍵盤這一步外包給了 AI。
這個區別很重要。程式碼品質不是靠 Vibe 保證的，而是靠那個自動執行的測試套件、靠工程師的最終確認，以及靠 Honk 背後的工程基礎設施。
METR 研究說 AI 讓程式設計師變慢了，這裡該如何理解
確實有矛盾感。
我們之前報導過 METR 的研究：使用 AI 工具的有經驗程式設計師，完成任務的速度反而比不用 AI 慢了 19%。
但 Spotify 的情況與 METR 測試的場景不同：
- METR 測試的是在 AI 工具下撰寫新的、陌生的任務，工程師需要不斷糾正 AI 的錯誤
- Spotify 的 Honk 面向的是高度結構化、擁有大量上下文的內部任務：成熟的程式碼庫、完整的內部文件、標準化的流程
Honk 在這種條件下運作良好，因為 Claude 有足夠的上下文可以利用。
這對工程師意味著什麼
Spotify 並未減少工程師數量。他們實際上加快了產品發布節奏——50 多項新功能的背後，仍然需要有人想清楚這些功能該做什麼、做成什麼樣子。
這大概是最現實的 AI 編程圖景：不是工程師消失了，而是工程師的工作內容正在向更高抽象層轉移——從寫程式碼，到定義程式碼應該做什麼。
至於這種轉變對工程師的長期職業發展意味著什麼，目前還沒有答案。但 Spotify 這個案例告訴我們：在合適的基礎設施下，這個轉變已經在真實的公司裡發生了。
參考來源：Spotify says its best developers haven't written a line of code since December,CocoLoop、 thanks to AI（TechCrunch）；Spotify's AI Coding Shift: Honk and Claude Code Explained（Let's Data Science）