Um agente de programação não responde uma única vez: ele planeja, gera código, executa testes e repete o ciclo para corrigir erros. É exatamente esse comportamento que o torna útil, mas também o que encarece a operação.
Segundo o MIT Technology Review, em material publicado em 2 de novembro de 2026 com patrocínio da HPE, uma única tarefa delegada a um agente pode consumir de 10 a 50 vezes mais tokens do que um prompt básico de chat. Quanto mais útil o agente fica, mais chamadas ele faz — e, com cobrança por token, os fluxos que mais geram valor são justamente os que mais pesam na fatura.
A pressão financeira já deixou de ser hipótese. A Uber teria esgotado todo o orçamento de IA previsto para 2026 ainda em abril, depois de ampliar o uso do Claude Code. O GitHub Copilot abandonou o preço fixo e passou a cobrar créditos medidos.
E o Gartner projeta que os custos de tokens em programação assistida por IA vão superar o salário médio de um desenvolvedor até 2028.
O erro de medir consumo em vez de resultado
A reação instintiva das empresas é racionar: cotas de uso, limites de assentos, aprovações obrigatórias antes de disparar um agente. O problema é que limites genéricos cortam também os fluxos que efetivamente entregam valor, e otimizam o número errado.
Custo por token mede consumo, não resultado. Parte do gasto é desperdício puro, como retentativas e loops descontrolados; outra parte é o trabalho de colocar software em produção.
Um medidor não distingue as duas coisas, e um teto de gastos também não.
Custo por pull request mergeado
A alternativa proposta é deslocar a métrica para o que efetivamente sai da esteira: dividir o custo total de desenvolvimento assistido por IA pelo número de mudanças que passam pela revisão e são mergeadas. Acompanhar retrabalho e defeitos ao lado dessa conta evita que mudanças mais baratas escondam queda de qualidade.
Se o custo por pull request cai à medida que o uso de IA cresce, sem comprometer a qualidade, a conclusão é que a empresa está convertendo mais consumo em software útil. A pergunta deixa de ser quantos tokens foram gastos e passa a ser quanto trabalho concluído o investimento produziu.
Rotear por complexidade, não por hábito
Melhorar essa equação exige duas mudanças. A primeira é reservar a inferência mais cara para as tarefas que realmente precisam dela.
Programação agêntica não demanda o modelo mais poderoso em todas as etapas: um modelo de fronteira, ou um flagship rodando on-premises, quando a política interna exige, faz o planejamento difícil e o raciocínio novo, enquanto geração de código, criação de testes e refatorações repetidas podem ir para modelos open-weight operados pela própria empresa. Um gateway distribui as requisições conforme complexidade da tarefa, sensibilidade dos dados, custo e latência, aplicando preço premium apenas na exceção, não no fluxo inteiro.
Modelos abertos tornam essa divisão cada vez mais viável. Benchmarks de engenharia de software mostram que os principais modelos open-weight se aproximam do desempenho de fronteira em algumas tarefas, o que não comprova equivalência em qualquer repositório ou fluxo.
Por isso, a recomendação é avaliar os candidatos contra o próprio código, os próprios testes e os próprios critérios de aceitação antes de liberá-los para trabalho de produção.
Quem é dono da capacidade
A segunda mudança é decidir quem detém a capacidade computacional. Na inferência alugada, cada chamada acrescenta um item à fatura.
Na capacidade própria, a maior parte do custo é comprometida antecipadamente, e cada chamada adicional fica proporcionalmente mais barata conforme o uso cresce. A propriedade não é gratuita: energia, operação, manutenção e depreciação entram na conta, e o número que importa é o custo totalmente carregado por pull request mergeado.
Há ainda um valor que não aparece em nenhuma nota fiscal: o controle sobre código sensível. Quando geração e testes rodam on-premises, o código proprietário não sai da empresa, e apenas prompts de planejamento aprovados e exceções governadas seguem para modelos externos, por meio de um gateway sob controle da organização.
Isso destrava justamente os repositórios sensíveis onde a segurança costuma travar a adoção, e onde estão os maiores ganhos.
O teste da hpe e o que ele ensina
A HPE relata ter roteado cargas rotineiras de mais de 150 aplicações internas para modelos open-weight rodando on-premises, incluindo na HPE Private Cloud AI, com queda de 30% a 50% nos custos de token. Os dados também mostram que o gasto é puxado pelo uso, não pelo número de licenças: os 5% de usuários mais ativos concentraram a maior parte do consumo, e o usuário mais pesado consumiu cerca de 450 vezes mais que o mais leve sob a mesma licença.
Se os power users passarem de uma minoria pequena para metade do quadro, o gasto mensal pode subir cerca de 4,4 vezes sem qualquer contratação nova. O mix varia de empresa para empresa, o que reforça a necessidade de medir.
A recomendação é acompanhar duas métricas: custo por desenvolvedor ativo, porque a média sobre todas as licenças esconde quem realmente puxa o gasto, e custo por pull request mergeado, porque conecta o dispêndio com IA a software que chega à produção. O passo seguinte é estabelecer a linha de base das duas antes de mexer na infraestrutura e rodar um ciclo completo de desenvolvimento em capacidade própria.
Se ambas não melhorarem com o aumento do uso, o modelo atual pode continuar sendo a melhor escolha. Capacidade própria não serve para todo mundo: uso baixo ou imprevisível favorece APIs, sem capital parado em infraestrutura ociosa.
A maioria das empresas tende ao híbrido, APIs de fronteira para o trabalho exigente e intermitente, capacidade própria para o volume repetível, com um gateway governado decidindo o que pode sair do prédio.
Por que isso importa
A discussão desloca o debate de IA corporativa de uma lógica de racionamento para uma lógica de engenharia de custos. Enquanto o preço por token dominar as decisões, áreas de tecnologia correm o risco de cortar exatamente os fluxos mais produtivos para cumprir tetos orçamentários definidos no escuro.
Medir entrega, pull requests mergeados, com qualidade acompanhada de perto, dá aos gestores uma base concreta para comparar modelos, arquiteturas e fornecedores, e para justificar investimento em capacidade própria quando o volume sustentado compensar.
