Quem faz boa revisão de código também consegue lidar bem com agentes de IA

• Para se tornar proficiente no uso de agentes de IA, é importante ter habilidade em revisão de código
• Modelos de linguagem de grande porte são bons em geração de código, mas carecem de capacidade de julgamento profunda, e muitas vezes desperdiçam tempo na direção errada
• Uma revisão minuciosa demais que só aponta detalhes de sintaxe, ou uma revisão de carimbo que aprova sem senso crítico, não ajuda no uso de IA
• Uma boa revisão de código inclui uma perspectiva estrutural para avaliar se existe uma forma melhor de fazer algo e evitar designs complexos
• No fim, programar com IA é um modelo como o "xadrez centauro", que combina julgamento humano com produtividade da máquina, e a habilidade de revisão de código se traduz diretamente em capacidade de uso de IA

---

Relação entre agentes de IA e revisão de código

• Usar agentes de IA da maneira correta é, na prática, o próprio processo de revisão de código
• Quem revisa código bem também consegue usar com eficácia ferramentas de código com IA como Claude Code, Codex e Copilot

Por que a habilidade de revisão de código é importante

• Modelos de linguagem de grande porte são bons em gerar grandes volumes de código, mas ainda carecem do julgamento de um engenheiro de software experiente
• Por isso, se deixados sem supervisão, tendem a desperdiçar muitos recursos com designs desnecessários ou ruins

Limites dos agentes de IA e erros de design

• Como exemplo, durante o desenvolvimento do projeto VicFlora Offline, o Codex dedicou muito esforço a fazer engenharia reversa do código de frontend
  • Na prática, havia uma abordagem de acesso a dados mais simples
  • Ao usar agentes de IA, percebe-se que mais ou menos uma vez por hora eles acabam fazendo algo suspeito
  • Ao detectar esse tipo de problema e corrigir a direção manualmente, é possível economizar horas de trabalho
• Em outra experiência de desenvolvimento de app, a IA propôs construir uma infraestrutura de background excessiva até para uma tarefa simples de processamento paralelo
  • Bastaria tratar isso no frontend de forma não bloqueante, mas ela tentou introduzir uma arquitetura complexa
  • É importante continuar controlando a IA para manter a simplicidade
• Quando não especialistas desenvolvem confiando apenas na IA, a complexidade e a ineficiência da base de código se acumulam, e isso pode até reduzir drasticamente a capacidade de resolver problemas

A essência e o efeito da revisão de código

• Colaborar com IA é semelhante a trabalhar com um desenvolvedor júnior entusiasmado, mas sem experiência
  • Como a IA não desenvolve capacidade de julgamento com o tempo, observação contínua é necessária
• O maior erro em revisão de código é olhar apenas para o código escrito e não pensar se existe uma alternativa melhor
  • A revisão de código ideal considera, de forma estrutural, o contexto do sistema como um todo
  • Antes de criar um sistema novo desnecessário, a prioridade deve ser reutilizar um sistema existente
• Um revisor 'nitpicky' obcecado apenas com estilo detalhado de código pode perder o verdadeiro potencial das ferramentas de IA
• Se agir como um revisor de 'rubber-stamp' e aprovar tudo sem crítica, será difícil colaborar de forma eficaz com IA/desenvolvedores juniores

Reflexões sobre a habilidade de usar ferramentas de IA

• Ferramentas tradicionais como o git têm estrutura e modo de operação claros, mas a estrutura básica da IA é opaca
  • A IA pode executar quase todo tipo de operação
• Alguns veem a utilização ampla de ferramentas de IA como a própria habilidade de uso de IA
  • Na prática, usuários experientes conseguem extrair ainda mais possibilidades
• Até o momento, agentes de código com IA podem ajudar em vários tipos de tarefa, mas exigem supervisão próxima
• Como no modelo de "xadrez centauro", quando a direção de um humano experiente se combina com as sugestões da IA, é possível atingir a produtividade ideal
• A habilidade de usar IA depende, no fim, da capacidade de revisão de código e do julgamento crítico de design
• Quanto melhores forem as habilidades de revisão de código, maior será o efeito do uso de ferramentas de agentic AI

