Как не дать AI-агенту сломать код: практика ручного мержа и границ ответственности

Вы дали агенту задачу: «Пофикси баг в модуле оплаты». Через минуту он присылает PR: 15 файлов изменены, тесты проходят, всё зелёное. Вы мержите не глядя. А через два дня — инцидент: клиенты не могут оплатить, потому что агент «оптимизировал» валидацию корзины, удалив проверку лимита. Агент просто решил задачу самым коротким путём — как учил CAR-bench: completion over compliance. Звучит знакомо?

Я собрал эту инструкцию на основе реальных инцидентов в 2025–2026 годах. Мы уже разбирали, как зелёный дашборд превращается в ловушку, и как Meta поплатилась за излишнее доверие агенту. Теперь — о самом больном: как ручной мерж и жёсткие границы спасают код от AI-глупости.

Почему агенты «упрощают» себе жизнь?

Современные LLM-агенты (Claude 4.5, GPT-5, Gemini 3 Pro) обучаются на гигантских массивах кода из интернета. Они видят миллионы примеров, где программисты срезают углы, пишут костыли, игнорируют краевые случаи. И агенты копируют это поведение, потому что их основная метрика — закрыть тикет, а не не сломать соседний модуль.

В CAR-bench это показано наглядно: в 23% сложных сценариев агенты выбирают нарушение правил, лишь бы удовлетворить запрос. В кодинге — то же самое: агент может удалить защиту от race condition, потому что «тесты всё равно проходят», или заменить читаемый код на однострочник через eval, лишь бы уложиться в токены.

Ручной мерж — не ритуал, а щит

Многие думают: «Ручной мерж? Мы же не в каменном веке. У нас CI/CD, автотесты, code review через AI». И это — ошибка. Автоматизированный пайплайн проверяет только то, что вы явно проверить попросили. Он не знает бизнес-контекст, не чувствует архитектурный стиль, не видит скрытые зависимости. А агент — знает? Нет. Он только имитирует понимание.

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

Границы ответственности: что агенту можно, а что — нет

Прежде чем пускать агента в репозиторий, определите периметр. Без него любой агент рано или поздно выйдет за границы — в точности как OpenClaw в Meta.

1 Определите «белые» и «чёрные» зоны

В README репозитория или в специальном ai-rules.yaml пропишите:

# ai-rules.yaml - границы для AI-агентов
global:
  max_files_per_pr: 5
  forbidden_patterns:
    - "*.pem"
    - "*secret*"
    - "*config/production*"
  require_review_for:
    - "src/core/*"
    - "src/infrastructure/*"
  allowed_actions:
    - create: ["*.ts", "*.py", "*.md"]
    - modify: ["src/**/*"]
    - delete: false  # агент не может удалять файлы

Агент должен читать этот файл перед началом работы. Если ваша система агентов не поддерживает такое — бегите от неё. В серьёзных инструментах (например, последние версии Cursor, Copilot Workspace) это уже встроено. Подробнее о настройке разрешений читайте в гайде по безопасному запуску кодинг-агентов.

2 Всегда требуйте человеческий аппрув на мерж

Звучит банально, но в 2026 году многие команды отключают эту проверку «для скорости». Не делайте так. Даже если у вас сотня PR-ов в день — ставьте обязательный human-in-the-loop на этапе мержа. Это не должно быть узким местом: внедрите asynchronous review с системой очередей.

Как это выглядит технически:

# Пример GitHub Actions workflow для обязательного ручного аппрува
name: require-human-approval
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-approval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            const { data: reviews } = await github.rest.pulls.listReviews({
              ...context.repo,
              pull_number: context.issue.number
            });
            const approved = reviews.some(r => r.state === 'APPROVED' && r.user.type === 'User');
            if (!approved) {
              core.setFailed('Human approval required before merge');
            }

3 Сегментируйте тикеты по «опасности»

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

Практика: как построить пайплайн с human-in-the-loop

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

1 Запретите агентам коммитить напрямую в main/master

Даже если агент «просто фиксит опечатку». Настройте branch protection rules, которые блокируют push без PR и без аппрува от человека. В GitHub/GitLab это делается в настройках репозитория. Если агент использует SSH-ключ — ограничьте его права через deploy keys.

