Вайбкодинг: интерфейсы — веб-продукты и приложения

Lovable и Replit удобны для сборки целого небольшого приложения с базой данных и логикой с нуля. Инструменты из темы «Вайбкодинг: сайты» сильнее в отдельных экранах и статичном контенте. Эти двое сразу думают в терминах данных и состояний приложения.

Claude Code, Codex CLI, Gemini CLI (см. тему «CLI и терминальные ИИ-агенты») здесь становятся основным инструментом, а не просто удобной альтернативой. Когда работаешь с уже существующим, более сложным проектом, важно глубже влезать в код и видеть все файлы сразу, а не только тот экран, который в фокусе прямо сейчас.

Отдельно полезно знать про Cursor. Это не терминальный агент, а полноценная IDE (редактор кода с окнами и кнопками, форк VS Code) со встроенным ИИ. По задачам он близок к терминальным агентам: видит весь проект, сам редактирует файлы. Но работает он через привычный визуальный интерфейс, а не через командную строку. Поэтому для дизайнера без опыта в терминале это часто более комфортная точка входа в сборку сложных проектов, чем Claude Code или Codex CLI.

Частый реальный сценарий — влиться в чужой, давно существующий продакшен-репозиторий компании. У него своя история, свои привычки и свои недокументированные решения, которых агент не знает и с нуля не угадает. В этом случае не проси агента сразу что-то менять. Сначала попроси его разобраться:

Изучи структуру этого проекта: какой стек используется, как устроены папки, где искать компоненты кнопок и цветовые токены — и кратко перескажи мне, прежде чем что-либо менять

Полезно также сразу попросить агента сгенерировать CLAUDE.md/AGENTS.md по итогам этого разбора (тема «Терминальные агенты: настройка под себя»). Тогда следующая сессия начнётся с готовой памятки, а не с нового разбора структуры с нуля.

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

• README.md — что это за продукт, для кого, какую задачу решает, как запустить проект локально. То, с чего начинает любой человек (или агент), впервые открывший репозиторий.
• ROADMAP.md — что уже сделано, что в работе, что запланировано и в каком порядке. Помогает агенту не предлагать функциональность, которая сознательно отложена на потом, и не тратить время на то, что уже реализовано иначе, чем ожидалось.
• ARCHITECTURE.md (или похожий файл) — какой стек используется и почему, как устроены папки, какие ключевые технические решения приняты и по какой причине. Это то же назначение, что и словарь из темы «Технический фундамент», только записанное для конкретного проекта, а не в общем виде.

Список не исчерпывающий. В реальных проектах к нему часто добавляют CHANGELOG.md (что изменилось в каждой версии) или CONTRIBUTING.md (правила для тех, кто присоединяется к разработке). Но если ты в одиночку ведёшь вайбкодинг-проект, трёх файлов выше обычно достаточно.

Это не то же самое, что CLAUDE.md/AGENTS.md из темы «Терминальные агенты: настройка под себя». Те файлы — правила поведения агента: что можно и нельзя, какие конвенции соблюдать. README/ROADMAP/ARCHITECTURE — спецификация самого продукта: что строится и куда он движется. На практике держи оба типа файлов вместе и явно проси агента читать их все в начале сессии, а не только CLAUDE.md.

Прочитай README.md, ROADMAP.md и ARCHITECTURE.md в этом проекте (или предложи их создать, если их ещё нет) и кратко перескажи мне, что за продукт, что уже сделано и что в планах, прежде чем начинать новую задачу

Раздел ниже — продвинутый уровень. Если это первое знакомство с вайбкодингом продукта, а не только сайтов, нормально прочитать его для общей картины. Вернёшься сюда уже на реальном проекте, когда почувствуешь нехватку структуры из README/ROADMAP/ARCHITECTURE выше.

README/ROADMAP/ARCHITECTURE — это скорее живой контекст, который обновляется по ходу проекта, а не жёсткое ТЗ на конкретный кусок работы. Для более точной задачи (целого нового продукта с нуля или отдельной сложной фичи внутри уже большого проекта) набирает обороты более строгий формат: spec-driven development, «разработка через спецификацию». Это осознанная альтернатива тому, чтобы вайбкодить вслепую одним промптом и потом разгребать, что агент придумал сам. Работает на любом масштабе: и для одной фичи с несколькими взаимосвязанными частями, и для всего продукта целиком, если он собирается с нуля именно по такой методологии. Вместо одного промпта на всю задачу заводится отдельная папка specs/[номер]-[название]/ с тремя файлами:

