Защита от ошибок ИИ-разработчика

Плейбук: Защита от ошибок ИИ-разработчика

Зачем я это сделал

Когда ИИ пишет код для проекта (вайбкодинг), он быстрый, но иногда делает опасные вещи: может затереть рабочую версию, отправить «сырой» код в прод, сломать базу данных. У меня в правилах было написано «так не делать» — но это были просто слова в инструкции. А слова ИИ может проигнорировать. Несколько раз именно из-за этого падал прод.

Что это даёт

Опасные действия теперь физически невозможны — система их блокирует, а не «просит не делать». Плюс она сама ведёт журнал всех изменений и при старте новой сессии напоминает, на чём остановились. Дисциплина из «надежды» превратилась в защиту, которую нельзя обойти.

Как это работает (простыми словами)

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

Шаги

1. 1. Сначала находим разрыв. Прошу ИИ проанализировать проект и сказать: что в правилах написано, но на деле не работает. Обычно вылезает куча «обещанного, но не сделанного».
2. 2. Ставим охранников (хуки). Настраиваю автоматические проверки на самые опасные действия: попытка затереть рабочую версию, отправить непроверенный код, сломать структуру базы. Каждая — блокируется намертво.
3. 3. Включаем авто-журнал. Система сама записывает каждое изменение и при старте показывает, что было в прошлый раз — чтобы не терять контекст, если что-то прервалось.
4. 4. Добавляем проверяющего. Отдельный ИИ-помощник проверяет самые рискованные изменения (например, в базе данных) перед тем, как их применить.
5. 5. Обязательно тестируем. Нарочно пытаемся сделать запрещённое — убеждаемся, что блокировка реально срабатывает, а не только числится на бумаге.

На чём сэкономило / что оптимизировало

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

Грабли

• - Главный урок: «написано в правилах» ≠ «работает». Любое правило безопасности нужно превращать в механизм, а не в текст. Иначе это просто пожелание.
• - Тестировать блокировки обязательно — иначе не узнаешь, что они мнимые.

🔧 Техническая часть (можно пропустить — для исполнителя)

• - Стек: Claude Code hooks (PreToolUse/PostToolUse/SessionStart) в .claude/settings.json.
• - 5 хуков: session-start.sh (подгружает last-session), post-bash.sh (авто-лог git commit), guard-bash.sh (блок --no-verify, git push --force, проверка alembic single-head перед PR), guard-env-edit.sh (approve на правку .env*), alembic_heads.py (счёт head через ast).
• - Субагенты: qa.md (численные гейты), migration-reviewer.md (ревью миграций).
• - Запуск аудита разрыва: плагин claude-code-setup → «проанализируй кодбазу и порекомендуй автоматизации».
• - Применено: Vision CRM (коммиты 3191888, a735a15). Тестировать блокировки на фейковом stdin.