StaminaBench: почему все coding agents сдаются после 5 ходов

Представьте: вы описываете AI-ассистенту задачу, он пишет код, вы просите внести правку — и так 10, 20, 50 раз подряд. Звучит как будущее программирования. Но есть проблема, которую все игнорируют: после пятой-шестой итерации код превращается в хаос, и никто точно не знает почему. Теперь — знают.

Исследователи из Amazon Web Services опубликовали StaminaBench — бенчмарк, который тестирует coding agents не на одной задаче, а на последовательности из 100 изменений. Результат: все модели ломаются после 5–6 ходов. Без тестов — раньше. С умным harness — до 12 раз лучше.

Что не так со старыми бенчмарками

Стандартные бенчмарки — SWE-Bench, SWE-BenchPro, HumanEval, MBPP — измеряют долю успешно совершённых задач. Агенту дают одну проблему, он её решает, сессия заканчивается. Это полезно для сравнения моделей, но не отражает реальность: в жизни工程师 не останавливается после первого удачного запуска — он правит, добавляет фичи, рефакторит.

Когда SWE-bench только появился, 10–15% решаемости были нормальным результатом. Сейчас топовые модели достигают 80%. Бенчмарк перестал быть вызовом — модели научились решать именно эти задачи, но это не говорит ничего о том, как они ведут себя на длинных сессиях. StaminaBench закрывает именно этот разрыв.

Как устроен StaminaBench

Агент получает задачу написать REST API сервер. Это не случайной выбор: REST API — это 4 базовых операции (CRUD — Create, Read, Update, Delete), типизированные поля, валидация, бизнес-логика, межсущностные связи. Всё, что нужно для реалистичного бэкенда.

Затем приходит последовательность из 100 change requests: добавить новый эндпоинт, изменить валидацию поля, удалить фичу, переименовать сущность. Каждый запрос — это изменение уже существующего кода, а не новая изолированная задача. Тесты генерируются программно, без участия LLM, что гарантирует воспроизводимость и объективность. Агент и сервер работают в изолированной среде через HTTP — бенчмарк полностью чёрный ящик и language-agnostic.

Начальная схема — 2–3 сущности с 4–5 полями. К 20–30 ходу — уже 10+ сущностей со сложными межсущностными связями и многошаговыми воркфлоу. К 100 ходу кодовая база разрастается до 6000 строк. Это имитирует реальный рост проекта.

Benchmark-таблица: почему StaminaBench уникален

SWE-Bench — один ход, ~50 строк кода, не процедурная генерация. SWE-EVO — один ход, 610 строк. FronTalk — до 10 итераций, 1000 строк, нет процедурной генерации. Commit0 — один ход, 1000+ строк. τ²-bench (customer service) — до 10 итераций, не про код. StaminaBench — 100+ итераций, 1000+ строк, language-agnostic, полностью процедурная генерация.

Ключевое отличие: StaminaBench может генерировать произвольно длинные последовательности изменений, создавая всё более сложные кодовые базы. Другие бенчмарки тестируют одну точку — StaminaBench тестирует траекторию.

7 моделей, 6 harnesses, 20 000+ ходов данных

В экспериментах участвовали семь open-source моделей разного масштаба и архитектуры: Devstral 2 от Mistral (123B dense), Devstral Small 2 (24B dense), GLM-5 от Zhipu (744B/40B MoE), Kimi K2.5 от Moonshot (1T/32B MoE), Nemotron Super от NVIDIA (120B/12B hybrid Mamba-Transformer), Qwen3-Coder-Next от Alibaba (80B/3B MoE), и Qwen3.5-122B от Alibaba (122B/10B MoE). Шесть agent harnesses: OpenCode, Cursor и другие. Итого — 20 сценариев по 100 ходов каждый.

Ключевой результат: без тестового фидбека все модели ломаются на 5–6 ходу. Это не зависит от размера — и 24B, и 1T MoE деградируют примерно одинаково. Код накапливает регрессии: неправильные эндпоинты, сломанная валидация, cascade deletions, rename-баги, неправильные форматы ответов. Без внешнего контроля агент продолжает генерировать следующий слой поверх сломанного.

Типы ошибок: от missing feature до self-kill

Авторы классифицировали ошибки агентов. Без retry-механизма (R=0) распределение следующее: missing feature — агент не реализовал запрошенную функцию полностью; validation too loose — агент ослабил валидацию, пропуская невалидные данные; cascade deletion — удаление одного поля ломает связанные сущности; rename failure — переименование одного поля не распространилось на все ссылки; wrong endpoint — эндпоинт с неправильным путём или HTTP-методом; wrong response format — формат JSON-ответа не соответствует спецификации; type error — несовпадение типов данных; server crash — агент случайно убил процесс; stuck loop — бесконечный цикл; self-kill pkill — агент убил свой собственный процесс.

Наиболее частая ошибка — missing feature. Агент получает change request, частично его обрабатывает, но не доводит до конца. Особенно коварны cascade-эффекты: удаление поля через 10 ходов после его создания может сломать код, который казался стабильным. Агент не видит этих зависимостей без тестов.

Тесты возвращают агента в строй — до 12x улучшение

