Jonathon's AI Wiki

Spotify — Coding is no longer the constraint (Niklas Gustafsson, Code with Claude London 2026)

9 min read

Source: Coding is no longer the constraint — Scaling devex to teams and agents at Spotify (YouTube 7oO37GRhwGk), Niklas Gustafsson (Spotify), Code with Claude London 2026 (May 21 2026). Transcript via local Whisper fallback (no YouTube captions).

Niklas Gustafsson leads Spotify’s developer-experience function — 15-year Spotify veteran. Spotify ships 4,500 deployments/day across a 40 M-line Java monorepo backend + thousands of polyrepos with ~3,000 engineers. The talk traces how their pre-AI fleet-management investment (Fleet Shift, a deterministic mass-PR tool) evolved into Honk (an AI-driven sibling that wraps the Claude Agent SDK inside Kubernetes pods + trusted verification tools) — and is now in alpha as Honk v2, integrated with Spotify’s agent orchestration platform Chirp for Google-Docs-style multiplayer agent sessions. Companion thesis: code-base standardization makes agents radically more effective; less variance + Linting feedback loops + Backstage as MCP/CLI surface = better agent output. Closing observation: coding is no longer the bottleneck — product decision-making and human judgment are the new constraints.

Key Takeaways

  • 99%+ of Spotify engineers use AI coding tools every week. 94% report in the latest engineering survey that AI tooling has made them more productive — at record-high self-assessed productivity. Adoption inflection coincided with Opus 4.5 release in November; growth has been “completely bananas” since.
  • PR frequency +76%. Most PRs Spotify ships are now authored by an AI agent together with a developer. The number kept growing while Niklas was making the slides — he had to revise it.
  • Code base grew 7× faster than engineers — pre-AI. Spotify’s response was a multi-year automation play: Fleet Shift for deterministic mass migrations, then Honk for the AI-driven cases the scripts couldn’t handle.
  • 2.5 M automated maintenance PRs merged. Vast majority merged with no human in the loop — automation creates the PR, automation validates it, automation merges it. Thousands ship every day.
  • Hyrum’s Law was the wall Fleet Shift hit. Simple changes (config bumps, dependency version bumps) were fine deterministically. Complex changes (API-call refactors) ran into every possible misuse of the API across millions of LOC. Migration scripts collapsed under corner-case load.
  • Honk = Agent SDK wrapped in Kubernetes pods + trusted verification tools. Spotify’s own harness around the Claude Agent SDK runs in their cloud environment. Verification tools include builds across multiple operating systems (their clients ship on many OSes). The agent uses those tools to verify changes before opening a PR.
  • Honk + Fleet Shift = orchestrated agentic mass-migrations. Fleet Shift schedules and tracks; Honk does the actual code change. A team owning a shift sees PR-creation count, merged count, CI-failure count in Backstage.
  • Latest Java migration: 3 days. What used to take “weeks or months” across hundreds of teams now takes a single engineer a few days using Honk + Fleet Shift.
  • Commercial offering. Spotify is shipping this as a packaged product on the Backstage developer-portal commercial offering.
  • Honk has Slack integration. Spotify engineers @-mention honk in Slack threads; the agent picks up context from the conversation, goes off, and returns with a PR.
  • Honk v2 alpha (released hackweek before the talk). Integrated with Spotify’s agent-orchestration platform Chirp — similar in spirit to Cloud Agents View / Agentech but with Spotify-specific infrastructure features. Enables many simultaneous agent sessions + coordination across them.
  • Multiplayer agent sessions are the v2 headline. “Imagine Google Docs but for Claude” — a developer shares an agent session with teammates who collaborate, give feedback, and iterate against the goal together. Sessions group into projects for larger feature-build efforts.
  • Multi-device. Honk v2 sessions are accessible from any device.
  • Code-base standardization makes agents more effective. “If Claude has a lot of other code to look at and that code looks roughly consistent, Claude will do a better job. We see agents perform worse in our more-fragmented code bases.”
  • Backstage as the MCP/CLI surface for agents. Spotify’s developer portal catalogs every component + ownership + status. All of that surface is now exposed as MCPs and command-line tools for Claude. Agents look up component ownership, ping the owning team on Slack, query A/B tests — the same surface human developers use.
  • Technology Radar + Golden State + Soundcheck. A multi-year standardization stack: a Tech Radar (recommended tech list with state labels), Golden State templates (per-component-type tech + practice recommendations), and Soundcheck (self-assessment UI for component compliance). Agents inherit these conventions.
  • Static analysis + linting drive Claude’s self-correction. Spotify’s Linters give immediate feedback when Claude uses a non-preferred pattern (e.g., “wrong way to call gRPC”). The Linter feedback loop has become a primary teaching mechanism for the agent.
  • The bottleneck moved off coding. Coding “used to be the bottleneck”; now PR review (76% more PRs), human product decisions (which experiments to run, which features to ship), and cross-functional coordination are the new bottlenecks. Auto-merging “safe-enough” PRs is part of the rebalancing — focus human review where it matters most.
  • Prototyping is now minutes, not days. Niklas’s most surprising stat: anyone at Spotify (including CEOs) can prompt Claude in the production codebase via a set of skills + Spotify’s prototyping infrastructure to get a buildable app on their device for a feature idea. “Days/weeks → minutes.”
  • Niklas’s six-month forecast. “In six months we’ll have a very different way of building products” — driven by the moving constraint set, not by new tooling.

