Coding Is No Longer the Constraint: Scaling DevEx to Teams and Agents at Spotify

1. The Adoption Milestone Nobody Planned For

Spotify did not set out to reach 99% AI adoption among engineers. It happened. When Niklas Gustavsson, Chief Architect and VP of Engineering, looked at the numbers in early 2026, the picture was clear: 99% of Spotify engineers use AI coding tools every week, 94% report increased productivity, and pull-request frequency is up 76%.

Those numbers sound like a success story — and they are. But they also reveal a problem.

When almost everyone is coding with AI and individual velocity has climbed that steeply, the old bottleneck disappears and a new one materializes. The constraint is no longer writing code; it is deciding what to change, reviewing what was generated, coordinating across thousands of repositories, and managing the humans in the loop. The problem became an orchestration problem.

This is the central insight of the talk: AI adoption at scale moves the constraint, it does not eliminate it. Engineering orgs that recognize the shift early can invest in the right places. Those that treat AI purely as a speed multiplier for individual contributors will be surprised when the bottleneck reappears elsewhere.

2. Honk: A Background Coding Agent Built for Production

To address the orchestration gap, Spotify built Honk — an internal background coding agent that runs Claude via the Anthropic Agent SDK, wrapped in a custom harness and deployed as Kubernetes pods. The “background” part is the design principle: engineers do not sit at a terminal watching Honk work. They trigger it, and it works autonomously in the background, opening pull requests when it is done.

What Honk can and cannot do

Honk’s tool access is deliberately narrow:

• Verify — formatters, linters, unit tests, and build tools, abstracted so the agent never has to know which framework is in use.
• Git — a restricted set of subcommands only.
• Bash — a strict allowlist, including ripgrep for code search.

Notably absent: free-form web search, documentation browsers, MCP connections to external services (in its core form). This is intentional. Narrower access reduces the surface area for unpredictable behavior and keeps the context window focused on the task.

The verification loop

Predictability comes from the verification loop. When Honk completes a change, a stack of deterministic verifiers runs automatically — the right ones, selected based on what language and build system the repository uses, without the agent having to know the details. Regex patterns extract only the relevant error lines and feed them back to Honk, so the agent sees a concise signal rather than thousands of lines of raw CI output.

On top of the deterministic layer sits an LLM judge: a second Claude call that reads Honk’s proposed diff against the original prompt and evaluates whether the change is in scope. At Spotify, the judge vetoes roughly a quarter of sessions. Of those vetoed sessions, about half recover by self-correcting; the other half are flagged for human review. The most common trigger: the agent exceeded the scope of the prompt — did more than asked rather than less.

3. Fleetshift and Backstage: Orchestrating at Scale

Honk does the coding. Fleetshift does the orchestration. The distinction matters.

Backstage (Spotify’s open-source developer portal, now a CNCF project) is the system of record for every software component Spotify runs. It knows who owns each service, what technologies it uses, where its code lives, and what downstream components depend on it. This catalog is what makes large-scale automation tractable: you can ask “which 1,800 data pipelines consume this dataset?” and get an answer in seconds, with links to every repository.

Fleetshift is a Backstage plugin that orchestrates migrations across that catalog at scale. A platform team defines a migration — for example, moving downstream data consumers from a deprecated API to a new one — and Fleetshift creates a work queue: which repositories need changing, in what order, with what priority. Engineers see a snapshot dashboard of progress and can click through to any automated PR without manually searching GitHub.

Honk sits in the middle: Fleetshift hands it a repository and a prompt; Honk opens a PR; Fleetshift records the outcome and moves to the next target.

The result: Spotify has merged 2.5 million automated maintenance PRs, the vast majority without human intervention. A Java backend migration that previously required weeks to months was completed in three days.

4. Context Engineering: Six Principles for Reliable Agent Prompts

Running 1,800 repository migrations with one agent taught Spotify hard lessons about prompt design. They call the discipline context engineering — and it is distinct from prompt engineering in the conversational sense. For background agents, the prompt is the entire context: there is no back-and-forth, no clarifying question, no human to nudge the agent mid-run.

Spotify distilled the experience into six principles:

1. Describe the end state, not the steps

Claude Code performs better when given a goal and allowed to determine the path. Step-by-step instructions work for deterministic tools; they constrain agents unnecessarily and break when the repository deviates slightly from the assumed starting state.

2. Add precondition statements

Agents need to know when not to act. A prompt that works for 80% of repositories will fail silently on the other 20% if it has no escape hatch. Explicit statements like “if the file x does not exist, exit without changes” prevent the agent from inventing solutions to problems it was not asked to solve.

3. Include concrete examples

Example code in the prompt disproportionately influences output quality. Showing the before and after of a single representative change is more effective than paragraphs of description.

4. Give testable goals

“Make this code better” fails. “Make the test UserServiceTest.testInvalidEmail pass” succeeds. The verification step needs something to verify against; vague goals produce unverifiable diffs.

