Какие тулы ставят себе Claude Code, Codex и Cursor AI - и почему сходятся лишь в 42% случаев?

Компания Armature (YC, продаёт сервисы "продвижения" dev-тулов в выдаче ИИ-агентов) прогнала три кодинг-агента - Claude Code, Codex и Cursor AI - через 16 893 сессии на 75 синтетических репозиториях и посмотрела, какие сторонние сервисы они реально дописывают в код: платёжки, базы, почту, хранилища. Итог: одинаковый инструмент все три агента выбирают лишь в 42% случаев. Дальше - конкретные цифры, кто как ищет, кто что предпочитает, и при чём тут MCP-сервер, раз уж вы искали именно его.

Что за исследование и почему к нему стоит отнестись с прищуром

Armature - стартап из Y Combinator (партия P26), их бизнес - "продвигать" продукты dev-тулов так, чтобы их чаще выбирали кодинг-агенты, то есть буквально GEO для SaaS. Об этом прямо написал сооснователь в обсуждении на Hacker News: "Disclaimer: I am a Co-Founder of Armature (YC P26) which sells growth services to dev tools". Там же один из комментаторов не постеснялся в выражениях: если твой бизнес - это "growth hacking и SEO-трюки, заставляющие модели выбирать продукты, которые на самом деле не лучшие для задачи", то грош цена такому бизнесу. Жёстко, но справедливо иметь это в виду, читая цифры дальше - те, кто их считал, прямо заинтересованы, чтобы разработчики бросились "оптимизироваться под агентов".

Методология при этом вменяемая: 16 893 прогона агентов, 75 репозиториев на 10 языках, 1163 вариации промптов; в финальный анализ ушли 5292 валидных сессии на 51 кодовой базе и 18 секторах. Песочницы гоняли через трёх провайдеров (E2B, Blaxel, Daytona), а роль "симулированного человека" и судьи выполняла Gemini 3.7 Flash. Опубликовано 3 сентября 2026 года.

И ещё один нюанс из того же треда на HN, который сильно снижает пафос выводов: "worth checking against your own permission settings before reading it as a model preference: allowlist a domain and the same agent will reach for it a lot more" - то есть разница в поведении агентов может объясняться не "характером" модели, а тем, какие домены им вообще разрешили трогать в песочнице. Помню это, когда вижу ниже цифры про Claude Code и веб-поиск.

Как Claude Code, Codex и Cursor AI вообще ищут инструменты

Первое реальное различие - не в том, что агенты выбирают, а в том, как они вообще принимают решение. Ниже - цифры из того же отчёта Armature (16 893 прогона, опубликован 3 сентября 2026 года).

Codex почти всегда лезет в интернет и делает это прицельно - через операторы вроде site:, сужая выдачу до доверенных доменов или конкретного решения. Cursor AI гуглит в двух третях сессий. А Claude Code большую часть решений принимает по своим "приорам" - тому, что уже знает из обучения и документации, - и лезет в веб примерно в 30% случаев. Зато когда лезет, читает в разы больше страниц за раз, а для по-настоящему незнакомых областей (в исследовании это песочницы выполнения кода) доля поиска у него подскакивает почти до 80%.

Вторая заметная разница - готовность вообще не брать готовый сервис, а написать своё. Claude Code делает это в 19% сессий - почти вдвое чаще, чем Codex и Cursor AI, у которых по 10%. Я уже сравнивал эти три инструмента по деньгам и скорости в отдельном разборе - там речь про токены и время ревью, а здесь видно, откуда часть этой разницы в скорости берётся: Claude Code реже вообще выходит из кодовой базы за сторонним сервисом.

Какие сервисы агенты выбирают чаще всего

По данным Armature (прогоны за август-сентябрь 2026), по категориям цифры такие:

• Платежи: Stripe выигрывает 9 случаев из 10.
• Базы данных: Neon побеждает в 66% сессий, дальше с большим отрывом - облачные варианты вроде Azure и AWS.
• Файловое хранилище: Amazon S3 - 45%, Azure и GCP - примерно по 20% каждый.
• Почтовые сервисы: Resend - 35,6%, Postmark - 27,4%, но выбор сильно завязан на язык - на TypeScript агенты берут Resend, на Python - SendGrid, на Go - Postmark, на Java - Azure Communication Services.
• Хостинг: Vercel доминирует в TypeScript/Next.js-проектах, Render чаще выигрывает в Python.

Контекст репозитория (язык, стек, уже подключённые зависимости) влияет на выбор сильнее, чем узнаваемость бренда - это прямой вывод авторов исследования, и он бьётся с тем, что я вижу в своих проектах: агент почти никогда не тащит новый сервис туда, где уже есть похожий, даже если тот новый более "модный".

Упоминание - не значит выбор

Самая показательная часть исследования - разрыв между тем, что агент упоминает в рассуждениях, и тем, что реально пишет в код.