Architecture — Fleet Shift + Honk

  Engineer writes plain-English migration
              │
              ▼
   ┌──────────────────────┐
   │     Fleet Shift      │  ← deterministic orchestrator (pre-AI)
   │  schedules + tracks  │     "do this across N components"
   │  per-component PRs   │
   └──────────────────────┘
              │
              ▼ (per component)
   ┌──────────────────────┐
   │        Honk          │  ← AI-driven code modifier
   │  Kubernetes pod      │     wraps Claude Agent SDK
   │  + verification tools│     + trusted tool palette
   └──────────────────────┘
              │
              ▼
   ┌──────────────────────┐
   │   Backstage UI       │  ← per-shift dashboard
   │  PR / CI / merged    │     team-owner view
   │  status per team     │
   └──────────────────────┘

Honk v2 layer added 2026:

  • Sessions become first-class objects in Chirp (Spotify’s agent-orchestration platform).
  • Sessions support multi-developer collaboration (“Google Docs for Claude”).
  • Sessions group into Projects (long-running feature builds).

The standardization → agent-effectiveness thesis

Spotify has spent multiple years consolidating its technology stack — for reasons that pre-date AI:

  1. Deep expertise on fewer technologies.
  2. Eliminate small decisions for teams (pre-selected technology choices = less cognitive overhead).
  3. Easier cross-team collaboration.
  4. Easier developer mobility between teams.

Niklas’s observation: all four reasons apply equally to agents. A consistent code base is a more-readable training signal for an LLM. Spotify’s internal data shows agents perform measurably worse in their more-fragmented codebases.

The standardization stack:

  • Tech Radar — recommended vs not-recommended technologies, state labels.
  • Golden State — per-component-type templates (e.g., “if you’re this type of backend service or iOS view, here are the technologies + practices to use”).
  • Soundcheck (in Backstage) — self-assessment UI for component compliance (e.g., “this component has a valid owner defined”).
  • Static analysis + Linters as feedback loops — Claude runs into the same Linter checks human devs do, and self-corrects when it gets non-standard.

Implementation notes

  • Honk is built on the Claude Agent SDK. Same SDK external builders use — same harness primitives.
  • Honk runs on Kubernetes pods in Spotify’s cloud env. Each migration shift schedules many pods to run in parallel.
  • Trusted-tool palette. The agent gets a curated set of tools including multi-OS build runners (since Spotify clients ship on many platforms) and Spotify’s CI environment. The agent uses these to verify each change.
  • Backstage exposes the dev portal as MCPs + CLIs. Component metadata, ownership, A/B-test results, deployment state — all are MCP-callable. The same surface engineers use.
  • Slack invocation pattern. @honk in a thread → honk picks up context, works async, returns with a PR.
  • Spotify ships Backstage commercially. Honk + Fleet Shift will be available as a packaged product to other companies via the Backstage commercial offering.

Try It

  1. Audit your codebase for fragmentation. Pick your most-touched codebase. Count technologies in use for the same problem (e.g., HTTP clients, ORMs, logger libraries). Niklas’s claim is that agent effectiveness drops in proportion to this variance. Measure agent task success rate on a fragmented vs consolidated repo and replicate or refute.
  2. Expose your dev portal as MCP. If you have a Backstage instance (or any internal dev-portal catalog), wrap the component + ownership + A/B + deployment queries as an MCP server. Watch what changes when agents can self-serve the same context engineers do.
  3. Build a Linter-as-feedback-loop pattern. Pick the three most-common “Claude does this wrong” patterns in your codebase. Add Linter rules + auto-fix hints for each. Run Claude on a real change and watch how often the Linter teaches it without you intervening.
  4. Try the auto-merge-with-no-human-in-loop pattern on safe changes. Niklas’s automation merges 2.5 M PRs without human review — but only for changes their validation pipeline declares safe. Pick the safest class of change in your repo (dependency bump that passes all tests + has a known-good security profile). Auto-merge it.
  5. Honk-style mass migration. Pick a deprecated API. Write the migration in plain English. Use Claude Code (or the Agent SDK directly) to run it across multiple repos via parallel sessions. Measure team-hours saved vs the old way.

Open Questions

  • Chirp + Honk v2 + Cloud Agents View — overlap with Anthropic’s primitives. Spotify built Chirp before Cloud Agents View was a thing. As Anthropic’s new Cloud Agents View matures, where does the boundary between Spotify-bespoke (Chirp) and Anthropic-platform (Cloud Agents View) land?
  • Auto-merge safety boundary — how is “safe” defined? Niklas says auto-merge applies to “PRs we think are safe enough.” The precise validation rubric (test coverage, change-size, file-class) isn’t in the transcript. Worth tracing through the Backstage commercial offering docs.
  • Honk commercial pricing. Niklas says it’s available “as a product in the Backstage packaging” — no pricing or SLA detail.
  • What was Spotify’s pre-AI fleet-shift cost? The “send a migration to hundreds of teams, takes months” baseline is mentioned but not quantified in engineer-hours. The 3-day Java migration cite is the contrast; the absolute baseline is fuzzy.
  • Hyrum’s Law — Spotify’s response was Honk; what’s the residual rate of agent-induced corner-case failures? Niklas frames the agent path as the better answer, but doesn’t quantify what % of Honk PRs still need human intervention.

Graph View

Backlinks