Prompting an App into Existence

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

Пример хорошего стартового промпта для Lovable или Bolt:

Сделай трекер привычек.
Пользователь: один человек, вход по email через Supabase Auth.
Данные: привычки (название, цвет, цель в днях) и отметки
выполнения (привычка, дата). Одна отметка на привычку в день.
Экраны: список привычек с полосой прогресса за 30 дней,
форма добавления, календарь отметок.
Ограничения: только мобильная вёрстка, тёмная тема,
без соцфункций и уведомлений в первой версии.

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

Первая генерация почти никогда не идеальна — это нормально. Цель стартового промпта не идеальное приложение, а правильный скелет: верная схема данных и нужные экраны. Косметику доведёте итерациями.

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

Второй приём — передавать контекст, а не пересказ. Если что-то сломалось, вставьте в чат точный текст ошибки из консоли браузера или с экрана, а не «что-то не работает». Ещё лучше — скриншот: современные инструменты понимают изображения, и скриншот кривой вёрстки точнее любого словесного описания. Формула рабочего баг-промпта: что я сделал, что ожидал, что получил, точный текст ошибки.

Третий приём — просить объяснение до изменения. Промпт «объясни, как сейчас сохраняются отметки привычек, ничего не меняя» стоит одну итерацию, но спасает от ситуации, когда агент «чинит» рабочую логику, которую вы просто не поняли. Возьмите за привычку: перед каждым изменением в незнакомой части приложения — сначала вопрос, потом правка.

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

Самая дорогая ошибка новичка — строить интерфейс неделю, а базу и авторизацию «прикрутить потом». Потом выясняется, что половина экранов написана под данные в памяти браузера, у сущностей нет владельца, и агент переписывает всё приложение заново.

Правильный порядок обратный: во второй-третьей итерации, как только скелет экранов готов, просите подключить реальное хранилище и вход. В Lovable и Bolt это Supabase: промпт «подключи Supabase: таблицы habits и checkins, у каждой строки поле user_id, вход по email» даёт вам сразу три вещи — постоянное хранение, понятие владельца данных и основу для политик доступа, о которых пойдёт речь в уроке про безопасность.

Схему данных диктуйте сами, а не оставляйте на волю агента. Минимальный словарь, который стоит знать: таблица — как лист в Excel; строка — одна запись; поле user_id — кому запись принадлежит; связь — «у привычки много отметок». Если вы явно напишете «у каждой отметки есть habit_id и дата, пара habit_id + дата уникальна», агент создаст правильную структуру. Если промолчите — может сложить отметки строкой JSON внутри привычки, и календарь потом придётся переделывать.

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

У каждого, кто вайб-кодил дольше часа, случался «цикл смерти»: агент чинит ошибку — появляется новая — он чинит её — возвращается первая. Признаки зацикливания: третья попытка исправить одно и то же место, ответы «теперь точно исправлено» без изменения поведения, растущий объём переписанного кода при неизменном баге.

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

Шаг один — откат. Вернитесь к последней рабочей версии через историю версий инструмента или git. Вы теряете полчаса «прогресса», который на деле был движением по кругу.

Шаг два — переформулировка с диагнозом. Вместо «почини календарь» дайте агенту роль диагноста: «не меняй код; перечисли три возможные причины, почему отметка не появляется в календаре, и скажи, как проверить каждую». Получив гипотезы, попросите исправить одну конкретную — так вы размыкаете цикл «стрельбы наугад».

Шаг три — смена подхода. Если и это не помогло, проблема обычно в архитектуре фичи, а не в строчке кода. Попросите реализовать фичу иначе: «убери текущую реализацию календаря и сделай заново: одна таблица checkins, календарь читает её напрямую». Свежая реализация по чёткой схеме почти всегда дешевле, чем лечение запутанной.