DEV Community: Jose Corral

How Spotify Automated Background Engineering with AI

Jose Corral — Fri, 20 Mar 2026 13:49:22 +0000

Most engineering teams think of changes to the codebase as a whole as a project. Spotify automated these changes in the background using AI.

Spotify's solution is called Honk, an AI agent for coding. It's an agent that makes changes to the codebase in the background without requiring an engineer to be brought into the work. It's not a chatbot integrated into a codebase. It's more like a background daemon for your entire codebase. Since implementing Honk, Spotify is now able to merge over 650 agent-created pull requests into production every month. For the migrations they have done so far, they have been able to save 60–90% of the time it would take to write the code by hand.

The problem Honk was designed to solve

At Spotify's scale, horizontal changes such as dependency upgrades, API changes, and convention enforcement have traditionally meant one thing: deterministic scripts. Write a script, execute it across all machines, validate output, and handle the edge cases it does not support. Sounds simple enough.

Well, it is, until it is not. Scripts are brittle. They fail on unknown code patterns, cannot reason about context, and take just about as long to write correctly as it does to do the migration in the first place. At a certain point, it just isn't worth it.
Honk flips the model. Instead of encoding every transformation in a script, engineers describe the change in plain language and the agent figures out how to apply it.

How it actually works

Honk is not open source, but rather an internal solution built on top of Claude Code and Claude Agent SDK. This is significant, as it is housed within Spotify's internal developer platform, called Backstage, which is open source. This is important, as all metadata is stored here, including what teams own what, what the status of services is, what level of security is required, and what level of reliability is needed. Honk reads all of this before ever touching any code.

If a developer wants to make a change, it is as simple as opening up Slack on one's phone, telling Claude to fix a bug or create a feature, and Claude writes the necessary code. Once the task is complete, a new version of the application is sent back to Slack for the developer to review. This means that bugs can be fixed before one ever gets to the office.

Initially, Spotify experimented with open-source agents such as Aider, and then developed their own agential loop using LLM API, and ultimately moved to Claude Code since their own approach demanded too rigid instruction sets and failed to handle complex and multi-step editing.

The verification loop

The first and foremost question for a non-deterministic AI is: how do you know it is actually right?

Context: Honk solves this with a tight feedback loop. The agent goes through the codebase, makes changes, and then runs formatters, linters, builds, and tests. Then it opens a pull request. If anything fails, it does not stop. It uses the failure and re-enters the loop. This continues until it succeeds or determines it cannot make it work and raises a flag for a human to look at it.

This is the magic of Honk. The AI makes the change. The toolchain checks it. You only see it when it has already passed CI.

What this means for your team

Honk is not an open-source tool, and it is closely integrated with Spotify's internal stack. However, the pattern it embodies is interesting nonetheless. You can't automate what you don't understand Everydev , Spotify's own team Every team involved with their own Backstage setup, or at least their own decent CI pipelines, can benefit from various pieces of this pattern today. Even the verification loop, considering the AI output untrusted until it passes your existing test suite, can be bolted onto any existing workflow today.

Teams running their own Backstage installation, or even just good CI pipelines, can start applying parts of this today. The verification loop, treating AI outputs as untrusted until they pass your existing test suite, can be bolted onto any workflow today.

Conclusion: The shift worth making

Honk is interesting, not because Spotify created an AI that can write code, there are plenty of solutions that can do that. Honk is interesting because they created an AI that thinks like an engineer: it knows scope, respects ownership, and verifies its own outputs before proceeding, and escalates when it's uncertain.

This is the hard part. Making an AI write a code change is easy. Making an AI think for itself across a dynamic, messy codebase with real services, real owners, and real consequences for getting it wrong requires infrastructure that most companies haven't yet developed.

The companies that will succeed at this are not the ones with the best AI models. They're the ones with good service catalogs, well-defined ownership, and CI systems so tightly controlled that they can catch the AI's mistakes. The AI is only as good as the system around it.

If you're interested in building something like this, start there, not with the AI.

Add`go fix` to Your CI Pipeline

Jose Corral — Fri, 20 Feb 2026 17:09:58 +0000

