195 requests para gerar testes com IA. E nenhum ganho de produtividade para declarar.

Em algum momento do processo, o agente olhou para um cenário que estava falhando e propôs uma solução: desativar o teste.

Não corrigir o código. Não ajustar a asserção. Desativar.

E aqui está a parte que me incomoda até hoje: se eu tivesse aceitado, o pipeline ficaria verde. Ninguém receberia alerta nenhum. A cobertura cairia em silêncio e eu só descobriria quando o bug chegasse em produção.

Esse episódio aconteceu no meio de um trabalho que um colega me pediu para documentar — ele queria replicar no time dele o que eu tinha feito no meu. Escrevi o documento. E ao escrever, percebi que a parte interessante não era o método. Era o que eu tinha medido, e principalmente o que eu me recusei a medir.

O que eu não vou dizer neste post

Não tenho ganho de produtividade para declarar.

Sei que essa é a primeira coisa que se espera de um texto sobre agentes de IA. “Reduzi 40% do tempo”, “entreguei em 3 dias o que levava 3 semanas”. Eu não tenho esse número, e não vou inventar.

O motivo é simples: não existe baseline. Eu não cronometrei o mesmo conjunto de testes sendo feito à mão, então não tenho o “antes” para comparar com o “depois”. Estimar isso de cabeça e apresentar como medição seria chute com cara de dado.

Se alguém precisar desse número para decidir adoção, o caminho honesto é cronometrar um recorte pequeno feito manualmente e comparar. Aí o número existe de verdade. Enquanto isso não for feito, qualquer percentual de ganho que aparecer nessa conversa é chute — inclusive se vier de mim.

O que eu tenho é o outro lado da conta: quanto a IA consumiu. Esse eu medi, request a request.

O método: spec → plano → implementação

Antes do método, um enquadramento que muda a leitura de tudo o que vem depois: isso não foi feito em dedicação exclusiva.

A prioridade do período era outra — teste exploratório e execução manual dos cenários que eu já tinha planejado. A automação com agentes andou nas janelas livres entre essas atividades.

Isso importa por dois motivos. O primeiro é de leitura dos números: a janela de 6 dias é de calendário, não de trabalho contínuo. O segundo é de origem: o desenho dos cenários é meu e veio antes, do planejamento e do teste manual. O agente entrou na etapa de transformar cenário já pensado em código. Não na etapa de decidir o que testar.

O fluxo é encadeado, e a ordem importa:

1. Spec — escrita antes de existir plano.
2. Plano — aprovado antes de existir código.
3. Implementação — contra um plano que eu já revisei.

O agente não começa a escrever teste porque alguém pediu “escreva os testes”. Ele escreve contra um plano revisado. Parece detalhe de processo, mas é o que separa geração de código de geração de bagunça.

O ferramental:

• GitHub Copilot no VS Code, num workspace único com três projetos abertos ao mesmo tempo: o sistema, a automação dele e o repositório de testes. O agente enxerga os três — é isso que permite ele relacionar o teste com o código que está sendo testado.
• Superpowers, conduzindo o encadeamento spec → plano → implementação.
• Serena (MCP), acrescentando navegação estrutural por símbolos via LSP: ir à definição, listar as referências reais de um símbolo, editar um símbolo inteiro.

Vale delimitar o Serena, porque é fácil errar aqui — e eu quase errei ao escrever o documento interno. O Copilot já faz indexação e busca semântica de repositório nas superfícies principais. O Serena não está tapando esse buraco.

O que ele adiciona é a camada estrutural: “quem chama este método” e “o que quebra se eu mudar esta assinatura” respondidos por referência real, não por trecho parecido. É determinístico — a resposta vem do índice da linguagem. Em base grande, é o que impede o agente de propor mudança no arquivo errado.

O que 195 requests consumiram

Aqui eu preciso ser rigoroso com o que o dado diz.

O que eu extraí mede consumo por modelo, nunca por fase do trabalho. Eu não instrumentei “quanto foi planejamento e quanto foi implementação”, então não afirmo isso. Dizer “36% foi planejamento” não sobrevive à pergunta “como você separou as fases?”.

A formulação que se sustenta é outra: declarar a política e mostrar o consumo que ela produziu.

