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的做法更接近工业化流程：有明确的需求、有测试覆盖、有review确认、有部署管道。工程师没有在随意振动，他们在做架构决策、需求定义、质量把控——只是把敲键盘这一步外包给了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, thanks to AI（TechCrunch）；Spotify's AI Coding Shift: Honk and Claude Code Explained（Let's Data Science）