Code review na era da IA

• A IA não acabou com o code review; ao contrário, ela deixou mais claro o ônus da prova
• As mudanças devem ser implantadas com evidências anexadas, como validação manual ou testes automatizados, e depois o review deve identificar riscos, intenção e responsabilidade
• Enquanto desenvolvedores individuais dependem da automação para acompanhar a velocidade da IA, equipes constroem contexto compartilhado e senso de responsabilidade por meio do review
• Se um PR não traz evidências de funcionamento, isso não é deploy rápido, mas apenas empurrar o trabalho para downstream; só desenvolvedores com um sistema de validação conseguem ter sucesso com o desenvolvimento acelerado por IA
• O gargalo do code review se deslocou da escrita de código para o processo de provar que funciona; a IA acelera o trabalho mecânico, mas a responsabilidade continua humana

Mudanças no code review na era da IA

• No início de 2026, mais de 30% dos desenvolvedores sêniores já estavam colocando em produção código majoritariamente gerado por IA; a IA é ótima para rascunhar funcionalidades, mas expõe vulnerabilidades em lógica, segurança e edge cases, incluindo um aumento de 75% em erros de lógica
• Desenvolvedores solo fazem deploy rápido com inference speed e usam suítes de teste como rede de segurança, enquanto equipes mantêm o review humano por contexto e conformidade
• Se feito corretamente, ambos podem usar a IA como acelerador, mas a diferença aparece em quem valida o quê e quando
• Se você não confirmou diretamente que o código funciona, então ele não está funcionando de verdade
  • A IA só reforça essa regra; não dá isenção dela

Como os desenvolvedores fazem review com IA

• Verificações ad-hoc com LLM: antes do commit, colar o diff no Claude, Gemini ou GPT para checar rapidamente bugs ou problemas de estilo
• Integração com IDE: usar ferramentas como Cursor, Claude Code e Gemini CLI para sugestões inline e refatorações durante a codificação
• Bots de PR e scanners: usar GitHub Copilot ou agentes customizados para marcar automaticamente possíveis problemas no PR, junto com ferramentas de análise estática e dinâmica como Snyk para checagens de segurança
• Loop automatizado de testes: gerar e executar testes com IA e definir mais de 70% de cobertura como condição de merge
• Review com múltiplos modelos: revisar o código com vários LLMs para capturar vieses específicos de cada modelo (ex.: gerar com Claude, auditar com um modelo especializado em segurança)

Desenvolvedor solo vs equipe: comparação

• Desenvolvedor solo
  • Foco do review: testes automatizados + spot checks limitados
  • Trade-off de velocidade: velocidade de inferência, correção de problemas em loops iterativos
  • Ferramenta principal: testes agênticos (ex.: loop do Claude Code)
  • Princípio: Prove it yourself
• Equipe
  • Foco do review: avaliar contexto e segurança com julgamento humano
  • Trade-off de velocidade: manter PRs pequenos para evitar gargalos de review
  • Ferramenta principal: combinação de bots + políticas (ex.: rotulagem de PR gerado por IA)
  • Princípio: Share the Proof

Desenvolvedor solo: deploy com “inference speed”

• Desenvolvedores solo tendem a ‘confiar no vibe’ do código gerado por IA, verificando apenas partes críticas e usando testes para encontrar problemas, o que permite entregar funcionalidades rapidamente
• Há uma tendência de tratar agentes de codificação como estagiários poderosos capazes de tocar grandes refatorações sozinhos
• Declaração de Peter Steinberger: “Agora eu não leio muito código. Eu acompanho o stream e, às vezes, só verifico partes-chave”
• O gargalo do desenvolvimento deixou de ser digitação e passou a ser o tempo de inferência (esperar a saída da IA)
• Ponto de atenção: sem testes robustos, o ganho percebido de velocidade desaparece
  • Pular o review não elimina trabalho; apenas o empurra para depois
  • A chave para ter sucesso com desenvolvimento acelerado por IA não é confiança cega, mas construir um sistema de validação
• Desenvolvedores solo responsáveis usam testes automatizados abrangentes como rede de segurança, mirando mais de 70% de cobertura
• Testes independentes de linguagem e baseados em dados têm papel decisivo
  • Se os testes forem suficientes, o agente consegue gerar e corrigir implementações em qualquer linguagem, com possibilidade de validação
  • No início do projeto, a IA cria um rascunho de spec.md e, após aprovação, repete o loop escrever → testar → corrigir
• Mesmo o desenvolvedor solo faz testes manuais e julgamento crítico na etapa final
  • Executa a aplicação diretamente, clica na UI e usa as funcionalidades
  • Em casos de maior risco, lê mais código e faz validações adicionais
  • Mesmo desenvolvendo rápido, limpa código bagunçado assim que encontra
• Princípio central: a missão do desenvolvedor é ‘entregar código cujo funcionamento ele mesmo comprovou’

