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. Horas-homem: razoável na teoria, injusto na prática porque penaliza quem trabalha melhor. Story points: úteis para o planejamento interno de equipes, mas difíceis de traduzir em preço para um cliente. Preço fixo por funcionalidade: confortável para o cliente, arriscado para quem desenvolve.
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.
Mas além da definição técnica, o que importa é o que os tokens representam na prática:
- O contexto que o problema exige — quanto você precisa explicar para a IA entender o que resolver
- A profundidade do raciocínio — problemas complexos geram respostas mais extensas e exigem mais iterações
- O número de ajustes — cada refinamento, correção ou volta atrás soma tokens
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.
Este modelo não substitui a experiência — a complementa. Um desenvolvedor sênior navega no Nível 3 com menos tokens porque sabe fazer as perguntas certas desde o início.
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
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. O consumo pode ser sintoma de ineficiência tanto quanto de complexidade.
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?
- Você está registrando seu consumo de tokens hoje, ou deixando passar dados que poderiam informar melhores decisões amanhã?
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. É um ponto de partida para construir o histórico que você não tem hoje — e que daqui a um ano pode ser a diferença entre cotar com confiança ou continuar chutando.