TL;DR
Исследование показывает: кодинг-агенты (Claude Code, Codex) регулярно «перестраховываются», даже когда в задаче уже есть всё, чтобы этого не делать. Они повторно гоняют тесты, которые прогонит CI. Делают бэкап того, что восстанавливается скриптом. Добавляют проверки на случай, который невозможен. Авторы собрали 200 парных задач, где отличается один факт о мире, и сравнили поведение агентов с этим фактом и без него.
Главная находка: сильный агент не равен спокойному агенту. Доля задач с лишней защитной работой составила от 11% до 59% в зависимости от конфигурации. Модель, которая лучше решает задачи, перестраховывается не меньше. Особенно плохо, когда в инструкции есть «проверь/протестируй», но не сказано, сколько. У такого действия нет естественной точки остановки, поэтому агент продолжает. Рост нарушений при неуказанной мере доходил до 69 процентных пунктов. Разработчики оценивали такие прогоны почти на 1,3 балла из 5 ниже.
Метод по сути — классификация рисков из управления проектами: избежать, передать, снизить, принять. Для каждого типа есть свой тип факта, который агенту нужно сообщить: «этого риска нет», «этим занимается другой», «вот предел», «решение окончательное». Факты авторы писали как утверждения о состоянии мира, а не как запреты («не добавляй проверки»). Агент должен сам сделать вывод.
Схема метода
Это не промпт-техника, а чек-лист фактов. Каждый пункт убирает свой вид лишней работы.
ИЗБЕЖАНИЕ (Avoidance) → факт: «этот сбой невозможен»
пример: данные восстанавливаются, вызовы идут по очереди,
версии зависимостей зафиксированы, типы исключают неверный ввод
→ агент не пишет защиты, фолбэки и проверки от него
ПЕРЕДАЧА (Transfer) → факт: «этим уже владеет другой механизм или человек»
пример: CI гоняет тесты, бот обновляет зависимости, ревьюер смотрит diff
→ агент не дублирует проверки
СНИЖЕНИЕ (Mitigation) → факт: «мера ограничена числом/уровнем»
пример: сколько прогонов, какой объём тестов, какая длина отчёта
→ агент не выходит за предел
ПРИНЯТИЕ (Acceptance) → факт: «решение принято и не обсуждается»
пример: «это финальная версия», «удаление окончательное»
→ агент не делает бэкапы и не переспрашивает
Всё пишется в одном сообщении агенту или в файле инструкций.
Пример применения
Задача: Вы владелец небольшого интернет-магазина на Python. Просите Claude Code починить баг: промокод SALE20 применяется в корзине дважды. Без контекста агент прогонит весь набор тестов трижды, сделает копию таблицы промокодов «на всякий случай», добавит проверку на дубли в пяти местах и напишет отчёт на две страницы.
Промпт:
Почини баг: промокод SALE20 применяется в корзине дважды.
Функция apply_discount в cart/discount.py.
Контекст:
- Полный набор тестов гоняет GitLab CI на каждый пуш,
а перед мерджем изменения смотрит Сергей (тимлид).
- Таблица промокодов promo_codes — кэш: её каждую ночь пересобирает
скрипт rebuild_promos.py из выгрузки 1С. Источник правды — 1С.
- Запросы к корзине обрабатываются через одну очередь,
параллельных записей в корзину нет.
- Версии зависимостей зафиксированы в poetry.lock.
- Для проверки достаточно одного целевого теста на изменённую функцию.
- Отчёт: не больше пяти строк.
Результат: Агент должен ограничиться правкой функции и одним целевым тестом. Не будет делать бэкап таблицы, перепроверять то, что покрывает CI, и добавлять защиту от гонок. Отчёт получится коротким. Это ожидаемое поведение, гарантии в статье нет: даже при явных фактах лишняя работа встречалась в заметной доле прогонов.
Почему это работает
Слабость. Агент не знает вашего окружения. Он видит код, но не видит, что CI всё равно прогонит тесты, что таблица восстановима и что решение уже принято. Для него осторожность безопасна, а лишняя проверка ничего не стоит. Поэтому он страхуется «на всякий случай». Особенно сильно он перестраховывается, когда в инструкции есть «проверь» без предела. Это расплывчатая просьба без точки остановки.
Сильная сторона. Агент хорошо выводит следствия из фактов. Если написано «тесты гоняет CI», он способен понять, что дублировать прогон не нужно. Авторы специально подавали факты как утверждения, чтобы проверить именно этот вывод, а не послушание запретам.
Как метод использует это. Вы заранее закрываете четыре типичные дыры: невозможность риска, чужую ответственность, предел меры и окончательность решения. Агенту больше нечего «додумывать» в сторону осторожности.
Рычаги: - Числа вместо глаголов. «Проверь» → «один целевой тест», «отчёт до пяти строк», «не больше двух запусков». Это самый сильный рычаг: именно неуказанная мера давала самый большой рост нарушений. - Кто владелец. Называйте конкретно: «GitLab CI», «Сергей на ревью». Конкретный владелец убедительнее фразы «это проверяется где-то ещё». - Окончательность решения. Формулируйте как факт: «это финальная версия», «удаление окончательное». - Постоянные факты в файл инструкций (CLAUDE.md, AGENTS.md): про CI, ревью, восстановимые данные. Остальное пишите в задачу.
Шаблон промпта
{задача: что сделать, где}
Контекст (факты об окружении):
- Тесты/проверки: {кто и когда их запускает, например «GitLab CI на каждый пуш»}.
- Ревью: {кто смотрит изменения и когда}.
- Восстановимость: {что можно пересобрать автоматически и чем}.
- Параллельность: {есть ли одновременные записи/запуски или всё идёт строго по очереди}.
- Зависимости и окружение: {что зафиксировано и не меняется}.
- Объём проверки: {сколько прогонов/какой уровень тестов достаточно}.
- Формат отчёта: {длина, что включить}.
- Решения, которые приняты: {что окончательно, например «версия схемы финальная»}.
Пишите только те строки, которые правда верны для вашего проекта. Неверный факт («CI всё покрывает», когда не покрывает) снимает защиту там, где она нужна. Ненужные строки удаляйте.
🚀 Быстрый старт — вставь в чат:
Вот шаблон блока «Контекст» для задачи кодинг-агенту. Адаптируй под мой проект: [опиши проект и стек].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, кто запускает тесты, кто делает ревью, что в проекте восстанавливается автоматически и какие решения окончательные. Это именно те факты, на которых строится метод: каждый из них закрывает один тип лишней работы. Из ответов она соберёт готовый блок для задачи или для CLAUDE.md.
Ограничения
⚠️ Факт должен быть правдой: Метод держится на достоверных утверждениях. Если вы напишете «CI всё проверяет», а CI не проверяет, агент послушно перестанет страховаться и пропустит ошибку.
⚠️ Лишнее не исчезает полностью: Даже при явных фактах в задаче лишняя защитная работа встречалась в заметной доле запусков. Факты снижают её, но не обнуляют.
⚠️ Запреты не проверяли: Авторы подавали факты как утверждения, а не как запреты вроде «не добавляй проверки». Работает ли прямой запрет лучше или хуже, из материала не видно.
⚠️ Только код на двух языках: Задачи на Python и Go в репозиториях, где специально убрали файлы инструкций для агентов. Как факты в CLAUDE.md взаимодействуют с остальными правилами, не измеряли. Перенос на другие области и языки — догадка.
⚠️ Неполный текст: Мне доступны введение, дизайн и аннотация. Раздел с разбивкой по моделям и конфигурациям обрезан, поэтому сравнения «какая модель лучше» здесь нет.
⚠️ Осторожность не всегда лишняя: В вариантах без фактов агент вправе страховаться. Метод про то, чтобы не перестраховываться при наличии фактов, а не про то, чтобы отключить осторожность.
Как исследовали
Идея была простой: отделить «агент осторожен по делу» от «агент осторожен по привычке». Для этого сделали 200 пар одинаковых задач. В каждой паре меняется ровно один факт. В одной версии он есть («это финальная версия», «CI гоняет тесты»), в другой его нет. Всё остальное, включая репозиторий, цель и проверяющий тест, совпадает. Если поведение разное, причина в этом факте.
Исходные ситуации взяли не из головы. Авторы изучили 18 922 реальные сессии разработчиков с кодинг-агентами и нашли 5 574 эпизода, где агент перестраховался сверх необходимого. Из них собрали 44 типовые ситуации, сгруппированные по четырём типам риска. Задачи сделали на 50 открытых репозиториях (34 на Python, 16 на Go) и убрали файлы инструкций. Так агент не получал подсказок помимо самой задачи. Репозитории взяли со свежими коммитами, чтобы модели не могли помнить их по обучению.
Проверили 8 моделей в Claude Code и Codex (9 600 запусков). Лишнюю работу оценивал агент-судья. Его откалибровали по разметке двух экспертов и получили точность 0,965 при согласии с людьми κ = 0,93. Отдельно 20 разработчиков оценили 800 прогонов: лишняя защитная работа снижала их удовлетворение на 1,27 балла из 5.
Удивило то, что способность решать задачи почти не влияет на склонность к лишней работе. Умный агент не обязательно спокойный. Практический вывод: полагаться на «модель сама поймёт» не стоит, окружение нужно описывать явно, особенно меру проверки.
Адаптации и экстраполяции
Этот блок — мои идеи, статья их не проверяла.
🔧 Техника: постоянные факты → в файл инструкций, разовые → в задачу
Факты про CI, ревью и восстановимые данные редко меняются. Их можно один раз записать в CLAUDE.md или AGENTS.md:
## Что уже обеспечено окружением
- Тесты на каждый пуш гоняет GitLab CI — не дублируй полный прогон локально.
- Изменения проходят ревью тимлида — отчёт о проверках держи коротким.
- Папки /build и /cache пересобираются автоматически — бэкапы не нужны.
- Если в задаче не указан объём проверки, запусти только целевые тесты
на изменённые файлы и сообщи, что проверил.
Последний пункт — моя вставка. Он закрывает главную находку: проверка без указанной меры уводит агента в избыточность.
🔧 Техника: аудит своего файла инструкций
Пройдите по инструкциям и найдите слова вроде «проверь», «протестируй», «убедись», «будь осторожен» без числа и предела. Это места, где агент, по логике статьи, будет раздувать работу.
Вот мой файл инструкций для агента: [вставить]. Найди формулировки, где
требуется проверка или осторожность, но не указана мера (сколько,
в каком объёме, до какого предела). Для каждой предложи версию
с конкретным пределом и вопрос, какой факт мне нужно уточнить.
Ресурсы
- Работа: ParanoiaEval: Benchmarking Unnecessary Defensive Work in Agentic Coding (препринт)
- Авторы: Hanjun Luo, Xiucheng Zhang, Zhuoning Xu, Zhimu Huang, Yingbin Jin, Xinfeng Li, Hanan Salam
- Университеты: New York University, NYU Abu Dhabi, The Hong Kong Polytechnic University
- Код и данные: https://github.com/ZhuoningXu/ParanoiaEval_release
- Теоретическая основа: рамка Avoidance–Transfer–Mitigation–Acceptance (ATMA) из управления рисками NIST (IR 8286 Rev. 1)