Claude Code والوكلاء الفرعيون اختصروا إعادة كتابة مشروع موروث من ثلاثة أشهر إلى أسبوع واحد

Разница между тремя месяцами и одной неделей в этой истории объясняется не тем, что модели вдруг начали писать идеальный код, а тем, что автор перестал использовать ИИ как умный автодополнитель и превратил его в полноценный инженерный конвейер. На примере двух Go-проектов одинакового масштаба он показывает: когда legacy разбирают вручную и по наитию, скорость упирается в хаос; когда у модели есть роли, процедуры, ревью и тестовый контур, переписывание монолита ускоряется кратно. Год назад отправной точкой был знакомый многим технический долг после MVP.

В проекте существовал один main.go примерно на две тысячи строк, где в одном месте были свалены бизнес-логика, конфигурация, HTTP-хэндлеры, работа с базой и прочая служебная обвязка. Такая структура может пережить ранний запуск продукта, но плохо выдерживает рост: любое изменение тянет за собой побочные эффекты, код сложно делить на зоны ответственности, а тесты становятся не опорой, а дополнительной болью.

Автор вспоминает, что тогда вытягивал систему в нормальную архитектуру по кусочкам, с самодельными тестами и постоянной ручной перепроверкой. Первый рефакторинг он делал в Cursor и потратил на него около трёх месяцев. Это был осторожный, почти хирургический процесс: вынести один блок, проверить, не сломалось ли поведение, затем перейти к следующему.

Недавний проект такого же масштаба дал совсем другой результат. Автор взял Claude Code, модель Opus, подключил трёх субагентов-ревьюверов и собрал вокруг них примерно тридцать скилов — повторяемых сценариев для типовых операций. В итоге переписывание заняло неделю, причём заметная часть этого времени ушла не на сам перенос кода, а на BDD-слой поверх реализации.

По его оценке, без сценариев на godog задача могла уложиться примерно в три дня. Суть статьи не в том, что один конкретный инструмент оказался сильнее другого, а в том, что автор сменил способ работы. Он противопоставляет свою практику популярным советам из серии дайте нейросети хороший промпт и ждите результата.

В реальном legacy этого недостаточно: модели нужен не только контекст, но и управляемая среда. Субагенты дают параллельный взгляд на изменения и ловят ошибки раньше, чем они добираются до основной ветки. Скилы снимают рутину, стандартизируют шаги и уменьшают число решений, которые приходится принимать заново.

BDD добавляет внешний контракт поведения, чтобы переписывание не превращалось в тихую подмену бизнес-логики красивой новой структурой. Именно поэтому автор называет важнейшим результатом не просто ускорение, а появление рабочего тулчейна level85. По сути это набор договорённостей между человеком, моделью и вспомогательными агентами: как декомпозировать задачу, как проверять промежуточные результаты, как ограничивать свободу генерации и где подключать тесты.

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

Главный вывод здесь практический: ускорение в AI-assisted development рождается не из одной модели, а из операционной системы вокруг неё. Если команда продолжает работать с ИИ как с чат-окном для разовых подсказок, монолитный код всё равно будет переписываться медленно и нервно. Но если превратить модель в часть процесса — с ролями, ревью, сценариями и фиксированными приёмами, — даже тяжёлый legacy можно разбирать в разы быстрее без полного отказа от инженерной дисциплины.

И это, пожалуй, главный урок статьи.