# Как готовить масштабную модернизацию кода к эпохе ИИ-агентов
Канонический URL: https://zero2claude.ru/blog/ai-code-modernization-prep
Дата: 2026-09-23
Теги: claude-code, агенты, enterprise, автоматизация
Инженеры Anthropic делятся практикой: почему в эпоху агентов узкое место модернизации legacy-систем — не написание кода, а организация процесса вокруг него.
Представь банковскую систему, где любое изменение кода обязано пройти согласование, ревью и одобрение — не потому что так удобно, а потому что этого требуют регуляторы и аудиторы. Этот процесс десятилетиями строился на одном допущении: изменение написал человек, и его проверит другой человек. Когда изменения начинает писать агент, а не человек, узкое место никуда не исчезает — оно просто перемещается. Теперь тормозит не производство изменений, а организация вокруг них: согласование, проверка, доверие.
Инженеры Anthropic, работающие непосредственно с крупными клиентами (в Anthropic это называют forward deployed engineers), собрали в этой статье практику подготовки к таким проектам. Речь не про то, как заставить Claude Code переписывать код быстрее, а про то, что должно быть готово в организации ещё до старта: что считать «готово», какие доказательства должно нести каждое изменение, как сертифицированные изменения попадают в прод, и что нужно подготовить, чтобы процесс вообще смог стартовать.
## Три вида модернизации — и это первый спор, который нужно решить
Прежде чем что-то планировать, стоит определить, какого типа модернизация вообще нужна тебе. От этого зависит буквально всё дальнейшее — от объёма контекста, который нужно собрать, до состава условий в сертификате изменений.
| Тип | Что это | Когда выбирать | Цель на выходе |
|---|---|---|---|
| Uplift (обновление) | Обновление версии в рамках того же стека (например, C++11 → C++20) | Стек в порядке, но версия отстала: end-of-life runtime, непропатченные уязвимости, зависимости, которые больше нельзя обновить | Версия runtime и набор пакетов |
| Transform (перенос) | Переход между стеками с сохранением поведения (например, COBOL → Java) | Проблема именно в стеке, а поведению системы можно доверять | Всё из uplift, плюс язык, фреймворки и архитектурные конвенции новой системы |
| Reimagine (пересборка) | Greenfield-переписывание на новой архитектуре с изменением поведения | Поведение системы тоже нужно менять, а не только код | Всё из transform, плюс письменная спецификация поведения новой системы |
В командах этот вопрос почти всегда спорный. Те, кто ближе к продакшену, хотят просто заменить стек, сохранив поведение неизменным — это снижает риск. Те, кто годами живёт с этой кодовой базой, и бизнес-стейкхолдеры хотят использовать момент, чтобы закрыть техдолг или добавить новые требования. Обе позиции разумны, но если вопрос не решить заранее, он всплывёт позже как спор о том, «правильное» ли конкретное изменение. Договориться о типе модернизации в начале — это трение, но оно экономит намного больше времени дальше по проекту.
## Шаг 1. Определи цель: карта кода и спецификация поведения
Хороший первый шаг — разобраться, что старая система на самом деле делает. Составление инвентаря текущего поведения помогает понять, что менять, а что отбросить, и тем самым решить, transform это или reimagine. Часто это вскрывает бизнес-логику и крайние случаи, о которых уже никто не помнит.
Claude может взять на себя большую часть этой работы — построить карту зависимостей и задокументировать процессы, которые никто уже не помнит, что строил. Плагин для модернизации кода с командами assess, map и extract-rules вытаскивает бизнес-правила прямо из исходников, с цитатами на конкретные строки, которые ты сможешь проверить.
Но одного анализа Claude не всегда достаточно — легаси-система может вести себя так, как не отражено в самом коде. Интервью с бизнес-пользователями и разработчиками, а также внутренняя документация закрывают эти пробелы. Сбор контекста в начале занимает время, но именно качество этого контекста определяет качество всех решений дальше по проекту. Для reimagine-модернизации требуется дополнительный шаг: письменная спецификация поведения, согласованная с группами пользователей.
## Зачем вообще ввязываться в модернизацию
Параллельно с определением цели стоит честно ответить: а зачем это вообще делать? Снижение затрат на поддержку — частый аргумент, но по опыту авторов, именно экономия почти никогда не была главной причиной запуска таких проектов.
Настоящая мотивация — снижение риска. Стоит взвешивать риск того, что случится, если модернизацию не делать вообще: система с непропатченными уязвимостями может обернуться утечкой данных или отказом, который поставит под угрозу сам бизнес. Устаревший, неподдерживаемый runtime и сокращающийся пул инженеров, понимающих систему, только усугубляют этот риск. Агентные инструменты вроде Claude Code сильно сократили сроки модернизации, но бюджеты всё равно трудно оценивать заранее — и это часто порождает инерцию и откладывание проекта.
Главная сложность на старте таких проектов — не техническая, а организационная: нужно собрать внутренний консенсус команд, которые владеют системой, и команд, которые от неё зависят. Чёткая бизнес-обоснованность на уровне руководства делает это проще и потом помогает разрешать споры о допустимом уровне риска в сертификате и правилах продвижения.
## Шаг 2. Собери сертификат: доказательства, что изменение верное
Сертификат — это набор условий, которым должно соответствовать каждое изменение в рамках модернизации. Тебе нужно выбрать условия, которые в совокупности дают самое сильное доказательство корректности изменения относительно цели. Каждое условие должно проверяться без участия человека — тогда агентный workflow сможет сам дорабатывать изменение, пока оно не пройдёт сертификат, либо помечать его для ручного ревью, если не получилось.
Набор условий зависит от цели, но обычно берётся из этого списка:
- исходный набор тестов проходит без ошибок;
- тесты, написанные Claude в процессе модернизации, проходят;
- покрытие тестами достигает согласованного порога;
- показатели производительности остаются в допустимых границах;
- независимые «враждебные» ревью от Claude (каждое — в свежем контекстном окне) не находят блокирующих проблем;
- для интерфейсов — Claude, управляющий компьютером, не находит регрессий;
- текущая и целевая версии дают одинаковый результат на одинаковом входе (живом, записанном или сгенерированном Claude);
- сохранённые состояния и форматы обмена данными корректно конвертируются между версиями;
- изменения работают в staging согласованный период без роста ошибок, задержек или алертов;
- статический анализ и security-сканирование не находят новых проблем;
- для компилируемых систем — сборка чистая, типы проходят проверку.
Сертификат нужно писать вместе с людьми, которые будут проверять и продвигать изменения в прод — разработчиками, группами пользователей и бизнес-лидами, зависящими от системы. Их вовлечение на этом этапе формирует то, что именно измеряет сертификат, и именно это раннее участие обеспечивает их доверие, когда изменения дойдут до ревью. Хороший тест готового сертификата: были бы они готовы принять изменение только на основании этих доказательств? Если да — правила продвижения из следующего шага можно сделать легче.
То, против чего сверяется сертификат, различается по типу модернизации: для uplift паритет проверяется против исходной кодовой базы и исходный набор тестов может стать ядром сертификата. Для transform паритет тоже против исходной системы, но исходные тесты редко запускаются на новом стеке — основную работу делают replay продовского трафика, дифференциальное тестирование и параллельный прод-деплой. Для reimagine сертификат опирается на спецификацию поведения — это самый сложный случай, потому что спецификация субъективнее готовой системы, а значит, больше решений остаётся на суждение модели.
## Шаг 3. Правило продвижения в прод: кто проверяет руками и что именно
Агенты производят изменения быстрее, чем любая команда людей способна вычитывать их diff за diff. Правило продвижения — это заранее согласованный многоуровневый путь ревью, который задаёт глубину человеческой проверки для каждого изменения, чтобы модернизация уложилась в приемлемые сроки.
Как и с сертификатом, этот шаг нужно проходить вместе с ревьюерами и вписывать в уже существующий в организации процесс change-management. Детали различаются по компаниям, но несколько правил универсальны:
- **Ранжируй изменения по «радиусу поражения» и уверенности агента.** Используй уже существующую в компании классификацию рисков, если она есть. Оставь полное человеческое ревью для критических участков кода.
- **Устраняй повторяющиеся флаги в источнике.** Группируй и анализируй помеченные изменения во времени — если один тип флага повторяется, исправь причину в самом workflow или в сертификате, а не проверяй каждый случай отдельно.
- **Проектируй формат вывода вместе с ревьюерами.** Договорись, какая информация и в каком виде делает проверку максимально быстрой, и какие сигналы дают больше уверенности, чем другие.
- **Расходуй время экспертов эффективно.** Эксперт предметной области (SME) не будет читать каждый финальный diff, но его суждение — самый дефицитный ресурс. Дай ему возможность идти прямо к изменениям с наивысшим риском и к помеченным решениям агента внутри них, без необходимости продираться через огромные diff'ы.
Многие из этих правил заранее «загружают» экспертов работой, вовлекая их в проект как можно раньше. Их обратная связь настраивает сертификат и агентный workflow ещё до старта полной модернизации, а их одобрение первых образцов изменений закладывает доверие ко всему процессу дальше.
## Шаги 4–6: инфраструктура, agentic workflow и первый прогон
После того как цель, сертификат и правило продвижения зафиксированы на бумаге, остаётся подготовить всё, что нужно для реального запуска. Это среда разработки и тестирования, CI/CD-пайплайны, достаточная пропускная способность ревьюеров и согласованные заранее процедуры одобрения — без этого даже отлично спроектированный процесс встанет на первом же изменении, ожидающем чьей-то подписи.
Дальше строится сам agentic workflow — кастомная динамическая схема работы Claude Code, которая распределяет модернизацию на множество более мелких, параллельных подпотоков работы (subagent workstreams), каждый из которых производит изменения. Этот workflow строится вокруг трёх артефактов, собранных на предыдущих шагах: цели, сертификата и правила продвижения — именно они определяют, что агент должен сделать, как проверить результат и куда его отправить дальше.
И только после этого имеет смысл запускать модернизацию целиком. Правильный подход — сначала доказать, что весь workflow работает от начала до конца на небольшой, изолированной части кодовой базы, а уже потом масштабировать его на весь проект. Такой прогон на малом участке — это финальная проверка того, что цель определена верно, сертификат достаточен, а правило продвижения реально выдерживает темп, с которым агенты производят изменения.
Прежде чем брать в работу большую модернизацию, полезно освоиться с базовыми возможностями инструмента на живых примерах — это можно сделать в бесплатном курсе zero2claude, не отходя от браузера.
## Частые вопросы
Технически агенты вроде Claude Code сильно ускоряют само написание изменений — проекты, которые раньше требовали годы, теперь можно закрыть за недели или месяцы. Но организационные процессы вокруг изменений (согласование, ревью, одобрение) остаются прежними, поэтому именно они становятся новым узким местом, и готовить их нужно заранее, а не по ходу проекта.
Это зависит от того, устарела ли только версия технологий (uplift), нужно ли сменить сам стек при сохранении поведения (transform), или требуется изменить и стек, и поведение системы (reimagine). Решить это стоит на старте и зафиксировать письменно — иначе спор о правильности изменений будет возникать снова и снова уже в процессе работы.
Сертификат — это набор проверяемых без участия человека условий (тесты, бенчмарки производительности, дифференциальное тестирование и другие), которым должно соответствовать каждое изменение кода. Он позволяет агентному workflow самостоятельно дорабатывать изменение до соответствия требованиям или помечать его для ручной проверки, если самостоятельно достичь нужного качества не получилось.
Агенты производят изменения намного быстрее, чем команда людей успевает вычитывать их diff за diff. Без многоуровневого правила продвижения (по риску и уверенности агента) ревью станет новым узким местом, которое обесценит всю выгоду от скорости агентов.
Модернизация кода с помощью ИИ-агентов — это не про то, чтобы просто «подключить Claude Code и подождать». Настоящая работа начинается раньше: договориться о цели, прописать доказуемый сертификат качества, согласовать правила продвижения в прод и подготовить инфраструктуру. Только после этого агентный workflow можно безопасно масштабировать с небольшого пилота на всю кодовую базу — и именно такая подготовка отделяет проекты, которые реально долетают до продакшена, от тех, что застревают на согласованиях.
Если хочешь попробовать всё это руками — начни с бесплатного курса [«Claude Code и терминал: с 0»](/learn/code-terminal).
По мотивам статьи Anthropic «How to prepare for AI-driven code modernization projects». Пересказали по-русски для новичков.