Revisão de código agentic

• Com a rápida melhora de desempenho dos agentes de programação, o ponto difícil da engenharia deixou de ser escrever código e passou a ser decidir se esse código merece confiança; assim, a revisão se tornou o trabalho de maior alavancagem
• A IA aumenta muito a produção, mas reduz a qualidade e a facilidade de revisão, e já foi medida uma diferença em que, diante de 4 vezes mais código, o valor real cresce só cerca de 10%
• A intensidade de revisão necessária varia conforme o blast radius (raio de impacto) da mudança, e um desenvolvedor solo e uma equipe que mantém um sistema grande com 10 anos de existência enfrentam restrições totalmente diferentes
• Os agentes raciocinam, mas esse raciocínio não é anexado ao PR e é descartado, criando para o revisor o ônus de reconstruir do zero a intenção desaparecida
• Escrever ficou barato, mas entender continua caro; por isso, as equipes que construírem sistemas de revisão confiáveis terão vantagem daqui para frente

---

O que os dados de 2026 realmente mostram

• O que por anos foi anedota e debate agora foi medido em larga escala por organizações com interesses diferentes — algumas até concorrentes —, chegando à mesma conclusão: a IA acelera drasticamente a produção, mas piora a qualidade e a possibilidade de revisão

• Medição da Faros AI (dados de março de 2026)

  • Acompanhamento da transição de baixa adoção de IA para alta adoção de IA em 4.000 equipes e 22.000 desenvolvedores
  • Lado positivo: os desenvolvedores fazem merge de mais PRs e concluem mais trabalho, aumentando a vazão por engenheiro
  • Números negativos
    • 861% de aumento em code churn
    • 242,7% de aumento na razão entre incidentes e PR
    • Taxa de defeitos por desenvolvedor de 9% → 54%
    • 441,5% de aumento no tempo mediano de revisão (tanto o tempo até a primeira revisão quanto o tempo médio de revisão quase dobram)
    • 31,3% de aumento em PRs com merge sem revisão
  • O merge sem revisão não foi uma escolha deliberada; foi o resultado de revisores incapazes de acompanhar o volume, tornando comum o merge de código que ninguém leu
  • Até equipes com práticas de engenharia maduras e disciplinadas foram atingidas da mesma forma; bons processos não conseguiram protegê-las, porque o volume chega mais rápido do que a velocidade com que o processo foi desenhado para absorver

• Estudo da CodeRabbit (dezembro de 2025)

  • Análise de 470 PRs de código aberto (320 coescritos com IA, 150 só por humanos), mostrando que mudanças feitas com IA vieram com cerca de 1,7 vez mais problemas
    • Cerca de 75% mais problemas de lógica e correção
    • Entre 1,5 e 2 vezes mais problemas de segurança
    • Mais de 3 vezes mais problemas de legibilidade
  • David Loker, diretor de IA: "É uma fraqueza previsível e mensurável, e as organizações precisam mitigá-la de forma ativa" — como é uma fraqueza conhecida e localizável, o processo de revisão pode ser ajustado exatamente para atacá-la

• Dados de produtividade da GitClear (até 2025)

  • Usuários que usam IA todos os dias têm cerca de 4 vezes mais produção bruta do que não usuários, mas o ganho real de produtividade em relação a si mesmos um ano antes é de só cerca de 12%
  • É uma estrutura em que humanos precisam revisar 4 vezes mais código
  • Bill Harding observa explicitamente que até esses 12% podem ser em parte viés de seleção, com desenvolvedores mais fortes concentrados no grupo que usa IA

• Relato do GitHub

  • O Copilot Review já foi executado em mais de 60 milhões de vezes, um crescimento de 10x em um ano, e mais de 1 em cada 5 revisões na plataforma já envolve agente
  • Não é mais uma prática de nicho, mas a própria forma como o código está sendo produzido
• Quatro conjuntos de dados e quatro metodologias convergem para uma única conclusão: o gargalo não desapareceu; ele se moveu para a etapa de verificação

Todo mundo está resolvendo problemas diferentes

