Два мира агентной разработки

Я использовал разные инструменты для агентной разработки (многие называют это вайб-кодингом). Каждый подход показал свои сильные и слабые стороны.

Есть подход Cursor, где всё построено вокруг IDE. Ты пишешь промпты, получаешь изменения на ревью, уточняешь — классический интерактивный режим.

А есть подход Claude Code с его чисто агентным режимом: даёшь инструкцию — агент автономно вносит изменения. Никакого постоянного диалога. Результат смотришь потом через git или другие средства.

Claude Code мне нравится своей автономностью, но там жёсткая привязка к моделям Anthropic. Cursor в этом плане гибче — выбирай любые модели. Но в нём нет той автономности, когда можешь просто поставить задачу и уйти.

Проблема масштаба

Когда проект вырастает до сотен тысяч строк кода, и Cursor, и Claude Code начинают буксовать. Они плохо понимают всю сложность архитектуры, не видят, как правильно встроить изменения в существующую структуру.
Обычно это заканчивается либо глубоким ручным рефакторингом, либо решением "всё выкинуть и начать заново".

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

Частично проблему решает режим планирования в Cursor, где он сначала составляет план, потом действует по нему.
Но всё это происходит в одном окне, в одном контексте. Контекст быстро забивается.
С одной стороны, растут расходы на входные токены (отправляется куча нерелевантной информации).
С другой — падает точность: современные модели хоть и держат миллион токенов контекста, но стабильно работают только на 100–200 тысячах.
Дальше начинаются потери важных деталей и галлюцинации.

Решение: субагенты

И вот здесь появляется изящное решение, которое придумали в Claude Code — субагенты.
Это отдельные экземпляры того же агента, но с фиксированным промптом и чёткими входными данными.

Логика простая: субагенту не нужен весь контекст проекта. Ему не важно, зачем ты это делаешь и какая глобальная постановка задачи.
Дай чёткие инструкции — "сделай А и Б" — он их выполнит и вернёт результат. Это ускоряет работу, повышает точность и экономит токены.

Прекрасно, правда? Кроме одного: в Claude Code имеем vendor lock на модели Anthropic.
Плюс доступ, например, к Opus 4.5 — только на дорогих тарифах.
В Cursor даже базовый тариф даёт доступ ко всем моделям — вот это классно!

Не так давно Cursor стал предлагать агентный режим интерфейса (слева запускаешь агентов).
Но это не совсем то: он не умеет ставить задачи субагентам, поэтому в контексте агента оказывается вся переписка, вся история — контекст забивается лишней информацией.
Приходится вручную под каждую задачу создавать отдельного агента и прописывать промпт.
Это не та автономная мультиагентность, которую хотелось бы иметь.

Хак: командная строка + оркестратор

Однако и в Cursor есть утилита командной строки cursor-agent (надо установить отдельно).
Через неё можно, как в Claude Code, передавать параметры, и агент будет решать задачу, ничего не спрашивая.

Проблема только в том, что нет встроенного механизма вызова субагентов через IDE.
Но ведь Cursor выполняет инструкции из промптов! Значит, можно попросить его самостоятельно инициировать работу субагентов.

Вот пример промпта, по которому Cursor понимает, что ему нужно запустить субагентов с определёнными ролями:

Используя подход по оркестрации мультиагентной разработки (agents/01_orchestrator.md), 
выполни доработку {ссылка на файл с постановкой задачи}.

Описание проекта {ссылка на описание проекта для агентов, если проект существующий}

Промпты агентов с указанными в 01_orchestrator.md ролями находятся в agents (02*.md..09.md).
Агентов нужно вызывать shell-командами:
cursor-agent -f --model {модель} -p {промпт}
и дожидаться от них результатов.

Промпт следующего формата:
"{содержимое файла с ролью} {входные данные согласно описанию роли}"

Модель:
аналитик, архитектор, планировщик — opus-4.5  
ревьюеры ТЗ, архитектуры, плана, кода и разработчик — composer-1

И это работает!

Достаточно описать логику мультиагентной цепочки — так называемого оркестратора, который живёт в основном окне диалога.
В зависимости от задачи он вызывает нужных субагентов: аналитика, архитектора, планировщика, разработчиков.
Даёшь ему шаблон команды для командной строки — и он запускает субагентов сам.

Контекст главного агента не забивается. Субагенты делают только свои специалированные задачи.
Процесс может работать часами, и в итоге ты получаешь результат: аналитику, архитектуру, план задач, план тестирования, доработанную функциональность, тесты и отчёты.
Дальше смотришь, что реально сделано, результаты тестов и при желании самостоятельно проверяешь изменения в коде.

Почему нужна команда агентов

Для большой доработки недостаточно просто планирования.
Нужна фактически работа команды разработки: аналитик (+ рецензент), архитектор (+ рецензент), планировщик, который декомпозирует задачи (это, кстати, одна из ключевых ролей, без которой всё развалится), разработчики и ревьюеры кода.

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

Разработчику не важен весь контекст — он работает над маленьким кусочком.
А то, что этот кусочек подходит, уже продумали аналитик, архитектор и планировщик.
И это прямо чётко работает!

Пример работающих промптов для ролей: github.com/rdudov/agents. Там же есть детальное описание всего процесса и ролей.

Если задача не реализовать что-то с нуля, а нужно доработать существующий большой проект, внедрить новую функциональность — только такой подход сработает.
Иначе агент наделает велосипедов, и через несколько итераций получим несопровождаемое решение.

От Waterfall к сходящемуся процессу

Я проверил работу своей команды агентов, отладил промпты — в целом всё работало.
Но в некоторых случаях процесс не сходился. Почему? Потому что это фактически waterfall: делаем компонент A, компонент B, компонент C, потом интегрируем — и... ничего не работает.

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

Внедрить полноценный Agile (делаем MVP, наращиваем функционал) тоже не вариант: слишком затратно.
Да, получаешь работающий результат, но фактически полностью переписываешь его на следующем цикле.
Для агентной разработки это (пока?) не вариант.

Я пошёл другим путём.
Прописал для планировщика явное требование идти "сверху вниз", от каркаса.
Сначала добавить все необходимые функции, классы, интерфейсы, чтобы сквозные тесты проходили с первой задачи и не ломали существующий функционал.
А дальше — наращивать "мясо", добивать реализацию.

В этом случае не нужно на каждом этапе переписывать всё — просто дописываешь имплементацию в существующий каркас.

Это сработало!

С каждой новой задачей процесс не расходится — он сходится к финальному работающему функционалу.
За счёт того, что на первом этапе пишутся сквозные тесты (пусть с заглушками, фейковыми ответами), видно, что всё продолжает работать.
Мы не делаем кучу кирпичиков, которые потом не стыкуются, а сразу собираем каркас, проверяем, что в таком виде это работает, и наращиваем внутреннюю имплементацию.

Если что-то не срастается — узнаём об этом гораздо раньше.
Процесс продолжает сходиться, а не разваливается в конце.

Итого

Мультиагентная разработка в Cursor с субагентами, где для разных ролей можно использовать разные модели, с подходом реализации "сверху вниз" (каркас → наполнение функциональностью), со сквозными тестами с самого начала и разделением на специализированные роли агентов — всё это позволяет решать сложные задачи для существующих систем с минимальным участием разработчика на промежуточных этапах.

Достаточно поставить задачу и дать команде агентов делать свою работу.
Когда всё будет готово, можно ознакомиться с промежуточными результатами по задачам и итоговыми отчётами по всей доработке.