Я собрал консилиум из шести AI-экспертов, чтобы они спорили над моими решениями до того, как я начну что-то строить, и где-то через час работы вдруг поймал себя на мысли, что среди этих шестерых нет ни одного, кто бы спросил «а юзеру это вообще нужно?». Все шесть смотрели на задачу одинаково: как построить, как упростить, что сломается. А продукт-то делается не для архитектуры, а для человека, который им будет пользоваться. В итоге я добавил седьмого агента, User Advocate, и восьмого, его GPT-двойника, оба опциональные, включаются только когда у задачи есть конечный юзер. Дальше расскажу, как так вышло, что эту дырку проглядел не я один, а целая система ревью, которую я специально и затачивал под то, чтобы ничего не проглядеть.
Что вообще за консилиум
Если коротко, у меня есть процесс, по которому я гоняю любое более-менее серьёзное решение перед тем, как оно превратится в код. Идея простая до безобразия: вместо того чтобы спросить одну нейросеть «как лучше?» и получить один уверенный ответ, я запускаю сразу несколько AI-агентов в разных ролях, и они разносят задачу с разных сторон. Подробнее про сам метод я уже писал отдельно, если интересно, можно глянуть, как я собрал SCD из двух существующих подходов, там вся механика.
На тот момент в консилиуме было ровно шесть голов. Три на Claude, это архитектор, прагматик и скептик. И три на GPT через codex, под теми же самыми шляпами. То есть архитектор от Claude и архитектор от GPT смотрят на одну и ту же задачу и часто видят её по-разному, и вот этот зазор между ними и есть самое ценное. Зачем мне два движка под одной ролью, я разбирал, когда OpenAI выкатила плагин для Claude Code и я в тот же вечер начал использовать обоих сразу.
Архитектор думает про структуру и про то, как это будет жить через полгода. Прагматик режет лишнее и спрашивает, а можно ли проще и дешевле. Скептик ищет, где всё развалится, и атакует слабые места. Хорошая команда ревьюеров, да? Вот и я так думал. Шесть экспертов, два разных движка, спорят между собой, я читаю синтез и принимаю решение. Звучит как надёжная штука.
Где щёлкнуло
Сидел я вечером, гонял очередную задачу через этот консилиум, и в какой-то момент поймал себя на странном ощущении. Все шесть ответов были про одно и то же. Не дословно, конечно, но по сути все про то, КАК это сделать. Как разложить на компоненты, как не переусложнить, где узкое место, что сломается под нагрузкой. И ни один, вообще ни один из шести, не задал вопрос про того, кто этим будет пользоваться: он этого хочет? он будет этим пользоваться так, как ты задумал, или вообще по-другому?
И тут до меня дошло. Я построил систему оценки идей, в самой сути которой лежит идея смотреть на задачу с разных углов, и при этом забил в неё шесть технических линз и ноль продуктовых. Все мои эксперты инженеры. Очень разные инженеры, спорящие друг с другом, но всё равно инженеры. А продукт существует не ради красивой архитектуры и не ради того, чтобы скептик не нашёл к чему придраться. Он существует ради человека, который откроет приложение и либо скажет «о, кайф», либо закроет и больше не вернётся. И вот этого человека в моём консилиуме не было.
Это, если честно, классический слепой пятак. Ты так увлекаешься тем, как ты круто всё устроил, что перестаёшь видеть очевидное. Причём заметьте, я ведь специально строил систему, которая должна ловить слепые зоны, для того она и нужна. А она сама оказалась со слепой зоной размером с пользователя. Смешно и грустно одновременно.
Не «нужно ли», а «что он хочет»
Я кинул эту мысль Claude Code, с которым работал: а что будет, если в консилиум добавить ещё одного агента, который представляет юзера. Мне разложили три варианта, как это можно сделать. Первый, сделать его обязательным, чтобы он всегда был в обойме. Второй, вынести в отдельный скилл, отдельную команду. Третий, сделать его опциональным агентом, который подключается по ситуации.
Я выбрал третий. Логика тут такая: не у каждой задачи есть конечный юзер. Если я решаю чисто внутреннюю инженерную штуку, какую-нибудь схему данных или способ деплоя, то User Advocate там нафиг не нужен, он будет просто шумом. А вот когда задача про продукт, про то, что увидит и потрогает живой человек, тогда его голос критичен. Опциональность тут не лень, а точность: эксперт включается там, где от него есть толк, и молчит там, где его мнение не к месту.
И вот тут был момент, который я хочу отдельно подчеркнуть, потому что без него этот агент превратился бы в бесполезную галочку. Я переформулировал его роль. Не «нужно ли это юзеру», на такой вопрос любой ответит «ну наверное да», и толку ноль. А «что юзер хочет видеть, как бы он хотел этим пользоваться, что бы ему понравилось». Чувствуете разницу? Первая формулировка это сухая проверка целесообразности, она почти ничего не даёт. Вторая это попытка влезть в шкуру человека и посмотреть его глазами. User Advocate у меня получился не про UX-шлифовку, не про «давайте подвинем кнопку на три пикселя». Он про продуктовое чутьё, про то самое «а они вообще захотят такое». Это совсем другой разговор.
Как это собралось
Сама реализация заняла немного. Claude Code написал два файла агентов, обычного User Advocate на Claude и его двойника на GPT, чтобы соблюсти ту же симметрию двух движков, что и у остальных ролей. Я тут выступал в роли заказчика и архитектора решения: задал вопрос, выбрал вариант, переформулировал роль так, чтобы она била в продукт, а не в формальную проверку. Код агентов и спеки писал не я руками, я этого и не умею, я оркестрировал, задавал направление и правил формулировки, а сборку делала нейросеть под моим управлением. Это, кстати, и есть мой способ работы с любым AI-агентом: я держу смысл и решение за собой, а механику отдаю.
А вот дальше случилось второе щёлканье, поменьше первого, но показательное. Через полчаса после того, как файлы агентов уже лежали на месте, я заметил, что в спеке, которая описывает весь процесс, нет формата вызова этих новых агентов. То есть агенты есть, а как именно их дёргать нигде не прописано. А в соседней спеке, которая про дебаты, про User Advocate вообще ни слова. Классика: сделал главное, забыл про обвязку, ровно как было когда я добавлял новый домен в Cartara через агентов и консилиум. Дописали правила вызова в обе спеки, отдельно для Claude и отдельно для GPT. Без этого агент существовал бы только на бумаге, и в следующий раз, запуская консилиум, я бы про него просто не вспомнил.
Это, кстати, отдельная мысль про работу с AI-агентами вообще. Мало написать самого агента, надо ещё прописать, как и когда система должна его вызвать, иначе он мёртвый груз. Половина «магии» автоматизации через ИИ это не сами умные куски, а скучная сцепка между ними, которую все норовят пропустить, потому что она неинтересная — про это у меня есть отдельная история, как я заставил каждый новый модуль встраиваться самому через плагин-registry.
Цифры по этой истории
- Экспертов в консилиуме было 6, стало 8, добавил User Advocate на Claude и его GPT-двойника
- Обновил три файла со спеками: основную спеку консилиума, спеку дебатов и общий README процесса
- На столе лежало 3 варианта реализации, выбрал опциональный агент
- Время от вопроса «а что если добавить юзера» до полностью прописанного агента — один вечер, с парой возвратов доделать обвязку
Что я из этого вынес
Главный вывод даже не про AI и не про мой консилиум. Он простой: кто собирает ревьюеров, тот и определяет, какие вопросы вообще будут заданы. Если ты набрал в комнату одних инженеров, ты получишь идеально вылизанную инженерно вещь, которая может оказаться вообще никому не нужной. И не важно, шесть это AI-агентов или шесть живых людей на созвоне, если среди них нет голоса пользователя, его никто и не услышит, потому что некому. Состав определяет результат раньше, чем кто-либо открыл рот.
Второй вывод про то, как легко обмануться собственной системой. Я строил инструмент специально против слепых зон, и он сам имел слепую зону. Так что любой свой процесс надо иногда останавливать и спрашивать не «правильно ли я отвечаю на вопросы», а «а те ли это вообще вопросы». Потому что можно безупречно отвечать не на то.
И третий, чисто практический, для тех, кто тоже возится с AI-агентами под свои задачи. Формулировка роли агента важнее, чем сам факт его наличия. «Нужно ли это юзеру» и «что юзер хочет видеть» это два разных агента с одним именем, и второй стоит первого десять раз. Не поленитесь докрутить, что именно ваш агент должен спрашивать, иначе получите вежливого болванчика, который кивает на любое ваше решение. Вот и делайте выводы.