Ваш проект может снова двигаться.

Что такое вайбкодинг

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

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

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

Где ломается

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

На второй-третьей неделе сервис начинает разваливаться от фич. Человек продолжает просить новые функции, но не видит корневой смысл продукта: какую задачу он решает, какой сценарий главный, какие куски можно не делать. В итоге прототип растёт в стороны, а не к запуску.

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

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

Деплой пугает сильнее, чем код. Надо купить сервер, домен, настроить доступы, окружение, логи, HTTPS, переменные, базу, обновления. Из-за этого люди откладывают запуск: локально что-то шевелится, а наружу выпускать страшно. Типовая ошибка — думать, что Codex надо поставить на сервер, чтобы он мог им управлять. Codex — это агент для работы с кодом из командной строки: его не обязательно ставить на боевой сервер, можно дать доступ, и он зайдёт туда с вашего компьютера.

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

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

Правила, которые экономят недели

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

Написать — дни, отладить — недели, соотношение примерно один к семи. Функция пишется за 1–3 дня и доводится до рабочего состояния за 2–3 недели. Срок и цену считают по второй части, а не по первой.

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

Лучший новый компонент — это отсутствие компонента. Прежде чем строить, заполни фразу «___ сам ___, без ___»: назови, что уже работает и делает половину задачи.

Больше 20 файлов — сигнал упростить фичу. Задели больше двадцати — остановись и спроси, можно ли упростить.

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

Сколько это стоит времени

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

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

Больше всего времени съедают не сами экраны, а повторы:

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

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

Пример: если сервису нужен автопостинг в соцсети, не всегда надо писать свой автопостинг. Иногда дешевле заплатить 20–50 долларов за готовый инструмент и проверить идею. Свой модуль имеет смысл делать позже, когда идея уже приносит деньги и этот расход правда стоит оптимизировать.