Pensamentos finais e perspectivas

• Agentes de IA podem passar a sensação de que, com o tempo, estão se tornando cada vez mais parecidos com engenheiros experientes
• Nos próximos anos, a experiência de colaborar com IA pode evoluir até um nível comparável ao de colaborar com engenheiros de nível pleno
• No momento, o ideal é experimentar várias ferramentas de IA (Codex, Claude Code, Copilot etc.), e a capacidade de supervisão crítica é o fator diferencial mais importante

Opiniões adicionais

• Houve discussões em lugares como o Hacker News sobre “até que ponto agentes de IA são úteis”
  • O autor não acredita que apenas com revisão de código a IA consiga contribuir em nível de kernel do Linux
  • Alguns também defendem que métodos de revisão de código como estilo e nomenclatura são importantes
  • Há uma visão crítica sobre fazer discussões de design na revisão de código, mas o autor não vê isso de forma negativa

[GN⁺]

Opiniões no Hacker News

• A ideia de que mesmo com um processo ruim dá para obter bons resultados se o controle de qualidade for bom é bastante duvidosa; é algo no estilo “pode continuar cuspindo tranqueira que, se alguém revisar, tudo bem”, mas nunca vi isso funcionar bem na prática; tentaram algo assim na indústria automotiva dos EUA, mas não me vem nenhum caso de sucesso à cabeça; se eu imaginar meu chefe me dizendo, como líder de equipe, “em vez de 5 pessoas competentes, vou te dar 25 iniciantes completos e esperar que, com sorte, saia algo que preste; você revisa tudo”, isso é absurdo; mas é curioso como, quando a IA entra nesse cenário, muita gente passa a pensar “hm? talvez funcione?”

  • Revisar código de gente com pouca experiência ou pouca motivação também é extremamente cansativo; consome uma energia mental e emocional enorme; quando você revisa a mesma funcionalidade pela quarta vez, bate um esgotamento e você acaba desistindo num ponto em que a qualidade já não sobe mais

  • Isso é o completo oposto do modelo de controle de qualidade que Deming (Edward Deming) desenvolveu no Japão e difundiu no Ocidente; qualidade não vem das pessoas, vem do processo; escolher um processo cheio de defeitos e esperar que humanos peguem os erros não é, de forma alguma, um bom método se o objetivo é qualidade; LLMs podem ser usados de várias formas, mas só algumas realmente trazem vantagem; a gestão parece iludida achando que IA resolve tudo, sem entender direito os pontos fortes e fracos da IA, ou então esquecendo as lições de Deming

  • Evolução é mutação aleatória e seleção, ou então a própria existência de toda vida complexa é um exemplo disso; não é o método que eu prefiro, mas existe uma tendência de se empolgar com palavras da moda e sair aplicando de forma aleatória até onde não faz sentido; na produção de certas peças plásticas de utensílios de cozinha, ainda existe o método de fabricar com baixa qualidade e depois um temporário corrigir manualmente com faca antes de embalar; eu mesmo já fiz esse tipo de bico; chip binning/rendimento em semicondutores também pode ser visto como um caso com taxa de falha altíssima; basta olhar ao redor para perceber que processos duvidosos não são exceção, são o normal

  • Quando a pessoa começa a se avaliar como alguém que “sabe usar IA”, ela pode cair na ilusão de que “a faixa de problemas que consigo resolver aumentou enormemente”; isso acontece com toda tecnologia de uso geral; no passado foi parecido com o boom dos algoritmos genéticos; todo mundo procura uma ferramenta “genérica” e passa a achar que dá para fazer tudo com ela; na prática, tenta-se otimizar sem contexto nenhum; IA é um exemplo ainda mais extremo desse fenômeno

  • Por melhor que seja o processo, isso por si só não ensina a construir um sistema que realmente funciona; o padrão que vejo repetidamente é a equipe passar muito tempo perdida, até que um engenheiro que sabe como resolver o problema entra em cena e coloca a direção nos trilhos

• É realmente difícil fazer a IA obedecer aos parâmetros exigidos; ela sempre se desvia aleatoriamente para direções sem sentido; quando trabalhei no highlighting de nftables, havia 230 tokens, 2.500 estados e mais de 50 mil transições de estado; mesmo dando à IA cinco regras claras, ela falhava em pontos aleatórios; não era só no resultado de código, ela nem conseguia fazer direito um Vimscript bem simples; no fim, uso IA apenas para documentação; ainda assim, ela começou a ajudar bastante a explicar coisas em partes, como rule, chain_block stmt, map_stmt_expr; eu só copio e colo os padrões de sintaxe que quero

• Geração de código com IA é bem útil na fase inicial de um projeto, mas em projetos maduros há motivos para preocupação; recentemente fizeram merge de um parser de Postgres com mais de 280 mil LOC no Multigres sem revisão pública; isso é algo para se observar com cautela no ecossistema open source; muita gente depende desses projetos para aprender e como referência, e se código de IA entra sem revisão adequada, o valor educacional e a confiança nessa dependência enfraquecem; revisão de código não serve só para pegar bugs, é central para colaboradores aprenderem, entenderem os motivos de design e acumularem conhecimento coletivo; a questão não é velocidade, é o processo de transferência de conhecimento; sobre o tempo até a divulgação do PR, veja o link

  • Eu supervisei esse trabalho e feedback sobre maneiras melhores de fazer isso é sempre bem-vindo; o que torna essa situação especial é que foi um trabalho de traduzir o parser em C do Postgres usando LLM; nessa escala, não dava para revisar tudo linha por linha, então criamos um procedimento separado para garantir consistência; verificamos tudo cuidadosamente todos os dias e isso levou dois meses; também trouxemos a maior parte dos testes do Postgres e os portamos com sucesso, então a confiabilidade de funcionamento ficou bem assegurada; o estágio atual do Multigres ainda é muito inicial, e pretendemos tentar mais cópias/traduções em massa de outros projetos no futuro, como Vitess; qualquer melhoria será considerada; o autor também está preparando um blog explicando todo o processo, então vale acompanhar; pessoalmente, fiquei muito surpreso com o que foi possível alcançar com ajuda de LLMs; claro, ainda foi necessário bastante domínio, e essa pessoa superou todos os critérios apresentados aqui

• Meu processo é mais ou menos assim

  1. Apresento os requisitos para a IA
  2. Faço a IA me perguntar o que não estiver claro
  3. Quando não há mais perguntas, peço que ela reformule os requisitos no formato de um PRD formal
  4. Eu critico
  5. Peço duas arquiteturas alternativas
  6. Escolho uma e critico
  7. Peço duas listas detalhadas de TODOs
  8. Escolho uma e critico
  9. Para um dos TODOs, peço duas opções de implementação
  10. Escolho uma e critico
  11. Repito a partir do passo 9
      No meio do caminho, vou tirando snapshots para poder voltar atrás
      Assim, talvez eu não chegue a algo excelente, mas pelo menos consigo um resultado que serve como referência para a minha própria implementação
      A desvantagem é que consome um tempo absurdo, e em 80% dos casos eu fico com a sensação de que teria sido mais rápido fazer tudo sozinho desde o início

  • Parece mais lento do que fazer sozinho; quando programo com IA, é como olhar o trabalho de um desenvolvedor mediano que passou a noite de domingo improvisando algo com base nas suas anotações, tipo “bebi umas e fiz mais ou menos isso com o que você escreveu, o que acha?”; você diz “NÃO, não gostei”, e se a direção geral estiver mais ou menos certa, ainda parece um pouco mais rápido refatorar aquilo e começar a segunda-feira de manhã do que partir do zero

  • Sempre que vejo esses guias passo a passo, no fim me parece que estão adicionando um incômodo gigantesco, a ponto de toda a eficiência que se esperava ganhar com IA desaparecer; na minha experiência, isso é quase sempre verdade; claro que há momentos em que a IA ajuda, mas saber quando e onde ela é útil também é uma habilidade importante

  • Eu trabalho numa camada mais baixa, e normalmente faço assim:

    • Eu mesmo crio a interface básica, ou, se ela já existir, passo para a etapa seguinte
    • Uso o LLM como ferramenta de autocompletar
    • Descrevo os requisitos e também informo quais arquivos de entrada precisam mudar
    • Não dou o objetivo final de uma vez; passo um passo por vez
    • Se vejo sinais de que está saindo do rumo, intervenho imediatamente para parar ou redirecionar a IA se ela estiver errada
      Em geral, quando eu dava um objetivo amplo e longo de uma vez só, o agente frequentemente errava ao julgar quando o trabalho estava concluído

  • Uso um processo parecido, mas um pouco mais simplificado; eu já passo um PRD, também dou uma arquitetura geral e peço a implementação de cada componente do jeito que quero; ainda leva bastante tempo, e fazer direto continua mais rápido, mas hoje em dia digitar tudo na mão me dá preguiça, então estou pensando em passar funções isoladas para o LLM implementar

  • Se eu tivesse usado a IA apenas para me indicar uma abordagem geral, bibliotecas e características da linguagem, teria sido muito mais rápido simplesmente fazer o trabalho principal eu mesmo

• Se você é bom em revisão de código, talvez seja melhor nem usar agentes de IA

  • O que senti ao revisar o código de colegas apaixonados por agentes como Claude Code e corrigir bugs neles é que o código parecia ter sido escrito em estado de alucinação, e muitas vezes quem o escreveu não conseguia explicar absolutamente nada sobre ele; ainda assim, acredito que deve haver gente produzindo código realmente bom com isso, mas tudo o que vi na prática foi decepcionante; felizmente, alguns perceberam isso por conta própria e voltaram a formas mais adequadas de trabalhar; se você olhar criticamente para o que sai hoje de workflows baseados em agentes, a resposta me parece clara; quem revisa bem código vai chegar a essa conclusão muito mais rápido

  • Se eu sou bom em revisão de código, quero continuar melhorando nisso

• Quem revisa código com cuidado tende a ter dificuldade com ferramentas de IA, enquanto quem revisa de forma superficial tende a depender demais da IA
  Em outras palavras, quem revisa código bem provavelmente se sai melhor programando diretamente, e em projetos desse tipo isso é ainda mais natural no longo prazo, porque a própria pessoa vai ter de manter o sistema; se programar não é um incômodo e você faz isso bem, não há tanta necessidade de usar IA; IA é ideal para dar uma olhada rápida e fragmentada quando você está aprendendo uma ferramenta desconhecida ou algo novo; admito que, hoje, graças aos LLMs, os resumos de mecanismos de busca melhoraram bastante; o tempo perdido tentando interpretar documentação inútil ou se distraindo com detalhes irrelevantes caiu a zero

