1Password - чему нас научил рефакторинг монолита с помощью AI-агентов

B5 в 1Password - это монолит на Go объёмом в несколько миллионов строк. Команда распиливает его на сервисы и на протяжении всей работы использует AI-агентов. Статья честно разделяет то, что далось легко, и то, где возникли проблемы.

Что сработало: агенты создают детерминированные инструменты

Первым шагом команды было не "пусть агенты напишут рефакторинг", а "пусть агенты создадут анализаторы, нужные для планирования рефакторинга". Инструментарий, объединивший анализ Go SSA, парсинг SQL и интеграцию с DataDog через MCP, позволил построить карту владения доменами и порядок выделения сервисов: Vault -> Billing -> AuthN/AuthZ -> ядро Identity. С этого момента команды спорили уже об устойчивых артефактах, а не об интерпретациях модели. В этом суть концепции agent-built-deterministic-tools.

Побочный эффект создания инструментария: телеметрия DataDog, потребовавшаяся для построения карты связности, дала компании сквозную видимость транзакций, которой раньше не было. Не связанный с задачей, но очень реальный плюс.

Миграция MustBegin: идеальная точка окупаемости

MustBegin - это используемый командой запуск транзакций с паникой при сбое базы данных. Таких вызовов в коде было больше 3000. Процесс миграции:

1. Сгенерированный через SSA манифест каждого места вызова
2. Классификация мест вызова по повторяющимся паттернам
3. Шаблоны преобразований под каждый паттерн
4. Инструкции (playbooks) с описанием сбоев и правил эскалации
5. Параллельные агенты в git worktree'ах

Выполнение заняло считаные часы. Почти всё календарное время ушло на инструменты и спецификации. Главная мысль: "Когда работа полностью специфицирована и ограничена рамками, агенты работают быстро и точно". Это ровно та же схема, что в acceptance-criteria-ids и specsmaxxing - сначала превратить экспертную оценку в понятный артефакт, и только потом запускать агентов.

Где всё сломалось: выделение сервисов

Выделение сервисов дало прирост продуктивности всего на 20-30%. Выявились три типа проблем:

• Ошибки в последовательности шагов. Агенты заполняли колонки UUID историческими данными до обновления кода вставки, что приводило к тихой потере данных. Ошибка из тех, что очевидны постфактум, но незаметны на код-ревью.
• Путаница с владением. Общие таблицы воспринимались так, будто каждый сервис владеет ими единолично, что приводило к конфликтам при развёртывании.
• Домыслы. Когда контекста не хватало, агенты закрывали пробелы локально правдоподобными догадками (например, предполагали, что формат идентификатора - ULID).

Общий вывод: вариативность моделей допустима, когда задача строго ограничена. Но она обходится слишком дорого, когда последствия зависят от порядка действий или их трудно откатить.

Четыре урока

В статье опыт сведён к четырём выводам:

1. Генерация кода - не узкое место. Узкие места - это ограничения последовательности, эволюция схем, порядок развёртывания и границы общего состояния.
2. Изолируйте недетерминированность. Используйте агентов для создания детерминированных анализаторов и манифестов, а затем жестко ограничивайте дальнейшую работу их результатами.
3. Явные спецификации предотвращают неявные домыслы. Если не задать инварианты, порядок выполнения и пути эскалации, агент придумает их сам - локально разумные, но глобально ошибочные.
4. Параллелизм требует решённой изоляции. Одновременная работа нескольких агентов возможна, только когда изменения структурно независимы. Worktree'ы решают проблему на уровне файловой системы; инженерная задача бесконфликтной декомпозиции остаётся на вас.

Второй и третий уроки дают прямое руководство к действию. Первый задаёт ориентиры, четвёртый предупреждает о рисках.

Более широкие выводы

Команда отмечает два смежных паттерна:

• Тяжёлые и медленные модели для планов, лёгкие и быстрые для исполнения. Приводится цитата Тидо Карриеро (вице-президент по инжинирингу в Cursor): большая модель предлагает конкретный план, человек его редактирует, модель поменьше выполняет. То же самое разделение, которое отстаивает ai-assisted-workflow, только сформулированное через то, куда тратятся токены.
• Агенты как новый класс акторов. Последствия для контроля доступа, аудита и доверия - то же проблемное поле, что и в agent-principal-agent-problem, но со стороны управления доступом, а не со стороны код-ревью.

Связь с остальной вики

Материал служит противовесом крайностям с обеих сторон. Против тезиса "агенты заменят инженеров": прирост всего 20-30% на сложных задачах, а главную ценность дают созданные агентами инструменты, а не написанный ими код. Против agentic-coding-is-a-trap и agentic-coding-fatigue: здесь дан конкретный рецепт, где агенты действительно окупаются, с реальными примерами вместо игрушечных. Паттерн согласуется с no-silver-bullet-llms - агенты не упрощают сущностную сложность (последовательности, схемы, владение данными), они берут на себя только привнесённую сложность (механическую переписку 3000 мест вызова).

Паттерн с детерминированными инструментами также перекликается с clean-code-coding-agents (агенты впустую жгут токены, ориентируясь в запутанном коде) и context-engineering (соберите правильное исходное состояние перед вызовом модели).

Смежные страницы: average-is-all-you-need про пошаговый разбор под управлением агентов, building-syntaqlite-ai про личный опыт той же эволюции (вайб-кодинг проваливается, дисциплинированная работа от спецификаций даёт результат).