TL;DR
Кодинг-агенты хорошо решают задачу в неподвижном мире и плохо переживают изменения в ходе работы. Коллега поправил файл, поменялись права доступа, всплыло новое требование. SWE-Shift сравнивает две ветки из одной точки сессии: в одной ничего не меняется, в другой прилетает правка. Так видно, потерял ли агент успех из-за самого изменения, а не потому, что задача ему не по силам.
Агент доделывает исходную задачу, но по дороге ломает то, что было сделано правильно. Он стирает чужой API, чтобы тесты зазеленели. Правит код по устаревшей информации и не перепроверяет её. Продолжает вызывать инструмент по старым правилам. Тесты при этом проходят, и кажется, что всё хорошо. В лучшей системе успех в «чистой» ветке был 67%, а после изменения упал до 25%. А в двух классах изменений (смена инструментов и сессии, устаревшие доказательства) ни одна из 17 систем не справилась ни разу.
Метод — оценочный протокол из четырёх шагов: сохранить состояние, разветвить, внести изменение, проверить по новым требованиям. Проверка идёт не только по исходным тестам, но и по сохранению чужой работы, свежести данных и отсутствию запрещённых действий. Для практика отсюда вытекает чек-лист: что проверять после изменения в сессии с агентом.
Схема метода
ШАГ 1: Агент работает над задачей до заданной точки (10%…90% пути) → снимок состояния
ШАГ 2: Снимок восстанавливается дважды → две одинаковые ветки
ШАГ 3: Clean — продолжение без изменений.
Shifted — в ветку вносят релевантное изменение (правка коллеги,
новый инструмент, новое требование, устаревшие данные)
ШАГ 4: Проверка по условиям, актуальным для каждой ветки:
задача + сохранение чужой работы + восстановление состояния +
права + побочные эффекты + свежие доказательства + бюджет
→ успех только если ВСЕ проверки пройдены
Исследователи прогоняют это автоматически. Читатель может повторить протокол вручную на своём агенте (см. шаблон ниже).
Пример применения
Задача: Вы ведёте бэкенд интернет-магазина на Django. Claude Code уже полчаса рефакторит расчёт скидок. Пока он работает, коллега Миша добавляет в модуль оплаты новую функцию для работы с ЮKassa, и она лежит в тех же файлах. Нужно, чтобы агент учёл правку, не снёс Мишину функцию и не отчитался о готовности по старым данным.
Промпт (сообщение агенту посреди сессии):
Стоп. Пока ты работал, в репозитории изменились файлы: Миша добавил
функцию refund_partial() в payments/services.py и обновил схему заказа.
Эти изменения легитимны, их нельзя откатывать или переписывать.
Что нужно сделать до продолжения:
1. Заново прочитай текущее состояние payments/services.py и models/order.py
(не опирайся на то, что читал раньше).
2. Выпиши список того, что изменилось и что из твоих уже сделанных правок
может быть затронуто.
3. Продолжай рефакторинг скидок, сохранив refund_partial() и всё, что
добавил Миша.
4. Перед тем как сказать «готово»: запусти тесты ЗАНОВО на текущем коде
и покажи вывод. Затем проверь, что refund_partial() на месте и
вызывается так же, как до твоих правок. Не ссылайся на прошлые
прогоны тестов.
Результат: Агент сначала перечитает файлы и выпишет список затронутых мест. Затем продолжит работу, не трогая чужую функцию. В конце он покажет свежий вывод тестов и отдельную проверку, что функция коллеги цела. Это закрывает три провала из кейсов статьи: удалённый чужой API, правку без нового чтения данных и отчёт по старым результатам.
Это применение выводов статьи, а не готовый промпт из неё. Сам промпт авторы не тестировали.
Почему это работает
Слабость. Агент держит в «голове» контекст сессии: всё, что он прочитал и сделал раньше. Когда мир меняется, этот контекст устаревает, но выглядит по-прежнему убедительно. Агент опирается на него, а не перечитывает реальность. Он оптимизирует «пройти исходные тесты». Чужая правка, свежие данные и права доступа в эти тесты не входят, поэтому их потеря остаётся незамеченной. В кейсе с Django все 39 исходных тестов прошли, а API коллеги пропал.
Сильная сторона. Если явно сказать агенту, что изменилось и что нужно сохранить, и потребовать свежие проверки, он выполняет такие шаги. Он умеет перечитывать файлы, заново запускать тесты и сверять списки. Ему просто не приходит в голову делать это самому.
Как это использует метод. Протокол превращает неявное требование («не сломай чужое, проверь свежее») в явные проверки. Из этого получаются рычаги управления: - Что проверять после изменения: сохранение чужой работы, свежесть данных, права и побочные эффекты. - Когда вмешиваться: статья проверяла девять точек, от начала до конца сессии. У разных систем поздние точки ведут себя по-разному: у GPT и Claude результат ниже, у Kimi, DeepSeek и GLM нет. Не полагайтесь на «в конце сессии безопаснее». - Что считать успехом: только если пройдены все применимые проверки, а не одни исходные тесты.
Шаблон промпта
Авторы не публикуют промпты для агента. Они публикуют структуру сценария: четыре обязательных элемента. Шаблон ниже повторяет эту структуру, чтобы протестировать своего агента на своей задаче.
Мы тестируем, как ты переживаешь изменения посреди работы.
{исходная_задача}
{что_изменится_во_время_работы}
{как_агент_узнает_об_изменении}
{что_должно_работать_по_исходной_задаче}
{что_уже_сделанное_и_чужое_должно_остаться}
{что_нужно_проверить_заново_на_актуальном_состоянии}
{чего_делать_нельзя}
Правила прогона:
1. Работай над задачей до точки {процент_прогресса}.
2. Затем я внесу изменение и продолжу сессию.
3. Успех = выполнены ВСЕ проверки из , а не только исходные тесты.
Что подставлять:
- {что_изменится_во_время_работы}: реальная правка коллеги, новое требование заказчика, смена токена или прав.
- {как_агент_узнает_об_изменении}: вы пишете в чат, меняется файл, меняется ответ инструмента. Проверьте разные варианты.
-
🚀 Быстрый старт — вставь в чат:
Вот шаблон сценария для проверки кодинг-агента на устойчивость к изменениям
в ходе работы. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что за проект, что может поменяться посреди работы и что нельзя сломать. Это нужно, чтобы заполнить
Ограничения
⚠️ Это бенчмарк, а не рецепт. Авторы показывают, где агенты ломаются, и частично проверяют диагностические приёмы (обновление состояния, сброс истории, увеличение бюджета токенов). Готовых промптов, которые это чинят, в статье нет. Всё, что ниже в «Адаптациях», — экстраполяция.
⚠️ Часть результатов неполна. В предоставленном тексте раздел диагностических контролей обрывается. Видно только, что сброс истории дал самый большой прирост в четырёх из пяти систем. Размер эффекта в доступном тексте не приведён.
⚠️ Только кодинг-агенты. Изменения вносили в репозитории из SWE-bench. Для чат-задач без инструментов и файлов вывод применим слабо.
⚠️ Тяжёлые провалы. Смена инструментов и сессий, а также устаревшие доказательства дали ноль у всех систем. Никакой промпт из этой статьи гарантированно не спасёт. Вручную проверяйте эти зоны.
⚠️ «Позже — хуже» не закон. У части систем поздние вмешательства проходят лучше. Единого правила, когда безопаснее менять условия, нет.
⚠️ Точечные значения. Основные результаты даны без доверительных интервалов.
Как исследовали
Идея была простой. Агент начинает работать над задачей из SWE-bench, в нужной точке сохраняется его состояние (история, рабочая папка, инструменты, счётчики). Дальше состояние восстанавливается дважды. В «чистой» ветке ничего не меняется. В «изменённой» вносится правка, например коллега добавляет API, меняются права или прилетает новое требование. Обе ветки стартуют из одного места, поэтому разница между ними точно объясняется изменением, а не случайностью прогона.
Всего собрали 120 сценариев на 23 снимках из 17 репозиториев. Они разбиты на 12 семейств изменений и 9 точек вмешательства (от 10% до 90% пути). Получилось 1 080 пар на систему. Протестировали 17 кодинг-систем, у каждой бюджет 1 млн токенов после развилки. Успех засчитывали только при прохождении всех применимых проверок: задача, сохранение чужой работы, свежие доказательства, права, побочные эффекты.
Результат однозначный: все 17 систем хуже в «изменённой» ветке. Лидер падает с 67% до 25%. «Парный успех» (оба продолжения удались) у него всего 20%. Удивил разрыв между общей силой и устойчивостью. Kimi-K3 сильнее DeepSeek-V4-Pro по обычному успеху, но слабее по сохранению успеха после изменения. А у Kimi-K2.6 при невысоком обычном результате сохраняется больше трети успешных прогонов.
Аудит реальных траекторий показал, как именно агенты ломаются. В Django агент удалил API коллеги при исправлении исходной ошибки, и 39 тестов прошли. В Astropy агент откатил внешний эффект, но проверка рабочей папки провалилась. В scikit-learn агент восстановил доступ к актуальным данным, но потом правил код, не обратившись к ним снова. Вывод для практики: зелёные тесты не доказывают, что агент ничего не сломал.
Адаптации и экстраполяции
🔧 Техника: блок «изменения в ходе работы» в файле инструкций агента → агент по умолчанию перепроверяет мир.
Этот блок собран из провалов кейсов статьи. Сам блок авторы не проверяли.
## Если что-то изменилось во время работы
Если я сообщил об изменении, файлы изменились без твоего участия
или ответ инструмента отличается от прежнего:
1. Перечитай актуальное состояние затронутых файлов. Не опирайся на то, что читал раньше.
2. Выпиши, что изменилось и какие твои прошлые правки это затрагивает.
3. Чужие правки не откатывай и не переписывай, если я не просил.
4. Перед «готово»: запусти проверки заново на текущем коде. Результаты прошлых прогонов не считаются.
5. Если инструмент, права или сессия изменились, проверь, какой интерфейс
разрешён сейчас, и не используй прошлые вызовы как рабочие.
Экстраполяция: сброс истории со сводкой. В статье сброс истории дал наибольший прирост в диагностике. Реализация там неизвестна, поэтому ниже один из вариантов: новая сессия вместо продолжения старой.
Мы начинаем новую сессию. Вот сводка предыдущей работы:
- Исходная задача: {задача}
- Что сделано и проверено: {список}
- Что изменилось в проекте с тех пор: {изменения}
- Что нельзя трогать: {чужие_правки}
Сначала прочитай текущее состояние репозитория, потом сверься со сводкой.
Если они расходятся, доверяй репозиторию и скажи мне об этом.
Ресурсы
- SWE-Shift: Evaluating Coding Agents in Evolving Workspaces: Victor Shea-Jay Huang, Rongqing Li, Zhangyue Yin, Kelong Mao, Yaqi Zhao, Xinyuan Wang, Yao Yin, Lirui Luo, Renrui Zhang, Hongsheng Li. MMLab (The Chinese University of Hong Kong), Fudan NLP Lab (Fudan University), HKUST, Peking University.
- Код: https://github.com/JeixHuang/SWE-Shift
- Опираются на SWE-bench Verified, Multi-SWE-bench, SWE-bench Multilingual. Родственные работы: SWE-Touch, SyncMind, SWE-INTERACT, SpecPath, ToolSandbox, Gaia2.