• Revisão de código também faz parte do trabalho, mas é a parte menos divertida; desenvolvedores sentem satisfação no momento de programar diretamente, então ferramentas de IA ajudam, mas como são imprevisíveis e ao mesmo tempo soam convincentes, exigem revisões ainda mais cuidadosas e acabam aumentando a carga; por que criamos ferramentas que tiram a parte divertida e só aumentam a parte chata? Fico me perguntando onde está o agente especializado em “revisão de código”

  • Na verdade, eu não acho muito divertido o ato de “escrever” código em si; para mim, o mais divertido é resolver problemas, criar coisas novas, quebrar sistemas em partes e recombinar tudo em estruturas melhores; usando LLMs para programar, sinto que ficou muito mais rápido transformar ideias em algo concreto com que eu posso mexer; o código existente também fica com mais segurança de tipos, melhor documentado e com refatorações complexas mais fáceis; não espero que LLM resolva problemas por mim, mas que ajude a reunir contexto, reaplicar padrões e automatizar código repetitivo; especialmente quando há código espalhado por vários arquivos, é muito conveniente deixar a IA gerar tudo e eu apenas revisar cada alteração

  • O OpenAI Codex Cloud adicionou recurso de revisão de código, e o novo modelo GPT-5-Codex foi treinado especificamente para isso [introdução às atualizações do Codex]; Gemini e Claude também ganharam recursos de revisão de código com integração com GitHub Actions e integração do Claude com GitHub; o GitHub também lançou seu próprio recurso Copilot Code Review; também há várias startups dedicadas a isso, como CodeRabbit, Greptile e Qodo Merge

  • O momento em que eu realmente sinto um arrepio é quando, durante a implementação, descubro uma estrutura subjacente extremamente elegante que muda até a minha forma de programar ou até de viver (embora isso aconteça muito raramente)

  • Quanto mais júnior o desenvolvedor, mais ele gosta de escrever código diretamente; já os seniores tendem a amar reduzir código; pessoalmente, revisão de código é a parte mais divertida do meu trabalho (quando não estou sendo esmagado por prazos); não concordo com a ideia de que revisão de código não é divertida

  • Na abertura houve a observação de que “a maioria dos desenvolvedores gosta de criar coisas novas”, mas na prática há muita gente que prefere entender padrões e estruturas em codebases já existentes e melhorá-las; também é preciso considerar que, para algumas pessoas, o processo de criar algo totalmente novo (design inicial — repetição infinita) é ainda mais difícil; quanto à pergunta “tiramos a diversão e aumentamos só a parte chata?”, provavelmente isso aconteceu porque focaram nas partes em que o ganho de produtividade parece mais evidente; e para IA de revisão já existem várias opções, como CodeRabbit e GitLab Duo; também não seria difícil usar algo como RooCode passando o Git diff para fazer a revisão

• O título deste texto me parece simplista demais; revisão de código e revisão de design são coisas diferentes, e o que se tenta fazer com IA não se limita a essas duas; para usar IA, você precisa de conhecimento especializado na área em questão, e mesmo olhando só para programação, capacidade de revisão por si só não basta: é preciso ter competência para validar o trabalho delegado à IA, seja em que domínio for; ironicamente, a IA costuma ser mais útil quando estou lidando com uma linguagem ou framework que não conheço bem, mas aí justamente minha revisão também não consegue ser profunda; também é curioso como a palavra “coding” voltou à moda na era da IA/LLM; hoje parece que as empresas preferem engenheiros capazes de fazer de tudo — arquitetura, análise de requisitos, full-stack e operação — em vez de simples coders

  • Meu cargo oficial é “Software Engineer”, mas nos últimos 5 anos

    1. Configurei/operei diretamente clusters Kubernetes para a minha equipe
    2. Usei Docker demais
    3. Desenvolvi pipelines de CI/CD
    4. Fiz incontáveis integrações/testes
    5. Também documentei demais requisitos, inclusive vários diagramas de sistemas
    6. Assumi várias tarefas diversas de TI que o time de infraestrutura não fazia
    7. E de vez em quando até programei

  • Usar agentes de IA corretamente é o mesmo processo de revisão
    porque LLMs conseguem produzir uma quantidade enorme de código, mas ainda não têm a profundidade de julgamento de um engenheiro de software competente
    É muito melhor corrigir a rota cedo do que deixar código ir se acumulando por muito tempo na direção errada; como com um desenvolvedor júnior, o sensato é discutir primeiro a visão geral/o design e ir ajustando cedo sempre que a direção sair do rumo; se você só descobrir depois de 100 mil tokens de código que as primeiras 100 linhas estavam erradas, no fim vai precisar refazer tudo

• Eu gosto muito da ideia de que, ao revisar código com colegas, o conhecimento compartilhado e os padrões coletivos melhoram; mas só de pensar em revisar código de uma IA teimosa e pouco cooperativa já sinto que viria um burnout

• Às vezes penso que, se eu ficar muito bom na parte mais entediante do meu trabalho, vou acabar fazendo só isso para sempre, e sinceramente odeio essa ideia; e, como o texto diz, é sempre melhor que os bugs nem entrem para começo de conversa; capturá-los depois que já entraram sempre envolve risco