Code Review: da prática à automação com IA

Code review é a revisão de uma mudança de código antes do merge. Um bom review verifica se o PR resolve o problema proposto, se mantém os padrões da codebase, se cobre os casos importantes com testes e se não cria riscos de segurança, performance ou manutenção.

Na prática, o review costuma travar sempre pelos mesmos motivos: PR grande demais, descrição ruim, revisor sobrecarregado, comentário vago, discussão de preferência pessoal e pouca clareza sobre o que realmente precisa bloquear o merge. Hoje, com IA escrevendo mais código, isso ficou ainda mais problemático.

Já não é novidade que o gargalo saiu um pouco da escrita e foi para a validação.

O próprio relatório do GitLab mostra confirma isso: 85% dos respondentes concordam que IA mudou o gargalo de escrever código para revisar e validar, e 84% dizem que o maior desafio com código gerado por IA é governar o que acontece depois que ele é criado.

Este guia mostra como fazer code review de um jeito mais prático, sem transformar revisão em um ritual pesado e sem jogar tudo na mão de uma ou duas pessoas do time.

Como fazer code review na prática

Um bom code review começa antes de abrir o primeiro arquivo alterado. Se você começa lendo linha por linha sem entender o objetivo do PR, vai gastar energia no lugar errado.

Use este fluxo como base:

1. Entenda o objetivo do PR.
2. Confira se a descrição explica o problema e a solução.
3. Veja os testes antes de entrar na implementação.
4. Revise lógica de negócio, segurança, performance e impacto fora do diff.
5. Comente com contexto, não só com opinião.
6. Aprove quando o código mantém ou melhora a qualidade da codebase.

Esse processo parece simples, mas resolve boa parte dos reviews ruins. Quem revisa deixa de procurar um problema no escuro e passa a avaliar a mudança com um objetivo claro.

O que olhar em um code review

O erro mais comum é tratar code review como leitura de diff. O diff é só a porta de entrada. Às vezes a parte perigosa está no impacto que aquela mudança causa em outro módulo, em uma permissão ou em uma regra de negócio.

A documentação de práticas de engenharia do Google recomenda olhar design, funcionalidade, complexidade, testes, nomes, comentários, estilo, documentação e contexto do sistema.

Na prática, eu olharia nesta ordem.

Objetivo do PR

Antes de revisar o código, entenda o que o PR deveria entregar. Se a descrição está vazia ou só diz “ajustes no fluxo”, peça mais contexto sobre o PR, você não vai conseguir revisar sem saber o objetivo.

Uma boa descrição deve responder algumas perguntas:

• Qual problema este PR resolve?
• Qual foi a abordagem escolhida?
• Quais partes do sistema foram afetadas?
• Existe ticket, spec ou conversa relacionada?
• Tem algum ponto em que o autor quer atenção especial?

Se o PR não explica isso, a pessoa que vai revisar precisa descobrir pelo diff. Esse é um jeito ruim de começar.

Testes

Testes dizem muito sobre a intenção da mudança. Antes de olhar para a implementação, veja se o comportamento novo está coberto.

• Existe teste para o caso principal?
• Existe teste para erro, permissão ou estado vazio?
• O teste valida comportamento ou só confirma detalhe de implementação?
• Algum teste antigo foi removido sem explicação?

Quando um PR mexe em uma regra de negócio importante e não traz testes para esse comportamento, você precisa revisar com mais cuidado. Quem está revisando precisa entender melhor os cenários afetados e decidir se faz sentido pedir cobertura antes do merge.

Lógica de negócio

A parte mais difícil do review costuma ser entender se a mudança realmente faz sentido para o produto.

Um PR pode estar tecnicamente correto e ainda implementar o comportamento errado, deixar regras de negócio de fora ou não cobrir situações importantes.

Por isso, o review precisa comparar a implementação com o que foi pedido originalmente e verificar se as regras, restrições e comportamentos esperados estão realmente refletidos no código e nos testes.

Segurança

Segurança não deveria depender apenas de ferramentas automáticas. Linters, scanners e IA ajudam a encontrar problemas, mas parte da análise ainda exige contexto sobre como aquela mudança funciona dentro do sistema.

