Миграция legacy-кода, которая раньше растягивалась на кварталы и годы, у ServiceTitan ужалась до пары недель для значительной части задач. В 50-минутном выступлении на InfoQ Principal AI Engineer Дэвид Стайн описал подход, при котором AI-агенты не «переписывают всё сразу», а конвейером переносят сотни мелких, строго проверяемых фрагментов кода. Для русскоязычных команд это важный сигнал: главный дефицит теперь не только в людях, а в качестве декомпозиции и валидации.
Как пишет InfoQ, Стайн рассказывал не про абстрактные демо с красивыми слайдами, а про реальную внутреннюю миграцию в ServiceTitan. Компания развивает платформу для подрядчиков и сервисного бизнеса: от HVAC и электрики до стройки и roofing. Внутри продукта важное место занимает отчётность: метрики по заявкам, инвойсам, техникам, клиентам и другим операционным данным. Проблема знакомая почти любой зрелой компании: за годы там накопился слой старого кода, завязанный на старые схемы баз данных, не всегда хорошо задокументированный и местами написанный людьми, которых в компании уже нет.
Стайн отдельно уточняет, что речь не о «лёгкой» миграции, где можно нажать кнопку и перегнать данные из одного формата в другой. Он говорит о сотнях тысяч строк кода, которым по 5-10 лет, с неочевидными зависимостями и неполным набором тестов. В ServiceTitan уже были попытки вынести часть старой логики отчётности в более современную архитектуру на базе data lakehouse, но проект буксовал. Это тот самый сценарий, который знаком многим техлидам: сотни Jira-тикетов, сотни инженерных недель, а где-то посередине возникает неприятный вопрос, не полезли ли вы не на ту гору.
Не «переписать всё», а разложить на конвейер
Ключевая идея Стайна проста и оттого неприятно практична. Просить LLM «перенеси мой legacy-монолит в новую архитектуру» бессмысленно примерно так же, как просить одного инженера за выходные перепридумать старую платформу. Модель теряет контекст, начинает додумывать детали, может изобрести новые метрики вместо переноса старых, сделать пять задач из пятисот и объявить работу почти завершённой. Стайн прямо перечисляет эти сбои: галлюцинации, непонимание задания, ложное ощущение прогресса и правдоподобный, но бесполезный результат.
Вместо этого команда ServiceTitan дробила миграцию до уровня «одного камня, а не всей горы». Для каждого отдельного переноса определялись одни и те же блоки: где лежит legacy-логика, какие таблицы и данные нужны, как выглядит целевой паттерн в новой системе, какие файлы надо поменять и как проверить, что результат совпадает с поведением старой реализации. В их кейсе речь шла о переносе метрик в стек с dbt MetricFlow и Semantic Layer. Когда задача сведена к повторяемому шаблону, её уже можно не раздавать людям по длинной доске задач, а запускать на потоке через агентов.
Стайн называет это assembly line pattern, то есть конвейерным подходом. Его логика в трёх шагах: декомпозировать, стандартизировать, автоматизировать. Первый и второй шаг инженерные команды умели и раньше. Новое здесь то, что в 2025 году LLM уже можно встроить в третий шаг и отдать ей не весь проект, а узкий, формализованный кусок. За счёт этого миграция legacy-кода перестаёт быть единичным героическим проектом и становится серией однотипных операций, которые можно сильно распараллелить.
Почему здесь важнее валидатор, чем сама модель
Самая интересная часть доклада даже не в слове AI, а в слове validation. Стайн несколько раз повторяет: если валидатор слабый, вы получите не ускорение, а дорогой генератор технического мусора. В ServiceTitan для проверки собрали отдельный симулятор, который строил отчёты через новую платформу и сравнивал их с результатами старого backend. Проверялись не только числа, но и форматирование, распределения данных и сопоставимость выборок. Иными словами, агенту недостаточно написать код, который «похож на правильный». Он обязан пройти машинную проверку с бинарным исходом: прошло или нет.
Дальше включается self-healing loop. Агент получает инструменты, сам собирает контекст, пишет код, запускает валидатор и, если видит расхождение, пробует снова. По словам Стайна, именно такой цикл позволил двигаться быстро, не превращая проект в лотерею. Команда несколько раз дорабатывала сам валидатор уже по ходу миграции нескольких сотен метрик, потому что именно он оказался главным элементом всей схемы. Это важный сдвиг для инженерных руководителей: раньше хорошая наблюдаемость и эталонные тестовые сценарии считались приятным бонусом, теперь без них автоматизированная миграция вообще не взлетает.
Ещё один приземлённый вывод из кейса: агентам нужен не «магический промпт», а доступ к нормальному рабочему контексту. В ServiceTitan для этого использовали обычный CLI и SnowSQL, чтобы модели могли смотреть реальные staging-данные в Snowflake, искать уже перенесённые артефакты и проверять свои изменения. Отдельно поддерживались файлы вроде migration_goals.txt и списка задач по фазам, где было зафиксировано, что считается готовностью, какими инструментами надо пользоваться и как проверять результат. То есть вместо разговоров о будущем без интерфейсов команда просто дала ботам тот же рабочий набор, которым пользуется живой инженер.
Практический итог звучит куда убедительнее большинства AI-историй на рынке. После настройки контекста, задач и валидатора система смогла перенести почти все оставшиеся метрики в крайне сжатый срок, буквально за пару недель. Около 15% задач всё же потребовали вмешательства инженера из-за высокой сложности, то есть автоматизация закрыла примерно 85% рутины. Для компаний с сотнями однотипных миграционных задач это уже не «интересный эксперимент», а вполне рациональная экономика. Особенно если альтернатива — держать команду в многоквартальном проекте с туманным финалом.
Для разработчиков и CTO вывод неприятно честный: AI не отменяет архитектурную дисциплину, а штрафует за её отсутствие. Если у вас нет внятной декомпозиции, эталонных данных, наблюдаемости и определения done, никакая миграция legacy-кода не станет быстрее. Зато у тех, кто это построит, появляется новая роскошь: не только переносить старое быстрее, но и раньше понимать, что выбранная архитектура не взлетает. Несколько недель вместо нескольких кварталов на такую проверку могут изменить не один backlog, а сам темп принятия технических решений.