Как создавать продукты с помощью AI, а не просто генерировать код

AI сегодня умеет писать код быстрее, чем большинство людей успевает нормально сформулировать задачу.

И вот тут начинается главный развод.

Ты открываешь Codex, Cursor, Claude Code или другой агент, пишешь что-то в духе:

Сделай мне приложение, где пользователи смогут играть, платить, общаться и получать красивую статистику.

Через несколько часов у тебя действительно что-то запускается. Есть кнопки. Есть база. Иногда даже тесты зелёные. Агент бодро пишет, что всё готово.

А потом ты открываешь продукт как обычный пользователь — и понимаешь, что он сделал вообще не то.

Не потому, что AI тупой. И не потому, что «vibe coding не работает».

Проблема в том, что код — только одна часть продукта. Причём теперь далеко не самая сложная.

Настоящая работа находится раньше:

• понять, что именно ты строишь;
• найти главную пользовательскую ценность;
• исследовать рынок;
• определить границы первой версии;
• разложить продукт на системы;
• описать пользовательские сценарии;
• спроектировать состояния;
• предусмотреть ошибки;
• подготовить контекст;
• сформулировать критерии готовности;
• проверить реальное поведение;
• довести визуал, анимацию и звук до уровня, на котором продуктом приятно пользоваться.

Я особенно хорошо это прочувствовал, когда вместо очередного сайта решил делать онлайн-игру в длинные нарды.

Нарды здесь не главная тема. Это просто хороший стресс-тест для метода: правила, сервер, два игрока, синхронизация, AI-противник, десятки состояний, ассеты, анимации, звук и будущая монетизация.

На таком проекте быстро становится видно: AI может сильно ускорить исполнение, но он не заменяет продуктовое мышление.

Эта статья — не рассказ «как я сделал нарды». Это система, по которой ты можешь спланировать и начать собирать свой продукт: Telegram Mini App, SaaS, маркетплейс, игру, CRM, мобильное приложение, AI-сервис или внутренний инструмент.

TL;DR

Если совсем быстро, процесс выглядит так:

1. Не начинай с промпта. Начинай с проблемы и пользователя.
2. Изучи рынок руками, а не только по скриншотам.
3. Определи главный риск, который должен проверить MVP.
4. Разложи продукт на отдельные системы.
5. Нарисуй пользовательские потоки.
6. Спроектируй состояния, а не только экраны.
7. Выпиши edge cases до разработки.
8. Собери AI Context Pack — пакет контекста для агента.
9. Разрабатывай вертикальными срезами.
10. Ставь acceptance criteria и stop-gates.
11. Не принимай отчёт AI за доказательство.
12. Проверяй продукт как реальный пользователь.
13. Считай визуал, motion и sound частью функции.
14. Тестируй core loop до того, как строить магазин, клубы и царство небесное.

1. Почему нельзя начинать с огромного промпта

Самая распространённая ошибка сейчас выглядит так:

идея
→ огромный промпт
→ агент генерирует код
→ что-то запускается
→ автор пытается понять, что получилось

Это очень соблазнительный процесс. Кажется, что ты экономишь время и сразу «делаешь продукт».

На деле ты просто переносишь все неразрешённые вопросы в код.

Агенту всё равно придётся решить:

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

Если ты этого не определил, AI не остановится и не скажет:

Босс, здесь требуется продуктовое решение.

Чаще он придумает решение сам. Уверенно. Красиво. Иногда даже с типами TypeScript.

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

Правильный порядок другой:

проблема
→ пользователь
→ исследование
→ главный риск
→ MVP
→ системы
→ сценарии
→ состояния
→ критерии
→ AI-исполнение
→ ручная проверка

AI лучше всего работает не как магическая кнопка, а как сильный исполнитель внутри уже определённой системы.

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

Что сделать у себя

До открытия coding-агента письменно ответь на пять вопросов:

1. Для кого я строю продукт?
2. Какой результат человек хочет получить?
3. Какой один сценарий создаёт основную ценность?
4. Какой главный риск я проверяю первой версией?
5. Что я сознательно не строю сейчас?

Пока ответы мутные, большой промпт только быстрее создаст большую мутную систему.

2. Сначала определи продукт, а не набор функций

Основатель обычно начинает с функций:

• профиль;
• чат;
• AI;
• платежи;
• пуши;
• статистика;
• подписка;
• рефералка;
• админка.

Но набор функций — ещё не продукт.