Alguns pontos básicos precisam entrar no review:

• a entrada de usuário está sendo validada no backend?
• autenticação e autorização estão aplicadas no lugar certo?
• dados sensíveis aparecem em logs, fixtures ou mensagens de erro?
• a mudança expõe um novo endpoint ou altera alguma superfície de acesso?
• existe risco de SQL injection, XSS ou acesso indevido?

O estudo Asleep at the Keyboard?, de Stanford, encontrou vulnerabilidades em uma parcela relevante dos programas gerados com Copilot em cenários ligados à segurança. A leitura que eu faria não é que código gerado por IA é necessariamente inseguro, mas que código aparentemente correto ainda precisa ser validado com mais cuidado quando envolve autenticação, dados sensíveis ou entrada de usuário.

Performance

Performance no review não é tentar antecipar todo problema que pode aparecer no futuro. É identificar mudanças que já dão sinais de que podem ficar caras ou instáveis quando chegam em produção.

Você precisa considerar algumas coisas, como:

• existem queries ou chamadas externas dentro de loops?
• a mudança aumenta o número de requests para outros serviços?
• listas grandes têm paginação?
• algum cache foi removido ou criado sem limite?
• a operação continua viável com volume real de dados?

O problema é que muita coisa funciona bem com pouco volume e começa a degradar quando o uso cresce. O review precisa tentar identificar esse tipo de risco antes que ele apareça em produção.

Arquitetura e manutenção

Uma mudança precisa se encaixar bem na arquitetura que já existe. Isso não significa impedir novas soluções, mas evitar que cada PR crie um padrão diferente ou adicione complexidade sem necessidade.

O review deve checar se a implementação segue a estrutura do projeto, mantém as responsabilidades bem separadas e não cria abstrações antes da hora. Também precisa considerar o custo de manutenção: uma solução pode funcionar hoje e ainda tornar a próxima mudança mais difícil.

Algumas perguntas poder ajudar a te direcionar, como:

• a solução segue os padrões já usados no projeto?
• existe uma forma mais simples de resolver o mesmo problema?
• a regra de negócio está no lugar certo?
• a mudança cria dependências ou abstrações desnecessárias?
• o código continua fácil de entender e alterar depois?

Impacto fora do diff

O PR mostra apenas os arquivos alterados, mas o impacto da mudança pode ir além deles.

Quando uma função muda de comportamento, é preciso entender quem depende dela. O mesmo vale para contratos de API, permissões, schemas e qualquer outra mudança que possa afetar partes do sistema que não aparecem no diff.

Em codebases grandes, esse problema fica ainda mais difícil porque uma mesma função, tipo ou regra pode ser usada por vários módulos e fluxos diferentes. Quanto mais dependências existem, maior a chance de uma mudança local quebrar algo distante do ponto onde o código foi alterado.

Por isso, revisar só as linhas do diff não é suficiente. O review precisa considerar também quem consome aquela mudança e quais partes do sistema podem ser afetadas por ela.

Checklist de code review

Eu gosto de usar checklist no review não para criar mais uma etapa, mas para garantir que alguns pontos importantes não dependam só de quem está revisando naquele dia.

Dá para começar com algo simples, como:

Objetivo

• ☐ O PR explica qual problema resolve.
• ☐ A mudança está alinhada com o ticket ou spec.
• ☐ O escopo está pequeno o suficiente para revisar com atenção.

Testes

• ☐ O comportamento principal está coberto.
• ☐ Casos de erro, permissão ou estado vazio foram considerados.
• ☐ Os testes validam comportamento, não detalhes frágeis de implementação.

Lógica de negócio

• ☐ O código entrega o comportamento esperado.
• ☐ Regras de permissão foram aplicadas no backend.
• ☐ Casos de borda importantes foram tratados.

Segurança

• ☐ Entradas externas são validadas.
• ☐ Dados sensíveis não aparecem em logs, mensagens ou fixtures.
• ☐ Autenticação e autorização foram revisadas.

Performance

• ☐ Não há query ou chamada externa desnecessária dentro de loop.
• ☐ Listas grandes têm paginação, limite ou estratégia clara.
• ☐ O impacto em dados reais foi considerado.

