Spotify mais que dobrou o volume mensal de mudanças de código com IA

O Spotify divulgou, em um balanço técnico comentado pela InfoQ em 12 de outubro de 2026, que o volume mensal de mudanças de código mescladas na empresa mais do que dobrou em um ano: de cerca de 8.100 para 17.000, na comparação de agosto a agosto. A aceleração vem do uso crescente de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → no desenvolvimento, e obrigou a empresa a rever controles de qualidade e confiabilidade que não foram desenhados para esse volume.

A escala que expôs os pontos fracos

Spotify opera quase 3.000 serviços em produção, que atendem 777 milhões de usuários ativos mensais, cerca de 100 milhões de clientes simultâneos e entre 11 e 12 milhões de requisições de backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → por segundo. Nessa escala, dobrar o ritmo de mudanças expõe rápido qualquer fragilidade de processo. A revisão interna da empresa identificou problemas em quatro frentes: processamento de conteúdo, mudanças na frota de serviços, capacidade de computação e qualidade dos aplicativos móveis.

O incidente de 24 de junho no pipeline de conteúdo

O pipeline de processamento de conteúdo do Spotify lida com mais de 500 mil novas músicas, vídeos, podcasts e audiobooks por dia. Em 24 de junho de 2026, três fatores se somaram: uma carga de processamento em lote programada competiu com a chegada de novos episódios, uma melhoria de qualidade aumentou os requisitos de processamento e um bug no agendamento reduziu a vazão em cerca de 10%. O resultado foi que episódios que normalmente apareciam em minutos ficaram horas atrasados.

Depois do incidente, o Spotify adicionou monitoramento ponta a ponta, corrigiu o agendador, moveu as cargas em lote para prioridade mais baixa, reorganizou a priorização de workloads e aumentou a capacidade. É um padrão comum em escala: a correção não ficou só no bug pontual, mas no processo em volta dele.

Fleet Management, Fleetshift e o agente Honk

Grande parte do salto em volume de mudanças vem da automação de manutenção. O sistema Fleet Management do Spotify já mesclou mais de 2,5 milhões de pull requests automáticos de manutenção, a maioria integrada automaticamente depois de checagens de segurança. O Fleetshift cuida da seleção de alvos, do agendamento e do acompanhamento de progresso dessas mudanças.

Para mudanças mais complexas, o Spotify criou o Honk, um agente de codificação em segundo plano que roda o modelo Claude via Agent SDK em pods Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps →. O Honk faz as modificações de código e pode rodar builds na esteira de CI. A empresa relata que uma migração recente para uma nova versão de Java em seus serviços de backend foi concluída em três dias com essa combinação de ferramentas.

Nem tudo correu sem atrito: uma atualização automática de dependência passou pelas checagens existentes e falhou em produção. Em resposta, o Spotify está reforçando salvaguardas, ampliando a capacidade de rollback e passando a agendar mudanças automatizadas dentro do horário de trabalho das equipes donas do serviço.

Os números por trás da mudança de perfil do trabalho

O tipo de trabalho que os engenheiros do Spotify mesclam também mudou. Trabalho de qualidade e otimização subiu de 27% para 31% do total de mudanças, enquanto manutenção e configuração caiu de 31% para 25%.

A empresa afirma não ter visto aumento correspondente de retrabalho, mas reconhece que o tamanho dos pull requests e a complexidade do código estão subindo. A revisão de incidentes não encontrou contribuição direta relevante de código escrito por IA nos problemas, mas concluiu que o volume de mudanças ultrapassou a capacidade de alguns controles de verificação.

O que dizem os desenvolvedores

Em publicações no LinkedIn, dois profissionais que acompanham o caso resumiram o dilema. Amit Jha, engenheiro de software na JumpCloud, escreveu:

Mais mudanças significaram mais pressão sobre testes, revisão e observabilidade.

More changes meant greater pressure on testing, review and observability.Amit Jha, engenheiro de software na JumpCloud

Alex Beck fez um ponto parecido sobre o verdadeiro gargalo:

Escrever código ficou mais fácil. A parte difícil agora é garantir que o trabalho realmente está bom antes de ir pra produção.

Writing code got easier. The hard part now is making sure the work is actually good before it goes live.Alex Beck

O que a pesquisa da DORA já vinha apontando

Os achados do Spotify dão contexto concreto à pesquisa DORA 2025 do Google, que associou a adoção de IA a maior throughput de entrega de software e melhor desempenho de produto, mas também encontrou uma relação negativa com a estabilidade das entregas. O relatório aponta testes automatizados, controle de versão e ciclos de feedback rápido como práticas relevantes para lidar com esse trade-off à medida que a adoção de IA cresce. O caso do Spotify é, na prática, essa pesquisa acontecendo dentro de uma empresa real.

O que ainda fica em aberto

O material divulgado não detalha quantos incidentes de produção aconteceram no período, nem o custo de rodar o Honk e o Fleetshift em escala via Agent SDK no Kubernetes. Também não há indicação pública de quanto tempo de engenharia foi redirecionado para configurar e manter essa pilha de automação. São lacunas relevantes para quem for comparar o caso do Spotify com a própria realidade antes de investir pesado em agentes de código.

O que muda pra quem constrói software no Brasil

O caso do Spotify é útil para qualquer time de engenharia brasileiro que esteja pensando em adotar agentes de codificação em escala, não só para quem opera no tamanho de um Spotify. Em resumo: acelerar a escrita de código com IA é a parte fácil; o gargalo migra para revisão, testes, observabilidade e capacidade de rollback, exatamente como mostram tanto o relato do Spotify quanto a pesquisa da DORA.

Antes de liberar um agente como o Honk para mexer em código de produção, vale medir se a esteira de CI, o monitoramento e os planos de rollback do time aguentam o dobro do volume atual de mudanças. Vale também revisar o agendamento de jobs automáticos: o incidente de 24 de junho do Spotify mostra como uma rotina de manutenção pode colidir com picos de carga real se ninguém olhar para a janela de execução. E vale acompanhar métricas como tamanho de pull request e complexidade de código, não só volume de mudanças entregues, porque é aí que o Spotify diz estar vendo o efeito colateral da velocidade.

Fonte: InfoQ