Tokenomics: quantificando onde os tokens são usados na engenharia de software com agentes

• Estudo que mapeia rastros de execução de sistemas de desenvolvimento de software multiagente baseados em LLM para etapas do SDLC, medindo uma estrutura em que o consumo de tokens se concentra em revisão de código e validação, e não na geração inicial
• Em 30 tarefas de desenvolvimento de software executadas pelo ChatDev, a etapa de revisão de código consumiu em média 59,4% dos tokens, sendo o maior ponto de consumo
• A composição média de tokens no conjunto total de tarefas foi de 53,9% de entrada, 24,4% de saída e 21,6% de raciocínio, mostrando que a transferência repetitiva de contexto entre agentes forma um grande communication tax
• Enquanto a etapa de codificação teve alta proporção de tokens de saída, com 58,0%, a etapa de documentação teve alta proporção de tokens de entrada, com 80,2%, distinguindo claramente os padrões de uso de tokens por fase de desenvolvimento
• A conclusão é que são necessários protocolos de colaboração entre agentes mais eficientes em tokens e um framework de avaliação padronizado para previsão de custos e otimização de workflow

---

Resumo

• Sistemas multiagente baseados em LLM (LLM-MA) estão sendo cada vez mais aplicados para automatizar tarefas complexas de engenharia de software, como engenharia de requisitos, geração de código e testes
• Como a eficiência operacional e o consumo de recursos ainda não são bem compreendidos, custos imprevisíveis e impacto ambiental tornam-se fatores que dificultam a adoção prática
• O estudo analisa rastros de execução de 30 tarefas de desenvolvimento de software realizadas pelo framework ChatDev com o GPT-5 reasoning model, mapeando as etapas internas para design, codificação, conclusão de código, revisão de código, testes e documentação
• Os resultados preliminares mostram que a etapa iterativa de revisão de código responde, em média, por 59,4% dos tokens, sendo a maior faixa de consumo
• Os tokens de entrada representam, em média, 53,9%, mantendo consistentemente a maior participação e fornecendo evidência empírica de ineficiências significativas na colaboração entre agentes
• O principal custo da engenharia de software com agentes não está na geração inicial de código, mas nos processos automatizados de refinamento e validação
• A metodologia pode ser usada para previsão de custos, otimização de workflow e pesquisa sobre protocolos de colaboração entre agentes mais eficientes em tokens

Introdução

• A engenharia de software em larga escala vem explorando sistemas multiagente baseados em LLM para automatizar tarefas complexas ao longo de todo o SDLC
• Frameworks LLM-MA simulam papéis de equipes humanas, como gerente de produto, arquiteto, desenvolvedor e tester, com agentes LLM especializados que executam de forma colaborativa tarefas de design, codificação e validação
• Em princípio, sistemas LLM-MA podem dividir o trabalho entre agentes para aumentar autonomia e robustez
• Estudos anteriores indicam que sistemas LLM-MA promovem pensamento divergente, reforçam raciocínio e factualidade e podem escalar para problemas além da capacidade de um único agente
• Na engenharia de software, existe o potencial de automatizar de ponta a ponta workflows que vão de requisitos até testes de forma integrada
• O framework AGENTTAXO fornece uma taxonomia para analisar a distribuição de tokens em sistemas LLM-MA gerais e introduz o conceito de “communication tax” para descrever o overhead de interação entre agentes
• A taxonomia de falhas MAST mostra que muitos problemas em sistemas LLM-MA vêm de questões de projeto e coordenação do sistema, como repetição de etapas e validação incompleta, e não apenas de limitações do LLM individual
• Pesquisas existentes analisaram o comportamento de agentes em contexto geral, mas ainda há uma lacuna de conhecimento sobre a eficiência de recursos de sistemas aplicados a workflows de engenharia de software em múltiplas etapas
• A pergunta central para adoção prática, “para onde vão os tokens”, ainda carece de resposta no domínio da engenharia de software
• Tokenomics é o termo usado para estudar a eficiência operacional e o consumo de recursos de sistemas LLM-MA
• A análise observa a distribuição do consumo de tokens ao mapear as etapas internas do ChatDev para fases de desenvolvimento
• O ChatDev simula uma empresa virtual de software, em que múltiplos papéis de agentes, como programadores e testers, completam o SDLC por meio de conversas de múltiplos turnos
• É fornecido um dataset curado com 30 rastros de execução e um pacote completo de reprodução

