TL;DR
Исследование показывает, на что тратить следующий шаг, когда кодовый агент застрял. Есть три варианта: «подумай ещё» (вычисления), «вот что код должен делать» (информация) и «запусти тесты и посмотри, что упало» (обратная связь). Авторы проверили каждый вариант отдельно и во всех комбинациях на одних и тех же сломанных состояниях. Сильнее всего помогает описание требуемого поведения: что именно код должен делать и где это менять.
Агенты ведут себя иначе, чем им полезно. Почти все сильные модели в 95–100% случаев просят запустить тесты и прочитать, что упало, хотя это самый слабый из трёх ресурсов. Выбор вслепую дал бы в среднем больше пользы. «Подумай подольше» помогает слабым моделям, а у сильных почти не даёт эффекта: они уже выжали из рассуждений всё. Найденный поиском чужой код не помогает совсем. Текст той же длины, но не по делу, тоже не помогает: важно содержание, а не объём.
Практический вывод: когда агент крутится по кругу, не проси ещё раз прогнать тесты. Остановите его и дайте короткую спецификацию. В неё входят два блока: где менять (файлы и функции) и что должно происходить (причина бага, требуемое поведение, граничные случаи). По отдельности «где» не даёт ничего, «что» даёт примерно половину эффекта, а вместе они дают весь эффект.
Схема метода
Так устроено исследование. Метод называется BRA (Banzhaf Resource Attribution, «разложение вклада ресурсов»):
ШАГ 1: Берём «замороженное» провальное состояние агента (задача + неверный код)
ШАГ 2: Клонируем его в 8 копий — все комбинации трёх ресурсов:
подумать (C) / получить информацию (I) / запустить тесты (F)
ШАГ 3: В каждой копии — одна и та же финальная правка кода
ШАГ 4: Считаем долю скрытых тестов, которые прошли → вклад каждого ресурса
отдельно и в паре с другими
ШАГ 5: Отдельно: даём модели самой выбрать ресурс и сравниваем с реальной пользой
Читателю этот дизайн повторять не нужно. Нужен вывод для практики:
Агент застрял
→ НЕ «запусти тесты ещё раз» и НЕ «подумай подольше»
→ Дай: ГДЕ менять + ЧТО должно происходить (поведение, причина, граничные случаи)
→ Одна правка по этому описанию
Пример применения
Задача: Вы разработчик интернет-магазина на Django. Агент в Claude Code уже в третий раз чинит расчёт доставки: бесплатная доставка от 3 000 ₽ считается по сумме до применения промокода. Тест test_free_shipping_after_promo падает. Агент гоняет его по кругу и каждый раз меняет что-то рядом.
Промпт:
Стоп. Не запускай тесты снова и не перебирай правки наугад.
Вот описание того, что должно происходить.
ГДЕ менять:
- файл orders/services/delivery.py, функция calculate_delivery_cost()
- вызывается из orders/views.py → CheckoutView.get_context_data()
ЧТО должно происходить:
- Причина бага: порог бесплатной доставки (3 000 ₽) сравнивается
с cart.subtotal, то есть с суммой до скидки.
- Требуемое поведение: порог сравнивается с суммой ПОСЛЕ применения
промокода. Корзина 3 200 ₽ с промокодом -500 ₽ = 2 700 ₽ → доставка
платная (299 ₽).
- Граничные случаи:
1) сумма после промокода ровно 3 000 ₽ → доставка бесплатная;
2) промокод на 100% → сумма 0 ₽, доставка платная;
3) промокода нет → поведение не меняется.
Сделай одну правку по этому описанию. Потом покажи диф
и кратко объясни, как он закрывает каждый граничный случай.
Результат: Агент перестанет перебирать правки и сделает одну целевую правку в указанной функции. В ответе будет диф и разбор трёх граничных случаев. Если спецификация верная, тест пройдёт с первой попытки. Если нет, вы сразу увидите расхождение между вашим описанием и тем, что агент понял.
Почему это работает
Слабость. Агент после неудачи не знает, чего он не знает. Запуск тестов даёт ему только факт «упало» и кусок вывода. Он видит симптом, а не требование. Поэтому он правит код вокруг симптома и тратит ходы впустую. «Подумай ещё» не добавляет данных: модель размышляет над тем же набором фактов. Поиск по репозиторию приносит много кода, но не говорит, что в нём должно измениться.
Сильная сторона. Если модели прямо сказано, какое поведение требуется и где его менять, она хорошо пишет сам код. Недостаёт ей не умения, а знания о цели. Поэтому информация сохраняет ценность даже у самых сильных моделей, а ценность рассуждений падает почти до нуля.
Как метод это использует. Спецификация закрывает именно недостающее: и что, и где. Эти два куска дополняют друг друга. Место без понимания причины не даёт ничего, причина без места даёт примерно половину, оба вместе дают весь эффект.
Рычаги управления: - Блок «где» (файлы, функции) → убирайте, если место очевидно, но не оставляйте только его. - Блок «что» (причина, поведение) → самый важный: именно он даёт основную часть эффекта. - Граничные случаи → добавляйте для функций с условиями и порогами. В исследовании на уровне функций спецификация включала контракт «вход–выход» и граничные случаи. - Объём → не растягивайте. Текст той же длины, но не по делу, эффекта не дал. Каждая строка должна нести требование. - «Один ход» → просите одну правку по описанию, а не бесконечный цикл. В исследовании так и было: ровно одна финальная ревизия.
Шаблон промпта
Стоп. Не запускай тесты снова и не перебирай правки наугад.
Ниже описано, что должно происходить.
ГДЕ менять:
- {файлы и функции, которые нужно изменить}
ЧТО должно происходить:
- Причина проблемы: {почему сейчас не работает — своими словами, без готового кода}
- Требуемое поведение: {что код должен делать — на 1–2 примерах с конкретными числами}
- Граничные случаи: {2–3 случая, где легко ошибиться, и правильный результат для каждого}
Сделай одну правку по этому описанию. Покажи диф и кратко объясни,
как он закрывает каждый граничный случай.
Что подставлять:
- {файлы и функции} — где лежит проблема. Если не знаете, попросите агента сначала показать, какие функции участвуют в сценарии.
- {причина} — объяснение «в чём суть», а не готовый патч. В исследовании описание не называло конкретные файлы и переменные, оно описывало поведение.
- {требуемое поведение} — лучше с числами из жизни: «корзина 3 200 ₽, промокод -500 ₽ → …».
- {граничные случаи} — пороги, ноль, пустой ввод, «ровно на границе».
Для файла инструкций агента (CLAUDE.md / AGENTS.md) — это моя адаптация, не формулировка из статьи:
Если после двух попыток тест всё ещё падает:
1. Не запускай тот же тест в третий раз.
2. Сформулируй, что именно ты не знаешь о требуемом поведении
(где менять? какой результат правильный? какие граничные случаи?).
3. Задай мне эти вопросы и жди описания.
Ограничения
⚠️ Спецификация в исследовании идеальна: авторы писали её по эталонному исправлению, проверяя, что информация о поведении принесёт в лучшем случае. Авторы прямо называют верхние ступени лестницы «инструментами», а не тем, что система может получить сама. Ваша спецификация будет менее точной, а неверное описание может увести агента в сторону. Этот риск в статье не измеряли.
⚠️ Только код: проверяли на Python-задачах: функции из MBPP+ и HumanEval+ и исправления в репозиториях SWE-bench. Перенос на тексты, анализ или другие области остаётся догадкой.
⚠️ Модели без скрытых рассуждений: все модели работали без встроенного «думающего» режима. На моделях с длинными внутренними рассуждениями ценность «подумай ещё» может оказаться другой.
⚠️ Обратная связь не бесполезна вообще: измеряли только отчёт по публичным тестам, до пяти падающих случаев, и одну правку после него. Подробная обратная связь в живой работе, где агент запускает программу много раз, может вести себя иначе. Но выбор «только тесты» в исследовании стабильно проигрывал.
⚠️ Правка одна: агент правил один раз, без циклов. Как всё сочетается в длинной цепочке ходов, статья не проверяет.
⚠️ Текст статьи обрезан: часть результатов (экономика токенов, полное сравнение стоимости ресурсов, доводы про жадное распределение) в доступном фрагменте не видна. Выводы выше опираются на то, что есть.
Как исследовали
Идея была простой: вместо сравнения целых агентов заморозить момент неудачи и посмотреть, что на самом деле помогло бы. Авторы взяли 194 провальных функции (первые попытки маленькой модели Qwen3-4B на MBPP+ и HumanEval+) и 126 провальных исправлений агента на SWE-bench Verified. Каждое провальное состояние клонировали в 8 копий: во всех комбинациях «подумать / получить информацию / запустить тесты». Затем во всех копиях выполнялась одна и та же финальная правка. Результат проверяли на скрытых тестах, которые в промпт не попадали.
Так можно было отделить пользу самого ресурса от побочного эффекта вроде «просто сделали ещё одну правку». Для проверки «важно ли содержание» добавили плацебо: нейтральный текст той же длины. Он дал примерно ноль. Информацию разложили на ступени: поиск по репозиторию, только место, только поведение и полная спецификация. Это дало неожиданную картину: поиск и «только место» не помогли, «только поведение» даёт около половины, обе части вместе дают весь эффект.
Шесть моделей (от Qwen3-4B до GPT-5.6 и Claude Sonnet 4.5) показали общую закономерность: у слабых моделей «подумать» стоило 0,13 по доле пройденных тестов, у самых сильных — около 0,01. Ценность информации падает слабее (0,06–0,14). На 24 самых сложных состояниях, где проваливались все модели, информация давала 0,12–0,25 для каждой. Спад в общей выборке объясняется «потолком»: сильные модели чаще решают задачи без помощи.
Дальше авторы дали четырём сильным моделям самим выбрать ресурс. Три из четырёх выбирали обратную связь почти всегда и получали пользу ниже, чем при случайном выборе. Исследование предварительно зарегистрировало гипотезу, что ресурсы усиливают друг друга, и данные её не подтвердили. Ресурсы скорее заменяют друг друга: 21 из 36 парных взаимодействий значимо отрицательные, положительных значимых нет. Это значит, что нескольких «подпорок» сразу не нужно: хватает самой ценной.
Адаптации и экстраполяции
🔧 Техника: запретить «ещё раз прогнать» → меньше вхолостую потраченных ходов
Добавьте в начало сообщения агенту: «Не запускай тесты, пока не опишешь своими словами, какое поведение должно получиться». Это заставляет агента сначала сформулировать недостающее знание. Это моя адаптация, в статье такого приёма нет.
🔧 Техника: убрать готовые имена из описания → описывать поведение
Авторы требовали, чтобы блок про поведение не называл конкретные файлы, функции и переменные. Он описывал причину и требуемое поведение. Придерживайтесь этого: так вы даёте суть, а не готовый патч, и агент не копирует подсказку слепо.
Экстраполяция: вопрос вместо выбора ресурса. Если агент сам просит «запустить тесты», это сигнал, что он не знает, чего вы хотите. Подмените его выбор вопросом (моя идея, не измерялась):
Прежде чем предложить следующий шаг, ответь на три вопроса:
1) Какое поведение здесь ожидается? Я описал его достаточно ясно?
2) В каком месте кода нужно менять поведение?
3) Каких граничных случаев в моём описании не хватает?
Если на любой из вопросов нет ответа — спроси меня, а не запускай тесты.
Ресурсы
- Работа: Where Should a Stuck Agent Spend Its Next Tokens? Causal Attribution of Inference-Time Resources (NeurIPS 2026, воркшоп Long-Context Foundation Models).
- Авторы: Saiyue Lyu, Jerrold Huang, Yunbei Zhang, Janet Wang, Zhenting Wang, Yingqiang Ge, Haibo Zhang. Университеты: University of British Columbia, University of Toronto, Tulane University, Rutgers University, Kyushu Institute of Technology.
- Данные: MBPP+ и HumanEval+ (EvalPlus), SWE-bench Verified.
- Основа метода: значение Банцафа (Banzhaf value) из теории кооперативных игр, разложение Мёбиуса для взаимодействий между ресурсами.