Como medir se um agente de código está te fazendo ganhar tempo, com número em vez de sensação

A sensação de velocidade engana porque o tempo economizado na escrita reaparece na revisão e no retrabalho. Quatro métricas que cabem numa planilha e mostram se o ganho é real ou se você só mudou...

Como medir se um agente de código está te fazendo ganhar tempo, com número em vez de sensação
Neste artigo
  1. Por que a sensação de velocidade engana?
  2. Quais quatro números bastam para saber se há ganho?
  3. Como comparar com o que você fazia antes sem parar tudo para medir?
  4. Qual métrica engana mais e por quê?
  5. Como detectar que o ganho virou prejuízo?
  6. Que meta é realista depois de três meses?

Quase todo mundo que adota agente de código relata ganho de velocidade, e quase ninguém tem número. Isso é um problema, porque a sensação de velocidade é justamente o que essa ferramenta mais distorce: escrever ficou rápido, e escrever nunca foi o gargalo.

O que costuma acontecer é deslocamento. O tempo que sai da digitação entra na revisão, no retrabalho e na conversa de alinhamento. Pode ainda assim ser ganho líquido, e frequentemente é, só que ninguém sabe de quanto. Este texto é sobre como medir sem montar um projeto de métricas.

Por que a sensação de velocidade engana?

Porque o que você percebe é o momento em que o código aparece na tela, e esse é o único trecho do ciclo que ficou dramaticamente mais rápido.

O ciclo inteiro é: entender o problema, decidir a abordagem, escrever, revisar, testar, corrigir, integrar. O agente acelera muito um desses sete, um pouco dois ou três, e piora um, que é a revisão, porque agora você revisa código que não escreveu.

Como a parte acelerada é a mais visível, a impressão é de ganho enorme. O saldo real pode ser bom, ruim ou neutro, e a diferença entre esses três cenários é grande demais pra ficar no achismo.

Quais quatro números bastam para saber se há ganho?

Não precisa de ferramenta. Uma planilha com quatro colunas resolve, preenchida por task.

Tempo até o primeiro diff aceitável. Do momento em que a task foi passada até existir um diff que você aceitaria revisar. Inclui as vezes em que você teve que reformular o pedido.

Rodadas de correção. Quantas vezes o diff voltou pro agente antes de ficar bom. Esse é o número que mais denuncia task mal escrita.

Tempo de revisão humana. Quanto tempo você gastou lendo e julgando. Se esse número cresce junto com o tamanho do diff, você não está ganhando, está terceirizando digitação.

Retrabalho em sete dias. Quanto daquele código precisou ser mexido de novo na semana seguinte. É o número mais incômodo e o mais honesto.

Como comparar com o que você fazia antes sem parar tudo para medir?

Você não precisa de grupo de controle formal, precisa de amostra pareada.

Pega cinco tasks parecidas com coisas que você já fez à mão nos últimos meses e usa a sua própria estimativa antiga como referência. Não é rigoroso, e é muito melhor que nada.

Se você quiser algo mais firme, alterna: uma task com agente, a próxima sem, por duas semanas. Cansa, mas em duas semanas você tem dado suficiente pra parar de discutir por impressão.

Qual métrica engana mais e por quê?

Linhas de código, disparado.

Agente produz volume com facilidade, e volume não é entrega. Pior: código gerado tende a ser mais verboso que código escrito à mão, então linhas por hora sobe justamente quando a qualidade cai.

A segunda mais enganosa é número de commits. Pela mesma razão: fica fácil produzir muitos, e muitos commits pequenos podem significar tanto disciplina quanto o agente tateando.

Se você só puder acompanhar uma métrica, acompanhe retrabalho em sete dias. É a que menos se deixa inflar.

Como detectar que o ganho virou prejuízo?

Tem três padrões que aparecem antes de o problema ficar óbvio.

O primeiro é a revisão crescendo mais rápido que a entrega. Se o diff dobrou de tamanho e o tempo de revisão triplicou, o agente está gerando mais do que você consegue julgar.

O segundo é o retrabalho concentrado nos mesmos arquivos. Quando o mesmo módulo volta pra oficina toda semana, normalmente é sinal de que o agente nunca teve contexto suficiente sobre ele.

O terceiro é o aumento de bug em produção sem aumento proporcional de feature. Esse é o caro, e é o que costuma ser percebido tarde.

Que meta é realista depois de três meses?

Depende demais do tipo de trabalho pra existir número universal, e desconfie de quem promete um.

O que é razoável esperar: tarefa repetitiva e bem especificada tende a ter ganho grande e consistente. Tarefa exploratória, em código legado mal documentado, tende a ter ganho pequeno e às vezes negativo no começo.

A meta mais útil não é de velocidade, é de estabilidade: manter o retrabalho de sete dias no mesmo patamar de quando você escrevia à mão, enquanto entrega mais. Se você conseguir isso, o ganho é real e sustentável.

WA in X

Escrito por

Thales Gomes

Fundador da SyntaxLab. Constroi e mantem software em producao com Claude Code e Codex, de SaaS multi-tenant a agentes de IA integrados a operacao de empresa.