Короче, это история про то, как восемь AI-экспертов в один голос предлагали мне переписать кусок архитектуры в проекте JustStep, а маленький eval-прогон взял и отменил всю затею, так что фича уехала в бэклог, ещё не родившись, и это оказалось лучшим решением за неделю. Если совсем коротко на ваш возможный вопрос «как принимать решения о фичах по данным, а не по мнению» — вот так: берёте вкусовой спор «надо или не надо», превращаете его в проверяемую гипотезу с цифрами, а потом смотрите на эти цифры, даже если они вам не нравятся. У меня случаи, где фича реально нужна, вышли на уровень 0-3%, и на этом разговор закончился.
С чего всё началось — а началось с одной жалобы
Был у меня бот в онбординге, который предлагает человеку один следующий шаг. И прилетела жалоба, что хочется не один шаг, а несколько направлений на выбор, три-пять штук, чтобы человек сам ткнул куда ему. Идея на поверхности красивая, я её даже оформил как отдельную спеку (внутри проекта она проходит под номером 08, branching). И вот тут самое интересное: жалоба была одна. Ровно одна, n=1, как это называется. Я это сам себе сразу отметил, что для решения переписать архитектуру одной жалобы как-то маловато, ведь одна жалоба может быть просто одним человеком со своим вкусом, а может быть и реальной болью половины юзеров, и пока ты не посчитал, ты не знаешь что из этого правда.
Раньше я бы в такой ситуации просто пошёл и закодил. То есть не я, конечно, код у меня пишет нейросеть под моим управлением, я оркеструю агентов, а не стучу по клавишам сам, я этого никогда и не умел. Но суть та же: дал бы команду Claude Code, тот за вечер набросал бы ветвление, я бы порадовался что фича есть, и только потом бы выяснилось что она никому толком не была нужна, а сложности в боте прибавилось. И вот чтобы не наступать на эти грабли, я в этот раз решил не кодить сразу, а сначала прогнать всё через процесс.
Консилиум из восьми: четыре Claude и четыре GPT
У меня под такие неоднозначные решения есть своя штука, которую я называю SCD, это когда перед тем как что-то строить, я гоняю спеку через консилиум, стресс-тест и дебаты. И вот сижу я, думаю вслух: «Готов готов. Консилиум по спеке будем делать? наверно надо бы. 8 экспертов». Восемь, потому что четыре эксперта это Claude через Agent SDK, и ещё четыре это GPT через Codex CLI, и они идут параллельно, каждый со своей ролью, архитектор, прагматик, скептик и так далее. Смысл в том чтобы получить не одно мнение, а целый веер мнений с разных сторон, причём от двух разных семейств моделей, чтобы они друг друга не повторяли как эхо (как спорили Claude и GPT про архитектуру моей UGC-игры).
И знаете, что выдали эти восемь умных голов? Почти все сказали примерно одно: да, ветвление штука полезная, давай делать, вот тебе варианты как лучше реализовать. То есть консилиум, если грубо, проголосовал за то чтобы тратить время на новую архитектуру. И вот тут была развилка, на которой раньше я бы и попался, раз эксперты сказали делать, значит делаем, кто я такой чтобы спорить с восемью AI сразу. Был у меня уже похожий случай, когда я собрал консилиум и сам же забыл, что в этом совете не хватает самого главного участника, живого пользователя, об этом я как-то писал отдельно (вот тут про забытого пользователя). Так что я уже учёный и знаю, что AI-эксперты тоже могут дружно ошибаться, если им скормить неполную картину.
После консилиума пошёл двойной стресс-тест, это когда скептик специально атакует все предложенные варианты и ищет в них дыры, причём отдельно атакует Claude и отдельно GPT. И вот в процессе всей этой движухи я сам себе пишу: «давай попробуем. А потом дебаты реально сделаем если что Крутая идея. Что бы мы делали без консилиума вообще». И это не сарказм, мне реально нравится сам процесс, потому что он заставляет думать, а не просто соглашаться с первой красивой идеей.
Главный вопрос: а кому вообще нужно это ветвление?
И вот на стресс-тесте всплыл правильный вопрос, который надо было задать с самого начала. Не «как лучше сделать ветвление», а «в скольки процентах случаев человеку вообще нужно несколько направлений вместо одного». Потому что если таких случаев один на сотню, то городить под них целую новую архитектуру это как покупать грузовик, чтобы раз в год отвезти один мешок картошки.
И тут я сделал то, что считаю главным выводом всей этой истории, вместо немедленного кодинга выбрал pre-merge gate. По-человечески это значит примерно два часа экспериментов с промптами плюс eval-сет, то есть набор реальных кейсов, которые прогоняешь через систему и смотришь что получается. У меня это вылилось в прогон порядка 160 вызовов на живых данных, где я смотрел, вот в этом конкретном онбординге человеку реально нужна была развилка или ему хватило одного шага. И самый строгий судья тут был не Claude, а Codex, который оценивал максимально придирчиво.
Цифры, которые отменили фичу
Результат: случаев, где ветвление действительно нужно, набралось 0-3%. Даже по самой строгой оценке Codex три процента потолок, а реально болтается около нуля. И всё, разговор закончен, потому что три процента это не та цифра, ради которой переписывают архитектуру. Это та цифра, ради которой фича едет в бэклог и ждёт своего часа.
Так я и сделал: спека 08 ушла в DEFERRED, то есть отложена, но не выброшена в мусор. И что мне тут особенно нравится, я не просто отложил её на «когда-нибудь», а прописал чёткие триггеры, при которых я к ней вернусь. Логика простая: пересматриваем не на n=1, а на n больше или равно десяти живых онбордингов. И конкретно: если будет хотя бы три жалобы, или хотя бы тридцать процентов людей жмут кнопку «Не совсем» после предложенного шага, или хотя бы три кейса с несколькими направлениями за неделю, вот тогда достаю спеку из ящика и довожу до ума. А пока данных нет, лежит и не мешает. Я даже зафиксировал это себе дословно в логе: «Спека 08 откладывается до n≥10 живых жалоб, не n=1».
А исходная-то боль куда делась?
И вот тут важный момент, чтобы не выглядело будто я просто отмахнулся от человека с его жалобой. Боль-то была реальная, просто я неправильно понял её причину. Человеку казалось что проблема в количестве вариантов, а на деле проблема была в качестве самого шага, бот предлагал не то, потому что хреново понимал цель. И эту настоящую боль я починил совсем другим и куда более дешёвым способом: просто сменил модель, ушёл с Haiku на GPT-5-mini да подкрутил классификацию целей. Всё. Никакой новой архитектуры, никакого ветвления, никаких недель работы, поменял исполнителя задачи на более умного и точного, и исходная жалоба закрылась.
Получается забавная картина: восемь AI-экспертов предлагали решать проблему сложным способом через новую фичу, а правильным ответом оказался простой свап модели за пару движений. И понял бы я это, если бы просто закодил ветвление по первому же предложению консилиума? Нет конечно. Я бы построил дорогую штуку, которая решает не ту проблему, и ещё бы радовался какой я молодец.
Что я из этого вынес
Метод, который тут сработал, я для себя формулирую так: превратить вкусовой спор в проверяемую гипотезу. Пока ты споришь «надо ветвление или не надо», ты споришь о вкусах, и тут кто громче, тот и прав, или кого больше, а у меня было восемь голосов «за». Но как только ты переводишь спор в плоскость «давай посчитаем в скольки процентах случаев это реально нужно», вкусовщина исчезает, и решение принимают данные, а не мнения. Даже если эти мнения исходят от очень умных AI-агентов, которых ты сам собрал в консилиум.
И ещё одно. Консилиум и стресс-тест это не машина, которая выдаёт вам готовое решение, чтобы вы его слепо исполнили. Это машина, которая помогает задать правильный вопрос. Восемь экспертов не сказали мне «не делай», наоборот, почти все были за. Но сам процесс вывел меня на тот единственный вопрос, сколько процентов, ответ на который и решил всё. А ответ дал уже не консилиум, а двухчасовой eval на реальных данных. Так что если вы строите что-то с AI-агентами и ловите себя на том, что собираетесь пилить фичу по одной жалобе и общему ощущению что «вроде надо», остановитесь на два часа и посчитайте. Два часа eval против недели зря написанного кода, по-моему, выбор очевиден. Вот и делайте выводы.