Klavis AI публикува Multi-step SWE, benchmark за последователна работа на coding агенти върху собствените им реализации. Препринтът е подаден на 4 ноември 2026 г. Задачите са 69, с по 5–15 зависими инженерни заявки. Най-силната оценена комбинация решава 18,5% от целите изпълнения; 38 задачи не са решени от никой от деветте тествани модела. Това са резултати на авторите, не независимо измерване на SIExpo.

Защо продължението има значение

Обичайна демонстрация показва дали агентът може да изгради една функция. Реалният проект често продължава с промяна на изисквания, миграция или оптимизация. Ако първоначалният дизайн е неудобен, следващата работа започва именно от него. Multi-step SWE прави тази зависимост част от оценката, вместо да предоставя нова чиста отправна точка за всяка заявка.

Репозиторият съдържа 574 стъпки на девет езика и използва формата на Harbor. Една стъпка е пълна инженерна заявка, а не извикване на инструмент. Проверките работят в отделни verifier контейнери. Публичното изпълнение изисква среда с Docker, ресурси и достъп до избрания модел; отвореният benchmark не прави изчисленията или външните услуги безплатни.

Публикацията на Klavis отделя успеха на отделните стъпки от успеха на цяла задача. За Claude Opus 5.5 с Claude Code тя отчита 56,8% преминали стъпки и 18,5% решени изпълнения. По-късните стъпки продължават и след неуспех, но това не заличава предишния провал при крайния показател. Pass@4 е друг показател: поне един успех в четири опита.

Как да четем сравнението

Резултатите сравняват модел заедно с работната му обвивка и настройките. Те не са лабораторно изолирана класация само на теглата. Авторите посочват и ограничения: преобладаване на C/C++ задачи, възможно познаване на публичен код и липса на отделна отправна линия, която да изолира натрупаните грешки от трудността на по-късните стъпки. По-дълъг бюджет сам по себе си не е доказано решение.

Това позволява по-умерен извод от „агентите не могат да програмират“. Една система може да е полезна за много отделни промени и все пак да не завърши цяла поредица по всички критерии. Показателите отговарят на различни въпроси. Ако се избира инструмент за дълъг проект, процентът завършени вериги е важен наред с качеството на отделните редакции.

Редакционен пример за собствен проект

Представете си малко приложение, което първо записва обяви, после добавя търсене, а след това роли и модерация. Първата версия може да изглежда завършена, но следващите изисквания проверяват дали моделът е оставил ясни граници между данни и права. Това е наш пример за зависими заявки, а не допълнителен случай от публикувания benchmark.

За подобен вътрешен опит очакванията могат да се запишат преди началото. След всяка стъпка се проверяват новото изискване и вече обещаното поведение. Ако търсенето работи, но редакцията допуска промяна на чужда обява, отделен видим успех не е достатъчен за целия проект. Проверяващата процедура трябва да следва първоначалните условия, а не само плана, който агентът сам си е съставил.

Важно е да се запази работната история. Подмяната на проблемния код с готово решение между стъпките би измерила друга способност. Повторните опити също трябва да се отчитат: резултатът от най-добрия опит не е равен на вероятността една обикновена сесия да приключи успешно.

Прегледът трябва да отчете и дали агентът правилно разпознава незавършената работа. Финалното съобщение, че всичко е готово, доказва какво е заявил агентът, но не и че всяко изискване е изпълнено. Сравнението с независими проверки отделя успешната работа от признат частичен резултат и от неправилно заявено приключване.

Публичните задачи дават основа за такива изследвания, без да отменят прегледа на лицензи, ресурси и безопасно изпълнение. SIExpo е проверил достъпните материали и методиката, но не е инсталирал benchmark или стартирал моделни изпитания. Стойността на новината е в по-реалистичния въпрос: може ли агентът да продължи да строи върху решенията, които вече е взел?