Почему новичку опаснее верить в вайб-кодинг, чем инженеру

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

Инженер, даже когда ленится и делегирует, чувствует, где у него нет контроля. Он видит странный код, замечает дубли, понимает, что логика собрана криво. У него остаётся внутренний стоп-сигнал. Даже если он не сразу чинит, он хотя бы видит, что происходит что-то не то.

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

Отсюда появляется главная ловушка. Результат есть, картины системы нет. Бот запускается, публикует, интерфейс кликается. Снаружи это выглядит как продукт. Внутри это набор совпадений, которые пока не развалились.

Я это поймал на своём боте. Он открывал страницу, подставлял промпт, генерировал результат и публиковал. На первых тестах всё выглядело как готовая система. В этот момент очень легко сказать себе “всё, работает” и идти дальше.

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

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

Пришлось возвращать ручное вмешательство. Бот останавливается, сигналит, ждёт. Я правлю промпт и запускаю дальше. Параллельно начинаю разбирать, что именно уходит в запрос и что приходит в ответ. В итоге нашёл конкретный триггер. В моём случае это было словосочетание “грубый контур”. После его удаления проблема исчезла.

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

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

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

Если ты хочешь идти дальше прототипа, придётся делать неприятную вещь. Разбираться, что именно ты собрал. Не на уровне “работает или нет”, а на уровне “почему работает, где держится на случайности и в каком месте может развалиться”. Без этого любой следующий шаг будет строиться на тех же совпадениях.

Вайб-кодинг снижает порог входа, но не отменяет инженерную базу. Он просто позволяет отложить её на потом. Проблема в том, что это “потом” всегда приходит.