Вайбкодинг 101: полный гайд для новичков в 2026 году
Короткий ответ: вайбкодинг в 2026 году - это уже не игрушка для программистов и не магическая кнопка "сделай мне сайт". Это новый базовый компьютерный навык. Примерно как Excel раньше: не каждому нужно быть мастером сводных таблиц, но почти каждому полезно понимать, как собрать простую таблицу, формулу и отчет.
С программированием происходит то же самое. Если ты работаешь за компьютером, у тебя уже есть задачи, которые можно автоматизировать: внутренний инструмент, личный скрипт, лендинг, простая CRM, форма заявки, дашборд, сайт для клиента, мини-приложение для своего бизнеса.
Но есть ловушка. Если заходить в вайбкодинг как в Тильду, где "что-то покрутил - и сайт появился", быстро начинаются проблемы. AI может написать код, но если ты вообще не понимаешь, что такое клиент, сервер, фронтенд, бэкенд, база данных, API, деплой и GitHub, ты не сможешь нормально поставить задачу, проверить результат и довести проект до прода.
Эта статья - большая текстовая версия двухчасового видео "Программирование это новый Excel". Видео можно посмотреть на YouTube, а ниже я разложил материал как самостоятельный гайд для новичка: от IT-карты до первого проекта, GitHub и Vercel.
Это не конспект "про программирование вообще". Это маршрут входа в вайбкодинг: сначала большая картина IT, потом конкретный стек, потом первый проект, который можно довести до публичной ссылки.
В ролике весь путь раскладывается как большая карта: цель, IT-карта, стек, кодинг, тестирование, деплой и итерация
Как устроен этот гайд
- Часть 1. IT-ландшафт и IT-карта - разбираемся, где в разработке клиент, сервер, сеть, фронтенд, бэкенд, базы, API и деплой.
- Часть 2. Собираем техстек - выбираем модель, инструменты, кодовую базу и минимальную установку для первого проекта.
- Часть 3. Первый вайбкодинг-проект - берем реальный кейс, даем задачу агенту, проверяем, деплоим и итерируем.
Внутри техстека держим три слоя
- Модель - какая LLM думает, пишет код и чинит ошибки.
- Код - где лежит проект, в каком фреймворке он сделан, как агент работает с файлами.
- Скилл - что должен уметь ты: ставить задачу, читать результат, проверять, давать фидбек и доводить до прода.
Внутренние ссылки по ходу статьи
- Бенчмарки моделей и код-агентов - когда надо выбрать модель или понять, кто сейчас силен в коде.
- Мой AI-стек в 2026 - актуальный набор инструментов, которыми я реально пользуюсь.
- Пошаговая установка первого техстека - отдельная версия setup-гайда; ключевые шаги я также продублировал ниже в этой статье.
- База инструментов - карточки моделей, агентов, компаний и стеков.
Главные выводы
Если ты совсем новичок, тебе не надо сначала учить год JavaScript, алгоритмы и устройство процессора. Тебе надо понять карту: где находится фронтенд, где сервер, как данные доходят до пользователя, зачем нужен API, почему GitHub и Vercel постоянно всплывают в разговорах про вайбкодинг и веб-разработку.
Вайбкодинг работает лучше всего, когда у тебя есть конкретная цель. Не "научиться программировать вообще", а "собрать страницу для заявки", "сделать форму для клиента", "автоматизировать отчет", "переделать сайт друга", "собрать MVP". Цель помогает агенту не писать абстрактную ерунду.
AI-инструменты не отменяют архитектуру. Cursor, Codex, Claude Code, GitHub Copilot, Lovable и Bolt могут писать код, но они работают внутри обычного IT-мира: языки, фреймворки, пакеты, базы данных, облака, деплой, тестирование.
Для первого международного веб-проекта нормальный стартовый стек такой: TypeScript, Next.js, Tailwind CSS, Cursor или Codex, GitHub и Vercel. Бэкенд можно не трогать, если первая задача - статичная страница или простой MVP без хранения данных.
Главный навык новичка - не "писать код руками", а ставить задачу, читать результат, замечать косяки, отдавать агенту конкретный фидбек и проходить цикл: планирование, архитектура, код, тестирование, деплой, итерация.
Часть 1. IT-ландшафт и IT-карта
Сначала нужна большая картина. Не язык, не фреймворк, не "какой промпт вставить в Cursor", а карта мира, в котором агент будет писать код. Если этой карты нет, вайбкодинг превращается в угадайку: AI что-то сделал, что-то сломалось, а ты не понимаешь, где именно проблема.
Программирование - это новый Excel
Раньше Excel был обязательным навыком для любого человека, который работает с информацией. Не всем нужно уметь строить финансовые модели на уровне инвестбанка. Но если человек вообще не умеет открыть таблицу, сделать формулу и привести данные в порядок, он выпадает из нормальной офисной работы.
Сейчас программирование движется туда же.
Не в смысле "каждый должен стать senior-разработчиком". Нет. Но уметь собрать маленький сайт, автоматизировать повторяющееся действие, подключить форму, написать простой скрипт или объяснить AI-агенту, что именно надо сделать, становится базовой грамотностью.
В видео я привожу пример из жизни: человек в рекламной команде сделал внутренний инструмент, который автоматизировал большую часть его рутины. Он не стал "классическим программистом", но стал самым продуктивным человеком в своей зоне, потому что увидел процесс, который можно переложить на программу.
Вот правильная мысль для старта:
Все, что ты регулярно делаешь за компьютером, потенциально можно автоматизировать.
Не обязательно сразу. Не обязательно идеально. Но если ты видишь повторяющееся действие, таблицу, форму, выгрузку, ручное копирование, отчет, лендинг или маленький внутренний процесс - это кандидат для первого проекта.
Начинай не с языка, а с цели
Первый шаг - не "выбрать язык программирования". Первый шаг - поставить цель.
Плохая цель: "я хочу научиться программировать".
Нормальная цель: "я хочу собрать страницу, которая принимает заявки от клиентов".
Еще нормальные цели:
- сделать простой лендинг для услуги;
- автоматизировать отчет в бизнесе;
- собрать внутреннюю страницу для команды;
- переделать старый сайт знакомого;
- сделать форму, которая сохраняет заявки;
- собрать личный дашборд;
- сделать маленький инструмент для своей работы.
Почему это важно: AI-агенту нужна конкретика. Если ты говоришь "научи меня программированию", он начинает лекцию. Если ты говоришь "сделай страницу для фитнес-бренда с hero, каталогом, формой заявки и деплоем на Vercel", он может построить маршрут.
В начале ролика цель формулируется до выбора стека: сначала что строим, потом чем строим
В примере из видео цель такая: взять существующий сайт Bonafide и сделать новую версию, вдохновленную Nike.com. Это не учебный todo-list, а понятная продуктовая задача: есть бренд, есть визуальный ориентир, есть будущий сайт.
Новичку лучше начинать именно так. Не с абстрактной "практики", а с маленького реального результата.
Почему нужна IT-карта
IT кажется магией, потому что внутри слишком много сущностей. Языки, фреймворки, терминал, GitHub, серверы, базы данных, API, облака, домены, билды, пакеты, деплой, логи, ошибки.
Если ты смотришь на это как на одну огромную коробку, вайбкодинг превращается в азартную игру: попросил AI, он что-то сделал, вроде работает, потом сломалось, и непонятно куда смотреть.
Нужна карта.
Большая IT-карта из ролика: вместо магической коробки мы раскладываем разработку по зонам
Карта нужна не для того, чтобы ты стал инженером за вечер. Она нужна, чтобы ты понимал, куда относится проблема.
Если текст на странице не того цвета - это фронтенд и CSS.
Если форма отправляется, но данные не сохраняются - это бэкенд или база.
Если сайт работает локально, но не открывается в интернете - это деплой, хостинг или домен.
Если агент поставил старую версию библиотеки - это пакетный менеджер и зависимости.
Если Vercel не понял, что проект на Next.js - это структура проекта и build settings.
Когда ты умеешь хотя бы грубо разложить проблему по карте, ты уже не беспомощен. Ты можешь дать агенту нормальный фидбек: "проверь деплой на Vercel", "посмотри package.json", "форма не пишет данные в базу", "на мобильном header перекрывает hero".
Языки программирования: зачем они вообще нужны
Компьютер внизу понимает не TypeScript и не Python. Он понимает машинный код: низкоуровневые инструкции, которые близки к железу. Людям так писать неудобно, поэтому появились уровни абстракции.
Сначала низкоуровневые языки вроде Assembly. Потом C. Потом более удобные языки. Потом JavaScript, Python, TypeScript и другие языки, которыми уже можно пользоваться человеку без постоянной боли.
В ролике языки объясняются как уровни абстракции: от машинного кода к языкам, которыми может пользоваться человек
Главная идея для новичка простая: язык программирования - это способ объяснить компьютеру, что делать, в форме, которая понятна человеку.
Но для вайбкодинга в вебе тебе не нужно знать все языки. На первом шаге важно понимать, что чаще всего всплывают:
- HTML - разметка страницы;
- CSS - внешний вид;
- JavaScript - логика в браузере;
- TypeScript - более строгая и безопасная версия JavaScript;
- Node.js - способ запускать JavaScript вне браузера;
- SQL - язык работы с реляционными базами данных.
Если ты идешь в современный веб-стек, TypeScript и Next.js будут встречаться постоянно. Поэтому для первого проекта лучше не спорить с рынком, а взять распространенный стек, который AI хорошо знает.
Веб - это клиент, сервер и сеть
Веб-разработка держится на трех больших блоках: клиент, сервер и сеть.
Клиент - это то, чем пользователь взаимодействует с продуктом. Браузер, мобильное приложение, десктопное приложение, иногда даже устройство без экрана. В нашем случае чаще всего клиент - это браузер.
Сервер - это компьютер, который отдает клиенту данные, страницы, картинки, ответы API и все остальное. Сервер не обязательно стоит у тебя дома. Обычно он где-то в облаке.
Сеть - это то, как клиент и сервер общаются между собой.
Базовая схема из ролика: клиент, сервер и сеть между ними
Пример: ты открываешь сайт. Браузер на твоем ноутбуке - клиент. Он просит страницу. Где-то в облаке сервер отдает HTML, CSS, JavaScript, картинки и данные. Между ними идет сетевое общение.
Для новичка это важнее, чем кажется.
Когда ты говоришь "у меня сайт не работает", надо уточнять: не работает где?
- В браузере не отображается кнопка?
- Сервер не отдает данные?
- Запрос не доходит?
- База не отвечает?
- Деплой не собрался?
- Домен не привязан?
Без этой карты все превращается в одну фразу: "сломалось". С картой ты начинаешь понимать, куда копать.
Что такое сервер
Сервер - это не магический шкаф. Это тоже компьютер, только его задача - обслуживать других.
Твой ноутбук обычно клиент: он просит, показывает, обрабатывает твои клики. Сервер обычно отвечает: хранит данные, отдает файлы, принимает запросы, запускает код, который должен работать постоянно.
В ролике сервер объясняется на примере сайта: часть картинки и данных приходит к клиенту с другой машины
У сервера есть две стороны:
- hardware - физическая машина или виртуальная машина;
- software - код, база, процессы, которые на ней работают.
Когда говорят "облачный сервер", обычно имеют в виду не небо и не абстрактную магию. Это чужой компьютер в дата-центре, который ты арендуешь или используешь через сервис.
Для вайбкодинга важно понимать уровни облака:
SaaS - сервис как продукт. Например, Dropbox. Ты пользуешься, но почти не трогаешь техническую часть.
IaaS - инфраструктура как сервис. Например, AWS или Yandex Cloud. Много контроля, много сложности.
PaaS - платформа как сервис. Например, Vercel, Supabase, Convex. Они забирают часть сложности и дают разработчику более понятный слой.
Для новичка чаще всего нужен PaaS. Не потому что это "игрушечно", а потому что ты хочешь собрать продукт, а не провести неделю в настройках AWS.
PaaS-сервисы вроде Vercel, Supabase и Convex убирают часть инфраструктурной сложности
Фронтенд: HTML, CSS и JavaScript
Фронтенд - это то, что пользователь видит и с чем взаимодействует.
В классическом вебе фронтенд держится на трех вещах.
HTML отвечает за структуру: где заголовок, где текст, где ссылка, где изображение, где форма.
CSS отвечает за внешний вид: цвет, размер, отступы, сетки, адаптивность, радиусы, состояние кнопки при наведении.
JavaScript отвечает за поведение: что происходит при клике, как открывается меню, как валидируется форма, как данные подгружаются без перезагрузки страницы.
Фронтенд в ролике разбирается как связка HTML, CSS и JavaScript
HTML можно увидеть прямо в браузере через View Page Source или инструменты разработчика. Это не значит, что ты должен сразу читать весь HTML. Но полезно понимать: страница не просто "нарисовалась". Под ней есть структура.
View Page Source показывает HTML-основу страницы: не магия, а разметка
CSS можно писать отдельно, но в современных проектах часто используют фреймворки. В видео я показываю Tailwind: это популярный CSS-фреймворк, который позволяет писать стили прямо рядом с разметкой через короткие классы.
Tailwind в IT-карте: популярный CSS-фреймворк для современных веб-проектов
JavaScript в современном вебе почти всегда идет вместе с TypeScript. TypeScript добавляет типы и снижает количество глупых ошибок. AI-агентам тоже проще работать с типизированным проектом, потому что у них больше подсказок о структуре кода.
Next.js - один из самых популярных фреймворков на базе React. Для первого проекта он хорош тем, что его отлично знают AI-модели, у него сильная экосистема и он нативно дружит с Vercel.
TypeScript и Next.js появляются как стандартная связка для современного веб-кодинга
Бэкенд, данные и базы
Бэкенд - это часть системы, которая отвечает за данные, бизнес-логику, авторизацию, работу с базой, обработку запросов и общение с внешними сервисами.
Новичку легко думать: "сайт - это картинка". Но почти любой серьезный продукт быстро упирается в данные.
Пользователь зарегистрировался - где хранить аккаунт?
Клиент оставил заявку - куда она попала?
Покупатель оплатил - где статус платежа?
Админ поменял цену - где это записано?
Здесь появляются базы данных.
Самое простое сравнение: база данных похожа на Excel, только для приложений. Внутри есть таблицы, записи, связи, запросы. SQL - это язык, которым можно спрашивать и менять данные в реляционных базах.
Database ecosystem из ролика: SQL, NoSQL, document, vector, time-series и другие типы баз
Для первого проекта не надо знать весь зоопарк баз данных. Но надо понимать, что "сохранить данные" - это отдельная задача, а не автоматическое свойство страницы.
Если ты делаешь статичный лендинг, база может не понадобиться.
Если ты делаешь форму заявки, можно сначала отправлять данные в почту, Telegram, Google Sheets или простой backend.
Если ты делаешь приложение с пользователями, оплатами, личными кабинетами и состояниями, база почти неизбежна.
Для новичка хорошая стратегия - не лезть в бэкенд раньше времени. Сначала собери фронтенд и деплой. Потом добавляй хранение данных через понятный сервис: Convex, Supabase или другой backend-as-a-service.
API: как программы разговаривают друг с другом
API - это интерфейс взаимодействия программ.
Когда клиент спрашивает сервер: "дай мне список товаров", это запрос к API.
Когда форма отправляет заявку, это запрос к API.
Когда твое приложение обращается к OpenAI, платежному сервису, CRM или базе, оно тоже часто делает это через API.
API в ролике объясняется как способ общения клиента, сервера и внешних сервисов
Самый распространенный формат для новичка - REST API. Есть и другие: GraphQL, WebSocket, RPC и так далее. На старте тебе не нужно знать все. Достаточно понимать, что API - это договор: куда отправить запрос, какие данные передать, какой ответ ждать.
Именно поэтому AI-агенту надо давать контекст. Если ты просто говоришь "подключи оплату", он может сделать что угодно. Если ты говоришь "подключи форму к API, который принимает имя, email, телефон и сообщение, обработай ошибку и покажи успешное состояние", шанс получить нормальный результат выше.
Тестирование и edge cases
Код написал - это еще не конец.
Нужно проверить, что работает основной сценарий. Потом проверить краевые случаи: пустая форма, длинный email, мобильная версия, медленная сеть, невалидный ответ сервера, ошибка деплоя, неправильная переменная окружения.
Тестирование в ролике идет отдельным этапом: сделал - проверил - нашел косяк - отдал агенту обратно
Edge case - это ситуация на краю нормального сценария.
Например, основная задача формы - отправить заявку. Edge cases:
- пользователь не ввел email;
- пользователь ввел email с ошибкой;
- сервер временно недоступен;
- заявка отправилась два раза;
- кнопка не помещается на мобильном экране;
- после успешной отправки человек не понял, что произошло.
Новичок часто думает, что разработка - это "написать код". На практике большая часть работы - это довести до состояния, где продукт не разваливается от первого неидеального действия пользователя.
AI здесь помогает сильно. Но он не угадает все важные edge cases, если ты сам не попросишь.
Часть 2. Собираем техстек
Теперь переходим от карты к рабочему набору. Техстек - это не список модных слов. Это связка решений, с которой проект можно создать, проверить, сохранить, задеплоить и потом развивать.
Для новичка техстек должен быть скучным и популярным. Скучным - потому что меньше сюрпризов. Популярным - потому что AI-модели хорошо видели этот код, документацию, ошибки и типовые решения.
Первый стек для новичка
В видео я предлагаю минимальный международный стек для первого вайбкодинг-проекта.
Тебе нужны:
- среда разработки: Cursor или похожая IDE;
- AI coding agent: Codex, Claude Code или другой агент;
- язык и фреймворк: TypeScript и Next.js;
- стили: Tailwind CSS;
- репозиторий: GitHub;
- деплой: Vercel.
Минимальный стек для первого проекта: IDE, агент, TypeScript, Next.js, GitHub и Vercel
Почему не выбрать что-то экзотическое?
Потому что AI лучше работает с популярным. Чем больше кода, документации, примеров и ошибок в интернете, тем лучше модель знает стек. TypeScript, React, Next.js, Tailwind, GitHub и Vercel - это не единственный путь, но это понятная стартовая связка.
Для России можно собирать аналогичный стек с другой инфраструктурой, если тебе нужны российские облака, платежи, хранение данных и юридическая совместимость. Но для первого учебного международного проекта Vercel проще.
Если хочешь сверить это с текущим рабочим набором инструментов, смотри мой AI-стек в 2026. Если нужна отдельная страница только про установку, она лежит здесь: первый техстек новичка. Но ниже я продублирую ключевые шаги прямо в этой статье.
Модель: что будет думать и писать код
LLM - large language model, большая языковая модель. Это то, что лежит под ChatGPT, Claude, Gemini и другими AI-сервисами.
Для вайбкодинга модель важна. Разные модели по-разному пишут код, понимают контекст, чинят ошибки, работают с инструментами и держат длинные задачи.
В ролике я показываю раздел бенчмарков vibecoding.ru: там модели для кода сравниваются по агрегированным сигналам из разных источников. Если выбираешь именно модель, начинай с рейтинга моделей. Если выбираешь не модель, а рабочий coding agent, смотри бенчмарки код-агентов.
Бенчмарки vibecoding.ru помогают выбирать модель для кода не по слухам, а по измеряемым сигналам
Но есть важное правило: не заучивай название "лучшей модели" навсегда. На 8-9 июня 2026 года расклад один, через неделю он может измениться. Поэтому правильнее понимать принцип:
- для маленьких правок подойдет более дешевая модель;
- для сложной архитектуры и больших задач нужна сильная модель;
- для дизайна и вкуса важен не только benchmark, но и реальный hands-on опыт;
- для кода важен не только chat, но и то, как модель работает внутри агента с файлами, терминалом и браузером.
Код: где живет проект и агент
AI coding tools сейчас расползлись по разным форматам.
IDE - инструмент встроен в среду разработки. Cursor - главный пример.
CLI - агент живет в терминале. Claude Code и Codex CLI - такие примеры.
Desktop app - отдельное приложение, где можно открыть проект и работать с агентом. Codex в таком формате удобен, когда хочется видеть чат, файлы, терминал и рабочий контекст рядом.
Cloud agent - ты даешь задачу в облаке, а агент работает где-то там, часто без полного визуального контроля.
Web builder - Lovable, Bolt и похожие инструменты, где пользователь строит приложение в браузере.
GitHub-native agent - агент работает прямо с репозиторием, issue и pull request.
В видео я показываю несколько поверхностей и объясняю, почему для практического проекта беру Codex.
Cursor как IDE: слева файлы, снизу терминал, справа код и проектная структура
Claude Code хорош как терминальный агент. Он живет ближе к классическому developer workflow: терминал, файлы, команды, проверки.
Claude Code в терминале: формат CLI ближе к обычной инженерной работе
Codex в этом прогоне удобен тем, что можно работать в отдельном приложении, видеть чат, проект, терминал, дерево файлов и браузерный контекст.
Интерфейс Codex App: чат, проект, дерево файлов, терминал и браузерный контекст
Важно: не надо становиться фанатом одного интерфейса. Инструменты меняются. Карта остается. Если хочешь посмотреть карточки инструментов отдельно, начинай с базы инструментов: там постепенно собираются Codex, Claude Code, Cursor и другие сущности.
Скилл: твоя роль в вайбкодинг-проекте
Третий слой стека - скилл. Это звучит менее эффектно, чем "новая модель" или "новый агент", но именно он решает, получится ли у тебя продукт.
Вайбкодинг не означает "я ничего не понимаю, а AI все сделает". Рабочая формула другая:
- модель дает интеллект;
- инструмент дает доступ к коду, терминалу и браузеру;
- скилл превращает хаотичную генерацию в управляемый процесс.
У новичка на первом этапе должно быть четыре базовых навыка.
Первый - ставить задачу. Не "сделай красиво", а "сделай лендинг для бренда X, в стиле Y, на Next.js и Tailwind, без бэкенда, с адаптивной hero-секцией, каталогом и формой".
Второй - читать результат глазами. Открыть страницу, пройти сценарий, посмотреть мобильную версию, сравнить с исходной задачей.
Третий - превращать ощущение в конкретный фидбек. Не "фигня", а "кнопка теряется, hero не похож на premium retail, на мобильном заголовок ломается, Vercel build упал на ошибке импорта".
Четвертый - доводить до публичной ссылки. Пока проект живет только локально, он не прошел реальность. GitHub и Vercel нужны не для галочки, а чтобы проект можно было открыть, проверить и показать другому человеку.
Вот почему в этой статье стек устроен не как список приложений, а как система: модель, код, скилл.
Установка техстека: пройди один раз и не возвращайся к хаосу
Ниже - сжатая, но рабочая версия отдельного гайда первый техстек новичка. Если ты читаешь эту статью как инструкцию, можешь идти прямо по шагам здесь.
-
Заведи аккаунт GitHub. Открой github.com/signup, зарегистрируйся, подтверди email и включи двухфакторную защиту. GitHub - это место, где будет лежать код и история изменений.
-
Открой терминал. На Windows это PowerShell или Windows Terminal. На macOS - Terminal. Терминал нужен не для понтов, а чтобы запускать проект, ставить зависимости и видеть ошибки.
Проверка:
pwd
Команда должна показать текущую папку.
- Поставь Git. Скачай Git с git-scm.com/downloads, установи и перезапусти терминал.
Проверка:
git --version
Сразу настрой имя и email:
git config --global user.name "Твое Имя"
git config --global user.email "you@example.com"
4. Поставь Cursor. Скачай редактор с cursor.com/download. Можно использовать VS Code, но новичку Cursor удобен тем, что файлы, терминал и AI находятся в одном рабочем окне.
- Поставь Node.js LTS. Открой nodejs.org/en/download, выбери LTS-версию, установи и перезапусти терминал.
Проверка:
node -v
npm -v
Если появились версии, Node.js стоит нормально.
-
Поставь pnpm. Это пакетный менеджер, через который будем создавать и запускать проект.
npm install --global corepack@latest corepack enable pnpm pnpm -v
Если pnpm не появился, используй прямую установку:
npm install -g pnpm@latest-11
pnpm -v
7. Создай первый Next.js-проект. Перейди в удобную папку, например на рабочий стол, и создай приложение:
pnpm create next-app@latest first-vibe-project --yes
cd first-vibe-project
pnpm dev
Открой http://localhost:3000. Если видишь стартовую страницу Next.js - проект живой.
-
Открой проект в Cursor. В Cursor выбери File -> Open Folder, открой папку first-vibe-project, затем открой встроенный терминал через Terminal -> New Terminal. Проверь, что команда pnpm dev запускается уже из Cursor.
-
Сделай первый коммит. Это сохранение состояния проекта.
git status git add . git commit -m "Initial Next.js app"
-
Создай репозиторий на GitHub и отправь код. На GitHub нажми New repository, назови его first-vibe-project, не добавляй лишний README, создай репозиторий и выполни команды из терминала проекта. USERNAME замени на свой GitHub username.
git branch -M main git remote add origin https://github.com/USERNAME/first-vibe-project.git git push -u origin main
-
Подключай backend только когда появились данные. Если проект просто показывает одну страницу, backend пока не нужен. Если появляются заявки, пользователи, задачи, посты или счетчики, можно добавить Convex:
pnpm add convex pnpm convex dev
Главное правило: сначала страница и деплой, потом данные. Не надо превращать первый день в архитектурный марафон.
- Задеплой на Vercel. Открой vercel.com/signup, войди через GitHub, нажми Add New -> Project, выбери репозиторий first-vibe-project, проверь что Framework Preset стоит Next.js, нажми Deploy.
На выходе у тебя должно быть четыре вещи: папка проекта на компьютере, код в GitHub, публичная ссылка на Vercel и понимание, как повторить цикл.
Если что-то ломается, не паникуй. Ошибка - это не провал, а конкретный текст для агента. Копируешь лог, отдаешь Codex, Claude Code или Cursor и просишь исправить с сохранением выбранного стека.
Часть 3. Первый вайбкодинг-проект
Теперь соединяем карту и стек в реальную работу. Цель этой части - не выучить все термины, а пройти полный цикл: задача, архитектура, генерация кода, проверка, GitHub, Vercel и итерация.
Практический кейс: переделываем сайт Bonafide
Теория нужна, но без практики она быстро выветривается. Поэтому в ролике мы берем реальный кейс: сделать новую версию сайта Bonafide, вдохновленную Nike.com.
Сначала формулируем задачу для агента: какой продукт, какой визуальный ориентир, какой стек, что должно быть на странице, где хостим, что не делаем в первой версии.
Промпт к агенту должен содержать цель, стек, визуальный ориентир и ограничения
На этапе архитектуры мы раскладываем задачу по карте:
- фронтенд: Next.js, TypeScript, Tailwind;
- бэкенд: в первой версии не делаем;
- данные: статичный контент на странице;
- деплой: Vercel;
- репозиторий: GitHub;
- тестирование: локально и после деплоя.
Архитектурная привязка задачи к IT-карте: что относится к frontend, backend, server и deploy
Это важный момент. Новичок часто просит AI "сделай сайт", а потом удивляется, что агент выбрал странный стек, не понял дизайн, сделал лишний бэкенд или положил проект не туда.
Чем точнее ты задаешь рамки, тем меньше агенту приходится угадывать.
GitHub: зачем нужен репозиторий
GitHub - это место, где хранится код проекта и история изменений.
В первом проекте можно не знать Git глубоко. Но надо понимать минимум:
- проект должен лежать в репозитории;
- изменения можно отправить на GitHub;
- Vercel может забрать код из GitHub и задеплоить сайт;
- если что-то сломалось, у тебя есть история и точка возврата.
Создание нового GitHub-репозитория для проекта из ролика
Если делаешь проект для себя или клиента, обычно репозиторий лучше делать private. В видео репозиторий может быть public, потому что это демонстрационный кейс.
Проверка результата
Когда агент сгенерировал страницу, не надо сразу верить. Надо открыть, посмотреть, покликать, проверить мобильную версию, сравнить с задачей, найти несоответствия.
В ролике первый результат не идеален. И это нормально. Вайбкодинг - не про "один промпт и готово". Он про скорость итераций.
Первый результат надо смотреть глазами: агент может сделать рабочую, но не финальную версию
Хороший фидбек агенту звучит не так:
"плохо, переделай".
Лучше так:
"Сайт слишком generic, нет ощущения Nike-like motion, логотип не сделан, hero слабый, кнопки не похожи на premium retail, проверь мобильную версию, сохрани стек Next.js и Tailwind, не добавляй бэкенд".
AI лучше чинит, когда ты превращаешь вкус и раздражение в конкретные требования.
Деплой: локальный код, GitHub и Vercel
Деплой - это выкладка проекта в интернет.
В простом варианте путь такой:
локальный проект -> GitHub -> Vercel -> публичный URL.
Ты работаешь на своем компьютере. Код отправляется в GitHub. Vercel подключен к репозиторию, собирает проект и публикует сайт.
Схема деплоя из ролика: локальная код-база, GitHub и Vercel
Почему это важно для новичка: сайт, который работает только у тебя на ноутбуке, еще не продукт. Продукт начинается, когда другой человек может открыть ссылку.
И да, деплой часто ломается.
В видео Vercel не сразу распознал проект как Next.js. Это не катастрофа. Это нормальная часть работы. Есть лог, есть ошибка, есть агент, которому можно отдать контекст и попросить исправить.
Vercel не всегда автоматически угадывает проект: ошибки деплоя надо читать и чинить
Когда деплой готов, появляется публичная ссылка. Но это не конец. После деплоя почти всегда всплывает еще один косяк: логотип не там, текст не обновился, мобильная версия поехала, кнопка не работает.
Деплой готов: проект уже можно открыть как публичный сайт
Итерация после деплоя
Шестой шаг - итерация. Это то, что отличает "сгенерировал демку" от "довел до продукта".
В ролике после деплоя обнаруживается проблема с логотипом. Мы не начинаем заново. Мы даем агенту конкретную задачу, он правит локально, пушит в GitHub, Vercel подтягивает обновление.
Это и есть нормальный workflow:
- Поставил цель.
- Разложил по архитектуре.
- Сгенерировал код.
- Проверил.
- Задеплоил.
- Увидел косяк.
- Поправил.
- Повторил.
После деплоя агент исправляет проблему и снова отправляет изменения через GitHub в Vercel
Новичку важно принять: ошибки будут всегда. Вопрос не в том, как сделать идеально с первого раза. Вопрос в том, как быстро ты проходишь цикл ошибки.
Чеклист первого вайбкодинг-проекта
Если хочешь повторить путь из ролика, используй такой порядок.
- Сформулируй конкретную цель. Не "учусь", а "делаю страницу/форму/инструмент".
- Опиши пользователя и сценарий. Кто откроет, что увидит, что должен сделать.
- Выбери простой стек. Для международного фронтенда: Next.js, TypeScript, Tailwind, Vercel.
- Уточни, нужен ли бэкенд. Если можно обойтись без базы в первой версии, обойди.
- Открой проект в Cursor или другом IDE.
- Запусти AI-агента и дай ему задачу с ограничениями.
- Проверь локальный результат глазами.
- Создай GitHub-репозиторий.
- Отправь код в GitHub.
- Подключи Vercel и задеплой.
- Прочитай ошибки, если деплой упал.
- Отдай агенту логи и попроси исправить.
- Проверь публичный URL.
- Сделай первый итерационный фикс.
Это уже полноценный цикл разработки. Маленький, но настоящий.
Где чаще всего ошибается новичок
Первая ошибка - просить слишком широко. "Сделай приложение" почти всегда хуже, чем "сделай страницу заявки с тремя секциями, формой и деплоем на Vercel".
Вторая ошибка - не понимать, где находится проблема. Если не различать frontend, backend, database, API и deploy, любой баг выглядит одинаково.
Третья ошибка - принимать первый результат за финал. AI часто делает черновик. Твоя работа - отредактировать задачу, дать фидбек, проверить, повторить.
Четвертая ошибка - рано лезть в сложный бэкенд. Для первого проекта лучше довести простой фронтенд до публичной ссылки, чем неделю строить идеальную архитектуру и ничего не показать.
Пятая ошибка - игнорировать деплой. Пока проект не открыт по ссылке, он не прошел реальность.
Как это связано с курсом
Эта статья дает базовую карту. Ее достаточно, чтобы понять, куда смотреть и как собрать первый простой вайбкодинг-проект.
Но системный вайбкодинг - это шире:
- как выбирать инструменты под задачу;
- как ставить агентам задачи;
- как проверять код;
- как работать с бэкендом, платежами, auth и базами;
- как строить продуктовую архитектуру;
- как не получить одноразовый нейрослоп вместо поддерживаемого проекта.
Если хочешь пройти это не случайными кусками, а по системе, смотри курс по системному вайбкодингу. Если хочешь следить за рынком инструментов, подпишись на AI FOMO Fix. Если выбираешь модель или агента, начинай с бенчмарков и базы инструментов.
FAQ
Можно ли начать вайбкодить, если я вообще не программист?
Да. Но начинать надо не с "выучи все языки", а с маленькой цели, понятной IT-карты и простого стека. AI напишет большую часть кода, но ты должен понимать, что он делает на уровне блоков.
Нужно ли учить JavaScript перед первым проектом?
Не обязательно глубоко. Но полезно понимать, что JavaScript отвечает за поведение в вебе, TypeScript делает его строже, а Next.js помогает собирать современные сайты и приложения.
Что выбрать новичку: Cursor, Codex или Claude Code?
Для первого проекта удобнее интерфейс, где видно файлы, чат, терминал и результат. Cursor хорош как IDE. Codex удобен как агентный workflow. Claude Code хорош как терминальный агент. Выбор менее важен, чем умение ставить задачу и проверять результат.
Нужен ли бэкенд в первом проекте?
Не всегда. Если ты делаешь статичную страницу, можно обойтись без бэкенда. Если нужны пользователи, заявки, платежи, личный кабинет или хранение данных, бэкенд понадобится.
Почему Vercel?
Для международного Next.js-проекта Vercel - самый простой старт: он хорошо понимает Next.js, подключается к GitHub и быстро дает публичный URL. Для российских сценариев могут понадобиться другие облака и платежные решения.
Что делать, если AI сгенерировал плохой результат?
Не принимать как финал. Описать конкретные проблемы, дать агенту ограничения, приложить логи или скриншот, попросить исправить. Вайбкодинг - это итерационный процесс, а не один промпт.
Где смотреть исходное видео?
Видео-основа этой статьи: Программирование это новый Excel. Теперь программировать можешь даже ты.
Источники и следующие шаги
Куда идти дальше
Курс
Хочешь глубже?
На курсе по системному вайбкодингу — полный стек, архитектура, деплой и реальные проекты.
Посмотреть программу →