Tenho pensado bastante sobre como o code review pode mudar à medida que a programação agêntica se torna parte normal do desenvolvimento de software.

Não tenho uma resposta definitiva — e desconfio de quem diz ter. Estamos ainda no começo dessa transição, e provavelmente vamos errar bastante antes de entender quais práticas realmente funcionam, quais precisam ser adaptadas e quais simplesmente deixam de fazer sentido.

O que quero compartilhar aqui é uma tese. Ela nasce de experiência prática, de algumas ideias que venho acumulando há anos sobre revisão de código e de uma percepção recente: talvez a IA não precise substituir o reviewer para transformar profundamente a maneira como revisamos software.

A metáfora do título vem da Bíblia: “coar o mosquito e engolir o camelo” descreve a situação em que somos rigorosos com detalhes pequenos, mas deixamos passar algo muito maior. Em code review, a comparação é quase inevitável: um diff de cinco linhas pode receber dez comentários; um de mil linhas, às vezes, recebe apenas “LGTM”.

Essa piada é engraçada porque reconhecemos nela um comportamento real.

Quanto menor o PR, mais fácil é discutir nomes, detalhes de implementação, pequenas otimizações e decisões locais. Quanto maior o PR, maior é o esforço necessário apenas para reconstruir mentalmente o que está acontecendo. Em algum momento, a profundidade da análise passa a ser limitada não pelo risco da mudança, mas pela capacidade cognitiva de quem revisa.

Com programação agêntica, esse desequilíbrio tende a ficar mais evidente.

Produzir código está ficando mais barato. Revisá-lo não.

Ferramentas baseadas em LLM já conseguem escrever funcionalidades, testes, migrations, integrações, refatorações e correções em uma velocidade que seria difícil imaginar poucos anos atrás.

Isso não significa que todo esse código seja bom. Significa apenas que o custo marginal de produzi-lo está caindo rapidamente.

A capacidade humana de revisão, por outro lado, continua essencialmente limitada pelas mesmas coisas de sempre: tempo, atenção, conhecimento do domínio, familiaridade com a codebase e capacidade de manter contexto suficiente na memória.

Se antes um desenvolvedor produzia uma quantidade de código que outro conseguia razoavelmente acompanhar, agentes podem alterar essa proporção de forma importante.

A solução provavelmente não pode ser apenas pedir que reviewers leiam mais código, mais rápido e com a mesma profundidade.

Também não me parece prudente concluir que devemos simplesmente remover a revisão humana.

Minha hipótese está em algum lugar no meio.

Talvez o reviewer precise subir um nível de abstração

Grande parte do code review tradicional começa pelo diff.

Abrimos o Pull Request, percorremos os arquivos e passamos a observar detalhes:

  • esse nome poderia ser mais claro;
  • esse loop pode estar fazendo trabalho desnecessário;
  • esse ToList() talvez esteja materializando dados cedo demais;
  • essa condição está duplicada;
  • esse método está crescendo demais;
  • esse tratamento de erro parece incompleto.

Todos esses comentários podem ser válidos.

Mas eles compartilham uma característica: estão muito próximos da implementação.

Há outras perguntas que podem ser ainda mais importantes:

  • Este PR está realmente fazendo o que foi solicitado?
  • Há acceptance criteria sem implementação aparente?
  • O diff contém mudanças que ultrapassam o escopo declarado?
  • Uma regra que antes tinha um único ponto de autoridade agora está sendo replicada?
  • Uma responsabilidade está migrando para uma camada que não deveria conhecê-la?
  • Esta mudança aumenta o raio de futuras alterações?
  • Estamos introduzindo uma exceção estrutural que tende a se repetir?
  • O comportamento mudou em uma área que o ticket ou a descrição do MR não mencionam?

Essas perguntas não são necessariamente mais difíceis porque exigem mais conhecimento de sintaxe ou framework.

Elas são mais difíceis porque exigem contexto.

E talvez seja exatamente aí que a IA tenha uma contribuição particularmente útil.

Code review como observação de sinais

Tenho pensado no Pull Request como algo que produz sinais em diferentes dimensões.

Algumas mudanças podem apresentar sinais sobre intenção e alinhamento. Outras sobre longevidade, acoplamento, testabilidade, complexidade, segurança ou outras propriedades relevantes para aquela codebase.

Não imagino esses sinais como uma pontuação absoluta de qualidade.

Prefiro algo mais próximo de uma classificação qualitativa:

  • Unknown — não há evidência ou contexto suficiente para avaliar;
  • Weak — há evidência concreta de risco ou degradação naquela dimensão;
  • Adequate — o contexto é suficiente e não há evidência material de problema;
  • Strong — há evidência positiva de que a mudança preserva ou melhora aquela propriedade.

A classificação, sozinha, não deveria bastar.

Ela precisa vir acompanhada de uma justificativa verificável: onde o sinal foi observado, qual evidência o sustenta e por que aquilo pode importar.

Por exemplo:

Intention & Alignment — Weak
O ticket exige a publicação de um evento após determinada ação, mas nenhuma implementação correspondente aparece no diff.

Ou:

Longevity — Weak
O PR introduz uma segunda implementação de uma regra que antes estava centralizada, aumentando a chance de futuras alterações precisarem ser sincronizadas em múltiplos pontos.

O objetivo não é transformar opinião arquitetural em autoridade algorítmica.

É tornar explícito aquilo que merece atenção humana.

O reviewer não sai do código. Ele ganha zoom variável.

Talvez a melhor forma de explicar essa ideia seja pensar em instrumentação.

Um piloto não precisa observar diretamente cada componente do motor durante todo o voo. Ele possui instrumentos que tornam determinados estados visíveis.

Quando tudo parece normal, consegue operar em um nível mais alto.

Quando um indicador chama atenção, aprofunda a investigação.

Vejo potencial para algo semelhante no code review.

Em vez de começar obrigatoriamente por uma leitura linear e uniforme de todas as linhas do diff, o reviewer poderia começar por uma visão mais ampla:

  • intenção;
  • comportamento;
  • risco;
  • impacto estrutural;
  • alinhamento com o solicitado.

Um sinal chama atenção.

O reviewer então aprofunda:

sinal → rationale → evidência → arquivo → método → linha de código

O humano continua com acesso ao código e continua responsável pelo julgamento.

A diferença é que passa a ter uma espécie de visão aumentada sobre onde vale investir profundidade cognitiva.

Não se trata de tirar o reviewer do código.

Trata-se de dar a ele zoom variável.

Guardrails antes e depois da implementação

Programação agêntica também torna mais importante pensar em controles em diferentes momentos do processo.

Antes da implementação, instruções de repositório, convenções, arquitetura, padrões e arquivos como AGENTS.md podem orientar agentes sobre como trabalhar naquela codebase e, igualmente importante, sobre o que não fazer.

Esses são guardrails preventivos.

Mas orientação não garante resultado.

Depois da implementação, uma análise independente pode observar aquilo que efetivamente apareceu no diff, preferencialmente sem depender da narrativa e do contexto carregados pelo agente que escreveu a mudança.

São funções diferentes:

antes: como esperamos que a mudança seja construída;

depois: o que realmente foi construído e que sinais isso produz.

E então entra o humano.

Aceitar. Recusar. Investigar. Comentar. Aceitar um trade-off conscientemente. Pedir refatoração.

A IA pode ajudar a enxergar.

A decisão continua sendo uma responsabilidade de engenharia.

De checklist a sinais

Essa forma de pensar não surgiu para mim com LLMs.

Há anos eu mantinha anotações informais sobre coisas que não queria esquecer durante desenvolvimento e revisão: acessibilidade, usabilidade, valores default, feature flags, impacto de privacidade, decisões que poderiam afetar outras partes do sistema e outras preocupações recorrentes.

Nunca chegaram a formar um checklist público ou um framework completo.

Mas elas me ensinaram algo: boa parte da engenharia consiste em lembrar de fazer as perguntas certas no momento certo.

Mais tarde, ao ler The Pragmatic Programmer, encontrei várias dessas preocupações expressas de maneira muito mais madura em princípios como ortogonalidade, DRY, reversibilidade, contratos, feedback e combate à entropia do software.

A novidade que vejo agora não é a existência dessas preocupações.

É a possibilidade de usar IA para ajudar a observá-las sistematicamente em uma mudança concreta, sem depender exclusivamente da memória e da atenção do reviewer.

Não precisamos revisar menos. Talvez precisemos revisar em outra altitude.

Há uma velha tendência em code review: quanto mais fácil é entender a mudança, mais profundamente conseguimos analisá-la.

Isso cria um paradoxo.

PRs pequenos recebem escrutínio intenso justamente porque são pequenos o suficiente para permitir escrutínio intenso.

PRs grandes, que potencialmente carregam mais risco, podem receber uma análise proporcionalmente mais superficial.

Na era da programação agêntica, essa assimetria tende a ficar mais difícil de ignorar.

Minha hipótese é que o futuro do code review não está em abandonar o humano e nem em tentar preservar exatamente o mesmo processo enquanto o volume de código cresce.

Talvez esteja em mudar a altitude da revisão.

A IA pode ajudar a expor sinais de intenção, risco, comportamento e impacto estrutural.

O reviewer pode começar mais acima e aprofundar quando alguma coisa merece atenção.

O objetivo não é terceirizar julgamento para uma máquina.

É tornar sinais importantes de engenharia mais difíceis de passar despercebidos.

Não sei se esse será o modelo dominante de code review daqui a alguns anos. Talvez surjam abordagens melhores. Talvez parte dessas ideias se mostre errada. Estamos todos aprendendo enquanto as ferramentas e os processos mudam.

Mas me parece cada vez mais difícil imaginar que continuaremos revisando código exatamente da mesma forma enquanto a maneira de produzi-lo muda tão profundamente.

Nos próximos textos, quero explorar algumas dessas dimensões individualmente: o que cada sinal tenta observar, que tipo de evidência pode sustentar uma classificação, onde a IA pode errar e qual deveria continuar sendo o papel do julgamento humano.

Porque talvez o desafio não seja ensinar a IA a dar LGTM.

Talvez seja garantir que nós não continuemos engolindo o camelo.