• A maior parte dos dados alarmantes acima vem de telemetria corporativa e de mantenedores de open source sobrecarregados; boa parte disso não se aplica ao desenvolvedor solo que cria algo usado por poucas pessoas

• Três variáveis que definem sua posição

  • blast radius: o que acontece quando quebra — nada, ou usuários irritados, dinheiro perdido, exposição de PII
  • Vida útil do código: um protótipo descartável que será refeito na semana seguinte, ou uma base que será mantida por anos
  • Número de pessoas que precisam entender: só você, que tem tudo na cabeça, ou uma equipe que compartilha a posse ao longo do tempo

• Solo, greenfield, sem usuários

  • O segundo papel da revisão, que é distribuir conhecimento dentro do time, simplesmente não existe ali (você é o time)
  • A escolha racional: depender fortemente de testes e automação, revisar só o que realmente importa e dar um toque leve no restante
  • Mas isso só funciona se os testes forem de verdade; pular revisão sem rede de segurança não elimina o trabalho, apenas o adia por um custo maior
  • "Sem usuários" é autorização para adiar a revisão, não para pular a verificação

• O perigoso meio do caminho

  • No momento em que o projeto passa a ter usuários, o papel da revisão na detecção de bugs se torna subitamente importante, porque os bugs afetam pessoas, e o papel de compartilhamento de conhecimento também entra em cena
  • Se o time mantém por mais alguns meses os hábitos da fase solo e só depois leva um postmortem, os números da Faros viram o seu painel

• Organizações grandes, base de código antiga, muitos usuários

  • Todos os números de alerta se aplicam com força máxima; mudanças que ninguém entende viram comprehension debt (dívida de compreensão) e acabam se convertendo no incidente de on-call de alguém
  • O ponto central não é "empresas devem ser cautelosas, solos podem relaxar", mas sim que o objetivo da revisão muda conforme a posição, então as regras também precisam mudar
  • Colocar um pipeline corporativo com múltiplos agentes e exigência de evidências em um protótipo de duas pessoas cria atrito sem sentido; aplicar "passou nos testes, pode deployar" a um sistema de pagamentos cria um gerador de incidentes com check verde

O que a revisão realmente faz agora

• Quando um humano escreve código, a intenção vem junto de graça, e as alternativas ponderadas e descartadas ficam na cabeça do autor; por isso, revisar significava inspecionar esse raciocínio
• Os agentes modernos também raciocinam e muitas vezes mostram visivelmente o seu thinking trace, mas esse raciocínio é descartado no momento em que o diff é gerado e não é anexado ao PR
• Além disso, esse é o raciocínio do agente sobre "como implementar", não o julgamento humano sobre "se isso era a coisa certa a fazer"
• Como resultado, a revisão deixa de ser a inspeção do raciocínio diante dos olhos e passa a ser a reconstrução de uma intenção não registrada, tornando-se mais difícil e mais lenta — daí o aumento de 441%

• AI Slop and the Software Commons (artigo de 2026)

  • Análise de 1.154 postagens em 15 threads do Reddit e Hacker News
  • Na expressão de um desenvolvedor, revisar PRs de agentes o transforma no "primeiro humano a ver esse código"
  • Nas palavras do artigo, a revisão "não foi feita para recuperar intenções desaparecidas"

• A solução é um problema de ferramenta

  • A intenção desaparecida pode ser recuperada — o raciocínio existiu, só foi jogado fora
  • Se o agente for obrigado a declarar o que tentou fazer e o que descartou, e isso for capturado como decision log (log de decisões) do PR, grande parte do custo de reconstrução desaparece
• "IA revisando IA" sozinha não é uma resposta completa; um segundo modelo com conhecimento prévio diferente encontra muitos bugs reais, mas não consegue oferecer o julgamento humano de "essa mudança vale a pena ser feita?"

As ferramentas são boas, mas não pelo motivo que anunciam

• Ferramentas dedicadas de revisão com IA já estão boas o suficiente, e a recomendação é rodar ao menos o agente principal de programação — e, se possível, um agente dedicado de revisão — em tudo, inclusive side projects

