Что делегировать AI-агенту, а что нет: рамка решения

Когда разработчик впервые начинает системно работать с AI-агентом, он упирается в вопрос, который звучит просто, но требует настоящего ответа: что вообще ему давать? Можно отдавать всё подряд и получать мусор вместо результата. Можно держать агента на коротком поводке и не получать никакого выигрыша. Правильный ответ — посередине, и он строится по чёткой рамке.

В этой статье разберём два вопроса, которые определяют решение, и три корзины, по которым раскладываются практически любые задачи.

Почему вопрос вообще возникает

Если вы уже понимаете, что такое Claude Code и чем агент отличается от чата, то знаете: агент действует в вашей среде — читает файлы, запускает команды, правит код, проверяет результат в цикле. Это его сила. Но именно она делает выбор задачи важным.

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

Поэтому решение «делегировать или нет» — не про лень, а про качество работы.

Рамка: два вопроса

Перед тем как отдать задачу агенту, достаточно ответить на два вопроса:

1. Насколько чётко определён результат и критерий «готово»?

Есть ли у вас ясное представление о том, что значит «сделано»? Можно ли это проверить — тестами, запуском, конкретным diff-ом? Если вы сами не можете сформулировать критерий готовности, агент его точно не угадает.

2. Какова цена ошибки и насколько уникален ваш контекст?

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

Ответы на эти два вопроса и определяют, в какую из трёх корзин попадает задача.

Три корзины

Делегировать целиком

Сюда попадают задачи, где:

результат однозначен и проверяем,
в кодовой базе уже есть образец или конвенция,
цена ошибки низкая (легко откатить и переделать).

Примеры из реальных проектов:

«Сгенерируй CRUD-модуль для сущности MenuItem по той же структуре, что и существующий Order.»
«Напиши unit-тесты для функции calculateOrderTotal, покрой граничные случаи.»
«Отформатируй все файлы по ESLint-конфигу проекта.»
«Переименуй переменную data в orderItems во всех файлах модуля.»

В нашем учебном проекте CoffeeCRM (Next.js + NestJS + PostgreSQL) такими задачами были бы: генерация Prisma-схемы по уже описанным сущностям, написание boilerplate-контроллеров, или миграция от одного стиля импортов к другому.

Почему это работает: агент видит образец, критерий ясен («работает как существующий модуль»), есть тесты или можно запустить. Именно ради этого класса задач агент и нужен — он делает скучное быстро и аккуратно.

Делать совместно

Сюда попадают задачи, где:

нет единственно правильного ответа,
решение влияет на весь проект надолго,
нужен ваш контекст, ваш вкус или бизнес-ограничения, которые нигде не записаны.

Примеры:

Выбор между двумя ORM: Prisma или TypeORM. Агент отлично перечислит плюсы и минусы, но решение — ваше, потому что оно зависит от команды, опыта, планов на масштаб.
Разбивка монолитного сервиса на несколько. Архитектурный trade-off с долгосрочными последствиями.
«Как организовать авторизацию в этом проекте?» — тут нужно знать, что сейчас в проекте, что будет завтра, каков опыт команды.

Как работать в этом режиме: используйте агента как умного собеседника для исследования. Попросите его выписать варианты и аргументы «за/против», набросать черновик архитектуры — а потом сами решаете. Для таких задач хорошо подходит plan mode (агент описывает план, вы его правите), о котором подробнее в статье про spec-driven подход против вайб-кодинга.

Агент думает вместе с вами, но руль у вас.

Сначала прояснить самому

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

Примеры:

«Почини баг» — без воспроизведения, без описания ожидаемого поведения. Агент честно попробует что-то — и закодирует ваше непонимание. Он не знает, что именно сломано, как это должно работать, в каком окружении это проявляется.
Задачи с секретами и прод-доступами. «Настрой деплой на сервер» не означает, что нужно пустить ключи в контекст агента. Это отдельный класс — безопасность.
Любые задачи, где вы сами не можете сформулировать «что значит готово». Если ответ на первый вопрос рамки — «не знаю», делегировать нельзя.

Что делать: сначала вы сами прописываете требование, воспроизводите баг, формулируете критерий. После этого задача переходит в первую или вторую корзину.

Как это работает на практике

Возьмём три задачи одного спринта в CoffeeCRM:

Задача	Корзина	Почему
Добавить эндпоинт `GET /menu` с пагинацией	Делегировать целиком	Конвенция есть, критерий ясен, тесты напишем в задаче
Решить, хранить ли изображения в S3 или локально	Совместно	Нет правильного ответа, зависит от инфры и бюджета
«Что-то не работает в авторизации»	Сначала прояснить	Непонятно что, как, когда — сначала воспроизведение

Когда вы научитесь классифицировать задачи до того, как их отдаёте, агент становится предсказуемым инструментом, а не лотереей.

Частный случай: субагенты

Если вы уже работаете с субагентами и параллельным выполнением, рамка та же, но важен ещё один нюанс: субагентам нужно давать полностью изолированные задачи из первой корзины. Задача, которая требует согласования между агентами, — это уже вторая корзина, где координирует человек.

Вывод

Рамка решения простая: чёткость результата + цена ошибки. Три корзины — делегировать целиком, делать совместно, сначала прояснить — покрывают практически любую задачу. Потратьте 30 секунд на классификацию до начала работы, и вы сэкономите в разы больше на исправлении.

Этот навык — не теория: он разбирается на конкретных кейсах в первом модуле полного курса по Claude Code, где мы строим CoffeeCRM с нуля, делегируя осознанно, а не наугад.