5 признаков, что vibe-coded проект не переживёт первого клиента

Проверка занимает около пятнадцати минут и не требует терминала. Достаточно доступа к панели проекта и честных ответов на пять вопросов. Если хотя бы два пункта «плохие» — это не повод паниковать, это повод потратить три-пять дней на фундамент до того, как придут реальные пользователи.

1. Где физически лежит база данных

Откройте дерево файлов проекта. Если вы видите там app.db, data.sqlite, database.json или папку /data рядом с src — это первый признак.

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

Как должно быть. База — отдельный сервис (managed Postgres/MySQL или хотя бы отдельный сервер с отдельными доступами и постоянным томом). Код знает только строку подключения из переменной окружения.

2. Есть ли история версий, которую можно откатить

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

Почему это опасно. Без Git откат невозможен. Каждая правка — окончательная. Классический сценарий: «попросил добавить кнопку, ИИ заодно отрефакторил авторизацию, теперь никто не может войти». Откатиться некуда, а исходный код уже перезаписан.

Как должно быть. Приватный репозиторий, осмысленные коммиты, тег или ветка на каждый релиз. Откат = вернуть предыдущий тег и задеплоить его.

3. Что произойдёт, если сервер перезапустится прямо сейчас

Самая недооценённая проверка. Задайте себе три вопроса: переживёт ли база перезапуск; останутся ли загруженные файлы (аватары, документы); поднимется ли приложение само или его надо «запустить руками из чата с ИИ».

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

Как должно быть. Всё состояние — в постоянном хранилище. Приложение стартует автоматически (systemd, docker restart policy, платформенный автозапуск) и само поднимается после падения.

4. Где лежат ключи и пароли

Поищите в проекте строки вида sk_live_, AKIA, postgres:// с паролем, password=. Если они в файлах, попадающих в репозиторий, — это четвёртый признак. Отдельно проверьте, нет ли ключей в клиентском бандле: откройте собранный сайт, загляните в исходники страницы.

Почему это опасно. Публичный репозиторий сканируется ботами круглосуточно. Утёкший ключ облака — это чужие инстансы на вашем счёте; утёкший ключ платежей — это чужие возвраты и списания; пароль от базы в коде — это доступ к данным клиентов.

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

5. Как вы выкатываете изменения в продакшен

Честный ответ большинства: «прошу ИИ поправить прямо на боевом сервере» или «нажимаю кнопку Redeploy и надеюсь». Если так — это пятый признак.

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

Как должно быть. Минимум два окружения: staging, где можно ломать всё, и production. Выкладка — одна команда или один коммит, откат — тоже одна. Правки от ИИ проходят тот же путь, что и от человека: ветка, проверка, деплой.

Что делать, если насчитали три и больше

Порядок важен, и он не совпадает с порядком списка:

1. Бэкапы. Даже кривые, даже ручные, даже раз в день — но появляются сегодня. Это единственное, что нельзя купить задним числом.
2. Git. Залить текущий код как есть, одним коммитом. Потом начать коммитить изменения.
3. Ключи. Ротация всего, что могло утечь, вынос в переменные окружения.
4. Вынос базы. Самый трудоёмкий шаг, но после бэкапов и Git он уже безопасен.
5. Staging и деплой. Настраивается последним, потому что без первых четырёх он только добавит уверенности без безопасности.

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

Читайте также: ИИ удалил базу данных: что делать в первые часы