Spotify doubled its changes and rework held flat

Spotify merged about 17,000 changes in August. A year earlier it merged about 8,100. If you run a product team and your engineers have started working with coding agents, that doubling is probably coming for you, and the first question your leadership will ask is what it does to quality.

The industry data gives a scary answer. Faros AI, an engineering analytics company, reports that quarterly code churn, meaning code written and then rewritten or deleted soon after, is up 861%. GitClear, which analyzes large code samples, reports duplicated code blocks up 81% between 2023 and 2026. The conclusion most people draw is that AI-written code piles up debt faster than anyone can clean it.

I drew it too. The call in this publication’s knowledge base says exactly that: generation scales with the model, cleanup scales with engineer-hours, so debt wins.

On September 16, Tyson Singer, who runs technology and platforms at Spotify, published the account of a company living through the doubling. Spotify serves roughly 777 million monthly users from nearly 3,000 production services. Its quality did slip. A scheduling bug cut throughput by about 10% on June 24 and left podcast episodes waiting hours to publish. An automated dependency upgrade passed every check and then failed in production for real users.

Here is what Singer says about the cause. Spotify reviews every major incident monthly, and across the ones reviewed, AI-written code was not a material direct contributor. His line: “AI increased the capacity to produce change. The next constraint became our ability to verify it.”

Then comes the number that cuts against the churn story. Spotify rebuilt its rework-rate metric so it separates genuine rework from new work and planned refactoring. It cites the Faros finding and says it sees no matching rise in its own rework rate. Quality and optimization work grew from 27% to 31% of everything shipped, while maintenance and configuration shrank from 31% to 25%.

More than twice the change did not produce more rework at Spotify, which suggests churn tracks how much verification a company funds before it speeds up.

Take the fair objection first. Spotify is an outlier. It has monthly incident reviews, staged rollouts, and the engineers to build a custom metric. Churn is an industry average, and averages are dragged by teams with none of that. Spotify also reports that pull requests and code complexity are both rising, and says it doesn’t yet know whether that is a warning sign or just bigger units of work done with agents. It is one operator describing itself. I’d treat every number above as reported, not verified.

But the objection helps the point. If the best-equipped company sees no rework rise and the industry average sees a huge one, the gap between them is worth explaining. The explanation Singer offers is that the fixes were to the delivery system: end-to-end monitoring, rollback capacity, safeguards on automated fleet changes, scheduling those changes during the owning team’s working hours. Spotify did not ban AI code or add diff readers.

That widens what “verification” means. Most commentary treats it as human review bandwidth, the hours someone spends reading what the model wrote. Spotify’s list is mostly about what happens after the merge: how fast you notice, how fast you undo.

For a PM this changes the question you bring to your engineering lead. “How much of our code is AI-written?” tells you little. “How quickly can we detect and reverse a bad change?” tells you whether doubling the volume is safe.

I’m not claiming churn data is wrong. The accumulation is real in the samples these firms measured. My claim is narrower and testable: the churn spike is a symptom of delivery systems that weren’t built for this volume, and it should vary with rollout and rollback maturity. Nobody has published that comparison.

Faros and the DORA research program both hold the data to run it. Cut rework rate by teams with similar AI adoption but different rollback and staged-rollout practice. If the spread is large, the debt story was a story about missing safeguards, and the fix is cheaper than anyone thought. If the spread is small, Spotify is a lucky exception and the debt is as structural as I thought.

Which is it at your company?