Когда вайбкодинг не подходит: проекты, где разработка с помощью ИИ создаёт больше рисков, чем пользы

Вопрос не в том, использует ли команда ИИ

Вайбкодинг становится плохим выбором не тогда, когда в проекте есть ИИ. Риск появляется, когда результат нельзя нормально проверить, ошибку трудно откатить, а у команды нет человека, который отвечает за архитектуру и последствия запуска.

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

1. Ошибка сразу затрагивает деньги

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

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

2. Данные нельзя потерять или раскрыть

Медицинские, финансовые, персональные и коммерчески чувствительные данные требуют ограниченного доступа, журналов, безопасного хранения и понятного срока удаления. Ошибка в фильтре или разрешениях иногда раскрывает данные не тому пользователю.

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

3. Продукт должен работать без остановки

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

ИИ-агент может помочь подготовить конфигурацию или диагностировать ошибку. Он не заменяет дежурство, ответственность за инфраструктуру и решение о том, когда безопасно менять рабочую систему.

4. Ошибку трудно откатить

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

Если проект нельзя безопасно остановить или восстановить, скорость генерации кода перестаёт быть главным преимуществом.

5. Требования неясны и часто меняются

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

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

6. Нужна сложная предметная экспертиза

В регулируемых областях важны не только функции. Есть требования к хранению данных, журналированию, доступам, документированию и проверяемости решений. Универсальный ответ агента не является доказательством соответствия правилам.

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

7. Нет владельца результата

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

До начала проекта назовите человека, который утверждает критерии, принимает риски, контролирует доступы и решает, что попадает в Production.

Матрица решения

Условие	Что делать
Ограниченный сценарий, низкая цена ошибки, понятная приёмка	Можно начать с вайбкодинга и коротких этапов проверки
Есть роли, данные, внешние интеграции или постоянная работа	Нужны технический план, ревью и отдельная проверка безопасности
Есть деньги, критичные данные, необратимые операции или высокая ответственность	Нужен опытный инженер; ИИ остаётся инструментом внутри контролируемого процесса

Как использовать ИИ там, где полный вайбкодинг не подходит

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

Если уже есть готовый проект, начните с диагностики и небольшого безопасного улучшения. На странице доработки проекта задачу можно описать через текущую проблему и критерий результата. Для нового продукта заранее зафиксируйте ограничения в заявке на разработку.

Итог

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