К задаче «добавить фильтр статей по рубрике» легко назначить архитектора, разработчика, тестировщика и ревьюера. Названия звучат убедительно, но ещё не объясняют, зачем нужны четыре отдельных исполнителя. Если каждый сначала заново читает один контроллер, а затем передаёт соседу пересказ, разделение увеличивает работу.
Я бы начинал с другого вопроса: какую часть результата можно получить отдельно и проверить, не дожидаясь остальных? Ниже — условная задача для технического блога. Это способ спроектировать делегирование, а не отчёт об измеренной экономии времени.
Сначала назовите результаты
Пусть нужно скрыть архивные статьи из блока свежих публикаций, сохранив их в поиске. Здесь есть три разных результата: карта потребителей общей выборки, изменение нужного запроса и независимая проверка, что поиск не потерял архив. Они связаны, но не совпадают.
Исследование должно закончиться списком мест, где используется выборка, со ссылками на код. Реализация — ограниченным изменением и проверками. Ревью — конкретными замечаниями к получившемуся поведению. Слова «архитектура», «бэкенд» и «качество» для этих границ слишком широки: под каждое подходит вся задача.
Запишите для каждого предполагаемого помощника вход и выход. Если выход одного описывается как «продолжить думать об этом же», самостоятельного поручения пока нет. Объедините работу или уточните вопрос. Отдельное окно контекста оправдано результатом, который полезно вернуть в основную задачу.
Найдите настоящую независимость
Исследовать поиск и изучать ленту публикаций можно параллельно, если оба помощника только читают свои цепочки. Им не нужно согласовывать правки. Но менять модель публикации и писать тест под ещё неизвестный интерфейс одновременно сложнее: тестировщик будет угадывать решение, которое другой исполнитель ещё не принял.
Для нашего примера я бы сначала поручил одному помощнику проверить, используется ли общий scope в поиске, RSS и главной. Основной исполнитель в это время может уточнять ожидаемое поведение страницы. После карты он меняет нужный запрос. Проверяющий получает уже конкретный diff и условия задачи.
Такое разделение не обещает ускорить любой этап. Независимый просмотр ценен ещё и тем, что его автор не защищает только что написанное им решение. Но одинаковая модель и одинаковые инструкции не гарантируют независимость выводов. Ревьюер должен смотреть на требования и фактические изменения, а не подтверждать резюме автора.
Посчитайте цену передачи
Передача включает подготовку контекста, ожидание ответа, чтение доказательств и объединение результатов. Это работа человека или основного агента, и её нельзя считать бесплатной. Список из пяти помощников сам по себе ничего не говорит о сроке выполнения.
Сравните два варианта на бумаге. В первом один исполнитель читает контроллер, меняет запрос и запускает проверку. Во втором отдельный исследователь приносит карту, разработчик уточняет её, тестировщик задаёт вопрос о базе, а ревьюер ждёт окончательный diff. Если задача занимает одну небольшую функцию и хорошо понятна, первый вариант часто проще организовать.
Другой случай — исследование нескольких независимых интеграций. Основному исполнителю не обязательно хранить в разговоре полный вывод поиска по каждой из них. Здесь помощники могут вернуть короткие подтверждённые заключения. В документации Claude Code отдельный контекст субагента описан именно как одна из возможностей такого разделения. Это свойство продукта, а не доказательство, что делегирование выгодно для вашей задачи.
Соберите карточку одного поручения
Вопрос: использует ли поиск тот же фильтр публикаций, что главная?
Вход: текущая рабочая копия; маршрут поиска и модель Post.
Действия: чтение кода и поиск ссылок, без правок и запуска приложения.
Результат: цепочка вызовов, найденное общее условие, места расхождения.
Доказательства: путь и символ для каждого вывода.
Неизвестное: отдельно перечислить то, что нельзя установить по коду.
Завершение: на вопрос дан ответ; проектирование исправления не требуется.Здесь есть узкая задача и ясная точка завершения. Исследователь не получает поручение «изучить весь проект» и не должен возвращать план новой архитектуры. При этом ему разрешено сообщить, что гипотеза общего фильтра неверна: полезный результат не обязан совпасть с ожиданием заказчика.
Если для ответа понадобился доступ к рабочей базе, это новая граница. Помощник должен назвать недостающий факт и предложить безопасный способ получить его. Давать широкий доступ только ради сохранения параллельности не стоит.
Проверьте схему на небольшой задаче
Выберите изменение с понятным результатом и сравните планируемые передачи с фактическими. Отмечайте повторное чтение одних файлов, вопросы о потерянных условиях и переделки из-за несогласованных решений. Это наблюдения для вашей команды, а не универсальные нормативы скорости.
Поручение удачно выделено, если итог можно проверить независимо: указанные места существуют, вывод отвечает на исходный вопрос, ограничения соблюдены. Если основному исполнителю приходится заново проводить всё исследование, улучшайте формат доказательств или убирайте лишнюю передачу.
Человек остаётся владельцем общего решения: определяет, какие риски допустимы, сверяет конфликтующие выводы и принимает итог. Задача не становится проверенной от того, что через неё прошли несколько агентов. Следующий практический шаг — разделить владение файлами и договориться о передаваемом контракте.