Desenho da pesquisa

• Objetivos e objeto de análise

  • O objetivo é investigar empiricamente como o consumo de tokens se distribui quando sistemas LLM-MA executam tarefas end-to-end de desenvolvimento de software
  • O objeto inicial de análise é o ChatDev
  • A arquitetura de “chat chain” do ChatDev representa um modelo sequencial em cascata claro, de design → codificação → testes, com etapas bem definidas, o que a torna adequada para mapeamento às fases de desenvolvimento de software
  • O ChatDev é um dos frameworks open source populares e amplamente citados

• Curadoria do dataset

  • O ChatDev foi executado em 30 tarefas diferentes de desenvolvimento de software
  • Os prompts foram coletados do ProgramDev Dataset usado no estudo MAST
  • Os prompts selecionados incluem desde algoritmos simples, como geração de números de Fibonacci, até aplicações mais complexas, como um jogo de xadrez
  • A diversidade foi verificada com base em pesquisas recentes segundo as quais a contagem de tokens de raciocínio pode servir como indicador substituto da complexidade da tarefa
  • O intervalo de consumo de tokens de raciocínio nas 30 tarefas vai de 17.280 a 40.000, sugerindo variedade suficiente de complexidade para o estudo

• Seleção do modelo

  • O modelo-base de todos os agentes é o GPT-5 reasoning model
  • Os critérios de escolha foram popularidade e atualidade do modelo, adequação a casos de uso com agentes e forte capacidade de raciocínio alinhada à expectativa de agentes autônomos
  • A versão do modelo usada no experimento foi gpt-5-2025-08-07
  • Como o parâmetro temperature não é suportado por esse modelo, foi usado o valor padrão 1.0
  • A janela de contexto é de 400.000 tokens e o máximo de tokens de saída é de 128.000
  • O cutoff de conhecimento é 30 de setembro de 2024

• Pipeline de análise

  • Na etapa de coleta de rastros, o ChatDev foi instrumentado para registrar em log o rastro completo de execução de cada uma das 30 tarefas
  • Foram capturados, em cada chamada ao LLM, o prompt, a resposta e as contagens de tokens de entrada, saída e raciocínio
  • O mapeamento de etapas é a metodologia central que converte as etapas internas do framework ChatDev em fases universais de desenvolvimento
  • Essa abstração permite uma análise generalizável e pode ser estendida a outros frameworks LLM-MA de engenharia de software
  • A agregação de tokens foi realizada com scripts em Python
  • Os rastros coletados foram parseados, e as contagens de tokens por fase de desenvolvimento foram somadas ao longo das 30 execuções
  • Houve detalhamento em tokens de entrada, saída e raciocínio

• Mapeamento entre etapas internas do ChatDev e fases de desenvolvimento

  • A fase de design corresponde a DemandAnalysis e LanguageChoose, com foco em compreensão de requisitos e decisões técnicas de alto nível
  • A fase de codificação corresponde a Coding e participa diretamente da escrita inicial do código-fonte
  • A fase de conclusão de código corresponde a CodeComplete e completa placeholders ou arquivos de código inacabados deixados pela etapa de codificação
  • A fase de revisão de código corresponde a CodeReview e realiza revisão, correção e melhoria por meio de conversas iterativas entre o agente programador e o agente revisor de código
  • A fase de testes corresponde a Test e se concentra em testes dinâmicos do sistema para encontrar e corrigir bugs de executabilidade
  • A fase de documentação corresponde a EnvironmentDoc, Reflection e Manual, gerando manual do usuário e documentação das dependências de ambiente necessárias

Resultados e discussão

• Pergunta de pesquisa

  • A pergunta central é qual é o padrão de consumo de tokens de sistemas LLM-MA em tarefas de desenvolvimento de software
  • Entender a tokenomics de sistemas de engenharia de software com agentes é importante para uma adoção prática e sustentável
  • Alto uso de tokens está diretamente ligado ao aumento de custos financeiros, consumo de energia e impacto ambiental
  • Identificar onde os tokens são consumidos dentro do SDLC permite criar um “mapa de custos” útil para previsão de custos e otimização de workflow
  • A análise foi conduzida em dois eixos
  • Distribuição do total de tokens por fase de desenvolvimento mapeada, como design e codificação
  • Proporção de tokens de entrada, saída e raciocínio dentro de cada fase

• Descoberta 1: a fase de revisão de código domina o consumo de tokens

  • O uso de tokens ao longo do processo de desenvolvimento é distribuído de forma muito desigual
  • A fase de revisão de código consome, em média, 59,4% dos tokens em todas as 30 tarefas, sendo o maior ponto de consumo
  • A fase de conclusão de código ocorreu em 6 das 30 tarefas e consumiu, nessas execuções, em média 26,8% dos tokens
  • A fase de documentação consumiu em média 20,1% e a fase de testes, 10,3%
  • A fase de testes ocorreu em 12 das 30 tarefas
  • A codificação inicial teve custo relativamente baixo, com média de 8,6%, e o design, 2,4%
  • O principal custo da engenharia de software com agentes se concentra no processo iterativo e conversacional de refinamento e validação, e não na geração inicial de código
  • O valor n nas figuras indica o número de tarefas, dentre as 30, em que uma determinada fase foi executada
  • Nem todas as fases são sempre executadas, e os agentes dentro do sistema multiagente decidem autonomamente quais fases executar
  • As barras de erro representam ±1 desvio padrão, mostrando a variabilidade do consumo de tokens em cada fase

• Descoberta 2: o consumo de tokens é centrado em tokens de entrada

  • Em todas as fases, exceto a de codificação, os tokens de entrada superam amplamente os tokens de saída e de raciocínio
  • A composição média total de uso de tokens por tarefa é de 53,9% de entrada, 24,4% de saída e 21,6% de raciocínio
  • A proporção aproximada de 2:1 entre tokens de entrada e de saída constitui forte evidência empírica do “communication tax” observado em estudos anteriores
  • Os agentes consomem tokens ao retransmitir repetidamente grandes contextos durante conversas colaborativas
  • Nos protocolos atuais de colaboração entre agentes, existe ineficiência: a maior parte dos tokens é gasta em transmitir contexto, e não em gerar novas saídas
  • O communication tax pode ser uma característica inerente de arquiteturas conversacionais multiagente e deve ser alvo de estudos futuros

• Descoberta 3: diferenças de perfil tokenômico por fase de desenvolvimento

  • As proporções de tokens por fase formam padrões próprios para cada atividade de engenharia de software
  • A fase de codificação é uma exceção orientada à saída, com 58,0% de saída e 6,9% de entrada
  • Essa estrutura orientada à saída na fase de codificação é compatível com a natureza da tarefa de gerar código-fonte longo a partir de especificações de design concisas
  • Fases de validação e documentação, como revisão de código e documentação, são centradas em entrada
  • A revisão de código teve 51,4% de entrada
  • A documentação teve 80,2% de entrada
  • Essas fases consomem código existente como grande contexto e produzem saídas analíticas menores
  • Os perfis de tokens por fase podem ser usados como mapa de custos por atividade de engenharia
  • Profissionais podem identificar melhor oportunidades de previsão de custos e otimização de processo

• Proporções de tokens por fase

  • A fase de design teve proporção média de 60,4% de entrada, 3,6% de saída e 36,0% de raciocínio
  • A fase de codificação teve proporção média de 6,9% de entrada, 58,0% de saída e 35,1% de raciocínio
  • A fase de conclusão de código teve proporção média de 47,7% de entrada, 41,7% de saída e 10,5% de raciocínio
  • A fase de revisão de código teve proporção média de 51,4% de entrada, 24,7% de saída e 23,9% de raciocínio
  • A fase de testes teve proporção média de 60,8% de entrada, 20,7% de saída e 18,4% de raciocínio
  • A fase de documentação teve proporção média de 80,2% de entrada, 8,3% de saída e 11,5% de raciocínio
  • A proporção média total por tarefa foi de 53,9% de entrada, 24,4% de saída e 21,6% de raciocínio

