Вчера я пришел к модели со словами: «Мне нужен сервис, который будет мониторить несколько показателей. Давай подумаем, как его сделать». Двадцать минут мы обсуждали архитектуру будущего сервиса, ограничения и риски. Где-то в середине этого разговора я спохватился и сделал шаг назад: «А как еще можно решить мою задачу?». Ответ пришел сразу, ведь уже есть готовое решение, а настроить в нем нужно всего два поля. Сервис, который мы так увлеченно проектировали, оказался не нужен. В статье я, Михаил Беляев, руководитель образовательных программ в «Битрикс24», разберу наиболее распространенные ошибки и поделюсь опытом, как их избегать.
Магия нового доступа
Для человека, который никогда не программировал, вайб-кодинг — эмоциональный опыт. Впервые идею можно не придумать и отдать разработчикам, а сразу собрать самому. Это может быть что угодно: от приложения до сервиса или инструмента под свою задачу. Идея перестает зависеть от бюджета, очереди задач и отдела ИТ.
Термин «вайб-кодинг» предложил Андрей Карпатый в феврале 2025 года, а уже в ноябре словарь Collins объявил vibe coding словом года. При этом, по оценке Axis Intelligence, 63% пользователей вайб-кодинг-платформ не разработчики, а продакт-менеджеры, основатели, маркетологи, дизайнеры. Возможность, которая десятилетиями была закрыта техническим барьером, открылась каждому.
Петля возможностей
У новой свободы есть обратная сторона, и я для себя называю ее «петлей возможностей». Это ситуация, когда техническая возможность настолько соблазнительна, что человек начинает строить решение раньше, чем понял задачу.
У человека появляется проблема или идея. Он идет к ИИ с просьбой «сделай мне сервис» вместо вопроса «как это лучше решить». Модель подтверждает реализуемость и начинает помогать. Появляются первые результаты, а с ними чувство магии и прогресса. Человек вкладывает еще больше времени. В конце выясняется, что задача решалась таблицей, формой, готовым сервисом, регламентом или изменением процесса.
Главная опасность в том, что ИИ слишком хорошо помогает двигаться в выбранном направлении — даже если направление выбрано преждевременно.
Обе половины петли давно изучены, просто раньше они не встречались в одной точке. Первую инженерная культура знает под именем XY problem — человек приходит с вопросом о своей попытке решения, а не о самой задаче. Проблема описана еще в девяностые, и у нее был встроенный ограничитель — опытный разработчик на форуме, который вместо ответа спрашивал «А зачем тебе это?». Модель же так не делает, она обучена поддерживать направление пользователя и охотно берет в работу любую задачу.
Вторая половина известна психологии как эскалация вовлеченности. Полвека исследований о том, как уже вложенные усилия заставляют продолжать сомнительный курс. Чем больше вложено, тем труднее остановиться. ИИ добавил сюда скорость, ведь чувство прогресса — главное топливо эскалации — он вырабатывает быстрее любой прежней технологии. Каждые несколько минут ты совершенствуешь результат.
Задача, подмененная решением
Главная ошибка совершается до первого промпта — в момент, когда задача формулируется с готовым решением внутри. Сравните: «Мне нужен сервис для автоматического подбора материалов» и «Мне нужно быстрее находить подходящие материалы и меньше ошибаться при выборе».
Первая формулировка оставляет модели один путь — проектировать сервис. Вторая сохраняет пространство вариантов: база знаний, таблица, шаблоны, готовый поиск, регламент, обучение сотрудников, и лишь в конце этого списка собственная разработка.
Когда человек говорит ИИ «сделай мне приложение», он часто уже совершил главную ошибку — подменил задачу решением.
Инженерная пауза
Защита от петли — не программистские знания, а привычка, которую я называю инженерной паузой. Ключевая компетенция здесь — постановка задачи.
Шаг первый — сформулировать задачу без решения
Запретите себе слова «сервис», «бот», «приложение», «сайт» в первой фразе. Вместо них ответьте на три вопроса: что должно измениться, для кого и как я пойму, что получилось.
Шаг второй — позвать модель оппонентом, а не исполнителем
Прямая инструкция работает: «Не предлагай решение. Задай мне вопросы, на которые у меня нет ответов». Насколько это востребовано, показывает история скилла /grill-me («прожарь меня») разработчика Мэтта Покока. Инструмент запрещает модели писать код, пока она не задаст автору полтора-два десятка, а иногда и полсотни уточняющих вопросов о задаче.
Репозиторий со скиллом собрал 74,5 тысячи звезд на GitHub. В эпоху, когда вся индустрия продает скорость, вирусным стал инструмент, добавляющий трение. Люди знают за собой склонность сразу бежать строить и сами ставят себе тормоз.
Шаг третий — пройти лестницу решений снизу вверх
Ничего не строить, а изменить процесс, написать инструкцию, завести таблицу или форму. После взять готовый сервис, настроить существующий инструмент, и только на верхней ступени — свой код. Попросите модель пройти лестницу с нижней ступени и обосновать каждый переход выше. Мой вчерашний кейс закончился двумя настройками готового решения — до верхней ступени мы не дошли, и это лучший исход.
Семь раз отмерь, один сгенерируй
Ничто из сказанного не отменяет того, что вайб-кодинг способен приносить бизнесу реальную пользу. Он сокращает дистанцию от идеи до работающей вещи настолько, что спорить с этим бессмысленно, и усиливает одного человека без команды и без опыта разработки. Прототип, мокап, быстрый эксперимент, который можно пощелкать и показать коллегам, теперь создается за вечер.
Но чем мощнее инструмент, тем дороже обходится неумение им пользоваться. Умение здесь не в промптах. Часть задач решается проще, вообще без кода, и выясняется это за пару вопросов до старта. А задачи, которые честно требуют кода, без паузы на «отмерь» придется переделывать: прототип, собранный до понимания задачи, оказывается не ускорением, а обходным путем к тому же пониманию — только дольше. Строить, чтобы разобраться, — легитимный инженерный ход, если у постройки есть статус эксперимента и право умереть. Петля начинается там, где эксперимент незаметно становится продуктом.
Зрелое использование вайб-кодинга начинается не с просьбы «Сделай мне приложение», а с вопроса «Помоги понять, нужно ли мне приложение?». Старая пословица не устарела — у нее просто обновился последний глагол. Семь раз отмерь, один сгенерируй.