Кейс: автономный рефакторинг кодовой базы в масштабе

В январе 2026 мы позволили ИИ-агенту отрефакторить 140 файлов в 3 микросервисах. Ноль регрессий. Вот как именно — и какие сюрпризы нас ждали.

Проблема

Наш платёжный сервис накопил 18 месяцев техдолга. Три сервиса — payments-core, billing-api и invoice-gen — использовали устаревший формат данных. Каждый инженер оценивал работу в 3-4 недели.

Подготовка

Вместо назначения человеку мы написали спек:

goal: "Мигрировать все сервисы с PaymentV1 на PaymentV2"
scope:
  services: [payments-core, billing-api, invoice-gen]
  file_types: [.ts, .tsx]
constraints:
  - Все тесты проходят после миграции
  - Никаких изменений поведения — выход побайтово идентичен
  - Максимум 5 файлов на коммит
  - Каждый коммит независимо откатываем
verification:
  - Полный тест-сьют после каждого коммита
  - Интеграционные тесты после каждого сервиса
  - Ревью diff человеком после полной миграции

Выполнение

Агент работал в три фазы:

Фаза 1: Анализ (2 часа)

Агент замапил каждое использование PaymentV1: 140 файлов, 23 определения типов, 47 функций конвертации, 12 эндпоинтов, 8 запросов к БД.

Нашёл скрытую зависимость с четвёртым сервисом (notifications), которую мы не включили. Агент пометил это и остановился.

Фаза 2: Планирование (30 минут)

34 коммита по графу зависимостей. Каждый — максимум 5 файлов, независимо откатываем.

Фаза 3: Выполнение (6 часов)

31 из 34 коммитов прошли с первого раза. Три потребовали восстановления:

1. Коммит 12: тест проверял старый формат. Агент исправил в follow-up.
2. Коммит 23: состояние гонки, не связанное с миграцией. Классифицировано как out-of-scope.
3. Коммит 29: циклический импорт. Агент реструктурировал.

Цифры

Главный вывод

Спек был продуктом. Агент — инструментом. 2-часовой ревью человека был ценнее 4 недель ручного рефакторинга — фокус на верификации намерения, а не на механическом выполнении.

«Лучший рефакторинг — тот, где инженер только верифицирует, а не исполняет.»