• Características das principais ferramentas

  • CodeRabbit: a mais amplamente distribuída, 1º lugar em F1 no benchmark independente Martian (jan-fev de 2026), com precisão de cerca de 49% e o melhor recall da indústria
  • Greptile: abre mão de precisão para garantir recall; em um benchmark detectou cerca de 82% dos bugs (contra 44% da CodeRabbit), mas com mais falsos positivos
  • Anthropic Code Review: menos de 1% dos resultados marcados como erro por engenheiros da própria empresa, elevando a taxa de PRs que recebem revisão real de 16% para 54%

• Experimento paralelo com 4 revisores (resultado fora dos vendors)

  • Um engenheiro aplicou CodeRabbit, Sentry Seer, Greptile e Cursor BugBot em paralelo por 3 semanas e meia, sobre 146 PRs reais, encontrando 679 ocorrências
  • Entre 617 locais únicos marcados, 93,4% foram detectados por exatamente uma única ferramenta, 6% por duas, quase nenhum por três e nenhum pelas quatro
  • As quatro ferramentas nunca marcaram juntas a mesma linha uma única vez
  • Cada ferramenta tem forças diferentes: a Greptile quase zera falsos positivos em correção e arquitetura; a CodeRabbit lança a rede mais ampla e oferece correção com um clique; a Seer é forte em gravidade de falhas operacionais
  • A heterogeneidade é o ponto central — quatro cópias do mesmo modelo são um único revisor com uma conta maior; quatro revisores realmente diferentes revelam bugs que nenhum deles encontraria sozinho

• Diretriz prática

  • Não perca tempo procurando uma única ferramenta suprema (ela não existe)
  • Em áreas de alto risco, use intencionalmente duas ferramentas de naturezas diferentes em paralelo (no experimento acima, Greptile para precisão cotidiana + Seer para gravidade operacional)
  • Se você trabalha solo, um bom revisor mais testes de verdade já bastam
  • Independentemente do marketing, meça sempre no seu próprio código, porque todos os resultados são limitados a uma base específica

Devemos delegar mais revisão para a IA?

• Uma pergunta que um ano atrás pareceria heresia agora está surgindo entre engenheiros experientes: a máquina deveria fazer uma parte maior, talvez a maior parte, da revisão?

• O fato desconfortável de que revisão por IA funciona

  • Menos de 1% das descobertas da Anthropic foram marcadas como erro; a IA encontra bugs que humanos deixaram passar e não se cansa nem no 30º PR do dia, justamente quando a confiabilidade humana costuma ser mais baixa
  • Enquanto isso, os humanos não conseguem acompanhar — 31% mais merges sem revisão e tempo de revisão com aumento de três dígitos
  • O enquadramento honesto não é "devemos delegar mais à IA?", mas "a IA já está fazendo isso; a questão é se faremos isso de forma deliberada ou fingindo que humanos ainda leem tudo enquanto deixam passar"

• A visão da loop engineering

  • A premissa do loop é sair de um humano que escreve prompts para o agente e passar a um sistema que escreve prompts para o agente, com um agente judge no centro para decidir se o trabalho foi concluído
  • O revisor passa a ser o próximo papel removido intencionalmente do loop interno por design; um ano depois da automação da escrita, a verificação também é automatizada, e o humano é empurrado para um nível acima

• O risco do loop fechado

  • Se um agente escreve, outro revisa e um terceiro julga, temos um loop fechado de modelos com correlated blind spots (pontos cegos correlacionados) — especialmente quando são da mesma família e concordam com confiança exatamente nos mesmos erros
  • Um "looks good" confiante sem nenhum humano é borrowed confidence (confiança emprestada) — a confiança do sistema vira a minha confiança, e no fim ninguém entende de verdade

• O humano não sai, ele sobe um nível

  • Em vez de ler todo diff, passa a possuir aquilo que não pode ser transferido ao modelo; accountability continua importando
  • O que o humano precisa guardar: o julgamento sobre se esta é a mudança certa a fazer, os gates caros de alto blast radius quando errar é caro, e comportamentos que ninguém especificou por escrito (o modelo só revisa código existente e quase nunca sinaliza requisitos que ninguém chegou a escrever)
  • Saímos de human in the loop para human on the loop — em vez de ler todo PR, a pessoa faz amostragem, spot check e auditoria do sistema, concentrando sua atenção limitada onde errar dói de verdade

