Voltar para as novidades

Quanto código de agente de IA você tem de revisar de verdade?

Resposta curta: em três semanas de um repositório onde agentes de IA escrevem quase toda linha, 88 commits mudaram 35.492 linhas. O commit mediano teve 85 linhas, pequeno o bastante para ler no café, mas 7 commits, 8% deles, carregaram metade do total, e um único dia entregou 12.679 linhas em 105 arquivos. A carga de revisão de agentes de IA não chega como fluxo, chega em rajada, então planeje o dia pelo pico e não pela média.

Quanto código de agente de IA chega em três semanas?

No repositório por trás do CanvasCode, onde agentes de IA de programação escrevem quase toda linha e um humano revisa antes de qualquer merge, três semanas produziram 88 commits e 35.492 linhas alteradas, somando inserções e remoções. Esses 88 são os commits que introduzem linha: o período tem ainda 27 commits de merge, para os quais o git não reporta estatística de linha, porque eles não carregam mudança própria. Essa é a carga bruta de revisão, e cada uma daquelas linhas precisou passar pelos olhos de alguém antes de chegar na branch principal.

O número que nos surpreendeu não foi o total, foi o calendário. De 21 dias, apenas 10 tiveram algum commit. Os outros 11 não produziram nada para revisar, ou seja, o trabalho não se espalhou pelo período. Ele se empilhou em um terço dos dias e deixou o resto vazio. Uma média de 1.690 linhas por dia é aritmeticamente verdadeira e não descreve nenhum dia que aconteceu de fato.

Por que a mediana engana sobre a carga de revisão de IA?

O commit mediano nessas três semanas mudou 85 linhas. Mediana aqui é o valor do meio depois de ordenar todos os commits por tamanho, e com número par de commits é a média dos dois centrais, 85,5, que o comando abaixo imprime como 85. Lido sozinho, esse número diz que revisar é fácil: 85 linhas são alguns minutos de atenção.

A distribuição diz outra coisa. Ordenando os mesmos 88 commits do maior para o menor, 7 deles carregam metade de todas as 35.492 linhas. O maior commit sozinho mudou 4.007 linhas. Ou seja, o commit típico é pequeno e a carga não é, porque a carga mora na cauda. Todo planejamento construído sobre a mediana, do tipo reservar meia hora por dia para revisar o que os agentes de IA produziram, sobrevive na maioria dos dias e desmorona justamente nos dias que importam.

Como é um dia de pico de saída de agente de IA?

O pior dia da janela, 7 de agosto de 2026, entregou 25 commits e 12.679 linhas alteradas tocando 105 arquivos distintos. São 36% de três semanas de produção chegando dentro de um dia só. O primeiro commit caiu às 12h51 e o último às 23h23, dez horas e meia depois, então também não foi uma sentada: o dia foi um gotejar constante que somou uma enchente.

Esse é o formato que quebra a revisão, e ele quebra de um jeito específico. Quem revisa 12.679 linhas não consegue aplicar o mesmo cuidado na linha 12.000 e na linha 100. Os desfechos realistas são aprovar em bloco, o que anula a revisão, ou parar os agentes enquanto você se recupera, o que anula o paralelismo que você montou. Nenhum dos dois é problema de técnica, e nenhum melhora lendo mais rápido.

Como medir a carga de revisão no seu próprio repositório?

Dois comandos, git puro e awk POSIX, sem ferramenta extra. Eles somam inserções e remoções, porque linha apagada também precisa ser lida antes de você concordar que ela deve sair. O primeiro imprime o total, a mediana e o quanto a carga está concentrada. Rode dentro de qualquer repositório:

