Пользователи Claude Code одобряют 93% запросов — надзор становится формальностью

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

В материале Habr об усталости от надзора приводится показатель Anthropic: пользователи Claude Code одобряют 93% запросов на подтверждение. Сам по себе этот процент не доказывает невнимательность: большинство действий действительно могут быть безопасными. Однако он ставит полезный продуктовый вопрос: какую ошибку способен остановить ваш интерфейс, если обычный сценарий работы с ним — согласиться и продолжить?

Почему кнопка перестаёт защищать

Человек, который выполняет задачу, постепенно собирает понимание происходящего. Проверяющему агента приходится восстанавливать его по чужим действиям: какие файлы прочитаны, почему выбран инструмент, что уже изменено и какие последствия даст следующая команда. Отдельное окно подтверждения редко вмещает весь этот контекст.

Представим агента, которому поручили убрать устаревшую функциональность. Он удалил код, поправил тесты и предлагает очистить связанные ветки. Чтобы оценить последний шаг, недостаточно увидеть корректную команду Git. Нужно знать, какие ветки ещё используются, есть ли незавершённая работа коллег и входила ли очистка удалённого репозитория в исходную задачу. Синтаксис команды здесь почти ничего не решает.

Проблема надзора за автоматикой гораздо старше LLM. Исходный материал обращается к авиации и беспилотным автомобилям: длительное наблюдение ослабляет внимание, а редкое вмешательство требует навыка, который трудно поддерживать без практики. Эти примеры помогают понять механизм. Переносить частоту аварий или эффективность конкретных мер из одной отрасли в другую по ним нельзя.

Что менять в продукте и процессе

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

Второй шаг — собирать проверку вокруг законченного результата. Для изменения кода это может быть набор правок с результатами тестов, перечнем затронутых компонентов и явным указанием действий за пределами локальной копии. Так проверяющий видит связь между шагами. При этом пакетное одобрение не должно незаметно включать опасную операцию: миграцию или удаление данных стоит показывать отдельно, с конкретным объектом и ожидаемыми последствиями.

Третий шаг — проверять результат доступными техническими средствами. Существует ли обещанный файл? Открывается ли он? Соответствует ли содержимое задаче? Проходят ли проверки? Такие вопросы особенно важны, когда инструмент завершился ошибкой, а агент всё равно уверенно сообщил об успехе. Красивое резюме не подтверждает выполненную работу.

Автоматический классификатор действий тоже может помогать. В пересказе Habr Anthropic сообщает, что её классификатор пропустил 17% из 52 разобранных случаев чрезмерной инициативы агента. Это небольшая специальная выборка, а не универсальная оценка риска. Для команды смысл показателя простой: дополнительная модель оставляет ошибки, поэтому ограничения доступа и проверка последствий сохраняют значение.

Кто должен проверять агента

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

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

Для продакта вывод конкретный: доля одобрений сама по себе слабо описывает качество контроля. Для разработчика — каждое разрешение должно сопровождаться достаточным контекстом для решения. Для основателя — время квалифицированной проверки нужно учитывать в стоимости работы агента. Иначе ускорение выполнения легко принять за ускорение получения надёжного результата.