Manutenção

• ☐ A solução segue padrões existentes da codebase.
• ☐ Nomes e estrutura ajudam na leitura futura.
• ☐ A documentação foi atualizada quando necessário.

Um ponto de atenção: se um item aparece em quase todo PR, provavelmente faz mais sentido automatizar essa checagem do que depender do checklist toda vez.

Como preparar um pull request para revisão

O autor tem mais responsabilidade pelo review do que parece. Um PR ruim força quem revisa a gastar tempo descobrindo contexto, separando mudança relevante de ruído e perguntando coisas que poderiam estar na descrição.

Antes de pedir review, dê uma olhada no próprio PR como se você fosse a pessoa que vai revisar.

Abra PRs pequenos e focados

PRs grandes demoram mais para revisar e tornam mais difícil manter o mesmo nível de atenção do começo ao fim. Quanto mais coisas entram na mesma mudança, maior a chance de algum detalhe importante passar.

Um bom PR tem um objetivo claro. Quando possível, separe refatoração, formatação e mudança de comportamento em PRs diferentes. Isso deixa a intenção mais fácil de entender, reduz o esforço de revisão e diminui o risco no merge.

Escreva uma descrição útil

A descrição de um PR não precisa ser uma redação, mas você precisa dar contexto pra pessoa.

Você pode usar esse modelo:

## O que muda

[Explique em poucas linhas o que este PR altera.]

## Por que muda

[Explique o problema, ticket ou regra de negócio por trás.]

## Como testar

[Liste comandos, cenários ou passos manuais.]

## Pontos de atenção

[Marque decisões que merecem revisão mais cuidadosa.]

Isso economiza muito tempo, quem vai revisar já começa sabendo onde olhar e por quê.

Rode testes e checks antes de pedir review

Antes de pedir review, o ideal é chegar com o básico já resolvido. Rode os testes que fazem sentido para a mudança, confira lint e build e veja se não entrou nenhum arquivo que não deveria estar ali.

Também é bom reler o diff na própria ferramenta do PR. Quando você olha a mudança no GitHub, GitLab ou Bitbucket, fica mais fácil enxergar coisas que passam batido no editor, como um trecho duplicado, um comentário esquecido ou uma alteração que entrou sem querer.

Isso deixa o review mais focado no que realmente importa na mudança.

Diga onde você quer feedback

Se existe uma parte da mudança em que você ainda tem dúvida, deixe isso claro no PR. Pode ser uma decisão técnica, uma regra de negócio ou um comportamento que ainda não está totalmente definido.

Isso ajuda quem revisa a entender onde vale olhar com mais cuidado e qual decisão precisa de uma segunda opinião, em vez de tratar todas as partes do PR com o mesmo nível de atenção.

Como comentar em um code review

Um bom comentário precisa ajudar quem escreveu o código a entender o problema e decidir o que fazer em seguida. Pra isso, ele deve ser específico sobre o que está errado, por que aquilo é importante e qual comportamento seria esperado.

Comentários vagos, como “isso está errado” ou “melhore esse nome”, pouco ajudam porque transferem o trabalho de interpretação para quem recebe o feedback.

Quando fizer sentido, explique também o impacto da mudança ou sugira um caminho. O objetivo não é escrever comentários longos, mas deixar claro o raciocínio por trás da observação.

O tom também é importante. O feedback deve ser direto e respeitoso, sempre focado no código e na decisão técnica, não na pessoa que escreveu.

Quando bloquear o merge

Nem todo problema encontrado no review precisa impedir o merge. Pra decidir isso, o mais importante é entender o impacto daquela mudança.

Se o comentário trata de uma preferência, de um pequeno ajuste de legibilidade ou de uma melhoria que pode ser feita depois sem aumentar o risco, ele pode ficar como sugestão. Quando qualquer detalhe vira um motivo para bloquear, o review perde prioridade e fica difícil distinguir o que realmente precisa ser resolvido antes de colocar o código em produção.

O bloqueio faz sentido quando existe um risco concreto na mudança. Isso inclui regras de negócio incompletas, falhas de segurança, falta de testes em comportamentos críticos, quebra de contratos, problemas claros de performance ou código difícil de manter em uma parte importante do sistema.

Nesses casos, não basta dizer que o PR ainda não pode ser aprovado. O comentário precisa explicar qual é o risco, por que ele impede o merge e o que precisa mudar para que a revisão possa seguir.

Como evitar gargalos no code review

O code review vira um gargalo quando o PR entra na fila, mas não existe clareza sobre quem vai revisá-lo nem quando isso vai acontecer. Enquanto isso, o autor segue para outra tarefa e a mudança fica parada. Quanto mais tempo passa, mais contexto se perde e maior é o esforço para retomar aquela discussão depois.

Por isso, além de melhorar a qualidade das revisões, o time precisa cuidar do tempo entre abrir um PR e receber o primeiro retorno. Ter responsáveis claros e dar alguma previsibilidade para quem está esperando já evita boa parte desse problema.

Responda rápido, mesmo que a revisão completa venha depois

O guia de práticas do Google recomenda responder aos pedidos de review em até um dia útil. Isso não significa interromper o trabalho toda vez que um PR chega. A ideia é evitar que a pessoa que abriu a mudança fique sem saber se alguém viu o pedido ou quando a revisão vai acontecer.

Quando não der para fazer o review naquele momento, uma resposta rápida já ajuda. Você pode informar quando pretende revisar ou indicar outra pessoa que tenha disponibilidade. Dessa forma, o autor sabe o que esperar e consegue decidir se continua naquela tarefa, espera pelo feedback ou segue com outra coisa.

Essa previsibilidade parece pequena, mas evita que PRs fiquem esquecidos na fila e reduz o tempo em que uma mudança fica parada sem um motivo claro.

Distribua a revisão

Quando poucas pessoas acabam revisando quase todos os PRs, elas viram um gargalo e o restante do time participa menos desse processo. Por isso, faz sentido distribuir a responsabilidade de forma mais clara, seja com CODEOWNERS, rodízio ou revisão por área.

Nem todo PR precisa passar pela pessoa mais experiente do time. Dependendo da mudança, diferentes pessoas podem revisar partes diferentes, como testes, arquitetura ou regras específicas do domínio.

O importante é deixar claro quem é responsável por cada tipo de decisão e evitar que toda revisão dependa sempre das mesmas pessoas.

Separe formatação de discussão técnica

Formatação, imports, estilo básico e outros padrões objetivos não deveriam consumir tempo de review. Quando esse tipo de detalhe ainda aparece com frequência nos comentários, normalmente é um sinal de que falta automação.

O tempo da revisão funciona melhor quando fica concentrado no que realmente exige contexto, como regra de negócio, arquitetura, segurança, performance e manutenção.

Transforme padrões repetidos em regras

Em times maiores, eu vejo um problema sempre acontecer: boa parte dos critérios de review acaba ficando na cabeça de algumas pessoas.

Quem conhece melhor o sistema lembra das exceções, dos cuidados de segurança e das decisões que o time já tomou. O problema é que, quando isso não está registrado em algum lugar, a mesma discussão volta em vários PRs.

Pra mim, faz mais sentido transformar esses critérios em regras de revisão. Na Kodus, você pode escrever Kody Rules em linguagem natural e aplicar em diferentes escopos, como organização, repositório, diretório, arquivo ou pull request. Assim, o que vale para toda a engenharia fica global, enquanto regras mais específicas só entram onde realmente fazem sentido.

Isso reduz a dependência de alguém lembrar do mesmo ponto toda vez. O time define o critério uma vez e passa a aplicá-lo de forma mais consistente nos reviews.

Alguns times também preferem versionar essas regras junto com o código. Nesse caso, elas podem ficar no próprio repositório e ser sincronizadas com a Kodus. Para organizações com muitos repositórios, também dá para centralizar essa configuração.

Eu gosto dessa abordagem porque coloca as regras de review no mesmo fluxo do código. Uma mudança de regra passa por PR, fica registrada no histórico e pode ser revertida se necessário.

Ajuste a automação para não virar mais uma fonte de ruído

Eu acho que automação só ajuda quando o time consegue confiar no que ela está fazendo. Quando a ferramenta comenta demais, revisa arquivos que ninguém quer olhar ou aponta coisas que já deveriam estar no lint, a tendência é simples: as pessoas começam a ignorar.

Por isso, eu ajustaria o comportamento da revisão para acompanhar o fluxo real do time. Na Kodus, dá para rodar reviews automaticamente quando um PR é aberto, revisar novos pushes ou deixar a revisão manual. Também é possível ignorar arquivos como lockfiles, definir branches base, limitar a quantidade de sugestões e filtrar o que aparece por severidade.

Esse tipo de configuração faz diferença porque nem todo time trabalha do mesmo jeito. Alguns preferem feedback automático a cada mudança. Outros querem evitar novas revisões enquanto o PR ainda está recebendo vários pushes. Também tem time que só quer acionar a revisão automatizada quando a mudança já está pronta para uma revisão mais cuidadosa.

Para mim, o melhor sinal de que a automação está bem configurada é quando ela entra no fluxo sem exigir atenção extra só para organizar os próprios comentários.

Code review de código gerado por IA

Eu revisaria código gerado por IA com o mesmo cuidado de qualquer outra mudança e em alguns casos, até com mais atenção. Esse código pode parecer correto, estar bem organizado e passar nos testes, mas ainda assim ignorar uma regra de negócio, aplicar uma permissão de forma errada ou introduzir um padrão que não faz sentido naquela codebase.

Para mim, o maior risco está no contexto. O modelo responde ao que recebeu no prompt, mas o PR precisa funcionar dentro de um sistema real, onde as regras também estão no código existente, nos tickets, na documentação e nas decisões que o time foi acumulando ao longo do tempo.

Por isso, ao revisar código gerado por IA, eu prestaria mais atenção principalmente:

• regras de negócio que não estavam explícitas no prompt;
• permissões e isolamento de dados;
• cobertura dos cenários importantes nos testes;
• consistência com os padrões existentes da codebase;
• dependências ou abstrações adicionadas sem necessidade;
• complexidade maior do que o problema realmente exige.

A IA pode acelerar bastante a implementação, mas isso não reduz a necessidade de validar se a mudança realmente faz sentido dentro do sistema antes do merge.

O papel da IA no code review

Pra mim, a IA funciona melhor no code review quando ajuda o time a chegar mais rápido no que realmente merece atenção. Ela pode resumir a mudança, aplicar regras que o time já definiu, buscar contexto em outras partes da codebase e apontar riscos que seriam fáceis de deixar passar em uma leitura rápida.

Isso não significa transformar a IA em responsável pelo merge. A decisão ainda precisa considerar coisas que dependem muito do contexto do produto e do sistema, como arquitetura, comportamento esperado, impacto da mudança e nível de risco.

Eu gosto de pensar no processo em três camadas:

Camada	Papel no code review	Exemplos
Automação tradicional	Cuida do que é determinístico e pode ser validado por regras objetivas.	Lint, formatação, type checking, testes e checks simples.
IA	Analisa o que exige mais contexto e interpretação.	Entender o PR, relacionar arquivos, identificar riscos e aplicar regras do time.
Revisor humano	Concentra a atenção nas decisões que realmente exigem julgamento.	Produto, arquitetura, impacto da mudança, risco e trade-offs.

Outro ponto que eu levaria em conta é o modelo usado na revisão. Dependendo do time, custo, privacidade e controle sobre onde o código é processado podem ser tão importantes quanto a qualidade do comentário.

Na Kodus, por exemplo, dá para usar BYOK e escolher o provedor e o modelo que fazem sentido para cada contexto. Um time pode preferir modelos mais caros em partes críticas da codebase e opções mais econômicas em reviews mais simples, ou simplesmente querer mais controle sobre custo e processamento dos dados.

Como usar contexto no review

Na minha opinião, um PR quase nunca deveria ser analisado só pelo diff. Por trás daquela mudança existe uma tarefa, uma regra de negócio, padrões do repositório e decisões que o time já tomou antes. Quando esse contexto não entra no review, quem revisa precisa reconstruir tudo sozinho para entender se a implementação realmente faz sentido dentro do sistema.

Parte desse contexto pode ser levada para a própria ferramenta de review. Na Kodus, por exemplo, as Kody Rules podem usar informações do pull request, referências a arquivos e funções MCP. Com isso, a revisão consegue considerar não apenas o código alterado, mas também outras informações que ajudam a entender como aquela mudança deveria funcionar.

Na prática, eu usaria esse contexto de algumas formas:

• Regras globais para critérios que precisam ser respeitados em toda a codebase, como não permitir logs com dados sensíveis.
• Regras por diretório quando uma parte específica do sistema exige cuidados próprios, como mudanças em src/auth.
• Regras por repositório quando um projeto tem critérios que não fazem sentido para os demais, como exigir determinados testes em uma API.
• Referências a arquivos quando a implementação precisa seguir um padrão que já existe em outra parte da codebase.
• MCP quando parte do contexto necessário para revisar o PR está fora do repositório e precisa ser buscado em outra ferramenta.

Também dá para usar memórias para manter instruções persistentes sobre como a codebase funciona. Eu acho isso especialmente útil para padrões que aparecem o tempo todo nos reviews, mas que não são simples o suficiente para virar lint. Pode ser onde determinadas validações devem acontecer, como os módulos são organizados ou quais decisões de arquitetura precisam continuar sendo respeitadas.

Com isso, o review deixa de depender tanto de alguém conhecer toda a história do projeto de cabeça. O contexto que antes precisava ser lembrado e explicado a cada PR passa a fazer parte do próprio processo de revisão.

Métricas para melhorar o processo de code review

As métricas de code review ajudam a entender onde o processo está perdendo tempo e onde a revisão está deixando de funcionar bem. Elas mostram, por exemplo, se os PRs estão esperando demais por uma primeira resposta, se poucas pessoas concentram a maior parte das revisões, se as mudanças estão chegando grandes demais ou se certos tipos de problema continuam passando pelo review.

Eu prefiro olhar para poucas métricas, desde que elas ajudem a explicar o que está acontecendo no fluxo. As mais úteis costumam ser simples:

Tempo até o primeiro review

Essa métrica mostra quanto tempo um PR fica esperando até alguém começar a revisá-lo. Eu gosto de olhar para ela porque uma espera longa quase sempre indica que existe alguma fila no processo.

Quando isso acontece com frequência, o problema não é só o tempo parado. O autor acaba mudando de contexto, a mudança deixa de estar fresca na cabeça e, quando o feedback chega, retomar aquela discussão exige mais esforço.

Tempo até o merge

Enquanto a primeira métrica mostra quanto o PR espera para começar a ser revisado, o tempo até o merge ajuda a entender quanto o processo inteiro está levando.

Se esse tempo começa a crescer, eu tentaria descobrir onde está a demora. Pode ser que os PRs estejam grandes demais, que poucas pessoas estejam concentrando as revisões ou que decisões importantes só estejam sendo discutidas quando o código já está pronto.

Por isso, eu não olharia apenas para o número. O mais útil é entender qual parte do fluxo está aumentando esse tempo.

Tamanho do PR

O tamanho do PR não explica sozinho se uma revisão vai ser boa ou ruim, mas é uma informação importante quando analisada junto com as outras métricas.

Quanto maior a mudança, mais contexto quem revisa precisa manter ao mesmo tempo. Isso torna mais difícil entender todas as relações entre os arquivos e perceber impactos que não aparecem diretamente no diff.

Eu acompanharia principalmente a quantidade de linhas e arquivos alterados. Se PRs muito grandes aparecem com frequência e também demoram mais para revisar, isso pode ser um sinal de que as mudanças precisam ser divididas melhor antes de chegar ao review.

Distribuição de revisores

Também vale acompanhar quem está fazendo os reviews.

Se duas ou três pessoas aparecem em quase todos os PRs, existe uma boa chance de o time ter criado uma dependência delas. Além de aumentar o tempo de espera, isso concentra conhecimento e faz com que o restante da equipe participe menos das decisões sobre o código.

Nesse caso, a métrica ajuda a identificar onde faz sentido distribuir melhor as revisões e aumentar o número de pessoas capazes de revisar determinadas partes do sistema.

Defeitos pós-merge

Para mim, essa é uma das métricas mais importantes porque conecta o code review ao que realmente aconteceu depois que a mudança chegou à produção.

