Código revisado por IA ainda precisa de uma pessoa responsável

Ferramentas de revisão com inteligência artificial conseguem apontar problemas e sugerir correções, inclusive em pull requests. Isso pode economizar tempo na análise, mas um comentário tecnicamente plausível não é prova de que a mudança preserva o comportamento esperado.

A distinção importa especialmente quando uma alteração atravessa dados sensíveis, autorização, contratos de API e regras que vivem fora do arquivo modificado.

Comece pela intenção da mudança

Antes de revisar a implementação, peça uma descrição verificável do comportamento que deveria mudar.

Uma revisão pode usar quatro perguntas simples:

1. Qual problema observável a alteração resolve?
2. O que deve permanecer exatamente como antes?
3. Quais fluxos e consumidores dependem desse contrato?
4. O que acontecerá se for necessário reverter a entrega?

Sem essas respostas, até testes verdes podem validar a solução errada.

O exemplo que um teste feliz pode ignorar

Imagine uma API que consulta documentos associados a uma organização. O agente propõe uma função simplificada:

// Exemplo conceitual: falta conferir o escopo da organização.
async function getDocument(documentId: string) {
  return database.document.findUnique({
    where: { id: documentId }
  });
}

Se a pessoa autenticada só pode acessar documentos da própria organização, procurar apenas pelo identificador não protege esse limite.

O contrato seguro depende de uma política de autorização apropriada, aplicada no ponto de acesso aos dados e verificada com casos negativos. Uma versão ilustrativa de consulta escopada seria:

async function getDocument(documentId: string, tenantId: string) {
  return database.document.findFirst({
    where: { id: documentId, tenantId }
  });
}

Esse segundo trecho não implementa autenticação nem substitui a política de autorização: ele demonstra apenas que o escopo precisa acompanhar a consulta. O tenantId deve vir de uma identidade já validada, nunca de um parâmetro livre fornecido pelo solicitante.

Um teste que consulta um documento permitido pode passar nos dois exemplos. O caso relevante é tentar consultar um documento de outra organização e verificar se o acesso é negado.

Cinco dimensões de revisão

Dimensão	Pergunta objetiva
Contrato	A resposta, os erros e os efeitos colaterais permanecem compatíveis?
Autorização	Quem executa a ação pode acessar cada recurso envolvido?
Fronteiras	O que ocorre com dados ausentes, duplicados ou fora do limite?
Operação	A mudança pode gerar lentidão, volume adicional ou falhas difíceis de detectar?
Reversão	Há um procedimento confiável para recuperar o comportamento anterior?

Essas perguntas não precisam transformar todos os PRs em cerimônias extensas. O grau de rigor deve acompanhar o impacto da alteração.

Como usar a revisão automática de forma útil

A análise assistida funciona melhor como uma fonte adicional de hipóteses. Em vez de aceitar qualquer sugestão, peça que ela identifique o risco, o trecho afetado, um caso de teste reproduzível e a condição que faria o alerta ser falso.

Comentários podem ser classificados em três grupos: correções com evidência reproduzível, hipóteses que precisam de confirmação e sugestões de estilo sem impacto funcional comprovado.

Essa triagem é valiosa porque impede que a quantidade de comentários vire substituta da qualidade da revisão.

Antes do merge

A pessoa responsável pela integração deveria conseguir explicar a mudança, apontar os testes relevantes e identificar o caminho de recuperação. O papel de um agente pode ser escrever, analisar, simular e propor; a responsabilidade técnica precisa continuar atribuída de maneira explícita.