Агенты и роли: почему движок использует команду специалистов

Коротко

Можно попросить одного универсального агента «сделай фичу и проверь её». Проблема в том, что он проверяет сам себя — и почти всегда одобряет собственную работу. Это как автор, который сам себе редактор: очевидные ошибки он не видит, потому что писал их с уверенностью.

Quest — движок вайб-кодинга — идёт другим путём: он разбивает работу на роли-специалисты, у каждой — свой характер, своя зона ответственности и свой системный промпт. Ключевой принцип: один делает — ДРУГОЙ проверяет.

Кто в команде базового движка (Quest)

Базовый движок собирает команду из 8 ролей (все едут в каждый пакет; какие «включатся» под конкретную задачу — решает целевая модель, читая маршрутизирующий текст; отдельного runtime-роутера пока нет — это roadmap):

• Владелец продукта — достаёт настоящее намерение и ценность, жёстко держит scope (лишнее → backlog).
• Аналитик — пишет требования в форме EARS, закрывает happy path, краевые случаи и ошибки.
• Архитектор — читает существующий код и карту зависимостей ДО правок, следует reuse-first, держит инварианты.
• Дизайнер — концепция и все состояния UI, доступность, характерная типографика (не шаблонный «фиолетовый градиент»).
• Инженер — доводит шаг до зелёного, не ломая соседнее; TDD; verify после каждого шага.
• Старший ревьюер — конкретная обратная связь file:line — что не так — как исправить.
• Аудитор безопасности — ищет, как это сломать: инъекции, утечки секретов, пробои изоляции данных.
• Верификатор-скептик — приходит ПОСЛЕ шага с единственной задачей: доказать, что шаг что-то сломал или недоделан.

(Специализированные роли для видео, презентаций, данных живут в тематических шаблонах и модулях, которые расширяют движок, — не в базовом Quest. Задачи отладки, рефакторинга и релиза базовый движок распределяет по этим восьми ролям — инженер чинит и рефакторит, ревьюер и верификатор проверяют, — а не заводит отдельных дебаггера/DevOps.)

Почему именно команда, а не один агент

Три причины, и все про надёжность:

1. Разделение труда против самообмана. Скептик-верификатор по умолчанию относится к работе инженера с подозрением и прогоняет проверку сам — он не заинтересован «понравиться».
2. Разные углы зрения. Безопасник смотрит «как сломать», дизайнер — «как человеку», архитектор — «что развалится при масштабе». Один агент физически не держит все эти линзы одновременно с одинаковой силой.
3. Право вето у критичных углов. Пять углов-инвариантов (безопасность, изоляция арендаторов, платный гейт, регрессии, целостность данных) несут вето: их critical-находка = BLOCK, даже если все остальные голоса «за».

Как это работает вживую: вход → что делает движок → результат

Вход:

«Добавь экспорт списка клиентов в CSV, кнопкой в кабинете.»

Что делает команда:

1. Владелец продукта уточняет scope: только видимые клиенты или все? С учётом фильтров? (рекомендует — с текущими фильтрами). Лишнее («ещё и в Excel, и по расписанию») → backlog.
2. Аналитик пишет EARS: КОГДА пользователь нажал «Экспорт», СИСТЕМА ДОЛЖНА отдать CSV только тех клиентов, что принадлежат его организации + краевые: пустой список, тысячи строк, спецсимволы в имени.
3. Архитектор проверяет: нет ли уже сервиса экспорта, чтобы переиспользовать, а не писать заново (reuse-first).
4. Инженер реализует, добавляя фильтр по организации в запрос — иначе выгрузятся чужие клиенты.
5. Безопасник ловит именно этот класс: «а запрос точно фильтрует по organization_id? а сортировка из пользовательского ввода не открывает SQL-инъекцию?»
6. Скептик-верификатор прогоняет два независимых «готово»-голоса и сам запускает проверку.

Результат:

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

Честно

• Все 8 ролей едут в каждый пакет. «Умная маршрутизация — включаем только нужных» сегодня делает целевая модель, читая текст, а не отдельный движок-роутер. Настоящий роутер — roadmap.
• Полные системные тексты ролей открываются после покупки. До оплаты видны обобщённые ярлыки («архитектор», «безопасность») и состав команды, но не полный промпт роли (у агентов systemPrompt вырезается из витрины).
• Роли — это дисциплина в тексте, а не магия. Ценность в том, что команда уже собрана, отлажена и настроена на модель Opus-класса для задач с суждением — это недели работы, свёрнутые в одну установку.