Equipes: a IA desloca o gargalo do review

• Em ambientes de equipe, a IA é uma poderosa assistente para code review, mas não pode substituir o julgamento humano necessário para qualidade, segurança e manutenibilidade
• Em ambientes com vários engenheiros colaborando, o custo dos erros e a vida útil do código são fatores muito mais importantes
• Muitas equipes usam bots de review com IA nas etapas iniciais do PR, mas a aprovação final continua exigindo humanos
• Declaração de Greg Foster, da Graphite: “Agentes de IA nunca vão substituir a aprovação de PR por engenheiros humanos de verdade”
• O maior problema prático não é a IA deixar passar questões de estilo, mas sim o fato de ela aumentar o volume de código e transferir a carga de revisão para humanos
  • Com a adoção crescente de IA, o tamanho dos PRs aumentou cerca de 18%
  • Os incidentes por PR aumentaram cerca de 24%
  • A taxa de falha em mudanças aumentou cerca de 30%
• Quando a velocidade de geração supera a capacidade de validação, o processo de review vira o fator limitante de velocidade de todo o fluxo de desenvolvimento
• Declaração de Foster: “Colocar em produção código que nenhum colega humano leu ou entendeu é um grande risco”
• Como a IA gera grandes volumes de saída em equipes, é necessário adotar desenvolvimento incremental e dividir a saída do agente em commits revisáveis
• A aprovação humana final não desaparece; em vez disso, evolui para se concentrar nas áreas que a IA deixa passar
  (alinhamento com roadmap, contexto organizacional e institucional que a IA não capta)

Segurança: vulnerabilidades previsíveis da IA

• Segurança é uma área em que o julgamento humano é absolutamente necessário
• Defeitos de segurança foram encontrados em cerca de 45% do código gerado por IA
• A taxa de erros de lógica é 1,75 vez maior que em código escrito por humanos
• A frequência de vulnerabilidades de XSS é 2,74 vezes maior
• Além dos problemas do próprio código, ferramentas baseadas em agentes e IDEs integradas com IA criam novos vetores de ataque
  • prompt injection, vazamento de dados e vulnerabilidades de RCE
• Como a IA expande a superfície de ataque, uma abordagem híbrida é eficaz
  • A IA sinaliza problemas, e humanos fazem a validação final
• Regra: código que lida com autenticação, pagamentos, segredos e entradas não confiáveis deve
  tratar a IA como um estagiário de alta velocidade e exigir, antes do merge, review humano de threat model e inspeção com ferramentas de segurança

Transferência de conhecimento por meio do review

• Code review é o principal meio pelo qual equipes compartilham o contexto do sistema
• Se a IA escreveu o código, mas ninguém consegue explicá-lo, o custo de on-call aumenta
• Quando se submete código gerado por IA sem entendê-lo por completo, o mecanismo de transferência de conhecimento que sustenta a resiliência da equipe entra em colapso
• Se o autor não consegue explicar por que o código funciona, o engenheiro de on-call não conseguirá depurar isso às 2 da manhã
• Caso em que um maintainer de OCaml recusou um PR de 13.000 linhas gerado por IA
  • A qualidade do código não era necessariamente ruim, mas faltava largura de banda de review para analisar uma mudança daquele tamanho
  • Review de código gerado por IA exige carga cognitiva maior do que review de código escrito por humanos
• Lição: a IA pode produzir grandes volumes de código, mas equipes precisam controlar o tamanho das mudanças para evitar gargalos de review

Como usar ferramentas de review com IA

• A experiência de uso com ferramentas de review por IA é claramente dividida
• Lado positivo: em alguns casos, elas capturam mais de 95% dos bugs, como null pointer exceptions, lacunas na cobertura de testes e antipadrões
• Lado negativo: alguns desenvolvedores veem comentários de review por IA como ‘ruído textual’, observações genéricas sem valor
• Lição: ferramentas de review com IA exigem configuração cuidadosa
  • ajuste de sensibilidade, desativação de tipos de comentário pouco úteis e políticas claras de opt-in e opt-out
• Quando bem configurado, um reviewer com IA pode capturar 70% a 80% dos problemas fáceis, permitindo que humanos foquem em arquitetura e lógica de negócio
• Muitas equipes recomendam PRs pequenos e acumuláveis, mesmo que a IA consiga produzir mudanças enormes de uma vez
• As mudanças devem ser commitadas com frequência, e cada alteração deve ser gerenciada em commits e PRs separados como unidades autocontidas, com mensagens claras
• Equipes mantêm limites claros de responsabilidade humana
• Independentemente do grau de contribuição da IA, a responsabilidade final recai sobre humanos
• Máxima educacional da IBM: “Computadores nunca podem ser responsabilizados. A responsabilidade cabe ao humano dentro do loop”

