Набор субагентов — самая заметная часть чужих настроек и самая бесполезная для того, кто начинает. Её копируют первой и получают отрицательный эффект.
Этот шаг плейбука в основном про то, как понять, что вам пока не надо.
Порог
Ниже определённого размера один исполнитель работает лучше набора.
Мои признаки, что порог не пройден:
- задача целиком помещается в один-два каталога;
- вы сами удерживаете в голове все связи проекта;
- у вас нет двух задач подряд, где нужен разный контекст;
- вы ни разу не написали «делай только вот эту часть, остальное не трогай».Пока так — заводить агентов не нужно. Всё, что они дают, вы получаете дешевле: формулировкой задачи и файлом контекста.
Стоимость набора при этом не нулевая. Каждый агент — описание, конкурирующее за срабатывание, и передача контекста при делегировании. На маленьком проекте это чистые потери: задача уходит исполнителю, который знает о проекте меньше, чем общий контур.
Восемь ролей — типичная первая ошибка
Первый набор, который заводят почти все, включает архитектора, разработчика, тестировщика, девопса, документацию, ревьюера, планировщика и оркестратора. Я тоже с него начинал: восемь файлов, три с лишним тысячи строк, шесть проектов.
Почему он не работает.
Роли из штатного расписания не имеют границ в коде. «Бэкенд-разработчик» — не граница, потому что под него подходит почти любая задача. Задача «добавить фильтр в список» одинаково подходит троим, и выбор становится случайным.
Такой набор ничего не знает о проекте. В моих восьми файлах не было ни одной команды проекта, ни одного пути, ни одного имени сущности. Зато были принципы проектирования на семьсот строк.
И он порождает передачи. Схема «планировщик → архитектор → разработчик → ревьюер → тестировщик → документация» на задаче в тридцать строк означает пять пересказов, каждый из которых теряет детали.
Проверка, которую советую сделать до копирования чужого набора: возьмите свою вчерашнюю задачу и решите, кому из восьми вы её отдадите. Если ответ приходит не сразу — набор не ваш.
Признаки готовой зоны
Зона — это то, вокруг чего имеет смысл заводить агента. У неё три признака.
Она очерчивается каталогами. Не «бэкенд», а конкретные пути: модели и миграции, публичные шаблоны и стили, общий модуль редактора. Если вы не можете назвать каталоги — зоны нет.
У неё своя среда. Свои команды, свои конвенции, свои типовые ошибки. Публичные шаблоны требуют помнить про две темы и адаптив, модели — про миграции и сидеры. Это разный контекст, и его разделение экономит внимание.
Она повторяется. Задачи в этой зоне приходят регулярно, а не раз в квартал.
Если все три есть — агент окупится. Если два из трёх — подождите.
Что заводить первым
Когда порог пройден, начинать стоит не с пишущих агентов, а с проверяющих.
Первый — ревьюер без права записи. Он даёт то, чего вы не получаете иначе: список замечаний, а не исправленный код. Разница принципиальная: исправление без отчёта отбирает у вас знание о том, что было не так.
Второй — прогон тестов и разбор падений, тоже без права записи. Он возвращает причину, а решение о починке остаётся за вами.
Третий — разведка: карта пути от точки входа до побочных эффектов перед нетривиальной правкой.
Все трое ничего не пишут, и это не совпадение. Проверяющие окупаются быстрее пишущих, потому что общий контур и так неплохо пишет код, а вот смотреть на свою работу свежим взглядом он не умеет.
Пишущих агентов заводите последними, когда зон станет действительно несколько.
Сколько их нужно
В блоге двенадцать субагентов, и это результат полугода работы, а не стартовый набор.
Признак, что агентов слишком много: два описания, между которыми вы сами не можете выбрать за пять секунд.
Признак, что мало: вы регулярно дописываете к задаче три строки контекста, потому что исполнитель не знает специфики. Эти три строки — заготовка нового агента.
Разумный старт — три штуки, все проверяющие. Дальше по мере появления зон.
Отклонения
Монорепо. Порог проходится раньше: в монорепо зоны заданы самой структурой, и агент на пакет оправдан почти сразу. Границей делайте пакет, а не слой.
Несколько языков в одном проекте. Тот же случай: разные языки означают разные конвенции, разные команды и разные типовые ошибки. Это готовые зоны, и разделение по ним работает с первого дня.
Команда с разделением ответственности. Если в команде уже есть договорённость, кто за что отвечает, зоны часто совпадают с ней. Но описания пишите по каталогам, а не по именам людей: люди меняются, каталоги остаются.
Проект в поддержке, где задачи редкие. Заводить набор не стоит вовсе. Раз в месяц вы всё равно не вспомните, кто у вас за что отвечает, и будете читать описания. Файла контекста и двух-трёх скиллов достаточно.