PayPal за время эксперимента всплыл в обсуждениях 139 раз - и ни разу не стал финальным выбором для оплаты, это место стабильно забирал Stripe. LangChain упомянули 194 раза, а выбрали как итоговое решение только 4. Supabase фигурировал 242 раза, но в итоговых интеграциях его почти везде вытеснял Neon. Netlify - 152 упоминания и всего 6 реальных выборов.

Это ровно то, из-за чего исследование вообще существует и зачем Armature его писала: если ты dev-тул и хочешь, чтобы агент не просто упомянул тебя как вариант, а реально вписал в код, узнаваемости бренда недостаточно - решают документация, наличие явных SDK-примеров и то, насколько легко агенту "приоритетно" на тебя наткнуться. Собственно этим Armature и торгует, так что мотив у них прозрачный - но сам паттерн "упомянули много, выбрали единицы" выглядит правдоподобно и без доверия к продавцу.

При чём тут MCP-сервер

Если вы искали это исследование из-за ключа "mcp сервер" - короткий и не очень приятный ответ: оно вообще не про MCP-серверы. Armature мерили выбор SaaS-сервисов и библиотек внутри сгенерированного кода (Stripe, Neon, Resend и так далее), а не то, какие MCP-серверы агенты подключают к себе в тулинг. Это разные слои: один - "какую внешнюю зависимость агент впишет в проект", другой - "каким инструментом агент пользуется сам, пока работает". Забавно, что сама Armature при этом работает и как MCP-сервер аналитики - можно подключить её к Claude Code или Cursor и спросить что-то вроде "какие у меня топ-проблемы за неделю" прямо из чата. Но это их собственный продукт, а не то, что измеряло исследование.

Косвенно из цифр про веб-поиск всё же следует практический вывод для агентного пайплайна: если хотите, чтобы Claude Code сам нашёл и выбрал ваш MCP-сервер или библиотеку без явной подсказки в промпте, надейтесь не на факт его существования, а на то, что он уже "осел" в приорах модели - через документацию, которую та видела при обучении, и через то, что легко гуглится в те самые 30% случаев, когда Claude Code вообще идёт в веб. Codex в этом смысле снисходительнее к новым именам - он гуглит почти всегда и активно фильтрует через site:, так что у малоизвестного, но хорошо задокументированного тула там шансов больше. У Cursor AI, кстати, своя история с попыткой удержать разработчиков внутри своей экосистемы - тоже вопрос не столько качества модели, сколько того, куда её направляют настройками.

Я полез проверить это на своём конвейере статей - blog-pipeline, тот самый, который генерирует и этот текст. Прогнал grep -ril "mcp" --include=*.py --include=*.md --include=*.json . по репозиторию - совпадение ровно одно: слово "mcp сервер" в keywords.json, в списке ключевых слов для тегов. Ни одного реального MCP-сервера в пайплайне нет - весь тулинг это ls scripts/*.py | wc -l → 15 обычных python-скриптов (bp_db.py, wordstat.py и ещё 13 таких же) поверх SQLite, вызываемые из cron. И это не игрушечный пример: bp_db.py published-titles --platform sunm8 возвращает 70 опубликованных статей на sunm8.ru, собранных этим самым пайплайном без единого MCP-подключения. Это ровно то, о чём говорит статистика Claude Code выше: агенту для рабочего пайплайна MCP не обязателен, если у него есть прямой CLI и понятные команды под рукой - лишний транспортный слой не нужен, когда задача и так решается прямым вызовом скрипта. Я вообще стараюсь держать тулинг Claude Code скупым по умолчанию - каждый лишний слой между агентом и задачей это либо лимит, либо точка отказа.

Что с этим делать, если у вас свой агентный пайплайн

Три вывода, которые я бы забрал из этого исследования, сделав скидку на то, кто его писал.

Во-первых, если продвигаете свой инструмент под ИИ-агентов - упоминания в чужих статьях и постах на Хабре почти ничего не решают, судя по разрыву PayPal и LangChain между "упомянули" и "выбрали". Решает то, что агент реально может прочитать и понять быстро: примеры кода, а не маркетинговые лендинги.

Во-вторых, если выбираете модель под агентный пайплайн, а не просто под чат - разница в поведении Claude Code, Codex и Cursor AI из таблицы выше не абстрактная: Codex надёжнее найдёт свежее или нишевое решение через агрессивный веб-поиск, а Claude Code скорее соберёт своё из того, что уже знает, и это быстрее, если вас устраивает "стандартный" стек вроде Stripe и Neon.

В-третьих, не переоценивайте значимость самого MCP как канала: 58% несовпадений в выборе инструментов между тремя агентами на одинаковых задачах - это в первую очередь про то, что у моделей разные приоры и разная готовность гуглить, а не про то, у кого какие серверы подключены. Мой собственный пайплайн без единого MCP-сервера тому косвенное подтверждение - для рабочей автоматизации хватает скриптов и cron, MCP тут не обязательное условие, а один из вариантов транспорта.