Не нужно сначала проектировать идеального универсального агента. Нужно сделать существующие процессы видимыми, а затем улучшать их на данных.
Reviewer.Agent получает diff, требования и соглашения, но не имеет прав на запись или production. Он создаёт структурированный артефакт: регрессии, архитектурные риски, что проверить QA и что уточнить человеку. Команда сразу может измерять, что агент нашёл, что пропустил и какие замечания создают шум.
Sergey.Agent, Dima.Agent и другие текущие конфигурации harness не унифицируются насильно. Они просто перестают жить только на ноутбуках: становятся видимыми, запускаемыми и сравнимыми объектами команды.
Если задача не one-shot’нулась и разработчик меняет навык, создаётся отдельная задача на изменение harness. Появляются история, проверка на регрессии, откат, владелец и командный пайплайн развития агентского стека — вместо устных советов «попробуй вот так».
Команда сравнивает близкие задачи, попытки, вмешательства человека и метрики. Более сильные профили получают коллективное развитие, слабые отмирают. Вероятно, одного агента на всё не будет, но число профилей сократится и закрепится за классами задач.
Например, easy bugs можно направлять в Fast Fixer, сложные задачи — сначала в Planner.Agent, а затем в Deep Coder, редкие задачи с высокой ценой ошибки — в Ultra Think. Reviewer.Agent может проверять код до человеческой приёмки, а QA.Agent — скриншоты, сценарии и риски регрессий. Все эти названия — примеры, а не предписанный каталог ролей.
Это не директива «все работают одинаково». Сначала команда наблюдает реально работающие стеки, подключает удачные навыки и проверяет конфигурации на задачах. Только затем договаривается, какой профиль лучше для какого класса работы.
По мере зрелости конкретная Jira‑задача всё чаще становится лишь тестом производственной системы. Основная инженерная работа смещается к развитию harness: сделать так, чтобы следующий экземпляр класса задач решался автономнее, дешевле и надёжнее.