From Mexico, the question I hear most about AI coding tools isn’t “are they fast?” Everybody already knows they’re fast. The real question is “what does all that speed do to quality?” Today InfoQ wrote up one of the most honest answers I’ve read from a big engineering org, and it comes from Spotify.
InfoQ’s report is based on a post on Spotify’s engineering blog by Tyson Singer, Spotify’s Head of Technology and Platforms. The headline number: total merged changes more than doubled year over year in August, from roughly 8,100 to 17,000. Spotify runs nearly 3,000 production services. That’s a lot of new change landing on a lot of systems.
AI wasn’t the cause. The pace was.
Spotify says it had quality problems this year, and it doesn’t hide that. What I like is how they went looking for the cause. Every month they review their major incidents, and during the AI ramp-up they added two questions: did AI-authored code directly contribute, and did the higher volume of change put more pressure on review, testing, rollout or observability?
The answer to the first one, in their words: “we did not identify AI-authored code as a material direct contributor.” The answer to the second one was yes. Spotify writes that “the volume of change increased faster than some of our verification controls could adapt.” Or, as the post says earlier, four areas tested them at once, “and, what may surprise some, AI slop isn’t among those.”
The examples are ordinary, and that’s why they’re useful. On June 24, a scheduled batch workload competed with new podcast episodes, a recent quality improvement made each episode need more compute, and a scheduling bug cut throughput by about 10%. Episodes that normally publish within minutes were delayed for hours. Separately, an automated dependency upgrade passed Spotify’s checks and still failed in production. None of that is exotic. It’s what happens when more change flows through the same pipes.
What the numbers say about quality
Spotify also checked whether engineers were trading quality for speed. They classify every merged PR by the kind of work it is. Quality and optimization work rose from 27% of the mix to 31%, and since the total doubled, that’s more than twice as much absolute quality work as a year earlier. Maintenance and configuration fell from 31% to 25%.
They rebuilt their rework-rate metric so it separates real rework from new work and legacy refactoring, and they report no rise in rework. But they flag two warning signs: code complexity and PR size are both creeping up. A bigger PR might just mean a human and an agent delivered a bigger unit of work safely, or it might be a problem. Spotify says it doesn’t know yet, and I respect this line a lot: “we are deliberately not rewriting the thresholds to make ourselves feel better.”
For context, Spotify cites Google Cloud’s 2025 DORA research, which found AI adoption associated with higher delivery throughput and product performance but lower delivery stability. Spotify’s data reads like a field report of that same tension.
Agents at fleet scale
Part of the volume is automation. Spotify’s Fleet Management framework has made large-scale changes across its services for years, most of them merged automatically after safety checks. For over a year now, it has also handled more complex agent-driven changes, including a Java migration across backend services that Spotify says took three days. InfoQ adds that Spotify’s background coding agent, Honk, runs Claude through the Agent SDK in Kubernetes pods, while Fleetshift handles targeting, scheduling and progress tracking.
More automation means new ways to fail, and Spotify’s fixes are refreshingly boring. They’re strengthening safeguards, expanding rollback capacity, and scheduling automated changes during the owning teams’ working hours, so a human is around when something lands. On the content pipeline they added end-to-end monitoring, fixed the scheduler, lowered the priority of batch work and added capacity. After a May incident they doubled reserved edge capacity.
What I take from it
This is one company describing its own data, with no outside audit, so I read it as a strong signal, not proof. But it matches what I see on much smaller projects. When an agent writes the code, my bottleneck isn’t typing anymore. It’s knowing whether the change is good: tests that actually cover the path, a rollout I can stop, logs that tell me something, and a rollback I trust.
Spotify puts it in two sentences I’m going to borrow for every team conversation about AI tools: “AI increased the capacity to produce change. The next constraint became our ability to verify it.” If you’re adding coding agents to your workflow, don’t just measure how much more you ship. Invest in the checks with the same budget and the same urgency. Otherwise the speed shows up in your incident review, not your roadmap.
Featured image: “Sieve, Flour Sifter,” February 2010, photo by Shliphmash, Wikimedia Commons, public domain. Cropped, resized to 1400×900 and lightly sharpened from the original upload.
_Sieve,_Flour_Sifter.JPG){kind=link}