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

> Gerei testes de um sistema legado com agentes de IA e medi o custo request a request: onde mora o desperdício, o que rejeitei e por que não declaro ganho.

- URL: https://iagofrota.com.br/blog/195-requests-gerar-testes-com-ia/
- Data: 2026-08-25
- Tags: qa, testes-automatizados, agentes-de-ia, github-copilot, custo-de-ia, pdd

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](https://lnkd.in/p/eEv3_Uaq) — 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?