Вайбкодинг без хаоса: 9 шагов от идеи до работающего приложения

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

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

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

Это маршрут, который можно повторить даже без опыта разработки.

Шаг 1. Выберите маленький результат

Не начинайте с команды "сделай мне CRM".

Возьмите результат, который можно проверить глазами.

Плохо:

Сделай CRM для отдела продаж с аналитикой, пользователями, Telegram, платежами и ИИ.

Лучше:

Сделай страницу со списком лидов. У каждого лида есть имя, компания, статус и комментарий. Лида можно добавить и поменять ему статус. Пока без авторизации, Telegram и базы данных.

Для первого проекта подходят:

• калькулятор;
• каталог;
• форма заявки;
• небольшой внутренний кабинет;
• дашборд на тестовых данных;
• генератор документа;
• простой поиск по таблице;
• лендинг с интерактивным блоком.

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

Шаг 2. Напишите мини-ТЗ на одну страницу

Агент для кода понимает обычный язык. Но обычный язык всё равно должен содержать границы.

Скопируйте шаблон:

ЦЕЛЬ
Что должно работать в конце.

ПОЛЬЗОВАТЕЛЬ
Кто этим пользуется и что он хочет сделать.

ВХОДНЫЕ ДАННЫЕ
Что уже есть: таблица, API, файлы, тексты, макет.

НУЖНО СДЕЛАТЬ
3–7 конкретных функций.

ПОКА НЕ ДЕЛАТЬ
Что сознательно исключаем из первой версии.

ОГРАНИЧЕНИЯ
Например: мобильная версия, русский язык, без авторизации.

ПРИЁМКА
Как я сам проверю, что задача сделана.

СТОП
Не добавлять новые функции без отдельной команды.

Последняя строка полезна именно потому, что агент умеет делать много и легко начинает "улучшать" проект за пределами задачи.

Рабочий цикл в одном экране

Нормальный ритм вайбкодинга: мини-ТЗ, первая рабочая версия, проверка, точка возврата, одна следующая правка, повторная проверка и предварительная публикация.

Перескакивать сразу к последнему пункту не нужно.

Шаг 3. Выберите среду

Есть два нормальных входа.

Без терминала

Если хочется сразу работать в браузере, подойдут Lovable или Replit Agent. Вы описываете приложение, получаете предварительную версию и продолжаете правками через диалог.

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

С репозиторием

Если проект должен жить дольше прототипа, смотрите в сторону Cursor, Claude Code или Codex и обычного Git-репозитория.

Cursor Agent умеет читать проект, редактировать файлы и запускать команды в терминале. Claude Code работает с кодовой базой, файлами, командами и Git. Codex рассчитан на задачи с кодом, репозиториями, списками изменений и проверками.

Не нужно ставить всё сразу. Выберите один основной агент.

Шаг 4. Получите скелет и меняйте по одной вещи

Первый запрос не должен строить весь бизнес.

Пример для внутреннего списка заявок:

Создай простое веб-приложение для списка входящих заявок.

Нужно:
- таблица с полями Имя, Компания, Телефон, Статус, Комментарий;
- кнопка "Добавить заявку";
- статусы: Новая, В работе, Закрыта;
- фильтр по статусу;
- адаптация под телефон.

Пока:
- без регистрации;
- без реальной базы;
- без Telegram;
- без CRM;
- используй тестовые данные.

Перед реализацией составь короткий план.
Реализуй только эту версию.
В конце запусти приложение и перечисли, что я должен проверить вручную.

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

Плохо:

Переделай дизайн, добавь авторизацию, подключи Telegram, сделай импорт таблицы и ещё почему-то медленно открывается таблица.

Лучше:

Добавь импорт CSV. Остальные функции не меняй. После изменения проверь добавление заявки, смену статуса и фильтр.

Одна итерация решает одну цель. Иначе после поломки непонятно, какая правка её вызвала.

Шаг 5. Включите историю версий

После первой рабочей версии подключите Git.

Git здесь нужен не для собеседования на разработчика. Это точка возврата.

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

