Spotify扩大AI开发应用，月度合并变更增至1.7万+

Spotify正把AI辅助开发更大规模地用于生产系统。公司8月合并的代码变更超过1.7万个，较此前约8100个增长一倍以上。面对变更数量激增，Spotify同步调整质量与可靠性体系，覆盖监控、测试、发布防护、回滚、容量规划和质量度量等环节。

Spotify目前运营近3000个生产服务，为7.77亿月活用户和约1亿并发客户端提供支持，后端每秒处理约1100万至1200万次请求。复盘显示，内容处理、集群变更、计算资源和移动端质量保障均出现新的压力。

6月24日，内容处理流水线的一项定时批处理任务与新节目处理争抢资源。一次质量优化提高了资源需求，加上调度错误导致吞吐量下降约10%，原本几分钟即可上线的内容被延迟数小时。该流水线每天处理超过50万首新增歌曲、视频、播客和有声书。此后，Spotify增加端到端监控，修复调度器，降低批处理优先级，重构任务优先级策略，并扩充处理容量。

在集群自动化方面，管理系统已合并超过250万个维护拉取请求，其中大多数通过安全检查后自动合并。Spotify引入了Honk：它在Kubernetes Pod中借助Agent SDK运行Claude，可自动修改代码并在CI中执行构建；Fleetshift则负责目标选择、调度和进度跟踪。公司称，近期一次后端Java迁移仅耗时三天。

但自动化并非没有风险。一次依赖升级虽然通过了既有校验，仍在生产环境发生故障。Spotify因此继续加强发布防护和回滚能力，并计划将自动化变更安排在责任团队的工作时段内执行。

复盘观点认为，代码生成变容易后，测试、评审、可观测性和上线前验证承受了更大压力。相关趋势也与2025年DORA研究相呼应：AI能提升软件交付吞吐量和产品性能，却可能削弱交付稳定性，自动化测试、版本控制和快速反馈闭环因此更加关键。

Spotify已将标准化维护交给集群管理系统，复杂代码变更交由Honk处理，由Fleetshift编排、CI验证。质量与优化类工作占合并变更的比例从27%升至31%，维护与配置类工作则从31%降至25%。返工量尚未增加，但拉取请求规模和代码复杂度持续上升；事件审查也未发现AI代码造成实质性直接影响，主要问题是变更量已超过部分验证机制的承载能力。