Продукт начинается с изменения состояния пользователя.

Было:

Я трачу три часа вручную, не понимаю, что происходит, или вообще не могу решить задачу.

Стало:

Я быстро получаю конкретный результат понятным способом.

Для фиксации этого нужен короткий Product Brief.

Шаблон Product Brief

Рабочее название:
Пользователь:
Проблема:
Текущий способ решения:
Главный результат:
Core loop:
Почему человек вернётся:
Главный продуктовый риск:
MVP:
Не входит в MVP:
Метрика проверки:

Пример логики, а не готового ответа

В моём игровом кейсе главный риск был не в том, получится ли сделать магазин досок или красивый профиль.

Главный риск:

Можно ли сделать быстрый, понятный и приятный игровой цикл, в котором два человека видят одно состояние, ходят по правилам и не страдают от кривого управления?

Значит, первая версия должна проверять:

• запуск матча;
• бросок;
• расчёт допустимых ходов;
• перемещение;
• синхронизацию;
• завершение;
• reconnect.

А магазин, турниры, клубы и сложная экономика могут подождать.

Для другого продукта core loop будет другим.

Например, для сервиса поиска заказов:

подключить источник
→ получить релевантные заявки
→ отфильтровать
→ связаться
→ сохранить результат

Для редактора презентаций:

загрузить контент
→ получить структуру
→ отредактировать
→ экспортировать

Для CRM:

добавить лида
→ изменить статус
→ поставить задачу
→ получить напоминание

Проверка: если убрать все второстепенные функции, остаётся ли понятная ценность, ради которой человек вообще открывает продукт?

Визуал: карта продукта
Заголовок: «Не список функций, а система ценности»
Что объясняет: связь между пользователем, core loop, системами и будущими функциями.
Подпись: «Профиль, магазин и статистика не должны маскировать отсутствие рабочего главного сценария».

3. Исследуй рынок как продакт, а не как турист по Dribbble

Исследование конкурентов часто превращается в папку из 70 красивых скриншотов.

Это полезно для настроения. Но почти бесполезно для продуктового решения.

Тебе нужно смотреть не только на то, как продукт выглядит, но и на то, как он работает:

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

Таблица исследования конкурентов

В случае с приложениями для нард я смотрел:

• игровые режимы;
• запуск матча;
• навигацию;
• внешний вид доски;
• поведение фишек;
• кубики;
• подсветку доступных действий;
• онлайн;
• AI;
• рекламу;
• подписки;
• покупки;
• отзывы.

Часто встречались одни и те же проблемы:

• устаревший дизайн;
• перегруженные экраны;
• агрессивная реклама;
• ощущение мобильного казино;
• непонятный старт обычной партии;
• слабая обратная связь.

Но цель исследования была не найти одно приложение и скопировать его.

Я собирал хорошие решения по кускам:

• у одного — хороший старт матча;
• у другого — понятные legal moves;
• у третьего — нормальный replay;
• у четвёртого — удобная приватная ссылка.

Главный принцип: копируй не продукт, а доказавшие себя паттерны. Потом собирай из них собственную систему.

Практика для читателя

Исследуй минимум пять продуктов:

• два прямых конкурента;
• один продукт с похожим core loop;
• один сильный продукт из другой категории;
• один провальный или плохо оценённый продукт.

Отдельно прочитай негативные отзывы. Там часто лежит бесплатная продуктовая аналитика, за которую команды потом платят консультантам.

Визуал: таблица исследования
Заголовок: «Как сравнивать продукты без “нравится / не нравится”»
Что объясняет: исследование функций, поведения, ошибок и жалоб.
Подпись: «Хорошее исследование заканчивается решениями, а не папкой референсов».

4. Отдели MVP от фантазий основателя

Почти любой проект в голове выглядит как будущая империя.

Сначала простой бот. Потом:

• маркетплейс;
• социальная сеть;
• клубы;
• подписка;
• токены;
• мобильное приложение;
• AI-коуч;
• международная экспансия;
• небоскрёб.

Это нормально. Ненормально пытаться построить всё до проверки главного сценария.

Матрица MVP / Later / Maybe / Not now

MVP

Без этого главная ценность не работает.

Later

Полезно после проверки core loop.

Maybe

Гипотеза, у которой пока нет доказанной ценности.

Not now

Сознательно исключено, даже если когда-нибудь может понадобиться.

Шаблон

В игровом продукте:

MVP

