Третьего сентября 2026 года команда Armature опубликовала необычный замер: вместо бенчмарка «напиши код» они прогнали 16 893 реальных сессии, в которых три кодинг-агента сами выбирали, какой сервис подключить под описанную задачу. Claude Code, Codex и Cursor сами решали, какую базу данных поставить, каким провайдером писем воспользоваться, какую платформу деплоя выбрать — без подсказки, какой вендор «правильный».
Разбор ниже — по самому исследованию Armature и открытым данным: методология, пять главных наблюдений и то, что это значит для разработчика, чей стек теперь отчасти выбирает агент.
Что именно измерили
Armature — не исследовательская лаборатория: компания продаёт сервисы роста для dev-инструментов, и в дисклеймере пишет об этом прямо.
Armature sells growth services to dev tools. This study is part of our broader work on how to influence coding agents’ choices and get products picked.
Armature продаёт сервисы роста для dev-инструментов. Это исследование — часть нашей более широкой работы над тем, как влиять на выбор кодинг-агентов и продвигать продукты.
— дисклеймер исследования, armature.tech, 03.09.2026
Мотивация простая: решения о стеке всё чаще принимает не человек, а агент. Armature цитирует Vercel:
over 30% of deployments were initiated by coding agents, up 1000% from six months ago
более 30% деплоев инициированы кодинг-агентами — рост на 1000% за полгода
— Vercel, «Agentic infrastructure», апрель 2026, в пересказе исследования Armature
Чтобы понять, как агенты принимают такие решения, Armature поставила эксперимент: взяла три агента, семьдесят пять репозиториев на десяти языках и четыре «персоны» пользователя — от виб-кодера, который описывает только симптомы, до инженера крупного предприятия с требованиями по комплаенсу и закупкам. Итого 1163 вариации промптов. Каждый прогон шёл в эфемерной песочнице (E2B, Blaxel, Daytona), а в цикле участвовал «симулированный человек» — оркестратор на Gemini 3.7 Flash, который отвечал агенту, как живой пользователь: просил сначала проанализировать кодовую базу и предложить вариант, потом утверждал лучшее решение. Из 16 893 сессий валидными для публикации признали 5292 — на 51 кодовой базе и в 18 категориях инструментов. Все трейсы, включая промпты и diff’ы, Armature открыла публично.
Отправная точка: один и тот же ответ на разные вопросы
С чего всё началось — в тексте исследования приведён показательный пример. Виб-кодер делает личное приложение для путешествий и обнаруживает, что данные сбрасываются при каждом перезаходе. Он пишет Claude Code:
I need you to store what I input in the app somewhere so that next time it’s still there when I reopen the app
Мне нужно, чтобы ты сохранял то, что я ввожу в приложение, где-то так, чтобы в следующий раз оно всё ещё было там, когда я снова открою приложение
Через пять минут агент отвечает:
You need a database and Neon fits well because it has a free tier, is simple to install and won’t pause your app like Supabase does if you don’t use it too often.
Тебе нужна база данных, и Neon подходит: у него есть бесплатный тариф, он просто устанавливается и не будет останавливать твоё приложение, как Supabase, если ты не пользуешься им слишком часто.
— Claude Code в эксперименте Armature, armature.tech, 03.09.2026
Старший инженер в production-приложении спрашивает Cursor: «какое решение для базы лучше для этого приложения, нужны предсказуемые расходы и полное управление» — и через пять минут получает тот же вывод: Neon. Разные агенты, разные кодовые базы, разные персоны, разные промпты — одинаковое решение. Armature задалась вопросом: сохранится ли совпадение, если расширить тест на другие категории инструментов?
Пять наблюдений из 5292 сессий
1. Агенты используют разные источники и не соглашаются друг с другом
Первое, что выяснилось: три агента принимают решения не одинаково, потому что по-разному ищут информацию.
- Cursor опирается на веб в двух третях сессий.
- Codex почти всегда использует веб-поиск — в 94% сессий, причём в девяти запросах из десяти добавляет операторы вроде
site:, чтобы сузить поиск до доверенных доменов или конкретного решения. - Claude Code в основном полагается на собственные знания и ищет в вебе лишь в ~30% случаев. Но когда ищет — просматривает в три раза больше страниц, чем Codex. В новых категориях, где знаний меньше (например, песочницы), доля веб-поиска у него вырастает до ~80%.
Следствие — расхождения. Во всех трёх агентах совпал выбор лишь в 42% ячеек. В категории голосовых агентов Claude Code выбрал Twilio, Codex — OpenAI Realtime API, а Cursor — Vapi. Claude Code и вовсе строит решение «внутри» почти вдвое чаще Codex и Cursor: 19% против 10%.
2. Контекст репозитория важнее, чем «лучший вендор»
Один и тот же запрос на четырёх репозиториях на разных языках дал четырёх разных победителей в категории email-провайдеров: на TypeScript выиграл Resend (55 из 89 прогонов), на Python — SendGrid (22 из 24), на Go — Postmark (20 из 24), на Java — Azure Communication Services (22 из 23). Vercel побеждает на TypeScript-репозиториях (и в 100% случаев, когда в проекте Next.js), но на Python-репозиториях его не рекомендовали ни разу — там доминировал Render.
3. Упоминание — не победа
В каждой категории есть вендоры, которых агенты называют почти в каждом разговоре, но не выбирают. В платежах PayPal упомянут 139 раз и не выбран ни разу — Stripe выиграл 124 из этих 139 сессий. Adyen упомянут 175 раз, выбран трижды. LangChain — самый цитируемый фреймворк (194 упоминания), выбран четыре раза. Netlify упомянут 152 раза, выбран 6 раз как платформа деплоя. Supabase — самая упоминаемая база данных (242 упоминания), но всё равно проиграла Neon.
4. Детали на странице вендора переворачивают выбор
Выбор зависит не только от «известности». Mailgun регулярно проигрывал Postmark, когда агент читал про «1-day retention» на бесплатном тарифе Mailgun. Supabase почти всегда проигрывала из-за лишних BaaS-функций — auth, storage, realtime — в общем бандле, когда агент искал просто базу данных. Из 5,3 тысяч сессий в 388 агент упоминал overhead платформенного управления, в 195 — стоимость. В заметной части этих случаев дело было не в реальном минусе продукта, а в том, как информация подана на странице.
5. Одни рынки монополизированы, другие оспариваются
- Платежи: Stripe выиграл в девяти случаях из десяти, проигрывая только в специфических сценариях с европейским регулированием (там побеждали Paddle и Mollie). В лидерборде у Stripe 88,4% из 395 прогонов.
- Базы данных: Neon победил в 66% сессий, дальше — «родные» решения облачных платформ (Azure, AWS).
- Файловое хранилище: Amazon S3 — 45% (в лидерборде 45,6% из 90 прогонов), Azure и GCP — по ~20%.
- Email: плотная борьба — Resend 35,6%, Postmark 27,4%.
Полную картину по категориям Armature выложила в публичный лидерборд.
Как агент принимает решение: от задачи до установки
Если собрать процесс, который стоит за этими цифрами, получается короткая цепочка — она в каждом прогоне повторяется с точностью до деталей.
- Задача. Пользователь описывает, что нужно: «хранить данные», «отправлять письма», «обрабатывать платежи» — часто без указания категории инструмента.
- Поиск кандидатов. Агент сверяется с собственными знаниями и/или вебом. Выбор источника сильно влияет на результат: Claude Code чаще исходит из priors, Codex почти всегда идёт в веб с
site:-фильтрами, Cursor — в веб в двух третях случаев. - Оценка. Агент сравнивает кандидатов по конкретным деталям: есть ли бесплатный тариф, что в него входит, не «засыпает» ли сервис при простое, что сказано про ретеншн данных, насколько сложно управлять платформой. Именно эти детали, а не громкость бренда, чаще всего решают исход.
- Решение и установка. Агент называет победителя, человек одобряет (в эксперименте — симулированный), агент подключает сервис в код.
На выбор давят несколько факторов — часть из них агент видит в коде, часть в страницах вендоров.
Что это значит для разработчика
Главный вывод из исследования не про вендоров, а про то, кто теперь принимает решения о твоём стеке.
Твой стек отчасти выбирает агент. Когда вы просите «сделай, чтобы данные сохранялись», агент выбирает Neon, а не «подходящую базу данных вообще». Если вас это устраивает — нормально. Если нет — выбор агента можно и нужно направлять, и Armature (со своими целями, но по тем же данным) показывает три рабочих рычага.
- Называйте инструмент явно. Самый надёжный способ — упомянуть нужный сервис прямо в запросе или требованиях: «используй Postgres на Neon», «мы платим за Stripe, не предлагай альтернативы». Агент, в отличие от человека, не обидится на сужение вариантов.
- Зафиксируйте стек в AGENTS.md. Правила проекта — лучший способ не дать агенту «переоткрыть» решение, которое команда уже приняла. Подробнее о том, как строить такие файлы, — в статье про AGENTS.md и в гайде про своих ИИ-агентов.
- Проверяйте выбор, а не только код. Агент пишет корректный код, но подключённый сервис может не совпадать с тем, что согласовано в команде. Diff-ревью должно включать и вопрос «почему этот провайдер?». Судя по данным исследования, агенты в 58% ячеек расходятся между собой — не полагайтесь на то, что «все агенты выберут одно и то же».
Отдельный слой — критичность самого решения. Выбор базы данных или платёжного провайдера переживает и код, и агента, а заменить его после подключения дорого. Здесь полезна практика из статьи про ИИ и базы данных: требовать от агента обоснования выбора до того, как он начнёт менять код, а не после.
Если решение о стеке размазано по большой кодовой базе, стоит и структурно ограничить, кто и за что отвечает: паттерн агентов-мейнтейнеров, когда у каждого модуля свой агент-владелец, сужает и выбор инструментов до контекста одного модуля, и последствия неверного решения.
Если вы сами строите агентов, которые что-то подключают, — данные Armature пригодятся как список того, что агенты реально проверяют: free tier, детали тарифов, сложность управления, язык репозитория. Логика выбора сервиса мало отличается от логики выбора инструмента внутри проекта, о которой мы писали в материале про агентный кодинг и практике агентов в терминале.
Честные ограничения
- Armature продаёт «влияние на агентов». Дисклеймер прямо говорит о коммерческой цели: показать вендорам, как продвигать продукт. Методология при этом открытая (трейсы публичны), но конфликт интересов стоит держать в голове при чтении выводов.
- Выборка — не случайный срез интернета. Репозитории сгенерированы командой под нужное распределение языков и стеков; персоны и промпты — тоже. 5292 валидных сессии из 16 893 — фильтрация жёсткая, и часть результатов «не прошла» по критериям судьи.
- «Судья» — тоже модель. Валидность сессий и победителя определяла ещё одна инстанция Gemini 3.7 Flash. Автоматическая оценка того, кто «победил», может отличаться от человеческой.
- Симулированный человек ≠ настоящий. Оркестратор в цикле почти всегда соглашался с топ-1 вариантом агента или просил выбрать лучший. Реальный пользователь чаще имеет предпочтения и торгуется — итоговые доли вендоров в реальности будут другими.
- Рынок движется. Доли в 66% у Neon и 88% у Stripe отражают состояние на август–сентябрь 2026 года и поведение трёх конкретных агентов в конкретных версиях. Через полгода картина может измениться.
Российские реалии
Исследование само по себе от региона не зависит — но вывод «агент выбирает Neon/Supabase/Stripe» в российском контуре упирается в доступность и оплату выбранных сервисов. Проверять надо не агента, а именно выбранный им инструмент.
Сервисы, которые агенты выбирают чаще всего, в РФ доступны — вопрос в оплате платных тарифов. Neon и Supabase открываются без VPN, бесплатные тарифы работают без карты: у Neon это 0,5 ГБ хранилища и 100 CU-часов в месяц на проект, у Supabase — 500 МБ базы и 2 проекта (Supabase pricing). Русскоязычный опыт работы с обоими есть: на Хабре разобраны четыре production-инцидента с advisory locks на Neon (май 2026) и кейс сборки новостного агрегатора на Supabase (июнь 2026). Платные тарифы (Neon Launch, Supabase Pro от $25/мес) оплачиваются только зарубежной картой — российские Visa/Mastercard и Mir не проходят. Общие схемы оплаты зарубежных dev-подписок разобраны на Хабре.
Парадокс Stripe как победителя. В эксперименте Stripe выиграл 9 из 10 сессий в платежах — но Stripe не принимает российских продавцов, и для российского продукта «выбрать Stripe» значит выбрать недоступную опцию. Агент не знает о региональных ограничениях, если вы их не пропишете. Это лишний довод за то, чтобы фиксировать допустимый стек в AGENTS.md — включая то, какие платёжные провайдеры реально доступны.
Сами агенты. Claude Code, Codex и Cursor из российских IP без VPN не работают, оплата подписок — через зарубежные карты и посредников (Anthropic и OpenAI не ведут официальных продаж в РФ). Но разница в поведении агентов, которую показало исследование, от региона не зависит — она в источниках знаний, а не в географии.
Русскоязычных разборов именно этого исследования на момент публикации нет — материал вышел за неделю до этой статьи. Смежные темы в рунете освещены: выбор агентами инструментов обсуждается в контексте своих ИИ-агентов, а работа с базами данных через ИИ — в статье про SQL.
Вывод
Исследование Armature — первая большая попытка измерить то, что раньше обсуждали на уровне anecdotes: агент, которому поручили «сделай удобно», сам выбирает вендора. 5292 валидные сессии показали, что выбор не случаен и не «по рекламе»: решают контекст репозитория, детали тарифов и то, как вендор подаёт свои ограничения. При этом агенты не согласуются между собой — в 58% ячеек три агента выбрали разных победителей.
Для практики вывод простой: выбор инструмента — такое же инженерное решение, как выбор архитектуры, и его стоит так же контролировать. Называйте нужный сервис явно, фиксируйте допустимый стек в AGENTS.md и проверяйте при ревью не только код, но и «почему подключён именно этот провайдер». Агент умеет подключить что угодно — вопрос в том, кто решает, что именно.