Второй ключевой результат: когда агенту дают тестовый фидбек и позволяют перезапустить неудачный шаг, количество успешных ходов вырастает до 12 раз. При R=10 (10 retry на каждом ходу) модель, которая без тестов проходит 4 хода, с тестовым циклом проходит 45–50.

Механизм простой, но важный: тесты ловят регрессии сразу, агент получает явный сигнал об ошибке и может исправить конкретную проблему. Без retry ошибка накапливается — каждый следующий ход работает с уже сломанным состоянием. С retry агент откатывается и пробует снова.

Важно: retry-бюджет R — это retry на уровне логики агента, а не инфраструктурные retries. Инфраструктурные retry (до 10 раз) применяются к каждому вызову агента при сбоях связи, malformed tool calls, случайном pkill. Эти retry не влияют на оценку агента — они нужны, чтобы инфраструктурные проблемы не портили метрику.

Но есть нюанс: программная генерация тестов — отдельная сложная задача. Не каждый проект может позволить автоматические тесты, которые покрывают все изменения. Именно это становится bottleneck для внедрения в реальный workflow.

Harness решает не меньше модели

Третий вывод — самый неожиданный. Разница между лучшим и худшим harness для одной и той же модели — до 6 раз. Сильная модель с плохим harness проигрывает слабой модели с хорошим.

Что делает harness хорошим? Это каркас, который определяет: как агент получает задачу, как отправляет код, как получает обратную связь, как хранит состояние между ходами. Хороший harness умеет кэшировать уже проверенный код, правильно разбивать большой запрос на подзадачи, давать агенту структурированную информацию об ошибках, изолировать уже проверенный код от новых изменений.

Для инженера практический вывод: прежде чем выбирать более мощную модель, проверьте, насколько хорошо выстроен ваш harness. Если вы используете bare API-обёртку для coding agent — вы недополучаете до 6x потенциала. Хороший harness — это инженерное решение, а не свойство модели.

Почему vibe coding без тестов — это путь в баги

Vibe coding — парадигма, которую популяризировал Andrej Karpathy: вы описываете задачу словами, AI пишет код, вы правите и повторяете. Это отлично работает для прототипов и учебных проектов. Но StaminaBench показывает, что на дистанции в 5–6 итераций даже самая мощная модель начинает деградировать. Код накапливает баги, и без тестов вы не знаете, где именно.

Проблема не в интеллекте модели. LLM хорошо справляются с генерацией кода — но удержание целостности растущей кодовой базы требует внешнего контроля. Каждый ход добавляет энтропии: новые зависимости, скрытые побочные эффекты, неявные контракты между модулями. Тесты — единственный механизм, который фиксирует эту целостность. Без них вы летите вслепую.

Часто задаваемые вопросы

Можно ли использовать результаты StaminaBench для выбора модели?

Косвенно — да. Но важнее выбрать правильный harness. Разрыв между harness (6x) больше, чем разрыв между моделями одного класса в одинаковом harness. Это значит, что инфраструктура важнее модели — особенно для production-задач, где сессии длятся десятки ходов. Прежде чем менять Qwen3-Coder-Next на Devstral 2, проверьте, какой harness вы используете.

Почему даже 1T MoE модели ломаются так же быстро, как маленькие?

Потому что проблема не в генерации кода, а в накоплении регрессий. Большая модель лучше понимает контекст, но базовый механизм — генерация следующего слоя кода поверх существующего — одинаков. Без тестов ни одна модель не может отследить все побочные эффекты своих изменений на 6+ ходу. С retry-механизмом разница между моделями начинает проявляться — большие модели лучше восстанавливаются после ошибок.

Сколько стоят такие эксперименты по вычислимости?

Авторы не называют точных цифр, но один экспериментальный прогон — 100 ходов, один scenario, один model-harness pair — это сотни API-вызовов. 20 сценариев × 7 моделей × 6 harnesses — это 840 конфигураций. Плюс ablation studies (R=0, R=2, R=10, разные модели). Rough estimate — десятки тысяч долларов на вычислениях. Именно поэтому такие эксперименты редки.

Как применить это в моём workflow?

Если вы используете coding agent для серьёзного проекта, инвестируйте в тестовый контур раньше, чем в более мощную модель. Хороший workflow выглядит так: агент генерирует код → автоматические тесты проверяют регрессии → если тесты красные, агент получает фидбек и retry. Это даёт 12x улучшение. Никакой апгрейд модели не компенсирует отсутствие тестов.

Итог

StaminaBench — редкий бенчмарк, который измеряет не peak performance, а устойчивость на дистанции. Главный вывод: без тестового контура ни один coding agent не выдерживает больше 5–6 итераций. Это не баг конкретной модели — это фундаментальное свойство текущих LLM. Проблема в накоплении регрессий, которое невозможно отследить без внешнего контроля.

Хорошая новость: правильный harness с программными тестами и retry улучшает результат до 12 раз. Прежде чем менять модель на более мощную — проверьте, есть ли у вас тестовый контур. Это даст больше, чем апгрейд. А если у вас уже есть хороший harness — вы входите в то меньшинство, которое получает от AI максимум.