Какие инструменты выбирают Claude Code, Codex и Cursor?

Когда кодинг-агенту дают задачу "отправляй каждый инвойс по email, найди лучшее решение и внедри его", что-то внутри сессии выбирает Resend, Postmark или SendGrid. В компании Armature решили выяснить, что именно стоит за этим выбором. В статье от 2026-09-03, опубликованной "командой Armature", приводятся результаты 16 893 прогонов claude-code, Codex и Cursor на синтетических репозиториях. Для первого отчёта which-tools-coding-agents-install авторы отобрали 5 292 валидные сессии на 51 кодовой базе из 18 отраслей.

Здесь важно, кто именно проводит измерения. Сама публикация лишь намекает на это, обещая продолжить поиски "того, что интересно вендорам и разработчикам", и ссылаясь на публичный лидерборд. Но на главной странице Armature (по состоянию на 2026-09-14) всё сказано прямо: их продукт называется "Станьте инструментом, который выбирает Claude Code". Это услуга, в рамках которой growth-инженер оценивает, как агенты выбирают инструменты в категории заказчика, и работает с вендором до тех пор, пока агенты не начнут выбирать именно его. Главной метрикой успеха служит частота выбора на той же выборке репозиториев. Таким образом, перед нами исследование от компании, чья выручка напрямую зависит от веры вендоров в то, что выбор агентов можно изменить. Это не означает, что цифры ошибочны, но само исследование одновременно служит коммерческим предложением.

Стенд и методика

Выборка формировалась на основе статистики по тысячам публичных репозиториев на GitHub: языки, фреймворки, сторонние сервисы, целевые платформы развёртывания, размер команды, возраст кодовой базы. В Armature утверждают, что скорректировали веса, поскольку стартапы публикуют в open source больше кода, чем корпорации, а затем поручили кодинг-агентам сгенерировать репозитории под целевое распределение. В итоге получилось 75 репозиториев на 10 языках с вымышленными названиями компаний, фиктивной историей git, ненастоящими API-ключами и реальными lockfile'ами. В отдельных вариантах интеграции с сервисами намеренно вырезали, чтобы у агента оставался пробел, который нужно закрыть.

Задачи формулировались от лица четырёх типажей - vibe-кодера, описывающего симптомы; джуниора, называющего категорию; сеньора, задающего ограничения; и корпоративного инженера с требованиями комплаенса и процедур закупки. Всего получилось 1 163 вариации промптов. В 20-25% случаев в промпте упоминалась стоимость или объём использования. Каждый прогон выполнялся в изолированной песочнице, причём среды чередовались между E2B, Blaxel и Daytona.

Два архитектурных решения оказали сильное влияние на результат. Роль "симулированного человека" исполняла Gemini 3.7 Flash: сначала она просила агента провести анализ и дать рекомендацию, а затем всегда соглашалась с первым предложенным вариантом либо предлагала агенту сделать выбор самому. В Armature выяснили, что требование сразу написать код подталкивает агентов делать всё своими силами, поскольку у них нет возможности запросить разрешение на подключение стороннего вендора. Добавление диалога с человеком снизило доминирование лидеров рынка и cloud-native решений: например, в объектном хранилище Cloudflare R2 стал побеждать в тех сессиях, где раньше безоговорочно выигрывал S3. Второй экземпляр Gemini 3.7 Flash выступал в роли судьи каждой сессии: он проверял диалог и diff на то, был ли провайдер уже жёстко задан в репозитории, состоялся ли реальный выбор (сам по себе OpenTelemetry не считался выбором сервиса наблюдаемости), а также какие игроки упоминались и кто в итоге победил.

Результаты

Три агента собирают информацию по-разному. Cursor опирается на поиск в вебе примерно в двух третях сессий. Codex ищет информацию в 94% случаев, причём в девяти запросах из десяти использует операторы вроде site:, чтобы ограничиться доменом вендора. Claude Code в основном полагается на базовые знания модели и ищет в сети примерно в 30% случаев, но при поиске просматривает втрое больше страниц, чем Codex. В более новых категориях вроде песочниц, где априорных знаний меньше, он обращался к поиску примерно в 80% сессий. Все три агента сошлись на одном и том же инструменте лишь в 42% ячеек матрицы. Для голосовых агентов Claude Code выбрал Twilio, Codex - OpenAI Realtime API, а Cursor - Vapi. Кроме того, Claude Code почти вдвое чаще предпочитает писать решение с нуля внутри проекта: в 19% случаев против 10%.