• Discussão

  • Os resultados preliminares fornecem um mapa inicial de custos do desenvolvimento de software com agentes
  • O grande custo de tokens na fase de revisão de código pode ser interpretado como “custo de conversa”
  • Esse custo surge diretamente da arquitetura conversacional dos sistemas LLM-MA, em que agentes trocam repetidamente o contexto completo do código para refiná-lo
  • Protocolos atuais de colaboração entre agentes para validação podem ser muito ineficientes, consumindo recursos enormes mesmo em tarefas que exigem pequenas correções
  • Isso também se alinha aos resultados da taxonomia MAST relacionados a falhas de validação e repetição de etapas
  • O alto uso de tokens pode ser um sintoma de sistemas de agentes tentando superar problemas intrínsecos de coordenação por meio de conversa forçada
  • Na prática, é possível estimar o custo de projetos baseados em agentes de acordo com o tipo de trabalho necessário
  • Projetos greenfield com maior peso de codificação inicial e projetos focados em refatoração e debugging de código existente têm estruturas de custo diferentes
  • Em projetos focados em refatoração e debugging de código existente, ciclos caros e centrados em entrada de revisão de código tendem a dominar os custos
  • Integrar checkpoints de “human-in-the-loop” antes da fase de revisão de código pode evitar loops iterativos caros e servir como decisão de projeto para aumentar a eficiência econômica e computacional
  • Um desafio de pesquisa é projetar protocolos de colaboração mais eficientes em tokens para validação e refinamento
  • É necessário ir além da simples transmissão do contexto completo
  • Também é necessário um framework de avaliação padronizado e abrangente
  • Esse framework pode servir como base comum para benchmark e comparação da eficiência de arquiteturas LLM-MA distintas, como o workflow conversacional hierárquico do ChatDev e a linha de montagem baseada em SOP do MetaGPT
  • Ele também pode funcionar como uma “Rosetta Stone” para traduzir o comportamento de cada framework em atividades universais de engenharia de software

Ameaças à validade e trabalhos futuros

• Ameaças à validade

  • A análise se baseia em um único sistema LLM-MA, o ChatDev, e em um único LLM, o GPT-5 Reasoning Model
  • Os padrões observados de consumo de tokens podem variar em outras arquiteturas LLM-MA ou em LLMs com eficiências de tokens diferentes
  • As 30 tarefas de desenvolvimento de software são variadas, mas podem não representar todos os cenários e níveis de complexidade possíveis
  • O tamanho do dataset curado decorre diretamente da falta de benchmarks públicos em larga escala com rastros de agentes especializados em engenharia de software
  • A curadoria dos dados é um processo caro e demorado
  • Algumas fases de desenvolvimento foram executadas apenas em um pequeno subconjunto das 30 tarefas
  • Conclusão de código teve n=6 e testes tiveram n=12, sendo acionados raramente
  • Como as conclusões sobre o perfil tokenômico dessas fases específicas se baseiam em amostras pequenas, elas podem ter baixa representatividade e generalização limitada
  • O mapeamento das etapas internas do ChatDev para fases de desenvolvimento de software é uma abstração
  • Embora seja um mapeamento lógico e útil para construir um framework de avaliação padronizado, ele é apenas uma entre várias maneiras possíveis de mapear atividades de agentes

• Conclusão e trabalhos futuros

  • Na engenharia de software com agentes, os custos de tokens não se distribuem de forma uniforme e se concentram esmagadoramente na fase iterativa e conversacional de revisão de código
  • Os tokens de entrada que compõem o “communication tax” representam a maior parte do uso total de tokens e são uma área-chave para otimização futura
  • O primeiro desafio de trabalhos futuros é expandir o dataset com mais tarefas para melhorar a generalização
  • O segundo é ampliar a análise para outros LLMs a fim de entender efeitos específicos de modelo
  • O terceiro é ampliar a análise para outros sistemas LLM-MA para comparar como diferenças de arquitetura afetam a tokenomics
  • O quarto é investigar a relação entre padrões de consumo de tokens e modos de falha
  • O quinto é desenvolver e validar ainda mais um framework robusto e universal de mapeamento de fases de desenvolvimento para benchmark da eficiência de agentes de engenharia de software

