Seu Code Review É Um Controle Fazendo Cinco Trabalhos

“Why are we waiting until code review to do all of those things?” Por que estamos esperando até o code review para fazer todas essas coisas?

A pergunta é de Rachel Laycock, CTO da Thoughtworks, e resume o texto que ela publicou em 2 de setembro de 2026. A parte que merece atenção é o “todas essas coisas”. À medida que a prática amadureceu, o code review absorveu em silêncio cinco trabalhos distintos: encontrar bugs, transferir conhecimento pelo time, mentorar engenheiros juniores, manter a arquitetura alinhada e atribuir a responsabilidade sobre o que sobe para produção.

No volume de autoria humana, um único portão conseguia carregar os cinco de forma medíocre sem que ninguém percebesse, porque a fila era curta o bastante para a mediocridade não se acumular. Esse volume acabou. Laycock cita Brian Houck, da DX, para descrever a mudança: na Meta, as linhas de código significativas por diff entregue por humano teriam aumentado 106% em um ano, e os dados da própria DX mostram o tamanho mediano de pull request crescendo 64%. Os dois números são de segunda mão no texto dela. Ela está citando Houck, e não reportando medições próprias, distinção que importa se você pretende colocar qualquer um dos dois em um slide.

Trate os números como direcionais em vez de precisos e o ponto estrutural sobrevive de qualquer maneira. Onde esses números valem, o mesmo checkpoint passa a receber um diff substancialmente maior pela mesma unidade de atenção humana, e a resposta organizacional padrão é revisar com mais rigor. Revisar com mais rigor deixa o checkpoint mais lento sem melhorar nenhum dos cinco trabalhos.

Os Cinco Trabalhos, Nomeados Separadamente

Já escrevemos que ninguém consegue matar o code review, apenas renomear a governança, e que a camada de revisão vira o gargalo que ela deveria resolver. A contribuição de Laycock é parar de tratar o portão como uma coisa só. Depois que os cinco trabalhos são nomeados separadamente, fica evidente que eles quase não têm nada em comum além de dividirem o mesmo espaço na agenda.

Encontrar bugs. Uma leitura em formato de diff, feita por uma pessoa cansada, depois que o código já existe, é um detector fraco. Testes, análise estática e varredura de segurança rodam a cada commit e não se cansam.

Transferir conhecimento. Ler o diff pronto de outra pessoa transfere a mudança, sem o raciocínio que a produziu. Esse raciocínio já evaporou quando o pull request abre.

Mentorar. Comentários assíncronos em um diff são um meio ruim de ensinar. O engenheiro júnior recebe correções sem o contexto que permitiria generalizá-las.

Alinhar arquitetura. Na hora da revisão, a decisão arquitetural já foi tomada e implementada. Objetar sai caro, então os revisores geralmente não objetam.

Atribuir responsabilidade. O carimbo de aprovação registra quem responde pelo que subiu. Esse é o único trabalho que o portão de fato executa, e ele é administrativo.

Quatro desses cinco acontecem no pior momento possível: depois que o trabalho terminou, por um único revisor, em texto.

Para Onde Cada Trabalho Vai

A redistribuição proposta por Laycock é específica. Pareamento e mob programming assumem a transferência de conhecimento e a mentoria, porque os dois funcionam em tempo real, enquanto o raciocínio ainda está vivo e perguntar não custa nada. Sessões coletivas de desenho em quadro branco assumem o alinhamento arquitetural, realizadas antes da implementação em vez de depois, quando mudar o desenho ainda é barato. Trunk-based development mantém os incrementos pequenos o suficiente para que a pergunta da revisão continue respondível. Testes automatizados, análise estática e fitness functions assumem a garantia das restrições arquiteturais, rodando continuamente em vez de dependerem da memória de quem calhou de revisar. Linting automatizado e varredura de segurança assumem formatação e classes de problemas conhecidos, onde nenhum humano deveria gastar atenção em 2026.

