Como revisar código gerado por IA com menos risco

A revisão de um pull request gerado com inteligência artificial começa antes do merge: o revisor precisa entender a intenção da mudança, ler o diff contra essa intenção e decidir se a evidência apresentada sustenta o risco assumido.

O foco não é procurar “erros de IA”. É ligar intenção da mudança, evidências de correção e decisão explícita: aprovar, pedir ajuste, limitar exposição ou rejeitar.

Comece pela intenção verificável da mudança

A descrição “gerado com IA” diz pouco. Ela informa uma origem provável, não uma razão de mudança. Para revisar bem, o primeiro deslocamento é simples: tratar o código como uma proposta de alteração no sistema, não como um artefato especial que deve ser aceito ou recusado por causa da ferramenta usada.

Isso muda a conversa no pull request. Em vez de perguntar se a inteligência artificial escreveu um código elegante, o revisor pergunta qual comportamento deveria mudar. Se essa intenção não aparece, a revisão começa no escuro. Um diff plausível pode esconder mudança de escopo, regra alterada sem explicação, dependência nova, atalho de segurança ou uma refatoração que troca clareza por aparência de sofisticação.

Também não basta dizer que “os testes passaram”. Testes existentes ajudam, mas podem não cobrir a regra alterada. O DORA recomenda testes ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade, e também recomenda manter e revisar as suítes de teste em vez de tratar qualidade como uma etapa posterior ao desenvolvimento DORA. Para a revisão, isso reforça um ponto prático: evidência boa precisa acompanhar a mudança, não apenas o ritual de abrir o pull request.

A decisão de liderança aqui é definir o que um pull request relevante precisa declarar antes da aprovação. Se o time aceita descrições vagas porque o diff “parece bom”, ele transfere julgamento para depois. Se exige intenção verificável, o time entende o que mudou, por que mudou e como sabe que funcionou.

Essa lógica conversa com decisões mais amplas de adoção de IA. Uma organização pode ter uma boa estratégia de inteligência artificial conectada ao negócio, mas ainda falhar na rotina se não traduzir essa estratégia em critérios de aprovação no trabalho cotidiano.

Como transformar a descrição do pull request em uma intenção verificável

Uma intenção verificável descreve comportamento. Ela responde, no mínimo, a quatro perguntas:

• O que deve mudar no sistema?
• Para qual usuário, processo ou integração essa mudança importa?
• Em qual condição a mudança deve acontecer?
• Como o revisor consegue observar que a mudança ocorreu?

Compare duas descrições possíveis.

“Corrige cupom” não é uma intenção verificável. Pode significar cálculo de desconto, mensagem de erro, regra de elegibilidade, arredondamento, uso indevido em produto promocional ou interação com frete.

“Impede que cupons sejam aplicados a produtos já promocionais, mantendo a aplicação normal em produtos sem promoção e exibindo mensagem de cupom inválido quando a regra bloquear o desconto” já permite revisão. O comportamento esperado aparece. O limite de escopo aparece. A condição observável aparece.

Exemplo fictício: validação de cupom em um carrinho

Imagine um pull request em que um agente altera a validação de cupom para impedir desconto em produtos já promocionais. Uma boa revisão começa antes da leitura linha a linha. Ela verifica se a descrição declara a regra nova, se o diff fica restrito ao cálculo de elegibilidade e se a evidência cobre pelo menos três condições: produto promocional, produto sem promoção e cupom inválido.

Uma revisão fraca aceitaria o pull request porque o agente resumiu a tarefa como concluída e os testes antigos passaram. Outra revisão fraca rejeitaria automaticamente porque foi gerado por IA. As duas decisões evitam o ponto central: a mudança proposta corresponde ao comportamento pretendido?

O critério concreto é este: se a descrição não permite escrever ou escolher um teste, executar uma verificação controlada ou inspecionar uma regra específica, ela ainda não é uma intenção revisável.

Quais evidências pedir antes de aprovar o código

Evidência proporcional não significa criar uma cerimônia pesada para qualquer ajuste. Uma mudança pequena de texto, sem impacto em regra ou fluxo, pode ter revisão leve. Uma alteração em autenticação, autorização, cobrança, cálculo, persistência, configuração, dados sensíveis ou dependências pede evidência mais forte.

A pergunta útil não é “tem teste?”. É “a evidência cobre o risco da mudança?”.

Para mudanças de regra de negócio, procure evidência que observe o comportamento final. Testes automatizados ajudam quando expressam a regra nova e seus limites. Teste exploratório pode ser adequado quando a mudança afeta experiência, fluxo ou combinação de estados que a suíte ainda não cobre. Leitura de código é indispensável quando há mudança estrutural, mas não deve substituir a observação do comportamento quando o risco está no resultado.

Alguns tipos de evidência cabem em situações diferentes:

• Teste automatizado para regra estável, comportamento repetível e regressão provável.
• Teste exploratório para fluxo de usuário, usabilidade, combinações de estado e efeitos não previstos.
• Inspeção de código para escopo, dependências, permissões, tratamento de erro e legibilidade.
• Verificação manual em ambiente controlado quando o efeito depende de configuração, dados ou integração.
• Comparação com regra de negócio quando o risco está em interpretar mal uma política interna ou uma condição operacional.

O cuidado é não transformar o checklist em teatro. Se a regra mudou e a evidência é apenas “compilou”, a revisão não demonstrou correção. Se os testes existentes passaram, mas nenhum exercita a regra nova, a evidência pode ser insuficiente. Se a mudança altera uma dependência sem explicar por quê, talvez o problema não seja falta de teste, mas falta de escopo justificável.

A discussão sobre produtividade também pede cautela. Na atualização de fevereiro de 2026, a METR considera os novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades de medir tempo com agentes concorrentes, além de seleção de participantes e tarefas METR. Isso não decide se um pull request específico é bom ou ruim. Apenas lembra que a revisão não deve ser guiada por uma crença genérica de aceleração. O que importa, naquela mudança, é a relação entre intenção, evidência e risco.

Como revisar o caminho de execução sem confundir processo com resultado

Agentes de código costumam deixar rastros: plano de execução, mensagens, comentários, resumo da alteração, lista de arquivos modificados e explicações sobre testes executados. Esses sinais são úteis. Eles ajudam a reconstruir o caminho. Mas caminho não é resultado.

A Anthropic distingue a trajetória de execução de um agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado; avaliações usam entradas, critérios de sucesso e verificadores, e podem exigir várias tentativas Anthropic. Na revisão de código, a analogia é direta: o resumo do agente pode orientar a leitura, mas não deve ser a prova principal.

Há três perguntas que ajudam a separar processo de resultado:

• O agente ou desenvolvedor descreveu passos, ou demonstrou o estado final esperado?
• A evidência observa o sistema em execução, ou apenas a intenção declarada no comentário?
• Existe um verificador independente da própria mensagem do agente, como teste, execução local, ambiente de validação ou inspeção da regra alterada?

Isso não significa desconfiar de tudo. Significa escolher onde colocar confiança. Confiar no resumo automático para localizar a mudança pode ser razoável. Confiar no mesmo resumo para aprovar uma alteração de permissão, cálculo ou persistência é outra coisa.

Na prática, comentários do agente entram como material auxiliar da revisão. O revisor pode usá-los para perguntar: “se esse foi o caminho, onde está a prova de que o resultado final corresponde à intenção?”. Essa pergunta evita tanto o ceticismo genérico quanto a aprovação por fluência.

Essa disciplina torna a revisão mais auditável. Em vez de medir apenas adoção de ferramenta, a empresa passa a observar se seus times conseguem explicitar critérios de correção e risco residual. Para um diagnóstico mais amplo desse ponto de partida, vale conectar a revisão de código a uma leitura de maturidade em IA, sem confundir maturidade com possuir modelo próprio ou automatizar tudo.

Quando pedir mais testes, limitar exposição ou rejeitar

A aprovação não precisa ser binária. Em código gerado por IA, como em qualquer código relevante, a decisão pode ter quatro caminhos: aprovar, pedir ajuste, limitar exposição ou rejeitar.

Peça mais testes quando a intenção está clara, o escopo parece coerente, mas a evidência é fraca. No exemplo fictício do cupom, isso aconteceria se o diff realmente mexe na elegibilidade, mas só existe teste para produto sem promoção. A pergunta do revisor não é “por que a IA errou?”. É “qual limite relevante ainda não foi observado?”.

Limite a exposição quando existe evidência razoável, mas o impacto é sensível ou depende de variáveis de produção. O capítulo de Google SRE sobre lançamentos graduais trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar a exposição e distingue disponibilizar código de ativar funcionalidades, inclusive com uso de configurações para separar essas decisões Google SRE. Para a revisão, isso sugere um caminho prudente: aprovar o merge pode ser diferente de liberar a funcionalidade para todos.

Rejeite quando a intenção é ambígua, o escopo mudou sem explicação ou a evidência não cobre o comportamento alterado. Também faz sentido rejeitar quando o diff introduz dependência, permissão, configuração ou mudança estrutural que não tem relação clara com a intenção declarada. Nesses casos, pedir “mais um teste” pode não resolver. O problema é que a mudança ainda não é revisável.

Aprovar é adequado quando a intenção é verificável, o escopo está preservado, a evidência é proporcional ao risco e o revisor consegue registrar a razão da decisão em uma frase. Essa frase é um bom teste de clareza. Se a aprovação depende de “parece certo”, “o agente explicou bem” ou “sempre funcionou assim”, a decisão ainda está frágil.

Esse raciocínio deve aparecer no roadmap de IA como política de revisão, checklist de pull request ou critério de liberação, não como promessa de ganho automático. Times que adotam IA para desenvolvimento precisam decidir como vão revisar, observar e aprender com as mudanças que aceitam.

Protocolo de revisão: intenção, evidência e decisão

Use este checklist no próprio pull request. Ele não valida qualidade pela origem do código, mas pela relação entre o que se pretendia mudar e o que foi demonstrado.

Intenção verificável

Pergunta: a descrição da mudança diz qual comportamento deve mudar, para quem e em qual condição?

Aprovar se a intenção pode ser conferida por teste, inspeção ou execução controlada. Pedir ajuste ou rejeitar se a descrição fala apenas em “melhorar”, “corrigir” ou “refatorar” sem comportamento observável.

Escopo preservado

Pergunta: o diff altera apenas arquivos, fluxos e dependências compatíveis com a intenção declarada?

Aprovar se mudanças laterais têm justificativa clara e são pequenas o bastante para revisar. Pedir ajuste ou rejeitar se há alterações não explicadas em autenticação, autorização, cálculo, persistência, configuração ou dependências.

Evidência proporcional

Pergunta: a evidência cobre o risco da mudança, e não apenas o caminho feliz?

Aprovar se há teste ou verificação suficiente para o comportamento principal e pelo menos um limite relevante. Pedir ajuste ou rejeitar se a evidência é só “compilou”, “o agente disse que terminou” ou “os testes existentes passaram” quando a regra mudou.

Resultado no ambiente

Pergunta: a revisão confirma o efeito final esperado, não apenas os passos executados pelo agente ou pelo desenvolvedor?

Aprovar se o resultado pode ser observado por teste, execução local, ambiente de validação ou verificador definido. Pedir ajuste ou rejeitar se a comprovação depende somente de mensagens, comentários ou resumo automático.

Decisão explícita

Pergunta: o revisor consegue registrar por que aprovou, pediu ajuste, limitou exposição ou rejeitou?

Aprovar se a decisão cabe em uma frase ligada à intenção e à evidência. Pedir ajuste ou rejeitar se a aprovação depende de confiança genérica na ferramenta, no autor ou no volume de testes.

Como documentar a decisão da revisão sem burocratizar o time

O registro não precisa virar uma nova cerimônia. Um comentário curto no pull request já cria um registro útil para aprendizado posterior.

Um bom registro contém quatro partes:

• Intenção: qual comportamento deveria mudar.
• Evidência aceita: qual teste, verificação ou inspeção sustentou a decisão.
• Risco conhecido: qual limite ainda merece atenção.
• Próxima observação: o que será acompanhado depois do merge ou durante a exposição controlada.

No exemplo fictício do cupom, um registro adequado poderia dizer: “Aprovado porque a mudança limita cupom em produto promocional, o diff ficou restrito à elegibilidade e os testes cobrem produto promocional, produto sem promoção e cupom inválido. Acompanhar mensagens de erro no fluxo do carrinho na validação”.

Esse comentário não garante ausência de defeitos. Nenhuma revisão garante. Mas ele melhora a qualidade da decisão porque deixa claro o que foi aceito, com base em quê e qual risco residual permanece. Se houver regressão depois, o time tem um ponto de partida para aprender. Se a mudança funcionar como esperado, o time também aprende quais evidências foram suficientes para aquele tipo de risco.

A revisão termina com uma frase clara no pull request: intenção verificada, evidência aceita, risco conhecido e decisão tomada. Quando essa frase não existe, a revisão ainda não terminou.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Qualidade de software com IA: testes, avaliação e responsabilidade
• Como testar código gerado por IA
• Como definir critérios de aceite para funcionalidades de IA

Fontes

• DORA: automação de testes
• Anthropic: avaliações de agentes
• METR: limites da medição de produtividade
• Google SRE: lançamentos graduais