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

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

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

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

• что человек делает в проекте;

• какой результат он получает;

• где сохраняется введенная информация;

• как проверить, что новая функция работает;

• как вернуться к рабочей версии, если изменение все сломало.

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

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

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

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

Интерфейс — то, что видит человек: поля, кнопки, сообщения, страницы. Его легко принять за весь продукт, потому что именно интерфейс агент показывает первым. Проверять его нужно действием. Поле принимает ожидаемый текст? После нажатия видно, что произошло? Ошибка объясняет, как ее исправить? Красивый макет без ответов на эти вопросы остается макетом.

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

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

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

Начните с описания данных. В учебном примере сущность одна: заявка. У нее есть текст и поле статуса с допустимыми значениями, а еще правила изменения этого поля. Тип базы можно выбирать после этого; агенту проще предложить подходящий вариант, когда известны данные и действия над ними.

Для рабочей версии стоит сохранить исходники, зависимости, настройки запуска и историю изменений. Тогда можно повторить известный способ запуска и сравнить новую версию с предыдущей. Репозиторий GitHub хранит файлы и коммиты проекта. Контейнер дает еще один способ зафиксировать окружение; в практическом руководстве Docker путь разделен на получение кода, сборку образа и запуск контейнера.

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

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

Для первой версии выберите одного пользователя и одно законченное действие. Запишите его так:

Пользователь делает [действие], проект сохраняет [данные] и показывает [проверяемый результат].

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

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

Подходящий первый проект отвечает четырем условиям:

1. Результат можно проверить самостоятельно за один сеанс: создать запись, обновить страницу, изменить ее и убедиться, что изменения сохранились.

2. Ошибка не причинит реального ущерба. Учебную версию не стоит начинать с приема платежей, медицинских рекомендаций или хранения документов клиентов.

3. Для работы не требуется десяток внешних сервисов. Каждая интеграция добавляет отдельные доступы, ограничения и способы отказа.

4. Вы понимаете предметную задачу. Если проект считает стоимость доставки, вы должны знать правила расчета и примеры правильного ответа.

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

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

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

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

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

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

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

Для формы недостаточно увидеть новую кнопку. Пройдите заранее записанные случаи:

• отправьте оба заполненных поля и найдите заявку в списке;

• обновите страницу и проверьте, что запись осталась;

• оставьте одно поле пустым и прочитайте сообщение;

• измените статус, перезапустите проект и снова найдите заявку.

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

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

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

Такой цикл требует больше действий, чем один длинный запрос, зато каждое действие можно принять или отклонить. Если самостоятельный проект уперся в переход от разовой генерации к повторяемому процессу, на курсе «Вайбкодинг на максималках» можно пройти связанный маршрут на собственном проекте: в программе есть Git и GitHub, работа с Codex, Docker, база данных, деплой и защита секретов.

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

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

1. Посетитель открывает форму и отправляет заполненные поля.

2. Пустое обязательное поле вызывает понятное сообщение.

3. Владелец видит новую заявку в списке.

4. Он меняет статус, обновляет страницу и видит сохраненное значение.

5. Проект запускается по записанной инструкции из чистого состояния.

6. Последняя принятая версия сохранена отдельным коммитом.

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

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

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

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

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