O Novo Gargalo Não é o Código — é a Tomada de Decisão
Por anos, a narrativa na engenharia de software foi que escrever código era o gargalo. Otimizamos IDEs, adotamos linguagens mais rápidas e investimos em pipelines de CI/CD — tudo em nome de entregar mais código, mais rápido. Mas o que acontece quando ferramentas de IA tornam a codificação quase sem esforço?
O Spotify está vivendo essa realidade. De acordo com Niklas Gustavsson, Chief Architect e VP de Engenharia do Spotify, a empresa atingiu um ponto onde 99% dos engenheiros usam ferramentas de IA semanalmente, e 94% relatam aumento de produtividade. A frequência de pull requests subiu 76%, com a maioria dos PRs agora sendo escritos por um desenvolvedor trabalhando junto com um agente de IA.
"Lançamos ferramentas internas o tempo todo para tornar nossos desenvolvedores mais produtivos, mas nunca vimos a taxa de adoção que vimos com ferramentas de IA."
Essa mudança não significa que o time de engenharia está pronto — significa que o gargalo mudou. O verdadeiro desafio agora é a tomada de decisão humana: o que construir, como priorizar e como revisar a enxurrada de código gerado por IA.
A abordagem do Spotify, compartilhada no Code with Claude 2026, oferece um modelo para qualquer organização que esteja escalando a experiência do desenvolvedor na era da IA. Você pode assistir à palestra completa aqui.
De Migrações Manuais ao Gerenciamento de Frota: A Base
Antes dos agentes de IA, o Spotify enfrentava um problema diferente. A base de código de produção crescia 7x mais rápido que o número de engenheiros. Os desenvolvedores estavam afogados em manutenção — atualizando dependências, migrando APIs, corrigindo vulnerabilidades. As migrações eram a maior fonte de frustração.
Em vez de pedir para centenas de times atualizarem componentes manualmente, eles construíram o Fleet Management. O motor por trás disso, o Fleetshift, automatiza mudanças em milhares de componentes. Até hoje, o Spotify já mesclou mais de 2,5 milhões de PRs de manutenção automatizados, a maioria mesclada automaticamente sem intervenção humana.
"Em vez de fazer isso componente por componente e manualmente, podemos imaginar uma maneira de fazer isso como uma forma de mutar toda a nossa frota de componentes?"
Mas scripts determinísticos encontraram um limite com mudanças complexas — substituir chamadas de API ou refatorar padrões de uso. Foi aí que os LLMs entraram.
Conheça o Honk: O Agente de Codificação em Segundo Plano do Spotify
Honk é o agente de IA interno do Spotify, construído sobre o Claude usando o Agent SDK. Ele roda em pods Kubernetes, tem acesso a sistemas de build CI em múltiplos SOs e se integra diretamente ao Fleetshift para orquestração.
# Exemplo conceitual: Como o Honk pode ser acionado via Slack
# Esta é uma representação simplificada da lógica de orquestração
def lidar_comando_slack(comando):
"""
Lida com uma mensagem do Slack que menciona o Honk.
Extrai a tarefa, cria uma sessão e retorna um PR.
"""
if "@honk" in comando:
tarefa = extrair_tarefa(comando)
id_sessao = criar_sessao_agente(tarefa)
url_pr = executar_honk_em_k8s(id_sessao)
return f"Honk está trabalhando nisso! O PR estará em {url_pr}"
return None
Em uma migração Java recente entre serviços de backend, o Honk completou a migração inteira em três dias — trabalho que antes levava centenas de times semanas ou meses.
Agora o Honk está disponível via Slack. Engenheiros podem mencioná-lo no meio de uma conversa, e ele sai, trabalha no problema e volta com um PR. O Honk v2 introduz colaboração multijogador: sessões de agente compartilhadas e projetos de time através do Chirp.
Experiência do Desenvolvedor é para Agentes Também
Um dos princípios de engenharia mais antigos do Spotify é: "Quanto menos tecnologias em que somos líderes mundiais, mais rápido vamos." Isso é anterior à IA em muitos anos. Ao padronizar um conjunto focado de tecnologias, eles constroem expertise mais profunda e facilitam a colaboração entre engenheiros.
Esse princípio se mostrou igualmente importante para agentes. Quando o Claude tem código consistente para referência, ele performa significativamente melhor. Em bases de código fragmentadas, o desempenho do agente é visivelmente pior.
"Se o Claude tem muito código para olhar, e esse código é razoavelmente consistente, o Claude fará um trabalho melhor."
Backstage: O Painel Único
O Backstage, o portal interno de desenvolvedor (IDP) open source do Spotify, é o ponto de partida para essa consistência. Antes do Backstage, o Spotify tinha cerca de 100 ferramentas internas diferentes. Agora, tudo está consolidado em um catálogo de componentes de software.
As capacidades do Backstage são expostas como MCPs e ferramentas de linha de comando, para que o Claude possa consultar quem é o dono de um componente, ler sua documentação ou enviar uma mensagem para o time responsável no Slack.
Soundcheck e Golden State: Guardrails Ativos
O golden state define as tecnologias e práticas recomendadas para cada tipo de componente. O Soundcheck fornece uma interface para os times autoavaliarem seus componentes em relação a esses padrões. Combinado com análise estática e linting, esses padrões se tornam guardrails ativos. Quando o Claude usa um padrão não ideal, ele recebe feedback imediato do sistema de lint e se corrige.
"Quando o Claude trabalha na nossa base de código, ele recebe feedback imediato se está usando o conjunto certo de tecnologias e padrões de design."
Esse loop de feedback funciona tanto para desenvolvedores quanto para agentes — e tem sido uma das maneiras mais eficazes de impulsionar a consistência em escala.
O Futuro: Mais Ideias, Decisões Mais Rápidas
Com a velocidade da codificação disparando, o gargalo se desloca para as decisões humanas. O Spotify sempre teve mais ideias do que capacidade de construí-las — mas agora qualquer um pode abrir o Claude no monorepo do cliente e prototipar uma funcionalidade em minutos. Até o CEO cria protótipos dessa forma.
"Isso trouxe a prototipação de algo que podia levar dias ou semanas para literalmente minutos agora."
O lado negativo: 76% mais PRs para revisar. O Spotify está aprendendo onde aplicar o julgamento humano — mesclando automaticamente o que é seguro, focando a revisão onde é mais importante — e repensando o planejamento à medida que o gargalo se move da codificação para a tomada de decisão.
Limitações e Cuidados
- Código gerado por IA ainda precisa de revisão. A mesclagem automática funciona para manutenção simples, mas mudanças de lógica complexas exigem supervisão humana.
- Padronização é uma faca de dois gumes. Excesso pode sufocar a inovação; o "golden state" do Spotify precisa evoluir continuamente.
- Colaboração de agentes é incipiente. Sessões multijogador (Honk v2) são promissoras, mas a confiabilidade em escala real ainda não foi comprovada.
Próximos Passos para Sua Organização
- Invista em um portal de desenvolvedor (Backstage ou similar) para criar uma fonte única de verdade para seu catálogo de software.
- Padronize sua stack de tecnologia — mesmo que doa no começo. A consistência compensa tanto para humanos quanto para IA.
- Comece pequeno com automação. O Fleet Management não aconteceu da noite para o dia. Escolha uma migração dolorosa e automatize-a.
- Trate agentes como desenvolvedores de primeira classe. Dê a eles as mesmas ferramentas, documentação e loops de feedback que seus engenheiros humanos.
Fleetshift e Honk estão disponíveis como parte do Spotify Portal para Backstage. Se orquestrar mudanças complexas de código em escala é relevante para sua organização, entre em contato com o time de plataforma do Spotify para uma demonstração personalizada.
Leitura Recomendada: