- Início
- The Thinking Wire
- 16.893 Sessões, Três Agentes de Código, 42% de Acordo: Sua Compra É o Agente que Estava Aberto
16.893 Sessões, Três Agentes de Código, 42% de Acordo: Sua Compra É o Agente que Estava Aberto
A Armature rodou 16.893 sessões de agentes de código em 75 repositórios, com 1.163 variações de prompt e três agentes (Claude Code, Codex, Cursor), e manteve como válidas 5.292 sessões em 51 codebases e 18 setores. Os setores iam de pagamentos e bancos de dados a deploy e observabilidade. A pergunta era qual fornecedor cada agente escolheria quando a tarefa exigisse um. Os três agentes escolheram a mesma ferramenta em apenas 42% das células.
Pegue uma célula. Ao receber o pedido de adicionar voz, o Claude Code foi para o Twilio, o Codex para a OpenAI Realtime API, o Cursor para o Vapi. Mesma tarefa, mesma classe de repositório, três relações com fornecedor. Quem abriu o terminal decidiu qual delas a sua empresa passaria a operar.
Argumentamos em fevereiro que agentes têm opiniões, com base nas 2.430 respostas só do Claude coletadas pela amplifying.ai. Aquele estudo mostrou que um agente tem defaults fortes. Este acrescenta três agentes em vez de um, repositórios em vez de prompts soltos, e uma taxa medida de desacordo entre agentes. Os 42% transformam “agentes têm opiniões” em problema de compras.
A escolha depende do seu repositório
A linguagem decidiu o fornecedor para o mesmo pedido de email. Segundo a Armature: Resend venceu em TypeScript (55 de 89 execuções), SendGrid em Python (22 de 24), Postmark em Go (20 de 24), Azure Communication Services em Java (22 de 23). Um prompt, quatro vencedores, e a variável decisiva foi a linguagem do repositório.
Para quem tem um parque poliglota a consequência é direta. Serviços em Go e serviços em TypeScript tenderiam a cair em provedores de email diferentes, a menos que algo os impeça. Ninguém escolheu isso. O agente leu o repositório e o fornecedor seguiu a linguagem, viesse de priors ou do que uma busca restrita àquela linguagem devolveu.
A escolha depende do hábito de busca do agente
Os três agentes pesquisam de formas diferentes, e o método molda a resposta. O Codex usou busca na web em 94% das sessões, e em nove consultas de cada dez usou operadores como site:. O Claude Code se apoiou principalmente nos próprios priors e buscou na web em cerca de 30% dos casos. O Cursor baseou a decisão na web em dois terços das sessões.
Construir ou comprar se dividiu pelas mesmas linhas. O Claude Code construiu internamente quase o dobro das vezes do Codex e do Cursor (19% contra 10%). No leaderboard como um todo, construir internamente venceu cerca de 13% das vezes, e cerca de 52% das execuções em performance no CI.
Um agente que busca fica exposto ao que a web diz hoje. Um agente que se apoia em priors fica exposto ao que a web dizia quando o modelo foi treinado. Nenhum dos dois fica exposto à sua política de compras, porque essa política está fora da web e fora dos pesos.
Citado 139 vezes, escolhido zero
O estudo separa menções de seleções, e a distância entre as duas é o achado mais útil para quem vende ferramentas de desenvolvimento ou compra essas ferramentas.
O PayPal foi citado 139 vezes e nunca escolhido. O Stripe venceu 124 dessas 139 sessões. O LangChain foi o framework mais citado, 194 menções, e foi escolhido 4 vezes. O Netlify foi mencionado 152 vezes e escolhido 6.
O agente percorre o mercado e depois converge. No leaderboard: Stripe 88,4% em pagamentos, Neon 66,3% em bancos de dados, AWS 61,9% em nuvem, E2B 42,5% em sandboxes de agentes, Vercel 41,5% em deploy com Render em 34,4%, Sentry 36,9% em observabilidade, Langfuse 33,7% em avaliação de LLM com construção interna em 29,2%, WorkOS AuthKit 26,4% em autenticação. Pagamentos está quase decidido. Autenticação e observabilidade seguem disputadas, e uma categoria disputada é onde qualquer condicionamento, do agente ou do repositório, tem mais espaço para mover a escolha.
A página de preços é superfície de ataque
Agentes leem páginas de preços e agem sobre o texto. A Armature relata que o Mailgun perdeu repetidamente para o Postmark quando agentes leram “retenção de 1 dia” no plano gratuito. Das 5.292 sessões (a Armature arredonda para 5,3 mil), 388 mencionaram overhead de gestão da plataforma e 195 mencionaram custos.
Visto do lado do fornecedor: no estudo, uma frase numa página de plano gratuito mudou qual fornecedor o agente selecionava, ao longo de muitas sessões, sem humano no circuito. A Armature declara o que isso significa para o próprio negócio: “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.” A empresa que rodou o estudo vende a capacidade de mover esses números. Isso é conflito de interesse e deve moldar a leitura do relatório. Os dados continuam de pé, e a declaração confirma a tese por um ângulo que nenhum leitor pode descartar: já existe uma indústria vendendo influência sobre o que o seu agente instala.
Descrevemos capacidade como commodity e orquestração como moat. A lista de fornecedores agora faz parte da orquestração. Se o seu scaffold não nomeia os fornecedores aprovados, os priors do agente nomeiam por você, e alguém está pagando para moldar esses priors.
O que o estudo sustenta e o que não sustenta
A metodologia merece ser dita sem rodeios. Os repositórios eram sintéticos: nomes de empresa falsos, históricos de git falsos, chaves de API falsas, lockfiles reais, distribuídos em dez linguagens. As sessões foram julgadas por um LLM, o Gemini 3.7 Flash. Prosa e widget do leaderboard divergem em frações de ponto em alguns lugares (S3 “45%” contra 45,6%), então os valores do widget são os usados aqui.
Repositórios sintéticos significam que os agentes viram codebases plausíveis. A sua codebase, com os seus contratos de fornecedor já nas dependências, ficou de fora. Um juiz LLM significa que os rótulos de seleção carregam a taxa de erro daquele modelo. O achado central sobrevive às duas ressalvas: três agentes, diante da mesma tarefa, divergem com frequência. As porcentagens exatas são outra história, e nenhum orçamento deveria ser construído sobre elas.
O estudo não diz qual agente escolhe melhor. Não há verdade de referência para “melhor fornecedor” nele, e nós tampouco vamos acrescentar uma. O número da própria Vercel, citado pela Armature, de que mais de 30% dos deployments foram iniciados por agentes de código, alta de 1000% em seis meses, vem do blog de um fornecedor. Registramos como contexto e nada além disso.
Faça isto agora
Escreva a allowlist de fornecedores e coloque-a onde o agente lê. Concretamente:
- Para cada categoria de capacidade que os seus agentes tocam (email, pagamentos, banco de dados, deploy, autenticação, observabilidade, avaliação de LLM), nomeie o fornecedor ou fornecedores aprovados. Onde já existe contrato, a lista é o contrato. Onde não existe, decida agora, porque o agente vai decidir de outro jeito.
- Coloque a lista no arquivo de instruções do repositório que todo agente que você roda lê (CLAUDE.md, AGENTS.md, regras do Cursor). Faça a mesma lista aparecer em todos os repositórios, independentemente da linguagem. A deriva condicionada pela linguagem é a falha específica que os dados mostram.
- Adicione um gate de dependências no CI que falhe diante de um SDK ou pacote novo de fornecedor não aprovado. O arquivo de instruções orienta. O gate impõe.
- Registre qual agente abriu cada pull request que adicionou dependência. Sem esse registro, você não consegue auditar os 42% dentro do seu próprio parque.
- Trate o texto da página de preços de um fornecedor como entrada não confiável para a sua compra, do mesmo jeito que trata uma dependência da cadeia de suprimentos. Fizemos o argumento da cadeia de suprimentos antes. A escolha de fornecedor pelo agente agora pertence a essa lista.
Três agentes, uma tarefa, 42% de acordo. O número vai se mover conforme modelos e fornecedores se adaptem uns aos outros. Se ele vai mover a sua compra depende de você ter escrito a lista primeiro.
Fontes
- Armature, Inc. “Which Tools Do Claude Code, Codex, and Cursor Choose?.” Setembro de 2026.
A Victorino ajuda times de engenharia a transformar política de fornecedores em allowlists legíveis por agentes e gates de CI antes que os agentes decidam por eles: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa