Você Ainda Deve Revisar o Código do Seu Agente de IA?

A discussão começa da mesma maneira em toda equipe. Um lado diz que os agentes agora entregam um código mais limpo do que metade dos pull requests que costumávamos aprovar sem olhar, então por que ainda estamos lendo cada linha? O outro lado diz que porque somos nós que assinamos.

Ambos os lados estão certos. É exatamente por isso que a discussão nunca termina. Ela não termina porque a pergunta está errada, e uma vez que você corrige a pergunta, a resposta se torna quase entediante.

O caso a favor de enviar sem ler cada linha

Comece com a versão mais forte do argumento otimista, porque é mais forte do que a maioria dos revisores admite.

Em uma tarefa delimitada com uma especificação clara e um conjunto de testes, um agente de codificação moderno produz um código mais consistente do que a média de um humano trabalhando sob pressão. Ele não se entedia no caminho de erro. Ele escreve a verificação nula às 18h de uma sexta-feira. Ele segue as convenções do projeto que lhe foram dadas, toda vez, sem as pequenas rebeliões silenciosas que um desenvolvedor cansado permite a si mesmo.

A revisão humana também já estava quebrada antes da chegada dos agentes. Qualquer um que tenha trabalhado em uma equipe real conhece o reflexo LGTM: a atenção do revisor colapsa após algumas centenas de linhas, e as aprovações que se seguem são sociais, não técnicas. Não perdemos uma era de revisão rigorosa. Perdemos um ritual que já era em sua maioria teatro.

Então, há o volume. Um desenvolvedor executando cinco agentes em paralelo gera mais diffs por hora do que qualquer humano pode ler cuidadosamente. Se sua regra é "ler tudo", você se reinstalou silenciosamente como o gargalo que acabou de automatizar. Um humano que lê rapidamente um diff de 900 linhas produz uma assinatura sem produzir conhecimento, e isso é pior do que não revisar nada, porque fabrica uma garantia onde não há nenhuma.

O caso para manter um humano no diff

Agora o outro lado, que também é mais forte do que os entusiastas admitem.

A responsabilidade não se transfere. O modelo não é chamado às 3 da manhã. Ele não está na revisão do incidente, não fala com o cliente cujos dados vazaram, e não carrega a consequência da mudança para o próximo trimestre. Quem mescla é responsável pelo resultado, e revisar é como a propriedade é exercida em vez de apenas declarada.

Revisores agentes falham na mesma direção que autores agentes. Este é o argumento que realmente resolve a proposta de "apenas deixe outro agente revisar". Dois agentes da mesma família de modelos, entregues ao mesmo contexto, compartilham priors, compartilham dados de treinamento e compartilham pontos cegos. Seus erros estão correlacionados. Um segundo agente irá felizmente detectar um teste ausente ou um erro não tratado, e irá aprovar a sutil incompreensão do seu domínio que produziu o bug em primeiro lugar, porque ele fez a mesma incompreensão. Dois revisores que estão errados na mesma direção não somam a uma revisão.

As medições também não são lisonjeiras. Dados da indústria mostram que revisores trocam significativamente mais rodadas em mudanças geradas por IA do que em mudanças escritas por humanos: o código chega mais rápido e leva mais tempo para se tornar confiável. Um estudo de janeiro de 2026 foi mais longe e descobriu que mudanças geradas por agentes carregam mais redundância e mais dívida técnica acumulada por mudança do que as escritas por humanos, enquanto revisores relatam se sentir melhores ao aprová-las. Essa lacuna, entre quão bom o código parece e quão bom ele é, é todo o risco em uma frase.

O debate está mal estruturado

Aqui está a reformulação que encerra a reunião.

Você não está revisando o código porque desconfia do autor. Você está revisando porque é você quem assina. Essas são atividades completamente diferentes, e toda a discussão vem da confusão entre elas.

Uma vez que você vê dessa forma, "o agente é melhor do que um humano" deixa de ser a pergunta decisiva. A pergunta decisiva é: se essa mudança estiver errada, quão caro é descobrir, e quão caro é desfazer? Um erro de digitação em um título de marketing é descoberto em segundos e revertido em segundos. Uma verificação de permissão invertida em um middleware de autorização é descoberta por um cliente, ou por um regulador, e nunca é realmente revertida, porque, nesse ponto, os dados já foram lidos.

Portanto, a resposta não é "revisar tudo" nem "confiar no agente". É:

Você para de revisar linhas. Você começa a revisar riscos.

Concretamente, a revisão se move do meio do trabalho para suas duas extremidades. Antes: leia o plano, porque um plano errado executado perfeitamente é o modo de falha mais caro que existe, e um plano tem quinze linhas em vez de novecentas. Depois: leia o diff em proporção ao raio de explosão. Entre eles, as linhas pertencem à máquina.

Como "o agente errou" realmente se parece

A coisa mais útil que você pode trazer de volta para sua equipe não é uma opinião, é uma lista de sinais objetivos. Não "o código parece estranho", mas sinais que você pode verificar em um diff em menos de um minuto. Estes são os que conquistaram seu lugar.

1. Os testes mudaram no mesmo commit que o código que cobrem. O verde foi construído, não observado. Este é o sinal de maior relevância na lista, e é o primeiro a ser verificado.
2. Uma asserção foi enfraquecida ou um teste foi desativado. Um skip, um only, uma asserção ampliada para aceitar o que o novo código acontece de retornar, um try/catch que engole o erro que o teste deveria expor.
3. O diff é maior que a tarefa. Arquivos que ninguém pediu foram tocados. O aumento de escopo em um agente não é entusiasmo, é um sinal de que o agente reinterpretou o objetivo em algum momento do caminho.
4. Uma superfície inventada. Um método de API, uma opção de configuração ou um caminho que não existe. Ele compila na cabeça do agente e em nenhum outro lugar.
5. O ambiente foi corrigido em vez do código. Um caminho absoluto codificado, um valor específico da máquina, um token pessoal, um nome de usuário. O sintoma desapareceu na máquina do agente e se transferiu para as de todos os outros.
6. Uma dependência apareceu sem ser solicitada. Nova cadeia de suprimentos, nova licença, nova superfície de manutenção, decidida por algo que não irá mantê-la.
7. Duplicação em vez de reutilização. Ele reimplementou um helper que já existia vinte linhas atrás. Este é o mecanismo por trás da dívida medida: cada mudança parece razoável localmente e a base de código ganha silenciosamente uma terceira maneira de fazer a mesma coisa.
8. O resumo não corresponde ao diff. "Corrigido e testado" quando nenhum teste foi executado. A narração é gerada com a mesma confiança, independentemente de o trabalho ter acontecido ou não, então trate-a como uma afirmação a ser verificada, nunca como um relatório.
9. As instruções pararam de ser seguidas. Pequenas convenções silenciosamente abandonadas é como uma sessão se degrada antes de começar a alucinar abertamente. Se você usar um canário em seu arquivo de contexto, isso é exatamente o que ele está lá para capturar.
10. Terreno sensível foi tocado de passagem. Uma leitura de .env, uma nova chamada de rede de saída, uma nova linha de log carregando dados do usuário, uma migração agrupada em um commit de recurso.

Note o que não está na lista: estilo, nomenclatura, formatação, "eu teria feito diferente". Esses sempre foram a parte mais fraca da revisão humana e agora são genuinamente um desperdício de um humano. Exclua-os da sua revisão e você recupera a atenção que precisa para os dez itens acima.

Quanto de revisão uma mudança merece?

O raio de explosão, não o tamanho do diff, decide. A tabela que sua equipe pode adotar esta tarde:

O tamanho do diff lhe diz quanto tempo a revisão leva. O raio de explosão lhe diz se é opcional.

As linhas não são sobre níveis de confiança. Elas são sobre o custo de estar errado, que é uma propriedade do código e não de quem o escreveu. É isso que torna a tabela utilizável: ninguém precisa concordar sobre quão bons os agentes são para concordar com a tabela. Se sua equipe estiver em um impasse sobre a questão filosófica, pule-a e negocie as linhas em vez disso. Você ficará surpreso com quão rápido isso converge.

Se seu produto lida com dados pessoais na Europa, uma linha a mais é escrita para você por lei em vez de por gosto: o que um recurso construído por IA deve respeitar sob o GDPR não é uma decisão de julgamento, e "um agente escreveu isso" nunca foi uma defesa.

O que muda quando cinco agentes rodam ao mesmo tempo

Tudo acima assume que você pode ver a mudança. Com agentes paralelos, essa suposição quebra primeiro, e quebra de uma maneira específica: o diff deixa de ter um único autor. Três agentes tocaram a árvore de trabalho desde seu último commit, e a pergunta "quem mudou este arquivo, e como parte de qual tarefa" não tem mais uma resposta óbvia. Revisar sem atribuição não é revisão, é arqueologia.

Esse é um problema de ferramentas, e é a razão pela qual AgentsRoom coloca a revisão onde os agentes estão, em vez de no final de um pull request:

• Review Mode mostra cada mudança que seus agentes fizeram, como um diff legível, antes que qualquer coisa seja comprometida. É o passo "ler o diff em proporção ao raio de explosão", feito barato o suficiente para que as pessoas realmente o façam.
• Revisão por agente filtra esse diff por agente e permite que você comprometa o trabalho de cada agente separadamente. Cinco agentes paralelos se tornam cinco unidades revisáveis em vez de uma árvore de trabalho ilegível, e uma mudança ruim permanece atribuível à tarefa que a produziu.
• A mensagem de commit é gerada a partir do diff real com o botão de brilho no campo de commit, então a história descreve o que mudou em vez do que o agente disse que estava fazendo. Essa distinção importa às 3 da manhã, seis meses depois.

