Команды ИИ-агентов в тестах Vals AI обходились в 1,8–5,1 раза дороже одиночных агентов, а статистически подтверждённый прирост качества появился только в одном из четырёх сравнений. Для команд, которые собираются масштабировать агентную разработку за счёт субагентов, вывод неприятный, но полезный: параллельная работа сама по себе не гарантирует ни лучший код, ни экономию времени.
Исследование провела компания Vals AI на бенчмарке Vibe Code Bench, сообщает Habr / Новости. Агентам давали техническое задание на веб-приложение, затем готовый проект разворачивали через Docker Compose и проверяли автоматизированными браузерными сценариями. В выборку вошли 50 приложений; тестировали GPT-6 Sol и Claude Opus 5.5 при среднем и максимальном уровне усилий на рассуждение.
Для каждого сочетания модели, уровня усилий и режима работы был выполнен один прогон. В одиночном сценарии над задачей работал один агент. В командном ведущий агент мог одновременно привлекать до пяти субагентов: раздать им части приложения, получить результаты и собрать итоговый проект. Такая схема близка к тому, как агентные платформы продают идею «виртуальной команды разработчиков» — с архитектором, исполнителями и координатором в одном контуре.
Самый заметный выигрыш получили у GPT-6 Sol на среднем уровне усилий. Доля успешно пройденных тестов выросла с 77,6% у одиночного агента до 84,9% у команды — на 7,3 процентного пункта. Для этой разницы авторы указали p = 0,005, то есть эффект в рамках проведённого эксперимента признан статистически значимым. В остальных трёх сопоставлениях разница по качеству не достигла статистической значимости.
Цена такого улучшения оказалась далеко не символической. На среднем уровне усилий одиночный GPT-6 Sol в среднем тратил на одно приложение $1,22, а командный режим — $3,07. Это примерно в 2,5 раза дороже. При максимальном уровне усилий одиночный Sol достиг 89% успешных тестов за $4,82 на приложение; команда поднялась до 90,4%, но средняя стоимость выросла до $8,54. Получается, что дополнительные расходы дали лишь 1,4 процентного пункта качества в этой конфигурации.
Разброс по стоимости между режимами достигал 1,8–5,1 раза. При этом время выполнения не всегда следовало за ценой: в отдельных запусках командный GPT-6 Sol завершал работу быстрее одиночного. Это важная деталь для продуктовых и инженерных руководителей. Если задача привязана к короткому окну релиза или быстрому прототипированию, более дорогой режим может иметь смысл. Но оценивать его только по числу одновременно работающих агентов — всё равно что выбирать облачную архитектуру по количеству контейнеров в схеме.
Модели по-разному организовывали совместную работу. Ведущий агент GPT-6 Sol быстро распараллеливал части приложения между помощниками. Claude Opus 5.5, напротив, сначала формулировал общие контракты между компонентами и только потом распределял работу по последовательным этапам. Поэтому тест не доказывает, что мультиагентный подход слабее одиночного: он показывает, что конкретная организация делегирования, модель и тип задач заметно меняют результат.
У исследования есть и очевидные ограничения. Проверяли только веб-разработку, только 50 приложений и только по одному запуску на каждую из восьми конфигураций. Такой дизайн позволяет увидеть сигнал, но не даёт основания переносить цифры на мобильную разработку, поддержку большого репозитория, анализ инцидентов или работу с корпоративным кодом. Тем более что один неудачный вызов инструмента либо конфликт в результатах субагентов способен сильно повлиять на итог единственного прогона.
Практический вывод для команд, внедряющих ИИ в разработку, довольно приземлённый: команды ИИ-агентов стоит включать не «по умолчанию», а после замера трёх показателей — качества, времени и стоимости на своих задачах. Субагенты могут окупиться на разложимых задачах с параллельными блоками работы, но на уже сильном одиночном агенте прирост легко превращается в дорогие десятые доли процента. Главный вопрос теперь не в том, сколько агентов запустить, а в том, где именно их координация приносит измеримую пользу.