Команда дослідників оприлюднила у вересні 2026 року на arXiv метод оцінки coding-агентів, який аналізує траєкторію їхніх дій замість того, щоб чекати на повний прогін задачі до кінця. Ідея проста: замість запуску агента до фінального результату (успіх/провал тесту) система дивиться на послідовність проміжних кроків і робить висновок про якість роботи агента значно швидше.

Для команд, які будують власних SWE-агентів (Software Engineering agents — AI-системи, що автономно правлять код), бенчмаркінг зазвичай є вузьким місцем: кожен прогін задачі вимагає розгортання ізольованого середовища з репозиторієм, виконання агентом багатокрокової роботи і фінального запуску тестового набору. При десятках чи сотнях задач у бенчмарку та потребі протестувати кілька версій агента це швидко перетворюється на суттєві витрати часу й обчислювальних ресурсів.

За даними arXiv, новий підхід дозволяє суттєво скоротити ці витрати, аналізуючи саму траєкторію дій агента, а не лише кінцевий результат.

Що саме запропонували дослідники?

Суть методу — оцінювати SWE-агента за тим, які дії він виконує на шляху до розв'язання задачі, а не лише за фінальним результатом «пройшов тест чи ні». Традиційні бенчмарки на кшталт SWE-bench вимагають довести кожну задачу до кінця: агент має відредагувати код, запустити тести і отримати остаточний вердикт. Запропонований метод натомість аналізує траєкторію — послідовність кроків, рішень і дій агента — і за нею оцінює якість роботи, не чекаючи повного завершення кожного тестового прогону.

Чому традиційний бенчмаркінг настільки дорогий?

Кожна задача в типовому SWE-бенчмарку — це окреме ізольоване середовище: копія репозиторію, залежності, тестовий раннер. Агент виконує задачу за багато кроків (читає issue, шукає релевантні файли, вносить правки, запускає тести, за потреби повторює цикл), і весь цей процес потрібно тримати «живим» до отримання фінального вердикту. Помножте це на десятки чи сотні задач бенчмарку та на кожну нову версію агента, промпту чи базової моделі, яку команда хоче протестувати, — і витрати compute й часу ростуть лінійно з кожним експериментом. Паралелити такі прогони теж непросто: ліміти API, rate limits провайдерів моделей і вартість токенів швидко перетворюють великий бенчмарк на дорогий проєкт сам по собі.

Кому і навіщо це знадобиться на практиці?

Найбільше від дешевшого бенчмаркінгу виграють команди, які самі розробляють або тонко налаштовують coding-агентів і регулярно тестують нові версії — зміну промпту, іншу базову модель, новий інструмент у наборі агента. Замість того щоб чекати повного прогону всього бенчмарку після кожної зміни, можна швидше й дешевше отримати сигнал про якість агента за траєкторією його дій. Це особливо цінно на ранніх ітераціях розробки, коли команда перевіряє багато варіантів поспіль і повний прогін кожного був би невиправдано дорогим. Ми вже писали про те, хто перевірить навички AI-агента, перш ніж він зіпсує продакшн — дешевший бенчмаркінг напряму стосується цієї проблеми. На практиці таким чином дешевше перевіряти:

Висновок AiiN

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

Що таке SWE-агент і чим він відрізняється від звичайного чат-бота?

SWE-агент (Software Engineering agent) — це AI-система, яка автономно виконує задачі розробки: читає опис проблеми, орієнтується в структурі репозиторію, редагує код у кількох файлах і запускає тести, щоб перевірити власну роботу. На відміну від чат-бота, який видає код одноразово, SWE-агент діє циклами «спроба — перевірка — виправлення» протягом усього завдання.

Чи означає новий метод, що повний прогін бенчмарку більше не потрібен?

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