Parei de medir produtividade por volume de código

O dashboard ficou verde e a confiança no sistema caiu. Linhas de código por semana subindo, PRs mergeados batendo recorde, velocity do time no melhor trimestre do ano. E, do outro lado, cada incidente demorava mais pra resolver, cada mudança nova exigia uma reunião pra entender o que já existia. A métrica bonita de mostrar pro board foi a primeira coisa que joguei fora.

O motivo é simples e desconfortável: desde que o agente passou a escrever metade do que sai do time, contar volume deixou de medir progresso. Passou a medir a taxa na qual acumulamos código que ninguém entende.

Volume nunca foi produtividade, só passava despercebido

Sempre foi ruim medir linhas ou PRs. A diferença é que antes o custo de escrever segurava o número numa faixa honesta: um humano digita devagar, então volume alto era, na média, sinal de esforço real. O gargalo era o teclado, e o teclado tinha um limite biológico que funcionava como controle de qualidade acidental.

Esse freio sumiu. Hoje um dev com agente abre dez PRs num dia sem suar. O número dobra, triplica, e não te diz nada sobre se o sistema ficou melhor. Pior: te dá um incentivo. Time que é medido por volume aprende rápido a produzir volume, e o agente é uma máquina de fabricar exatamente essa métrica. Você otimiza para o número e o número deixa de significar qualquer coisa. É a Lei de Goodhart em velocidade de GPU.

Quando a medida vira meta, ela para de medir. Com agente, ela para em uma tarde.

O sistema entrega no ritmo do gargalo, não do teclado

A pergunta que passei a fazer não é “quanto código saiu”, é “onde a entrega trava”. E o gargalo quase nunca está mais na digitação. Está na revisão, no entendimento, no deploy, no medo de mexer numa parte que ninguém domina. Gerar mais código a montante de um gargalo desses não acelera nada. Só engrossa a fila.

Foi isso que troquei. Aposentei linhas, PRs e velocity. No lugar entraram quatro medidas, três delas emprestadas de DORA porque DORA tem uma virtude rara: ela não pergunta quem escreveu o código, humano ou máquina. Mede o fluxo, não a autoria.

• Lead time até produção. Do commit ao usuário. É o relógio honesto: se o agente gera mais e isso não chega mais rápido, o ganho é fictício.
• Retrabalho. Quanto do que entrou volta pra ser mexido em semanas. Código de agente costuma passar no teste e falhar no segundo requisito. Retrabalho alto é dívida disfarçada de entrega.
• Defeito que escapa. Bug que o cliente encontra antes de nós. Volume alto com escape subindo é a definição operacional de “verde no dashboard, vermelho na confiança”.
• Custo por decisão. Essa eu inventei pro nosso contexto. Não conto código, conto quantas decisões de arquitetura o time consegue tomar bem por trimestre. Porque é isso que a máquina não faz por você, e é o que de fato move o sistema.

O que a métrica nova protege

Trocar de métrica não é higiene de dashboard. É definir o que o time entende por “bom”. Se o número no topo é volume, o time otimiza geração e a arquitetura vira aluvião. Se o número é fluxo e retrabalho, o time otimiza entender antes de escrever, e o agente vira alavanca em vez de mangueira aberta.

O board não precisa ver quantas linhas produzimos. Precisa ver que uma mudança leva dois dias em vez de duas semanas, que quase nada volta, que o cliente não é o nosso QA. Isso vende melhor que velocity, e tem a vantagem de ser verdade.

Métrica não descreve o trabalho. Ela escolhe qual trabalho vai acontecer. Escolha a que você teria orgulho de ver o time otimizar até o limite.