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

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

Published: 2025-08-21 · Source: https://subxcat.com/ru/articles/vibe-coding-limits · Author: SUBXCAT

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

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

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

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

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

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

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

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

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

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

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

## Интеграции

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

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

## Поддержка

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

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

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

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

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

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

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

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

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

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

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

## Коротко

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

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