Tokens são as unidades de dados processadas por modelos generativos, e o consumo delas define diretamente o custo das ferramentas de IA para desenvolvimento, sobretudo sob cobrança por consumo. O Gartner prevê que, até 2028, os custos de AI coding superarão o salário médio de um desenvolvedor, puxados pela alta no consumo de tokens de LLM e pela migração do licenciamento por assento para o licenciamento por consumo. O ponto que muda a conversa não é o número, é a causa: segundo o Gartner, a disciplina de tokens não emergirá apenas da escolha do desenvolvedor, porque desenvolvedores tendem a otimizar por velocidade e conveniência, não por eficiência de custo. Sem um modelo operacional de engenharia governado, os custos podem escalar mais rápido que os ganhos de produtividade que a ferramenta deveria entregar. A saída, portanto, não é usar menos IA. É governar três coisas: o contexto que se envia, o modelo que se escolhe e o rastro do que se gastou.

O custo que mudou de natureza sem ninguém avisar o orçamento

Durante décadas, software corporativo teve custo previsível: licença por usuário, renovação anual, orçamento que cabia numa planilha. Ferramentas de IA para desenvolvimento quebraram esse modelo. O Gartner aponta que a mudança de licenciamento por assento para cobrança por consumo, entre fornecedores de agentes de codificação, está introduzindo estruturas de custo altamente variáveis para cargas de trabalho de engenharia.

Some-se a isso um problema de visibilidade que o Gartner descreve sem meias palavras: muitos fornecedores carecem de transparência sobre como o consumo de tokens é calculado e cobrado, o que limita a capacidade das empresas de prever e controlar custos. Sem visibilidade clara do uso de tokens nas tarefas de desenvolvimento, as organizações correm risco de estouro de orçamento e perdem a capacidade de acompanhar a relação entre custo e valor entregue. Segundo o analista sênior Nitish Tyagi, a maioria das organizações ainda não tem maturidade nem framework para medir custo contra impacto de negócio, e líderes de engenharia estão cada vez mais preocupados porque o gasto fica difícil de justificar, com orçamentos se esgotando antes do previsto.

A tese deste guia: custo de IA em engenharia não é problema de consumo, é problema de arquitetura de governança. Pedir para o time “usar menos” falha porque coloca a decisão econômica no ponto onde ela compete com prazo e conveniência. O que funciona é tirar a decisão do impulso individual e colocá-la na arquitetura: contexto controlado por desenho, modelo escolhido por política, gasto medido por rotina. Governança de IA, aqui, não é documento de compliance. É o que impede a conta de crescer mais rápido que o valor.

Por que pedir disciplina ao desenvolvedor não resolve

A reação intuitiva de quem vê a fatura subir é conversar com o time. Fazer treinamento, pedir bom senso, criar uma cartilha de boas práticas. A abordagem falha por um motivo estrutural, e não por falta de comprometimento das pessoas.

O desenvolvedor está resolvendo um problema com prazo. Diante da escolha entre colar o arquivo inteiro no contexto e resolver em dois minutos, ou recortar cuidadosamente o trecho relevante e resolver em quinze, a pressão do dia empurra para a primeira opção. É exatamente o comportamento que o Gartner descreve ao afirmar que desenvolvedores tendem a otimizar por velocidade e conveniência em vez de eficiência de custo, e por isso a disciplina de tokens não surge da escolha individual. O custo é difuso e aparece na fatura do mês seguinte; o prazo é concreto e aparece na retrospectiva da semana.

A conclusão prática é incômoda para quem esperava resolver com comunicação interna: se a economia depende de cada pessoa decidir contra o próprio incentivo imediato, ela não vai acontecer de forma consistente. Precisa estar no sistema, não na boa vontade.

De onde vem o desperdício, segundo o Gartner

O release do Gartner nomeia os modos de falha que puxam o consumo para cima. Vale ler como diagnóstico, porque cada um tem um controle correspondente:

As três alavancas de governança que o Gartner recomenda

As recomendações do Gartner para líderes de engenharia se organizam em três alavancas. Nenhuma delas é sobre usar menos IA; todas são sobre usar com desenho.

Alavanca 1 · Contexto: pagar só pelo que a tarefa precisa

O Gartner recomenda tornar obrigatória a prática de context engineering, treinando desenvolvedores a otimizar o contexto de entrada: incluir apenas informação relevante, resumir quando possível e eliminar dados desnecessários, reduzindo o consumo de tokens sem comprometer a qualidade do resultado. Traduzido para arquitetura: o sistema deve entregar ao modelo o recorte da tarefa, e não o repositório inteiro, e isso é decisão de desenho da plataforma de engenharia, não de esforço individual repetido a cada prompt.

Alavanca 2 · Modelo: nem toda tarefa merece o modelo mais caro

A segunda recomendação é alinhar a seleção de modelo à complexidade da tarefa. O Gartner orienta quebrar o trabalho em tarefas menores, que possam ser resolvidas por modelos menores, escalando para modelos de fronteira apenas quando a complexidade exigir, com estratégias de roteamento inteligente que direcionem o que é simples e frequente para modelos menores e reservem os mais caros para trabalho complexo e de alto valor. O Gartner também sugere um framework de decisão por caso de uso, classificando as tarefas em três modos de execução: conduzidas pelo desenvolvedor, pelo desenvolvedor com agente, ou inteiramente pelo agente.

Alavanca 3 · Rastreabilidade: o que não é medido não é governado

A terceira alavanca são os controles: o Gartner recomenda introduzir limites de tokens, políticas de escalonamento e monitoramento automatizado, embutindo esses controles nos fluxos de engenharia para garantir consistência e evitar crescimento descontrolado do custo. E, de forma explícita, recomenda embutir revisões de uso de tokens nos ciclos de desenvolvimento, com revisões regulares dos fluxos de maior consumo como parte das retrospectivas de sprint, para identificar ineficiências, refinar práticas e disseminar conhecimento entre os times.

Onde a governança deixa de ser slide e vira rotina

A recomendação de levar a revisão de consumo para a retrospectiva de sprint é, na prática, a mais transformadora das três, e a mais fácil de subestimar. Ela move a governança de custo do território do comitê trimestral para o território da rotina de engenharia, que é onde o comportamento realmente muda.

Isso tem endereço concreto em empresa de porte: o sistema onde o trabalho de engenharia já é planejado, medido e revisado. Quando o consumo de IA vira um item da retrospectiva no Jira, quando a política de uso vira uma decisão registrada com dono e data, e quando o ajuste de um fluxo caro vira uma tarefa com prazo em vez de uma intenção de reunião, a governança ganha a única coisa que a torna real: acompanhamento. É o mesmo princípio que vale para qualquer programa de qualidade ou de dívida técnica. Trabalho que não entra na fila não acontece, por mais consenso que tenha gerado na apresentação.

•     Revisão de consumo como item recorrente. Os fluxos de maior gasto entram na retrospectiva com a mesma seriedade de um incidente, e a discussão gera ação registrada, não impressão compartilhada.

•     Política de uso versionada e rastreável. Quais modelos são permitidos, qual o teto por projeto, quando escalar para um modelo maior. Decisão com dono, histórico e data de revisão.

•     Ajuste de fluxo caro como tarefa, não como recomendação. O fluxo identificado como ineficiente vira item priorizado, com responsável e critério de conclusão.

Por que isso é trabalho de especialista em IA, e não de FinOps genérico: governar custo de IA exige entender simultaneamente o que faz o consumo subir (contexto, autonomia, escolha de modelo), como desenhar a plataforma para que o controle seja estrutural e não voluntário, e como transformar isso em rotina de engenharia acompanhada. São três competências distintas: arquitetura de IA, engenharia de plataforma e gestão do trabalho. A CSP Tech atua nas três, como especialistas em arquitetura de dados e IA e com consultoria Jira (Atlassian Gold Partner) na camada onde a governança vira rotina com dono, prazo e trilha.

