Быстрый AI-MVP оказался слишком быстрым

The Verge и Wired сейчас очень хорошо поймали момент: вайб кодинг перестал быть забавой для тех, кто любит по ночам собирать что-то из AI-ответов. Это уже массовый способ быстро дойти до работающего экрана, формы, прототипа. И в этом есть настоящая ценность. Честно. Иногда это единственный способ вообще сдвинуться с места.

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

Я это говорю без снобизма. Мы в Paladin Engineering регулярно видим такие истории. Кто-то приносит нам живой прототип и говорит почти с гордостью: “Смотрите, оно уже работает”. И это правда работает. Только потом мы начинаем разбирать, как именно оно работает, и выясняется, что продукт держится на честном слове, двух AI-сессиях и удачном стечении обстоятельств.

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

Но дальше приходит реальность. И она не особенно романтична.

Первое, что ломается, это граница между прототипом и продуктом. Пока приложением пользуется один человек, всё выглядит терпимо. Но как только туда попадает реальный пользователь, появляются вопросы, которых на этапе vibe coding никто не задавал. Что делать с невалидным вводом? Кто видит чужие данные? Что происходит, если API отвечает медленно? Где лежат токены? Можно ли вообще доверять тому, что было сгенерировано на ходу, если код никто толком не читал?

И вот тут многие делают странный вывод: “Ну ладно, значит, вайб кодинг не подходит”. Я бы так не сказал. Он подходит. Просто не на той стадии, на которой его обычно продают в соцсетях.

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

В Paladin Engineering мы часто видим один и тот же сценарий. Продукт собирается быстро. На вид он даже симпатичный. Но когда начинаешь смотреть глубже, там нет понятной модели доступа, нет нормального логирования, нет истории изменений, нет ясного ответа на вопрос, что будет при сбое. А иногда и сам автор уже не помнит, почему он выбрал именно такую структуру. Это не шутка. Через пару недель с такими проектами разговариваешь как с человеком, который всё сделал быстро и очень искренне хочет, чтобы прошлое больше не поднималось.

Я не считаю это провалом. Скорее, это взросление. Просто неприятно, что взросление всегда приходит в виде списка задач.

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

Если же вы идёте в публичный запуск, в деньги, в данные пользователей, в поддержку, в мобильные устройства, в интеграции с чужими системами, то нужен другой режим. Более скучный. Более медленный. Зато потом не приходится чинить “быстрый MVP” под давлением первых реальных пользователей.

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

И да, если продукт уже живой, у него появляется цена поддержки. Это тот момент, который чаще всего недооценивают. Сегодня кажется, что код “почти готов”. Завтра выясняется, что он завязан на зависимости, которые никто не проверял, на API, которые могут измениться, на сценарии, которые не были описаны, и на человеческую память, которая, как ни обидно, не вечная. Потом кто-то уходит в отпуск, кто-то меняет приоритеты, и вот у вас уже не свежий эксперимент, а маленький техдолг с красивой обёрткой.

Мы в Paladin Engineering обычно смотрим на такие вещи трезво. Не потому что не любим быстрые идеи. Наоборот. Быстрые идеи полезны. Но у них должен быть маршрут. Где прототип заканчивается, где начинается проверка, где включается ревью, где появляются роли и контроль. Без этого vibe coding легко превращается в очень дорогой способ быстро получить проблему, которую потом придётся разбирать руками.

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

Заключение: Вайб кодинг действительно помогает собрать первое живое тело продукта. Но дальше, как всегда, начинается инженерия. И чем раньше это признать, тем меньше будет боли потом.