El Dolor de las Migraciones de Datasets a Gran Escala
Si alguna vez has sido responsable de deprecar un dataset muy usado, sabes de lo que hablo: una larga cola de consumidores downstream, pull requests manuales y reuniones interminables de coordinación. En Spotify, dos datasets de usuarios súper pesados necesitaban ser deprecados para dar paso a nuevas versiones con dimensiones más ricas. ¿El problema? ~1,800 pipelines de datos downstream directos, repartidos en tres frameworks diferentes: BigQuery Runner (SQL), dbt y Scio (Scala). El esfuerzo manual se estimó en 10 semanas de ingeniería.
Ante esa perspectiva, el equipo recurrió a su agente de codificación interno, Honk, combinado con las plataformas Backstage y Fleet Management. Esta es la historia de cómo lo lograron — y lo que aprendieron para el futuro.
Fuente: Blog de Ingeniería de Spotify
Paso 1: Encontrando los Repositorios Objetivo con Backstage
Antes de cualquier cambio de código, necesitas saber qué cambiar. Spotify usó los plugins de linaje de endpoint y Codesearch de Backstage para mapear cada consumidor downstream de los datasets deprecados. Cada página de endpoint en Backstage proporcionaba una lista clara de repositorios que necesitaban migración. Con Codesearch, escribieron consultas para encontrar repositorios objetivo en todo su GitHub Enterprise, y orquestaron todo con el plugin Fleetshift.
Paso 2: Ingeniería de Contexto — La Parte Más Difícil
Como discutimos en la Parte 2 de la serie, la ingeniería de contexto es la parte más crítica — y más difícil — de trabajar con agentes de codificación en segundo plano. Honk tenía que manejar tres frameworks de pipeline diferentes:
| Framework | Consistencia | Desafío |
|---|---|---|
| BigQuery Runner | Alta | Estandarizado, más fácil de dar prompt |
| dbt | Alta | Estandarizado, más fácil de dar prompt |
| Scio | Baja | Altamente variable por equipo, muy difícil de dar prompt correctamente |
Lo Que No Funcionó
- Usar una guía de migración escrita para humanos como contexto: Honk hizo suposiciones incorrectas sobre los mapeos de campos.
- Intentar cubrir Scio de manera integral: Sin acceso a skills Claude o MCPs, el prompt se volvió inmanejable. El equipo decidió pausar las migraciones Scio y enfocarse en los otros dos frameworks.
Lo Que Funcionó
- Escribir tablas de mapeo explícitas en el archivo de contexto — sin suposiciones.
- Especificar DÓNDE NO migrar: Para campos que requerían juicio humano, Honk los dejó sin cambios, pero añadió comentarios con enlaces a guías de migración.
Tip de oro: Si tu código base no tiene tests unitarios, la capacidad de Honk para verificar su propio trabajo es limitada. Los repos de BigQuery Runner y dbt en Spotify rara vez tenían tests de build, así que el equipo dependió de los equipos downstream para la verificación manual.
Paso 3: Rollout y Resultados
Usando Fleetshift, Spotify lanzó 240 PRs de migración automatizados. La UI de Fleetshift proporcionó un dashboard para monitorear el progreso, navegar por los PRs y comunicarse con los equipos responsables — invaluable para troubleshooting.
Resultado: 10 semanas de ingeniería ahorradas. Miles de pipelines downstream migrados sin esfuerzo manual.
Limitaciones y Lecciones Aprendidas
1. Estandarización es Clave
El éxito de las migraciones agentivas a gran escala depende de consolidar y estandarizar tu paisaje de datos. Los frameworks inconsistentes (como Scio) son mucho más difíciles de automatizar.
2. Infraestructura de Pruebas es Fundamental
Sin tests unitarios, los agentes no pueden verificar su propio trabajo. Exigir pruebas en todos los repositorios es un prerrequisito para la codificación autónoma.
3. Ingeniería de Contexto Sigue Siendo un Arte
Incluso con buen contexto, el agente puede cometer errores si el mapeo no es explícito. Usa tablas, no prosa.
4. No Olvides al Humano en el Loop
Algunas decisiones requieren juicio humano. Deja comentarios claros y enlaces para los revisores.
¿Qué Sigue para Honk?
El equipo de Honk está trabajando en una funcionalidad que permitirá al agente recopilar su propio contexto — leyendo tickets de JIRA, documentación y esquemas antes de hacer cambios. Esto reducirá la necesidad de ingeniería de contexto previa y mejorará la calidad de los cambios de código.
Combinado con esfuerzos estratégicos más amplios hacia la estandarización y las pruebas, Spotify espera que Honk pueda enfrentar migraciones aún más complejas de forma autónoma.
Próximos Pasos para tu Equipo
- Audita tu paisaje de datos: Identifica frameworks que se usan de forma inconsistente.
- Estandariza donde sea posible: Cuanto más uniforme sea tu código base, más fácil será la automatización.
- Invierte en pruebas: Los agentes que pueden ejecutar tests e iterar son mucho más confiables.
- Empieza pequeño: Intenta automatizar una sola migración con un archivo de contexto bien definido antes de escalar.
Si te interesa el ecosistema Python que impulsa estos workflows, echa un vistazo a nuestro análisis de las nuevas características de Python 3.14.3. Y para construir pipelines de IA visuales y code-first, mira nuestra introducción a Daggr.
Conclusión
La experiencia de Spotify con Honk, Backstage y Fleet Management demuestra que los agentes de codificación en segundo plano pueden reducir drásticamente el trabajo manual — pero solo cuando la infraestructura los soporta. Estandarización, pruebas e ingeniería de contexto cuidadosa son los cimientos del éxito.
Las 10 semanas de ingeniería ahorradas en esta única migración son solo el comienzo. A medida que Honk gane la capacidad de recopilar su propio contexto y los agentes Claude Code subyacentes mejoren, el potencial para el mantenimiento autónomo de software crece exponencialmente.
Mensaje principal: No esperes magia solo de los agentes. Invierte primero en la consistencia y testabilidad de tu código base, y los agentes vendrán.