Вайбкодинг для самых маленьких. Первая идея.
Бывало такое, что в голову приходит идея своего проекта
или просто бесит, что макеты пылятся в Figma и никому не нужны?
Как же хорошо, что мы живём во время, когда нейронка нужна не только чтобы спросить, почему болит кишка или как заработать миллион, если тебе осталось жить месяц, но и чтобы писать код.
Причём не в формате
«вот тебе кусок кода, дальше сам»
а так, чтобы
— вести тебя за руку
— понимать структуру проекта
— помнить контекст
— и применять его по ходу работы
Короче, вайбкодинг.
1. Макет
Первое — подготовь макет.
По возможности:
• вынеси всё в токены
• сгруппируй информацию
• приведи дизайн в порядок, чтобы нейронке было проще понять, что вообще происходит
Слои переименовывать необязательно.
ИИ от Figma, который сам переименовывает слои, — вполне нормальный вариант закрыть этот вопрос за 5 минут.
Покажи флоу:
• используй прототипы
• состояния
• переходы
• если есть, анимации (не супер обязательно, но если есть что-то критичное, лучше показать)
Представь, что ты нашёл человека с горы,
который никогда не видел твой дизайн,
и тебе нужно максимально точно донести,
что именно ты хочешь получить на выходе.
2. Определись с инструментом
Cursor, Lovable, v0, Claude Code, GPT — вариантов вагон, но важно понимать,
что, для чего и зачем.
Cursor
• идеален как код-компаньон
• хорош для реальных проектов
• правки, рефакторинг, логика, баги
• когда тебе нужен ИИ внутри IDE
Claude Code
• очень силён в понимании большого контекста
• хорошо заходит для архитектуры, сложной логики и больших файлов
• меньше суеты, больше вдумчивости
Lovable / v0
• история про «быстро собрать что-то»
• лендинг, MVP, поиграться
• для полноценных проектов я бы не использовал
• имхо, это больше про fun, чем про прод
GPT
Лично я использую его, чтобы:
• написать нормальный промпт для код-компаньона
• обсудить идею продукта
• прикинуть технологический стек
• подумать об архитектуре до начала работы
3. Архитектура и стек
Где хранить пользователей?
Как работать с данными?
Как сделать авторизацию?
Как не обосраться так, чтобы на релизе продукт не вынесли?
Всё не так сложно, как кажется.
Перед тем как писать хоть строчку кода:
• используй GPT как партнёра по мышлению
• опиши идею продукта
• попроси предложить несколько сценариев архитектуры
• сравни варианты по сложности, стоимости и масштабируемости
Это этап осмысления,
и он экономит тонну времени и нервов дальше.
4. MCP и Figma
Когда ты определился со всем выше,
подключай MCP Figma
и начинай переносить макеты в реальность.
Да, что-то обязательно отвалится.
Это нормально.
С этим придётся смириться.
Главное:
• тыкать нейронку носом в её косяки
• показывать, где не так
• править итеративно
Через пару кругов ты придёшь к тому,
что она реально делает то, что у тебя нарисовано.
Отдельно важно:
• перенос дизайн-токенов
• сборка дизайн-системы прямо из Figma
• единые компоненты и стили
Это сильно упрощает жизнь дальше.
5. Как идти и что делать
После того как сверстал первые экраны,
не пытайся оживить всё одним промптом.
Не так:
«вот страница, сделай, чтобы работало»
А так:
• поэтапно
• аккуратно
• блочно
Если логика сложная:
• давай больше вводных
• проси сохранять решения в контексте
• заводи TO-DO-листы
• фиксируй договорённости
Медленно, но уверенно
наполняй продукт логикой, смыслом и «живостью».
6. Контекст
Обязательно следи за контекстом.
Хороший тон:
• под каждую задачу — отдельный чат
• но с сохранённым контекстом проекта
Постоянно заново объяснять,
что за продукт и что ты вообще делаешь,
это прямой путь к:
• шизофрении
• амнезии
• выгоранию
Никому это не нужно.
Следуя этим шагам,
ты оживишь свой давно пылившийся дизайн.
И, возможно
не факт
но возможно
если это кому-то нужно,
он принесёт тебе дофамин
и какие-то деньги.
Как-то так.
Пака 👋
@germannovikov
