Spotify: la IA aumenta la velocidad y obliga a reforzar la verificación

Spotify ha publicado una revisión poco complaciente de los problemas de calidad que aparecieron al aumentar el ritmo de desarrollo con herramientas de inteligencia artificial. El punto central no es que el código generado por IA sea automáticamente peor. Según el análisis interno de la compañía, el riesgo más visible fue que el volumen de cambios creció más deprisa que algunos controles de revisión, pruebas, despliegue, observabilidad y recuperación.

El ejemplo más concreto aparece en el procesamiento de contenido. Spotify recibe más de 500.000 canciones, vídeos, podcasts y audiolibros nuevos cada día. Una combinación de factores provocó retrasos de horas en episodios que normalmente se publicaban en minutos: un trabajo por lotes competía con nuevas cargas, una mejora de calidad había aumentado el coste de cómputo por episodio y un error del planificador redujo el rendimiento alrededor de un 10 %. Además, algunos fallos de procesamiento podían quedar ocultos y la falta de capacidad de transcodificación no generaba una alerta suficiente.

La respuesta fue esencialmente de ingeniería operativa: monitorización de extremo a extremo, corrección del planificador, menor prioridad para trabajos por lotes, más capacidad y una nueva jerarquía de servicios y cargas. Cuando los recursos escasean, las cargas críticas y las nuevas publicaciones deben tener precedencia. La lección es sencilla: una métrica de éxito situada solo al final del proceso no basta si las etapas intermedias pueden fallar silenciosamente.

Spotify también detectó nuevos riesgos en la automatización de cambios. Su sistema Fleet Management puede aplicar modificaciones a gran escala después de pasar comprobaciones de seguridad, y durante más de un año ha gestionado cambios impulsados por agentes, incluida una migración de Java completada en tres días. Sin embargo, una actualización automática de dependencias superó los controles y falló en producción. La compañía está ampliando las salvaguardas, mejorando la capacidad de rollback y programando cambios automatizados durante el horario de los equipos responsables.

Los datos internos ayudan a evitar una conclusión demasiado fácil. En agosto, los cambios fusionados pasaron aproximadamente de 8.100 a 17.000 en un año. El trabajo clasificado como calidad y optimización subió del 27 % al 31 %, mientras que mantenimiento y configuración bajaron del 31 % al 25 %. Spotify no identificó el código escrito por IA como causa directa material de los incidentes revisados, pero sí observó que la velocidad de cambio estaba presionando los controles de verificación.

La compañía también está revisando sus métricas. Ha separado la reelaboración real de la refactorización de código antiguo y observa que el tamaño de las solicitudes y la complejidad están creciendo. No ha relajado esos umbrales para que las cifras parezcan mejores. Esa cautela importa: en un entorno donde un agente puede producir unidades de cambio mayores, las métricas históricas deben reevaluarse, no descartarse.

El mensaje para otros equipos es práctico. Aumentar la capacidad de escribir software solo mejora el resultado si también aumentan la observabilidad, las pruebas de regresión, el despliegue gradual, la reversión y la medición de calidad. La IA puede acelerar la ejecución, pero la arquitectura de entrega sigue necesitando señales independientes que indiquen si el sistema continúa funcionando para sus usuarios.