В шести моих репозиториях до сих пор лежит одинаковый каталог из восьми файлов: архитектор, бэкенд-разработчик, ревьюер, девопс, документация, оркестратор, планировщик задач, тестировщик. Три тысячи восемьсот четырнадцать строк, побайтово совпадающих между проектами.
Я их не удаляю, потому что это хороший экспонат. На них видно ошибку, которую делают почти все, включая меня этой весной: набор агентов собран по штатному расписанию отдела разработки.
Что было внутри
Файл архитектора — семьсот пятьдесят одна строка. Начинается так:
# Architect Agent
## Роль
Технический архитектор, отвечающий за проектирование системы,
принятие архитектурных решений и обеспечение масштабируемости.
## Принципы архитектуры
### 1. SOLID Principles
- Single Responsibility
- Open/Closed
- Liskov Substitution
- Interface Segregation
- Dependency InversionДальше чистая архитектура, разделение ответственности, независимость от фреймворка, тестируемость. Ещё семьсот строк в том же духе.
Файл документации — девятьсот тридцать шесть строк. Тестировщика — семьсот сорок девять. Девопса — пятьсот шестнадцать. Ревьюера — триста двадцать два, из них половина чеклист «проверь типы, проверь права, проверь запросы, проверь кэш».
Всё это написано аккуратно и почти всё — правда. Проблема в том, что это правда про любой проект на Symfony, а не про мой.
Ни одной команды проекта
Я посчитал упоминания докера по файлам: в шести из восьми — ноль. Ни имени контейнера, ни формы вызова консоли, ни пути к файлу композиции.
Оркестратор объявляет «базовый стек Symfony-проектов»:
- Backend: Symfony 8 + PostgreSQL/MySQL + Doctrine ORM
- Frontend: Twig + CSS Framework (TailwindCSS/Bootstrap)
- Async: Symfony Messenger + Redis/RabbitMQ
- Caching: Redis/MemcachedСлэши здесь — вся суть. Это описание не проекта, а класса проектов. В моём стоит PostgreSQL, Tailwind и Redis, и ни один агент об этом не знает: они знают, что бывает или то, или другое.
Дальше «стандартные компоненты проекта»: слой сущностей, слой сервисов, слой контроллеров, слой репозиториев, обработчики сообщений. В том проекте, где это лежит, слои называются иначе, а между ними стоят границы модулей, которых в списке нет вообще.
Результат предсказуемый: агент, начинающий работу, знает про типичный проект больше, чем про этот. И достраивает недостающее из типичного — ровно тот механизм, который я разбирал в статьях про промпты, только зафиксированный письменно.
Задача подходит троим
Вторая беда — маршрутизация. Восемь ролей из штатного расписания пересекаются так же, как пересекаются живые люди в команде.
Задача «добавить фильтр по метке в список задач» подходит бэкенд-разработчику. И архитектору, потому что появляется связь многие-ко-многим. И тестировщику, потому что нужны тесты. Кому её отдавать?
В теории на это есть оркестратор. Его файл содержит схемы вида:
Orchestrator → Task Planner → Architect
↓
Backend Developer (Entity, Repository, Service)
↓
Backend Developer (Controller, Forms/Validation)
↓
Code Reviewer → Tester
↓
DevOps (Migration, deployment)
↓
DocumentationКрасивая схема. На задаче в тридцать строк она означает шесть передач, из которых пять — пересказ уже сделанного следующему исполнителю. Каждая передача теряет контекст и добавляет своё.
Я честно прогнал по этой схеме несколько задач. Быстрее всего было отменить схему и сделать самому.
У ревьюера были права на правку
Третья проблема техническая, и она чинится проще всего.
В файлах первого поколения нет фронтматтера. Нет ни имени, ни описания-условия, ни списка инструментов. Это просто markdown, который подставляется целиком.
Следствие: ревьюер может править код. И правит. Просят проверить дифф — по дороге исправляет найденное, потому что это выглядит полезным. На выходе я получаю не список замечаний, а новый дифф, который надо ревьюить заново, теперь уже без ревьюера.
То же с тестировщиком: попросили прогнать тесты, он поправил красный тест. Формально помог. Фактически стёр информацию, ради которой я и запускал прогон.
Одинаковые файлы в шести проектах
Отдельный симптом, который я тогда считал достижением: восемь файлов побайтово одинаковы во всех шести репозиториях.
Проверяется одной командой:
diff -q task/.claude/agents/architect.md lms/.claude/agents/architect.md
# тишина — файлы идентичныТишина означает, что за всё время существования ни один агент не узнал ничего про проект, в котором живёт. Набор, полностью независимый от кодовой базы, — это не переносимость, это отсутствие содержания.
Сравните с тем, что я пишу сейчас: агент бэкенда в блоге начинается с формы вызова консоли внутри контейнера и заканчивается указанием, кому делегировать прогон тестов. Скопировать его в другой проект нельзя без правки половины строк. Это и есть признак, что в нём что-то есть.
Чем набор всё-таки помог
Ругать легко, поэтому честная часть.
Первое: он задал словарь. «Позови ревьюера», «отдай тестировщику» — эти формулировки прижились и работают до сих пор, хотя за ними теперь стоят совсем другие файлы.
Второе: чеклист ревьюера был неплох. Проверка типов, прав, тяжёлых запросов, кэша, асинхронной обработки — этот список пережил переезд и стал скиллом code-review. То есть содержимое оказалось полезным, ошибочной была форма: это чеклист, а не роль.
Третье, неожиданное: файл документации на девятьсот тридцать шесть строк оказался хорошим шаблоном для человеческой документации. Как агент он не работал никогда, а как справочник по разделам — пригодился.
Общий вывод из первого поколения: полезное в нём было процедурами, а не исполнителями. Всё, что выжило, выжило в виде скиллов.
Что осталось
Шесть репозиториев с восемью файлами лежат нетронутыми. Удалить их — минутное дело, но эти проекты сейчас в спячке, и когда я к ним вернусь, набор придётся не чистить, а заменять целиком.
Вторая причина не трогать — мне нравится смотреть на эти файлы, когда хочется написать нового агента «на всякий случай». Семьсот пятьдесят одна строка про SOLID, ноль строк про проект — хорошее напоминание, во что превращается агент, у которого нет границы по коду.
Про то, что пришло на смену, — в следующей статье цикла. Коротко: границы перестали быть профессиями и стали каталогами.
