Agente de codificação de IA pode gastar 50 vezes mais tokens que um prompt simples

Um agente que corrige os próprios erros gasta muito mais do que parece

Quando um desenvolvedor pede a um agente de IA para resolver uma tarefa de código, o agente não responde uma vez e para. Ele planeja, gera código, roda testes e repete o ciclo até corrigir os próprios erros. Segundo reportagem publicada pela MIT Technology Review em 2 de novembro de 2026, essa tarefa única pode consumir de 10 a 50 vezes mais tokens (as unidades de texto que os modelos de linguagem processam e que definem o preço cobrado pela API) do que um prompt simples de chat.

Isso cria um paradoxo incômodo: quanto mais útil o agente fica, mais chamadas ele faz ao modelo, e mais caro ele sai. Em contratos cobrados por token, os fluxos de trabalho que geram mais valor são justamente os que mais pesam na fatura.

Vale um aviso de transparência: o material usado nesta reportagem é um conteúdo patrocinado, produzido pela fabricante de infraestrutura HPE e publicado como anúncio dentro do site da MIT Technology Review, não escrito pela equipe editorial do veículo. Os números internos da HPE citados mais adiante são autodeclarados pela empresa, que vende justamente o tipo de infraestrutura que recomenda.

As contas já estouraram em empresas reais

O texto cita três sinais de que esse custo já afeta operações reais:

• A Uber teria esgotado todo o orçamento de IA previsto para 2026 já em abril, depois de ampliar o uso do Claude Code, agente de codificação da Anthropic.
• O GitHub Copilot deixou de cobrar uma assinatura de valor fixo e passou a usar créditos medidos por consumo.
• A consultoria Gartner prevê que o custo em tokens de codificação com IA vai superar o salário médio de um desenvolvedor até 2028.

A reação mais comum a esse tipo de pressão é a mais óbvia: limitar o uso, criar cotas por assento, exigir aprovação antes de rodar um agente. O problema, segundo o artigo, é que esse racionamento trava justamente os fluxos que geram valor, porque custo por token mede consumo, não resultado. Uma chamada cara pode ser desperdício (um loop que trava repetindo a mesma tentativa) ou pode ser o trabalho de verdade que entrega o software. Um medidor de tokens não distingue as duas coisas, e um teto de gastos também não.

A métrica proposta: custo por pull request que vai ao ar

Em vez de token consumido, a reportagem propõe medir o custo total de desenvolvimento assistido por IA dividido pelo número de mudanças que passam na revisão e são de fato mescladas no repositório (o chamado merged pull request). Junto com isso, recomenda acompanhar retrabalho e taxa de defeitos, para que uma mudança mais barata não esconda uma mudança de qualidade pior.

Se esse custo cai à medida que o uso de IA sobe, sem perda de qualidade, a equipe está convertendo consumo em software útil. A pergunta deixa de ser quantos tokens o time gastou e passa a ser quanto trabalho concluído esse investimento produziu.

Como dividir o trabalho entre modelo caro e modelo barato

O artigo argumenta que codificação com agentes não exige o modelo mais potente em toda etapa. A recomendação é reservar um modelo de ponta (ou uma versão instalada localmente quando a política da empresa exigir) para planejamento difícil e raciocínio inédito, e direcionar trabalho repetitivo, como geração de código, criação de testes e refatoração recorrente, para modelos de peso aberto operados pela própria empresa.

Um gateway (uma camada de roteamento entre a aplicação e os modelos) decide para onde vai cada pedido, segundo a complexidade da tarefa, a sensibilidade dos dados, o custo e a latência exigida. A ideia é cobrar caro só na exceção, não no fluxo inteiro. Benchmarks de engenharia de software citados no texto mostram que modelos de peso aberto já chegam perto do desempenho de modelos de ponta em algumas tarefas, mas isso não garante equivalência em qualquer repositório: a recomendação explícita é testar os candidatos contra o próprio código, os próprios testes e os próprios critérios de aceitação antes de colocá-los em produção.

Infraestrutura própria muda a conta, mas não é de graça

O texto compara dois modelos de custo:

Segundo a HPE, uma plataforma híbrida interna da própria empresa roteia cargas de trabalho rotineiras de mais de 150 aplicações para modelos de peso aberto rodando em infraestrutura local (incluindo a linha HPE Private Cloud AI), e o resultado declarado foi uma redução de 30% a 50% no custo em tokens. Como já dito, esse número vem do próprio fornecedor que está vendendo a solução, e não foi auditado de forma independente na reportagem.

Quem usa mais dita a conta, não quem tem licença

Um dado chama atenção: segundo a HPE, os 5% de usuários que mais usam IA geram a maior parte do consumo, e o usuário mais intenso chegou a gastar cerca de 450 vezes mais do que o usuário mais leve na mesma licença. Se esses usuários pesados crescerem de uma minoria pequena para metade do time, o gasto mensal pode subir cerca de 4,4 vezes com o mesmo número de pessoas contratadas.

Por isso a recomendação prática do artigo é acompanhar dois números em paralelo: custo por desenvolvedor ativo (porque a média de todas as licenças esconde quem realmente consome) e custo por pull request mesclado (porque conecta gasto em IA a software que efetivamente foi entregue). A sugestão final é medir essas duas métricas antes de trocar qualquer infraestrutura, rodar um ciclo completo de desenvolvimento em capacidade própria e só migrar se os dois números melhorarem de fato.

O que isso muda para quem monta agentes no Brasil

Para um time brasileiro que paga APIs de modelo em dólar, o ponto central do artigo pesa duas vezes: o câmbio amplifica qualquer variação de consumo em token, e um pico de uso de uma equipe que adotou um agente de codificação pode virar surpresa no orçamento do mês sem que ninguém tenha mudado o plano contratado. A lógica de separar tarefa difícil (modelo de ponta via API) de tarefa repetitiva (modelo aberto rodando localmente) é a mesma independente de moeda, mas o efeito de evitar chamadas desnecessárias em dólar é proporcionalmente maior aqui do que em uma operação que fatura e paga em dólar.

Antes de considerar comprar GPU própria ou contratar um produto como o citado no texto, dá para aplicar a parte da reportagem que não depende de infraestrutura nova: medir, hoje, quanto cada pull request mesclado custou em chamadas de API, identificar quem no time é o usuário pesado e testar, no próprio pipeline, se um modelo de peso aberto resolve as tarefas repetitivas (geração de teste, refatoração simples) com qualidade equivalente antes de rotear esse trabalho para fora do modelo de ponta. Isso não exige comprar nada: só muda o que a equipe mede e para onde manda cada tipo de pedido.

Fonte: MIT Technology Review — IA