Почему вайб-код ломается и как этого избежать: 10 правил

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

Мы в Emaya каждый день пишем код с Claude Code и регулярно чиним чужие проекты из Cursor, Lovable и Bolt. Правила ниже — выжимка из обоих опытов.

Почему это происходит

ИИ отлично решает задачу, которую видит прямо сейчас. Но он не помнит, почему три недели назад вы договорились хранить даты в определённом формате, и не знает, что на сервере стоит другая версия Node.js. Каждая правка — небольшой риск. Без страховки риски копятся, и однажды проект падает.

10 правил

1. Git с первого дня

Без истории версий любая неудачная правка необратима. Попросите ИИ настроить git сразу:

Инициализируй git, добавь .gitignore для этого стека
(node_modules, .env, логи, загруженные файлы) и сделай
первый коммит. Дальше после каждой рабочей фичи
предлагай коммит.

И храните копию репозитория не только на ноутбуке — в приватном репозитории GitHub или GitLab.

2. Маленькие шаги

Одна фича — одна сессия — один коммит. «Переделай весь интерфейс и заодно добавь оплату» почти гарантированно сломает что-то третье.

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

3. Сначала план, потом код

Для любой задачи сложнее одной кнопки — режим планирования или просьба «составь план, ничего не меняй». Прочитать план за 2 минуты дешевле, чем разбирать последствия час.

4. Тесты на то, что важно для денег

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

Напиши автотесты для функции расчёта стоимости:
обычные значения, ноль, пустое поле, очень большая
площадь, скидка 100%. Запусти и покажи результат.
После каждой будущей правки запускай их.

5. Секреты только в .env

Токены Битрикс24, ключи OpenAI, пароли от базы — никогда в коде и никогда в репозитории. Особенно опасно, когда ключ попадает во фронтенд: его видит любой посетитель сайта.

Проверь весь проект на наличие ключей, токенов и паролей
в коде, включая историю git. Вынеси их в .env, добавь
.env.example без значений. Перечисли, какие ключи надо
перевыпустить, потому что они уже были в репозитории.

Если ключ хоть раз попал в публичный репозиторий — считайте его скомпрометированным и перевыпустите. Подробнее — в статье о безопасности работы с ИИ.

6. Одинаковое окружение локально и на сервере

«На ноутбуке работает, на сервере — нет» — самая частая жалоба. Зафиксируйте версии: Node.js или Python, базы данных, зависимостей (lock-файл обязателен). Опишите запуск в README или CLAUDE.md так, чтобы его можно было повторить.

7. Деплой одной командой

Ручное копирование файлов на сервер по FTP и правки «прямо на проде» — прямой путь к рассинхронизации. Нужен скрипт или CI, который каждый раз делает одно и то же: забирает код из git, ставит зависимости, собирает, перезапускает и проверяет, что сервис ответил.

Напиши скрипт деплоя: сборка, загрузка на сервер,
перезапуск процесса, проверка эндпоинта /health.
Если проверка не прошла — откат на предыдущую версию.

8. Бэкапы, которые вы проверяли

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

9. Логи и уведомления об ошибках

Вы должны узнать о падении раньше клиента. Достаточно простого: логи с ротацией, проверка доступности раз в несколько минут и сообщение в Telegram, если сервис не отвечает.

10. Память проекта

Записывайте договорённости в CLAUDE.md (или аналог в вашем инструменте): как запускать, как деплоить, что нельзя трогать, какие особенности у API. Тогда каждая новая сессия ИИ начинает с правильным контекстом, а не изобретает проект заново.

# Правила проекта
- Деплой только через ./deploy.sh
- Папку migrations не редактировать без вопроса
- Все суммы хранить в тиынах (целые числа)
- Время — в часовом поясе Астаны

Мини-регламент: как работать с ИИ в живом проекте

Правила работают, когда превращаются в ритуал. Вот последовательность, которую можно повесить на стену:

1. Перед задачей: git status чистый, последняя версия закоммичена.
2. Постановка: что нужно, что не трогать, как проверить результат.
3. План: прочитать и утвердить, прежде чем ИИ начнёт менять файлы.
4. Реализация: одна фича, без «заодно поправь ещё вот это».
5. Проверка: автотесты плюс ручная проверка главного сценария.
6. Коммит с понятным описанием на человеческом языке.
7. Деплой только скриптом, затем проверка, что сервис отвечает.
8. Запись: новое знание о проекте — в CLAUDE.md.

Полезный промпт, который стоит давать перед любым деплоем:

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

Такой список занимает минуту, но часто ловит то, что вы бы заметили только после жалобы клиента.

Признаки того, что проект пора спасать

• Каждая правка ломает что-то в другом месте.
• Никто не знает, какая версия сейчас на сервере.
• Ключи лежат в коде, а репозиторий публичный.
• Бэкапов нет или их ни разу не проверяли.
• Сервис падает, а узнаёте вы об этом от клиентов.

Отдельный тревожный сигнал — когда вы боитесь просить ИИ о правках, потому что «вдруг всё сломается». Это значит, что у проекта нет страховочной сетки: ни версий, ни тестов, ни понятного отката. Нормальное состояние обратное: любую правку можно попробовать, проверить и отменить за минуту.

Если узнали два пункта и больше — лучше остановить разработку новых фич и навести порядок. Это быстрее, чем кажется: обычно хватает нескольких дней.

Как мы помогаем

Для таких случаев в Emaya есть «Аптечка вайб-кода»: начинаем с диагностики, затем выносим секреты, настраиваем git, деплой, бэкапы и мониторинг, а при необходимости — рефакторим. Типичные проблемы проектов из Cursor, Lovable и Bolt мы разобрали в отдельной статье блога. Если хотите сразу собрать сервис с правильной основой — посмотрите «Вайб-код».