[GN⁺]

Comentários do Hacker News

• Uso um sistema multiagente para fins pessoais
  Quando dou um problema, primeiro um modelo rápido e barato faz perguntas e, com base nas respostas, refina o prompt de entrada
  Depois divide o problema em seções e escolhe uma estratégia em que um árbitro final tira a conclusão, ou vários agentes debatem e então o árbitro resume tudo
  O melhor método é o que eu chamo de all angles, em que várias estratégias rodam em paralelo e um metaárbitro final sintetiza as respostas
  A parte mais útil que adicionei recentemente é uma tela para ver a divergência entre as estratégias
  Uso isso para questões do dia a dia, como busca de moradia, escola e problemas familiares

  • Tem um vídeo de demonstração do que fiz aqui: https://streamable.com/e49cgt
  • Você mencionou custo, então queria saber se poderia explicar melhor a estrutura aproximada de custos por tipo de problema
    Também queria entender quais estratégias você usa e como o custo muda entre elas
  • Queria saber que harness de execução você usa e quais LLMs utiliza
  • Também montei um sistema parecido, mas foquei mais em loops de feedback do que em melhoria exploratória de prompts
    Num estilo de cibernética, vou expandindo continuamente uma biblioteca de verificações determinísticas e correções automáticas para manter a estabilidade da saída dos prompts
    Os “problemas” que essa biblioteca não consegue tratar ficam visíveis para a pessoa que está conduzindo o processo

• Usei GitHub Copilot bastante, sem interrupções, durante um mês, mas depois da mudança de preço no mês seguinte acabei com todos os tokens em dois dias
  Uma mudança tão brusca parece sinal de que o preço dos tokens é arbitrário e de que os negócios de IA estão ficando sem dinheiro rapidamente

  • Acho que isso está mais ligado a forçar a maior valuation possível ou um IPO
    Também há rumores de que a margem em inferência passa de 70%
    Usando a SpaceX como exemplo, ela elevou os preços dos produtos ao consumidor de forma geral nos últimos 6 meses, mas como Alphabet e Anthropic juntas estão pagando mais de US$ 2 bilhões por mês, não é que esteja faltando dinheiro
    A Microsoft/GitHub estava numa posição de reembalar o produto dos outros, então acabou saindo no prejuízo nessa história
  • O caso do GitHub está mais para uma exceção que parece especialmente brusca porque houve uma mudança recente de política de preços
    Em geral, os preços são definidos por vários fatores subjacentes, e isso por si só não significa que sejam arbitrários
    Por exemplo, se executivos do GitHub tivessem definido o preço dos tokens com um gerador de números aleatórios, aí sim seria precificação arbitrária

• Há um trecho dizendo que “os tokens de entrada representam em média 53,9% do consumo, a maior fatia”, mas no meu uso a proporção fica mais perto de 10:1
  A esmagadora maioria dos tokens consumidos está no lado da entrada, e é comum o agente ler um milhão de tokens para corrigir uma única linha de código
  Se estiver perto de 1:1 ou se a saída for maior, eu assumiria que há algum problema com o agente ou que a base de código é nova ou vazia

  • Fico curioso se você já tentou fornecer ferramentas melhores para o agente explorar e documentar a base de código, como AST, servidores de linguagem e afins
    Um milhão de tokens sem cache parece bastante coisa
  • Se os tokens de entrada dominam o custo nesse nível, isso significa que dá para melhorar muito apenas aproveitando melhor o cache
    Seria possível mandar o modelo fazer uma etapa única de “compressão”, despejando as partes relevantes do código, e usar esse resultado como prefixo em cache para muitas chamadas de subagentes

