spotifyMay 18, 2026

Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify | Spotify Engineering (opens in new tab)

Spotify argues that AI has shifted software development’s main constraint from writing code to coordinating people, systems, and decisions. Years of investment in standardized platforms, automation, and developer experience enabled Spotify to adopt AI coding tools at extraordinary scale. The company’s experience suggests that consistent infrastructure and strong feedback loops are essential for making both human developers and coding agents effective. ## Rapid AI Adoption - More than 99% of Spotify engineers use AI coding tools weekly. - 94% report improved productivity. - Pull request frequency has increased by 76%, with most PRs created by developers working alongside AI agents. - Adoption accelerated sharply after the release of Claude Opus 4.5. ## Fleet Management Before AI Agents - Spotify’s codebase was growing seven times faster than its engineering workforce. - Developers increasingly spent time on dependency upgrades, API migrations, and vulnerability fixes. - Fleet Management automated changes across hundreds or thousands of components. - Its orchestration system, Fleetshift, has merged more than 2.5 million maintenance PRs, most without human intervention. - This approach reduced migrations from work taking weeks or months across many teams to centrally managed operations. ## Honk: A Background Coding Agent - Deterministic scripts struggled with complex refactoring and the edge cases found across large codebases. - Spotify created Honk, a background coding agent powered by Claude through the Agent SDK. - Honk runs in Kubernetes pods, allowing many coding sessions to execute concurrently. - It can use trusted tools and run builds in CI across multiple operating systems. - Fleetshift identifies targets, schedules work, and tracks PRs, while Honk performs the code changes. - A recent Java migration across Spotify’s backend services took three days. - Engineers can invoke Honk through Slack, where it uses conversation context to create and return PRs. - Honk v2 adds shared sessions, team projects, and agent orchestration through Chirp. ## Standardization Improves Agent Performance - Spotify’s principle of limiting the number of technologies it supports reduces decisions and improves collaboration. - Consistent service architectures and design patterns also give AI agents better reference material. - Agents perform worse in fragmented codebases with inconsistent conventions. - Backstage provides a unified internal developer portal and catalog for software components. - Spotify exposes Backstage capabilities to agents through MCP integrations and command-line tools. - Agents can discover component ownership, read documentation, and contact responsible teams. ## Guardrails Through Backstage - Backstage’s Soundcheck and “golden state” define recommended technologies and practices. - Teams can assess their components against these standards. - Static analysis and linting provide immediate feedback when developers or agents use unsuitable patterns. - This creates a feedback loop that helps agents correct their work and drives consistency across the organization. Spotify’s experience indicates that scaling AI development requires more than giving engineers access to models. Organizations should invest in standardized platforms, searchable component metadata, automated fleet-wide workflows, and strong validation systems so agents can operate reliably at team scale.

backstagek8sai-agentslack+4

spotifyApr 6, 2026

Background Coding Agents: Supercharging Downstream Consumer Dataset Migrations (Honk, Part 4) | Spotify Engineering (opens in new tab)

Spotify used its Honk background coding agent with Backstage and Fleet Management to automate migrations from two deprecated datasets to new versions. The effort targeted roughly 1,800 downstream pipelines and produced 240 automated pull requests, potentially saving about 10 engineering weeks. The experience showed that agents perform best when repositories follow standardized patterns, prompts contain precise technical context, and automated testing is available. ## The Challenge of Large-Scale Dataset Migrations - Two heavily used datasets needed replacement to support new dimensions and features. - The datasets had approximately 1,800 direct downstream pipelines and affected thousands more indirectly. - Migrations spanned three frameworks: - BigQuery Runner - dbt - Scala-based Scio - Manual migration was estimated to require around 10 engineering weeks within a six-month deadline. ## Using Backstage to Identify Consumers - Backstage’s endpoint lineage pages revealed downstream dataset consumers. - Its Codesearch plugin located relevant repositories across Spotify’s GitHub Enterprise environment. - The Fleetshift plugin used those results to organize and orchestrate repository migrations. - Backstage also provided a centralized view for tracking progress and opening generated pull requests. ## Context Engineering for Honk - Honk needed detailed, self-contained prompts because it could not access external documentation, dataset schemas, MCPs, or custom Claude skills during execution. - Scio was excluded because its flexible, inconsistent implementations made it difficult to describe all migration cases in one reliable prompt. - BigQuery Runner and dbt were more standardized, making them better candidates for automation. - An initial prompt based on a human migration guide was insufficient and caused incorrect assumptions about field mappings. - Explicit mapping tables in the context file significantly improved results. - Prompts also specified cases where fields should not be migrated automatically. - Honk left those fields unchanged. - It added comments linking to human migration guidance for later review. ## Testing and Automated Pull Requests - BigQuery Runner and dbt repositories generally lacked build-time unit tests. - As a result, Honk could not automatically verify and correct its changes, one of its key capabilities. - Downstream teams had to manually test the generated pull requests before merging. - Despite this limitation, the team successfully created 240 automated migration PRs. - Fleetshift’s Backstage interface simplified monitoring, troubleshooting, repository navigation, and communication with owning teams. ## Lessons for Future Agent-Driven Maintenance - Large-scale automation depends on standardizing frameworks and data practices across repositories. - Consistent testing and validation requirements are essential so agents can verify their own changes. - Future Honk functionality will allow agents to gather context from sources such as JIRA tickets and documentation before editing code. - Better context gathering should reduce the need for exhaustive prompt files and improve migration quality. Spotify’s experience suggests that background coding agents can substantially reduce migration toil, but their effectiveness depends on disciplined standardization, explicit migration rules, and strong automated testing.

