Desarrollo de software con IA: Spotify duplicó sus cambios de código y descubrió que escribir ya no es el cuello de botella

Spotify pasó de aproximadamente 8.100 a 17.000 cambios de código fusionados al mes en solo un año. Es la cifra más reveladora hasta ahora sobre el desarrollo de software con IA a escala real. Pero lo importante no es el número. La compañía reconoce que el volumen de cambios superó algunos de sus controles de verificación, y que tuvo que rediseñar monitoreo, pruebas y capacidad de reversión para no perder la calidad de la que presume ante 777 millones de usuarios activos mensuales.

El contexto importa: Spotify opera casi 3.000 servicios en producción, atiende a unos 100 millones de clientes concurrentes y procesa entre 11 y 12 millones de peticiones por segundo en backend. En su revisión interna, publicada en su blog de ingeniería y recogida por InfoQ, la empresa identificó problemas en cuatro frentes: procesamiento de contenido, actualizaciones masivas de la flota, capacidad de cómputo y calidad de las apps móviles. Un matiz clave es que, según Spotify, el «AI slop» (código basura generado por IA) no estaba entre las causas. Su análisis de incidentes no encontró una contribución directa material del código escrito por IA, y tampoco detectó un aumento del retrabajo, aunque sí crecen el tamaño de los pull requests y la complejidad del código.

El caso más ilustrativo ocurrió el 24 de junio. Un trabajo por lotes programado competía con episodios nuevos, una mejora de calidad había aumentado el cómputo necesario por episodio y un bug del planificador redujo el rendimiento en cerca de un 10%. El resultado: episodios que suelen publicarse en minutos tardaron horas, en una canalización que procesa más de 500.000 canciones, vídeos, podcasts y audiolibros nuevos cada día. Spotify añadió monitoreo de extremo a extremo, corrigió el planificador, bajó la prioridad de los lotes y amplió capacidad. La propia empresa admite que los orígenes fueron «corrientes»: alertas que fallaban en silencio y huecos en la planificación de capacidad. La IA aceleró las correcciones, pero el criterio siguió siendo humano.

La automatización, por su parte, abrió otro flanco. Su sistema Fleet Management ya ha fusionado más de 2,5 millones de pull requests de mantenimiento automatizado, la mayoría sin intervención humana tras pasar controles de seguridad. Sobre esa base añadieron Honk, un agente de programación en segundo plano que ejecuta Claude mediante el Agent SDK en pods de Kubernetes, mientras Fleetshift se encarga de seleccionar objetivos, programar y seguir el progreso. El resultado más llamativo: una migración de Java en todos los servicios backend completada en tres días. Sin embargo, una actualización automática de dependencias superó todas las verificaciones y aun así falló en producción, afectando a usuarios finales. A esto se suma un factor externo: Spotify señala que el auge de la IA ha disparado la demanda de CPU y GPU en toda la industria sin un aumento equivalente de oferta, lo que reduce la capacidad de reserva.

Cómo escalar el desarrollo de software con IA sin romper producción

La investigación DORA 2025 de Google ya apuntaba en esta dirección: la adopción de IA se asocia con mayor rendimiento en entrega y producto, pero también con una relación negativa con la estabilidad de las entregas. Spotify es la prueba práctica. Como resumió Alex Beck en LinkedIn, escribir código se volvió fácil; lo difícil es asegurar que el trabajo sea bueno antes de salir a producción. Estas son las lecciones aplicables a tu organización:

Mide el cuello de botella real. Si el volumen de cambios se duplica, revisa si tus pruebas, revisiones y observabilidad escalan al mismo ritmo. Spotify lo detectó porque revisó sus incidentes, no porque lo mostrara un panel de productividad.

Invierte en verificación antes que en generación. Pruebas automatizadas, control de versiones y ciclos de retroalimentación rápidos son las prácticas que DORA vincula con gestionar bien la aceleración.

Prepara la reversión. Spotify está ampliando su capacidad de rollback porque asume que algunos cambios, aunque pasen los controles, fallarán. Diseñar para el fallo es más barato que prometer que no ocurrirá.

Programa los cambios automáticos en horario laboral del equipo dueño. Un cambio masivo que falla un sábado por la noche sin nadie disponible multiplica el daño. Es una medida sencilla y casi gratuita.

Prioriza cargas de trabajo. Define niveles de servicio para que lo crítico (nuevas subidas, en el caso de Spotify) tenga preferencia cuando la capacidad escasea, y que los trabajos por lotes cedan.

Alerta sobre los fallos silenciosos. Si un error no despierta a nadie, nadie lo arreglará. Instrumenta de extremo a extremo antes de ampliar la automatización.

Hay otro dato útil para quien planifica la calidad del software con IA: la mezcla de trabajo cambió. Las tareas de calidad y optimización subieron del 27% al 31% de los cambios fusionados, mientras que mantenimiento y configuración bajaron del 31% al 25%. Es decir, la IA liberó tiempo de tareas rutinarias para dedicarlo a mejorar el producto. Esa es la señal de que la inversión está rindiendo, siempre que los controles acompañen.

Si buscas casos comparables, mira cómo Netflix usa un grafo de conocimiento para automatizar diagnósticos de observabilidad, cómo GitHub reescribió 800.000 líneas con migración de código asistida por IA y la advertencia de John Carmack sobre el código generado por IA que necesita refactorización. Los tres refuerzan la misma idea: la velocidad solo vale si puedes verificarla.

La pregunta que debería quitarte el sueño

La lección de Spotify es incómoda y útil: el desarrollo de software con IA no falla porque la máquina escriba mal, sino porque la organización sigue verificando como cuando se cambiaba la mitad. Antes de pedirle a tu equipo el doble de entregas, hazte una pregunta: si mañana tus cambios se duplicaran, ¿tus pruebas, tus alertas y tu capacidad de reversión aguantarían?