В эксперименте Armature на 5292 проверенных сессиях Claude Code, Codex и Cursor выбирали один и тот же инструмент только в 42% случаев. Выбор инструментов агентами становится новой точкой влияния на рынок devtools: побеждает не самый узнаваемый бренд, а тот, чьи документы, цены и примеры агент сумел прочитать в нужный момент.
Исследование молодой компании Armature описал 7 сентября The New Stack. Команда наблюдала тысячи сессий поиска инструментов у кодинг-агентов и проверяла, как они принимают решения в задачах, похожих на реальные запросы разработчиков: подобрать сервис, встроить его в репозиторий, учесть язык, фреймворк и контекст проекта.
Масштаб у работы заметный, хотя к цифрам стоит относиться аккуратно. Сооснователь Armature Теодор Отценбергер говорил о 17 тыс. сессий, но ключевые выводы компания строит на меньшей валидированной выборке из 5292 сессий. В эксперимент попали 75 публичных GitHub-репозиториев и три агента: Claude Code, Codex и Cursor. Исследователи извлекали из проектов данные о языках программирования, фреймворках, сторонних сервисах, платформе деплоя, размере команды и возрасте кодовой базы. Затем статистику дебайасили, потому что открытые репозитории чаще похожи на стартапные проекты, чем на тяжелый enterprise.
Самый неприятный для маркетинга вывод: старый брендовый капитал плохо конвертируется в выбор агента. Репозиторный контекст оказался сильнее общего знания рынка. В задаче выбора email- или коммуникационного сервиса разные языки давали разных победителей: Resend чаще выигрывал в TypeScript-проектах, SendGrid — в Python, Postmark — в Go, Azure ACS — в Java. Это не значит, что один сервис объективно лучше другого. Это значит, что агент смотрит на задачу через призму уже лежащего перед ним кода, доступных примеров и собственных эвристик.
Разница между самими агентами тоже существенная. По данным Armature, Cursor опирался на веб примерно в двух третях сессий. Codex почти всегда использовал веб-поиск — в 94% сессий, причем в девяти запросах из десяти применял операторы вроде site. Claude Code чаще полагался на внутренние знания и ходил в веб примерно в 30% случаев, зато при поиске открывал в три раза больше страниц, чем Codex. Для разработчика это важная практическая деталь: один и тот же промпт в разных IDE и агентных средах может привести не просто к разному коду, а к разным поставщикам, зависимостям и будущим счетам.
Еще один симптом: упоминание не равно победа. Основатель и CTO Glokal AI OÜ Джит Паттанаик обратил внимание, что PayPal упоминался 139 раз, но не был выбран ни разу. LangChain стал самым часто упоминаемым фреймворком — 194 упоминания, однако выбран был только четыре раза. Для рынка это почти издевательская метрика: можно быть «на слуху» у модели, но проиграть в момент реализации, если агент нашел более удобную документацию, понятный pricing, свежий пример или библиотеку, лучше совпадающую с текущим стеком.
Отсюда растет интерес к Answer Engine Optimisation — оптимизации не под поисковую выдачу, а под машины, которые сразу дают ответ и выполняют действие. SEO пытался привести человека на страницу. AEO пытается убедить агента выбрать конкретный SDK, API или облачный сервис. Разница принципиальная: агент не впечатляется логотипом, не помнит стенд на конференции и не «любит» бренд за двадцать лет присутствия в комьюнити. Он читает README, документацию, страницы цен, changelog, GitHub issues и чужой код. Если там шум, устаревшие примеры и юридическая поэзия вместо конкретики, агент может уйти к конкуренту без всякой драмы.
Для IT-команд это не только маркетинговая история. Если разработчики все чаще нажимают «принять» на патч агента, выбор инструментов агентами превращается в скрытый procurement. В проект могут попасть сервисы, которые никто не согласовывал с безопасниками, финансами или платформенной командой. В малой компании это закончится лишней подпиской. В крупной — проблемами с комплаенсом, SLA, хранением данных и поддержкой. Поэтому внутренние правила для AI-разработки должны описывать не только стиль кода и тесты, но и допустимые зависимости, поставщиков, лицензии и условия, при которых агенту разрешено тянуть сторонний сервис.
Для поставщиков devtools вывод еще жестче: документация становится каналом продаж, а не приложением к продукту. Нужны короткие install-пути, рабочие примеры под разные языки, ясные ограничения тарифов, честные страницы миграции и машинно-читаемые подсказки. Плохая документация и мутный pricing раньше раздражали разработчика; теперь они могут просто выбросить продукт из агентного выбора еще до того, как человек увидит вариант.
Следующий спор на рынке будет не о том, заменят ли агенты разработчиков, а о том, кто управляет их предпочтениями. Если агент становится новым входом в закупку инструментов, компаниям придется проверять не только код, который он написал, но и цепочку решений, по которой он пришел к конкретному API, облаку или библиотеке; подробности исследования и цитаты участников опубликованы в .