Репозиторий влияет на выбор не меньше самого агента. Одна и та же задача по отправке email на четырёх разных репозиториях дала четырёх разных победителей: Resend на TypeScript (55 из 89 прогонов), SendGrid на Python (22 из 24), Postmark на Golang (20 из 24) и Azure Communication Services на Java (22 из 23). Vercel побеждал на TypeScript (в 100% случаев при наличии Next.js) и ни разу не был предложен на Python, где доминировал Render.

Упоминание в диалоге ещё не означает выбор. PayPal упоминался 139 раз в сессиях про платежи и не был выбран ни разу; в 124 из этих сессий победил Stripe. Adyen упоминался 175 раз и был выбран трижды, LangChain упоминался 194 раза и выбран четырежды, Netlify упоминался 152 раза и выбран шесть раз. Supabase упоминался чаще всех среди баз данных (242 раза), но всё равно уступил Neon.

Мелкие детали на страницах вендоров переворачивали исход. Mailgun регулярно проигрывал Postmark, как только агент находил строку "хранение логов 1 день" на бесплатном тарифе. Supabase постоянно проигрывал из-за того, что в его тарифы включены аутентификация, хранилище файлов и realtime, тогда как агенту требовалась только база данных. Из 5,3 тыс. сессий в 388 упоминались накладные расходы на управление платформой, а в 195 - стоимость. В отчёте отмечается, что в заметной части этих случаев претензия возникала из-за того, как вендор подал информацию, а не из-за реального дисквалифицирующего фактора. Конкретных цифр для этой доли авторы не приводят.

В некоторых категориях конкуренции почти не было. Stripe побеждал в девяти случаях из десяти, уступая лишь Paddle и Mollie в сценариях с регуляторными требованиями ЕС. Neon забрал 66% выборов в категории баз данных, за ним следовали cloud-native решения провайдеров. S3 занял 45% в хранении файлов, Azure и GCP получили по 20%. В категории email разрыв был минимальным: 35,6% у Resend против 27,4% у Postmark.

Что стоит учитывать при анализе

Самый надёжный вывод исследования - это расхождение в результатах: три агента на одной и той же задаче в одном и том же репозитории выбирают разные инструменты, а язык программирования репозитория влияет на выбор сильнее, чем формулировка задачи. Это согласуется с идеями agentic-search-context-engineering о том, как поиск формирует контекст агента, и служит практическим аргументом в пользу явного указания вендора в инструкциях репозитория вместо того, чтобы отдавать выбор на откуп запущенному агенту.

Применимость полученных процентных соотношений ограничена несколькими факторами. Репозитории писали сами кодинг-агенты, поэтому структура проектов и зависимости уже могли отражать их собственные паттерны. Симулированный человек всегда принимает первую же рекомендацию, что отражает лишь приоритетный выбор агента, а не то, что реальный разработчик в итоге выкатит в прод. И оркестратором, и судьёй выступала одна и та же модель Gemini, при этом в статье не сказано, как часто оценки судьи сверялись с ручной проверкой человеком. Версии агентов и моделей не указаны, хотя базовые знания меняются с каждым релизом. Две трети прогонов отложены до следующего этапа, и причины их исключения (помимо общих критериев валидности) не раскрываются. Наконец, авторы не приводят доверительных интервалов, уязвимость чего наглядно объясняет llm-output-variance: для ячеек по 23-24 прогона статистического шума между запусками достаточно, чтобы сменить победителя.

Выводы о страницах вендоров - это именно то, что Armature продаёт, и одновременно самое интересное для авторов документации. Они указывают в ту же сторону, что и llms-txt, а также категория готовности к агентам в specification-website-checklist: агент воспринимает страницу с тарифами буквально, и оговорка, рассчитанная на человека, может привести к отказу от продукта. Инструмент agent-reading-test как раз напрямую измеряет способность агентов читать подобные страницы.