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

Если непонятно, о чём вообще речь, сначала посмотрите что такое вайбкодинг и как выглядит его рабочий цикл. Здесь — практика.

Что нужно до первого запуска

Три вещи. Больше на старте не нужно ничего.

1. Место, куда сложить проект

Отдельная папка, а не «Рабочий стол». Внутри — сразу git:

mkdir my-first-project
cd my-first-project
git init
git commit --allow-empty -m "старт"

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

2. Инструмент

На старте достаточно одного. Выбор зависит от того, что вы делаете: браузерный конструктор, редактор с агентом или CLI-агент в терминале. Различия и условия доступа разобраны в обзоре инструментов. Для первого проекта берите тот, который запускается быстрее всего — менять инструмент потом дешевле, чем неделю выбирать.

3. Место для секретов — вне проекта

Ключи API, пароли, токены не должны лежать в папке проекта. Агент читает файлы целиком и может процитировать любой из них — в ответе, в коммите, в логе. Заведите отдельный файл вне репозитория или переменные окружения и с первого дня добавьте в .gitignore:

.env
.env.local
*.key
secrets/

Какой проект брать первым

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

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

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

Как сформулировать задачу

Формулировка задачи — единственное, чем вы управляете напрямую. Разница видна сразу.

Плохо: «сделай форму обратной связи».

Хорошо: «Форма из трёх полей: имя, email, сообщение. Пустой email — красная подпись под полем, отправка не уходит. Успех — форма очищается и показывает „Отправлено“. Данные уходят POST-запросом на /api/feedback в формате JSON. Внешних библиотек не подключай.»

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

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

Пять контрольных точек

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

  1. Что изменилось. git status и git diff перед тем, как соглашаться. Если агент тронул файлы, о которых речи не было, — это повод остановиться, а не «наверное, так надо».
  2. Что добавилось в зависимости. Новый пакет в проекте — это чужой код, который будет исполняться. Спросите, зачем он, и погуглите название: подделки под популярные пакеты — рабочий способ атаки.
  3. Где лежат секреты. Поиск по проекту на key, token, password, secret. Ключ, случайно вписанный в исходник, уезжает в историю git навсегда.
  4. Что происходит при неправильном вводе. Пустое поле, очень длинная строка, буквы вместо числа, кавычка в тексте. Модель по умолчанию пишет счастливый сценарий.
  5. Запускается ли это с нуля. Склонируйте проект в чистую папку и запустите. Половина «работает» держится на файле, который есть только у вас.

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

Ошибки первой недели

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

Что делать дальше

После первого проекта развилка обычно такая: