Co-Design Bench от Alibaba показал, что ведущие агенты для программирования полностью решают лишь 26,4% реальных задач по изменению приложений, выявляя пробелы, скрытые старыми тестами.

Согласно новому бенчмарку, созданному на основе реальных запросов пользователей, агенты для программирования на базе ИИ могут выполнить значительную часть изменений в программном обеспечении, но не предоставить полностью работоспособный результат. Тест показал, что даже самая сильная система завершала все необходимые части задачи лишь в 26,4% случаев. Это означает, что ручная доработка оставалась необходимой почти в трех из четырех заданий.
Бенчмарк под названием Co-Design Bench разработали исследователи Alibaba и нескольких азиатских университетов. Как сообщает The Decoder, он оценивает агентов на изменениях существующих веб-приложений, а не на изолированных задачах программирования. Задания могут включать визуальные референсы, аудио, видео и документы, отражая смешанные входные данные, которые команды разработки и создания продуктов все чаще передают ИИ-инструментам.
Co-Design Bench призван решить проблему, которую его исследователи описывают как насыщение устоявшихся оценок программирования. Когда модели могут запускать, проверять и исправлять собственный код, они способны набрать более 99% в некоторых старых бенчмарках, оставляя мало возможностей для различения систем.
Новый тест вместо этого использует запросы из реальных сессий программирования. Исследователи отобрали случаи, в которых пользователям уже приходилось переформулировать запросы или откатывать неудачные изменения. Они варьируются от относительно узких задач, таких как извлечение суммы из чека и обновление связанных итогов, до более масштабного редизайна приложений.
Такая конструкция делает бенчмарк менее похожим на чистое, обособленное упражнение по программированию и более похожим на хаотичную работу по поддержке работающего продукта. Это также означает, что результаты не следует воспринимать как универсальный показатель для каждого рабочего процесса программирования. Однако они наглядно показывают разрыв между созданием правдоподобного кода и полным выполнением запроса пользователя.
Согласно статье, описанной The Decoder, GPT-6 Astra показал лучший результат среди десяти протестированных моделей. В среднем он выполнил около 70% требований заданий, но полностью решил только 26,4% задач. Задание считалось завершенным только тогда, когда все необходимые функции работали в приложении.
В опубликованном рейтинге за GPT-6 Astra следовали Claude Opus 5 и Qwen3.8-Max, а Grok 4.6 занял последнее место. При масштабной переработке приложений меньшая модель Qwen3.8-27B поднялась на второе место, хотя исследователи не сочли этот результат доказательством общего преимущества модели.
Процесс оценки также был строже простой проверки кода. Один автоматизированный проверяющий тестировал готовое приложение в браузере, а второй рецензент проверял положительные результаты и искал визуальные макеты, жестко заданные выходные данные или другие сокращенные решения, которые могли создать видимость выполнения запроса без реализации соответствующего поведения.
Это результаты исследования, а не независимо проверенные показатели внедрения или производительности. Авторы бенчмарка признают, что автоматизированные проверяющие могут ошибаться. Кроме того, задания используют один фиксированный запрос, а не живой диалог, в котором пользователь может отвечать на вопросы или исправлять агента в процессе работы. Поэтому результаты показывают, с чем агенты испытывали трудности в рамках этой тестовой конфигурации, но не точный объем человеческого труда, необходимый в каждой производственной среде.
Один из наиболее важных выводов бенчмарка касается агентского harness — программной среды, которая позволяет модели читать файлы, изменять код, запускать приложения и проверять результаты. В отдельном сравнении Qwen3.8-27B набрал 75% при масштабной переработке в одной среде, но только 56% в другой. Относительный рейтинг двух моделей также менялся в зависимости от среды.
Этот результат ставит под сомнение практику сравнения агентов для программирования исключительно по рейтингам моделей. Производительность модели зависит от инструментов, которые она может вызывать, получаемого контекста, способа наблюдения за поведением браузера и способности восстанавливаться после ошибочного изменения. Поэтому для покупателей, оценивающих ИИ-помощника для программирования, практической единицей сравнения является сочетание модели и harness.
Исследование также показало, что дополнительные вычисления не всегда надежно сокращали разрыв. GLM-5.2 использовал почти в шесть раз больше токенов, чем GPT-6 Astra, при небольших изменениях, но получил значительно более слабый результат. Более глубокое рассуждение или более длительный запуск могут помочь в некоторых задачах, однако результат говорит о том, что дополнительное использование токенов не заменяет лучшего разбиения задач, тестирования и взаимодействия с приложением.
Для инженерных команд непосредственный вывод заключается в том, что ИИ-агенты для программирования по-прежнему наиболее полезны как контролируемые партнеры по реализации, а не как автономные владельцы изменений продукта. Агент может создать основную часть функции, но командам по-прежнему необходимо проверять крайние случаи, визуальное соответствие, обработку данных и взаимодействия между требованиями.
Особенно высок риск для задач, сочетающих изменения макета, дизайна, взаимодействия и контента. Бенчмарк показал, что производительность всех моделей снижалась по мере объединения большего числа типов изменений, хотя такие взаимосвязанные требования типичны для реальной работы над продуктом. Поэтому рабочий процесс, в котором каждый запрос рассматривается как единый prompt, может создать убедительную частичную реализацию, оставив важные детали незавершенными.
Команды, оценивающие инструменты, должны тестировать их на репрезентативных внутренних задачах, включая изменения существующих кодовых баз и приложений, а не только на примерах разработки с нуля. Следует измерять полное принятие результата, частоту регрессий, время проверки и частоту ручных исправлений. Это дополняет устоявшиеся оценки, такие как SWE-bench Verified, но не должно заменять проверку человеком или защитные меры при развертывании.
Результаты важны и для разработчиков агентских платформ. Улучшенная проверка браузера, более четкое отслеживание состояния, надежный откат и более сильная валидация могут улучшить результаты не меньше, чем увеличение базовой модели. Вывод о harness показывает, что продуктовым командам следует оценивать весь рабочий процесс, включая разрешения, надежность инструментов, наблюдаемость и восстановление после сбоев.
Следующим полезным сигналом станет то, выйдут ли Co-Design Bench или аналогичные оценки за пределы фиксированных одноразовых запросов. Реальная разработка программного обеспечения включает уточнения, меняющиеся требования и обратную связь от пользователей или руководителей проектов, поэтому интерактивные версии теста могут дать другую картину полезности агентов.
Исследователям и покупателям также следует обращать внимание на результаты, в которых модель и harness указываются вместе, а не публикуется единый рейтинг моделей. Независимое воспроизведение помогло бы установить, сохраняются ли заявленный рейтинг и значительный эффект среды на разных кодовых базах и типах приложений.
Наконец, показатели принятия результатов реальными инженерными командами останутся более значимыми, чем одно лишь завершение бенчмарк-задач. The Decoder ранее ссылался на исследование METR, согласно которому руководители проектов принимали код, созданный ИИ, примерно на 24 процентных пункта реже, чем соответствовали результаты SWE-bench Verified. Этот разрыв предупреждает, что кажущееся завершение задачи не превращается автоматически в программное обеспечение, готовое к развертыванию.
Co-Design Bench важен потому, что измеряет последний этап работы агентов для программирования: не способность агента создать код, а то, работает ли запрошенное изменение продукта во всем приложении. Результат в 26,4% полностью выполненных задач напоминает, что частичная автоматизация все равно может создавать значительные обязанности по проверке и исправлению.
Для разработчиков ИИ и корпоративных покупателей практический вывод состоит в том, чтобы перестать считать модель всем продуктом. Надежное выполнение будет зависеть от сочетания модели, harness, тестов, контекста приложения и одобрения человека. Пока эти компоненты не будут оцениваться вместе на реалистичных задачах, заявления об автономной разработке программного обеспечения следует воспринимать осторожно.