• быстрый матч;
• приватная партия;
• AI;
• правила;
• основная доска;
• legal moves;
• reconnect;
• результат.

Later

• локальная игра на одном устройстве;
• турниры;
• коллекция досок;
• расширенная статистика.

Maybe

• клубы;
• сложный анализ;
• дополнительные игровые режимы.

Not now

• всё, что мешает проверить саму игру.

MVP — это не «три экрана вместо тридцати».

MVP — это минимальная целостная система, которая проверяет главный риск.

Если твой продукт требует авторизации, сервера, данных и ошибок, нельзя просто нарисовать happy path и назвать его MVP.

Жёсткий вопрос: если эта функция исчезнет, сможем ли мы проверить основную ценность продукта?

Если да — скорее всего, она не нужна в первой версии.

Визуал: roadmap
Заголовок: «MVP / Later / Maybe / Not now»
Что объясняет: приоритизацию функций.
Подпись: «Сначала докажи, что core loop нужен людям. Потом строй вокруг него экономику и экосистему».

5. Разложи продукт на системы

После определения MVP не надо сразу рисовать страницы.

Сначала полезно разложить продукт на самостоятельные системы.

Для большинства цифровых продуктов список будет похожим:

Пользователь и авторизация
Бизнес-логика
Данные
Основной интерфейс
Платежи
Уведомления
Интеграции
Ошибки и восстановление
Аналитика
Админка
Безопасность

В игровом кейсе появились:

• Rules Engine;
• Game State;
• Multiplayer;
• Matchmaking;
• Telegram authentication;
• AI opponent;
• GameBoard;
• Animation Controller;
• Sound System;
• Replay;
• Rating;
• Admin.

Для SaaS это могут быть:

• Workspace;
• Permissions;
• Billing;
• Documents;
• Search;
• Notifications;
• Audit Log.

Для каждой системы опиши:

Название:
Ответственность:
Входные данные:
Результат:
Зависимости:
Критические ошибки:
Что хранится:
Критерий готовности:

Почему это важно

Без системной карты coding-агент обычно начинает смешивать всё:

• правила лежат в UI-компоненте;
• сетевой код меняет локальное состояние;
• платежи напрямую обновляют баланс;
• экран сам решает, можно ли пользователю выполнить действие;
• backend повторяет логику в пяти местах.

Пока проект маленький, всё выглядит терпимо.

Потом любое изменение превращается в археологическую экспедицию.

Главный принцип: UI показывает состояние. Бизнес-логика определяет допустимое поведение. Сервер хранит авторитетную истину там, где это необходимо.

6. Проектируй пользовательские потоки

User flow — это не карта всех экранов.

Это путь пользователя к результату.

Хороший flow отвечает:

• откуда человек пришёл;
• чего он хочет;
• какие шаги проходит;
• где принимает решения;
• где может ошибиться;
• как возвращается;
• чем заканчивается сценарий.

Шаблон User Flow

Точка входа:
Намерение:
Предусловия:
Основной путь:
Развилки:
Ошибки:
Recovery:
Успешный результат:
Метрика:

Минимальный набор flow для продукта

1. Первый запуск.
2. Повторный пользователь.
3. Главный happy path.
4. Отмена.
5. Ошибка.
6. Возврат после перерыва.
7. Повторное действие.
8. Удаление или выход, если релевантно.

Пример онлайн-сценария

открыть приложение
→ выбрать режим
→ найти соперника
→ подтвердить готовность
→ начать матч
→ выполнить действие
→ получить подтверждение
→ завершить
→ открыть результат

Но хороший flow также показывает ветки:

соперник не найден
→ продолжить поиск
→ сыграть с AI
→ создать приватный вызов

интернет пропал
→ показать cached state
→ переподключиться
→ получить authoritative snapshot
→ продолжить

Визуал: user flow
Заголовок: «От точки входа до результата»
Что объясняет: основной путь и ветки восстановления.
Подпись: «Flow без ошибок — это не реальный продукт, а презентация».

7. Проектируй состояния, а не только экраны

Это, пожалуй, самый важный переход от обычного дизайна к продуктовой системе.

Экран отвечает:

Как это выглядит?

Состояние отвечает:

• что сейчас происходит;
• что видит пользователь;
• что ему доступно;
• что запрещено;
• что делает клиент;
• что делает сервер;
• что видит второй пользователь;
• какое событие переводит систему дальше;
• что происходит при ошибке.

Один и тот же экран может находиться в десятках состояний:

