A Cockroach Labs Audita o Revisor Antes do Merge. Copie o Gate Antes de Ligar o Auto-Merge

Entre 21 de abril e 11 de setembro, um pipeline de agentes da Cockroach Labs fez merge de 1.238 pull requests em um repositório espelho usado como campo de provas. Depois da primeira semana de operação autônoma, os autores ligaram o que chamam de “human approval mode”, e só nesse modo conseguiram ter certeza de que o código tinha qualidade para ir aos clientes. Sete desses PRs foram revertidos depois. 92 issues foram escaladas até o Chief humano. A conta de tokens passou de US$ 135.000, o que os autores calculam em cerca de US$ 84 por issue do GitHub.

Os números vêm de um texto de Adam Storm e Rafi Shamim sobre cinco meses rodando bugs por um pipeline inspirado em um hospital. As issues são pacientes. Os agentes formam a equipe médica. No topo fica um humano, o Chief. A parte que interessa é a última estação antes do merge, que eles chamam de Discharge Nurse (a enfermeira da alta).

Essa estação faz algo que raramente vemos em pipelines de agentes. Nas palavras dos autores, “a Discharge Nurse audita o revisor. O último gate antes do merge não revisa o código de novo. Ele verifica se a revisão aconteceu do jeito certo.”

Já escrevemos sobre times que revisam menos por design e sobre a capacidade de verificação como restrição. Este texto parte dali. Se a revisão vai ser feita por agentes, em volume, o controle necessário é a evidência de que a revisão aconteceu e convergiu. Tiramos do texto da Cockroach três artefatos que, na nossa leitura, produzem essa evidência, e dois outros praticantes explicam por que o primeiro importa e como chegar lá.

Um gate que confere a revisão e deixa o código para os revisores

Uma segunda revisão de código feita por outro agente acrescenta mais uma opinião. Uma auditoria da revisão faz outra pergunta: o processo que deveria rodar rodou mesmo? Os revisores obrigatórios estavam lá? Os achados bloqueantes foram respondidos? O loop terminou porque o trabalho convergiu ou porque algo desistiu?

Na nossa leitura, essa pergunta é mais difícil de falsificar do que uma revisão nova, e uma checagem determinística consegue verificar boa parte dela. Um modelo consegue produzir uma aprovação plausível para um código que mal leu. Produzir uma trilha completa e coerente de achados resolvidos e aprovações registradas é uma barra muito mais alta.

Os autores da Cockroach definiram o próprio critério de sucesso no mesmo espírito. A pergunta que importava para eles não era quantos PRs por hora, e sim quantos daqueles PRs os teriam envergonhado se eles mesmos tivessem feito o merge. Um indicador parcial nos dados deles são sete reversões entre 1.238 PRs com merge. Duas ressalvas valem aqui. Os números vêm de um espelho do repositório usado como campo de provas, separado do repositório principal do CockroachDB, e uma reversão é um sinal atrasado e parcial de constrangimento. O texto também traz uma rodada separada no Db2 com números chamativos de velocidade e custo. Os autores dizem que não estavam revisando nada daquele código e ainda estão confirmando a correção, então deixamos esses números de fora.

Por que a revisão de outro agente prova menos do que parece

Cindy Sridharan, escrevendo sobre depurar código que você já não entende, dá a explicação mais clara de por que empilhar revisores adversariais não entrega o que os times esperam. O veredito dela sobre revisão adversarial: uma revisão adversarial não merece confiança como instrumento de verificação e funciona melhor como instrumento de eliminação.

Eliminar ainda vale a pena. Em um dos incidentes dela, cerca de um terço das afirmações que ela contestou não tinha citação que as sustentasse e foi descartado. É uma limpeza real. Só que uma contestação que remove afirmações sem suporte deixa as sobreviventes sem prova. Outra coisa precisa confirmá-las, como um teste ou um humano. Os números dela vêm de um conjunto pequeno de bugs próprios e devem ser lidos como o relato de uma praticante, e, num trecho, ela mesma alerta contra tirar conclusões demais de um único exemplo.

Ela também propõe uma métrica que, para nós, deveria estar no painel de todo pipeline de agentes. Segundo Sridharan, o número de intervenções humanas por bug é a medida mais honesta de quão nativa em agentes uma fábrica de software realmente é.

A Cockroach Labs publica um insumo dessa medida: no período, 92 issues chegaram ao Chief humano. Essa contagem deixa de fora as aprovações humanas dos merges, então serve só como piso para essa medida. Não vamos calcular uma razão a partir dela. O que importa é que a contagem existe, e um pipeline que conta suas escaladas já começou a medir isso.

O log de precedentes que só um humano escreve

O segundo artefato, na nossa leitura do texto, é um log de precedentes que só um humano pode escrever. Registramos aqui como lemos o princípio: quando um humano resolve um caso ambíguo, a decisão vira precedente, e os agentes podem usá-la sem poder alterá-la.

