Зачем вообще измерять, какие инструменты выбирают агенты?

Когда разработчик вводит задачу в Claude Code, Codex или Cursor, он почти никогда не думает о том, что именно агент установит под капотом. Нужна база данных? Агент сам выберет между Neon и Supabase. Нужен поиск по коду? Агент сам решит — grep или ripgrep. Нужен HTTP-клиент? Выбор тоже за агентом.

По мере того как агенты берут на себя всё больше частей процесса разработки, один конкретный сценарий люди полностью делегируют ИИ — выбор сервиса для реализации конкретной потребности в уже существующем кодовой базе. Это делают и vibe-кодеры без технического бэкграунда, и опытные senior-инженеры.

Именно это наблюдение подтолкнуло стартап Armature (YC P26) к крупнейшему на сегодняшний день эксперименту в своём роде.

ℹ Об исследовании
Armature — стартап Y Combinator, который помогает dev-инструментам попасть в «выдачу» AI-агентов. Исследование проводилось на собственной инфраструктуре компании, результаты и полные трейсы сессий опубликованы в открытом доступе.

Методология: как считали 16 893 сессии

Исследователи наблюдали почти за 17 000 сессий с разными типами персон — vibe-кодеры, junior-инженеры в стартапах, senior-разработчики в корпорациях — при 1 163 вариантах промптов, 75 репозиториях и трёх агентах: Claude Code, Codex и Cursor, которые реально внедряли решения, а не просто рекомендовали их.

Из этих 16 893 запусков к публикации были отобраны 5 292 сессии на 51 кодовой базе и 18 секторах, признанных валидными.

Для начала исследователи проанализировали тысячи публичных GitHub-репозиториев, извлекая статистику по языкам, фреймворкам, сторонним сервисам и размерам команд. Выборку скорректировали по публично доступным данным, чтобы устранить перекос в сторону стартапов. Затем агентов «укомплектовали» для создания реальных репозиториев под эти требования. В итоге получилось 75 репозиториев на 10 языках с фиктивными названиями компаний, историями git и API-ключами, но реальными lockfile-файлами, верифицированными через npm и аналогичные реестры.


graph TD
    A["Анализ тысяч GitHub-репо"] --> B["Формирование панели: 75 репо, 10 языков"]
    B --> C["Генерация 1163 вариантов промптов"]
    C --> D["Запуск агентов: Claude Code / Codex / Cursor"]
    D --> E["16 893 сессии"]
    E --> F["Отбор 5292 валидных сессий"]
    F --> G["Публикация результатов + трейсов"]

Ключевые находки: как агенты ищут информацию

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

Поведение при веб-поиске: три совершенно разных стратегии

Cursor опирается на веб в 2/3 сессий. Codex почти всегда использует веб-поиск (94% сессий), причём в 9 случаях из 10 применяет операторы вроде site: для фокусировки на доверенных доменах. Claude Code же полагается прежде всего на собственные веса и обращается к вебу лишь в ~30% случаев.

Это принципиальное расхождение в архитектуре принятия решений:

АгентЧастота веб-поискаСтратегия
Codex~94% сессийЦелевой поиск с операторами (site:auth0.com)
Cursor~67% сессийОбщий веб-поиск по теме
Claude Code~30% сессийПриоритет внутренних прайоров модели

Стратегия поиска — это не просто технический выбор: она определяет, насколько агент «в курсе» актуального состояния экосистемы и чьи docs он читает в первую очередь.

Почему агенты так привязаны к CLI-инструментам

LLM читает и пишет текст. CLI принимает текст на вход и возвращает текст на выходе — это напрямую соответствует тому, как работает модель. Командная строка также компонуема, поддаётся скриптингу и плотно представлена в обучающих данных, что делает терминал более естественным интерфейсом для агента, чем графическая IDE.

Агенты лучше всего справляются с циклом, который образуют инструменты: найти в коде, отредактировать через diff, запустить тесты, сделать коммит.

Поэтому неудивительно, что в топ попадают именно текстовые утилиты: grep/ripgrep, curl, jq, git.

💡 Почему ripgrep выигрывает у grep
Cursor, Claude Code, Codex CLI и Aider — все выбрали ripgrep вместо стандартного grep. Причина — скорость: рекурсивный поиск с rg в 2,62 раза быстрее grep -R, обнаружение файлов с fd — в 2,46 раза быстрее find.

Три парадигмы — три разных агента

Исследование Armature показало, что сами агенты устроены принципиально по-разному, и это влияет на то, какие инструменты они предпочитают.

Три разные парадигмы: Codex — облачный автономный агент (запустил и забыл), Cursor — визуальная AI-IDE (интерактивное редактирование), Claude Code — нативный терминальный ассистент (глубокое рассуждение по кодовой базе).

Claude Code: глубина вместо широты

Claude Code создан для полной автономности: он не просто предлагает код, а читает файлы, вносит изменения, запускает shell-команды, управляет git-процессами и итерирует до выполнения задачи.

Claude Code рассматривает MCP как фундаментальную часть архитектуры: поддерживает конфигурации на уровне суб-агентов, поиск инструментов и серверы, встроенные в плагины.

Codex: облачная изоляция и параллелизм