Quando esse rigor ainda não se justifica

•     Uso experimental e de baixo volume. Se a empresa está avaliando ferramentas com poucos usuários e gasto marginal, montar governança formal custa mais que o problema que resolve. O momento de estruturar é antes de escalar, não antes de experimentar.

•     Licenciamento fixo por assento, sem componente de consumo. O risco descrito pelo Gartner nasce da cobrança variável por uso. Onde o contrato é de valor fixo, a urgência é menor, embora a tendência de mercado apontada seja de migração para consumo.

•     Antes de existir visibilidade mínima do gasto. Não dá para governar o que não se enxerga. Se hoje a empresa não sabe quanto gasta e em quê, o primeiro passo é medir, e só depois desenhar política e limite.

Perguntas frequentes

O que são tokens e por que eles definem o custo da IA?

Tokens são as unidades de dados processadas por modelos de IA generativa. Como boa parte das ferramentas de desenvolvimento assistido por IA cobra por consumo, a quantidade de tokens processada impacta diretamente a fatura. Segundo o Gartner, o aumento do consumo de tokens, somado à migração do licenciamento por assento para o licenciamento por consumo, é o que sustenta a previsão de que os custos de AI coding superarão o salário médio de um desenvolvedor até 2028.

Por que o custo da IA em desenvolvimento é difícil de prever?

Por dois motivos que o Gartner aponta. Primeiro, a cobrança por consumo cria estruturas de custo altamente variáveis, diferentes da previsibilidade do modelo por assento. Segundo, muitos fornecedores não são transparentes sobre como o consumo de tokens é calculado e cobrado, o que limita a capacidade de prever e controlar. Sem visibilidade do uso por tarefa, cresce o risco de estouro de orçamento e a dificuldade de relacionar custo e valor.

O que é governança de IA aplicada a custo de engenharia?

É o conjunto de decisões estruturais que tira a economia de tokens do voluntarismo individual: definir o nível de autonomia adequado a cada tipo de tarefa, direcionar tarefas simples a modelos menores e reservar modelos de fronteira para o trabalho complexo, controlar o contexto enviado, e estabelecer limites, políticas de escalonamento e monitoramento embutidos no fluxo de engenharia. São as linhas de ação que o Gartner recomenda a líderes de engenharia de software.

Como transformar governança de IA em prática, e não em documento?

Levando-a para a rotina onde o trabalho já é acompanhado. O Gartner recomenda embutir revisões de consumo de tokens nos ciclos de desenvolvimento, com revisão regular dos fluxos de maior gasto nas retrospectivas de sprint. Na prática, isso significa que a política de uso, a revisão de consumo e o ajuste dos fluxos caros passam a ter dono, prazo e histórico no mesmo sistema em que o time planeja e revisa entregas.

Próximo passo

Se a sua empresa passou da experimentação para o uso em escala e ninguém sabe responder quanto custou a última funcionalidade entregue com IA, o problema não é a ferramenta nem o time. É a ausência de um modelo operacional que torne o controle estrutural. Solicite um diagnóstico de governança de IA em engenharia com a CSP Tech e receba o mapa das três alavancas no seu ambiente: como o contexto é montado hoje, como os modelos são escolhidos e onde a revisão de consumo precisa entrar para virar rotina.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas de engenharia e Atlassian da CSP Tech (Atlassian Gold Partner, Microsoft Gold Partner, parceira Databricks, participante do Anthropic Partner Network, 34 anos de mercado).

Fonte principal (oficial, acesso ago/2026): Gartner, press release “Gartner Predicts AI Coding Costs Will Surpass Average Developer's Salary by 2028 as Token Consumption Surges” (gartner.com/en/newsroom, Stamford, 24/jun/2026), incluindo as declarações do analista sênior Nitish Tyagi e as cinco recomendações a líderes de engenharia de software citadas neste artigo. Todas as afirmações atribuídas ao Gartner neste texto são previsões, tendências ou recomendações do referido release, com o horizonte temporal original preservado.