• Caso de Kun Chen (ex-engenheiro L8 da Meta, solo builder)

  • Publica cerca de 40 PRs por dia e praticamente parou de fazer revisão de código, executando de 20 a 30 agentes em paralelo
  • Moveu o esforço para o plano (plan) — escreve planos detalhados antes, deixa os agentes rodarem por horas, e a qualidade do plano define por quanto tempo a execução autônoma consegue seguir
  • Ele não parou de verificar; apenas registrou previamente a intenção, resolvendo pela metade o problema do "primeiro humano a ver esse código" (o humano entende o motivo antes, e não só depois)
  • Também não trabalha sem rede de segurança — um gate automático de revisão chamado No Mistakes inspeciona o código antes do merge, e o agente espera para escalar quando fica travado
  • Mas ele é um construtor solo, sem time grande e sem um sistema minado por 10 anos de legado; as condições dele não existem para a maioria dos leitores — copiar isso para um time com muitos usuários é reproduzir os números da Faros no próprio dashboard
• Conclusão do espectro: para solo e sem usuários, deixar quase tudo com a IA já é uma posição defensável em 2026; em contextos grandes e com muitos usuários, a máquina pode fazer a primeira e a segunda passagem e os 90% tediosos, mas caminhos que sustentam carga (load-bearing paths) ainda precisam de humanos reais. A quantidade de humanos não deve ser regulada por culpa, mas por blast radius

O que fazer na prática

• Princípio organizacional: alinhar o esforço de revisão ao custo do erro, puxar o máximo possível do trabalho determinístico barato para o começo do fluxo e reservar a atenção humana para o que só humanos conseguem fazer

• Organize por risco, não por autor (Tier by risk, not by author)

  • Mudanças de configuração podem passar com lint e uma olhada rápida
  • Alterações em caminhos centrais da lógica de negócio exigem pacote completo: tipos, testes, dois revisores de IA diferentes, um humano dono daquele sistema e uma etapa de segurança
  • Não desperdice revisão pesada em boilerplate, e não deixe mudanças grandes passarem só porque os testes ficaram verdes

• Corte rápido a cauda cara (Fast-fail the expensive tail)

  • Early-Stage Prediction of Review Effort (janeiro de 2026), estudo sobre 33.707 PRs escritos por agentes
  • Agentes são fortes em mudanças pequenas e bem definidas, e cerca de 28% dos PRs são merged quase imediatamente; porém, no momento em que recebem feedback subjetivo, tendem a "sumir", abandonando justamente a troca que é o centro da revisão
  • Em um artigo complementar de 2026, a evasão do revisor responde por 38% dos PRs de agentes rejeitados
  • Os pesquisadores construíram um "circuit breaker" que prevê PRs de alto custo de manutenção antes que um humano os veja, usando sinais baratos como tipo de arquivo e tamanho do patch, e isso funcionou bem

• Eleve o padrão do que merece ser revisado

  • A solução não é trancar o repositório, mas recusar revisão de mudanças que chegam sem evidências
  • Exigências antes da revisão: declaração do objetivo da mudança, diff em vez de um bloco de 3.500 linhas sem contexto, saída dos testes e prova de que aquilo foi realmente executado
  • Em vez de absorver pessoalmente o custo caro de reconstruir a intenção, devolva isso ao autor da submissão, que consegue fazer esse trabalho por um custo bem menor

• Mantenha os PRs intencionalmente pequenos

  • PRs gerados por agentes tendem a ser grandes (na Faros, em média 51% maiores), e a participação do revisor é um dos preditores mais fortes de merge
  • PRs grandes e impossíveis de revisar são rejeitados na hora ou, pior, recebem rubber stamp
  • Instrua o agente a criar commits pequenos; um diff que um humano realmente consegue ler agora não é mais cortesia, mas restrição de design

