Ограничения вайбкодинга: где он перестаёт работать

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

Это не значит, что инструмент плохой. Это значит, что задача вышла за пределы того, что можно надёжно сделать, не понимая кода. Ниже — пять мест, где это происходит чаще всего, и признаки, по которым видно, что ты уже там.

Сложное состояние

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

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

Безопасность

ИИ оптимизирует «чтобы заработало». Проверка прав, валидация на сервере, лимиты на запросы — всё это не нужно, чтобы заработало, поэтому этого часто нет.

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

Нагрузка и данные

На десяти тестовых записях любой запрос быстрый. На ста тысячах выясняется, что страница списка грузит всю таблицу целиком, а для каждой строки ходит в базу ещё раз. Индексов нет, потому что их никто не просил.

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

Интеграции

Платёжные системы, CRM, почта, склад, сторонние API. У каждой интеграции есть подробности, которых не видно в примере из документации: повторные вебхуки, ограничения частоты, таймауты, изменения версий, разные форматы ошибок.

ИИ пишет «счастливый путь» — запрос ушёл, ответ пришёл. Что делать, если ответ не пришёл, пришёл дважды или пришёл через минуту, обычно не описано. Пока внешняя система ведёт себя хорошо, этого не видно. Первый сбой у партнёра — и данные расходятся, а где именно, никто не знает.

Поддержка

Самое тихое ограничение. Проект работает, но:

никто не может объяснить, как он устроен;
одно и то же сделано в нескольких местах по-разному;
библиотеки устарели, а обновление ломает всё сразу;
тестов нет, и единственный способ проверить правку — пройти всё руками.

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

Признаки, что ты упёрся в стену

Правка в одном месте регулярно ломает что-то в другом.
ИИ «чинит» ошибку, она возвращается в другом виде через пару дней.
Одну и ту же проблему ты описываешь уже в третьем разговоре.
Ты боишься трогать какие-то части приложения.
Пользователи сообщают об ошибках, которые ты не можешь воспроизвести.
Счёт за хостинг или API растёт быстрее, чем число пользователей.
Ты не можешь ответить на вопрос «видит ли пользователь А данные пользователя Б».

Если совпало два-три пункта, дело не в промптах. Проект перерос способ, которым его делают.

Что делать дальше

Варианты не исключают друг друга.

Сузить зону вайбкодинга. Продолжай генерировать интерфейс и типовые экраны, а оплату, права доступа и интеграции отдай человеку, который читает код.

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

Остановиться и посчитать. Иногда честный ответ — переписать ядро, оставив интерфейс. Решать это стоит по фактам, а не от усталости.

Коротко

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

SUBXCAT как раз работает на этой границе: помогаем понять, что в проекте можно оставить, а что пора переделать.