Quando um bug passa pelo review, eu tentaria entender se havia alguma chance razoável de identificá-lo antes do merge. Se havia, vale descobrir o que faltou naquele processo: contexto, teste, uma regra mais clara, a pessoa certa olhando aquela mudança ou alguma checagem que poderia ter sido automatizada.

A ideia não é usar essa métrica para procurar quem deixou o problema passar. Ela serve para encontrar padrões e melhorar o processo para que o mesmo tipo de erro tenha menos chance de acontecer novamente.

Perguntas frequentes sobre code review

O que é code review?

Code review é o processo de revisar uma mudança de código antes que ela seja integrada à branch principal. Normalmente, isso acontece em um pull request ou merge request, onde uma ou mais pessoas analisam a implementação, os testes e o impacto daquela mudança no restante do sistema.

Como fazer um bom code review?

Eu começaria entendendo o que o PR deveria resolver. Sem isso, fica difícil avaliar se a implementação está realmente correta.

Depois, olharia para os testes, a lógica de negócio, segurança, performance, arquitetura e possíveis impactos fora do diff. Durante a revisão, os comentários precisam deixar claro qual é o problema, por que ele importa e, quando fizer sentido, o que precisa mudar antes do merge.

O que olhar primeiro em um PR?

Para mim, o melhor ponto de partida é entender a intenção da mudança. Por isso, eu começaria pela descrição do PR e pelos testes.

A descrição ajuda a entender qual problema está sendo resolvido, enquanto os testes mostram quais comportamentos o autor espera preservar ou alterar. Com esse contexto, fica muito mais fácil ler a implementação e identificar se alguma parte importante ficou de fora.

Qual é o tamanho ideal de um PR?

Não existe um número que funcione para todos os times. O mais importante é que o PR tenha um objetivo claro e seja pequeno o suficiente para que alguém consiga entender a mudança sem precisar reconstruir uma parte inteira do sistema.

Quando um mesmo PR mistura feature, refatoração, formatação e outras mudanças sem relação direta, a revisão tende a ficar mais difícil. Nesses casos, normalmente faz sentido dividir o trabalho em mudanças menores.

IA substitui o code review humano?

Eu não vejo a IA como substituta do code review humano. Ela funciona melhor como uma camada adicional de revisão.

A IA consegue analisar o PR mais cedo, aplicar regras do time, encontrar padrões suspeitos e buscar contexto em outras partes da codebase. Ainda assim, decisões sobre produto, arquitetura, risco e trade-offs dependem de pessoas que entendem como aquele sistema funciona e por que determinadas decisões foram tomadas.

Como revisar código gerado por IA?

Eu teria um cuidado especial com o contexto. Código gerado por IA pode parecer correto e até passar nos testes, mas ainda assim ignorar uma regra de negócio, uma permissão ou uma decisão de arquitetura que não estava explícita no prompt.

Por isso, vale verificar se a mudança segue os padrões da codebase, respeita as regras de acesso, tem testes que realmente cobrem os comportamentos importantes e resolve o problema que deveria resolver. A velocidade com que o código foi produzido não deveria reduzir o nível de validação antes do merge.

Próximos passos

Se o code review do seu time está ficando lento, eu começaria pelo básico antes de adicionar mais processo. PRs menores, descrições melhores, responsáveis mais claros, respostas mais rápidas e automação para checagens repetitivas já resolvem boa parte da fricção.

Depois disso, eu olharia para o contexto disponível durante a revisão. Quanto mais fácil for entender por que aquela mudança existe, quais regras ela precisa respeitar e o que pode ser afetado fora do diff, melhor tende a ser a decisão de merge.

Isso fica ainda mais importante agora que a IA está aumentando a velocidade com que código é produzido. Se mais mudanças chegam para revisão, o desafio deixa de ser apenas escrever código e passa também por conseguir validar esse código sem transformar o review em um novo gargalo.

Na Kodus, é justamente nessa parte que eu vejo mais valor: transformar padrões que o time já usa em regras de revisão, aplicar essas regras nos lugares certos da codebase e trazer mais contexto para o PR antes da decisão de merge.