Код больше не узкое горлышко: как Spotify масштабирует DevEx на команды и агентов

Коротко

Никлас из Spotify рассказывает, как компания с ~3000 инженеров перевела разработку на AI-агентов: 99% инженеров используют AI-инструменты еженедельно, частота PR выросла на 76%, большинство мерджей сейчас написаны агентом совместно с разработчиком. Главный инструмент, внутренняя обёртка над Claude Agent SDK под названием Honк, работающая поверх системы Fleet Shift, которая ещё до AI домерджила 2.5 млн автоматических maintenance-PR. Параллельно Spotify годами стандартизировал стек и инфраструктуру (Backstage, golden state, soundcheck, линтеры), и теперь видит прямую связь: эта консистентность определяет, как хорошо Claude работает в монорепе. Бутылочное горлышко сместилось с написания кода на ревью и принятие решений: PR-ов слишком много, и человеческое суждение приходится фокусировать туда, где оно реально что-то решает.

Главный тезис

Сильные инженерные практики, стандартизация кодовой базы и измеримая инфраструктура не отменены AI-агентами, они определяют, насколько эффективно агенты работают, и сдвигают узкое место с написания кода на принятие продуктовых решений.

Ключевые идеи

• 0:46, Spotify оперирует ~3000 инженеров, бэкенд лежит в монорепе на 40 млн строк кода, плюс тысячи polyrepo, и делает ~4500 деплоев в день.
• 2:23, более 99% инженеров используют AI-инструменты для кода еженедельно, 94% в опросе подтверждают рост продуктивности при рекордной самооценке.
• 1:57, взрывной рост произошёл вокруг релиза Opus 4.5 в ноябре, именно тогда Claude Code «completely exploded» по внутренней статистике.
• 3:03, частота PR выросла на 76% и продолжает расти; большинство PR теперь авторизованы агентом совместно с разработчиком.
• 4:02, ещё до AI кодовая база росла в 7 раз быстрее, чем число инженеров, поэтому Spotify заранее инвестировал в автоматизацию обслуживания.
• 5:50, система Fleet Shift домерджила 2.5 млн автоматических maintenance-PR, большинство, без human-in-the-loop.
• 7:27, детерминированные миграционные скрипты ломаются о Hyrum's Law: код имеет настолько широкую API-поверхность, что при прогоне по миллионам строк всплывают все corner cases.
• 8:05, Honk, внутренняя обёртка над Claude Agent SDK, запускаемая в Kubernetes pod, с собственным harness и доверенным набором tool-ов для верификации (включая CI-сборки на нескольких ОС).
• 10:45, миграция Java для JVM-бэкенда, которая раньше занимала месяцы по сотням команд, теперь делается одним инженером за 3 дня.
• 11:26, разработчики сами додумали вызывать Honk через Slack-меншн, и это стало распространённым паттерном, Honk возвращается с готовым PR.
• 11:49, Honk V2 интегрирован с оркестратором агентов Chirp, добавляет multiplayer-режим («Google Docs для Claude»), shared sessions и проектные группировки.
• 14:15, внутренняя догма: чем меньше технологий, тем быстрее команды; теперь это работает и для агентов, Claude хуже справляется в фрагментированных кодовых базах.
• 16:40, Backstage стартовал как каталог владельцев компонентов, а сейчас всё, что делает разработчик, экспонируется агентам как MCP или CLI-инструменты.
• 19:01, стандартизация оформлена через technology radar, golden state (рекомендованные стеки и практики по типу компонента) и UI Soundcheck для самоаттестации команд.
• 20:13, статический анализ и линтеры дают немедленный feedback Claude прямо в процессе работы: спикер видит, как агент сам себя исправляет, наткнувшись на правило.
• 23:01, обратная сторона ускорения: PR-ов на ревью стало настолько больше, что это главная жалоба разработчиков в последнем опросе.
• 25:05, теперь любой сотрудник, включая CEO, может прототипировать в реальном production-монорепе клиента: Claude собирает приложение, его можно установить и расшарить.
• 23:45, кодинг перестаёт быть бутылочным горлышком, ограничения смещаются в сторону человеческих решений: что строить, что показывать пользователю.

Почему это важно

Это редкий публичный отчёт изнутри флагманской компании о том, как 3000-инженерная организация реально переезжает на агентов: не «мы внедрили Copilot», а полный стек, Fleet Shift, Honk, Chirp, Backstage, Soundcheck. Anthropic выигрывает от кейса (Claude как дефолт в production-пайплайне крупного клиента), Spotify коммерциализирует свой пайплайн через Backstage как продукт для других компаний, а вся индустрия получает чёткое подтверждение: ставка на стандартизацию и измеримость инфраструктуры окупается именно сейчас, когда агенты начинают писать большинство кода. Для конкурентов сигнал: без консистентной кодовой базы и автоматической верификации даже сильная модель деградирует.

Идеи

