Операции, которые в Datadog занимали до 45 минут, после миграции стали укладываться примерно в секунду. Команда перевела критичный сервис на новую модель хранения, а рефакторинг с ИИ использовала не как магию из презентаций, а как рабочий инструмент под жёстким контролем тестов. Для русскоязычных команд это полезный кейс без розовых очков: AI помогает тащить тяжёлый продакшен-код, но только там, где инженерия и до него была в порядке.
Об этом сообщает InfoQ со ссылкой на инженера Datadog Арнольда Вакима. Он рассказал, как команда меняла Stream Router, API для управления маршрутизацией в пайплайне метрик. Изначально сервис был построен как eventually consistent-система на key-value модели. Пока таблица маршрутизации была умеренного размера, схема жила. Когда связей и записей стало слишком много, база начала упираться в ограничения на размер транзакций, а самые тяжёлые операции деградировали до тысяч последовательных round trip-запросов.
Проблема была не только в скорости. В старой KV-модели приложению приходилось буквально изображать из себя реляционную базу: вытягивать десятки тысяч записей в процессы подов, вручную восстанавливать связи между сущностями и исполнять логику, которую в нормальной схеме держат внешние ключи и сама СУБД. Это знакомый антипаттерн для многих внутренних платформ: сначала key-value кажется быстрым и простым, потом бизнес-логика распухает, и код начинает платить за каждое архитектурное упрощение из прошлого.
Что именно сделала команда
Datadog не пыталась лечить симптомы. Инженеры пересобрали схему данных так, чтобы отношения между доменными сущностями были выражены явно, а не восстанавливались в коде. После этого предстояло самое неприятное: переписать значительную часть кодовой базы, сохранив прежний API, но переведя реализацию со старого FoundationDB-бэкенда на PostgreSQL. Здесь и подключили Claude и Cursor. По словам Вакима, модели не писали код автономно. Для каждого метода разработчики давали старую реализацию, описание новой схемы и падающий тест. Модель генерировала первый проход, а тесты быстро показывали, получилось ли хоть что-то кроме правдоподобного текста.
Ключевых условий успеха было три. Первое — хорошая модульность. Новый Stream Router смог реализовать тот же внешний API, но уже поверх PostgreSQL, не заставляя остальные части системы срочно переписываться вслед за ним. Второе — полноценный набор тестов, который давал бинарный ответ на каждый AI-сгенерированный шаг: работает или нет. Третье — параллельная инфраструктура для выката. В продакшене одновременно работали две независимые версии Stream Router: старая на FoundationDB и новая на PostgreSQL. Трафик между ними переключали через feature flags, а отдельный validator-сервис в каждом кластере регулярно сравнивал ответы обеих систем и сразу сигнализировал, если они расходились.
Сама миграция шла в три фазы. Сначала Claude использовали, чтобы описать намерение каждой ключевой функции: что именно она должна делать, где границы поведения, какие инварианты нельзя сломать. Затем команда переходила к точечным промптам: брала упавший тест, добавляла ожидаемое поведение и контекст из предыдущего шага, после чего просила модель исправить конкретный метод. Последний этап — выкат по blue/green-схеме, где две реализации жили параллельно и сравнивались в бою, а не в лабораторной стерильности. Это важная деталь: рефакторинг с ИИ здесь не заменял инженерный процесс, а встраивался в него как ускоритель для рутинной, но рискованной переписи.
Где ИИ помог, а где пришлось работать руками
Самая полезная часть этого кейса в том, что Datadog честно описала не только удачи. Высокоуровневые промпты, где модели предлагалось «понять задачу целиком», работали заметно хуже, чем короткие и жёстко сфокусированные задания. Claude генерировал запросы, которые были корректны по результату, но не по эффективности. Они делали слишком много round trip-обращений и не находили оптимизации, которые для опытного backend-инженера выглядят почти базовой техникой: batching, приёмы с UNNEST, common table expressions. Эти версии команда писала сама, а уже потом модель могла повторять увиденный паттерн в следующих методах. То есть ИИ неплохо копирует сильные решения, когда ему показали образец, но сам до них доходит не всегда, даже если такие подходы давно описаны в профильной литературе.
Вторая неприятная статья расходов — токены. По словам Вакима, команда слишком часто скармливала моделям полные дампы вывода тестов вместо коротких релевантных фрагментов. Добавьте сюда кодовый контекст, схему данных и несколько итераций уточнений — и получится не только дорогой, но и шумный цикл. Для компаний, которые уже смотрят на AI-инструменты как на часть delivery-процесса, вывод тут прямой: экономия времени разработчика легко съедается плохой подготовкой контекста. Если промпт похож на лог-файл после ночного инцидента, модель, скорее всего, тоже будет думать как после ночного инцидента.
Зато результат у Datadog получился вполне приземлённый и оттого убедительный. После миграции операции, которые раньше могли идти до 45 минут, стали занимать около секунды. Задержки сократились с сотен миллисекунд до единиц. Объём хранения данных уменьшился до 40 раз, CPU и память просели вниз, а расходы на базы данных, по оценке команды, снизились на 90%. Отдельно Ваким отмечает, что PostgreSQL и DuckDB упростили работу со связями и сделали запросы эффективнее. Иными словами, выигрыш был не только в скорости конкретной операции, но и в общей стоимости владения системой.
Для разработчиков и техлидов здесь есть довольно трезвый вывод. Рефакторинг с ИИ лучше всего работает не там, где проект разваливается, тестов нет, а схема данных напоминает коллективное творчество пяти эпох. Он работает там, где уже есть модульные границы, внятные контракты, хороший test suite и безопасный путь в прод через параллельный запуск и валидацию ответов. Тогда AI действительно сокращает время на механическую перепись кода и помогает быстрее пройти длинную миграцию. Если этой базы нет, модель, скорее всего, только ускорит производство правдоподобных ошибок.
Пожалуй, главный вопрос после этого кейса звучит так: станет ли bottleneck в крупных миграциях качеством моделей или качеством самой инженерной среды. Опыт Datadog подталкивает ко второму варианту. Похоже, следующий конкурентный разрыв будет не между командами, у которых есть Claude или Cursor, а между теми, у кого AI подключён к дисциплине тестов, хорошей архитектуре и нормальному продакшен-процессу, и теми, кто всё ещё надеется заменить это одним удачным промптом.