A IA escreveu o código. Quem responde pelo deploy?

Um pull request pode chegar com implementação, testes e uma explicação convincente em poucos minutos. Quem revisa recebe um problema menos conveniente. Precisa descobrir se aquelas mudanças fazem o que o produto exige, inclusive quando alguma coisa falha.

O volume de código pronto para revisão pode crescer sem que a capacidade de entendê-lo acompanhe. Aprovar tudo porque o teste passou é uma resposta tentadora. É também uma forma de entregar a decisão a um teste que talvez tenha repetido a mesma suposição errada do código.

O próprio GitHub documenta que a revisão do Copilot pode deixar passar problemas e sugerir correções desnecessárias. A revisão humana continua fazendo parte do processo. Nossa recomendação é organizar essa revisão pelo comportamento que precisa sobreviver ao deploy.

Comece pela regra que não pode quebrar

Imagine uma integração que recebe a confirmação de uma inscrição e cria um ingresso. O provedor pode reenviar o mesmo evento. A regra do produto é que uma inscrição gere um único ingresso, mesmo com entregas repetidas.

Uma implementação pode consultar o evento, verificar que ele ainda não existe e então salvar o ingresso. Parece correto ao ler cada linha. Duas requisições simultâneas, porém, podem fazer a consulta antes de qualquer gravação.

A revisão precisa perguntar onde o sistema garante a unicidade. Uma restrição no banco pode proteger a gravação. Se o fluxo também envia um e-mail, a transação local não torna o envio externo atômico. É preciso definir como registrar o trabalho pendente e repetir o envio sem criar outro ingresso.

Esse é um exemplo hipotético. O ponto é procurar a decisão que depende do comportamento do sistema inteiro. A clareza de uma função isolada não resolve concorrência.

Leia o caminho completo da mudança

Siga o dado desde a entrada até o efeito final. No exemplo do ingresso, a leitura inclui a verificação de origem do evento, a identificação da inscrição e a gravação. Depois vem a notificação.

Confira os arquivos existentes que o código novo chama. Uma função chamada createTicket pode enviar e-mail internamente. Um tratamento de erro pode converter uma falha em resposta de sucesso. Esses detalhes mudam o que acontece quando o provedor tenta novamente.

Peça uma explicação curta para cada dependência nova. Se uma biblioteca entrou apenas para substituir uma função já disponível, retire-a. Toda dependência adicionada continuará exigindo atenção depois que o pull request fechar.

Faça os testes discordarem da implementação

Comece escrevendo resultados esperados sem copiar a estrutura do código. Para essa integração, uma revisão poderia exigir:

Situação	Resultado esperado
O mesmo evento chega duas vezes	Um único ingresso
Duas entregas chegam juntas	A mesma regra de unicidade continua válida
O ingresso foi salvo e a notificação falhou	A notificação pode ser retomada sem duplicar o ingresso
O evento tem origem inválida	Nenhum ingresso criado

O teste de concorrência precisa exercitar a proteção usada na gravação. Um banco simulado que devolve sempre a resposta esperada pode esconder justamente o defeito que você quer encontrar.

Quando estiver corrigindo um bug, confirme que o teste falha sem a correção. Esse passo evita comemorar um teste que nunca observou o problema.

Reduza a mudança até conseguir explicá-la

Uma alteração de comportamento junto com uma reorganização de pastas e uma atualização de dependências custa mais para revisar. Peça entregas separadas quando essas mudanças forem independentes.

Antes de aprovar, a pessoa responsável deve conseguir descrever o efeito para o usuário, a falha mais provável e como perceber essa falha depois da publicação. Não precisa decorar cada linha. Precisa saber onde procurar quando chegar o primeiro relato.

Anote também o limite do rollback. Reverter código não desfaz automaticamente uma migração destrutiva nem recolhe um e-mail enviado. Essas consequências pertencem à decisão de publicar.

A IA pode ajudar a investigar o diff e propor casos esquecidos. Use essa ajuda. O critério de aprovação continua sendo uma mudança que alguém consegue explicar e sustentar quando o caminho feliz acaba.