Оговорка: Armature продаёт услуги по продвижению для разработчиков инструментов. Это исследование — часть более широкой работы компании о том, как влиять на выбор кодинг-агентов и добиваться того, чтобы продукт был выбран.
По мере того как агенты берут на себя всё больше этапов написания кода, есть одна задача, которую делегируют абсолютно все — от вайб-кодеров без технического背景 до senior-инженеров: выбор конкретного сервиса для реализации задачи в существующей кодовой базе.
Пример с выбором базы данных:
Вайб-кодер собирает личное приложение для путешествий и замечает, что при каждом новом подключении данные сбрасываются. Просит Claude Code:
Мне нужно, чтобы то, что я ввожу в приложении, где-то сохранялось — чтобы при следующем открытии приложения данные оставались на месте
Claude Code анализирует кодовую базу и через 5 минут отвечает:
Тебе нужна база данных, и Neon хорошо подходит: есть бесплатный тариф, простая установка, и в отличие от Supabase не «засыпает», если приложением редко пользуются
Пользователь соглашается, агент устанавливает базу. Готово.
Senior-инженер, работающий над production-приложением, спрашивает у Cursor:
Какое решение для базы данных лучше всего подойдёт для этого приложения, важна предсказуемая стоимость и полное managed-обслуживание
Через 5 минут вывод тот же — Neon, с чёткими причинами, почему конкуренты не подходят. Инженер одобряет, агент реализует решение.
Это реальный эксперимент, который провели в Armature. Два разных сэндбокса, разные агенты, разные кодовые базы, разные персоны и промпты — и одинаковый результат. Возник вопрос: если распространить тест на другие категории инструментов, увеличив разброс контекста, кодовых баз и персон, изменится ли итог?
Вопрос важен для разработчиков, которым хочется понимать, можно ли доверять суждению агента о том, что действительно подходит под их задачу. Но ещё важнее он для вендоров, чьё выживание всё сильнее зависит от того, будет ли их продукт выбран кодинг-агентом (в апреле Vercel сообщила, что «более 30% деплоев инициированы кодинг-агентами — рост на 1000% за полгода»).
Поэтому команда Armature решила провести крупнейший эксперимент, чтобы понять, как кодинг-агенты рассуждают об инструментах, как их находят и выбирают, и кто в итоге побеждает в каждой категории. Проанализировали почти 17 тысяч сессий с разными типами персон (вайб-кодеры, junior-инженеры в стартапах, senior-разработчики в enterprise), 1163 варианта промптов, 75 репозиториев и 3 кодинг-агента (Claude Code, Codex, Cursor), которые действительно внедряли решения, а не просто их рекомендовали.
Публикуются как агрегированные результаты и лидерборды по категориям, так и все наблюдения — включая полные трейсы с промптами пользователей, цепочками рассуждений и реальными диффами кода, применёнными агентом.
Как проводились эксперименты
Панель репозиториев
Сначала проанализировали тысячи публичных GitHub-репозиториев и извлекли статистику по языкам программирования, фреймворкам, сторонним сервисам, платформам деплоя, размерам команд и возрасту кодовой базы. Поскольку у технологических стартапов открытые репозитории встречаются чаще, чем у крупных компаний, а стеки у них заметно отличаются, статистику скорректировали по публично доступным данным и получили целевое распределение панели.
Затем задействовали кодинг-агентов для создания реалистичных репозиториев под эти требования. В финале сгенерировали варианты, из которых удалили части кодовой базы и вместе с ними — целые реализации сторонних сервисов, чтобы проводить корректные эксперименты без смещения.
В итоге получили 75 репозиториев на 10 языках, с фейковыми названиями компаний, фейковой git-историей, фейковыми API-ключами и настоящими lock-файлами, проверенными по реестрам менеджеров пакетов, например npm.
Реальные задачи
Каждый эксперимент — это конкретная задача внутри репозитория, поставленная от лица одного из четырёх профилей:
- Вайб-кодер: описывает только симптомы и желаемое состояние, редко называет категорию инструмента
- Junior-инженер: обычно упоминает желаемый результат и название категории
- Senior-инженер: точнее формулирует требования и то, что нужно избегать
- Инженер в крупной компании: детализирует конкретные ограничения, требования комплаенса, закупок и т.д.
Промпты в целом простые и прямые, слегка адаптированные под каждый эксперимент (с учётом репозитория и персоны), но в 20–25% случаев тестировалось добавление в промпт конкретных деталей — например, стоимости или объёма использования — чтобы проверить их влияние на итоговый результат.
В итоге получилось 1163 варианта, например: «Теперь нужно, чтобы каждый счёт, который мы генерируем, отправлялся на email пользователя с красивым сообщением, найди лучшее решение и реализуй его».
Раннер
Каждый эксперимент запускался в отдельном эфемерном сэндбоксе. Проверили, что выбор сэндбокса не влияет на выводы, но на всякий случай ротировали между тремя провайдерами (E2B, Blaxel и Daytona).
«Симулированный человек» в цепочке
Реальные диалоги редко представляют собой один промпт и агента, непрерывно работающего над целью без вмешательства. Поэтому в цепочку добавили «симулированного человека» — оркестратор на базе Gemini 3.7 Flash. Это позволило разыграть более реалистичные сценарии, где агента сначала просят проанализировать кодовую базу и порекомендовать лучшее решение. На этом этапе симулированный человек всегда соглашался с топ-1 решением либо просил агента выбрать лучший вариант и реализовать его. Но выяснилось, что если с самого начала просить реализовать задачу без промежуточных вопросов, агент смещается в сторону собственной разработки in-house — потому что не может запросить разрешение на выбор конкретного стороннего решения. Добавление «человека» в цикл снизило доминирование лидеров рынка и облачно-нативных решений, приблизив картину к реальности.
Например, в эксперименте с объектным хранилищем Cloudflare R2 начал побеждать в сессиях, где ранее агент всегда выбирал Amazon S3.
Судья
Ещё один инстанс Gemini 3.7 Flash анализировал сессии. Его роль двойная:
- Оценить валидность сессии по списку критериев — например, выбор не был смещён репозиторием, который уже «предвыбрал» провайдера; решение действительно было выбрано (для observability, скажем, отбраковывался только голый OpenTelemetry без привязки к платформе).
- Определить каждого упомянутого игрока и итогового победителя (по переписке и реальным диффам кода).
Что показали результаты
Из 16 893 запусков отобрали 5292 сессии на 51 кодовой базе и в 18 отраслях, которые сочли валидными и готовыми к публикации. Это не означает, что остальные 10+ тысяч выброшены — их могут опубликовать позже. В этой первой волне извлекли лишь часть выводов, которые всё ещё скрыты в трейсах, и продолжат копать глубже. С сегодняшнего дня все трейсы публичны, так что желающие могут провести собственный анализ. Ниже — пять первых наблюдений, показавшихся интересными.
Разные агенты используют разные источники и приходят к разным выводам
- Cursor опирается на веб-поиск в 2/3 сессий.
- Codex почти всегда использует веб-поиск (94% сессий), но в 9 запросах из 10 применяет операторы вроде
site:, чтобы сузить поиск до доверенных доменов или углубиться в конкретное решение (например,site:auth0.com password reset MFA social connections). - Claude Code полагается в первую очередь на собственные знания и обращается к веб-поиску лишь в ~30% случаев. Но когда обращается — просматривает в 3 раза больше страниц, чем Codex. В более новых категориях, например в сэндбоксах, где встроенные знания слабее, поиск использовался ~80% времени.
- Все три агента выбирают один и тот же инструмент лишь в 42% случаев: например, в категории голосовых агентов Claude Code выбирает Twilio, Codex — OpenAI Realtime API (👀), а Cursor — Vapi.
- Claude Code почти в два раза чаще строит решение in-house, чем Codex и Cursor (19% против 10%).
Контекст репозитория играет ключевую роль
- При одном и том же запросе на четырёх репозиториях на четырёх разных языках получили четырёх разных победителей среди email-провайдеров: Resend побеждает на TypeScript (55/89 запусков), Sendgrid на Python (22/24), Postmark на Go (20/24), Azure ACS на Java (22/23).
- Vercel побеждает на TypeScript-репозиториях (и, естественно, в 100% случаев при использовании NextJS), но ни разу не был рекомендован на Python-репозиториях, где доминировал Render.
Упоминание — не то же самое, что победа
Многие известные игроки упоминаются почти в каждом диалоге, но почти никогда не выбираются. В реальном мире можно было бы ожидать, что часть из них всё же побеждала бы благодаря человеческому фактору, но некоторые результаты впечатляют:
- В категории платёжных провайдеров PayPal упомянут 139 раз и не выбран ни разу (Stripe победил в 124 из этих 139 сессий). Похожая история с Adyen: 175 упоминаний и всего 3 выбора.
- LangChain — самый упоминаемый фреймворк (194 упоминания), но выбран лишь 4 раза (!).
- Netlify упомянут 152 раза, выбран как платформа деплоя лишь 6 раз.
- Supabase — самая упоминаемая база данных (242 упоминания), но всё равно значительно отставал от Neon.
Дополнительные фичи или детали на страницах вендоров способны развернуть выбор
- Mailgun регулярно проигрывал Postmark, когда агенты видели пункт «хранение данных 1 день» на бесплатном тарифе.
- Supabase почти всегда проигрывал из-за избытка ненужных BaaS-фич (auth, storage, realtime), упакованных в единый тариф, тогда как агенты искали только базу данных.
- Из 5,3 тысяч сессий в 388 упоминалась нагрузка на управление платформой, в 195 — стоимость. В значительной части этих случаев причиной оказывалась не сама дисквалифицирующая характеристика, а способ подачи информации.
Некоторые рынки поразительно монополизированы, другие — предмет острой конкуренции
- Stripe побеждал в 9 случаях из 10, проигрывая только в конкретных случаях с европейским регулированием, где более специализированные игроки (Paddle, Mollie) оказывались сильнее.
- Neon победил в 66% случаев, за ним — облачно-нативные решения (Azure, AWS).
- В файловом хранении доминирует Amazon S3 с 45%, за ним Azure и GCP с 20% каждый.
- Resend и Postmark идут почти вровень с долей установок 35,6% и 27,4% соответственно.
Это только начало серии экспериментов о том, как кодинг-агенты выбирают сторонние сервисы. Планируются и новые эксперименты — вопросы и предложения можно направлять на contact@armature.tech.
Кто побеждает в каждой категории и почему
Полные результаты, анализ, ключевые выводы и все трейсы доступны в публичном лидерборде.