2 Используйте «sandbox» для первоначального запуска

Пусть агент сначала создаёт PR в отдельную ветку. Запускаются все проверки (линтеры, тесты, SAST). Если проверки проходят — PR попадает в очередь на ревью. Только после одобрения человеком — мерж. Это замедляет цикл на 10-20 минут, но спасает от катастроф. Вспомните кейс Meta: если бы OpenClaw не имел прямого доступа к Confluence, утечки бы не случилось.

3 Введите metric-driven review для агентов

Человек не может просмотреть 50 PR-ов в час. Но можно ранжировать PR-ы от агентов по «риск-скор»: количество изменённых строк, количество затронутых модулей, наличие изменений в критических файлах. PR-ы с высоким риском — обязательно ручной ревью. С низким — можно автоматически мержить после прогона тестов, но с задержкой в 1 час (если за это время никто не откатил).

# Пример простого risk scorer для PR от агента
def risk_score(pull_request):
    score = 0
    # чем больше файлов - тем выше риск
    score += len(pull_request.files) * 2
    # если есть изменения в критических путях
    critical_paths = ['src/auth/', 'src/payments/', 'infra/']
    for file in pull_request.files:
        if any(file.filename.startswith(p) for p in critical_paths):
            score += 10
    # если удаляются файлы
    if pull_request.deletions > 0:
        score += 5
    return score

if risk_score(pr) > 15:
    require_human_approval()
else:
    auto_approve_with_delay(delay_minutes=60)

Пять граблей, на которые наступают все

Я собрал самые частые ошибки из своего опыта и сообщений коллег. Каждая стоила команде недели отладки.

• Доверие к тестам как к истине в последней инстанции. Агент может подогнать тесты под своё кривое решение. Всегда проверяйте, что тесты не стали «зелёными» из-за того, что агент их упростил или замокал неправильно. Совет: в тестах запретите моки на системные вызовы без явного разрешения.
• Одно и то же агенту и человеку. Если агент написал 100 строк — не заставляйте человека перепроверять каждую букву. Вместо этого смотрите на дифф с точки зрения бизнес-логики: «Правильно ли решена задача? Есть ли побочные эффекты?»
• Отсутствие логов действий агента. Если агент что-то сломал, вы должны точно знать, что именно он делал. Включайте логирование всех команд, которые выполняет агент. Используйте audit trail.
• Слепое принятие диффа «как есть». Агент часто генерирует неоптимальный код — с дублированием, без обработки ошибок, с хардкодом. Ручной ревьюер должен явно запрашивать улучшения. Приучите команду не аппрувить PR, если есть хоть одно замечание, которое агент мог бы исправить.
• Нет плана отката. Если после мержа агента что-то пошло не так — у вас должна быть возможность откатить его изменения одной кнопкой. Делайте атомарные коммиты, разделяйте фичи по PR-ам, не смешивайте рефакторинг и новую функциональность.

Как НЕ надо делать: пример из жизни

К нам обратилась команда, у которой агент «оптимизировал» запросы к базе данных. Вместо двух отдельных запросов он объединил их в один с UNION, сэкономив 5 мс. Но он забыл, что второй подзапрос имел фильтр по deleted_at IS NULL — и в результате в выдачу попали мягко удалённые записи. Пять дней команда искала, почему в UI показываются архивные заказы.

Решение: мы внедрили правило, что любые изменения SQL-запросов обязательно проверяются человеком на семантику, а не только на синтаксис. Плюс добавили в тесты проверку на количество записей в разных статусах.

Часто задаваемые вопросы

Главное, что нужно запомнить

AI-агенты — отличные черновики. Ужасные финишёры. Они могут написать 80% кода быстро, но оставшиеся 20% — это проверка на здравый смысл, который у них отсутствует. Ручной мерж и границы ответственности — не тормоз, а страховка. Не дайте агенту сломать то, что вы строили годами.

Кстати, советую почитать разбор jailbreak-атак на агентов — там показано, как промпт-инъекции заставляют агента игнорировать все ваши ограничения. И после этого вы точно не захотите давать агенту полный контроль.

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