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

Из каждого утюга я слышу про десятки крутых AI-сервисов, подключаемые skills, агенты-валидаторы и множество других обвесов вокруг вайб-кодинга. Всё это создаёт целый новый мир вместе с новыми ролями и вакансиями на рынке. Но очень сложно начать делать что-то действительно кайфовое, пока не разберёшься в базе. Что я, собственно, и сделал.

Этот гайд — стартовый, для тех, кто хочет на простом примере получить большой результат. Как только смогу воспроизвести что-то более сложное с использованием skills, интеграций и других трендов, будет вторая часть. А пока покажу, как добиться повторяемого процесса генерации дизайна в код, без сложных зависимостей и танцев с бубном.

Сделав всё по гайду, у тебя получится генерировать как минимум веб-страницу, которая:

  • сделана по дизайну

  • адаптивна под разные размеры экрана

  • учитывает retina и non-retina дисплеи

  • поддерживает локализацию с динамическим переключением языков

  • и позволяет реализовать другие свои хотелки

🕵 Потыкать готовый лендинг можно тут
🥷 А если понравиться гайд, нужен будет ещё похожий контент про дизайн, AI и продуктовую кухню — залетай в мой TG-канал

1. Что нужно для старта

  • Figma с доступом к Dev Mode для подключения Figma MCP

  • AI-ассистент. Я использовал Cursor с моделью GPT 5.3 Codex (сразу скажу: в бесплатном тарифе нет смысла)

  • Базовое понимание дизайна и вёрстки

  • Умение формулировать мысли техническим языком. Ведь AI не умеет читать мысли. Если ты сам не понимаешь, что хочешь получить, он тем более не поймёт

2. Подготовка макета в Figma

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

%pageName %type [%widthScreen · %theme]

Где:

  • %pageName — название страницы или отдельного блока

  • %type — тип состояния: default, hover, layout

  • %widthScreen — ширина экрана

  • %theme — тема: light, dark

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

Правило 1: Контент и ассеты

Дизайн должен содержать финальные тексты и графику. Локализацию сразу делать необязательно. Если вместо графики пока заглушки — окей, но делай их контейнеры сразу в финальных размерах.

Для дизайна, который меняет цветовое оформление, в Figma-проекте сразу заводим стили по принципу:

  • Light/Primary

  • Dark/Primary

Правило 2: Брейкпоинты

Всегда готовь отдельные фреймы под ключевые разрешения: 1920, 1280, 768, 375. Это база. Но ещё важнее — вынести отдельно ключевые блоки, а не только всю страницу целиком. На них будем показывать разные нюансы взаимодействия или весь контент, который скрыт (галереи, аккордеоны, карусели).

Такая структура помогает точечно работать с блоками и не заставлять AI каждый раз анализировать дизайн целиком, достаточно локализовать проблему: «Сейчас работаем только с Menu Default [1920 · Light], нужно исправить…».

В моём кейсе был следующий набор блоков: Home page, Menu, Download app button, Hero, Price, Feature, Settings, Footer.

Правило 3: Ресайз-логика

Поскольку сегодня AI всё ещё не очень уверенно интерпретирует auto layout и логику слоёв в Figma, некоторые моменты нужно буквально показывать на пальцах. Для этого делаем отдельный layout-фрейм, где показываем:

  • что тянется по ширине

  • что фиксировано

  • где перенос в колонку

  • где горизонтальный скролл

  • где min-width и max-width контейнера

Да, делаем визуальную инструкцию. И да, возможно, уже через пару месяцев это будет не нужно. Но сейчас это решает большую часть проблем и сильно повышает качество результата.

Правило 4: Состояние элементов

Hover, active, disabled — это тоже отдельный фрейм, на котором важно показать состояния элементов. Можно, конечно, ссылаться на UI Kit. Но на практике проще и гибче сделать отдельный фрейм конкретного блока.

Например, для меню делаем фрейм «Menu Hover [1920 · Light]» и показываем hover у всех элементов сразу. Так AI понимает не только цвет, но и контекст. Это сильно снижает шанс, что он сделает какую-нибудь херню.

