Что такое вайбкодинг и почему одного промпта недостаточно

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

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

Она не исчезла. Она просто стала менее заметной.

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

ИИ-агенты уже умеют искать по проекту, менять файлы и запускать команды. Некоторые могут сами пройти несколько шагов и попытаться исправить ошибку. Это видно в официальных описаниях Codex и Cursor Agent.

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

1. Человек описывает небольшое изменение и критерий готовности.

2. ИИ изучает контекст и предлагает план или правку.

3. Проект запускается.

4. Результат проверяется по сценарию, а не только глазами.

5. Ошибка превращается в новый конкретный вход: лог, скриншот, неуспешный тест.

6. Рабочая версия сохраняется, и начинается следующая итерация.

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

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

Здесь человек не пишет код, но управляет проверкой. Он решает, какое поведение считать правильным, предоставляет факты об ошибке и не принимает зелёный экран за доказательство.

После успешной итерации нужна контрольная точка. Git как раз хранит историю изменений и позволяет вернуть прежнее состояние файлов. Для вайбкодинга это не факультативная сложность, а способ безопасно экспериментировать: неудачная генерация перестаёт быть катастрофой, если рабочая версия сохранена. Git: About Version Control.

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

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

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

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

ИИ может предложить функции, но не знает, какая из них докажет ценность идеи. Человек решает, что входит в первую версию, а что пока мешает её закончить.

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

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

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

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

Если агент сам запускает команды, это ускоряет поиск. Но человек всё равно определяет, исправлена ли исходная проблема, а не только исчезло ли красное сообщение.

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

Для веб-проекта хотя бы отдельно проверьте секреты, доступ к данным и передачу учётной информации. OWASP рассматривает управление секретами и тестирование веб-безопасности как самостоятельные практики, а не финальную косметическую проверку. Secrets Management Cheat Sheet, Web Security Testing Guide.

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

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

Чем конкретнее критерий, тем меньше приходится доверять уверенной формулировке агента.

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

Файлы и части проекта. Где находится интерфейс, где серверная логика, где настройки. Иначе вы не сможете проверить, что именно изменил агент.

Клиент и сервер. Код в браузере показывает экран и отправляет запросы. Сервер обрабатывает данные и обращается к базе или внешним сервисам. Это различие помогает понять, почему зелёное сообщение на форме ещё не доказывает доставку заявки.

База данных. Какие сущности вы храните, как они связаны и кто имеет к ним доступ. Не нужно сразу проектировать сложную схему, но каждое поле должно иметь понятную причину.

Логи и ошибки. Где посмотреть фактическое сообщение о сбое и как повторить проблему. Лог полезнее предположения «наверное, модель что-то сломала».

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

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

Это не сокращённый курс профессии разработчика. Это карта проекта, без которой трудно ставить задачи ИИ и проверять ответы.

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

Подходящий проект:

• нужен лично вам или понятному пользователю;

• имеет один основной сценарий;

• не обрабатывает платежи, медицинские сведения и другие данные с высокой ценой ошибки;

• допускает ручную проверку результата;

• может быть выброшен или переделан без серьёзных последствий.

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

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

На курсе «Вайбкодинг на максималках» этот минимум проходит через практический проект: устройство разработки, Codex и VS Code, Git, ошибки, база данных, сервер и деплой. Цель такого маршрута не в том, чтобы писать весь код вручную, а в том, чтобы довести свою идею до работающей версии и понимать, как развивать её дальше.

Есть три простых признака:

1. Вы можете объяснить, что должно произойти, не перечисляя детали интерфейса.

2. При ошибке вы знаете, где искать факты: в браузере, журнале сервера, базе или тесте.

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

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