Em fevereiro de 2026, durante a divulgação dos resultados do Q4 2025, o co-CEO do Spotify Gustav Söderström soltou uma frase que repercutiu em toda a comunidade dev: "Quando falo com meus engenheiros mais seniores, eles não escreveram uma única linha de código desde dezembro. Eles só geram código e supervisionam." Não era retórica. O Spotify tinha acabado de entregar mais de 50 features em 2025 usando um sistema interno de agentes de IA chamado Honk, construído sobre o Claude Code da Anthropic.

O que chama atenção não é o hype. É a escala. São 1.500 pull requests gerados por IA já incorporados à produção, economia de 60 a 90% no tempo de migrações, e um workflow onde engenheiros despacham código pelo celular no caminho do trabalho. Essa é a história de como isso funciona por dentro.

O que aconteceu no Spotify em dezembro

O ponto de virada, segundo Söderström, coincidiu com o lançamento do Claude Opus 4.5 dentro do Claude Code em novembro de 2025. A partir de dezembro, os engenheiros seniores do Spotify pararam de abrir editores de texto. Em vez de digitar código, passaram a descrever o que precisavam em linguagem natural e revisar o resultado.

Isso não aconteceu do dia para a noite. O Spotify vinha investindo em automação de código desde fevereiro de 2025, quando iniciou uma investigação formal sobre integração de agentes de IA ao seu sistema de Fleet Management, a plataforma interna que aplica transformações de código em escala através de repositórios. Até meados de 2024, o Fleet Management já respondia por cerca de 50% de todos os pull requests do Spotify, mas só lidava bem com tarefas mecânicas: bump de dependências, atualização de configs, refactors simples. Código complexo ainda exigia mãos humanas.

A aposta em agentes de IA foi justamente para cobrir esse gap.

Como o Honk funciona

Honk é o codinome interno do agente de código do Spotify. Na prática, funciona assim: um engenheiro abre o Slack no celular durante o trajeto para o escritório, manda uma mensagem para o Claude pedindo para corrigir um bug ou adicionar uma feature ao app iOS. O Claude executa a tarefa, e o engenheiro recebe de volta no Slack uma nova build do app pronta para review. Se tudo estiver correto, faz merge para produção antes de chegar na mesa.

Söderström descreveu o fluxo exatamente assim durante o earnings call: "Um engenheiro no trajeto de casa, pelo Slack no celular, pode dizer ao Claude para corrigir um bug ou adicionar uma feature ao app iOS, e quando o Claude termina, o engenheiro recebe uma nova versão do app no Slack para fazer merge em produção, tudo antes de chegar ao escritório."

Por baixo desse workflow aparentemente simples, o Honk opera com três ferramentas restritas via Model Context Protocol (MCP):

  • Verify: executa formatadores, linters e testes usando o sistema de build interno do Spotify. Em vez de depender de arquivos AGENTS.md por repositório, o MCP permite operar em milhares de repositórios com configurações de build diferentes
  • Git: com subcomandos restritos, bloqueando push e alterações em origin, com formato padronizado de commit
  • Bash: com lista restrita de comandos permitidos, incluindo ripgrep para busca em código

Uma decisão que me pega é o que o Honk deliberadamente não tem. Não há ferramentas de code search nem de documentação acopladas ao agente. A equipe do Spotify condensou o contexto relevante diretamente no prompt, ou usa "workflow agents" separados para preparar prompts a partir de fontes internas e externas. A filosofia é clara: limitar as ferramentas reduz fontes de falha imprevisível.

Três gerações de agentes até o Claude Code

O Honk não nasceu pronto. O blog de engenharia do Spotify documenta três gerações distintas.

A primeira usou agentes open source como Goose e Aider. Funcionavam em demos, mas travavam ao escalar para milhares de repositórios. Gerar pull requests confiáveis em contextos tão diversos era inconsistente demais para uso em produção.

A segunda geração foi um loop agêntico construído internamente sobre APIs de LLM. Tinha restrições rígidas: usuários especificavam arquivos manualmente via comandos git-grep, com limite de 10 turnos por sessão e 3 retries. A equipe do Spotify descreveu essa abordagem como algo que "rapidamente se tornou incontrolável" para mudanças multi-arquivo.

A terceira geração é o Claude Code, e foi o salto. Max Charas (Senior Staff Engineer) e Marc Bruggmann (Principal Engineer) lideram o desenvolvimento. O Claude Code se tornou o agente de melhor performance do Spotify, usado em aproximadamente 50 migrações e na maioria dos PRs gerados por agentes em background que foram incorporados à produção.

