A Dor das Migrações de Dataset em Escala
Se você já foi responsável por depreciar um dataset muito usado, sabe bem: uma longa cauda de consumidores downstream, pull requests manuais e reuniões intermináveis de coordenação. No Spotify, dois datasets de usuários pesadíssimos precisavam ser depreciados para dar lugar a novas versões com dimensões mais ricas. O problema? Cerca de 1.800 pipelines de dados downstream diretos, espalhados por três frameworks diferentes: BigQuery Runner (SQL), dbt e Scio (Scala). O esforço manual foi estimado em 10 semanas de engenharia.
Diante dessa perspectiva, o time recorreu ao agente de codificação interno, Honk, combinado com as plataformas Backstage e Fleet Management. Esta é a história de como eles conseguiram — e o que aprenderam para o futuro.
Passo 1: Encontrando os Repositórios-Alvo com o Backstage
Antes de qualquer alteração de código, é preciso saber o que alterar. O Spotify usou os plugins de linhagem de endpoint e Codesearch do Backstage para mapear cada consumidor downstream dos datasets depreciados. Cada página de endpoint no Backstage fornecia uma lista clara de repositórios que precisavam de migração. Com o Codesearch, eles escreveram consultas para encontrar repositórios-alvo em toda a paisagem do GitHub Enterprise, e orquestraram tudo com o plugin Fleetshift.
Passo 2: Engenharia de Contexto — A Parte Mais Difícil
Como discutimos na Parte 2 da série, a engenharia de contexto é a parte mais crítica — e mais difícil — de trabalhar com agentes de codificação em segundo plano. O Honk tinha que lidar com três frameworks de pipeline diferentes:
| Framework | Consistência | Desafio |
|---|---|---|
| BigQuery Runner | Alta | Padronizado, mais fácil de dar prompt |
| dbt | Alta | Padronizado, mais fácil de dar prompt |
| Scio | Baixa | Altamente variável por time, muito difícil de dar prompt corretamente |
O Que Não Funcionou
- Usar um guia de migração escrito para humanos como contexto: O Honk fez suposições incorretas sobre mapeamentos de campos.
- Tentar cobrir o Scio de forma abrangente: Sem acesso a skills Claude ou MCPs, o prompt ficou inviável. O time decidiu pausar as migrações Scio e focar nos outros dois frameworks.
O Que Funcionou
- Escrever tabelas de mapeamento explícitas no arquivo de contexto — sem suposições.
- Especificar ONDE NÃO migrar: Para campos que exigiam julgamento humano, o Honk os deixou inalterados, mas adicionou comentários com links para guias de migração.
Dica de ouro: Se sua base de código não tem testes unitários, a capacidade do Honk de verificar seu próprio trabalho fica limitada. Os repositórios de BigQuery Runner e dbt no Spotify raramente tinham testes de build, então o time dependeu de times downstream para verificação manual.
Passo 3: Rollout e Resultados
Usando o Fleetshift, o Spotify lançou 240 PRs de migração automatizados. A UI do Fleetshift forneceu um dashboard para monitorar o progresso, navegar pelos PRs e se comunicar com os times responsáveis — algo inestimável para troubleshooting.
Resultado: 10 semanas de engenharia economizadas. Milhares de pipelines downstream migrados sem esforço manual.
Limitações e Lições Aprendidas
1. Padronização é a Chave
O sucesso de migrações agentivas em larga escala depende de consolidar e padronizar sua paisagem de dados. Frameworks inconsistentes (como Scio) são muito mais difíceis de automatizar.
2. Infraestrutura de Testes é Fundamental
Sem testes unitários, os agentes não podem verificar seu próprio trabalho. Exigir testes em todos os repositórios é um pré-requisito para codificação autônoma.
3. Engenharia de Contexto Ainda é uma Arte
Mesmo com bom contexto, o agente pode cometer erros se o mapeamento não for explícito. Use tabelas, não prosa.
4. Não Esqueça do Humano no Loop
Algumas decisões exigem julgamento humano. Deixe comentários claros e links para os revisores.
O Que Vem por Aí para o Honk?
O time do Honk está trabalhando em uma feature que permitirá ao agente coletar seu próprio contexto — lendo tickets do JIRA, documentação e schemas antes de fazer alterações. Isso reduzirá a necessidade de engenharia de contexto prévia e melhorará a qualidade das mudanças de código.
Combinado com esforços estratégicos mais amplos em direção à padronização e testes, o Spotify espera que o Honk enfrente migrações ainda mais complexas de forma autônoma.
Próximos Passos para o Seu Time
- Audite sua paisagem de dados: Identifique frameworks usados de forma inconsistente.
- Padronize onde possível: Quanto mais uniforme sua base de código, mais fácil a automação.
- Invista em testes: Agentes que podem rodar testes e iterar são muito mais confiáveis.
- Comece pequeno: Tente automatizar uma única migração com um arquivo de contexto bem definido antes de escalar.
Se você se interessa pelo ecossistema Python que potencializa esses workflows, confira nossa análise dos novos recursos do Python 3.14.3. E para construir pipelines de IA visuais e code-first, veja nossa introdução ao Daggr.
Conclusão
A experiência do Spotify com Honk, Backstage e Fleet Management prova que agentes de codificação em segundo plano podem reduzir drasticamente o trabalho manual — mas apenas quando a infraestrutura os suporta. Padronização, testes e engenharia de contexto cuidadosa são as bases do sucesso.
As 10 semanas de engenharia economizadas nesta única migração são apenas o começo. À medida que o Honk ganha a capacidade de coletar seu próprio contexto e os agentes Claude Code subjacentes melhoram, o potencial para manutenção autônoma de software cresce exponencialmente.
Mensagem principal: Não espere mágica apenas dos agentes. Invista primeiro na consistência e testabilidade da sua base de código, e os agentes virão.