В отличие от Claude Code и Cursor, Codex выполняет задачи в изолированных облачных контейнерах, не затрагивая локальную среду. Асинхронная параллельная модель позволяет одновременно передавать несколько задач и возвращаться к результатам позже — это удобно командам, которые хотят выстраивать очередь чётко сформулированных задач.

Cursor: IDE-подход с акцентом на скорость

Cursor позволяет переключаться между разными моделями — GPT-5.3-Codex, Claude Sonnet 4.5, Gemini 3 Pro и собственной моделью Composer — в рамках одной сессии. MCP Cursor рассматривает как плагинную систему с жёстким лимитом в 40 инструментов и настройкой в один клик из курируемого списка.

⚠ Важный нюанс об оркестровке
Оркестратор (harness) — это код вокруг модели, и он влияет на ваш счёт сильнее, чем сама модель. Он решает, что модель читает, что может запускать и что отбрасывает. Смените его — и та же модель сдвинется на 18 пунктов на тех же задачах.

Практические выводы: что это значит для разработчиков и вендоров

Если вы разработчик

Представьте: vibe-кодер строит персональное travel-приложение и замечает, что оно сбрасывается при каждом подключении. Он просит Claude Code: «мне нужно где-то хранить то, что я вввожу, чтобы это сохранялось при следующем открытии». Claude Code анализирует кодовую базу и через 5 минут отвечает: вам нужна база данных, и Neon подходит, потому что у неё есть бесплатный тир, она проста в установке и не приостанавливает приложение при отсутствии активности, как Supabase.

Это означает: агент не просто ищет популярный инструмент — он ищет тот, который объяснён понятно и доступен в знакомых агенту источниках.

Инструменты, которые выиграют в долгосрочной перспективе — те, что решат самую сложную задачу в этой области: не генерацию кода, а понимание контекста. Любой инструмент может написать функцию. Вопрос в том, какой инструмент понимает вашу кодовую базу достаточно хорошо, чтобы написать правильную функцию в правильном месте с соблюдением ваших конвенций.

Если вы вендор dev-инструмента

Большинство изменений находятся не в самом продукте: фиксы приземляются в документации, в процессе установки и в том, как продукт представлен в местах, где агенты ищут информацию.

Запуск считается успешным, когда агент устанавливает продукт и подключает его к репозиторию — а не просто упоминает его.

Другими словами: если ваш инструмент не попадает в контекст агента (через docs, npm/PyPI-страницы, авторитетные домены, индексируемые при site:-поиске), агент просто не выберет его — даже если он технически лучший.

# Пример того, как Codex ищет решение:
# site:auth0.com password reset MFA social connections
# Именно так агент формирует целевые запросы
# — ваш продукт должен быть на таких доменах
📝 Чеклист для вендора
  • ✅ Документация структурирована так, чтобы агент мог её пройти без GUI
  • ✅ Установка через одну команду (npm i, pip install, brew install)
  • ✅ Страница на npm/PyPI содержит ключевые use cases в тексте, а не только в картинках
  • ✅ Продукт упоминается на авторитетных доменах (official docs, Stack Overflow)
  • ✅ Есть MCP-сервер или CLI-интерфейс (агенты предпочитают текстовые интерфейсы)

Что дальше: «агентный SEO» как новая реальность

Взрывной рост CLI-инструментов для разработки в 2025–2026 годах отражает более глубокий сдвиг в том, как создаётся программное обеспечение. Терминал — уже не просто место для запуска команд. Это место, где вы делегируете работу AI-агентам, понимающим вашу кодовую базу, вашу git-историю и ваши намерения.

Чтобы понять, как агенты выбирают инструменты, команда Armature измерила почти 17 000 сессий в среде, где агенты работают точно так же, как в реальном мире — на разных репозиториях, взаимодействуя с разными персонами (vibe-кодеры, junior- и senior-инженеры) в компаниях разного размера.

Результат этой работы — не просто академический бенчмарк. Это первый шаг к тому, что исследователи называют «агентным SEO»: оптимизации продуктов под то, как их воспринимают и выбирают AI-агенты, а не люди. По аналогии с тем, как 15 лет назад компании учились оптимизировать контент для Google, сегодня им придётся учиться оптимизировать свои инструменты для Claude, Codex и Cursor.

Итоги

Исследование Armature с 16 893 сессиями даёт три главных вывода:

  1. Агенты используют веб радикально по-разному: Codex ищет в 94% случаев с операторами, Cursor — в 67% в режиме общего поиска, Claude Code полагается на свои прайоры в 70% сессий.
  2. CLI-инструменты выигрывают по умолчанию: ripgrep, curl, jq, git — естественный язык агентов, потому что они текстовые, компонуемые и хорошо представлены в обучающих данных.
  3. Выбор агента определяется доступностью в «точках поиска»: если ваш продукт не появляется там, где агент ищет (авторитетные домены, пакетные реестры, корректные docs), у него нет шанса быть выбранным — независимо от качества.

Для разработчиков это значит: понимать логику агента, которым вы пользуетесь, означает получать от него лучшие результаты. Для вендоров — это новая дисциплина роста, которую игнорировать уже нельзя.