O que mudou entre a segunda e a terceira geração? A equipe parou de dar instruções passo a passo. Com o Claude Code, os prompts descrevem o estado final desejado e deixam o agente descobrir como chegar lá. Essa diferença parece sutil, mas na prática determina se o agente consegue lidar com a variabilidade entre milhares de repos.

Context engineering: prompts como produto

Talvez a lição mais transferível do Spotify seja como eles tratam prompts. Não como texto descartável. Como produto.

A equipe identificou dois anti-padrões recorrentes quando o Honk foi disponibilizado para centenas de desenvolvedores. O primeiro: prompts genéricos demais, esperando que o agente "leia a mente" do autor. O segundo: prompts detalhados demais, que desmoronam assim que o agente encontra algo inesperado.

O meio-termo que funciona segue princípios específicos documentados na série de posts do blog de engenharia:

  1. Descrever o estado final, não o caminho
  2. Declarar explicitamente quando o agente não deve agir
  3. Incluir exemplos concretos de código no prompt
  4. Definir objetivos mensuráveis e verificáveis
  5. Uma mudança por prompt (mudanças atômicas)
  6. Usar o próprio agente para refinar prompts

Esse último ponto é o mais interessante. A equipe descobriu que o agente está "em uma posição surpreendentemente boa para dizer o que faltou no prompt." Ou seja, o loop de refinamento envolve rodar o agente, ver onde ele erra, perguntar a ele o que faltou, e ajustar. É meta, mas funciona.

Para migrações em larga escala, o Spotify adota o que chama de "prompts estáticos maiores": prompts longos e detalhados que são versionados no controle de versão, testados e avaliados em termos de performance. A migração de AutoValue para Java Records, por exemplo, usa um prompt estático que permite previsibilidade geral do agente.

Os resultados em números

Os dados públicos do Spotify sobre o Honk:

  • 1.500+ pull requests gerados por IA e incorporados à produção
  • 60 a 90% de economia de tempo em migrações comparado com escrita manual
  • Aproximadamente 50% de todos os PRs do Spotify já eram automatizados pelo Fleet Management antes do Honk (meados de 2024)
  • Centenas de desenvolvedores usando o sistema ativamente
  • 50+ features de produto entregues em 2025

Entre as features mais visíveis: Prompted Playlists, que permite criar playlists descrevendo o que se quer ouvir em linguagem natural (lançada em janeiro de 2026). Page Match, que escaneia uma página física de livro e pula para o trecho correspondente no audiobook (fevereiro de 2026). About the Song, que exibe detalhes de contexto diretamente no app (fevereiro de 2026).

O AI DJ, outra feature do Spotify, atingiu 90 milhões de assinantes e mais de 4 bilhões de horas de engajamento. As ferramentas de mixagem geraram, segundo o Spotify, 50 milhões de playlists criadas pelos usuários.

Os resultados financeiros do Q4 2025 mostram crescimento: 751 milhões de usuários ativos mensais, 290 milhões de assinantes Premium, receita de 4,5 bilhões de euros e 701 milhões de euros de lucro operacional — embora a correlação direta com a adoção de IA no desenvolvimento não tenha sido detalhada pela empresa.

Conclusão

O que o Spotify está fazendo não é futurismo. É produção. 1.500 PRs em produção, três gerações de iteração documentada, e uma filosofia de design que prioriza restrição sobre flexibilidade.

Duas coisas me ficam dessa história. A primeira: a decisão de limitar deliberadamente as ferramentas do agente em vez de dar acesso a tudo. Parece contraintuitivo, mas o Spotify diz que remover fontes de informação do contexto elimina falhas imprevisíveis. Menos capacidade, mais confiabilidade.

A segunda: a transição de "escrever código" para "supervisionar código" é real, mas exigiu quase um ano de experimentação (fevereiro de 2025 a dezembro de 2025). Não foi plug and play. Foi tentativa, falha, três gerações de arquitetura, e centenas de prompts refinados. Há também relatos de engenheiros que consideram a revisão de grandes volumes de código gerado por IA mais trabalhosa do que a escrita manual — um trade-off que o modelo de "supervisão de código" ainda precisa amadurecer.

Para quem quer replicar, o blog de engenharia do Spotify tem a série completa em três partes. A barreira não é o modelo de IA. É a infraestrutura de build, teste e deploy que precisa existir ao redor dele.

Referências pesquisadas nesta publicação