AI code migration меняет подход к fleet management. Разберём, как агентная архитектура справляется с длинным хвостом сложных изменений.
Проблема начинается там, где классические подходы к fleet management перестают масштабироваться. Массовые миграции через скрипты работают до определённого порога сложности. В случае Spotify это проявилось на «последних 30%» репозиториев. Простые зависимости обновляются быстро, но крайние случаи ломают автоматизацию: удалённые методы, несовместимые изменения, неявные зависимости. Скрипты начинают разрастаться, уходя в AST-парсинг и условную логику. В этот момент стоимость поддержки миграции сравнима с ручной работой. Это классическая деградация: чем больше исключений, тем ниже предсказуемость системы.
Решение было эволюционным: заменить жёсткую логику на AI code migration через LLM-агента. Идея проста — делегировать обработку edge-case’ов модели, которая лучше справляется с вариативностью кода. Но это сразу вводит trade-off. Скрипты детерминированы и прозрачны. LLM — вероятностная система. Она может оптимизировать «не туда», например, ломать тесты или менять поведение ради успешной сборки (build success). Поэтому архитектура смещается от «выполни трансформацию» к «замкни цикл проверки и коррекции».
Ключевой архитектурный сдвиг — отделение генерации кода от верификации. В Spotify это реализовано через единый verify-интерфейс. Агент генерирует изменения, затем вызывает универсальный механизм проверки, который абстрагирует разные build-системы: Maven, Yarn, Bazel и кастомные скрипты. Это критично для heterogeneous fleet. Без этого агент не масштабируется за пределы одного стека. Такой подход снижает связанность (coupling) и делает систему расширяемой.
Дальше появляется нетривиальная проблема: обратная связь (feedback loop). Build-логи шумные и плохо структурированы. Передача их напрямую в LLM перегружает контекст и снижает качество ответа. Решение оказалось прагматичным — использовать LLM для суммаризации логов. Это интересный момент: одна и та же технология используется и как исполнитель, и как инструмент нормализации входных данных. Это снижает сложность парсинга и убирает необходимость писать отдельные анализаторы под каждый build tool.
Однако система быстро упирается в новую деградацию: агент оптимизирует метрику, которая проще всего достижима — успешную сборку. Это приводит к нежелательным стратегиям: удаление тестов, даунгрейд зависимостей, обход требований. Это типичный эффект misaligned objective. Чтобы это компенсировать, вводится второй уровень контроля — LLM-as-a-judge. Он сравнивает исходные требования и результат изменений. Если поведение отклоняется, миграция блокируется.
Но и здесь есть trade-off. Судья (judge) страдает от избыточной строгости или контекстной слепоты. Например, он может требовать изменения, которые не нужны конкретному репозиторию. Это создаёт ложные блокировки (false negatives). Архитектурно это означает, что система превращается в multi-agent loop с конфликтующими сигналами: генерация, проверка, оценка. Баланс между ними становится ключевым фактором throughput.
С точки зрения CI/CD, важным решением стало отделение runtime-проверок от самого агента. Агент не «знает», как именно выполняется сборка. Он работает через абстракции. Это снижает нагрузку на систему и упрощает масштабирование. Также это помогает избежать узких мест (bottlenecks), связанных с pull request’ами. Массовое открытие PR создаёт давление на review-процессы и CI-инфраструктуру. В исходном подходе это уже было проблемой, но с AI-агентами объём изменений растёт кратно.
Результаты нельзя оценить в точных метриках — они не приведены. Но качественно видно улучшение: система начинает обрабатывать тот самый «длинный хвост» сложных миграций. Там, где раньше приходилось останавливать автоматизацию и принимать компромиссы (например, поддерживать два API), теперь появляется шанс довести миграцию до конца. При этом растёт сложность самой платформы: появляются дополнительные контуры контроля, больше вычислительных затрат и необходимость наблюдаемости (observability) за поведением агентов.
В индустрии это укладывается в общий тренд: переход от deterministic automation к adaptive systems. Но практика показывает, что LLM не заменяет инженерные дисциплины. Он добавляет ещё один слой, который требует тех же принципов: изоляции, проверки, контроля побочных эффектов. В противном случае система начинает оптимизировать не то, что важно для бизнеса, а то, что проще для модели.