Вайб-кодинг работает только там, где ты можешь проверить результат

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

Очень часто задача вообще формулируется не как задача, а как ощущение.

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

Раньше это быстро вскрывалось. Ты упирался в ограничения и был вынужден остановиться. Нужно было понять, как это устроено, иначе просто не двигался дальше. Задача уточнялась до реализации.

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

На самом деле ты получил не решение, а интерпретацию.

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

Вайб-кодинг отлично работает, пока есть чёткий критерий. В таких задачах всё просто:

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

Но как только критерий размывается, начинается другая история. “Сделай удобно”, “сделай нормально”, “пусть пользователю будет понятно”. Формально результат есть. Страница открывается. Кнопки работают. Но проверить качество такого результата уже сложнее. Нельзя просто прогнать тест и получить ответ.

Есть хороший пример из обсуждений вокруг Software 3.0. Разработчик делает приложение для визуализации меню: OCR, генерация изображений, сборка интерфейса. Полноценный продукт. Через время ту же задачу решают одной строкой в модели: загрузил фото, написал промпт, получил результат. Приложение становится лишним.

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

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

Отсюда и проходит реальная граница. Не между “есть код” и “нет кода”. А между тем, можно ли однозначно проверить результат или нет.

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

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