Правило 5: Переключение тем

Если макет рассчитан на переключение тем — делаем отдельный фрейм. Если цвета нормально заведены в Figma, дальше всё тянется без проблем. У меня с этим почти никогда не было боли. 

Всё, база готова. Теперь время переноса. Проверьте, что Figma MCP в твоём проекте включена:

Открываем проект → Dev Mode → Inspect → MCP

  • Server status = Enabled

  • Image source = Download

Внимание! Ресурсы из Figma часто прилетают максимально херовыми, даже SVG. Поэтому часть файлов всё равно придётся заменять руками.

3. Перенос дизайна в код

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

Шаг 1. Фундамент

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

Я делаю сайт про %тема.
Нужно поэтапно заверстать его через Figma MCP, ссылка на проект %ссылка

Дизайн-макеты содержат основные брейкпоинты, которые отметил в названии фреймов: Home [1920 · Light] — где «1920» это размер экрана. Полный список брейкпоинтов: 1920, 1280, 768, 375. Ссылка на главную страницу с шириной 1920: %ссылка

Все ресурсы забираем из Figma. Дизайн делаем как в макетах. Анимацию элементов делаем потом. Важно работать не на скринах, а со структурой слоёв

Работать будем этапами. Задавай мне все уточняющие вопросы

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

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

Шаг 2. Агент-шаблон 

Мы в самом начале написания кода, и лучше сразу зафиксировать правила, чтобы неожиданно не переписывались какие-то блоки, соблюдалось переиспользование кода и так далее. Для этого делаем запрос на генерацию AGENTS_BASE.md (название может быть любым).

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

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

Шаг 3. Соединяем кусочки

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

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

Также добавляем +20px внизу контейнера, чтобы scrollbar не наезжал на контент

Думаю, схема тут понятна. Ссылаемся на заранее подготовленные состояния блоков или экранов, прописываем, что надо исправить. Как только победили все трудности, переходим к следующему блоку в дизайне. Наша задача пока только заверстать всё как в макете, уточнить логику отображения UI, какие-то мелкие эффекты.

Шаг 4. Актуальная графика

Когда адаптив работает шикарно во всех браузерах, а цветовые темы переключаются, надо поправить ресурсы. Как я писал выше, сейчас из Figma прилетают кривые SVG и растр с плохим качеством. Тут два стула:

  1. Руками заменять все ресурсы с исправлением нейминга

  2. Делегировать AI, явно прописав, что на что заменять. Причём ссылаться можно как на имя файла, так и на блок, в котором находится файл:

// Замена внутри блока
В блоке Feature есть List с преимуществами, для них я подготовил нормальные SVG, они должны быть 32х32px. Замени в размеченных мной местах следующие файлы, а старые удали:
- Поддержка 150 валют > ic_unlimList_BENEFIT_24
- Работа оффлайн > ic_offlineMode_16

// Замена конкретного файла
В блоке Hello будет замена 457г483759734 на final-promo-light.png в размере х2 для ретина-экранов

Шаг 5. Какая-то фича

Когда дизайн готов, можно добавлять всё, о чём ты давно мечтал: переключение тем, локализацию, интеграцию. Достаточно ввести запрос. У тебя достаточно контекста и правил, чтобы AI изолированно делал нужный функционал. Если взять для примера локализацию:

Теперь делаем локализацию, она будет доступа через кнопку %buttonName, для нее нужно сделать dropdown в общей стилистике

Для начала сделаем выбор из двух языков: RU, EN. Задай все уточняющие вопросы и приступим

Так, шаг за шагом всё получится.

Важная мысль, которую я понял в самом конце

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

Вот тут и есть ловушка. Чем больше ты берёшь на себя, тем сильнее падает внимание к деталям и качеству. Я сам это на себе очень почувствовал. Поэтому важно не впадать в истерию «я теперь full-stack everything». Иначе можно очень быстро выгореть, создавая при этом посредственный результат.