• AI-инструменты дали Spotify самый быстрый adoption rate среди всех инструментов, которые они когда-либо раскатывали.
• Скачок Claude Code пришёлся не на анонс модели, а на конкретный релиз Opus 4.5, именно качество модели, а не маркетинг, переключило кривую.
• Спикеру пришлось менять цифру по PR frequency прямо во время подготовки слайдов, настолько быстро всё растёт.
• Fleet Shift отлично работал для конфигов и bump-ов зависимостей, но сломался на замене API-вызовов, именно сложные миграции стали полигоном для LLM.
• Ранние попытки LLM-миграций провалились: «модели были слишком тупые, и мы тоже подходили слишком тупо», оба фактора признаются честно.
• Honk начинался как способ ускорить миграции, но превратился в общую агентскую платформу, паттерн «инструмент перерос задачу».
• Версионирование Honk, это уже фактически 8-я версия, маркируемая как V2: внутренние продукты живут вне маркетинговой логики.
• Honk выполняется в Kubernetes pod-ах, то есть агентские сессии трактуются как обычная распределённая нагрузка, а не как «AI-фича».
• Сборка проверяется на нескольких операционных системах, потому что клиент Spotify работает на разных ОС, верификация подстроена под реальные продуктовые ограничения.
• Slack-вызов агента возник снизу, не как продуктовое решение, разработчики переоткрыли паттерн самостоятельно.
• Honk V2 включает shared agent sessions, концепция «Google Docs для Claude», multi-human + agent коллаборация.
• Идея «меньше технологий = быстрее» предшествует появлению AI на 15+ лет, но именно сейчас приносит дивиденды.
• Spotify напрямую видит, что фрагментированные кодовые базы деградируют Claude, это эмпирическое наблюдение, не теория.
• Backstage начинался не как портал, а как простой каталог владельцев, чтобы знать, кого пейджить при инциденте.
• Все Backstage-инструменты экспонируются агентам как MCP/CLI, человеческий developer portal превращается в agent portal без переделок.
• Claude может запинговать команду-владельца в Slack с вопросом, агент становится участником коммуникации, а не только кодером.
• Линтеры выполняют двойную роль: обучают и разработчика, и агента соблюдать стандарты, причём агент исправляется немедленно, без code review.
• Spotify авто-апрувит часть PR без человеческого ревью, порог «достаточно безопасно для merge» становится отдельным инженерным решением.
• Прототип можно собрать в реальной production-монорепе клиента, а не в отдельной песочнице, это меняет экономику валидации идей.
• CEO лично собирает прототипы, нижняя граница технической экспертизы для участия в продуктовой разработке сдвинулась.
• Время прототипа упало с «дней/недель» до минут.
• Узкое место сместилось не в ревью или инфраструктуру, а в продуктовые решения, что вообще строить.
• Spotify считает, что через 6 месяцев их продуктовая разработка будет «совершенно другой», открытое признание, что текущие практики временные.
• Метрики PR frequency собираются через инструментацию инфраструктуры, а не через ручную отчётность, измерять можно только то, что инструментировано.
• Fleet management теперь коммерциализируется как продукт через Backstage, побочный эффект внутренней эффективности становится бизнес-линией.

Инсайты

• Скорость кода без стандартизации стека ведёт к деградации агентов, консистентность кодовой базы становится прямым множителем качества модели.
• Любая детерминированная автоматизация кодовых изменений упирается в Hyrum's Law, LLM нужны не столько для интеллекта, сколько для устойчивости к corner cases.
• Инфраструктура, спроектированная для людей (developer portal, линтеры, owner-каталог), оказывается готовой агентской инфраструктурой без переделок, это говорит о том, что хороший DX и хороший agent experience изоморфны.
• Бутылочные горлышки в разработке не исчезают, они мигрируют: пока кодинг был дорогим, дефицит был на разработчиков; теперь дефицит, на способность принимать решения и ревьюить.
• Рост частоты PR создаёт новый класс проблем, review backlog, который классические инженерные практики не закрывают; нужны новые механизмы автоапрува по уровню риска.
• Прототипирование в production-кодовой базе уничтожает разделение «исследователь vs инженер», продуктовая валидация становится доступна без посредников.
• Инвестиции в наблюдаемость инженерной системы (instrumentation всего пайплайна) окупаются именно в момент AI-перехода, потому что без метрик невозможно увидеть сдвиг продуктивности и узких мест.
• Распространение агентских инструментов идёт снизу через самоорганизацию разработчиков (Slack-вызов Honk), это сильнее, чем сверху-вниз продуктовое внедрение.
• Multiplayer-агенты сигналят, что следующая фаза, это не «человек ↔ агент», а команда людей ↔ команда агентов с общим состоянием.
• Чем больше кода пишет агент, тем важнее становятся дешёвые быстрые сигналы корректности (линт, тесты, CI на нескольких ОС), именно они формируют петлю обратной связи для модели.
• Стратегия «меньше технологий» из эпохи людей перенеслась на эпоху агентов без изменений, это дисциплина, у которой не было ожидаемой временной привязки, и она оказалась универсальной.