Minha política foi Opus no planejamento, modelo automático na implementação. O consumo reflete isso: o Opus é 30% dos requests mas 49% dos créditos; o automático é 51% dos requests e só 21% dos créditos.

Janela de 03 a 10/08/2026 — 195 requests, 24 sessões, 6 dias de calendário com atividade:

Modelo	Requests	Créditos	Créditos/request
copilot/auto	51,3%	21,4%	~36
copilot/claude-opus-5	30,3%	49,0%	~140
copilot/claude-sonnet-5	9,2%	7,9%	~74
sem modelo registrado	4,1%	0%	—
copilot/gpt-5.6-sol	2,6%	20,5%	~691
copilot/gpt-5.6-terra	2,6%	1,1%	~38

Aquela linha “sem modelo registrado” são 8 requests em que o campo modelId não veio preenchido na sessão. Eles entram no total de requests e ficam fora do total de créditos.

Eu poderia ter escondido essas 8 linhas e feito a tabela somar 100% redondinho. Preferi mostrar. Tabela que fecha perfeito costuma esconder alguma coisa.

Outras duas limitações que eu declaro junto com o dado: 14 requests (7,2%) não trazem o campo de crédito e entram como zero — e zero aqui não quer dizer consumo zero. E “créditos” é a unidade que o próprio Copilot registra, que eu não converto em reais nem em nenhuma unidade de cobrança.

O desperdício mora numa cauda que ninguém audita

Olhe de novo para a tabela, agora só pela última coluna:

Modelo	Créditos por request
copilot/gpt-5.6-sol	~691
copilot/claude-opus-5	~140
copilot/claude-sonnet-5	~74
copilot/gpt-5.6-terra	~38
copilot/auto	~36

O gpt-5.6-sol fez 5 requests. Cinco. Isso é 2,6% do volume da janela — e consumiu 20,5% dos créditos. Cada request dele custa cerca de 19 vezes um request do modelo automático.

Cinco chamadas que eu nem lembro de ter feito comeram um quinto do orçamento da semana.

Isso tem nome. O Nassim Taleb chama de Extremistão o domínio em que uma observação isolada domina o total: some o homem mais alto do mundo a uma amostra de mil pessoas e a média mal se mexe; some cinco requests de ~691 créditos a uma semana de 195 e você perde um quinto do orçamento.

Mas a camada que me interessa mais está em Arriscando a Própria Pele. Risco de cauda costuma ser transferido — quem decide não é quem sente a consequência. E é exatamente o caso aqui: o crédito não sai do meu bolso, o request caro não me acorda de madrugada, e o custo chega diluído num relatório que alguém lê no fim do trimestre.

Cauda que ninguém sente no bolso é cauda que ninguém audita.

Não estou propondo que cada dev pague a própria conta de IA. Estou dizendo que, sem alguém com pele em jogo olhando o número, a cauda cresce sem oposição. No meu caso, essa pessoa passou a ser eu — depois de medir.

Essa é a lição que eu levaria para qualquer time adotando isso: o desperdício não mora no modelo que aparece nas conversas. Mora numa cauda curta que ninguém audita. Se você olhar só o modelo dominante, deixa passar a maior parte do custo evitável.

Eu errei o meu próprio número

A primeira versão do meu extrator contava 250 requests.

O VS Code grava a mesma sessão de chat em vários workspaceStorage, e eu estava somando o mesmo request duas ou três vezes. Corrigi com deduplicação por sessão + request e o número virou 195. Os percentuais mudaram alguns pontos; nenhuma conclusão mudou.

Poderia ter passado batido. Passou porque o número é reprodutível — e o que separa um número de uma alegação é justamente isso. O extrator lê workspaceStorage/<hash>/chatSessions/*.jsonl do próprio VS Code, termina com código de saída 1 se perdeu qualquer dado na leitura e imprime um bloco de cobertura no fim. Nesta janela: 0 linhas ilegíveis, 0 patches rejeitados, 0 sessão sem snapshot.

Se o número estiver errado, o comando mostra isso em um minuto. Foi exatamente o que aconteceu comigo.

O que eu rejeitei da IA

Esta é a seção que faz o resto do texto valer alguma coisa. O planejamento de testes gerado por modelo trouxe três tipos de proposta que não entraram:

1. Cenários que não faziam sentido — plausíveis na escrita, sem correspondência com o comportamento real do sistema.
2. Cenários impossíveis de testar — dependiam de estado que a suíte não consegue montar.
3. Uma tentativa de desativar um cenário em vez de fazê-lo passar.

O terceiro é o perigoso, e é o que eu peço que você leve daqui se não levar mais nada.

Um teste desativado passa no CI sem alarme nenhum. O pipeline fica verde, a cobertura cai em silêncio e ninguém descobre até o bug chegar em produção. Quando o agente propõe mexer no status de um teste em vez de mexer no código, isso é sinal de parada. Sempre revisão humana. Sempre.

E não adianta ficar indignado com o modelo. Agente de IA otimiza o objetivo que você deu. Se o objetivo que ele leu foi “deixe a suíte verde”, desativar teste é uma solução perfeitamente válida do ponto de vista dele. Quem define o objetivo e audita o resultado é a pessoa.

O que eu ainda não medi

Além da falta de baseline manual, tem um buraco no meu próprio dado que eu prefiro declarar a maquiar.

83% dos requests da janela (162 de 195) rodaram num workspace multi-root e não são atribuíveis a um projeto pelo caminho da pasta. Consequência direta: número por modelo vale, número por projeto não sai deste dado.

Se alguém precisar de custo por projeto, o caminho é separar workspaces antes de medir. Não estimar em cima do que já existe.

Eu já tinha feito. Só não tinha nomeado.

Umas semanas antes de fechar esse trabalho, li o artigo do Bryan Soares sobre Parity-Driven Development — o PDD.

A tese dele é que, num refactor de legado, a pergunta que importa não é “o código novo está bonito?”, mas “o sistema novo ainda se comporta igual ao antigo?”. E que essa pergunta quase sempre é respondida por sensação: “acho que tá igual”. O PDD troca a sensação por evidência rastreável — cada achado carrega um tier de confiança, e o método se recusa a fechar um achado abaixo do mínimo que você definiu no início do projeto.

Quando li, tive duas reações ao mesmo tempo.

A primeira foi de reconhecimento: o que eu tinha feito na migração dos meus testes era a mesma coisa, comparando o comportamento do sistema novo contra o legado em vez de confiar em opinião. Eu só não tinha nomeado, e principalmente não tinha publicado.

A segunda foi menos confortável. Bateu aquela sensação de ter chegado atrasado numa ideia que já era minha. Levei um tempo para entender que não era atraso — era validação. Se duas pessoas chegam no mesmo lugar por caminhos diferentes, o lugar provavelmente existe. O que me faltou não foi visão. Foi confiança de escrever.

Acabei procurando o Bryan para comentar isso, e rendeu uma conversa muito boa sobre o assunto. Recomendo o artigo dele sem reservas — e recomendo mais ainda a prática de procurar quem escreveu a coisa que te fez pensar.

E tem uma conexão direta com o vício que descrevi lá em cima. O tier de confiança do PDD bloqueia por estrutura o que eu tive que barrar por vigilância: um cenário desativado não produz tier alto por construção, porque os tiers mais altos exigem diff automatizado dado a dado ou teste de caracterização passando. Não a ausência de um teste que falha.

Vigilância cansa. Estrutura não.

Por fim

Se eu fosse refazer isso hoje, do zero, seria mais ou menos assim:

1. Abrir um workspace com os projetos que se relacionam — código e automação — para o agente enxergar os dois lados.
2. Ligar a navegação por símbolos antes de gerar qualquer coisa. É o que segura o agente no alvo certo em base grande.
3. Encadear spec → plano → implementação, e revisar o plano antes de deixar gerar código.
4. Definir a política de modelos por fase antes de começar, e medir o consumo depois.
5. Rodar a medição já na primeira semana, olhando especificamente a cauda — o modelo raro e caro é onde mora o desperdício.
6. Tratar toda proposta de desativar ou pular teste como bloqueio de revisão.

No fim do dia, o que eu trouxe aqui não é um caso de sucesso com percentual bonito no topo. É um relato com número reprodutível, limitação declarada e uma lista do que eu não deixei entrar.

Acho que a gente precisa de mais desses. A conversa sobre agentes de IA em qualidade está cheia de ganho declarado e vazia de medição — e uma coisa não é a outra.

Você já mediu o que os seus agentes consomem, ou só o que eles entregam?