Nada disso substitui o julgamento. Remove as desculpas para não exercê-lo.

Faça a máquina ser responsável pelas linhas

Se você quer parar de ler linhas, algo mais precisa lê-las. Na prática, quatro coisas carregam essa carga:

Testes que o agente não escreveu na mesma respiração que o código. Escritos primeiro, ou escritos por um agente diferente, ou no mínimo revisados como sua própria mudança. No momento em que o código e seus testes vêm da mesma geração, eles param de ser evidências independentes.

Um revisor com um modelo diferente. Esta é a resposta prática para o problema de falha correlacionada. Se um segundo agente revisa, execute-o em um provedor ou família de modelos diferente do autor. Você não irá decorrelacionar os erros completamente, mas um revisor da família Codex em código escrito por Claude captura uma classe de problema mensuravelmente diferente do que um revisor do mesmo modelo, precisamente porque não compartilha os priors do autor.

Portões que não se cansam. Tipos, lint, verificação de segredos, pisos de cobertura, um CI que recusa uma migração agrupada com um recurso. Cada regra que você pode expressar como um portão é uma regra que você nunca precisa notar novamente.

Um loop que se fecha sobre si mesmo. Um agente que constrói, executa seu próprio trabalho contra o plano e itera antes de entregar qualquer coisa remove toda a categoria de "não executou nem mesmo" da sua revisão. Esse é o loop de agente autocorrigível, e é a diferença entre um agente que produz um diff e um que produz um resultado. Isso não responde à pergunta de se um humano deve assinar. Apenas significa que o humano está assinando algo que já funciona.

Então, você ainda revisa?

Sim, e menos do que faz hoje.

Pare de ler linhas para se sentir responsável. Leia o plano antes, porque é onde os erros caros são cometidos. Leia o diff depois em proporção ao que pode quebrar, usando a escada em vez do seu humor. Mantenha um humano, pessoalmente, em autenticação, pagamentos, permissões, dados pessoais e qualquer coisa irreversível, porque um modelo não pode manter responsabilidade e um segundo agente compartilha os pontos cegos do primeiro. Dê tudo o mais para testes, tipos, portões e um revisor que não compartilha o modelo do autor.

As equipes que erram isso falham em uma das duas direções, e ambas são evitáveis. Uma revisa tudo, se torna o gargalo e começa a aprovar silenciosamente sem ler, que é o pior de ambos os mundos. A outra não revisa nada, envia rapidamente por dois meses e depois passa um trimestre pagando dívidas que nunca viu acumular.

O debate na sua reunião não é realmente sobre se os agentes são bons. É sobre quem está disposto a assinar. Responda a isso, e a política de revisão se escreve sozinha.

Perguntas frequentes

Você ainda deve revisar o código gerado por IA?

Sim, mas não linha por linha em tudo. Revise o plano antes que o agente comece, depois revise o diff em proporção ao que a mudança pode quebrar. Textos e CSS recebem uma leitura rápida. Autenticação, pagamentos, permissões, dados pessoais e migrações são lidos linha por linha por um humano, toda vez.

Um agente de IA pode revisar o código de outro agente de IA?

Ajuda, mas não é um substituto para um humano em código arriscado. Dois agentes da mesma família de modelos, dados ao mesmo contexto, tendem a falhar na mesma direção. Seus erros estão correlacionados, então um segundo agente captura erros de digitação e testes ausentes, mas compartilha os pontos cegos que produziram o bug. Se você usar um revisor agente, execute-o em um modelo diferente do autor.

Como você sabe se um agente de IA cometeu um erro?

Procure sinais objetivos no diff em vez de ler por estilo. O mais forte: testes mudaram no mesmo commit que o código que cobrem, o que significa que o verde foi construído e não observado. Outros incluem aumento de escopo, uma asserção desativada ou enfraquecida, uma API inventada, um caminho local codificado e um resumo que não corresponde ao diff.

Os agentes de IA substituirão revisores humanos de código?

Eles já substituíram a maior parte da leitura de linhas. Eles não podem substituir a assinatura. A responsabilidade não se transfere para um modelo, então um humano ainda possui a decisão de mesclar qualquer coisa que seja difícil de reverter.

Você precisa revisar o código de IA linha por linha?

Apenas onde o raio de explosão justifica. A revisão linha por linha não escala além de alguns agentes rodando em paralelo, e um humano que lê rapidamente um diff de 900 linhas às 18h produz uma assinatura sem produzir conhecimento. Dedique essa atenção às mudanças que são caras para desfazer.

O que nunca deve ser mesclado sem revisão humana?

Qualquer coisa que toque autenticação, pagamentos, permissões, dados pessoais, migrações de banco de dados, caminhos de exclusão e infraestrutura. Esses compartilham uma propriedade: o custo de estar errado não é proporcional ao tamanho do diff.