Isso importa porque a alternativa é deriva. Um agente que escreve os próprios precedentes pode, ao longo de muitas rodadas, reescrever o padrão pelo qual é julgado. Cada mudança parece razoável isoladamente. O efeito acumulado é uma régua de revisão definida por quem está sendo revisado. Um log com escrita restrita a humanos transforma cada decisão de julgamento em algo auditável, com dono, e mantém a definição de “aceitável” com as pessoas enquanto o volume de trabalho fica com os agentes.

O mesmo time auditou também as próprias instruções. Em julho, revisou 25 arquivos de skill que somavam pouco mais de 100.000 palavras e marcou cerca de 23.000 palavras, uns 23%, como removíveis. Texto de instrução acumula do mesmo jeito que precedente. Alguém precisa ser dono da poda, e esse alguém deve ter a autoridade que os agentes não têm.

A regra escrita de quando parar

O terceiro artefato é um disjuntor. A Cockroach Labs passa um PR adiante quando ele acumula quatro rodadas consecutivas de retrabalho em que cada uma trouxe um novo achado bloqueante, ou seis rodadas substantivas de qualquer tipo.

Duas coisas tornam essa regra útil. Ela está escrita, com números, antes de o loop começar. E ela separa um loop que está convergindo (os achados diminuem) de um que está girando em falso (cada rodada traz algo novo e bloqueante). Sem uma regra assim, um loop de revisão entre agentes tem dois modos de falha: roda indefinidamente queimando tokens, ou termina quando o revisor cansa de achar coisas, o que nos logs fica idêntico a convergência.

Os autores admitem que a regra entrou há pouco tempo e que não têm bons dados sobre a eficácia dela. Lemos isso como motivo para adotá-la e instrumentá-la agora, sem esperar. Uma condição de parada escrita e medida é evidência melhor do que uma informal que você não consegue medir.

Codifique a revisão antes de automatizar a aprovação

Swizec Teller, escrevendo a partir de uma organização de engenharia com 21 pessoas, mostra onde isso chega na prática. O time dele aprova e faz merge automático de 16% de todos os pull requests. O caminho até ali passou por algumas dezenas de linters customizados, que codificam julgamentos de revisão em checagens que rodam sempre do mesmo jeito. O time também rejeita metade dos comentários que o BugBot faz, então até a saída de um bot de revisão ainda passa por filtro humano.

A ordem é a lição. O time do Swizec transformou julgamentos recorrentes de revisão em checagens determinísticas primeiro e só depois deixou uma fatia limitada de PRs entrar com base nelas. Os números são dele, de operação, sem método publicado, e uma organização com 21 pessoas não serve de molde para toda empresa. A sequência se transfere mesmo assim: a aprovação automática se conquista tornando a revisão legível para uma máquina.

Isso se liga a um argumento que já fizemos sobre técnica de teste no prompt. Uma instrução ao agente orienta. Uma checagem que roda independentemente do que o agente decidiu é controle. Um linter é controle. Uma auditoria da trilha de revisão é controle. Um lembrete no prompt de sistema para “revisar com cuidado” é orientação, como qualquer outra instrução.

Faça isto agora

Se agentes já revisam código na sua organização, ou se você pretende ligar o auto-merge neste trimestre, coloque três artefatos no lugar antes. A Cockroach ligou o human approval mode depois da primeira semana. O gate de auditoria é o que exigiríamos antes de desligar esse modo.

Uma auditoria da revisão antes do merge. Defina como é uma trilha de revisão completa no seu repositório: quais revisores, quais achados precisam estar resolvidos, quais aprovações registradas. Adicione um gate que barra o merge quando a trilha está incompleta. Ele dispensa a leitura do diff.
Um log de precedentes com escrita só para humanos. Toda decisão escalada é registrada pelo humano que a tomou. Os agentes leem. Garanta a restrição de escrita com permissões de acesso, sem depender de instrução.
Uma regra escrita de parada do loop, com números. Comece pelas quatro rodadas consecutivas com novos achados bloqueantes, ou seis rodadas substantivas no total, da Cockroach, e ajuste com os seus dados. Registre cada vez que o disjuntor dispara.

Depois acompanhe as intervenções humanas por issue, como sugere Sridharan, e conte as reversões de PRs de agentes já com merge. Esses dois números dizem mais sobre a confiabilidade do seu pipeline do que qualquer gráfico de vazão.

Fontes

Cockroach Labs. “Five months treating bugs like patients and coding agents like a medical team.” Outubro de 2026.
Cindy Sridharan. “How to effectively debug when you no longer understand the code.” Outubro de 2026.
Swizec Teller. “When code is cheap, judgement becomes the job.” Outubro de 2026.

A Victorino ajuda times de engenharia a implantar gates de auditoria e regras de parada que tornam o auto-merge de agentes defensável: contato@victorino.com.br | www.victorino.com.br