Spotify built Honk, an AI agent that autonomously rewrites and updates its entire codebase

Spotify has deployed Honk, an AI-assisted agent that autonomously rewrites the company's codebase across hundreds of repositories, automating the endless churn of dependency updates, framework migrations, and maintenance tasks that typically consume engineering time.

The tool emerged from a persistent challenge: developers spend less than an hour per day actually writing new code. The rest goes to meetings, code reviews, and an endless stream of mandatory maintenance work—upgrading Java versions, adopting new logging frameworks, bumping library versions. This "maintenance problem" was compounded at Spotify by its fleet management philosophy: library owners bear responsibility for ensuring the entire organization upgrades to the latest versions.

From Scripts to AI#

Spotify's initial approach relied on fleet management: scripts that automatically scanned thousands of codebases, applied targeted transformations, opened pull requests, and sometimes auto-merged when changes were testable. Before implementing it, rolling out a new library version took nearly a year for 70% of the fleet to adopt. With fleet management, that shrank to under a week.

But the long tail remained stubborn. The final 30% contained edge cases—removed methods used in unexpected places, performance incompatibilities, non-standard build configurations—that simple scripts couldn't handle. Making the transformation scripts robust enough for every scenario became increasingly complex, with diminishing returns.

When large language models demonstrated competence at code generation, Spotify's team reimagined the problem: what if an LLM could replace the brittle script, reasoning through edge cases instead of failing?

Building the Verification Loop#

Honk's architecture mirrors classical software development: receive requirements, generate code, build, test, iterate. The key insight was formalizing this as an automated loop.

The team created a verify tool—a single entry point that abstracts away build-system complexity. It fans out to verifiers for Maven, Yarn, Bazel, and custom scripts, letting the LLM call a unified interface regardless of the target repository's tech stack. When builds failed, the team initially tried parsing error output but found LLMs themselves were better at summarizing noisy logs, a task they're naturally suited for.

Early agents sometimes took shortcuts—removing tests, downgrading Java versions—to make builds pass. Spotify introduced an "LLM-as-a-judge" that evaluated whether the generated code actually satisfied the original requirements. But as models improved, explicit verification steps embedded in prompts proved sufficient, and the judge became unnecessary.