Дослідники представили бенчмарк SWE Refactor Bench, який перевіряє AI coding-агентів не на одноразових pull request, а на повній міграції технологічного стеку в реальному репозиторії — задачі, що розтягується на десятки послідовних кроків. За даними arXiv, навіть провідні агенти суттєво втрачають точність і послідовність дій, коли горизонт задачі зростає з кількох кроків до десятків.

Це важливо, бо більшість публічних бенчмарків для coding-агентів — SWE-bench та подібні — вимірюють здатність вирішити один ізольований баг чи невелику фічу в межах одного pull request. Реальний рефакторинг виглядає інакше: оновити версію фреймворку, перенести залежні модулі, виправити ланцюг регресій, які виникають одна за одною, і зробити це так, щоб репозиторій залишався у робочому стані на кожному кроці.

SWE Refactor Bench закриває саме цей розрив — і показує, що розрив між «розв'язати один баг» і «провести проєкт через довгу трансформацію» для сучасних агентів значно ширший, ніж припускали попередні тести.

Що саме перевіряє SWE Refactor Bench?

Бенчмарк ставить агента перед задачею повної міграції стеку в реальному репозиторії, а не перед точковим фіксом. Замість одного pull request агент має провести серію взаємопов'язаних змін — і кожна наступна залежить від того, наскільки коректно виконана попередня.

• Задачі побудовані на реальних, а не синтетичних репозиторіях
• Горизонт виконання — десятки кроків замість одного-двох
• Успіх залежить від збереження працездатності коду на кожному проміжному етапі, а не лише в фіналі

Такий формат ближчий до того, що насправді роблять інженерні команди, коли переводять сервіс на нову версію мови, оновлюють ORM чи мігрують з одного фреймворку на інший.

Чому довгі задачі «ламають» навіть топові агенти?

За даними arXiv, продуктивність агентів падає саме з ростом кількості необхідних кроків — короткі задачі агенти вирішують відносно надійно, а на горизонті в десятки дій якість суттєво просідає. Це узгоджується із загальною проблемою agentic-систем: помилка на кроці N не зникає, а переноситься на кроки N+1, N+2 і далі, поки не накопичиться до стану, який агент вже не здатен відкотити чи виправити самостійно.

У короткому pull request агент може дозволити собі одну неточність, яку легко відловить рев'юер. У багатокроковій міграції та сама неточність на десятому кроці змінює контекст для всіх наступних тридцяти — і саме тут проявляється різниця між «агент, що вирішує задачі» і «агент, що веде проєкт».

Кому і як це варто враховувати вже зараз?

Якщо ви обираєте coding-агента для рефакторингу чи міграції стеку, наявність високого результату на SWE-bench чи подібних одно-PR бенчмарках нічого не каже про те, як агент поводитиметься на завданні, що триває днями. За нашою оцінкою, перед тим як довіряти агенту багатофайлову міграцію без нагляду, варто прогнати його на власному тестовому репозиторії саме на задачі з довгим горизонтом, а не орієнтуватися на маркетингові цифри одиничних бенчмарків.

Практично це означає: розбивайте довгу міграцію на контрольні точки, де людина перевіряє стан репозиторію, а не покладайтеся на те, що агент самостійно доведе весь ланцюг змін до кінця. Як ми вже писали, розбираючи чому agentic AI не масштабується без зміни процесів і штату, довгі автономні ланцюжки дій вимагають не лише сильнішої моделі, а й перебудови робочого процесу навколо неї.

Висновок AiiN

SWE Refactor Bench фіксує те, що практики вже підозрювали: горизонт задачі — окрема вісь складності, яку одно-PR бенчмарки просто не бачать. За нашою оцінкою, індустрії найближчим часом бракуватиме не моделей, здатних написати правильний код на кроці, а агентних систем, що вміють тримати консистентний стан репозиторію протягом днів роботи без людського втручання на кожному кроці. Поки цього нема, довгі рефакторинги залишаються задачею для людини з агентом-помічником, а не для агента, якому просто віддали ключі від репозиторію.

Що таке SWE Refactor Bench?

Це бенчмарк для оцінки AI coding-агентів на задачах повної міграції стеку в реальних репозиторіях, а не на ізольованих pull request. Він вимірює здатність агента виконувати десятки послідовних кроків, зберігаючи працездатність коду на кожному з них.

Чи означає це, що топові агенти взагалі не годяться для рефакторингу?

Ні — вони добре справляються з короткими та середніми задачами. Проблема виникає саме на довгому горизонті, коли кроки накопичуються, а помилки одного кроку впливають на всі наступні.

Чи означає це, що бенчмарки на кшталт SWE-bench більше не потрібні?

Ні, вони лишаються корисними для оцінки базової якості коду на коротких задачах. Але для рефакторингу й міграцій варто додатково перевіряти агента саме на довгих багатокрокових сценаріях, які SWE-bench не покриває.