git log --since=3.weeks --pretty=tformat:'C' --shortstat |
awk '/files? changed/{
  ins=0; del=0
  for (i=1; i<=NF; i++) {
    if ($(i+1) ~ /^insertion/) ins=$i
    if ($(i+1) ~ /^deletion/)  del=$i
  }
  print ins+del
}' | sort -rn | awk '{ t+=$1; a[NR]=$1 }
END {
  half=t/2; s=0
  for (i=1; i<=NR; i++) { s+=a[i]; if (s>=half) break }
  printf "%d commits, %d lines changed\n", NR, t
  printf "median %d lines per commit\n", (NR%2 ? a[(NR+1)/2] : (a[NR/2]+a[NR/2+1])/2)
  printf "%d commits (%.0f%%) carry half of that\n", i, i*100/NR
}'

No nosso repositório ele imprime:

88 commits, 35492 lines changed
median 85 lines per commit
7 commits (8%) carry half of that

Essa saída é a nossa em 13 de agosto de 2026. A janela é relativa, então o mesmo comando rodado em outro dia cobre outras três semanas: compare com o seu número, não com o que está impresso acima. O segundo comando mostra o calendário, que é onde a rajada fica visível:

git log --since=3.weeks --pretty=tformat:'C %ad' --date=format:'%Y-%m-%d' --shortstat |
awk '/^C /{ d=$2; next }
     /files? changed/{
       ins=0; del=0
       for (i=1; i<=NF; i++) {
         if ($(i+1) ~ /^insertion/) ins=$i
         if ($(i+1) ~ /^deletion/)  del=$i
       }
       n[d]++; L[d]+=ins+del
     }
     END { for (d in L) printf "%s  %3d commits  %6d lines\n", d, n[d], L[d] }' | sort

Se a sua saída tiver poucos dias enormes e muitos dias vazios, o seu problema de revisão é de agenda, não de técnica.

A rajada muda o jeito de revisar?

Ela muda o que você faz antes de revisar, não a revisão em si. A ordem que usamos para ler saída de agente de IA é a mesma no dia calmo e no dia de pico: começar pelo que não deveria ter mudado, depois procurar o teste que falharia se aquilo estivesse errado, e só então ler o código. Esse método é outro artigo, como revisar código escrito por vários agentes de IA, e este aqui de propósito não o repete.

A fronteira entre os dois merece ser dita com todas as letras, porque eles respondem perguntas diferentes. Aquele artigo responde como revisar uma entrega de agente de IA. Este responde quanto chega e quando, que é pergunta de capacidade. Método nenhum salva você de um dia de 12.679 linhas. Só mudar a chegada salva.

Dá para suavizar a rajada em vez de absorver?

Três coisas mexem na chegada, e nenhuma delas é revisar mais rápido. A primeira é pedir entregas menores por frente, que é a única alavanca sob controle direto de quem revisa. A segunda é um portão de máquina antes do humano: testes, formatador e análise estática rodando em cada frente, para que o que chega numa pessoa já se saiba que compila e passa. No nosso repositório nada chega à revisão sem esse portão, e é por isso que o dia de pico foi sobrevivível.

A terceira é sequenciar os merges em vez de deixar as frentes terminarem juntas, que é o mesmo problema descrito em como integrar o trabalho de vários agentes de IA. Frentes que caem ao mesmo tempo produzem rajada mesmo quando cada uma era razoável sozinha. Escalonar transforma um dia irrevisável em três dias revisáveis.

Onde isso foi medido, e o que isso não prova

Um repositório, três semanas, medido em 13 de agosto de 2026, numa aplicação web Laravel onde agentes de IA escrevem conteúdo e funcionalidades sob portão humano. É amostra pequena e um tipo específico de projeto. A sua distribuição vai ser diferente, e os comandos acima existem para você conferir a sua em vez de confiar na nossa.

Dois limites que conhecemos. Primeiro, cinco dos 88 commits não têm marcador de sessão, então qualquer leitura por sessão desses dados está incompleta; os números deste artigo contam todo commit sem merge e não dependem daquele marcador. Segundo, linha alterada é aproximação do esforço de revisão, não medida dele: 500 linhas de uma migration gerada se leem mais rápido que 50 linhas de regra de negócio. A rajada é real, mas o custo exato de uma linha não é coisa que esta medição resolva.