Spotify вдвічі збільшив обсяг коду через AI

Друга автоматизована лінія: хто саме мержить мільйони змін

Паралельно із загальним зростанням кількості змін у Spotify працює окрема система автоматизації — Fleet Management. Вона вже злила понад 2,5 млн автоматичних pull request'ів з обслуговування коду, і більшість із них мержаться автоматично після перевірок безпеки, без участі людини.

Для складніших змін компанія додала Honk — фонового агента на базі Claude (через Agent SDK), який працює в Kubernetes-подах, самостійно вносить правки в код і запускає збірки в CI. Fleetshift при цьому відповідає за вибір цілей, планування та відстеження прогресу, а Honk — безпосередньо за код. За словами Spotify, завдяки цій зв'язці нещодавня міграція на Java в backend-сервісах зайняла три дні.

Але й ця лінія автоматизації не убезпечила від збоїв: за словами Spotify, одне автоматичне оновлення залежностей пройшло всі наявні перевірки й усе одно відмовило у production. Після цього компанія посилює захисні механізми, розширює можливості швидкого відкату змін і планує автоматичні зміни на робочі години команд, які відповідають за відповідний код.

Як саме стався збій із контентом 24 червня

Інцидент, згаданий у короткій версії, мав не одну причину, а збіг трьох факторів одночасно: запланований batch-процес конкурував за ресурси з обробкою нових епізодів, покращення якості обробки саме в цей час збільшило навантаження, а в логіці планування ресурсів стався окремий баг.

У результаті пропускна здатність пайплайна впала приблизно на 10%, і контент, який зазвичай з'являвся протягом кількох хвилин, затримувався на години. Спотify усунула причину не одним патчем, а комплексом заходів:

• додала end-to-end моніторинг, щоб бачити затримку раніше за користувачів
• виправила сам планувальник
• перенесла batch-завдання в нижчий пріоритет
• переробила логіку пріоритизації навантаження
• збільшила обчислювальні потужності

Що каже DORA 2025 про цю закономірність

Дослідження Google DORA 2025, на яке посилається матеріал, фіксує: використання AI пов'язане з вищою швидкістю доставки коду й продуктивністю, але водночас — із негативним зв'язком зі стабільністю релізів. DORA називає практики, що допомагають керувати цим ризиком при зростанні обсягів AI-коду: автоматизоване тестування, контроль версій і швидкі цикли зворотного зв'язку.

Інженери, які коментували кейс Spotify в LinkedIn, описують ту саму проблему практично: More changes meant greater pressure on testing, review and observability (Amit Jha, JumpCloud) і Writing code got easier. The hard part now is making sure the work is actually good before it goes live (Alex Beck).

Де межа: що зросло, а що — ні

У Spotify частка роботи над якістю й оптимізацією зросла з 27% до 31% змін, а частка обслуговування та конфігурації впала з 31% до 25%. Кількість переробок при цьому не зросла, хоча pull request'и стають більшими й складнішими за обсягом. Власний розбір інцидентів компанії не виявив суттєвого прямого внеску AI-згенерованого коду в збої — проблема була в тому, що обсяг змін випереджав частину механізмів перевірки.

Перед тим як масштабувати AI-розробку, варто перевірити ті самі точки, які посилила Spotify:

• чи моніторинг фіксує проблему раніше, ніж її побачить користувач
• чи тестування встигає за новим обсягом змін, а не за попереднім
• чи є швидкий і випробуваний спосіб відкотити зміну
• чи зростання кількості pull request'ів не випереджає зростання спроможності команди їх перевіряти

Дати запуску Honk та деталей вартості впровадження цієї системи в матеріалі немає.