5 métricas de code review: 0 comentário = alerta

Sobre os números deste texto. O framework das cinco métricas vem do capítulo 14 do meu livro sobre code review com harness. Os cenários, as horas e as porcentagens aqui são exemplos trabalhados para mostrar como cada métrica se comporta, não medição de um time em produção. Rode o script no seu repositório antes de adotar qualquer número daqui.

Você abre um PR na sexta às 15h. Ninguém comenta nada. Segunda de manhã, um “LGTM” aparece, o merge acontece. Você respira. “Passou tranquilo.”

Não passou tranquilo. Passou sem que ninguém olhasse.

Essa é a métrica que quase ninguém está medindo: quantos comentários seu PR recebeu. E aqui vai a parte que me deixou nervoso quando percebi: 0 comentários é o pior sinal, não o melhor. É o sinal de que o revisor rolou o scroll até o final, viu que estava verde e apertou aprovar. O código passou pelo GitHub. Não passou pela cabeça de ninguém.

As 5 métricas que separam ritual de revisão

O capítulo 14 do meu livro sobre harness lista cinco métricas para medir a saúde da revisão. Nenhuma delas exige ferramenta paga. Todas saem da API do GitHub.

A métrica 3 é a que quero abrir aqui, porque é a que mais gente lê errado. As outras quatro são intuitivas (“mais rápido é melhor”, “menos ciclo é melhor”). A métrica 3 tem uma zona de “muito baixo é ruim, muito alto também é ruim”, e você precisa saber onde está.

Por que 0 comentário é alerta

Se um PR fecha com 0 comentários, existem três explicações possíveis:

1. O PR é trivial de verdade (renomear variável, atualizar dependência de patch)
2. O código está impecável (raro em PR de feature)
3. Ninguém leu

Numa distribuição típica desses cenários, dos PRs com 0 comentários, uns 20% costumam ser categoria 1 (trivial). Zero são categoria 2 (impecável — não existe). O restante é categoria 3.

Aí a métrica de Time to First Review parece ótima (“aprovamos em 45 minutos!”) e a métrica de Comentários por PR parece ótima (“média 2, super enxuto!”) — mas a saúde da revisão está péssima. Você automatizou o carimbo, não a revisão.

O outro extremo (25+ comentários por PR) também é sinal ruim, mas de outra coisa: PRs grandes demais, ou revisor entregando apontamentos aos poucos (que é a métrica 4).

Coletando as métricas em 30 linhas

O script fica assim (versão enxuta do que está no capítulo 14):

import os
from datetime import datetime, timedelta
from github import Github

g = Github(os.environ['GITHUB_TOKEN'])
repo = g.get_repo("seu-usuario/seu-repo")

since = datetime.now() - timedelta(days=30)
pulls = repo.get_pulls(state='closed', sort='updated', direction='desc')

metrics = []
for pr in pulls:
    if not (pr.merged_at and pr.merged_at > since):
        continue

    reviews = pr.get_reviews()
    first_review = next(
        (r for r in reviews if r.state != 'COMMENTED'),
        None
    )
    ttfr_h = None
    if first_review:
        delta = first_review.submitted_at - pr.created_at
        ttfr_h = delta.total_seconds() / 3600

    metrics.append({
        'pr': pr.number,
        'ttfr_h': ttfr_h,
        'ttm_h': (pr.merged_at - pr.created_at).total_seconds() / 3600,
        'comments': pr.get_review_comments().totalCount,
        'files': pr.changed_files,
    })

# Distribuição de comentários (a métrica 3)
zero_comments = sum(1 for m in metrics if m['comments'] == 0)
print(f"PRs com 0 comentário: {zero_comments}/{len(metrics)} ({zero_comments/len(metrics)*100:.0f}%)")

Coloque isso num GitHub Action que roda toda segunda de manhã e derrame o resultado num JSON. Não precisa de dashboard sofisticado. Precisa apenas de um número visível para o time.

E os apontamentos da IA (métrica 5)?

Aqui aparece uma armadilha nova. Times que ligaram CodeRabbit ou Claude review costumam olhar só a métrica 5 (“taxa de resolução de IA”), e pulam a métrica 3. O raciocínio: “A IA está comentando por nós, então a métrica 3 não conta”. Não é bem assim.

A IA pega o que é autoFixable — bem cortado pelo padrão autoFixable, que eu descrevi em outro post. O que sobra para o humano é justamente a parte não trivial: arquitetura, N+1, nome de função, regra de negócio. Se a IA está comentando 8 coisas por PR e o humano está comentando 0, você ainda tem o problema da métrica 3. Só que agora ele está mascarado.

Meta razoável: IA + humano combinados na faixa de 6–12 comentários, com pelo menos 2 vindo do humano. Se o humano zerou, é porque a IA virou o revisor de fato. Isso pode ser aceitável (times pequenos, PRs enxutos), mas você tem que decidir que aceita. Não pode virar padrão silencioso.

Como as 5 métricas conversam entre si

Uma métrica sozinha engana. As cinco juntas contam a história de verdade.

• Time to First Review baixo + Comentários por PR baixo + Ciclos alto = revisor está tacando aprovação e depois voltando aos poucos
• Time to Merge alto + Comentários alto = PRs grandes demais, precisa cortar
• Comentários por PR baixo + Taxa de IA alta = humano largou, IA virou o dono da revisão
• Time to First Review alto + Comentários por PR médio = time saudável, só falta priorizar PR

Você não corrige com discurso (“pessoal, comentem mais nos PRs”). Corrige com regra no AGENTS.md do repositório e com PR menor. As camadas de review que a PLAID descreveu para sustentar 4x mais PRs num time pequeno mostram o mesmo mecanismo: quando a métrica 4 (ciclos) cai, o volume sobe sem estourar o revisor.

Fechando

• 0 comentário por PR não é aprovação. É a assinatura de que ninguém leu
• As 5 métricas se leem em conjunto. Uma sozinha mente sempre
• A zona sadia de comentários por PR é 6–12 (IA + humano), com pelo menos 2 vindos do humano
• Meça a distribuição, não a média. Média 10 pode ser 5 PRs de 0 + 5 PRs de 20, o que é péssimo
• Um GitHub Action de 30 linhas resolve a coleta. Não precisa de ferramenta paga

Eu passei anos achando que “aprovado rápido, sem comentário” era o troféu. Era o oposto. Foi só quando comecei a olhar a métrica 3 que a saúde da revisão parou de ser palpite.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews