Вы просите кодинг-агента «сделать, чтобы данные сохранялись», и через пять минут он возвращается с подключённой базой Neon. Просите «отправлять письма» — и получаете готовую интеграцию с Resend или SendGrid. Выбирать сервисы и библиотеки агент начал не потому, что вы его об этом попросили: он делает это по умолчанию, когда задача не содержит названия инструмента.
В сентябре 2026 года команда Armature опубликовала замер того, как именно это происходит: 16 893 сессии, в которых Claude Code, Codex и Cursor сами выбирали, какой сервис подключить, — без подсказки, какой вендор «правильный». Разбор подробностей исследования — в отдельной статье про кейс Armature. Здесь — выводы, которые из него следуют для практики, и то, как разработчику направлять выбор агента, а не полагаться на удачу.
site:), Claude Code — в основном на собственные знания (~30% веба). Совпадение всех трёх агентов — только в 42% случаев.Что на самом деле происходит при выборе
Когда вы не указываете инструмент, агент проходит короткую цепочку: анализирует кодовую базу и формулировку задачи, собирает список кандидатов из собственных знаний или веба, сравнивает их по конкретным деталям и называет победителя. Выглядит как размышление, но по данным Armature это скорее конвейер с предсказуемыми точками отказа.
Агенты не согласуются между собой
Первое, что показали 5292 валидные сессии, — три агента принимают разные решения, потому что по-разному ищут информацию. Cursor опирается на веб в двух третях сессий, Codex — почти всегда (94%, причём в девяти запросах из десяти сужает поиск операторами site:), а Claude Code в основном исходит из собственных знаний и ищет в вебе лишь в ~30% случаев. В новых категориях, где знаний меньше (например, песочницы), доля веб-поиска у него вырастает до ~80%.
Следствие прямое: во всех трёх агентах выбор совпал лишь в 42% «ячеек» эксперимента. В категории голосовых агентов Claude Code выбрал Twilio, Codex — OpenAI Realtime API, Cursor — Vapi. Claude Code и вовсе строит решение «внутри» почти вдвое чаще остальных: 19% против 10%.
Контекст репозитория важнее «лучшего вендора»
Один и тот же запрос на репозиториях на разных языках дал четырёх разных победителей в категории 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.
Упоминание — не победа
В каждой категории есть вендоры, которых агенты называют почти в каждом разговоре, но не выбирают. PayPal упомянут 139 раз и не выбран ни разу — Stripe выиграл 124 из этих 139 сессий. LangChain — самый цитируемый фреймворк (194 упоминания), выбран четыре раза. Supabase — самая упоминаемая база данных (242 упоминания), но всё равно проиграла Neon.
Детали на странице вендора переворачивают выбор
Выбор зависит не от одной «известности». Mailgun регулярно проигрывал Postmark, когда агент читал про «1-day retention» на бесплатном тарифе Mailgun. Supabase почти всегда проигрывала из-за лишних BaaS-функций (auth, storage, realtime) в общем бандле — когда агент искал просто базу данных. Из 5,3 тысяч сессий в 388 агент упоминал overhead платформенного управления, в 195 — стоимость. В заметной части этих случаев дело было не в реальном минусе продукта, а в том, как информация подана на странице.
Почему это важно: твой стек формирует агент
Доля решений о стеке, которые принимает агент, растёт быстрее, чем кажется. Vercel в апреле 2026 года сообщал, что более 30% деплоев инициированы кодинг-агентами — рост на 1000% за полгода (Vercel, «Agentic infrastructure»).
Если вы просите «сделай, чтобы данные сохранялись», агент выбирает Neon, а не «подходящую базу вообще». Если вас это устраивает — нормально. Если нет — выбор агента можно направлять. Причём именно потому, что выбор систематичен (на решение влияют язык репозитория, формулировка, детали тарифов и подача фактов), на него можно влиять теми же рычагами.
Тут и кроется риск, о котором агент не предупредит: он выбирает «популярное и логичное по своим источникам», а не то, что согласовано в вашей команде или доступно в вашем регионе. ИИ-агент для кодинга сегодня — это уже не генератор кода по команде, а участник инженерных решений, поэтому и управлять им нужно как участником: с правилами и границами. Про то, как зафиксировать допустимые рамки, — в гайде по AGENTS.md и в материале про своих ИИ-агентов.
Как направлять выбор агента
Приём 1. Называйте инструмент явно
Самый надёжный способ — упомянуть нужный сервис прямо в задаче или требованиях. Агент, в отличие от человека, не обижается на сужение вариантов и не торгуется.
Пример запроса без указания инструмента:
Мне нужно, чтобы данные сохранялись между перезаходами приложения.
Агент с вероятностью ~66% выберет Neon. Пример запроса с указанием инструмента:
Храни данные в Postgres на Supabase — мы уже используем её в проекте.
Не предлагай альтернативы без явного запроса.
Второй вариант стоит на пару токенов дороже и экономит часы на согласование стека, которое иначе случится уже после того, как код написан.
Приём 2. Фиксируйте стек в AGENTS.md
Правила проекта — лучший способ не дать агенту «переоткрыть» решение, которое команда уже приняла. В файл стоит включать и соглашения по коду, и допустимый стек по слоям. Полный разбор формата AGENTS.md — в отдельной статье, здесь — практический минимум для контроля выбора.
## Стек
- База данных: Postgres на Neon (использовать только её)
- Платежи: Stripe уже подключён — новых провайдеров не добавлять
- Email: Resend
- Деплой: Vercel (проект на Next.js)
## Чего агент не должен делать
- Не предлагать замену БД/платёжного провайдера без явного запроса
- Не добавлять сервисы с бесплатным тарифом «для проверки»
Если выбор инструмента для вас критичен — а выбор базы данных или платёжного провайдера переживает и код, и агента, — запишите его в правила. Это тот случай, когда «расплывчатое» правило дороже отсутствия правила.
Приём 3. Формулируйте критерии выбора
Когда инструмент честно не выбран и вы готовы рассмотреть варианты, перечислите агенту критерии. По данным Armature, агент и так сравнивает кандидатов по деталям: бесплатный тариф и его условия, число «лишних» функций, сложность управления. Дайте ему правильные рамки:
Подбери сервис для отправки писем. Критерии:
1. бесплатный тариф на старте;
2. хранение данных в РФ или ЕС;
3. оплата картой, выпущенной в РФ (или через посредника) — проверить;
4. без привязки к одному облаку.
Сравни 2-3 варианта и назови лучший с обоснованием.
Список критериев превращает скрытое решение агента в явное: он обязан показать, что сравнивал, и объяснить выбор. В исследовании Armature именно детали — бесплатный тариф, лишние функции, overhead — чаще всего и решали исход; список критериев заранее подставляет эти детали вместо того, чтобы агент додумывал их сам.
Приём 4. Проверяйте выбор, а не только код
Агент пишет корректный код, но подключённый сервис может не совпадать с согласованным в команде. Судя по данным Armature, агенты в 58% «ячеек» расходятся между собой — не полагайтесь на то, что «все агенты выберут одно и то же». Diff-ревью должно включать вопрос «почему этот провайдер?». До того как агент начнёт менять код, полезно требовать обоснования выбора — эта практика разобрана в статье про ИИ и базы данных.
Чек-лист: что проверить перед тем, как отпустить агента подключать сервис
- [ ] В задаче явно назван инструмент, если выбор уже сделан командой
- [ ] В AGENTS.md зафиксирован стек по слоям: БД, платежи, email, хранилище, деплой
- [ ] В AGENTS.md перечислены недоступные в вашем регионе вендоры (см. блок «Российские реалии» ниже)
- [ ] Агенту даны критерии выбора, а не расплывчатое «сделай удобно»
- [ ] Ревью включает вопрос «почему подключён именно этот провайдер»
- [ ] Агент не добавил «пробный» сервис, которого не было в стеке
Российские реалии
Исследование само по себе от региона не зависит — но вывод «агент выбирает Neon/Supabase/Stripe» в российском контуре упирается в доступность и оплату выбранных сервисов. Проверять надо не агента, а именно выбранный им инструмент.
Что из «победителей» Armature доступно в РФ. 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 не работают, оплата подписок — через зарубежные карты и посредников. Русскоязычный опыт работы с ними есть: разбор Codex CLI в российском контексте на Хабре (что умеет, как оплачивать) и руководство по Claude Agent SDK (июль-август 2026). Но разница в поведении агентов, которую показало исследование, от региона не зависит — она в источниках знаний, а не в географии.
Русскоязычных разборов именно этого исследования на момент публикации нет — материал вышел за неделю до этой статьи. Смежные темы в рунете освещены: выбор агентами инструментов обсуждается в контексте своих ИИ-агентов, а работа с базами данных через ИИ — в статье про SQL.
Куда это ведёт: разговор про devtools
Если агент сам выбирает, какой сервис подключить, то вендорам приходится продавать не человеку, а модели — и любая нейросеть для кодинга превращается в канал дистрибуции инструментов. В начале сентября на Hacker News это сформулировали как вопрос «Are Devtools Dead?»: зачем платить за линтер, инструмент миграций или интеграцию с мониторингом, если агент «просто делает» это сам. Первый ответ в треде спорит с самой постановкой вопроса:
Sounds like something a shovel salesman would say. It doesn’t make sense to trade deterministic, efficient code for unreliable agents. The agents will use the same tools we do and will be more effective that way.
Звучит как слова продавца лопат. Нет смысла менять детерминированный, эффективный код на ненадёжных агентов. Агенты будут использовать те же инструменты, что и мы, — просто эффективнее.
— verdverm, HN-тред «Are Devtools Dead?», 05.09.2026
Практический вывод из этого спора для разработчика скромнее: отмирает не класс инструментов, а класс «человеческих рабочих процессов» вокруг них. Линтер никуда не девается — просто его теперь вызывает агент, и решение о том, какой линтер и с какими правилами, тоже стоит принимать явно, пока его не приняли за вас.
Честные ограничения
- Armature продаёт «влияние на агентов». Дисклеймер исследования прямо говорит о коммерческой цели: показать вендорам, как продвигать продукт. Методология открытая (трейсы публичны), но конфликт интересов стоит держать в голове.
- Выборка — не случайный срез интернета. Репозитории сгенерированы под нужное распределение языков и стеков; персоны и промпты — тоже. Валидными признаны 5292 сессии из 16 893.
- «Судья» — тоже модель. Валидность сессий и победителя определяла ещё одна инстанция Gemini 3.7 Flash.
- Симулированный человек ≠ настоящий. Оркестратор почти всегда соглашался с топ-1 вариантом агента. Реальный пользователь чаще имеет предпочтения — итоговые доли вендоров в реальности будут другими.
- Рынок движется. Доли в 66% у Neon и 88% у Stripe отражают состояние на август–сентябрь 2026 года и поведение трёх конкретных агентов в конкретных версиях.
Вывод
Главный вывод из исследования — не про вендоров, а про то, кто теперь принимает решения о стеке. Агент, которому поручили «сделай удобно», сам выбирает вендора — и выбор этот систематичен, а значит, им можно управлять.
Практика сводится к четырём действиям: называйте нужный сервис явно, фиксируйте допустимый стек в AGENTS.md, формулируйте для агента критерии вместо расплывчатого «лучшего решения» и проверяйте при ревью и код, и «почему подключён именно этот провайдер». Если вы сами строите агентов, которые что-то подключают, — те же данные пригодятся как список того, что агенты реально проверяют. Агент умеет подключить что угодно — вопрос в том, кто решает, что именно.
Дальше по теме: что такое агентный кодинг, агенты-мейнтейнеры модулей, контекст агента, ИИ в терминале, мультиагентные workflow.
