O time de Ankit Jain na Aviator faz merge de quatro vezes mais pull requests do que fazia um ano atrás. Quase nenhuma linha desse código foi digitada por um humano. O time tentou as correções óbvias: ferramentas de revisão com IA, checklists mais rígidos, mais revisores. Nenhuma funcionou. A revisão continuou sendo a etapa mais lenta do fluxo de entrega.
O que funcionou foi abandonar a leitura linha a linha e construir uma camada de verificação ao redor da intenção.
O framework que Jain descreve tem cinco passos. Três são mudanças estruturais no processo de revisão. Dois são decisões organizacionais sobre quem é dono das regras. A combinação transforma a revisão de código de um exercício de leitura em um veredito baseado em evidências.
Mover o Julgamento Humano Para a Frente
A revisão convencional coloca a atenção humana no final. Alguém lê 400 linhas, tenta reconstruir o que a mudança deveria fazer e decide se parece correto. Com quatro vezes o volume, o revisor depende de uma descrição de ticket que só ajuda se o time mantém bons tickets. A maioria dos times não mantém.
O time de Jain moveu o julgamento humano para a frente. Antes de uma única linha ser gerada, eles revisam a intenção: critérios de aceite, restrições, casos de borda. A atenção de um engenheiro sênior vale mais nesse ponto, porque uma ideia errada custa quase nada para corrigir antes de o código existir.
Depois, tratam essa intenção como um contrato. Cada critério de aceite recebe um veredito determinístico com evidência anexada. O revisor vê cinco vereditos de critérios com screenshots e traces de requisições. Sem diff de 500 linhas.
O princípio é direto. Se você não consegue dizer o que uma mudança deveria fazer antes de ela existir, lê-la depois também não vai dizer.
Minere Seus Comentários de Revisão
Todo time tem padrões que moram na cabeça de engenheiros seniores. Esses padrões são aplicados um comentário de revisão por vez. Olhe o histórico de revisão de qualquer time e você vai encontrar os mesmos comentários repetidos várias vezes: use o tipo Money para qualquer coisa com moeda, nada de escrita direta na tabela de usuários, apenas logger estruturado.
Com 4x o volume de PRs, repetir esses comentários manualmente vira um gargalo próprio. O time de Jain revisou seus comentários recorrentes e os transformou em invariantes: regras reutilizáveis que uma máquina aplica em toda mudança.
O ponto de partida é concreto. Minere seus últimos 1.000 comentários de revisão. Os 20 que você mais repete são suas primeiras invariantes. Você não está inventando regras. Está escrevendo as que já existem.
Uma boa invariante é tediosa e específica. “Use o tipo Money para qualquer coisa com moeda” qualifica. “Escreva código limpo” não.
Os Cinco Passos
As duas práticas acima se encaixam em um framework de cinco passos que Jain chama de Argue, Capture, Codify, Debate, Own:
- Argue. Deixe agentes desafiarem as soluções uns dos outros antes de o pull request existir, quando mudar de direção é mais barato.
- Capture. Registre a intenção e os critérios de aceite. Coloque-os no pull request.
- Codify. Transforme os comentários que seu time repete em invariantes.
- Debate. Gaste o tempo de revisão humana nas decisões, não no diff.
- Own. Decida quem é dono das regras que verificam o código.
Os passos 1 a 3 são estruturais. Mudam o que é revisado e como. Os passos 4 e 5 são organizacionais. Mudam quem revisa e quem mantém a camada de verificação.
A Linha do Tempo É Honesta
Jain é direto sobre o custo de transição. O mês um vai parecer trabalho dobrado: o time revisa código e constrói invariantes ao mesmo tempo. No mês dois, o registro captura o suficiente e as revisões encolhem. No mês três, o revisor lê intenção, não código.
Essa rampa de três meses merece destaque porque a maioria das mudanças de processo promete retorno imediato. Esta promete um mês pior antes de um melhor. O investimento está em construir um registro de regras que se compõe ao longo do tempo.
A Pergunta Que Fica
O framework tem um passo que a maioria dos times vai pular: Own. Quem mantém as invariantes? Quem decide quando uma regra está errada? Quem atualiza o registro quando o codebase muda?
Se invariantes são padrões de time escritos formalmente, eles precisam da mesma governança que qualquer outro padrão. Alguém precisa ser dono do registro da mesma forma que alguém é dono da suíte de testes. Sem essa propriedade, as invariantes divergem, a camada de verificação enferruja, e o time volta a ler diffs.
Já escrevemos sobre a camada de intenção como superfície emergente de governança. O framework de Jain adiciona a mecânica prática: os cinco passos, a linha do tempo, e a questão específica de propriedade que determina se a camada se sustenta.
A semente é pequena. Puxe seus últimos 1.000 comentários de revisão. Encontre os 20 que se repetem. Escreva-os como invariantes. O registro começa aí.
Fontes
- Jain, Ankit. “We Stopped Reviewing Code and Started Verifying Intent.” Aviator/Tessl, Outubro de 2026.
A Victorino ajuda equipes a migrar revisão de código de leitura de diffs para verificação de intenção. contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa