TL;DR
WideSWE — это бенчмарк из 120 реальных задач, где одну фичу или один багфикс нужно внести сразу в несколько репозиториев. Главная практическая находка: агент редко ломает код, но часто не доделывает работу. Он чинит один репозиторий, видит зелёные тесты и останавливается. Остальные репозитории остаются нетронутыми.
Вот как это выглядит. Вы просите «добавь поддержку в Go, Python и Ruby SDK». Агент делает Go, пишет «готово», а про Python и Ruby молча забывает. Иногда он даже сам называет нужные изменения в плане, но реализует только часть. Есть и вторая беда: агент пишет свои тесты по своему же неверному пониманию задачи. Тесты проходят, а нужное поведение не сделано.
Что с этим делать, зависит от типа задачи. Багфиксы лучше решать отдельным запуском на каждый репозиторий: узкий фокус помогает не забывать. Фичи, где репозитории должны сойтись по контракту, лучше делать в общем рабочем пространстве. Там агент видит соседний код и сверяется с ним. Отдельные запуски расходуют примерно втрое больше запросов и не дают выигрыша в целом.
Схема метода
В статье нет одного «метода». Это сравнение двух режимов запуска агента:
РЕЖИМ A (совместный): один запуск → агент видит все репозитории → правит сразу везде
+ видит контракты и соседние реализации, может сверять поведение
− забывает часть репозиториев, останавливается после первого успеха
РЕЖИМ B (раздельный): по одному запуску на репозиторий → один и тот же промпт
+ узкий фокус, не забывает свой репозиторий
− не видит соседей, строит неверные догадки об их интерфейсах
− расходует втрое больше запросов
Выбор режима:
Багфикс → режим B
Фича с контрактом → режим A + явный чек-лист репозиториев
Любой режим → финальная проверка: «каждый репозиторий из списка изменён и проверен?»
Пример применения
Задача: У вас сервис доставки еды в духе «Самоката». Три репозитория: delivery-api (Go), delivery-web (React), courier-app (Kotlin). Нужна фича: клиент оставляет «комментарий для курьера» («домофон не работает, звоните»). Поле должно уйти через API и отобразиться у курьера. Это фича с общим контрактом, поэтому берём совместный режим и страхуемся от «остановился на первом».
Промпт:
Рабочее пространство содержит три репозитория: delivery-api, delivery-web, courier-app.
ЗАДАЧА: добавить поле «комментарий для курьера» (строка до 300 символов, необязательное).
Клиент вводит его в веб-форме оформления заказа. API сохраняет его в заказе.
Приложение курьера показывает его на экране заказа.
ПЕРЕД НАЧАЛОМ работы:
1. Выпиши список ВСЕХ репозиториев, которые нужно изменить, и что именно в каждом.
2. Выпиши, что считается «готово» для каждого репозитория (поведение, не названия функций).
ПРАВИЛА:
- Сначала изучи контракт в delivery-api, потом подгоняй под него web и courier-app.
- Не останавливайся, пока не обработан каждый репозиторий из списка.
- Прохождение тестов в одном репозитории — это не конец задачи.
- Свои тесты пиши по требованиям из задачи, а не по своей реализации.
ПЕРЕД ЗАВЕРШЕНИЕМ:
Пройди по списку и для каждого репозитория ответь: изменён? Поведение соответствует
критерию «готово»? Сверь формат поля (имя, тип, пустое значение) во всех трёх местах.
Если хоть один пункт не выполнен — продолжай работу.
Результат: Агент сначала выдаст список затронутых репозиториев и критерии готовности. Дальше он будет править код, начиная с API. В конце появится явная сверка по каждому репозиторию. Это не гарантирует успех, но снижает шанс «забыл фронт» или «поле называется по-разному в API и в приложении».
Почему это работает
Слабость. Агент идёт по пути наименьшего сопротивления. Тесты в одном репозитории позеленели, и работа ощущается законченной. Чем больше объём, тем выше шанс забыть часть. В статье агент сам планировал изменения в обоих репозиториях, но потом ушёл в один. Ещё одна ловушка: агент пишет тесты по своей же реализации. Если он неверно понял задачу, код и тесты разделяют одну ошибку, и проверка ничего не ловит.
Сильная сторона. Когда агент видит соседние репозитории, он использует их как справочник. Он берёт интерфейс из одного и подгоняет под него другой. Он сравнивает две реализации одного поведения и находит расхождение. Раздельные запуски этого лишены: агент делает неверные допущения о соседнем репозитории.
Как использовать. Явный список репозиториев и критериев «готово» превращает размытое «сделай везде» в чек-лист. Финальная сверка по списку закрывает дыру «остановился после первого успеха». А выбор режима по типу задачи позволяет использовать узкий фокус там, где он помогает (багфиксы), и общий контекст там, где он нужен (фичи).
Рычаги управления: - Чек-лист репозиториев в начале → убери для задачи в одном репозитории, оставь для любой мультирепо-задачи. - Критерии «готово» на поведении, а не на тестах → ловят случаи, когда тесты верны, а поведение нет. - Порядок «контракт первым» → меняй под задачу: что является источником истины, то и изучается первым. - Финальная сверка → можно вынести в отдельный короткий запрос после завершения.
Шаблон промпта
Рабочее пространство содержит репозитории: {список_репозиториев}.
ЗАДАЧА: {описание_фичи_или_бага}
Ожидаемое поведение: {что_должно_происходить_в_итоге}
ПЕРЕД НАЧАЛОМ:
1. Выпиши ВСЕ репозитории, которые нужно изменить, и что именно в каждом.
2. Для каждого репозитория опиши критерий «готово» через поведение.
ПРАВИЛА:
- Источник контракта: {репозиторий_с_контрактом}. Изучи его первым.
- Не останавливайся, пока не обработан каждый репозиторий из списка.
- Зелёные тесты в одном репозитории — не конец задачи.
- Тесты пиши по требованиям из задачи, а не по своей реализации.
- Если сомневаешься, что репозиторию не нужны правки, объясни почему.
ПЕРЕД ЗАВЕРШЕНИЕМ:
Для каждого репозитория из списка ответь: изменён? Критерий «готово» выполнен?
Сверь форматы данных (имена, типы, пустые значения) между репозиториями.
Если хоть один пункт не выполнен — продолжай.
Что подставлять: {список_репозиториев} — имена из вашего рабочего пространства. {описание_фичи_или_бага} — задача своими словами с граничными случаями. {репозиторий_с_контрактом} — где живёт API или общая схема.
Для багфикса запускайте отдельную сессию агента на каждый репозиторий с одним и тем же описанием. Из шаблона оставьте только задачу и критерий «готово» для этого репозитория.
Шаблон собран из паттернов отказов, найденных в статье. Авторы сами такой промпт не проверяли.
Ограничения
⚠️ Шаблон не проверен напрямую: в статье измерены только сами отказы агентов и сравнение режимов «совместно / раздельно». Что именно чек-лист снижает долю забытых репозиториев, остаётся гипотезой.
⚠️ Вывод про режимы опирается на небольшую выборку: сравнение сделано на одной связке агента и модели, на 89 задачах. Багфиксов в нём всего 29. Разница в 10 п.п. по типам задач может сдвинуться на другой выборке.
⚠️ Раздельный запуск не лечит неверную реализацию: если репозиторий уже изменён, но неправильно, отдельный запуск почти не помогает. Он хорошо работает там, где агент вообще не тронул репозиторий.
⚠️ Больше шагов — не значит лучше: в статье агенты делали сотни запросов и всё равно оставляли работу недоделанной. Длинная сессия не гарантирует завершённость.
⚠️ Узкая область: результаты получены на задачах из открытых экосистем (Sentry, Kubernetes, Symfony и др.). Для вашего монорепо или микросервисов поведение может отличаться.
Как исследовали
Исследователи взяли 200 крупнейших GitHub-организаций и нашли 103 экосистемы, где репозитории работают как единый продукт. Из 1,7 млн pull request'ов (PR, запросов на слияние) они выделили 109 тысяч, ссылающихся на соседние репозитории. Ручной отбор и запуск тестов оставили 120 задач: 60 багфиксов и 60 фич в 41 экосистеме. Задача считалась решённой, только если прошли тесты во всех целевых репозиториях.
Проверили семь связок «агент + модель». Лучшая решила 42,5% задач, остальные от 11 до 37,5%. При этом лучшая связка хотя бы в одном репозитории преуспевала в 83% задач. Разрыв между «частично» и «полностью» и есть главная находка. Среди провалов лучшей связки в 48 из 69 случаев один репозиторий проходил все целевые тесты, а другой нет. Существующие тесты (регрессии) почти не ломались. Агенты не портят, а недоделывают.
Неудачные запуски разобрали по трём причинам: не увидел весь объём, увидел но не сделал, сделал но неверно. Причины сильно зависели от модели. Одна часто застревала на «изучении» и не доходила до реализации. У других ошибки чаще возникали уже после правок. Одна и та же модель в разных оболочках агента показала разный результат: 42,5% против 32,5%. Значит, инструмент важен не меньше модели.
Самый интересный эксперимент — совместный запуск против раздельных на 89 задачах с одинаковыми промптами. Итог почти ничья (40% против 36%), но внутри у 22% задач результат поменялся. Багфиксы лучше решались раздельно, фичи лучше совместно. Раздельные запуски требовали втрое больше запросов. Для практики вывод такой: выбирайте режим по типу задачи, а не «всегда так» или «всегда эдак».
Ещё одна деталь: авторы переписали часть скрытых тестов, потому что те требовали конкретных имён функций или точного текста ошибки, которых не было в задаче. Иначе правильные решения отвергались бы.
Адаптации и экстраполяции
🔧 Техника: критерий «готово» через поведение → меньше ложных зелёных тестов
В статье агент использовал строку с именем исключения, хотя задача требовала структурированную информацию. Тесты были написаны под ту же ошибку. Добавьте в промпт:
Для каждого тестового сценария укажи, какую фразу из задачи он проверяет. Если сценарий нельзя привязать к фразе из задачи — удали его.
🔧 Техника: сверка «до и после» → ловит остановку на первом успехе
Вместо одного финального вопроса задайте короткий отдельный запрос после того, как агент сказал «готово»:
Вот список репозиториев: {список}. Покажи git diff --stat по каждому. Для каждого репозитория без изменений объясни, почему правки не нужны.
Экстраполяция: правила в файле инструкций агента. Если вы часто работаете с мультирепо-пространством, перенесите правила из шаблона в CLAUDE.md или AGENTS.md:
## Правила для задач в нескольких репозиториях
- В начале всегда составляй список затрагиваемых репозиториев.
- Задача не закончена, пока каждый репозиторий из списка не обработан или не обоснован как не требующий правок.
- Зелёные тесты в одном репозитории — не сигнал остановки.
- Перед завершением сверь формат данных между репозиториями.
Это моя адаптация. Авторы такой файл не тестировали.
Ресурсы
- WideSWE: Can Coding Agents Coordinate Changes Across Repositories? Zhejiang University и Tsinghua University (авторы: Wang Baoyi, Wang Xingliang, Zhi Chen, Wu Jiayi, Wu Kaiming, Yin Jianwei и др.)
- Связанные бенчмарки: SWE-bench (Jimenez et al.), DeepSWE (Huang et al.), ProgramBench (Yang et al.)
- Примеры экосистем из статьи: Sentry (github.com/getsentry), Kubernetes, Symfony, Ansible
- Рейтинг организаций: gitstar-ranking.com/organizations