loading
empty
ready
selected
pending
success
error
offline
reconnecting
expired
forbidden

В моём примере одна игровая доска имела состояния:

• до броска;
• запрос броска;
• результат;
• фишка выбрана;
• drag;
• первый шаг сделан;
• ход готов;
• сервер подтверждает;
• соперник ходит;
• сеть нестабильна;
• reconnect;
• resync;
• timeout;
• результат.

Из простой идеи «покажи доску» появилось около ста состояний и сценариев по всему продукту.

Шаблон State Specification

State ID:
Название:
Входное условие:
Что видит пользователь:
Доступные действия:
Запрещённые действия:
Что делает клиент:
Что делает сервер:
Что видит другой пользователь:
Событие перехода:
Следующее состояние:
Ошибки:
Поведение при reconnect:
Acceptance criteria:

Пример универсального state

State ID: DOC-05
Название: Документ сохраняется

Вход:
Пользователь изменил контент.

UI:
Индикатор «Сохраняем…».

Доступно:
Продолжать редактирование.

Запрещено:
Повторный ручной submit.

Клиент:
Отправляет revision и idempotency key.

Сервер:
Проверяет актуальную версию и сохраняет.

Переход:
SAVE_CONFIRMED → saved
REVISION_CONFLICT → conflict

Recovery:
Показать актуальную серверную версию и предложить merge.

Такой state можно передать дизайнеру, разработчику, QA и AI-агенту. Все понимают, о чём речь.

Главный принцип: список экранов описывает интерфейс. Реестр состояний описывает продукт.

Визуал: карта состояний
Заголовок: «Один экран — десятки состояний»
Что объясняет: разницу между страницей и поведением системы.
Подпись: «Loading, selected, pending, error и reconnect — это не мелочи, а части сценария».

8. Найди edge cases до пользователей

Happy path почти всегда работает первым.

Пользователь:

• нажал правильную кнопку;
• интернет идеальный;
• данные актуальны;
• сервер отвечает;
• второй пользователь ведёт себя прилично;
• никто ничего не нажимает дважды.

В реальности всё иначе.

Категории edge cases

Пользовательский ввод

• двойной клик;
• неправильный формат;
• пустое значение;
• слишком длинное значение;
• закрытие без сохранения;
• действие не в том порядке.

Сеть

• медленный ответ;
• timeout;
• потеря соединения;
• повторный запрос;
• пришёл старый ответ;
• смена Wi‑Fi на мобильную сеть.

Авторизация

• истёкшая сессия;
• нет прав;
• ссылка принадлежит другому пользователю;
• пользователь заблокирован.

Состояние

• данные изменились на другом устройстве;
• локальная версия устарела;
• действие частично завершилось;
• сервер перезапустился;
• событие обработано дважды.

Multi-user

• два человека одновременно редактируют;
• второй пользователь вышел;
• третий открыл приватную ссылку;
• роли изменились во время сценария.

Интеграции

• внешний API не ответил;
• платёж подтвердился с задержкой;
• файл загрузился частично;
• webhook пришёл дважды.

Edge-case checklist

Перед разработкой задай вопросы:

• Что будет, если нажать дважды?
• Что будет, если ответ придёт через 20 секунд?
• Что будет, если пользователь закроет приложение?
• Что будет, если он вернётся завтра?
• Что будет, если данные изменились на другом устройстве?
• Что будет, если сервер уже принял действие, а клиент не получил ответ?
• Что будет, если действие нельзя отменить?
• Что увидит второй пользователь?
• Что сохраняется после ошибки?
• Как человек поймёт, что делать дальше?

В игровом проекте edge cases включали:

• недопустимый ход;
• только один ход;
• отсутствие ходов;
• повторный бросок;
• рассинхронизацию;
• выход;
• reconnect;
• третий пользователь;
• повторный серверный запрос.

Но принцип одинаков для любого продукта.

Полезное упражнение: выпиши минимум 20 способов сломать свой главный сценарий. Если получилось только три, ты пока думаешь как автор happy path, а не как продакт.

9. Преврати решения в нормальное ТЗ

ТЗ для AI-продукта — не один гигантский документ с литературным описанием мечты.

Это набор связанных артефактов.

/product
  PRODUCT_BRIEF.md
  MVP_SCOPE.md
  ROADMAP.md

/flows
  USER_FLOWS.md
  STATE_REGISTRY.yaml
  EDGE_CASES.md