• что и зачем — описание задачи (продукта целиком или одной фичи), пользовательские сценарии и критерии приёмки, с явным указанием, что сознательно не входит в скоуп (spec.md у GitHub Spec Kit, requirements.md у AWS Kiro — суть та же, разное название у разных инструментов);
• как — технический стек, модель данных, архитектура и разбивка на компоненты (plan.md у Spec Kit, design.md у Kiro);
• что конкретно делать — tasks.md в обоих: разбивка на маленькие независимые задачи, каждая из которых явно ссылается на конкретный пункт из первого файла, а не берётся из воздуха.

Для лендинга или простой формы такая детализация избыточна. Но она окупается там, где есть несколько движущихся частей, будь то одна сложная фича или продукт целиком. Агент реже расходится с изначальным намерением, потому что каждую готовую задачу можно проверить не «нравится или нет», а «выполняет ли она именно то, что написано в спецификации». Готовыми командами такой workflow уже поддерживают несколько инструментов. GitHub Spec Kit — открытый эталонный инструмент, портативный, работает поверх любого агента, с явными командами /speckit-specify, /speckit-plan, /speckit-tasks. У части агентов они пишутся через точку: /speckit.specify. AWS Kiro — отдельная agentic IDE со встроенным workflow этого же вида, но требует именно её как среду разработки. Есть встроенный Plan Mode в Cursor. И сам Claude Code можно явно попросить работать по этой же логике, даже без отдельного инструмента. Конкретные названия файлов, команд и инструментов сверяй в моменте: эта практика оформилась совсем недавно и продолжает быстро меняться.

Прежде чем писать код для [фичи / продукта — описание], собери для неё три файла в папке specs/[название]/: spec.md с описанием и критериями приёмки (и явно — что не входит в скоуп), plan.md с техническим решением, tasks.md с разбивкой на маленькие задачи со ссылкой на конкретный пункт spec.md. Покажи все три черновика перед тем, как начать писать код

Прежде чем описывать агенту экран, посмотри, как его решают живые продукты. Mobbin — 1 400+ iOS- и веб-приложений с флоу целиком, Refero — 140 000+ экранов веба и iOS, Nicelydone — 200 000+ скриншотов SaaS с поиском по тексту на экране. Бесплатные тарифы у всех трёх сильно урезаны. Перенос в Figma у Mobbin и Refero проверь на своём тарифе: на бесплатном скриншот часто приходится копировать руками. Микровзаимодействия и анимации — в 60fps, это 2 100+ записей из реальных приложений. Показать агенту видео нельзя, но описать по нему, что двигается, как долго и с каким изингом, — можно и нужно.

Что такое MCP в общем виде и почему это работает точнее, чем скриншот, разобрано в теме «Софт: справочник по инструментам» (раздел «MCP: как агент подключается к твоим реальным данным»). Здесь практика конкретно для Figma. MCP-сервер даёт терминальному агенту (например, Claude Code) прямой доступ к реальному файлу в Figma: компонентам, стилям, токенам отступов и цвета. Угадывать вёрстку по скриншоту агенту больше не нужно. Результат получается точнее по пикселям и сразу использует реальные дизайн-токены проекта, а не придуманные заново значения.

Как подключить в общих чертах (конкретные шаги сверяй с актуальной документацией Figma, они меняются). Рекомендованный сегодня вариант — удалённый сервер, который хостит сама Figma. Ничего запускать на компьютере не нужно, достаточно один раз добавить его в агента. У Claude Code это одна команда:

claude mcp add --transport http figma https://mcp.figma.com/mcp

