TL;DR
Если кодирующему агенту дать репозиторий с чужой работой (от другого агента или из прошлой сессии), он принимает эту работу как определение того, что ещё осталось сделать. Он смотрит изменения, гоняет тесты и сдаёт результат, почти не сверяя его с исходным запросом. Авторы называют это acceptance bias (склонность принимать унаследованное).
Главная находка: тот же агент, который решает задачу с нуля, с чужого «почти готового» результата проваливается в разы чаще. Разрыв составил от 20 до 53 процентных пунктов. Работа выглядит законченной: в среднем она уже проходит ~98% скрытых тестов, а у половины состояний падает всего 1–3 теста. Поэтому агент не ищет, что не так. Чаще всего (в 59–88% провалов на DeepSWE) он заканчивает с теми же упавшими тестами, с которыми начал. При этом с чистого листа он эти тесты проходил. Ещё одно следствие: рейтинг агентов при таком старте переворачивается, то есть сильный на чистом старте агент не обязательно хорош в доработке чужого.
Практический вывод: слова «готово» от предыдущей сессии или агента нельзя считать входом для следующего. Проверять нужно против исходного ТЗ, а не против текущего состояния кода.
Схема метода
В статье нет приёма, это бенчмарк. Схема эксперимента, из которого следует вывод:
ШАГ 1: Агент-предшественник решает задачу → сдаёт «готово», но скрытые тесты падают
ШАГ 2: Сохраняют его итоговое состояние (код, файлы, установленный софт)
ШАГ 3: Новый агент получает ТОЛЬКО исходный запрос + это состояние
(без истории работы, без сообщения «это провалилось»)
ШАГ 4: Сравнение: тот же агент, та же задача, но с чистого старта
Пример применения
В статье нет готового промпта. Ниже промпт по её мотивам, авторы его не проверяли. Он нужен, чтобы показать, где проблема бьёт сильнее всего: передача работы между сессиями.
Задача: Вчера Claude Code в Cursor «закончил» интеграцию интернет-магазина с ЮKassa: приём платежа, вебхук подтверждения, возврат. Сегодня вы открыли новую сессию. Истории нет, остался только репозиторий и сообщение вчерашней сессии «всё готово». Если просто написать «доработай и проверь», новый агент, скорее всего, пробежится по коду, запустит имеющиеся тесты и скажет «ок».
Промпт:
Ниже — исходное ТЗ. Предыдущая сессия сообщила, что работа завершена.
Считай это непроверенным утверждением, а не фактом.
<ТЗ>
1. Создание платежа через ЮKassa с чеком по 54-ФЗ.
2. Вебхук: при payment.succeeded заказ переходит в статус «оплачен»,
повторный вебхук не должен дублировать действия.
3. Возврат полной и частичной суммы из админки.
4. При отмене платежа резерв товара снимается.
Порядок работы:
1. Выпиши из ТЗ каждое требование отдельным пунктом.
2. Для каждого пункта найди в репозитории, где он реализован,
и как это можно проверить (тест, запрос, запуск).
Если не нашёл — пометь «не реализовано».
3. НЕ опирайся на то, что код «выглядит законченным»
и на то, что существующие тесты проходят: они могли не
покрывать требование.
4. Для каждого пункта напиши отдельную проверку и запусти её.
5. Итоговая таблица: требование | где в коде | как проверено | статус.
Статус «выполнено» ставь только если проверка запущена и пройдена.
6. Исправь всё, что не «выполнено», и повтори п. 4–5.
Результат: Модель сначала разложит ТЗ на пункты, затем покажет сопоставление пунктов с кодом. Потом напишет и запустит проверки на каждый пункт, а не только на уже существующие тесты. В финале будет таблица со статусами и список исправлений. Видно, какие пункты вчерашняя сессия пропустила или сделала не так (например, идемпотентность вебхука или частичный возврат).
Почему это работает
Слабость. Модель плохо замечает то, чего в тексте и коде нет. Она с трудом находит ошибки без внешней обратной связи и охотно достраивает на чужих ошибках вместо пересмотра. Когда состояние выглядит законченным, у неё нет сигнала искать пробелы. Работа «определяет» оставшийся объём: изменения просмотрели, тесты запустили, дела нет.
Сильная сторона. Модель хорошо делает с нуля. С чистого листа те же агенты проходили эти тесты. Она также неплохо проверяет конкретный пункт по конкретному критерию, когда критерий ей явно дан.
Как это использовать. Нужно сломать «якорь» (привязку к готовому решению). Поэтому в промпте выше: - исходное ТЗ ставится выше состояния кода, а чужое «готово» объявляется непроверенным; - проверка идёт по пунктам ТЗ, а не по принципу «что тут есть»; - статус «выполнено» разрешён только после запущенной проверки.
Рычаги: - Пункт 3 («не опирайся на существующие тесты») можно убрать, если в проекте тесты надёжны. - Для небольших задач сократите таблицу до списка «пункт → проверено / нет». - Если работа не критична, можно вообще не ремонтировать, а откатить и начать с нуля: чистый старт в статье стабильно лучше. Это вывод из данных, но самой стратегии «откат» авторы отдельно не тестировали.
Шаблон промпта
Шаблон тоже не из статьи, а сделан по её выводам:
Исходное ТЗ ниже. Предыдущий исполнитель сообщил, что работа завершена.
Считай это непроверенным утверждением.
<ТЗ>
{исходный_запрос}
Порядок:
1. Разбей ТЗ на отдельные проверяемые требования.
2. Для каждого найди, где оно реализовано в {репозиторий_или_среда}.
Не нашёл — «не реализовано».
3. Не считай работу выполненной из-за того, что она выглядит
законченной или что {существующие_проверки} проходят.
4. Для каждого требования напиши и запусти свою проверку.
5. Итог — таблица: требование | где | как проверено | статус.
«Выполнено» — только после пройденной проверки.
6. Исправь невыполненное и повтори п. 4–5.
Подставьте: {исходный_запрос} — исходное ТЗ без пересказа, {репозиторий_или_среда} — где работает агент, {существующие_проверки} — тесты, линтер, CI.
Ограничения
⚠️ Лечение не проверено: статья измеряет проблему, а не способы её решения. Промпт выше — гипотеза по мотивам выводов, его эффект авторы не измеряли.
⚠️ Только кодирующие агенты: проверяли на задачах с репозиториями и терминалом. Для текстов, аналитики и переписки перенос вероятен, но в статье не показан.
⚠️ Тесты, а не живые проекты: задачи взяты из бенчмарков, с жёсткими скрытыми тестами. В вашем проекте «правильно» определяет ТЗ, и без внятного ТЗ проверять не против чего.
⚠️ Предшественники — открытые модели: «чужую работу» писали три семейства открытых моделей. С результатами других моделей или людей картина может отличаться (хотя авторы видят падение во всех группах).
⚠️ Разбор неполный: в предоставленном тексте оборван раздел про acceptance bias, поэтому детали поведения агентов (что именно они трогают и не трогают) взяты из аннотации и введения.
Как исследовали
Идея простая: взять известные бенчмарки по программированию (DeepSWE и Terminal-Bench) и вместо чистого старта подсунуть агенту состояние, в котором уже кто-то поработал и сказал «готово», хотя скрытые тесты падают. Предшественниками выступили три открытых модели, которые на каждую задачу получали до восьми часов. Результаты отфильтровали: оставили только случаи, где агент объявил задачу завершённой, но тесты всё равно не прошли. Затем двое людей проверили, что попытка осмысленная и тесты согласуются с ТЗ. Получилось 198 «остаточных» состояний из 111 задач.
Затем пять сильных агентов получали только исходный запрос и это состояние, без истории и без намёка, что попытка не удалась. Запрос, тесты и инструменты оставались теми же, менялся только старт. Результат: успех падал на 20–53 пункта (например, с 72% до 20%) на DeepSWE и на 21–35 пунктов на Terminal-Bench. Первые места в рейтинге на чистом старте не гарантировали лучшего результата при доработке.
Удивило, что состояния были почти правильными: в среднем ~98% тестов уже проходили. Казалось бы, нужно лишь дожать. Но на задачах, которые агент решал с нуля, он с унаследованного состояния проваливался в 61–81% случаев. В 59–88% провалов на DeepSWE агент сдавал работу с тем же набором упавших тестов, то есть фактически ничего не исправлял. Отсюда вывод для практики: «почти готово» опаснее «ничего нет».
Адаптации и экстраполяции
🔧 Техника: ревьюер без доступа к «отчёту о готовности» → меньше якорение
Идея по мотивам статьи: не показывать проверяющему агенту вывод исполнителя («всё сделано, тесты зелёные»). Дайте ему только ТЗ и репозиторий.
Ты — независимый аудитор. Тебе даны только ТЗ и репозиторий.
Отчёта исполнителя у тебя нет и не будет.
Найди, чего в ТЗ не хватает в коде, и докажи запущенной проверкой.
Статья показывает, что даже без отчёта агенты якорятся на самом состоянии. Поэтому здесь заранее пригодится правило «не считать выполненным без запущенной проверки». Эффективность этой связки авторы не проверяли.
Ресурсы
- Работа: SWE-Residual: Evaluating Starting-State Robustness of Coding Agents
- Код: https://github.com/userljz/SWEResidual
- Авторы: Jinze Li, Weijie Liu, Jinfeng Xu, Shuo Yang, Xin Yang, Yang Zhang, Yijun Wang, Zifei Shan, Edith C.H. Ngai
- Организации: The University of Hong Kong, Tencent, University of Tokyo, University of North Texas, The University of British Columbia
- Связанные работы: Recovery-Bench, Handoff Debt, Handoff Tax, FixedBench