ИИ ускорил генерацию гипотез, но не их проверку

Автор статьи на «Хабре» описывает практический опыт применения генеративного ИИ для проверки продуктовых гипотез до запуска. По его наблюдению, ИИ ускорил генерацию идей, но узкое место сместилось на этап верификации: проверка гипотез осталась такой же дорогой, как и в 2020 году. В итоге выигрывает тот бизнес, у которого больше гипотез доходит до реального импакта, а не тот, кто быстрее придумывает новые.

Автор приводит личный кейс: он хотел выйти на средние компании с оптовым сбытом и построил стратегию на трёх гипотезах — что клиенты ни к кому не привязаны, что их задачи никто не закрывает комплексно и что при виде готового решения они переключатся. Исследования и оценка рынка были проведены по всем правилам, но гипотезы провалились: ушли ресурсы нескольких команд, бюджет на промо и несколько месяцев работы.

После провала автор прогнал через систему тот же бриф и тот же контекст, что были до запуска. Система за шесть шагов и без затрат на трафик нашла пять логических дыр: первая гипотеза опиралась на сигнал, который одинаково объяснял и привязанность, и её отсутствие; вторая опровергала сама себя, так как у конкурентов продукты были, просто с другим UX; третья смешивала уход клиента и добавление второго сервиса; гипотезы зависели друг от друга, но проверялись как независимые; а лендинг в принципе не мог ответить на поставленный вопрос. Система предложила начать с коротких интервью.

Описанная архитектура напоминает проектную команду: диспетчер формулирует техническое задание, оркестратор после каждого шага решает, кого звать дальше, а исполнители — консультант, генератор гипотез, валидатор и планировщик проверки — работают по инструкциям в файлах SKILL.md. Каждая роль запускается отдельным агентом в своём контексте, а методология вынесена в общий справочник, поэтому правки доходят до всех сразу. Вся обвязка называется харнессом.

Ключевой элемент — согласованное ТЗ, которое сохраняется в файл 00-tz.md с пометкой «СОГЛАСОВАНО». Без этой отметки оркестратор не стартует и возвращает задачу диспетчеру. В ТЗ фиксируются допущения, список дыр (GAP), бюджет шагов (тир) и тип выхода; ошибка в ТЗ обходится дороже всего, поэтому здесь обязателен человек.

Автор подчёркивает, что результаты живых проверок возвращаются в контекст проекта, и следующая задача стартует уже с учётом полученных данных. Это позволяет отсеивать слабые идеи до запуска и доводить сильные до эксперимента за один прогон, оставляя человеку только согласование. По его мнению, именно такой подход превращает ИИ из генератора красивых, но случайных гипотез в рабочий инструмент проверки.