Затем внутри сессии набери /mcp, выбери сервер Figma и пройди авторизацию в браузере («Allow access»). После этого агент может открывать файлы по ссылке на фрейм или компонент. Удалённый сервер умеет не только читать макет, но и создавать и менять содержимое файла: фреймы, компоненты, переменные, auto layout. Второй вариант — десктоп-сервер. Он включается в настройках Dev Mode десктоп-приложения Figma, запускается локально на компьютере (адрес вида http://127.0.0.1 с портом, который покажет Figma) и работает с тем файлом, который сейчас открыт в приложении. Он встречается в более старых инструкциях и остаётся запасным путём. Удалённый Figma MCP формально работает на любом плане, но на бесплатном Starter и на View/Collab-местах это до 20 вызовов в месяц — на проект не хватит. Для реальной работы нужно Dev- или Full-место на платном плане (200 вызовов в день, на Enterprise — 600); чтобы агент не только читал, но и менял файл, нужно Full-место. Десктопный сервер — только на Dev- или Full-месте на платном плане.

Пример промпта после подключения Figma MCP:

Собери компонент Button по дизайну из Figma [ссылка на конкретный компонент: правый клик → Copy link to selection], используй действующие цветовые токены и токены отступов из библиотеки, а не произвольные значения

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

Агент не создаст проект в Supabase и не получит ключи сам. Сначала заведи проект на supabase.com, а URL и publishable-ключ (в старых проектах — anon-ключ) положи в файл .env. Таблицу назови profiles, а не users, чтобы не путать её с системной auth.users. И без политик безопасности строк (RLS) таблица открыта всем, у кого есть адрес проекта:

Проект Supabase создан, URL и publishable-ключ (в старых проектах — anon-ключ) лежат в .env. Создай таблицу profiles с полями id (ссылка на auth.users), email и created_at, включи на ней RLS с политикой «пользователь видит и меняет только свою строку». Оформи это как SQL-миграцию в папке проекта и подключи к таблице форму регистрации

Авторизацию разбей на два шага. Вход по email Supabase умеет сразу, но по умолчанию шлёт письмо с подтверждением. У встроенной почты Supabase жёсткий лимит писем в час — на время разработки подтверждение можно выключить в настройках Auth. Вход через Google требует ручной настройки в Google Cloud Console и в панели Supabase, агент её за тебя не сделает:

Добавь вход по email через Supabase Auth: страница логина, регистрация с письмом-подтверждением, защита приватных страниц от неавторизованного доступа

Добавь вход через Google. Сначала распиши по шагам, что мне нужно сделать руками в Google Cloud Console и в панели Supabase, и дождись, пока я скажу «готово». Только потом пиши код

Отдельный шаг — полировка UX и проверка доступности, прежде чем показывать проект кому-либо:

Прогони по этому прототипу проверку доступности: контрастность текста, alt-тексты у изображений, фокус при навигации с клавиатуры — и почини найденные проблемы

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

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

Если у продукта есть платная функциональность, платежи почти никогда не пишут с нуля. Подключают готовый сервис вроде Stripe (подробнее про саму идею — в теме «Технический фундамент»). Сначала реши, что продаёшь: разовый платёж и подписка — разные режимы Stripe Checkout. Для обоих нужен серверный роут с секретным ключом, webhook, который подтверждает оплату, и песочница Stripe (Sandbox, раньше — test mode) на время разработки:

Подключи Stripe Checkout в режиме подписки для тарифа Pro, в песочнице Stripe (Sandbox, раньше — test mode). Сессию оплаты создавай в серверном роуте, секретный ключ бери из .env. Добавь webhook, который после успешной оплаты отмечает пользователя как Pro в базе, и страницы успеха и отмены. Сначала скажи, где у проекта будет жить серверная часть

Прежде чем показывать это клиенту, проверь, что API-часть действительно работает, а не просто выглядит рабочей в интерфейсе. Здесь пригодятся два вспомогательных инструмента:

• Postman — приложение, через которое можно напрямую «постучаться» в эндпоинт API (тема «Технический фундамент») без интерфейса продукта: отправить тестовый запрос и посмотреть, что именно вернул сервер. Полезно, когда непонятно, проблема в интерфейсе или в самом бэкенде.
• ngrok — сервис, который даёт временный публичный адрес для проекта, который пока крутится только на локальном компьютере. Часто нужен для проверки вебхуков (уведомлений от Stripe о том, что платёж прошёл). Внешний сервис не может достучаться до localhost, а через ngrok может.

Оба инструмента можно попросить агента настроить и объяснить пошагово. Разбираться в них самостоятельно необязательно. Достаточно знать, что они существуют и зачем.

Git — система версий, которая хранит историю изменений кода: кто, что и когда поменял. Если что-то сломалось, она позволяет откатиться назад. Терминальные агенты умеют работать с git напрямую, поэтому полезно знать базовые слова. Commit — сохранённый «снимок» изменений с описанием. Branch — параллельная версия проекта для экспериментов, не влияющая на основную. Pull request — предложение слить изменения из branch в основной проект.

Сразу разведём это с историей версий в самой Figma. History в Figma и git в коде — две полностью независимые системы, которые ничего не знают друг о друге. Изменения в макете не попадают в git автоматически. И наоборот: откат кода никак не откатывает Figma-файл. Если нужно синхронизировать состояние дизайна и кода, это делается отдельным шагом (через Figma MCP, см. раздел выше). Само по себе «это же тоже версии» ничего не синхронизирует.

Закоммить текущие изменения с понятным сообщением на английском и создай новую ветку для эксперимента с тёмной темой

Если над одним проектом одновременно работает больше одного человека (дизайнер и разработчик, два дизайнера), рано или поздно оба меняют один и тот же файл в разных ветках. Git не может сам решить, чья версия правильная. Это называется merge conflict: git честно останавливается и просит человека выбрать, какой вариант оставить, вместо того чтобы угадывать. Пугаться этого не нужно. Конфликт — нормальная часть совместной работы, а не поломка. Агента можно прямо попросить объяснить, что именно конфликтует, и предложить решение:

У меня конфликт при слиянии веток — покажи, что именно конфликтует в каждом файле простыми словами, и предложи, как объединить обе версии

Общая техника точечной правки вместо переделки с нуля разобрана в теме «Вайбкодинг: сайты»: «не меняй ничего, кроме X», скриншот с пометкой вместо словесного описания, откат вместо бесконечных патчей. Здесь она работает так же, но на большем проекте цена ошибки выше. Добавь к ней одну привычку, специфичную для проекта с историей и несколькими людьми: пробуй рискованную правку в отдельной ветке (branch, см. выше), а не сразу в основной. Если эксперимент не удался, просто вернись к основной ветке, ничего не потеряв в рабочей версии. Если удался — слей его обратно. Это дешевле, чем чинить основную ветку после неудачной правки.

Перед показом клиенту или запуском попроси агента написать и прогнать автотесты. Это программы, которые сами проверяют, что ключевые сценарии (например, регистрация или отправка формы) действительно работают:

Напиши и запусти автотесты для формы регистрации, покажи, какие проходят, а какие нет, и почини сломанные

Сам деплой не отличается от простого сайта. Механика та же, что и в теме «Вайбкодинг: сайты», раздел «Деплой»: те же сервисы вроде Vercel, та же одна команда агенту. Разница в другом. Перед публикацией продукта с реальными пользователями и данными пройди чек-лист безопасности — тема «Безопасность вайбкодинг-проекта».

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

Что делать, когда что-то из этого сломалось, а не заработало с первого раза, разобрано в теме «Чтение и отладка кода агента». А если задача — встроить ИИ как функцию внутрь самого продукта для его будущих пользователей (чат-помощник, генерация описаний на лету и подобное), это уже другая задача. Она разобрана в теме «ИИ как функция внутри прототипа».

Объясни простыми словами, что такое git commit и branch — как будто я никогда не занимался разработкой

У меня есть готовый макет в Figma и подключённый Figma MCP — с чего начать сборку компонентов, чтобы не переделывать всё заново?

Мне дали доступ к существующему продакшен-репозиторию компании — с чего начать, чтобы не сломать ничего в первый же день?

Помоги составить README.md, ROADMAP.md и ARCHITECTURE.md для моего проекта [описание]: задай уточняющие вопросы, если данных не хватает, прежде чем писать

У меня есть фича [описание] со сложной логикой из нескольких шагов — оформи её как spec.md с критериями приёмки, прежде чем мы перейдём к плану и задачам