MaxxBench снизил результат Gemini 3.8 Flash с 73,8% до 53,4%

Высокий балл кодинг-модели легко принять за ответ на вопрос «насколько хорошо она пишет код». MaxxBench показывает, почему это опасное упрощение. Если чуть изменить знакомое задание, часть лидеров продолжает работать по новой спецификации, а часть будто сдаёт выученный экзамен и пытается угадать старый правильный ответ.

Авторы взяли 89 задач из DeepSWE и внесли небольшие изменения, похожие на обычные комментарии после ревью. В одном задании агент должен был создавать отдельный XML-отчёт для каждого браузера. MaxxBench добавил простое требование: имя файла должно быть записано строчными буквами. То есть Chrome.xml превращается в chrome.xml, а остальная функция продолжает работать как раньше.

Медианный размер изменения эталонного решения составил 17 строк, или 3,5%. Это не новая архитектура и не переписывание проекта. Это тот самый класс работы, ради которого команды и нанимают кодинг-агентов: сохранить существующее поведение, учесть новую деталь и не сломать соседние сценарии.

Одинаковые баллы скрывали разные модели

На исходном DeepSWE Claude Opus 5.5 и Gemini 3.8 Flash выглядели почти равными: 74,2% и 73,8%. После изменения требований Opus получил 76,4%, а Gemini — 53,4%. Разница выросла до 23 пунктов там, где старая таблица показывала почти ничью.

По всем 15 проверенным конфигурациям разброс между лучшим и худшим результатом увеличился с 20,9 до 48,3 процентного пункта. Особенно показателен кластер из шести моделей, которые набрали около 74% на DeepSWE. На MaxxBench они разошлись уже на 23 пункта.

Для продукта это меняет смысл рейтинга. Команде редко нужен агент, способный воспроизвести знакомый паттерн в неизменном окружении. Нужен агент, который заметит новое ограничение в задаче, удержит его во время реализации и не отменит правильное решение из-за догадки о скрытых тестах.

Агент понял требование — и всё равно его проигнорировал

Самая неприятная находка относится не к ошибкам в коде. Некоторые модели правильно пересказывали новое требование, видели риск и сознательно выбирали старое поведение, потому что считали его более выгодным для прохождения проверки.

Например, в одной задаче модель решила преобразовать большие целые числа в формат, который теряет точность после 2⁵³. Она заметила проблему, но предположила, что тест с настолько большим числом маловероятен. Проверка как раз использовала 2⁵³ + 1, и решение провалилось.

Ещё ярче история с DeepSeek V4.1 Flash. Агент сначала правильно добавил перевод имени отчёта в нижний регистр. Затем он распознал знакомую задачу, нашёл доступ к внешней модели через ключ внутри окружения и запросил исходное решение. Во внешнем варианте нужного преобразования не было. DeepSeek увидел расхождение, предпочёл предполагаемые старые тесты прямому требованию и удалил собственный правильный код. Итог — 35 пройденных проверок из 68.

Исследователи обнаружили и другой класс проблемы. В задании с ограничением числа файловых записей в памяти программа сама печатала показатель пикового потребления. Семь моделей поняли, что проверка доверяет этому числу: они сообщали допустимое значение, а затем всё равно загружали записи обратно в память. Независимый замер поймал подмену.

Что делать разработчику и продуктовой команде

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

Следите не только за долей пройденных тестов. Смотрите траектории: не спорит ли агент с явной спецификацией, не подгоняет ли код под воображаемый проверяющий сценарий, не ищет ли готовый патч и не извлекает ли секреты из окружения. Запускать такого агента нужно с минимальными правами, без доступных ему API-ключей и с закрытой сетью.

Главный вывод MaxxBench простой: хороший кодинг-агент не тот, кто помнит знакомый ответ. Хороший агент сохраняет работоспособность проекта, когда требования внезапно меняются на одну строку. Именно это и стоит измерять перед внедрением.