Nenhuma dessas práticas é nova. O que mudou foi a aritmética que tornava ignorá-las sustentável. Um time podia pular o pareamento e absorver o custo de conhecimento quando um humano escrevia cada linha, porque esse humano retinha o raciocínio. Quando agentes produzem parte substancial da implementação, essa retenção deixa de acontecer por padrão. Laycock enuncia a exigência de forma direta: “If agents are going to produce substantially more of the implementation, we need to be much more deliberate about maintaining human understanding…”

A frase mais afiada dela é a que vale levar para a próxima reunião de planejamento: “We need engineers to understand systems, not diffs.” Precisamos de engenheiros que entendam sistemas, não diffs. É a mesma restrição que descrevemos quando dissemos que a compreensão é o gargalo, chegando aqui como instrução de desenho organizacional em vez de diagnóstico.

A Lista de Exceções

Tirar quatro trabalhos do portão não faz a revisão humana desaparecer. Dá escopo a ela. Laycock publica os critérios como uma lista fechada de cinco condições que justificam um humano lendo o código:

Mudanças arquiteturais.
Mudanças que cruzam uma fronteira de segurança.
Mudanças com raio de impacto enorme.
Código em um sistema crítico que o time não conhece bem.
Casos em que o time diz explicitamente que sua confiança está baixa.

O quinto é o mais interessante e o mais fácil de sabotar. Ele só funciona se o time conseguir declarar baixa confiança sem que essa admissão custe capital político a alguém. Onde baixa confiança é lida como fraqueza, ninguém declara, e o critério vira silenciosamente uma lista de quatro itens.

Repare também no que ficou de fora: volume, senioridade do autor e se o código foi escrito por humano ou por agente. Os critérios tratam do risco da mudança, sem considerar a procedência das teclas digitadas. Um time que acrescenta “qualquer coisa que um agente escreveu” como sexto critério não adotou revisão por exceção. Renomeou a revisão universal e deu a ela um rótulo de som permissivo.

Por Que Isso É Mais Governança

O discurso soa como um pedido para revisar menos. Releia a redistribuição e o efeito é o inverso. No modelo atual, um checkpoint carrega cinco obrigações e cumpre a administrativa. Sob revisão por exceção, cinco obrigações ganham cinco mecanismos, quatro deles rodando continuamente em vez de uma única vez no fim.

Isso é mais superfície de controle. Também é mais caro de montar, o que é a razão real pela qual os times não fazem. Pareamento custa agenda. Sessões de desenho em quadro branco custam agenda. Fitness functions custam tempo de engenharia para construir e manter. A revisão por exceção só é barata depois que esses investimentos existem. Adotar a lista de exceções primeiro, sem os quatro destinos, produz exatamente o que os críticos preveem: menos revisão e nada no lugar dela.

É aqui também que o padrão do chicote da aceleração morde. O lado da geração fica mais rápido em uma semana. O lado da verificação precisa de trimestres de mudança de prática para acompanhar. Anunciar revisão por exceção na segunda-feira e construir as fitness functions “depois” inverte a sequência.

Faça Isso Agora

Pegue seus últimos vinte pull requests mergeados e classifique cada um contra os cinco critérios de Laycock. Conte quantos se qualificam. Depois olhe para o que o resto recebeu de revisão humana: o processo exigindo, ou a mudança justificando.

Depois faça a pergunta mais difícil sobre essa maioria: qual dos cinco trabalhos aquela revisão de fato executou? Se a resposta honesta para a maior parte deles for “atribuiu responsabilidade”, você tem um fluxo de assinatura, e está pagando com atenção de engenharia sênior em um momento em que essa atenção é a coisa mais escassa que você tem.

Para cada um dos quatro trabalhos deslocados, nomeie a prática que vai recebê-lo e a data em que ela começa. Destino sem data é intenção, e a fila não vai esperar.

Fontes

Rachel Laycock, CTO da Thoughtworks. “Maybe We Shouldn’t Be Reviewing All This Code.” Setembro de 2026.

A Victorino ajuda organizações de engenharia a redesenhar prática de revisão e verificação para volume de agentes: contato@victorino.com.br | www.victorino.com.br