• Leia mudanças em testes com mais cuidado do que mudanças em código

  • Um modo de falha importante dos agentes: mudar o comportamento e depois "consertar" os testes reescrevendo assertions para se adaptarem ao novo comportamento quebrado
  • Um check verde em cima de 200 testes editados não significa nada até que se confirme que as edições estavam corretas; trate diffs que reescrevem muitos testes como sinal de alerta e leia-os primeiro
  • O valor de mutation testing: cobertura diz se a linha foi executada; teste de mutação diz se os testes perceberiam caso aquela linha estivesse errada

• Trate a CI como uma parede imóvel

  • Observe os padrões sobre os quais o GitHub já alerta os revisores: testes removidos, lint pulado, limiar de cobertura reduzido, helpers duplicados que já existiam e entradas não confiáveis fluindo para prompts
  • O último item merece ênfase especial — recursos criados por agentes são uma nova fonte de prompt injection; se texto controlado pelo usuário for passado diretamente para chamadas de LLM, a vulnerabilidade não aparece no diff e fica escondida em dados que só chegarão depois
  • Agentes enfraquecem a CI sem malícia só para conseguir passar (a descida de gradiente encontra o caminho mais barato até o verde), e gates determinísticos são a única parte cujo veredito não pode ser revertido por um parágrafo confiante; por isso, devem permanecer rígidos

• O merge pertence ao humano

  • Modelos não podem ser chamados de madrugada nem responsabilizados, então a posse é de quem aperta o botão de merge
  • Quando a revisão por IA diz calmamente e com confiança "looks good", ela está necessariamente entregando uma confiança que não foi conquistada
  • Trate toda revisão por IA como sensor, nunca como sentença — ela fornece dados, não a decisão

O que isso significa se você lidera uma equipe

• A restrição principal para entregar não é mais quão rápido se escreve código, mas quão rápido uma pessoa confiável consegue se convencer da correção da mudança
• Planejamentos que tratam geração como gargalo e revisão como algo grátis ficam silenciosamente estagnados enquanto o dashboard de velocidade continua verde
• O relatório da Faros afirma explicitamente que, mesmo com mais produção, o trabalho de QA e revisão também aumenta; reduzir headcount de engenharia com base no argumento de que "a IA nos deixou mais rápidos" antes de fechar a lacuna de revisão é perigoso
• O imposto sobre engenheiros seniores representado por tempos de revisão três dígitos maiores cai com mais força exatamente sobre as pessoas que menos deveriam virar gargalo, e isso não aparece em métricas que contam apenas PRs com merge
• Mantenedores de open source bateram primeiro e mais forte nessa parede — um fluxo constante de contribuições plausíveis, porém vazias, consome tempo real de triagem mesmo quando feito com boa intenção; isso é o canário na mina, e as empresas são as próximas da fila
• Quem reage bem trata a capacidade de revisão não como folga liberada pela IA, mas como um recurso real que precisa ser medido, protegido e consumido de propósito

Escrever ficou barato, mas entender não

• Não aceite respostas uniformes nos extremos — para quem trabalha solo e sem usuários, os relatos corporativos de churn e duplicação ainda são risco futuro, não incêndio presente; portanto, faz sentido depender de testes e revisar apenas o que importa, desde que se reconheça com honestidade que o trabalho adiado continua sendo dívida
• Em contextos grandes e com muitos usuários, todos os números de alerta aqui falam de você; a única resposta válida é estratificação, exigência de evidências, um processo de revisão deliberadamente heterogêneo e humanos que assumem a posse do merge
• Em todo o espectro, o que não muda é a economia fundamental — escrever ficou barato, mas entender continuou tão caro quanto sempre foi
• As equipes que vão se destacar daqui para frente não serão as que gerarem mais código, mas as que construírem um sistema de revisão realmente confiável, sem jamais confundir "os testes passaram" com "um humano entende o que isso faz e por quê"
• Como Simon Willison coloca, a essência do trabalho é entregar código com funcionamento comprovado — os agentes não mudaram isso; apenas colocaram a comprovação no centro do trabalho, em vez de tratá-la como tarefa secundária
• A capacidade de entender um sistema profundamente o bastante para se responsabilizar por ele continua sendo a habilidade mais duradoura e interessante do software — e este é um momento excepcional para se tornar extremamente bom nisso