Agentes de código pressionam orçamento e reacendem disputa por capacidade própria

O avanço dos agentes de programação está mudando a economia da IA corporativa. Quando um agente recebe uma tarefa de código, ele não responde uma única vez: planeja, gera código, executa testes e repete o processo para corrigir erros. Segundo o material apurado, uma única tarefa pode consumir de 10 a 50 vezes mais tokens do que um prompt básico de chat. Quanto mais útil o agente se torna, mais chamadas ele faz — e, com preço por token, os fluxos que mais geram valor também podem se tornar os mais caros.

A pressão já aparece em sinais concretos. A Uber teria esgotado todo o seu orçamento de IA de 2026 já em abril, após ampliar o uso do Claude Code. O GitHub Copilot passou de preço fixo para créditos medidos. Já a Gartner prevê que os custos de tokens para programação com IA superem salários médios de desenvolvedores até 2028. São informações de naturezas distintas — um relato de mercado, uma mudança de cobrança e uma projeção —, mas todas apontam para a mesma direção: a conta da IA generativa está ficando variável, visível e difícil de conter.

A reação natural tem sido racionar. Limites de uso, cotas por assento e aprovações antes de disparar agentes tentam conter a fatura. O problema é que travas generalizadas podem restringir justamente os fluxos que entregam mais valor. Além disso, otimizam a métrica errada. O custo por token mede consumo, não resultado. Parte do gasto reflete desperdício, como novas tentativas e loops descontrolados; outra parte representa trabalho que faz software chegar ao fim. Um medidor não distingue as duas coisas, e um teto de gastos também não.

A métrica que troca consumo por entrega

A métrica que importa deixa de ser o token consumido e passa a ser o custo de cada mudança que chega ao código em produção.

Uma alternativa proposta no material é medir o custo por pull request mesclado: o custo total de desenvolvimento assistido por IA dividido pelo número de mudanças que passam por revisão e são mescladas. Acompanhar retrabalho e defeitos ao lado dessa métrica é parte do método, para que mudanças mais baratas não escondam queda de qualidade. Se esse custo cair à medida que o uso de IA sobe, sem comprometer a qualidade, a empresa está convertendo mais consumo em software útil. A questão deixa de ser quantos tokens foram usados e passa a ser quanto trabalho concluído o investimento produz.

Para melhorar essa equação, o material aponta duas mudanças. A primeira é reservar inferência cara para tarefas que realmente precisam dela. A segunda é reduzir o custo do trabalho rotineiro. Na prática, isso significa não usar o modelo mais poderoso em todas as etapas. Modelos de fronteira, ou modelos de ponta disponíveis on-premises quando a política exige, ficam para planejamento difícil e raciocínio novo. Geração de código, criação de testes e refatorações repetidas podem ser direcionadas a modelos de pesos abertos operados pela própria empresa. Um gateway pode rotear solicitações conforme complexidade, sensibilidade dos dados, custo e latência, reservando a inferência premium para as exceções.

Os modelos de pesos abertos tornam essa divisão mais prática, mas o próprio material faz uma ressalva importante: benchmarks de engenharia de software mostram que modelos abertos líderes podem se aproximar do desempenho de fronteira em algumas tarefas, o que não estabelece equivalência em todos os repositórios ou fluxos. Antes de atribuir trabalho de produção, a recomendação é avaliar os candidatos contra o próprio código, os testes e os critérios de aceitação da empresa.

Roteamento e capacidade própria

A segunda decisão é sobre quem controla a capacidade computacional. Com inferência alugada, cada chamada adiciona custo à fatura. Com capacidade própria, a maior parte do custo é comprometida antecipadamente, e cada chamada adicional fica mais barata à medida que o uso cresce. A economia, porém, não é gratuita: energia, operação, manutenção e depreciação precisam entrar na conta. O número que importa é o custo total por pull request mesclado, não apenas o preço aparente do token.

A capacidade própria também traz um benefício que não aparece na fatura: controle sobre código sensível. Quando geração e testes rodam on-premises, código proprietário permanece dentro da empresa. Apenas prompts de planejamento aprovados e exceções governadas seguem para modelos externos, por meio de um gateway controlado pela organização. Isso abre repositórios sensíveis nos quais a segurança costuma travar a adoção — e onde, segundo o material, estão os maiores ganhos.

A HPE relata que uma plataforma híbrida de IA roteia cargas rotineiras de mais de 150 aplicações internas para modelos de pesos abertos rodando on-premises, incluindo no HPE Private Cloud AI, com queda de 30% a 50% nos custos de tokens. Os números aparecem em conteúdo patrocinado pela HPE e produzido fora da redação da MIT Technology Review; são, portanto, indicadores divulgados pela fornecedora, não uma auditoria independente. A empresa também recomenda acompanhar custo por desenvolvedor ativo e custo por pull request mesclado, fazer a linha de base antes de mudar a infraestrutura e rodar um ciclo completo de desenvolvimento em capacidade própria. Se as duas métricas não melhorarem com o aumento do uso, o modelo atual pode continuar sendo a melhor escolha.

O limite da conta e o espaço para o híbrido

Os dados apresentados também mostram que o gasto é puxado pelo uso, não pelo número de licenças. Os 5% de usuários mais intensivos geraram a maior parte do consumo, e os mais pesados usaram cerca de 450 vezes mais que os mais leves na mesma licença. Se usuários intensivos passarem de uma minoria pequena para metade da força de trabalho, o gasto mensal pode subir cerca de 4,4 vezes com o mesmo número de funcionários. Médias calculadas sobre todas as licenças tendem a esconder esses usuários e a subestimar a pressão sobre o orçamento.

Capacidade própria não serve para todos. Uso baixo ou imprevisível favorece APIs, sem capital parado em infraestrutura ociosa. A propriedade compensa quando a demanda sustentada mantém a capacidade ocupada. Por isso, a expectativa do material não é uma escolha binária, mas um arranjo híbrido: APIs de fronteira para trabalho exigente ou intermitente e capacidade própria para volume repetível, com um gateway governado decidindo o que sai da empresa.

Para o mercado, o sinal é que a governança de IA se aproxima da governança de software e de infraestrutura. A pergunta deixa de ser apenas quanto a empresa gasta por token e passa a incluir quanto custa cada entrega, quem controla a capacidade e como o uso intensivo afeta a conta. O que permanece em aberto é a métrica de cada organização: sem linha de base, teste de ciclo completo e acompanhamento de qualidade, não há como saber se mais consumo está virando mais software entregue ou apenas uma fatura maior.