A indústria de software passa décadas medindo a coisa errada.
Não porque os desenvolvedores sejam improdutivos — mas porque as ferramentas de medição capturam atividade, não pensamento. Horas trabalhadas. Commits realizados. Histórias completadas. Tudo contável, tudo visível, e quase tudo irrelevante para entender quanto e quão bem um problema foi realmente resolvido.
A IA não chegou apenas para acelerar o desenvolvimento. Ela trouxe algo inesperado: um novo sinal. Cada sessão de trabalho com um modelo de linguagem deixa um rastro quantificável — o consumo de tokens — que pela primeira vez permite vislumbrar o esforço cognitivo real por trás de uma tarefa.
A pergunta que nenhuma metodologia responde bem
Se você desenvolve software de forma independente ou lidera uma equipe de consultoria, há uma pergunta que aparece em todo projeto e quase nunca tem uma resposta satisfatória:
Quanto devo cobrar por isso?
Não é uma pergunta de negócio. É uma pergunta técnica disfarçada de pergunta de negócio. Para respondê-la bem, você precisa estimar a complexidade real do problema — e é aí que tudo complica.
A indústria tentou de muitas formas. As horas-homem penalizam quem trabalha melhor: quem resolve algo em duas horas cobra a metade de quem leva quatro. Os story points servem para planejar internamente, mas são impossíveis de converter em preço para um cliente externo. O preço fixo por funcionalidade coloca toda a incerteza do lado de quem desenvolve — e quem desenvolve quase sempre subestima.
Todos compartilham o mesmo problema de fundo: são aproximações subjetivas de algo que ninguém conseguiu medir objetivamente — a complexidade real de um problema de software.
A IA está introduzindo algo que pode mudar isso.
Por que a complexidade é tão difícil de medir
Duas tarefas podem parecer semelhantes na superfície e ser radicalmente diferentes em profundidade.
"Adicionar um campo ao formulário de registro" parece simples. Mas se esse formulário está conectado a três sistemas legados, tem validações em quatro camadas e ninguém documentou as regras de negócio, a tarefa real não tem nada a ver com o que parece de fora.
As métricas tradicionais não capturam isso. As horas medem o tempo decorrido, não a dificuldade real. Os story points refletem uma estimativa grupal que depende de quem está na sala e quão bem conhece o sistema. A experiência ajuda, mas não escala — e não é transferível sistematicamente de um projeto para outro.
O que sempre faltou é um sinal que emerge do próprio trabalho, não da estimativa prévia.
Tokens: o que são e o que representam
Quando você trabalha com um modelo de inteligência artificial, seja para gerar código, revisar lógica, planejar arquitetura ou depurar erros, cada interação consome tokens. Em termos simples, um token equivale a uma fração de palavra: aproximadamente 1–2 tokens por palavra em português. Em outras palavras, o que os tokens revelam é quanto contexto um problema precisa para ser entendido, quantas iterações são necessárias antes de chegar a respostas de qualidade, quantos ajustes e correções se acumulam no caminho. Não é atividade, é esforço cognitivo real, visualizado de forma quantitativa.
Exemplo concreto: gerar o esquema inicial de um banco de dados pode consumir cerca de 2.000 tokens. Depurar um erro de concorrência em um sistema distribuído pode chegar a 50.000. Essa diferença não é arbitrária — reflete complexidade real.
O padrão que emerge: complexidade e consumo
Com histórico suficiente de trabalho com IA, emerge uma correlação que não é perfeita, mas é significativa:
| Nível | Tipo de tarefa | Tokens estimados | Exemplos |
|---|---|---|---|
| 1 – Operacional | Baixa incerteza | 500 – 2.000 | CRUD básico, scripts simples, ajustes de estilo |
| 2 – Funcional | Variabilidade média | 5.000 – 20.000 | Integrações de API, módulos com regras de negócio |
| 3 – Sistêmico | Alta incerteza | 20.000 – 100.000+ | Arquitetura, debugging complexo, refactoring profundo |
Não é uma regra fixa. Um prompt mal construído pode gastar 30.000 tokens em algo operacional. Mas com histórico próprio, essas faixas se ajustam e se tornam previsíveis.
Os três níveis em detalhe
Nível 1 – Operacional: Baixa incerteza. O problema está bem definido e a solução tem um caminho claro. A IA executa com pouca orientação adicional. Em termos de precificação, este nível é o mais fácil de cotar porque a variabilidade é pequena.
Nível 2 – Funcional: Variabilidade média. Há decisões de design envolvidas e o contexto do sistema é necessário. A IA propõe alternativas e o desenvolvedor orienta, descarta, ajusta. Aqui o consumo de tokens começa a refletir algo valioso: as iterações de decisão.
Nível 3 – Sistêmico: Alta incerteza. O problema está mal definido, envolve múltiplos sistemas ou tem dependências não documentadas. O desenvolvedor guia ativamente a exploração, e o trabalho se estende por múltiplas sessões. É o nível mais difícil de cotar com métodos tradicionais — e onde os tokens fornecem mais valor como sinal.
Um desenvolvedor sênior consome menos tokens em problemas de Nível 3 (desenvolvimento de código) porque tem mais experiência e provavelmente dispõe de mais técnicas para enquadrar o problema desde o início. Isso não invalida o modelo, o sinal continua válido, mas o histórico precisa ser seu, não de outra pessoa.
Dos tokens ao preço: como usar seu histórico
O valor real de medir o consumo de tokens não está em uma tarefa isolada — está no histórico acumulado.
Suponha que você passou três semanas registrando o consumo por tarefa concluída:
- Semana 1: 180.000 tokens para 8 tarefas → média ~22.500 por tarefa
- Semana 2: 210.000 tokens para 11 tarefas → média ~19.000 por tarefa
- Semana 3: 195.000 tokens para 10 tarefas → média ~19.500 por tarefa
Você tem uma capacidade produtiva mensurável: ~200.000 tokens semanais, ~20.000 por tarefa em média. Se chegar um projeto novo com 12 funcionalidades, você pode classificá-las por nível e projetar o consumo total esperado, contrastando com seu histórico.
Não é uma fórmula exata, mas é uma base quantificável que antes não existia. Mais importante: quando um projeto termina consumindo o dobro do estimado, você tem dados concretos para entender por quê — e para cotar melhor da próxima vez.
O modelo que muda: do tempo ao valor resolvido
Se a complexidade de solução de um problema pode ser medida de forma mais precisa, o modelo tradicional de precificação para esse trabalho muda completamente.
Modelo tradicional
Preço = horas × tarifa
Este modelo tem um problema fundamental: penaliza a eficiência. Quem resolve algo em 2 horas cobra menos do que quem leva 8, mesmo que o valor entregue seja idêntico.
Nova abordagem
Preço = complexidade × capacidade de resolução
A complexidade é determinada pelo problema. A capacidade de resolução vem do desenvolvedor — incluindo as ferramentas que usa e quão bem as usa. Um problema de Nível 3 tem um preço que reflete sua dificuldade real, independentemente de ser resolvido em 6 horas com IA bem utilizada ou em 6 dias sem ela.
Os tokens não implementam este modelo por si sós, mas fornecem as evidências que tornam a conversa de precificação mais sólida.
O que os tokens não resolvem
Nem todo consumo reflete valor. Um prompt mal formulado gera muitos tokens com pouco resultado. Se você está aprendendo a usar IA ou explorando território desconhecido, o consumo será alto mesmo que o resultado não justifique. O sinal tem ruído — e esse ruído leva tempo para ser calibrado.
A experiência continua sendo a variável mais importante. Um desenvolvedor sênior resolve problemas de Nível 3 com menos tokens do que um júnior, não porque o problema seja mais simples, mas porque sabe enquadrá-lo melhor desde o início.
Os modelos de IA evoluem rapidamente. O que hoje requer 30.000 tokens pode ser resolvido com 8.000 em seis meses. O histórico precisa ser atualizado conforme as ferramentas melhoram.
Não substitui a conversa com o cliente. No final, a precificação também é uma negociação. Os dados de tokens fornecem argumentos, não respostas automáticas.
Perguntas abertas para sua equipe
- Você está medindo a complexidade dos seus projetos antes de cotar, ou você cota e depois descobre a complexidade?
- Quanto da sua precificação atual é baseada em dados próprios versus intuição acumulada?
- O que acontecerá com o modelo de horas quando os clientes entenderem que a IA pode comprimir dias em horas?
- O preço de um projeto deve refletir o tempo investido ou o problema resolvido?
- Faz sentido, no seu contexto específico, começar a medir tokens agora — ou há outros sinais que já estão te dizendo o que você precisa saber?
Conclusão
"Quanto devo cobrar por isso?" continuará sendo uma pergunta difícil. A complexidade do software não desaparece só porque agora temos ferramentas melhores.
Mas pela primeira vez existe um sinal quantificável que emerge do próprio trabalho. O consumo de tokens deixa um rastro do esforço cognitivo real envolvido em resolver um problema.
Não é uma fórmula. É a informação que começa a se acumular desde a primeira tarefa que você registra — e que em um ano transforma o "quanto devo cobrar?" em uma pergunta que você pode responder com seus próprios dados.