Anthropic published a conversation this week with Niklas Gustavsson, VP Engineering at Spotify. Gustavsson trained as a molecular biologist, got into software through genome sequencing data, and has been in the industry for close to thirty years since. What makes him worth listening to is that Spotify has been automating its own codebase maintenance longer than most of the industry, and that effort now runs almost entirely on Claude. I watched it back because it’s one of the rare cases where an engineering leader puts real numbers behind what happens when you point agents at a codebase of this size.
From deterministic scripts to agents
Five or six years ago, Spotify’s codebase was growing seven times faster than its engineering headcount could keep up with. Their answer was “fleet management”: instead of asking every team to manually carry out the same migration (a Java upgrade, an API replacement), Spotify built infrastructure to push those changes as an automated mutation across thousands of repositories at once. It worked, until it hit a ceiling. Code has a huge API surface, Gustavsson says: the moment a method gets called five different ways, a deterministic script balloons into thousands of lines of edge-case handling.
That ceiling is why Spotify started experimenting with LLMs early, with mixed results at first. What the team built eventually grew into Honk, their internal tool for automated code changes. Early versions ran on homegrown components plus a separate LLM judge that checked the output. That judge pushed PR success rates from roughly 20 to 30 percent up to 80 percent, but it’s since been removed: the models and the agent harness got good enough that the extra verification layer stopped adding value.
Architecture: the agent SDK plus a verification loop
Honk now runs on the Claude Agent SDK, in a Kubernetes pod, with access to Spotify’s internal tooling. Since version 2, teams can add their own tools instead of working from a fixed allowlist. The most important piece isn’t code generation, it’s verification: the agent can run CI builds itself, on both Linux and macOS (needed for iOS work), and in some cases drive a simulator to test an implementation against a Figma design.
Gustavsson is direct about this: verification is the one thing that matters once an agent is executing a task on its own, with no human in the loop. That forced a culture shift at Spotify. Test coverage used to be allowed some slack, because the owning team would still eyeball every PR. Once PRs merge automatically without a team ever seeing them, that test coverage has to hold up on its own. The investment went into better test infrastructure rather than faster agents, which is exactly why he doesn’t see speed and quality as a trade-off: quality encoded in scripts, a CLAUDE.md, or a set of MCPs runs faster than quality that lives in someone’s head.
The numbers
Spotify ships roughly 4,500 production deployments a day, across about 2,900 engineers. The metrics Gustavsson cites: a 75 percent or greater improvement in PR frequency directly attributable to AI tooling, and 73 percent of all PRs now AI-authored. He doesn’t treat that as the finish line. Spotify is working to connect those deliverables (PRs, deployments, planned work items) through to A/B tests and, eventually, to user value and revenue, so they know exactly what an improvement cost in tokens and hours against what it delivered.
A second, less technical point: over the past few months Spotify built internal prototyping infrastructure that lets anyone, including non-engineers, turn an idea expressed in plain language into a working prototype inside their own mobile apps, complete with an internal app store to share them. One of the co-CEOs has a few prototypes in there.
What stood out to me
Two things are worth setting against this, because the story is easy to read as pure progress.
The first is the degree of model dependence. Honk now runs almost entirely on the Claude Agent SDK, and Gustavsson himself notes that consistency across codebase and tooling makes agents perform better. That’s a real technical argument, but it also means a company this size is tying its core process, maintaining a 20-million-line monorepo, more and more tightly to a single vendor. Nothing in the conversation suggests Spotify has a fallback for that.
The second is the “73 percent AI-authored” metric itself. That number tells you who typed the first draft of the code, not who’s accountable when it breaks. Gustavsson is honest about the investment needed to merge PRs with no human in the loop, and that’s exactly the point: the higher that percentage climbs, the more the verification layer has to carry, and that layer is built on tests that humans still designed. That’s a sound order of operations, but it’s an assumption you have to keep checking, not a result that holds up on its own as the percentage rises.
What sticks with me is how plain the closing advice is: invest in standardization and test automation before you bring in agents, not after. That’s exactly the unglamorous work that usually gets skipped because it doesn’t make for a good demo. At Spotify, it’s the reason the rest of it actually works.
Watch the full conversation on YouTube: How Spotify runs agents across 20M+ lines of code, with Niklas Gustavsson.
This piece also ran in Dutch: Hoe Spotify Claude loslaat op 20 miljoen regels code.