Spotify published an analysis in its engineering blog on how AI changed the service's development: the number of merged changes per year grew from approximately 8,100 to 17,000, and the share of work on quality and optimization — from 27% to 31%. An analysis of incidents over one month showed that none were directly caused by code written by AI — the speed of change verification simply couldn't keep up with the growth in their volume. The author of the material is Tyson Singer, Head of Technology and Platforms, SVP.

image
image

What happened

The company reported on a year of working with AI tools in the material 'AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity'. In addition to the growth in the change flow and the share of quality work, the report analyzes the main incidents of the month. The June 24 incident in content processing occurred when a batch job, increased computation per episode, and a scheduler bug coincided in time — episode publication was delayed by several hours. The second case was an automatic dependency upgrade that passed all checks and still led to a failure. The third incident occurred in May: after it, Spotify doubled its reserved edge capacity, because the industry's overall demand for CPU and GPU under AI loads absorbed free capacity, and regional failovers became noticeable. The common thread in all three cases is one: verification mechanisms — reviews, tests, rollouts, and observability — were not adapting fast enough to the growth in the volume of changes.

Context

The conclusions are drawn at a scale that is hard to dismiss as a private case: Spotify serves approximately 777 million users, processes 11–12 million requests per second, and consists of approximately 3,000 services. By the time of the report, code generation had ceased to be a bottleneck — the bottleneck in development became the ability to verify changes at the same speed at which they are produced. Spotify supports this observation with a reference to the industry study FAROS 2026 'AI Acceleration Whiplash', dedicated to the leap in code turnover after AI adoption. The infrastructure background is also changing: AI demand for compute has densely occupied free CPU and GPU capacity, so the capacity reserve that used to come for free now has to be reserved separately.

Why this matters for the industry

For the industry, this is an argument against banning AI code: the thesis of 'AI slop' as a source of production incidents is not confirmed by this material, the real bottleneck is the speed of change verification. Hence the shift in priorities: companies are strengthening reviews, tests, observability, and rollback mechanisms, rather than restricting AI development. The most transferable element of the report is the rework rate metric, weighted by the age of the changed code: it attempts to separate rework from new work and show the real price of acceleration. Infrastructure teams should plan capacity reserves in advance for rollbacks and failovers, because AI demand for CPU and GPU has turned free resources into a scarcity. Builders get a demand signal from the analysis: review triage, change risk scoring, and agents for mass migrations — an under-staffed layer of tools, even though agents have been performing large-scale work like a Java migration in three days for over a year.

Why this matters for users

For Spotify listeners, the practical effect is more positive: risks have shifted not to content quality, but to infrastructure — hence rare delays in episode publication and the service's sensitivity to a lack of compute capacity, which the company now offsets with capacity reserves. Readers who build products themselves get a checklist from the analysis: check whether reviews and CI can withstand a doubled change flow; whether there is a capacity reserve for rollbacks and regional failovers; whether automatic dependency upgrades and batch job priorities are controlled. The key idea is that you need to check not only the code itself, but also the volume and pace of changes — they have become the main source of risk.

What is still unknown / limitations

This is a self-report from one company without a published measurement methodology, without a control group, and without ablation, so the correct formulation is 'the volume of merged changes doubled', not 'AI confirmedly doubled productivity'. The thesis 'no incident was directly caused by AI code' is methodologically weak: the growth in the volume of changes is itself an indirect risk factor, and an analysis of incidents over one month is a small sample. The formula and threshold values for the rework rate are not disclosed, which hinders correctly adopting the metric. The FAROS 2026 study is only mentioned in the analysis, so the external validity of the conclusions currently relies on a single case.

Sources

Author

Look at AI, editorial team