Most Go programmers have never invoked go fix in their CI pipeline. It’s been a dormant command for over a decade, originally designed for pre-Go 1.0 migrations, then left to rust. But it still works, and when hooked up to your CI pipeline, it becomes a stealthy enforcer that prevents your codebase from falling into antiquated ways.

The concept is simple: go fix will automatically refactor your code to conform to more modern Go idioms. Consider:

interface{} -> any
direct loop searches → slices.Contains
Or cumbersome sort.Slice calls → slices.Sort

How it works

Run it like you’d run go teston packages, not files:

# Apply fixes in-place
go fix ./...

# Preview changes without applying them
go fix -diff ./...

The -diff flag is the magic for CI integration. It prints a unified diff of what would change without modifying any files. If it’s empty, your code is already modern. If not, something is up for attention.

The tool is version-aware. It will read the go directive from your go.mod, and propose fixes only relevant to that version. A project on go 1.21 ill get min/max and slices.Contains rewrites, but not for range int (that’s 1.22+). Update your go.mod, and new modernizations will be enabled automatically.

The CI step

Here’s a GitHub Actions job that will fail if go fix finds modernization opportunities. Add it to your existing workflow:

name: Go Fix Check
on:
  pull_request:
  push:
    branches: [main, develop]
jobs:
  gofix:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
      - name: Check for go fix suggestions
        run: |
          OUTPUT=$(go fix -diff ./... 2>&1)
          if [ -n "$OUTPUT" ]; then
            echo "::error::go fix found modernization opportunities"
            echo ""
            echo "$OUTPUT"
            echo ""
            echo "Run 'go fix ./...' locally and commit the changes."
            exit 1
          fi
          echo "✓ No go fix suggestions - code is up to date."

When a PR brings (or leaves behind) code that could be refactored, the test will fail and print the diff exactly. The dev will run go fix ./... locally, commit, and push. Done.

A few things to note for multi-platform repos: go fix will only scan one GOOS/GOARCH per run. If you have platform-specific files, you might want to run it with different build modes:

- name: Check go fix (multi-platform)
        run: |
          for PAIR in "linux/amd64" "darwin/arm64" "windows/amd64"; do
            GOOS="${PAIR%/*}" GOARCH="${PAIR#*/}" go fix -diff ./... 2>&1
          done

What actually gets fixed?

Here’s a realistic before/after to give you a feel for the kind of changes go fix makes:

// Before
func contains(s []string, target string) bool {
    for _, v := range s {
        if v == target {
            return true
        }
    }
    return false
}

// After: go fix ./...
func contains(s []string, target string) bool {
    return slices.Contains(s, target)
}

// Before
for i := 0; i < len(items); i++ {
    fmt.Println(i, items[i])
}

// After: go fix ./...
for i := range len(items) {
    fmt.Println(i, items[i])
}

These are not only cosmetic changes slices.Contains is easier to understand and avoids a whole class of off-by-one errors in manually written loops. min/max are built-ins since Go 1.21and convey meaning directly.

Other typical changes include replacing interface{} with any, swapping context.WithCancel(contest.Background()) for t.Context() in tests, and deleting the no-longer-needed x:=x loop variable capture that Go 1.22 made redundant.

Tip: run it twice

Some fixes introduce new patterns that other analyzers can then optimize. Running go fix ./... a second time often reveals these follow-up optimizations. In reality, two passes is usually sufficient to reach a fixed point.

Go 1.26 makes this even better

Go 1.26 rewrote go fix from scratch on top of the Go analysis framework (the same one used by go vet), introducing over 24 modernizer analyzers and a new //go:fix inline directive that enables library authors to mark functions for automatic call-site inlining during migrations. If you’re using an earlier version of Go, you’ll have fewer analyzers at your disposal, but the CI pattern above remains the same. For the full scoop, see the official blog post.

Start today

The cost of entry is zero. You already have go fix installed, it comes with the Go toolchain. Add the CI step, run go fix ./... once on your codebase to flush out the backlog, and let the CI pipeline keep things tidy from there on out.
Your future self, browsing a PR diff that lacks a manually written contains loop, will thank you.