Кнопка «одобрить» у coding-агента не делает вас страховкой
Кнопка «одобрить» у coding-агента не делает вас страховкой — в соло-цикле с одним взглядом перед merge это срабатывает лишь когда последствия ошибки высоки и вы успеваете её поймать до коммита. В разборе по данным LoopRails codex даже plan-approval лишь снижает долю «плохих» предложений агента, но не учит человека их ловить.
Правильный вопрос — не «нужен ли человек», а «успеет ли поймать»
Human-in-the-loop может улучшать безопасность ИИ, но обычно не улучшает по умолчанию. Формулировка «нужен ли review?» почти всегда получает ответ «конечно» — и именно поэтому она бесполезна для проектирования агентных циклов. Полезнее спросить: может ли человек реалистично поймать эту ошибку вовремя?
Если ответ отрицательный, шаг review — не контроль безопасности, а декорация. Человек становится «именем на approval»: система уже приняла решение, а вы подписываете бумагу. Для coding-агентов это особенно коварно: агент уверенно объясняет rationale, diff выглядит правдоподобно, а под давлением сроков вы пробегаете глазами и жмёте approve. Такой цикл не ловит ошибки — он создаёт иллюзию, что кто-то их ловит.
Цифры codex: approve снижает риск предложения, но не ловят ошибки
Исследование LoopRails codex по AI coding agents даёт неудобную картину. Plan-approval снизило частоту атак примерно с ~90% до 60–74% — в основном потому, что агент реже предлагает плохие действия. Но intervention success — когда плохое действие уже показано человеку для перехвата — составил 9–26% при любой протестированной стратегии oversight.
Разрыв между «ошибка показана» и «ошибка исправлена» огромен. Confirmation prompt его не закрывает: gate на входе и gate на выходе — разные механизмы. Первый фильтрует намерения агента, второй требует от вас навыка детекции под давлением сроков. Данные говорят: второй навык у людей слабый, и никакая кнопка approve это не компенсирует.
Когда oversight становится театром
Несколько паттернов превращают human-in-the-loop в ритуал.
Automation bias — люди пере-доверяют подсказкам системы и одобряют без реальной проверки; чем надёжнее инструмент кажется, тем сильнее эффект. Rubber Stamp — reviewer под давлением читает уверенную rationale агента, пробегает глазами и жмёт approve: это исход по умолчанию наивного oversight, а не редкий сбой. Denylist Theater — список запретов, который агент может обойти, остаётся policy на бумаге, а не boundary в системе. Alert-Fatigue Spiral — перегрузка промптами убивает внимание: на Three Mile Island сработало 100+ сигналов за минуты; у клиницистов от 49% до 96% safety alerts отклоняются.
Квадрант «высокие последствия + низкая управляемость» — самый опасный. Review здесь не даёт safety, а даёт scapegoat. Автор называет это moral crumple zone: человек абсорбирует blame за failure системы без реальной власти предотвратить сбой. Агент удаляет production database или проводит платёж — accountability падает на того, кто нажал approve, хотя у него не было ни authority, ни awareness, ни времени.
Prevention-first вместо декоративного review
Когда человек не может поймать ошибку вовремя, менять нужно design, а не добавлять ещё один prompt. Brennhill предлагает метод Grade, Guard, Show, Prove — каркас для oversight AI-агентов, который LoopRails описывает как бесплатный sourced framework.
Grade (G0–G3) — классификация действий по reversibility, blast radius и stakes: от тривиального чтения файла (G0) до критических операций вроде удаления prod или внешних платежей (G3). На G3 нагрузку несёт prevention, а не review.
Guard — контроли по grade: sandbox-first (изолированная среда, без сети, scoped credentials), blast-radius cap, capability lock (опасные действия невозможны, а не «не рекомендуются»), kill switch. Пример Knight Capital (~$440M за ~45 минут в 2012): торговое ПО без halt-механизма — цена отсутствия interruptibility. Circuit breaker и maker-checker для irreversible действий — только когда checker может verify, а не формально подписать.
RAIL — инвариант: Reversible, Authorized, Interruptible, Logged. Show — preview имеет смысл только когда человек реально в контуре; декоративный preview бесполезен. Prove — seed errors и adversarial actions; измерять intervention success rate, а не approval rate. Невалидированный oversight — checkbox, не evidence.
Рабочий квадрант HITL — высокие последствия плюс высокая управляемость: readable diff, passing/failing tests, reviewer видит реальный эффект и может reject до merge, действие reversible. Нужны provenance («как это попало ко мне»), detection affordances вместо persuasive explanations и attention budget — каждый лишний prompt съедает scrutiny.
Что делать в соло-агентном цикле
Шесть выводов, которые можно перенести в свой цикл без отдельной команды безопасности.
- HITL — не автоматом: только высокие последствия и реальный шанс поймать вовремя.
- Клик approve ≠ ловля ошибок — цифры codex это подтверждают.
- Automation bias ведёт к rubber stamp по умолчанию; не надейтесь на «я внимательный».
- Высокие последствия + низкая управляемость → ложная безопасность и moral crumple zone.
- Реальная safety — prevention: grade, sandbox, cap, lock, kill switch, RAIL.
- Prove it: seed errors, measure catches — не approval rate.
Практический старт: прогнать свои agent actions через grading (G0–G3) — на looprails.dev есть interactive grader. Для G3 сначала sandbox и capability lock, потом уже думать о review. Если reviewer не может verify diff и тесты до merge — не claim oversight, меняйте архитектуру цикла.
Human-in-the-loop не враг. Враг — убеждение, что кнопка approve сама по себе делает агент безопасным.
Источники
- Brennhill, «Does Human-in-the-Loop Actually Improve AI Safety?» — Dev.to (доступ: 2026-07-01 UTC)
- Оригинальная публикация на LoopRails — https://looprails.dev/article-hitl-ai-safety.html (ссылка из поста; доступ: 2026-07-01 UTC)