Почему агенты для кодирования по-прежнему сталкиваются с трудностями при работе с кодом частных компаний
Real-SWE тестирует восемь агентов для кодирования на лицензированных частных кодовых базах. Лучший из них решает 38,8 процента задач, а пять категорий неудач показывают, где агенты допускают ошибки.
Источники: Coding Agents Still Struggle With Private Company Code
Публичные тесты на программирование оценивают полезные навыки, но мало что говорят о том, что происходит в частном производственном коде компании. Тест под названием Real-SWE предназначен для оценки второго типа задач. Его создатели — небольшая стартап-компания Specific Labs, поддерживаемая Y Combinator — получили лицензию на использование частного кода от реальных компаний, выделили десять задач, уже выполненных тамошними инженерами, и передали их восемью помощникам-программистам. Лучший из них справился с 38,8 процента задач.
Одна из задач связана с чрезвычайной ситуацией в области выставления счетов: счета, выдаваемые сервисом, формируются без учета налогов, а выставление счетов возобновляется в понедельник. Всего помощники предприняли шестьдесят четыре попытки решить эту проблему, и две из них увенчались успехом. Эта задача называется «Налоговая юрисдикция» и является одной из десяти.
Почему этот код остается скрытым
Основатели недавно опубликовали этот тест-бенчмарк, и он попал на главную страницу Hacker News с несколькими сотнями баллов и более ста комментариев. Real-SWE оценивает восемь комбинаций моделей и агентов на десяти задачах, при этом на каждую задачу выполняется по восемь попыток. Всего проводится 640 тестовых запусков, а итоговый балл — это доля попыток, которые были успешными.
Основные проекты напоминают обычное коммерческое программное обеспечение: приложение для управления событиями с более чем 200 000 пользователями и местом в топ-100 App Store, финтех-продукт, обработавший более 100 000 банковских выписок, а также платформа для продаж для предприятий. Агенты используют Docker и Kubernetes, три базы данных (Postgres, MySQL, MongoDB), Redis, GitHub и имитированную облачную среду Amazon, хотя каждая задача предоставляет только те сервисы, которые необходимы для её выполнения.
В некоторых средах используются Slack, Intercom, Google Drive, ClickUp и сервер Linear MCP, который позволяет агенту читать заявки непосредственно из Linear. Если какие-то детали не были указаны в заявке, агенту приходится искать их в дискуссиях или документах, так же как это делал бы собственный инженер команды.
Только работа с налогами включает использование сервиса NestJS на TypeScript, двух экземпляров одного и того же внешнего налогового органа (практической среды тестирования и реальной системы для подачи заявлений) и базы данных InfluxDB, в которой фиксируются завершённые продажи.
Задачи форматируются по стандарту Harbor, а проверка остаётся скрытой до момента оценки. Это делается для снижения вероятности того, что агент будет подстраиваться к открытым тестам вместо реальных требований. Инструменты проверки берутся из тестовых наборов, которые уже используются этими компаниями, в некоторых случаях буквально без изменений.
Авторы объясняют свою мотивацию примечательным утверждением: 99 процентов токенов в реальных предприятиях скрыты от моделей Frontier. Поскольку эти задачи поступают из частного программного обеспечения, а не из публичных проектов на GitHub, модели не могли увидеть код или его секреты во время обучения.
Собственные цифры этого теста показывают среднее количество символов в инструкции — 1,742, что меньше, чем у FrontierCode (2,056) или DeepSWE (1,975). Однако в среднем случае для исправления ошибок требуется обработка 11 файлов, тогда как у этих двух моделей — 6.
Результаты сильно различаются в зависимости от задачи
Единый общий балл скрывает две совершенно разные группы задач: те, которые агенты решают снова и снова, и те, в которых они терпят неудачу каждый раз. Метод многорегионального анализа помог решить 67,2 процента задач, API-ключи и среды — 65,6 процента, проблемы с избыточными правами — 50 процентов, а миграция идентификаторов клиентов — 40,6 процента.
Ситуация с концом списка довольно мрачная. Уровень налоговой юрисдикции составляет 3,1 процента, а уровень линейной обработки — 4,7; показатели хранилища данных S3 (10,9), подсчёта токенов API (12,5) и миграции графика оплаты (14,1) также не намного выше. Что касается инструмента для сокращения объёма аналитических данных, то никто не добился успеха: ни один пример не был обработан за шестьдесят четыре попытки.
Что касается налоговой юрисдикции, единственные два успеха были достигнуты с помощью двух разных моделей, причём каждая из этих моделей потерпела неудачу при выполнении той же задачи в остальных семи попытках. При обработке данных в нескольких регионах, что считается самой простой задачей, три модели выполнили её на 100%, а две другие — по два раза. Средний показатель в 67,2 процента скрывает ту группу моделей, которые никогда не ошибались, и другую группу, которая почти никогда не добивалась успеха.
Один из авторов написал на Hacker News, что низкие показатели отражают задачи, «над которыми настоящие инженеры работали неделями».
Полный рейтинг:
| Место | Модель и инструменты |
|---|
Оценка не объясняет причину сбоя
Каждый неудачный запуск получает одну из пяти меток, взятых из таксономии DeepSWE:
- Непроверенное предположение. Вместо проверки рабочей среды агент угадывает, как будет вести себя система.
Каждый процентный показатель рассчитывается на основе количества собственных неудачных запусков модели в качестве знаменателя.
У Grok 4.6 было 61 сбой, две трети из которых (67,2 процента) связаны с несоответствием требованиям. У Gemini 3.8 Flash — 55 сбоев, из которых 49,1 процента представляли собой ошибки интеграции. У GPT-5.6 Sol наибольшую группу составляют непроверенные предположения — 43,3 процента из 67 сбоев, тогда как у Fable 5.1 из 49 сбоев они распределены более равномерно: примерно 37 процентов — это несоответствие требованиям, а примерно 35 процентов — ошибки интеграции.
Два модели, Grok 4.6 и Muse Spark 1.3, завершили тест на уровне 23,8 процента, но демонстрируют различия в причинах сбоев. У Grok основная причина — несоответствие требованиям, у Muse Spark — ошибки интеграции, составляющие 41 процент. Регрессии никогда не превышают 10,9 процента и равны нулю в трех из восьми конфигураций. Класс ошибок «неправильный файл» встречается всего дважды: у GLM 5.3 (7 процентов) и Kimi K3 (3,1).
Следует проявлять осторожность. Метки были опубликованы, но процесс их формирования описан недостаточно подробно, чтобы считать приведенные проценты окончательными доказательствами. В публичном описании не уточняется, выполняли ли классификацию человеческие инженеры, автоматизированная модель или их сочетание.
Более длительные тесты не делали их более надежными
Тесты также делились в зависимости от времени выполнения. При времени менее десяти минут 70 из 98 тестов провалились, что составляет 71,4 процента. При времени десяти минут и более 398 из 542 тестов провалились, что составляет 73,4 процента.
Количество используемых токенов также говорит о многом. Grok 4.6 в среднем использует от 3 000 до 20 000 токенов на восемь из десяти задач, однако при выполнении задач с самыми низкими результатами — линеаризуемого сканирования и сокращения потока аналитики — он использует соответственно 261 000 и 315 000 токенов. Высокое потребление токенов может служить тревожным сигналом, особенно если оно значительно превышает нормальный уровень для данного ресурса. Если результат выполнения в несколько раз превышает ожидаемый, следует проанализировать ситуацию или вмешаться, вместо того чтобы позволить неудачной попытке исчерпать выделенные ресурсы.
Самый дорогой агент не всегда был лучшим
Ориентировочная стоимость одной запусковой процедуры составляет от 2,50 долларов (Gemini 3.8 Flash) до 6,96 долларов (Fable 5.1), причем порядок цен практически не соответствует рейтингу лидеров. GPT-5.6 Sol стоит 2,65 доллара и занимает последнее место, тогда как самый дешевый вариант — Gemini 3.8 Flash — оказывается на третьем месте. Все эти значения являются ориентировочными расчетами и не представляют собой универсального рейтинга цен, поскольку фактические расходы зависят от ценообразования, настроек, длительности задачи, количества попыток и использования инструментов.
Fable 5.1 стоит в 2,78 раза дороже Gemini 3.8 Flash и обеспечивает на 7,6 процентных пунктов лучшие результаты. То, стоит ли это усилий, зависит от стоимости неудачной задачи. В данном случае неудачей считается ошибка в выставлении счетов, обложение клиента налогом, когда он освобожден от него, или ситуация, когда отчеты не сходятся в конце квартала. Для небольших изменений интерфейса суммы выглядят совершенно иначе.
Значительная часть разницы обусловлена объемом токенов. GLM 5.3 в среднем генерирует 117 000 токенов на каждый запуск, в то время как GPT-6 Astra — 24 000, что составляет почти в пять раз больше при выполнении одинаковых десяти задач. К двум показателям авторы теста приложили предупреждения: у Grok 4.6 стоимостью 3,44 доллара и Kimi K3 стоимостью 3,90 доллара отсутствуют некоторые данные об использовании, поэтому реальная стоимость может быть выше. Считайте эти значения минимальными значениями.
Одна и та же платформа, но разница в семнадцать баллов
Каждая запись сочетает модель с инструментарием ее производителя, и именно поэтому в тесте оценки приводятся как «комбинации модели и платформы, а не отдельные модели». Однако две платформы упоминаются дважды, что позволяет провести приблизительное сравнение. С помощью Codex CLI GPT-6 Astra достигает результата 33,8 процента против 16,2 у GPT-5.6 Sol, что составляет разницу в 17,6 баллов. С помощью Claude Code Fable 5.1 показывает результат 38,8, а GLM 5.3 — 28,8, то есть разница составляет десять баллов.
Тем не менее, десять задач и восемь конфигураций составляют небольшую таблицу, причем к каждому результату прилагается опубликованный диапазон уверенности. Каждая модель была протестирована 80 раз, поэтому показатель Fable 5.1 в 38,8 процента соответствует 31 успешному тесту, а показатель GPT-5.6 Sol в 16,2 процента — 13 тестам. Если для одной модели результат одной задачи меняется, её оценка смещается на несколько пунктов. Никто не должен выбирать поставщика на основе таблицы такого размера, и авторы не призывают к этому никого. Этот эксперимент показывает, что публичные оценки могут быть неполным указателем производительности в частном кодовом базисе, и к этой разнице относятся пять практических категорий сбоев.
Протестируйте пять категорий на собственном коде
Таксономия — это то, что можно использовать. Вы можете применять её к своему репозиторию в любое время.
Возьмите последние двадцать заявок на интеграцию, открытых агентом, и каждой неудачной или сильно изменённой присвойте один из пяти классов. Посчитайте их количество. Распределение будет результатом исследования, и оно не совпадёт ни с одной моделью, о которой вы читали на этой неделе, поскольку зависит как от вашей базы кода и привычек написания заявок, так и от самой модели. К классу с наибольшим количеством примеров добавьте ограничение.
Если доминируют непроверенные предположения, необходимо вести журнал просмотров. Попросите агента записывать, какие файлы он открывал перед внесением любых изменений, и отклоните изменения, если в списке отсутствует файл с кодом, ответственным за нужное поведение. Несоблюдение требований обычно связано с соответствующим тикетом. Преобразуйте инструкцию в список критериев приемки и отмечайте их по одному, поскольку инструкция с пятью требованиями, спрятанными в длинном абзаце, является причиной 67,2 процента ошибок у Grok. Ошибки интеграции означают, что тесты проходят на уровне модулей, но проваливаются при работе в цепочке вызовов, поэтому тестируйте путь, который проходит реальное приложение, начиная с точки входа. Ошибки из-за неправильного файла встречаются редко, но каждый такой случай требует детального расследования: убедитесь, что к каждому измененному файлу можно получить доступ из кода, который действительно использует приложение.
С этого момента следите за одним показателем: долей запросов агента на внесение изменений, проходящих проверку с первой попытки, с разбивкой по категориям ошибок. Он меняется при ужесточении требований и снова изменяется при обновлении используемой модели.