/logic
  RULES.md
  DATA_MODEL.md
  API_CONTRACTS.md

/design
  DESIGN.md
  SCREEN_REGISTRY.yaml
  ASSET_INDEX.md
  MOTION_SPEC.md

/quality
  ACCEPTANCE_CRITERIA.md
  QA_PLAN.md
  BUG_REPORT_TEMPLATE.md

Что описывать в ТЗ

• цели;
• пользователи;
• MVP;
• будущие функции;
• системы;
• user flows;
• states;
• переходы;
• edge cases;
• клиентскую логику;
• серверную логику;
• данные;
• ошибки;
• reconnect;
• дизайн;
• ассеты;
• motion;
• аналитику;
• тесты;
• acceptance;
• порядок реализации.

Почему модульные документы лучше

1. Агенту проще читать конкретный контекст.
2. Изменение ruleset не требует переписывать весь master prompt.
3. Можно назначить источник истины.
4. Разные специалисты читают только нужную часть.
5. Проще отслеживать противоречия.
6. Git нормально показывает изменения.

Правило: один документ — одна зона ответственности.

10. Собери AI Context Pack

AI Context Pack — это набор материалов, который позволяет агенту выполнить задачу без постоянного угадывания.

Минимальная структура:

/product
/rules
/flows
/states
/design
/assets
/api
/tests
/acceptance

Что отвечает на какой вопрос

Не передавай всё всегда

Большой контекст не равен хорошему контексту.

Для конкретной задачи агенту нужны:

• общий продуктовый brief;
• затрагиваемые states;
• API;
• дизайн;
• критерии;
• ограничения.

Если задача касается анимации фишки, не надо грузить ему всю экономику будущих турниров.

Главный принцип: контекст должен быть достаточным, структурированным и релевантным задаче.

11. Используй дизайн для снятия неопределённости

Дизайн — не украшение после разработки.

Он отвечает на продуктовые вопросы:

• что главное;
• что вторично;
• какие действия доступны;
• как выглядит ожидание;
• где отображается ошибка;
• что видит пользователь после действия;
• как различаются состояния;
• какие компоненты повторяются.

Design Source of Truth

Зафиксируй приоритет источников:

1. Product Spec — поведение
2. State Registry — состояния
3. Approved Design — layout
4. Approved Assets — внешний вид объектов
5. Motion Spec — движение
6. Старые концепты — только референс

Это важно, потому что AI-инструменты легко смешивают версии.

Например:

• старый макет содержит вкладку Compete;
• новый scope требует Рейтинг;
• старый экран показывает ставки;
• экономика пока выключена;
• старая доска была случайной генерацией;
• approved asset уже другой.

Без приоритета агент выберет то, что проще реализовать.

Accepted / Rejected

Не бойся хранить две папки:

/design/accepted
/design/rejected

Rejected полезен:

• показывает, что уже пробовали;
• объясняет, чего не делать;
• сохраняет хорошие части layout;
• снижает вероятность повторения ошибки.

Но production-код должен смотреть только на accepted.

Визуал: accepted / rejected
Заголовок: «AI начал придумывать продукт за меня»
Что объясняет: необходимость ручной классификации дизайна.
Подпись: «Красивый экран может быть отклонён, если он нарушает scope или продуктовую логику».

12. Создавай пригодные ассеты, а не красивые картинки

Генератор изображений легко создаёт доску, кубик, товар, интерьер или персонажа, которые отлично выглядят отдельно.

Но production asset должен работать внутри системы.

Проверка игрового или интерактивного ассета

• правильная перспектива;
• фиксированные пропорции;
• прозрачный фон;
• согласованный свет;
• одинаковый масштаб;
• чистые края;
• отсутствие лишних деталей;
• нужные состояния;
• подходящий формат;
• предсказуемость при анимации.

В моём примере один красивый board render мог быть бесполезен, потому что:

• фишки уже вшиты;
• фон не прозрачный;
• геометрия не совпадает;
• разные доски имеют разные размеры;
• точки расположены по-разному;
• нельзя поверх нормально рассчитывать координаты.

Поэтому понадобилось разделить:

board background
checker ivory
checker black
dice faces
legal markers
shadows
motion references

Visual reference и runtime asset

Это разные вещи.

Visual reference

Показывает характер:

• материал;
• свет;
• настроение;
• форму.

Runtime asset

Используется в продукте:

• фиксированный размер;
• прозрачность;
• согласованная геометрия;
• оптимизированный формат;
• версия в Git.