Для более рискованной функции используйте отдельную ветку. В GitHub ветка изолирует изменения до того, как вы решите объединить их с основной версией. Список изменений показывает, что агент поменял на самом деле.

Новичку достаточно понимать три вещи:

• коммит — сохранённая точка проекта;
• ветка — отдельный маршрут изменений;
• список изменений — разница между версиями.

Шаг 6. Просите не уверенность, а доказательство

Не спрашивайте:

Всё работает?

Дайте проверяемую инструкцию:

Запусти приложение.
Запусти доступные тесты и сборку.
Проверь ошибки в терминале.
Перечисли, что проверено автоматически.
Отдельно перечисли, что я должен проверить руками.
Не утверждай, что всё работает, если какой-то пункт не проверялся.

Хороший отчёт после изменения выглядит не как "готово", а примерно так:

Сборка: PASS
Тесты: PASS
Ошибки линтера: 0

Проверить вручную:
1. Добавить заявку.
2. Сменить статус.
3. Перезагрузить страницу.
4. Открыть с телефона.

Количество тестов зависит от проекта. Смысл не в цифре, а в проверяемом результате.

Шаг 7. При ошибке остановите новые функции

Типичная петля выглядит так:

1. добавили функцию;
2. что-то сломалось;
3. попросили ИИ заодно исправить и улучшить дизайн;
4. стало хуже;
5. дали огромный запрос со всей историей.

При появлении дефекта развитие лучше заморозить.

Дайте отдельную задачу:

СТОП новых функций.

Проблема:
после нажатия "Сохранить" новая заявка исчезает после обновления страницы.

Нужно:
1. воспроизвести ошибку;
2. найти причину;
3. объяснить её кратко;
4. исправить минимальным изменением;
5. повторить проверку.

Не делать рефакторинг соседнего кода.

Верните рабочее состояние и только потом продолжайте развитие.

Когда надо перестать промптить и начать диагностировать

Есть несколько красных флагов:

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

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

Шаг 8. Уберите секреты из исходного кода

Как только появляются реальные API, база данных, почта или платёжная система, появляется новая граница.

Пароли, API-ключи и токены не должны лежать в публичном репозитории или в клиентском коде.

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

Перед использованием ключа спросите агента:

Где будет храниться этот секрет? Может ли пользователь браузера его увидеть? Попадёт ли он в Git или результат сборки?

Шаг 9. Проверьте предварительную версию до публикации

До рабочей публикации сделайте отдельную предварительную версию.

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

Перед публикацией пройдите ручной чек:

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

Только после этого выпускайте рабочую версию.

Какой набор инструментов нужен на старте

Не ищите "лучший ИИ для программирования". Выберите инструмент под способ работы.

Lovable / Replit Agent подходят, если хочется начать в браузере и быстро увидеть интерфейс.

Cursor удобен, когда нужен привычный редактор и агент, который работает с файлами и командами проекта.

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

Codex полезен для делегирования задач с кодом, репозиториями, изменениями и проверками.

GitHub хранит историю версий, ветки и запросы на слияние.

Vercel даёт предварительную и рабочую публикацию веб-проекта.

Один агент, один репозиторий и один способ публикации — нормальный стартовый набор.

Три промпта, которые стоит сохранить

Перед новой функцией

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

После изменения

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

Когда всё начало разваливаться

СТОП новых функций.

Определи последнее состояние, где проект работал.
Покажи текущий список изменений.
Найди минимальную причину проблемы.
Предложи минимальный фикс.
После исправления повтори проверку.

Где заканчивается вайбкодинг и начинается система

Для первого калькулятора или прототипа одного агента для кода часто достаточно.

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

Тогда проблема уже не только в том, умеет ли модель написать код. Нужен контур вокруг модели.

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

Если оставить одно правило

Не пытайтесь получить весь продукт одним промптом.

Получите маленькую рабочую версию. Зафиксируйте её. Дайте одну следующую задачу. Попросите доказательство. Зафиксируйте снова.

Так вайбкодинг перестаёт быть серией эффектных демо и становится способом собирать рабочие инструменты.