Цитаты

«more than 99% of our engineers use AI coding tools every week», 2:23 Более 99% наших инженеров используют AI-инструменты каждую неделю

«94% of our engineers reports that using AI tooling has helped them become more productive», 2:34 94% инженеров сообщают, что AI-инструменты сделали их продуктивнее

«We're seeing today an increase of 76% in PR frequency», 3:03 Частота PR выросла на 76%

«our production code base was growing seven times faster than the number of engineers», 4:02 Production-кодовая база росла в семь раз быстрее, чем число инженеров

«we've now merged 2.5 million of those automated maintenance PRs», 5:50 Мы смерджили 2.5 миллиона автоматических maintenance-PR

«Code, as it turns out, has a very, very wide API surface», 7:02 У кода, как выясняется, очень-очень широкая API-поверхность

«The models were just too stupid. The way we were trying to do it was just too stupid», 7:57 Модели были слишком тупыми. И мы пробовали делать это тоже слишком тупо

«the latest Java migration we did took three days», 10:45 Последняя миграция Java заняла у нас три дня

«the fewer technologies that we use, the faster we will be able to go», 14:21 Чем меньше технологий мы используем, тем быстрее можем двигаться

«if Claude has a lot of other code to look at and that code looks roughly consistent, Claude will do a better job», 16:16 Если у Claude есть много другого кода для изучения и он выглядит примерно одинаково, Claude справится лучше

«All of those tools were kind of shit as well», 17:06 Все эти инструменты были, в общем-то, дерьмовыми

«imagine Google Docs or something similar, but for Claude», 13:02 Представьте Google Docs или что-то похожее, но для Claude

«one of our most frequent feedbacks at the moment is there's just too many freaking PRs to review», 23:01 Один из самых частых отзывов сейчас, слишком много чёртовых PR-ов для ревью

«coding is much less of a bottleneck now», 23:45 Кодинг сейчас гораздо меньше является узким местом

«Spotify is a company that has too many ideas», 24:31 Spotify, компания, у которой слишком много идей

«anyone, including as it turns out one of our CEOs, are now building these prototypes», 25:57 Любой человек, включая, как выясняется, одного из наших CEO, теперь собирает прототипы

«in six months or so I think we'll have a very very different way of building products», 27:08 Через примерно полгода у нас будет совершенно другой способ строить продукты

Факты

• Spotify держит ~3000 инженеров и делает 4500 деплоев в production ежедневно.
• Бэкенд, монорепо на 40 миллионов строк кода; рядом, тысячи polyrepo.
• 99%+ инженеров используют AI-инструменты для кода каждую неделю; 94% отчитываются о росте продуктивности.
• Рост частоты PR, +76% (цифра продолжает расти).
• До AI кодовая база росла в 7 раз быстрее числа инженеров.
• Fleet Shift домерджил 2.5 млн автоматических maintenance-PR, большинство, auto-merge без человеческого ревью.
• Скачок adoption Claude Code произошёл вокруг релиза Opus 4.5 (по словам спикера, в ноябре прошлого года).
• Honk построен поверх Claude Agent SDK, запускается в Kubernetes pod внутри собственного harness.
• Honk умеет запускать CI-сборки на нескольких операционных системах для верификации.
• Последняя миграция Java, 3 дня одним инженером вместо месяцев работы сотен команд.
• Honk V2 анонсирован на Hack Week, на день раньше выступления (то есть «вчера» относительно доклада).
• Spotify работает в Backstage 15+ лет в эволюционирующей форме, спикер сам 15 лет в компании и Backstage появился до него.
• Внутренние правила оформлены как technology radar, golden state, Soundcheck UI для самоаттестации команд.
• Fleet Shift + Honk коммерциализируются как продукт через Backstage Developer Portal.
• Прототипирование в production-кодовой базе клиента доступно через набор skills и кастомную инфраструктуру.

Источники

• Hyrum's Law, закон, сформулированный инженером Google: при достаточном числе пользователей API все наблюдаемые свойства системы становятся зависимостями.
• Claude Agent SDK, основа Honk.
• Backstage, open-source developer portal, созданный в Spotify.
• Fleet Shift / Fleet Management, внутренняя система массовых code-модификаций.
• Honk / Honk V2, внутренний агентский инструмент.
• Chirp, внутренний оркестратор агентских сессий, аналог Claude Agents / Agent Deck.
• Soundcheck, UI в Backstage для самоаттестации компонентов.
• Упомянуты для сравнения: Claude Agents, Agent Deck.
• Boris (вероятно, представитель Anthropic), упомянут как спикер утренней keynote.

Итог

Spotify показывает: AI-агенты не отменяют инженерную дисциплину, а делают её решающим фактором. Выигрывает тот, кто заранее построил консистентный стек, измеримую инфраструктуру и автоматическую верификацию, именно там модель раскрывает скорость.