Главный принцип: если ассет нельзя масштабировать, позиционировать и переиспользовать, это картинка, а не компонент продукта.

13. Ставь задачи coding-агенту правильно

Плохая задача:

Реализуй весь MVP по приложенным материалам.

Хорошая задача ограничивает scope и даёт доказательство.

Шаблон задачи Codex

Цель:
Контекст:
Scope:
Не входит:
Затрагиваемые файлы:
Screen / State IDs:
Входные данные:
Ожидаемое поведение:
Запрещённое поведение:
API / contracts:
Assets:
Motion:
Acceptance criteria:
Тесты:
Артефакты проверки:
Stop-gate:

Пример структуры

Цель:
Реализовать состояние сохранения документа.

Scope:
DOC-04 ready
DOC-05 saving
DOC-06 saved
DOC-07 conflict

Не входит:
История версий
Совместное редактирование

Acceptance:
- повторный запрос идемпотентен;
- offline state виден;
- конфликт не перезаписывает серверные данные;
- Playwright делает четыре скриншота;
- агент останавливается после visual review.

Почему stop-gate обязателен

Агент любит продолжать.

Ты попросил вертикальный срез — он уже строит billing.

Ты попросил экран — он мигрировал базу.

Ты попросил поправить визуал — он решил переписать architecture.

Stop-gate задаёт границу:

После выполнения покажи артефакты и остановись до человеческого подтверждения.

14. Разрабатывай вертикальными срезами

Есть соблазн сначала сделать весь backend, потом весь frontend, потом дизайн, потом тестирование.

В итоге через месяц у тебя огромная техническая система без нормального пользовательского сценария.

Вертикальный срез проходит через все слои:

пользовательское действие
→ интерфейс
→ бизнес-логика
→ данные
→ ответ
→ ошибка
→ аналитика
→ проверка

Примеры vertical slice

SaaS

регистрация
→ создание workspace
→ приглашение человека
→ сохранение
→ повторный вход

Маркетплейс

найти товар
→ открыть
→ добавить
→ оплатить
→ увидеть заказ

Игра

создать матч
→ бросить
→ сделать легальный ход
→ синхронизировать
→ завершить

Первый vertical slice не обязан быть красивым во всём.

Но он обязан быть целостным.

Почему это лучше

• главный риск проверяется раньше;
• интеграционные проблемы появляются сразу;
• дизайн проверяется на реальных данных;
• легче получить пользовательский feedback;
• меньше кода выбрасывается.

15. Отчёт AI не является доказательством

Это правило стоит распечатать и повесить рядом с монитором.

AI может написать:

• изменено 267 файлов;
• 245 тестов зелёные;
• 14 builds;
• фаза завершена;
• production-shaped flow готов;
• implementation-ready.

Это полезная техническая информация.

Но она не отвечает на вопрос:

Пользователь может нормально пройти сценарий?

В моём процессе Codex периодически писал, что работа завершена, хотя при реальной проверке игровая логика продолжала ломаться.

Что не является приёмкой

• количество изменённых файлов;
• зелёная сборка;
• красивый отчёт;
• скриншот одного экрана;
• наличие тестов без проверки сценария;
• слова «готово».

Что является приёмкой

• пользовательский flow пройден;
• expected совпадает с actual;
• данные сохранились;
• повторное действие безопасно;
• ошибка корректно восстанавливается;
• второй пользователь видит правильное состояние;
• визуал соответствует accepted reference;
• тестовые артефакты доступны;
• баг нельзя воспроизвести повторно.

Трёхуровневая проверка

1. Техническая

• build;
• types;
• unit tests;
• integration tests;
• contract tests.

2. Сценарная

• happy path;
• error path;
• reconnect;
• повтор;
• два клиента;
• restart.

3. Пользовательская

• понятно ли, что делать;
• достигается ли результат;
• где возникает недоверие;
• хочется ли повторить сценарий.

Главный принцип: задача закрывается не тогда, когда AI закончил писать. Она закрывается, когда ты подтвердил поведение.

Визуал: сообщение AI «готово»
Заголовок: «245 тестов зелёные. А продукт где?»
Что объясняет: разницу между отчётом и реальным пользовательским результатом.
Подпись: «Технический фундамент может быть готов, а MVP — всё ещё нет».

16. Визуал, анимация и звук — часть продукта

Функция может технически работать и ощущаться отвратительно.

