CHAPTERS
- 0:16 – 2:18
Spotify’s AI transition: engineering scale and rapid tool adoption
Niklas sets context on Spotify’s engineering organization and how developer experience has been a long-term focus. He highlights the unusually fast internal adoption of AI coding tools—especially Claude Code—and frames the talk around what changed and how Spotify is adapting.
- •~3,000 engineers with a strong devex optimization culture
- •High deployment velocity (~4,500 prod deployments/day)
- •Mixed repo strategy: huge backend monorepo plus thousands of polyrepos
- •AI tool adoption curve is unprecedented internally
- •Claude usage spikes notably after the Opus 4.5 release
- 2:18 – 3:49
Measuring impact: AI usage rates and productivity signals (PR frequency)
The talk quantifies adoption and perceived productivity gains across the org. PR frequency is used as an operational proxy for shipping velocity, showing a major step-change coinciding with improved models.
- •>99% of engineers use AI coding tools weekly
- •94% report increased productivity in the latest survey
- •PR frequency up ~76% and still rising
- •Most PRs now co-authored by an AI agent with the developer
- •Model improvements (Opus 4.5 timeframe) correlate with the jump
- 3:49 – 5:21
The hidden problem: codebase growth outpacing engineers and the maintenance tax
Niklas explains that code growth was already a critical issue pre-AI, with production code expanding far faster than headcount. Maintenance work—version upgrades, API deprecations, security fixes—was consuming increasing developer time.
- •Production code grew ~7x faster than engineer count (pre-AI)
- •Engineers spending more time maintaining vs. building new value
- •Recurring pain points: dependency/version migrations, deprecations, vulnerabilities
- •Old approach: broadcast migration guidance to hundreds of teams
- •Migrations routinely took months across thousands of components
- 5:21 – 6:22
Fleet management pre-AI: Fleetshift and automated maintenance PRs at massive scale
Spotify built fleet-wide automation to mutate large numbers of components consistently, reducing team-by-team manual upgrades. This system (Fleetshift) has merged millions of automated PRs, many without human involvement.
- •Shift from manual migrations to fleet-wide mutation model
- •Fleetshift orchestrates maintenance changes across repos
- •~2.5 million automated maintenance PRs merged to date
- •Most changes auto-merged with automation validating safety
- •Thousands of automated maintenance PRs shipped daily
- 6:22 – 7:54
Why deterministic scripts broke down: complexity, corner cases, and Hyrum’s Law
Automation via scripts worked for simple edits but became brittle for complex refactors like API replacements. Running changes across huge surfaces exposed endless edge cases, driving script complexity and fragility.
- •Simple config/dependency bumps: automation works well
- •Complex refactors: many coding variants and corner cases appear at scale
- •Migration scripts become “incredibly complicated”
- •Hyrum’s Law explains how all observable behaviors become depended upon
- •Motivation to explore LLMs for flexible transformations
- 7:54 – 9:55
Introducing Honk: LLM-powered fleet code changes and verification in CI
Spotify evolved from early LLM experiments into Honk, now powered by Claude via the Agent SDK. Honk runs in Kubernetes with access to trusted tools, including multi-OS build verification through CI, and plugs into Fleetshift orchestration.
- •Early LLM attempts struggled until models/patterns improved
- •Honk is the iteration result; now uses Claude + Agent SDK
- •Runs in Kubernetes pods and can be scheduled at scale
- •Uses trusted tools; verification includes running builds/CI
- •Integrated into Fleetshift for orchestrated multi-repo migrations
- 9:55 – 10:56
Operational workflow: tracking shift status and compressing migrations from months to days
Niklas shows how teams monitor a shift’s progress across dozens of repositories and intervene only when needed (e.g., CI failures). He cites dramatic cycle-time reduction, including a Java migration completed in three days by a single engineer.
- •Shift dashboard shows PR created/merged/failed status
- •Humans focus on exceptions (failed CI) rather than routine work
- •Large migrations no longer require hundreds of teams coordinating
- •Example: latest Java migration completed in ~3 days
- •Significant time savings compared to weeks/months previously
- 10:56 – 11:26
From internal platform to product: Fleetshift/Honk via Backstage commercial offering
Spotify is packaging these capabilities so other companies can use them through Backstage. This reflects a broader pattern of turning internal developer platform innovations into reusable products.
- •Fleetshift/Honk offered externally through Backstage packaging
- •Positions fleet automation as a reusable devex capability
- •Connects internal platform work to ecosystem adoption
- •Backstage serves as the distribution channel for the offering
- •Invitation to evaluate for similar enterprise migration needs
- 11:26 – 11:56
Developers repurpose Honk: Slack-driven agent requests and PR generation
Engineers quickly found interactive uses beyond planned fleet migrations by invoking Honk from Slack. A common pattern emerged: discuss in Slack, mention Honk, and receive a PR back, accelerating everyday engineering workflows.
- •Honk can be invoked over Slack like other AI assistants
- •Workflow: Slack conversation → @mention Honk → PR returned
- •Unplanned emergent behavior: developers innovate around the tool
- •Interactive, on-demand changes complement scheduled fleet shifts
- •Honk becomes a general-purpose internal coding agent
- 11:56 – 14:00
Honk V2 and Chirp: orchestration, shared sessions, and ‘multiplayer’ agent collaboration
Spotify releases an alpha of Honk V2 during Hack Week, focusing on interactive and collaborative agent usage. Integration with Chirp enables managing many agent sessions, shared “Google Docs-like” collaboration, and project-level organization.
- •Honk V2 alpha released (internally) with major new capabilities
- •Integrated with Chirp, Spotify’s agent orchestration system
- •Run many concurrent agent sessions; schedule Honk jobs
- •Shared sessions enable multi-developer collaboration
- •Project grouping supports larger feature/product efforts across sessions
- 14:00 – 16:32
Optimizing the codebase for agents: standardization as a force multiplier
Niklas argues that fewer technologies and consistent patterns accelerate teams and improve agent performance. Standardized stacks reduce decision overhead, ease collaboration, and provide agents with more consistent examples to learn from within the codebase.
- •Longstanding belief: fewer technologies → faster delivery
- •Benefits: deep expertise, fewer micro-decisions, easier cross-team contributions
- •Standardized backend services share stacks and patterns
- •Agents perform better in consistent codebases; worse in fragmented ones
- •Intentional variance for experimentation, not uncontrolled sprawl
- 16:32 – 18:33
Backstage as the system of record for humans and agents: catalog, ownership, and actions
Backstage evolved from a component ownership catalog into a central portal for operational actions and tooling. Agents can access this information via MCPs/CLIs to discover owners, coordinate via Slack, and navigate the org’s software landscape.
- •Backstage replaced ~100 scattered internal tools with a unified portal
- •Origin: catalog to identify component ownership (critical for incidents)
- •Now the main place developers take actions on components
- •Agent-accessible interfaces (MCPs/CLI tools) expose catalog capabilities
- •Agents can find owners and contact teams when clarification is needed
- 18:33 – 21:06
Driving consistency: tech radar, ‘golden state,’ Sound Check, and automated enforcement
Spotify encodes preferred technologies and practices through guidance and self-assessment in Backstage, then reinforces it with static analysis and linting. This gives both developers and agents fast feedback loops to align with platform constraints and best practices.
- •Technology radar communicates recommended vs. discouraged tech
- •‘Golden state’ defines preferred stacks/practices per component type
- •Sound Check enables teams to self-assess compliance (e.g., valid ownership)
- •Static analysis and lint checks implement the standards in code
- •Agents learn by feedback: lint failures prompt self-correction
- 21:06 – 23:40
What changes (and what doesn’t) with agents: verification, metrics, and human judgment
Niklas closes with lessons learned: strong engineering practices remain essential, especially tests and verification that agents can run. Spotify measures devex extensively and is rethinking where human review should apply amid a flood of AI-assisted PRs.
- •Engineering rigor still required; verification is foundational
- •Autonomy improves when agents can run tests/builds themselves
- •Heavy instrumentation across infra and PRs supports data-driven iteration
- •PR volume increases create review bottlenecks; selective review is needed
- •Auto-approvals for low-risk changes; focus humans where it matters
- 23:40 – 27:36
Coding is no longer the constraint: prototyping in production code and shifting bottlenecks
With agents accelerating implementation, Spotify sees coding become less of a bottleneck, especially for prototyping and early validation. Constraints move toward decision-making—choosing which ideas to pursue and what to ship—prompting new planning experiments.
- •Agents reduce implementation bottlenecks but don’t eliminate them entirely
- •Prototyping becomes dramatically cheaper and faster (minutes vs. days/weeks)
- •Non-engineers (including executives) can prototype in real monorepos
- •Prototype output: installable apps to test and share internally
- •New bottleneck: human decisions on prioritization and shipping; process changes underway
