Depois dos story points: o que medir no AI-DLC

Um story point é um palpite sobre quão difícil uma tarefa é para um humano. Quando um agente escreve o código, ninguém mais é esse humano.

No AI-DLC, meça quatro coisas no lugar de pontos e velocity: quanto tempo leva de um intent aprovado até código testado e pronto para deploy, com que frequência as pessoas devolvem o trabalho do agente nos gates, quanto tempo leva de um problema até um intent aprovado, e o que de fato chegou aos usuários. E nunca leia o throughput sozinho. Leia ao lado do cycle time, sempre.

Essa é a resposta. O resto deste guia é por que as métricas antigas quebram, quais pares mantêm as novas honestas e onde o AI-DLC 2 já anota os dados para você. Se você está chegando agora no método, comece por o que é AI-DLC.

Aprendi a maior parte disso acompanhando squads piloto adotarem AI-DLC dentro de uma grande organização de engenharia. A coisa mais útil que vi foi um par de gráficos que discordavam. O throughput subiu desde a primeira semana. O cycle time piorou. Um time que reportasse só o primeiro gráfico teria declarado vitória, e um time que reportasse só o segundo teria matado o piloto. Os dois estariam errados.

Story points medem a coisa errada agora

O whitepaper do AI-DLC faz a pergunta em voz alta: a estimativa de esforço, como story points, ainda seria tão crítica se a IA apaga a linha entre tarefas simples, médias e difíceis? E a velocity ainda seria relevante, ou os times deveriam começar a substituí-la por valor de negócio?

A resposta honesta é não, e o motivo é mecânico. Um story point é um proxy de esforço humano: quanto tempo uma pessoa precisa para entender, escrever e testar uma mudança. A velocity soma esses proxies por sprint. Quando um agente gera o código em minutos, as partes caras mudam de lugar. Escrever fica barato. Decidir, revisar e integrar não. Uma tarefa que o time chamaria de 8 pode levar dez minutos para o agente e dois dias para quem revisa, e pontos não conseguem dizer por qual das metades você está pagando.

O AI-DLC também acaba com o recipiente onde os pontos moravam. As sprints viram bolts, fatias de entrega medidas em horas ou dias. Estimar uma sprint de duas semanas em pontos fazia sentido. Estimar um bolt de três horas em pontos é teatro.

Quatro métricas para substituir pontos e velocity

O whitepaper só propõe valor de negócio. O guia da Augment Code chega no mesmo ponto pelo lado da adoção: a produtividade individual sobe enquanto a entrega quase não se mexe. Os times que acompanhei convergiram para um conjunto mais completo, e cada métrica substitui um número antigo específico por um motivo específico.

O que substitui o quê

A construção fica rápida. O que sobra para medir é a parte humana dos dois lados dela.

Métrica antiga	Métrica de AI-DLC	O que ela mede de verdade
Story points	Construction Lead Time	Tempo corrido de um intent aprovado até uma Unit testada e pronta para deploy. A velocidade do agente e o tempo de review das pessoas, juntos.
Velocity	Valor de negócio entregue	O que chegou aos usuários e moveu a métrica que o intent nomeou. Queimar pontos nunca fez isso.
Contagem de bugs	Taxa de retrabalho	Com que frequência as pessoas respondem Request Changes em um gate, por stage. Onde o agente continua errando.
Tempo na sprint	Discovery Lead Time	Tempo corrido desde que um problema é identificado até um intent aprovado. Tudo o que vem antes do agente.

A última linha é a que os times esquecem. Quando a construção encolhe de semanas para dias, a parte mais lenta da entrega muitas vezes é tudo o que vem antes dela: as reuniões, os documentos, as aprovações que transformam “os clientes reclamam de X” em um intent claro. No rollout que acompanhei, o discovery levava muito mais tempo do que a construção, e ninguém media isso porque o trabalho de produto e de design nunca tinha sido rastreado do jeito que os tickets eram. Se você só mede a metade do agente, otimiza a metade que já é rápida. Escrevi sobre esse buraco antes do agente em o ponto cego do AI-DLC.

O throughput mente quando você lê ele sozinho

Este é o padrão que vi em todos os squads piloto. Na primeira semana, o agente produz código na hora, então as mudanças mergeadas por dev disparam. Ninguém redesenhou o code review para o volume novo, então as mudanças se acumulam esperando uma pessoa, e o tempo entre o primeiro commit e o deploy sobe antes de cair.

O throughput diz que o piloto é um sucesso. O cycle time diz que está falhando. Nenhum dos dois é a verdade sozinho. O estudo da Microsoft sobre o próprio rollout de Claude Code e Copilot CLI encontrou que quem adotou mergeou cerca de 24% mais pull requests, e os autores tiveram o cuidado de dizer que um pull request mergeado “não é a mesma coisa que o valor que ele entrega” (arXiv 2607.01418). Essa ressalva é o ponto inteiro desta seção.

Leia throughput e cycle time juntos

longo·cycle time·curto

Travado

Pouca coisa sai e o que sai demora. O método ainda não está funcionando, ou o repositório não é legível para um agente.

Gargalo de review

O agente produz muito, as pessoas não dão conta de absorver. O vale da curva em J. Diminua as Units e redesenhe o review, não mate o piloto.

Cauteloso ou ocioso

Rápido quando sai, mas sai pouco. Ou o time é cauteloso de propósito, ou o agente quase não é usado.

Onde você quer estar

Sai mais e sai mais rápido. Normalmente se chega aqui depois do vale, nunca no primeiro dia.

baixothroughputalto

Um time que vai do canto inferior esquerdo para o superior direito não está falhando. Está no vale, a caminho do inferior direito.

A solução para o gargalo de review não é um revisor mais rápido. São pedaços menores na origem. Peça ao agente para estimar o tamanho de cada Unit antes de a Construction começar, quebre qualquer coisa que geraria um merge request enorme (por endpoint, migrations separadas) e combine com o time um tamanho que quem revisa consiga de fato ler. A curva em J inteira, e quando tratá-la como problema estrutural em vez de curva de aprendizado, está em por que o AI-DLC te deixa mais lento primeiro.

O AI-DLC 2 já registra a maior parte disso

A boa notícia do AI-DLC 2 é que você não precisa de uma ferramenta nova de analytics para começar. Cada pedaço de trabalho ganha uma pasta de registro com um log de auditoria append-only que conhece 108 tipos de evento, e o motor compila um grafo de runtime a partir dele depois de cada transição de stage.

Perguntas que o registro responde

Nomes de evento do guia de estado e auditoria do AI-DLC 2.10.0. O resumo de runtime é só leitura e pode rodar a qualquer momento.

A pergunta	Onde o AI-DLC 2 anota
Onde o agente continua errando?	GATE_APPROVED e GATE_REJECTED por stage, mais a contagem de revisões no arquivo de estado. Rejeições sobre o total de decisões é a sua taxa de retrabalho por stage.
Quanto tempo as pessoas deixam o trabalho esperando?	De STAGE_AWAITING_APPROVAL até GATE_APPROVED. O /aidlc --status mostra há quanto tempo o gate aberto está esperando; o doctor sinaliza gates esperando há mais de 24 horas.
As checagens determinísticas estão pegando alguma coisa?	SENSOR_FIRED, SENSOR_PASSED, SENSOR_FAILED, somados no resumo de runtime.
O time está ensinando o agente?	Aprendizados capturados nos gates, contados no resumo de runtime, e as regras que eles adicionaram à memória do projeto e do time.
O código mergeado bate com o que foi revisado?	O aidlc attest classifica cada caminho alterado como verified, drifted, unattested ou unverifiable em relação aos recibos de review.

O jeito mais rápido de começar é o /aidlc-session-cost, que imprime duração, resultado de cada stage, resultados dos sensores e aprendizados do workflow atual, ou o comando que ele lê, que também gera JSON:

aidlc engine runtime summary --json

Um sinal que eu adicionaria por cima: o tempo entre um gate abrir e a aprovação. Um documento de requisitos aprovado quarenta segundos depois de aparecer não foi lido. É uma medida grosseira, mas um time em que esse número continua caindo ao longo da tarde é um time ficando cansado, e gates cansados são por onde passam as decisões ruins. Mais sobre isso em gates são uma função de perda.

Métricas de harness: o agente está melhorando?

As quatro métricas acima dizem se a entrega melhorou. Um segundo conjunto diz se o seu setup em volta do agente está melhorando: o contexto, as regras, as checagens. Esse setup é o harness, e é a parte que você controla.

Quatro métricas de harness

1. 01

   Taxa de escalonamento

   A fatia de tarefas que acabam precisando que uma pessoa intervenha além dos gates planejados. Ela deve cair conforme o harness amadurece. Se não cai, as regras e o contexto não estão aprendendo.

   +
2. 02

   Taxa de espiral do agente

   A fatia de tarefas em que o agente fica em loop sem progresso: a mesma correção tentada três vezes, a mesma pergunta feita de novo. Leia nos logs de sessão. Uma taxa de espiral subindo normalmente significa context rot ou uma spec vaga.

   +
3. 03

   Taxa de retenção de código

   A fatia do código escrito pelo agente que ainda existe N dias depois, direto do histórico do git. Não precisa de instrumentação.

   +
4. 04

   Alocação de atenção

   A fatia do tempo dos engenheiros gasta em decisões (especificar, revisar, escolher) contra operação. É autodeclarada, então trate como conversa, não como número.

A retenção é a que parece mais simples e é a mais fácil de ler errado. Um estudo grande com 201 projetos open source encontrou que o código escrito por agentes sobrevive mais do que o código humano, com um risco 16% menor de ser modificado (Will It Survive?). Isso pode significar que o código é bom. Também pode significar que ninguém se sente dono dele, então ninguém mexe. Outro estudo encontrou que arquivos gerados por IA recebem manutenção com menos frequência, e quando recebem, são humanos que fazem a grande maioria do trabalho (arXiv 2605.06464). A conclusão do próprio primeiro artigo é a certa: o gargalo pode não ser a qualidade da geração, e sim as práticas da organização em volta do código. Leia a retenção junto com quem modifica o código e por quê. Retenção alta mais ninguém mexendo em um módulo que deveria estar mudando não é qualidade. É código órfão.

Três jeitos de estragar as suas métricas

Toda métrica vira meta no momento em que você coloca ela numa avaliação de desempenho. Estas são as três que eu vi acontecer, ou quase acontecer.

Erros de medição em rollouts de AI-DLC

• ✗Anti-pattern:
  Transformar um score de prontidão em KPI.Ferramentas que pontuam quão legível um repositório é para um agente são úteis como diagnóstico. Transforme o score em meta e os times criam um CLAUDE.md vazio para subir o número.
• ✗Anti-pattern:
  Confiar na velocidade que as pessoas sentem.No estudo controlado do METR, devs experientes ficaram 19% mais lentos com ferramentas de IA enquanto acreditavam estar 20% mais rápidos. Velocidade autodeclarada não é métrica.
• ✗Anti-pattern:
  Contar mudanças mergeadas como produção.O throughput sobe na primeira semana de qualquer jeito. Sem cycle time e retrabalho do lado, você está medindo quanto o agente digitou.
• ✓Obrigatório:
  Medir os pares, por stage, a partir do registro.Lead time com throughput, retrabalho por stage, tempo de discovery antes do agente. Tudo isso já está no log de auditoria.