Фишка переместилась — функция выполнена.

Но продуктовый experience зависит от:

• реакции на нажатие;
• траектории;
• времени;
• тени;
• звука;
• состояния кнопки;
• подтверждения;
• отсутствия лагов.

Универсальная модель взаимодействия:

действие
→ мгновенная реакция
→ переход
→ результат
→ подтверждение

Motion не должен маскировать логику

Анимация обязана:

• объяснять изменение;
• сохранять контекст;
• показывать причинность;
• не тормозить пользователя;
• не создавать ложное состояние.

В игровом кейсе один кубик определяет один атомарный ход:

source → destination

Если одной фишкой используются два кубика:

source
→ intermediate
→ final

Но это пример более общего принципа:

Анимация должна повторять структуру действия, а не устраивать кино ради кино.

Звук

Хороший звук:

• подтверждает контакт;
• усиливает материал;
• помогает понять результат;
• не повторяется раздражающе;
• совпадает с таймингом.

Я записывал настоящие звуки нард: броски кубиков, движение и столкновение фишек, установку на поверхность.

Не потому, что без этого игра не запускается.

А потому, что пользовательское ощущение складывается из мелочей, которые по отдельности почти незаметны.

Главный принцип: визуал, motion и sound — не последний косметический слой. Они участвуют в понимании и доверии.

17. Как проверять реализацию

Чек-лист технической проверки

• приложение собирается;
• типы проходят;
• unit tests зелёные;
• integration tests зелёные;
• миграции воспроизводимы;
• повторные запросы безопасны;
• логи не содержат секретов.

Чек-лист сценарной проверки

• первый запуск;
• повторный запуск;
• основной flow;
• ошибка;
• offline;
• reconnect;
• другой пользователь;
• два устройства;
• server restart;
• отмена;
• повтор.

Чек-лист визуальной проверки

• размеры соответствуют reference;
• состояния различимы;
• нет запрещённых элементов;
• используется approved asset;
• компонент не прыгает;
• текст не обрезан;
• mobile safe area учтён;
• 320px работает;
• reduced motion работает;
• loading и error не спрятаны в случайный toast.

Чек-лист пользовательской проверки

• человек понимает первый шаг;
• достигает результата без подсказки автора;
• не теряет данные;
• понимает, что произошло после действия;
• доверяет результату;
• понимает ошибку;
• знает, как продолжить;
• хочет вернуться.

18. Повторяемая система создания AI-продукта

Ниже — процесс, который можно применить к большинству цифровых продуктов.

Шаг 1. Problem

Сформулируй проблему и результат пользователя.

Артефакт: Product Brief.

Gate: можешь объяснить ценность одним абзацем без списка функций.

Шаг 2. Research

Изучи конкурентов, аналоги и негативные отзывы.

Артефакт: Competitor Matrix.

Gate: есть минимум пять решений, которые влияют на scope.

Шаг 3. MVP

Определи главный риск и минимальную целостную систему.

Артефакт: MVP / Later / Maybe.

Gate: понятно, что сознательно не строится.

Шаг 4. System Map

Разложи продукт на зоны ответственности.

Артефакт: System Map.

Gate: у каждой системы есть вход, выход и критерий.

Шаг 5. User Flows

Опиши основные и негативные пути.

Артефакт: Flow Map.

Gate: есть happy path, error и recovery.

Шаг 6. States

Опиши поведение системы внутри экранов.

Артефакт: State Registry.

Gate: ни один критический переход не зависит от догадки разработчика.

Шаг 7. Edge Cases

Попробуй сломать продукт до пользователя.

Артефакт: Edge-case List.

Gate: минимум 20 сценариев по категориям.

Шаг 8. Context Pack

Собери релевантные документы для AI.

Артефакт: папка /context.

Gate: агент знает source priority и запреты.

Шаг 9. Vertical Slice

Реализуй один полный сценарий.

Артефакт: рабочий flow.

Gate: сценарий проходит через UI, логику, данные и ошибки.

Шаг 10. Manual QA

Пройди сценарий руками.

Артефакт: verification report и видео.

Gate: expected совпадает с actual.

Шаг 11. Visual Acceptance

Сверь продукт с accepted design и motion.

Артефакт: reference vs implementation.

Gate: пользовательская часть принята человеком.

Шаг 12. User Testing

Дай продукт людям без сопровождения.

Артефакт: наблюдения, метрики, баги.

Gate: понятно, где реальная проблема, а где личный вкус автора.