5. Keep changes atomic

Combining multiple unrelated modifications in one prompt exhausts the context window and typically produces partial results. One prompt, one concern. Fleetshift handles sequencing across concerns; Honk handles the individual task.

6. Ask the agent what was missing

Counter-intuitively, the agent is often the best source of feedback on its own prompt. After a failed run, asking “what information would have helped you complete this correctly?” frequently surfaces missing context that a human reviewer would not have noticed.

5. Standardization as an Agent Accelerator

One of the most counterintuitive findings from Spotify’s experience: stricter standardization made agents faster, not slower.

Spotify’s platform defines a Golden State for each type of component — the recommended technology stack, structure, and practices. Teams self-assess against the Golden State using Soundcheck, a developer portal UI that generates a scorecard. Components that are closer to the Golden State are cheaper to automate: the agent can make reliable assumptions about what it will find.

The inverse is also true. When Spotify attempted to use Honk on Scio pipelines (a Scala framework with many idiomatic patterns), the diversity of approaches across repositories made it impossible to write a single prompt that worked across the board. The team deprioritized Scio migrations in favor of the more standardized dbt and BigQuery Runner frameworks — and those worked well.

The principle generalizes: whatever makes a human engineer effective on an unfamiliar repo also makes an agent effective. Consistent naming, predictable project layout, linting rules, and test coverage are not bureaucratic overhead. For agentic automation, they are the prerequisite.

Niklas Gustavsson summarized this as: “The fewer technologies we are world-leading in, the faster we go.” A narrower, deeper stack yields more automation surface and more reliable agents.

Feedback loops as guardrails. Spotify’s linting and static analysis tools produce immediate, machine-readable signals when an agent uses a non-preferred pattern. These signals are fed back into the verification loop. Rather than trying to encode every preference in the prompt, the team lets the toolchain enforce standards — and the agent learns from the feedback within the same session.

6. What Changes When the Agent Is the Engineer

Spotify’s experience points to three structural changes that organizations face once background coding agents become part of the standard workflow.

Code review evolves

When a human opens a PR, the reviewer trusts that the author understood the surrounding context. When an agent opens a PR, that assumption weakens. Spotify is rethinking code review practices for agent-authored changes: what checks should humans focus on, what can linters and the LLM judge handle, and how should PR review time be allocated when 650+ agent PRs land in production every month.

Platform investment becomes leverage

Every platform capability exposed to agents multiplies across thousands of sessions. Adding Backstage component ownership to Honk’s context means every future session can route notifications, find the right team, and scope changes correctly — without any engineer configuring that per session. Spotify exposes these capabilities through MCPs and command-line tools so that agents can discover and use them in the same way humans do.

Human decision points must be explicit

Background agents do not interrupt to ask questions. Every decision point that previously happened through a tap-on-the-shoulder conversation must either be encoded in the prompt, handled by a verifier, or escalated through a defined channel (Honk v2 uses Slack integration for mid-session mentions, and a “Chirp” layer for multi-agent team coordination). The discipline of making implicit decisions explicit is uncomfortable but necessary — and it also improves how humans document and communicate changes.

claude -p "$(cat agent-task.txt)" \
  --allowedTools "Edit,Read,Bash(git diff),Bash(npm test),Bash(rg)" \
  --output-format text

#!/usr/bin/env bash
set -e

echo "Running agent..."
claude -p "$(cat agent-task.txt)" \
  --allowedTools "Edit,Read,Bash(git diff),Bash(npm test),Bash(rg)" \
  --output-format text

echo "Running verifiers..."
npm test          # or: pytest, cargo test, go test ./...
git diff --stat   # Show what changed

#!/usr/bin/env bash
DIFF=$(git diff)
TASK=$(cat agent-task.txt)

VERDICT=$(claude -p "You are a code reviewer. Here is the original task:
---
$TASK
---
Here is the diff the agent produced:
---
$DIFF
---
Does the diff accomplish exactly what was asked — no more, no less?
Reply with APPROVE or VETO, then one sentence explaining why." \
  --output-format text)

echo "Judge verdict: $VERDICT"
if echo "$VERDICT" | grep -q "^VETO"; then
  echo "Judge vetoed the change. Reverting."
  git checkout .
  exit 1
fi

claude -p "The following task failed:

$(cat agent-task.txt)

The error or veto reason was: <paste the output here>

What information was missing from the task description that would have
helped you complete it correctly?" \
  --output-format text

Where to go next

• Read the full Spotify Engineering series on Honk: Part 2 — Context Engineering, Part 3 — Feedback Loops, Part 4 — Dataset Migrations
• Explore Backstage and the Fleetshift plugin to understand how a software catalog enables fleet-scale automation
• Watch the original Code with Claude 2026 session for Niklas Gustavsson’s live demo and Q&A