O resultado do METR merece mais uma linha, porque é a evidência mais limpa de que a percepção falha aqui (METR). Os devs não eram descuidados. Eram pessoas experientes trabalhando nos próprios repositórios, e a sensação de velocidade delas estava errada na direção oposta à verdade. Se a percepção falha para elas, falha para o seu time. Meça.

Um dashboard para o primeiro trimestre

O que colocar na parede

• ✓Obrigatório:
  Cycle time (mediana e percentil 75) ao lado do throughput, toda semana.Nunca um sem o outro.
• ✓Obrigatório:
  Taxa de retrabalho por stage.Requisitos, design e planos de código separados. O stage com a taxa mais alta é onde o seu contexto ou o seu intent está mais fraco.
• ✓Obrigatório:
  Discovery Lead Time.Do problema identificado ao intent aprovado. Comece a medir mesmo que dê vergonha.
• ✓Obrigatório:
  Tempo de espera no gate e tempo até aprovar.Esperas longas indicam gargalo de review. Aprovações instantâneas indicam cansaço.
• •Opcional:
  Retenção de código em 30 e 90 dias, com quem modificou.Do histórico do git. Leia junto com ownership, não sozinha.
• ✓Obrigatório:
  Um ponto de decisão em quatro semanas.Se o cycle time não começou a cair depois de umas quatro semanas, descubra se é a curva em J ou um problema estrutural antes de decidir qualquer coisa.

Nada disso precisa de um time de dados. O log de auditoria, o histórico do git e uma planilha te levam pelo primeiro trimestre. O que precisa é da disciplina de reportar o par que discorda, principalmente quando uma das metades parece ótima. E isso muda o que você premia, o que é um problema à parte: quando o trabalho vira especificar e revisar, a matriz de competências tem que acompanhar. Isso está em do squad ao pod.

Perguntas frequentes

Story points ainda fazem sentido com agentes de IA?+

Pouco. Pontos estimam esforço humano, e quando um agente escreve o código o esforço sai de digitar e vai para decidir e revisar. Uma tarefa pode levar minutos para o agente e dias para quem revisa.

O próprio whitepaper do AI-DLC pergunta se estimativa e velocity ainda importam, e sugere valor de negócio no lugar.

O que substitui a velocity no AI-DLC?+

Valor de negócio entregue, lido junto com Construction Lead Time (do intent aprovado ao código testado), taxa de retrabalho nos gates e Discovery Lead Time antes do agente. O throughput continua útil só quando lido ao lado do cycle time.

Como eu meço retrabalho no AI-DLC?+

Conte os Request Changes contra o total de decisões nos gates, por stage. O AI-DLC 2 registra os dois como GATE_REJECTED e GATE_APPROVED no log de auditoria, mais uma contagem de revisões por stage no arquivo de estado.

As métricas DORA ainda servem com agentes de IA?+

Sim, principalmente o lead time for changes, que é o mais próximo do que os agentes afetam. O que muda é que você precisa adicionar o que vem antes (tempo de discovery) e os gates (retrabalho, tempo de espera), porque é para lá que o AI-DLC move o gargalo.

Por que o nosso cycle time piorou depois de adotar AI-DLC?+

Porque o agente produz mais mudanças do que o seu processo de review foi feito para absorver. É o padrão mais previsível em rollouts de AI-DLC. Diminua as Units, redesenhe o review e dê umas quatro semanas antes de decidir.

Onde o AI-DLC 2 guarda os dados do workflow?+

Em uma pasta de registro por pedaço de trabalho em aidlc/spaces/<space>/intents/, com um arquivo de estado, cada artefato e um log de auditoria append-only. O aidlc engine runtime summary --json agrega tudo.

Para onde ir agora

Meça a parte humana. A velocidade do agente se resolve sozinha na primeira semana, e fica linda num gráfico. O que decide se o AI-DLC funciona é quanto tempo as pessoas levam para decidir, com que frequência elas precisam devolver trabalho, e se o que vai para produção é o que alguém quis dizer.