Шаг 13. Iteration

Исправь критичные точки.

Артефакт: новый verified build.

Шаг 14. Monetization

Только теперь проверяй, за что готовы платить.

Артефакт: monetization hypothesis.

Gate: core loop уже создаёт ценность.

19. Практические шаблоны

19.1 Product Brief

Название:
Пользователь:
Проблема:
Текущий способ решения:
Главный результат:
Core loop:
Почему человек вернётся:
Главный риск:
MVP:
Не входит:
Метрика:

19.2 Competitor Matrix

Продукт:
Аудитория:
Core loop:
Первый запуск:
Time to value:
Сильное решение:
Слабое место:
Ошибки:
Монетизация:
Отзывы:
Что забрать:
Что не повторять:

19.3 MVP Matrix

Функция:
Ценность:
Нужна core loop:
Сложность:
Риск:
Статус:
Причина:

19.4 User Flow

Точка входа:
Намерение:
Предусловия:
Основной путь:
Развилки:
Ошибки:
Recovery:
Результат:
Метрика:

19.5 State Specification

State ID:
Название:
Вход:
UI:
Доступно:
Запрещено:
Client:
Server:
Другой пользователь:
Transition:
Next:
Errors:
Reconnect:
Acceptance:

19.6 Acceptance Criteria

Given:
When:
Then:

Visual:
Network:
Persistence:
Error:
Accessibility:
Performance:

19.7 AI Context Pack

/product
/rules
/flows
/states
/design
/assets
/api
/tests
/acceptance

19.8 Задача для Codex

Цель:
Контекст:
Scope:
Не входит:
Файлы:
State IDs:
Поведение:
Запрещено:
Contracts:
Assets:
Motion:
Acceptance:
Tests:
Artifacts:
Stop-gate:

19.9 Bug Report

Название:
Окружение:
Предусловия:
Шаги:
Expected:
Actual:
Частота:
Видео:
Логи:
State version:
Severity:

19.10 Asset Checklist

• настоящий alpha;
• нет вшитого фона;
• фиксированный масштаб;
• единый свет;
• правильная перспектива;
• стабильная геометрия;
• чистые края;
• source и runtime разделены;
• формат оптимизирован;
• версия зафиксирована.

19.11 Visual Quality Checklist

• понятная иерархия;
• основной CTA один;
• состояния читаются;
• legal/illegal различимы;
• UI не перекрывает контент;
• motion объясняет действие;
• звук синхронизирован;
• слабое устройство поддержано;
• reduced motion есть;
• mobile safe areas работают.

19.12 User Test Checklist

Цель:
Аудитория:
Build:
Сценарий:
Задачи:
Наблюдения:
Метрики:
Запись:
Критерий успеха:
Известные ограничения:

20. Что делать после первого рабочего прототипа

Рабочий прототип — не конец.

Это первый момент, когда начинается нормальная продуктовая работа.

Дальше нужно проверить:

• понимает ли пользователь продукт;
• может ли пройти core loop;
• где ошибается;
• где не доверяет;
• где ждёт;
• где интерфейс конфликтует с логикой;
• где AI реализовал формально правильную, но неприятную механику;
• готов ли человек вернуться;
• за что он потенциально готов платить.

Не надо сразу строить сложную монетизацию.

Сначала докажи:

1. Пользователь достигает результата.
2. Он понимает, что произошло.
3. Сценарий стабилен.
4. Продукт ощущается качественно.
5. Есть причина вернуться.

После этого можно исследовать:

• подписку;
• комиссии;
• платные функции;
• косметику;
• B2B-модель;
• usage-based pricing;
• marketplace;
• другие варианты.

Вывод

AI реально меняет разработку.

Человек без классического опыта программирования может собрать продукт, который раньше требовал отдельной команды.

Но это не означает, что достаточно написать один умный промпт.

Чем сильнее становятся инструменты исполнения, тем важнее становится работа до исполнения:

• исследование;
• приоритизация;
• архитектура продукта;
• состояния;
• контекст;
• критерии;
• проверка.

AI не снимает с тебя ответственность.

Он просто даёт тебе очень быструю команду, которая иногда безумно эффективна, а иногда с серьёзным лицом строит вообще не тот продукт.

Твоя задача — не научиться писать самый длинный промпт.

Твоя задача — научиться управлять созданием продукта:

понять
→ разложить
→ описать
→ передать
→ проверить
→ улучшить