Contrato do PR: dever do autor com o reviewer

• Tanto para solo quanto para equipes, a prática recomendada que emerge é tratar código gerado por IA como um rascunho útil que precisa de validação
• Há um framework simples usado em comum pelas equipes mais bem-sucedidas

• Componentes do contrato de PR

  1/. What/Why: resumir a intenção e a razão da mudança em 1–2 frases
  2/. Evidências de funcionamento: resultados de testes aprovados e etapas de validação manual (capturas de tela, logs)
  3/. Risco + papel da IA: indicar o nível de risco da mudança e quais partes foram geradas por IA (ex.: funcionalidade de pagamentos é de alto risco)
  4/. Foco do review: apontar 1–2 áreas que exigem revisão humana (ex.: arquitetura)
• Isso não é burocracia; é um mecanismo para respeitar o tempo do reviewer e deixar clara a responsabilidade do autor
• Se você não consegue escrever isso, então ainda não entende sua própria mudança o suficiente para pedir aprovação de outra pessoa

Princípios centrais

• Exigir evidência, não promessa: adotar “código funcionando” como linha de base, exigir que agentes de IA executem o código ou rodem testes unitários após gerar código e verificar evidências como logs, screenshots e resultados; não abrir PR sem novos testes ou uma demonstração de funcionamento
• Usar IA como primeira revisora, não como árbitra final: tratar a saída do review por IA como consultiva; uma IA escreve o código, outra revisa, e o humano coordena a direção das correções; review por IA deve ser usado no nível de corretor ortográfico, não de editor
• Review humano deve focar no que a IA deixa passar: se houve introdução de vulnerabilidades, duplicação de código existente (falha comum da IA), e se a abordagem é sustentável para manutenção; a IA filtra os problemas fáceis e humanos assumem os julgamentos difíceis
• Aplicar desenvolvimento incremental: dividir o trabalho em unidades pequenas para que a IA consiga gerar e humanos consigam revisar; usar commits pequenos com mensagens claras como checkpoints; nunca commitar código que você não consegue explicar
• Manter alto padrão de testes: desenvolvedores que usam agentes de codificação com eficiência mantêm práticas fortes de teste e pedem à IA rascunhos de testes para gerar testes de edge cases que humanos podem deixar passar

Perspectiva futura: o gargalo muda de lugar

• A IA está deslocando o code review de uma fiscalização linha a linha para um controle de qualidade em alto nível, mas o julgamento humano continua sendo um elemento essencial de segurança
• Isso é uma evolução do workflow, não a eliminação do code review
• O escopo do code review passa a incluir não só o diff do código, mas também a conversa ou o plano entre a IA e o autor
• O papel do reviewer humano se aproxima cada vez mais do de um editor ou arquiteto, focando em decisões importantes e confiando à automação as verificações rotineiras
• Para desenvolvedores solo, o caminho à frente é empolgante, mas, por mais que novas ferramentas surjam, os bons desenvolvedores continuam seguindo o princípio de ‘confiar, mas verificar’
• Em equipes grandes, espera-se fortalecimento da governança de IA
  • formalização de políticas sobre contribuição da IA e exigência de aprovação de que um funcionário revisou diretamente
  • surgimento de papéis como ‘auditor de código de IA’
  • plataformas enterprise evoluindo para suportar melhor contexto multi-repositório e aplicação de políticas customizadas
• O princípio central não muda: code review garante que o software atenda aos requisitos e seja seguro, robusto e manutenível
• A IA não altera esse fundamento; muda apenas a forma de chegar lá
• O gargalo do desenvolvimento se desloca da escrita de código para o processo de provar que funciona
• O excelente reviewer de código na era da IA abraça essa mudança, mas mantém a linha da responsabilidade enquanto permite que a IA acelere o trabalho mecânico
• A IA pode acelerar o processo, mas não deve levar à abdicação da responsabilidade
• Engenheiros passam a valorizar cada vez mais proof over vibes
• O code review não desapareceu; ele está se tornando mais estratégico
• Seja um desenvolvedor solo fazendo deploy às 2 da manhã ou um líder de equipe aprovando mudanças críticas em sistemas importantes, o fato comum é que a responsabilidade final pelo que a IA produziu continua sendo humana
• Adote a IA, mas mantenha o hábito de conferir o trabalho novamente

[tested]

https://www.coderabbit.ai/
Alguém já usou o CodeRabbit? O preço é bem salgado, então não sei se vale tudo isso.

[developerjhp]

Se você usar a extensão do Chrome abaixo, pode receber de forma prática uma revisão do GPT com base no diff do PR do GitHub~!
https://github.com/developerjhp/Diffinity

[crawler]

Se foi você mesmo que fez, acho melhor postar no Show GN.

Até 5 meses atrás você postava direitinho no Show GN, então por que fazer divulgação nos comentários, buá buá...