• Quando você usa agentes para programar, eles parecem querer escrever testes unitários aos milhares, mas têm pouca inclinação para testar de forma dinâmica

  • Também gostam de queimar uma quantidade enorme de tokens escrevendo e depurando testes semanticamente quebrados
  • Teste unitário também é um tipo de teste dinâmico
    Teste estático é algo como lint ou verificação de tipos
    Se você quer outros tipos de teste dinâmico além de testes unitários, fico curioso se já tentou explicitar isso como requisito na etapa de planejamento ou de PRD
  • A AWS também força bastante soluções complexas com Lambda que ligam o máximo possível de serviços faturáveis da AWS para requisitos simples
    Os interesses deles nem sempre estão alinhados com os seus
    Neste caso, eles querem fazer você gastar dinheiro desnecessariamente com trabalho inútil
    Acho que já passou da hora de parar de usar o eufemismo “tokens”
  • Basta instruir para fazer mais testes dinâmicos
    Acho que parte da resistência a testes dinâmicos vem do fato de que eles tornam tudo mais lento e podem interromper o software em lugares inesperados

• Lembrei de um artigo do ano passado que fornecia orientação de orçamento para otimizar a eficiência no uso de tokens
  [1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...

• Isso é parecido com milhas de recompensa de companhia aérea e, do ponto de vista da empresa, não tem vantagem em relação a alugar tempo de GPU bare metal

  • Espero que essa fase horrível acabe logo, à medida que mais empresas de hardware lancem NPUs baratas e os tamanhos dos modelos sejam melhor otimizados
    Quando a maior parte da demanda por IA puder ser atendida com hardware e modelos on-premise ou on-device, fico me perguntando para que servirão essas megafazendas de computação e modelos, com seus custos operacionais
    Provavelmente os únicos clientes restantes serão grandes governos, e no fim o contribuinte vai pagar pelos bilhões de dólares investidos pelo cartel da IA

• Escrevi um post no Substack sobre isso em dezembro: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...

• Antigamente, empresas como o Google contratavam engenheiros observando o quão bem conseguiam otimizar infraestrutura
  Em breve, talvez as empresas passem a olhar para a capacidade do engenheiro de otimizar a eficiência de tokens de IA

  • Isso exige assumir que tokens continuarão tendo custo significativo
    Não tenho certeza de que os desenvolvedores encontrarão novos usos para gastar mais tokens na mesma velocidade em que os preços caem
  • Sei como reduzir a conta de tokens da empresa a zero
    Basta tratar tokens como um custo de utilidade pública, como internet, e fazer os engenheiros pagarem do próprio bolso

• Como curiosidade paralela, eu estava numa reunião para avaliar um novo produto candidato, e tudo ia bem até aparecer uma tela mostrando que tinham adicionado IA ao produto
  Claro que tinha IA, e parecia algo muito forçado
  Um dos sinais disso era haver uma coluna mostrando quantos tokens cada consulta tinha consumido
  Perguntei quem pagava pelo custo dos tokens, e disseram que estava incluído na licença; então perguntei se havia um limite de orçamento ou se era ilimitado, e responderam que era uma boa pergunta e que iam verificar
  Perguntei isso porque uma única consulta simples sobre um dispositivo, que eles tinham acabado de mostrar, tinha queimado 250 mil tokens
  Nesse momento, ouvi um dos executivos do outro lado dizer em voz alta: “Por que estamos mostrando isso ao cliente?” e demos boas risadas
  A lição aqui é que o custo de adicionar IA a qualquer coisa não está sendo devidamente calculado, e o custo real de operar IA menos ainda
  Tudo que tiver IA embutida vai ficar mais caro, você queira ou não

  • AIshittification

• Tokenomics já é uma palavra usada para explicar a economia de criptomoedas, então, mesmo que os tokens usados em IA sejam de outro tipo, não entendo por que insistir em redefinir esse termo

  • Tokenomics também já era uma palavra usada há muito tempo entre entusiastas de maconha
  • É a nova moda
    Esqueça a moda anterior; essa também vai envelhecer logo, então é melhor embarcar antes que seja tarde demais
  • cryptocurrency economics = cryptonomics
  • “Crypto” também já existia antes de o pessoal de criptomoeda tomar a palavra para si
    “Web 3.0” também existia antes de o pessoal de criptomoeda transformar Web3 em algo centrado em cripto
    Então não vejo qual é o problema
    Termos continuam sendo reutilizados em contextos diferentes
    Além disso, a maioria já saiu do mundo cripto, então a chance de causar confusão também não é tão grande