Uma oficina compartilhada pode ter ferramentas diferentes para trabalhos diferentes, desde que todos sigam as mesmas regras de segurança. Nas empresas, a pergunta não é qual agente vence em tudo: é como escolher sem perder controle nem ficar preso a um fornecedor.
Minha recomendação é um agente padrão por fluxo, uma alternativa homologada e políticas e evals comuns. Benchmarks públicos ajudam a selecionar candidatos; dados internos decidem o que fica, o que sai e qual modelo atende cada tarefa. Os exemplos do iFood, da Tecban e de outras empresas mostram por que essa decisão precisa considerar entrega, qualidade, custo e risco — não só adoção ou demonstrações impressionantes.
Neste texto:
- 1. Adoção não é resultado
- 2. O que empresas brasileiras já fazem
- 3. O que os benchmarks dizem sobre cada agente
- 4. A estratégia recomendada: portfólio pequeno, política comum
- 5. Como rotear modelos e decidir o que fica de fora
- 6. O control plane e os sensores que tornam a estratégia verificável
- 7. Como medir valor para a empresa
1. Adoção não é resultado
Na pesquisa Developer Ecosystem 2026, com mais de 15 mil desenvolvedores profissionais, 90% disseram usar coding agents no trabalho ao menos semanalmente; 68%, diariamente. Entre maio e julho, Claude Code apareceu em 39% das respostas, GitHub Copilot em 21%, Codex em 16% e Cursor em 12%. Como as categorias se sobrepõem, esses números medem adoção declarada, não qualidade ou retorno financeiro. Fonte: JetBrains Research.
A JetBrains relata que as despesas de IA cresceram cerca de dez vezes em seis meses e que muitos desenvolvedores já usavam três a cinco ferramentas por mês. Para centralizar autenticação, roteamento e orçamento, evoluiu um wrapper de CLI para o JetBrains Central. Mais de mil desenvolvedores internos adotaram a solução em poucas semanas; naquele momento, ela cobria três agentes de terminal. Fonte: relato da JetBrains.
Já a Box padronizou o Cursor como IDE e plataforma de agentes. O case relata mais de 800 desenvolvedores usando a ferramenta diariamente, adoção de 85% na engenharia e um programa de mentoria. A liderança estima aumento de 30% a 50% na capacidade de entrega do roadmap. São números divulgados pela Box em um case do fornecedor, sem experimento que isole o efeito da ferramenta. Fonte: case Box/Cursor.
Box escolheu uma ferramenta principal; JetBrains preservou opções e centralizou autenticação, uso e orçamento. A solução da JetBrains cobre os ambientes compatíveis, mas não estabelece um padrão de governança entre harnesses.
Eu manteria um agente principal, mas deixaria contexto, permissões, métricas e critérios de qualidade acessíveis fora dele. Se a plataforma não expõe integrações ou sinais necessários, a conveniência pode virar dependência. Uma segunda opção homologada permite comparar resultados e preparar uma migração sem exigir que todos usem todas as ferramentas.
Essa disputa já chegou ao trabalho de engenharia. A DORA relata que 90% dos profissionais de tecnologia usam IA no trabalho e que mais de 80% percebem aumento de produtividade. Mas a adoção também se associa a mais throughput e mais instabilidade na entrega. A IA amplifica o sistema existente: com boas plataformas e testes, ajuda; com ferramentas fragmentadas e processos frágeis, acelera a dívida técnica. Fonte: DORA, 2025.
Por isso a pergunta não é se todo mundo precisa usar IA em toda tarefa. Na pesquisa do Stack Overflow com mais de 49 mil pessoas, 80% já usavam ferramentas de IA, mas só 29% confiavam na precisão das respostas; 45% apontaram soluções “quase certas” como a maior frustração e 66% disseram gastar mais tempo corrigindo esse tipo de código. Lançar licenças sem preparar quem revisa e mantém o software pode ampliar a distância entre quem experimenta e quem precisa absorver o custo dos erros. Fonte: Stack Overflow Developer Survey 2025.
A resposta não é tratar ceticismo como resistência. A DORA identifica uma posição sobre IA que seja clara e comunicada como um fator que modera o impacto da adoção no throughput. Para a empresa, isso pede formação, participação dos desenvolvedores na escolha dos fluxos e regras comuns de teste e revisão. Sem isso, a corrida por ferramentas pode virar um conjunto de usos desiguais e difíceis de governar. Fonte: DORA 2025, errata sobre a Figura 34.
2. O que empresas brasileiras já fazem
No iFood, o time de Developer Experience identificou a espera por revisão como gargalo. No recorte publicado, a empresa tinha mais de 1.500 pessoas em engenharia, cerca de 10 mil repositórios e aproximadamente 18 mil merge requests por mês; quase metade dos MRs analisados tinha menos de 30 linhas. Fonte: engenharia do iFood.
O Auto Approval aplica regras e análise de risco a mudanças pequenas e pode aprovar automaticamente as que ficam abaixo do limite definido. O iFood relata redução de cerca de 33% no tempo global de aprovação e de 58% nos MRs com menos de 30 linhas. Esses percentuais são do fluxo de revisão, não de um coding agent: o Auto Approval é um sensor determinístico sobre merge request pequeno. À parte, a GenPlat reúne mais de 150 modelos, limites de uso, sanitização, controles de segurança e fallback. Os resultados são relatos da própria empresa, não de um experimento independente. Fonte: engenharia do iFood.
O iFood também descreve Copilot, Cursor e Claude Code consultando documentação de engenharia por um MCP interno. Esse MCP é um terceiro desenho, distinto do Auto Approval e da GenPlat. O relato apresenta a arquitetura, mas não quantifica ganho de produtividade nessa integração. Fonte: engenharia do iFood.
Na Tecban, o uso do GitHub Copilot veio acompanhado de registro de demandas, avaliação de risco e validação técnica antes da produção. No case da Microsoft, a empresa estima ganhos de cerca de 30% no desenvolvimento e 14% nos testes. A fonte não detalha método de cálculo nem grupo de controle; são estimativas reportadas pela Tecban. Fonte: case Tecban/Microsoft.
Em pesquisa de 2024 com 500 profissionais brasileiros de organizações com mais de mil funcionários, 99% disseram já ter experimentado ferramentas de criação de código por IA. Na percepção dos participantes, 40% das empresas incentivavam o uso; 39% permitiam com incentivo limitado. A pesquisa não informa quantas medem qualidade, custo ou estabilidade do código. Fonte: pesquisa do GitHub no Brasil.
3. O que os benchmarks dizem sobre cada agente
Comparar agentes só pela marca esconde variáveis importantes. O que precisa ser comparado é agente + modelo + configuração + tarefa. Um estudo apresentado no MSR 2026 analisou 7.156 PRs fechados e comentados ou revisados em repositórios públicos, gerados em 2024 e 2025. Os resultados abaixo agregam o recorte observado, mas cada agente foi medido em um período diferente: Pinna e colegas, Comparing AI Coding Agents.
| Agente | PRs no estudo | PRs mergeados no recorte |
|---|---|---|
| Codex | 2.002 | 77,9% |
| Cursor | 569 | 74,5% |
| Claude Code | 139 | 71,9% |
| GitHub Copilot | 2.194 | 68,0% |
| Devin | 2.252 | 61,6% |
Esses percentuais não servem para escolher um vencedor. A amostra do Claude Code é menor, os períodos variam e os agentes receberam tarefas diferentes. O estudo encontrou 82,1% de aceitação em documentação e 66,1% em novas funcionalidades; por categoria, Claude Code liderou documentação e funcionalidades, enquanto Cursor se destacou em correções. Merge não prova ausência de defeitos: use o resultado para formular testes internos, não como comparação causal de produtividade ou qualidade.
O contexto da tarefa também muda o resultado. No SWE-Bench Mobile, pesquisadores avaliaram 22 combinações de agente e modelo em tarefas de um produto iOS, com especificações, designs e testes. A melhor configuração resolveu 12% das tarefas. Outra análise de 254 submissões ao SWE-bench encontrou empates e diferenças pequenas demais para ordenar com confiança vários dos líderes. Cada benchmark mede capacidades diferentes; nenhum prevê sozinho o desempenho no legado da sua empresa.
Essa variação é chamada de jagged technological frontier: a IA pode ajudar muito em algumas tarefas e prejudicar o resultado em outras que parecem igualmente difíceis. Em um experimento com 758 consultores da BCG, participantes com IA foram 19 pontos percentuais menos propensos a acertar uma tarefa deliberadamente posicionada fora da fronteira de capacidade do GPT-4. O estudo avaliou trabalho de consultoria, não programação; ele sustenta a necessidade de identificar limites por tarefa, não uma conclusão sobre coding agents. Fonte: estudo publicado na Organization Science.
Os agentes proprietários também têm estratégias diferentes. Proprietário não significa necessariamente preso a um único modelo: algumas ferramentas integram modelos e agentes de outros fornecedores; outras se otimizam em torno do próprio ecossistema. Kiro, Antigravity, Windsurf, Amazon Q e JetBrains publicam controles empresariais, mas o estudo de PRs não os compara. Governança se avalia à parte. Resultado se mede em piloto, com as tarefas da empresa.
O Kiro serve de exemplo de política de modelo fechado. A governança empresarial não deixa a empresa trazer um modelo. Ela só permite tirar modelos da lista que o Kiro já oferece. Modelo novo não entra no dia do anúncio do fornecedor: entra quando o Kiro publica, e mesmo assim só chega aos desenvolvedores depois que o admin inclui na allow list. A documentação diz isso de forma direta: se a allow list está ligada, modelo novo fica invisível até alguém aprovar. A geografia publicada para inferência é Estados Unidos e Europa, não América do Sul. Fonte: proteção de dados do Kiro. Uma empresa no Brasil que padroniza o Kiro espera o catálogo e ainda opera fora do mapa de região. A concorrência num harness que chama o fornecedor direto usa o modelo atual enquanto esse time continua no anterior. O impacto não é o logo. É o calendário de evolução do produto.
Claude Code, Cursor, GitHub Copilot e Codex também oferecem controles empresariais. Claude Code separa configurações locais, de projeto e gerenciadas; Cursor documenta controles de modelos, MCP e execução; Copilot distingue políticas para agentes parceiros e configurações locais; Codex usa AGENTS.md. Em cada caso, confira a cobertura no IDE, terminal, ambiente remoto e CI.
Os estudos de produtividade também dependem do contexto. Um percentual isolado pode parecer convincente no slide e ainda dizer pouco sobre outra tarefa. Veja o que cada pesquisa mediu:
| Estudo | Resultado observado | O que ele permite concluir |
|---|---|---|
| GitHub Copilot/Microsoft Research, 2023 | Participantes com Copilot concluíram 55,8% mais rápido uma tarefa delimitada: implementar um servidor HTTP em JavaScript. | Ganho naquela tarefa e naquele experimento; não estima o ciclo completo de entrega de uma squad. |
| Google, experimento com 96 engenheiros, 2024 | Melhor estimativa de 21% menos tempo numa tarefa complexa, com intervalo de confiança amplo. | Sinal favorável em ambiente empresarial; os autores alertam para os limites de generalização. |
| METR, estudo com 16 mantenedores de OSS, 2025 | Em 246 tarefas de projetos que conheciam bem, o uso das ferramentas da época aumentou o tempo em 19%. | Agentes podem acrescentar custo de coordenação e revisão em alguns contextos. A atualização de 2026 diz que os novos dados ainda não permitem estimar com confiança o efeito das ferramentas atuais. |
O DORA 2025 encontrou associação entre adoção de IA, throughput e desempenho de produto, mas também uma associação negativa com estabilidade. Como pesquisa observacional com quase cinco mil profissionais, não prova causalidade. A pergunta para a empresa é: o tempo economizado ao produzir código aparece também após revisão, merge e implantação? Fonte: DORA 2025.
Placares com tarefa publicada, como SWE-bench, Terminal-Bench, Aider e LiveCodeBench, servem para escolher candidatos. A adoção sai dos evals internos, nas tarefas da empresa.
4. A estratégia recomendada: portfólio pequeno, política comum
Eu adotaria quatro decisões, nesta ordem:
- Defina a política da empresa antes de escolher o fornecedor. Classifique dados e tarefas, defina quais ferramentas podem acessar cada repositório e sistema, e quais ações exigem revisão humana.
- Escolha um harness padrão por fluxo de trabalho, por exemplo, agente de IDE para edição interativa e agente de terminal para tarefas longas ou automatizadas. Harness é o conjunto de modelo, ferramentas, permissões, contexto e loop de execução; comparar apenas o nome do modelo não basta.
- Homologue uma alternativa real, com paridade mínima de contexto, autenticação, ferramentas e métricas. Não precisa liberar todas as opções para todos: mantenha uma lista curta e retire uma opção quando ela deixar de cumprir os requisitos.
- Roteie modelos dentro desse perímetro e revise a decisão com dados de custo por tarefa concluída, qualidade após merge, latência e esforço de revisão.
O motivo é prático: benchmark público não prevê o seu código, fornecedor nenhum vence todas as tarefas, e adotar um único produto como fronteira de política cria dependência. No outro extremo, liberar cada ferramenta sem identidade, contexto e telemetria multiplica as brechas. Portfólio pequeno equilibra especialização e governança sem exigir que cada dev use tudo.
| Decisão | Recomendação | Por quê |
|---|---|---|
| Um único fornecedor para toda a empresa | Não como arquitetura exclusiva. Pode haver um padrão inicial. | Troca de modelo, preço ou política não deveria obrigar a reconstruir contexto e controles. |
| Todo mundo escolhe qualquer agente | Não. Comece com uma lista homologada. | Permissões, retenção, auditoria e políticas variam entre produtos e superfícies. |
| Mesmo harness para todo trabalho | Não por padrão. Separe por fluxo e risco. | IDE, terminal, cloud agent e CI têm autonomia e fronteiras diferentes. |
| Padrão com saída testada | Sim. Um principal e ao menos uma alternativa elegível por fluxo crítico. | Mantém experiência comum e comprova que a portabilidade funciona na prática. |
5. Como rotear modelos e decidir o que fica de fora
Roteamento não é mandar automaticamente cada prompt ao modelo mais barato. É escolher entre opções aprovadas, conforme classe de tarefa, risco e resultado dos evals. Um ponto de partida para um piloto:
| Tipo de trabalho | Rota inicial | Condição para manter essa rota |
|---|---|---|
| Explicar código, escrever teste localizado ou atualizar documentação | Modelo de menor custo que passe os evals; automação determinística quando resolver melhor. | Qualidade aceita sem aumentar revisão ou retrabalho. |
| Implementar feature isolada ou corrigir bug bem delimitado | Modelo padrão de coding no harness aprovado. | CI, revisão e tempo total iguais ou melhores que a linha de base. |
| Refatorar entre serviços, investigar falha ambígua ou planejar mudança arquitetural | Modelo de maior capacidade, com contexto selecionado e plano revisável. | Melhora a taxa de conclusão e não amplia acesso além do necessário. |
| Alterar produção, identidade, pagamentos ou dados regulados | Agente sem autonomia de execução; aprovação humana e controles determinísticos. | A rota não recebe credenciais ou ação irreversível sem um gate apropriado. |
Os preços publicados ajudam a formular hipóteses de custo, mas não determinam o custo da entrega. Por exemplo, em 29 de setembro de 2026, a API lista Claude Sonnet 5 a US$ 2/US$ 10 e Gemini 3.8 Flash a US$ 0,75/US$ 3,75 por milhão de tokens de entrada/saída, com preço introdutório do Gemini válido até o fim de 2026. Isso não compara qualidade, custo de assinatura do harness, cache, tokens de raciocínio ou chamadas de ferramenta. Meça custo por tarefa aceita e entregue; preço por token é só uma parcela.
Aplicaria a mesma regra ao catálogo de agentes:
| Decisão de portfólio | Exemplos e critério |
|---|---|
| Manter como candidato | Cursor, Claude Code, Codex, GitHub Copilot, Kiro, Antigravity, Windsurf, Amazon Q e JetBrains podem entrar no piloto se atenderem às políticas da empresa. Entrar na lista não é ranking de qualidade. |
| Manter como padrão | Somente o produto que passar pelo piloto do fluxo: mesmas tarefas, contexto e permissões; registrar custo, sucesso, defeitos e tempo humano. |
| Deixar fora do uso corporativo | Ferramenta que não permita cumprir identidade, dados, auditoria ou restrições de ferramentas exigidas naquele ambiente. Isso é decisão por configuração e plano, não condenação permanente da marca. |
| Não adotar como plano empresarial | “O modelo campeão do mês” como estratégia, ou um gateway que só vê tokens e presume controlar comandos locais, MCP, repositório e produção. |
Um modelo pequeno pode atender tarefas repetitivas; tarefas ambíguas recebem mais capacidade; operações de alto impacto permanecem limitadas por permissões e aprovação. A rota só muda quando os evals internos mostram que mudou o equilíbrio entre qualidade, custo e risco.
6. O control plane e os sensores que tornam a estratégia verificável
Uso control plane para nomear a arquitetura proposta que coordena políticas, contexto, ferramentas, custos e evidências entre agentes. Os produtos de mercado cobrem superfícies diferentes: um gateway vê requisições e consumo, mas chamadas MCP, comandos locais e violações arquiteturais exigem sensores em outros pontos do fluxo.
Cursor · Claude Code · Codex · Copilot
│
▼
Contratos e adaptadores por harness
identidade · permissões · MCPs aprovados
contexto versionado · orçamento e telemetria
│
▼
Repositório · ambiente de execução · PR/CI
│
▼
Entrega · incidentes · custo por resultado
As responsabilidades ficam distribuídas: o fornecedor controla o loop do harness; a empresa, os acessos e as regras do produto; o repositório, o comportamento esperado. CI e operação verificam o resultado. O GitHub, por exemplo, documenta políticas e auditoria para seus agentes, mas agentes locais no VS Code têm configuração própria. Fonte: GitHub AI Controls.
No kit pessoal de skills que mantenho fora da empresa, centralizar regras compartilháveis e variantes por harness reduziu duplicação. Isso não é o ambiente de produção. Numa empresa, também é preciso governar identidade, orçamento, acesso a sistemas e entrega por squad. Um repositório de instruções não resolve isso sozinho.
Em Harness Engineering for Coding Agent Users, Birgitta Böckeler distingue guia, que orienta antes da ação, de sensor, que verifica o resultado. Ambos podem ser computacionais (política, linter) ou inferenciais (instrução, revisão semântica).
| Preocupação | Guia antes da mudança | Sensor depois da mudança | Eixo |
|---|---|---|---|
| Dependências entre módulos | Contrato de arquitetura versionado no repositório (inferencial). | Teste estrutural no PR/CI (computacional). | Architecture fitness |
| Comportamento da feature | Critérios de aceite e exemplos aprovados (inferencial). | Testes de comportamento (computacional) e revisão humana dos casos críticos (inferencial). | Behaviour |
| Código sustentável | Convenções e exemplos de implementação (inferencial). | Typecheck e lint (computacionais), com revisão semântica quando necessária (inferencial). | Maintainability |
| Acesso a ferramentas | Catálogo MCP e permissões aprovadas (computacionais). | Bloqueios verificáveis e eventos de auditoria (computacionais). | Behaviour |
O quadro é um modelo, não uma descrição das empresas citadas. Um prompt que diz “não acesse dados sensíveis” não substitui permissões do sistema; um teste verde também não corrige uma regra de negócio mal especificada.
7. Como medir valor para a empresa
O piloto pode revelar problemas de integração. Para ampliar o uso, a empresa precisa responder: o ganho no fluxo de entrega compensa o custo e o risco nos produtos afetados? Compare cada produto e tipo de mudança com uma linha de base sem agente, acompanhando o resultado após merge e implantação.
Três números para o piloto. O resto entra quando esses três já mostrarem sinal:
Tempo até produção, por tipo de tarefa
Defeito ou rollback depois do merge
Custo por tarefa aceita
Recorte o painel por produto, risco e tipo de tarefa. Somar PRs ou dividir tokens pelo número de desenvolvedores esconde diferenças de legado, CI e complexidade. A economia de uma equipe também pode desaparecer se revisão, suporte ou incidentes crescerem em outra. Meça o fluxo completo e as metas de produto; atribuir o resultado aos agentes exige mais que correlação no dashboard.
O iFood mostra o gargalo de revisão. A JetBrains mostra a pressão de custo. O Kiro mostra o calendário de um catálogo fechado. A decisão continua a da abertura.
Na sua empresa, qual regra dos agentes ainda vive só num prompt — e como vocês descobrem que ela falhou antes de chegar à produção?
Top comments (0)