backstagedatabase-designdata-pipelinebigquery+4

spotifyFeb 19, 2026

How We Release the Spotify App: A Look Under the Hood (Part 2) | Spotify Engineering (opens in new tab)

Spotify’s Release Manager Dashboard replaced a Jira-heavy workflow with a unified command center for mobile and desktop releases. It reduces context switching and cognitive load by aggregating release status, bugs, testing, build health, and usage metrics into one interface. A backend that caches and pre-aggregates data from roughly ten systems makes the dashboard fast and affordable. ## From Jira to a Release Command Center - Previously, Release Managers depended on Jira tickets, multiple browser tabs, and Slack conversations. - This made it easy to miss details and required constant context switching. - The dashboard was designed to: - Prioritize the Release Manager’s workflow. - Remain understandable to anyone familiar with Spotify’s release process. - Reduce cognitive load. - Support fast, accurate decisions. ## Release Data Spotify treats each platform-and-version combination as a **track**. Android, iOS, and Desktop share some libraries but are released independently. - Track-specific information includes: - Current release state. - Release-blocking bugs. - Team regression-testing sign-offs. - Final release candidate build status. - Build verification test results. - App Store upload status. - Crash, ANR, and CPU-exception rates per song. - Daily active users. - The dashboard also highlights: - Blocking bugs without an assigned version. - Bugs without a priority. - Reports from internal users and alpha/beta testers. - Release management includes finding appropriate owners for unassigned issues, even when temporary team ownership is needed. ## React, TypeScript, and Backstage - The dashboard is a Backstage plugin built with React and TypeScript. - Spotify’s Backstage ecosystem already provides: - Software Catalog functionality for distributing builds to app stores. - App-build and crash plugins with deeper detail. - Shared UI components and data across developer tools. - The interface provides a quick health overview, with drill-down capabilities for investigating blockers. - Status colors communicate urgency: - **Green:** Ready for the next stage. - **Yellow:** Something still needs attention. - **Red:** An error requires corrective action. ## Backend Aggregation and Performance - A dedicated backend acts as an API gateway for approximately ten existing systems. - It consolidates their data into one consistent API for the dashboard. - The initial implementation queried large amounts of data on every reload, making it slow and expensive. - Caching and five-minute pre-aggregation reduced load time to about eight seconds while significantly lowering operating costs. ## Dashboard Sections ### Production - Shows the currently deployed Android, iOS, and Desktop versions. - Since these releases have completed the release process, only production metrics are displayed. - Metrics include: - Crash data. - Rolling daily active users over the previous 24 hours. - This helps Release Managers detect problems shortly after rollout. ### Current - Displays the branched version that has not yet reached production. - Tracks release blockers such as: - Open blocking bugs. - Incomplete regression testing. - Crash rates above release thresholds. - Builds that do not contain the latest release-branch commits. - Yellow indicators represent pending work, while red indicators call for direct investigation or action. - The ITGC section confirms that full production rollout is permitted only after: - ITGC tests pass. - Reporting is correct. - Data loss remains below the defined threshold. - A Release Status Ping link generates a Slack update with the release’s current state. ### Upcoming - Mirrors the Current release view for the next planned version. - Sections that are not yet relevant are shown in a grayed-out state. The dashboard illustrates how a specialized aggregation layer and focused UI can turn a fragmented release process into a clear operational workflow. For organizations managing complex, multi-platform releases, combining cached cross-system data with color-coded status and drill-down details can improve both speed and release safety.

backstageci-cdreacttypescript+4