Como revisar código gerado por IA

Para revisar código gerado por IA, comece pelo que mudou — quais arquivos e por quê — e depois teste o comportamento você mesmo antes de ler qualquer linha de código. Em seguida, verifique as áreas em que o código de IA mais costuma falhar: falta de checagens de permissão no servidor, segredos expostos ao navegador, entradas não validadas, pacotes ou funções que não existem e edições em coisas que você nunca pediu para tocar.

A IA escreve código que normalmente funciona e muitas vezes parece organizado. Isso facilita aprovar sem realmente verificar. Este guia é uma rotina de revisão que funciona tanto para quem lê código fluentemente quanto para quem não lê nada.

Dimensione a revisão ao risco

Nem toda mudança exige a mesma atenção.

Passo 1: veja o que mudou

Antes de julgar o código, obtenha a lista de alterações:

• Se o projeto está no Git, veja o diff: os arquivos e linhas alterados desde o último commit. Veja como usar Git com um app criado com IA.
• Ou pergunte diretamente à IA:

Liste todos os arquivos que você alterou na última mudança e, para cada um, explique em uma frase o que mudou e por quê.

Sinais de alerta nesta etapa: arquivos não relacionados ao pedido, arquivos excluídos, mudanças em configurações ou dependências que você não pediu.

Passo 2: teste o comportamento primeiro

Ler o código diz o que ele deveria fazer; testar diz o que ele faz de fato. Antes de ler:

• Teste a mudança como um usuário comum, no desktop e em uma tela do tamanho de celular.
• Teste com entradas erradas: campos vazios, textos muito longos, números negativos, uma data no passado.
• Teste deslogado e como outro usuário.
• Refaça os fluxos mais importantes: cadastro, login, a ação principal, pagamento.

Se o teste falhar, você economizou tempo de leitura — relate com clareza e deixe a IA corrigir. Veja como escrever um bom relatório de bug.

Passo 3: verifique as permissões no servidor

O item mais importante a checar. Ferramentas de IA muitas vezes escondem um botão na página, mas deixam o servidor disposto a executar a ação para qualquer um que pedir.

Para cada rota ou função que lê ou altera dados, pergunte:

• Ela verifica se o usuário está logado?
• Ela verifica se este usuário pode acessar este registro?
• Essa verificação está no servidor, não apenas na página?

Para cada rota de API que você adicionou ou alterou, diga qual checagem de permissão ela faz no servidor, citando a linha. Sinalize qualquer rota sem essa checagem.

Depois teste: entre como usuário A, anote o ID de um registro, entre como usuário B e solicite esse registro. A checklist de segurança para apps criados com IA traz o teste completo.

Passo 4: procure segredos expostos

• Pesquise nos arquivos alterados qualquer coisa que pareça uma chave ou senha.
• Verifique se as chaves secretas são lidas de variáveis de ambiente e usadas apenas no código do servidor.
• Fique atento a prefixos públicos como VITE_ ou NEXT_PUBLIC_ em variáveis secretas — eles são incorporados ao código do navegador.

Veja como manter suas chaves de API seguras.

Passo 5: verifique entradas e erros

• Validação no servidor. Verificações do navegador podem ser contornadas. Campos obrigatórios, tamanhos, formatos e valores permitidos também devem ser checados pelo servidor.
• As consultas ao banco usam parâmetros, não texto montado juntando a entrada do usuário à consulta.
• Erros não são engolidos. Um try/catch que não faz nada esconde falhas. Os erros devem ser registrados, e o usuário deve ver uma mensagem simples.
• Nenhum detalhe interno exibido ao usuário — rastreamentos de pilha e erros do banco pertencem aos logs.

Passo 6: confirme que é real

Modelos de IA às vezes produzem código que parece correto, mas se refere a coisas que não existem.

• Pacotes: cada nova dependência deve ser um pacote real, mantido, com exatamente esse nome. Desconfie de nomes que pareçam erros de digitação de pacotes populares.
• Funções e opções de API: se o código chama uma função de biblioteca ou uma opção de API externa que você nunca viu, consulte a documentação oficial.
• Código provisório: pesquise por TODO, mock, fake, dados de exemplo fixos no código ou funções que retornam um valor fixo.

Você adicionou algum pacote novo? Para cada um, informe o nome exato, para que serve e se poderíamos passar sem ele.

Passo 7: verifique se encaixa

O código pode funcionar e mesmo assim tornar o app mais difícil de alterar depois:

• Duplicação. A mesma lógica copiada em vários lugares vai divergir com o tempo.
• Consistência. Deve seguir os padrões que o resto do app usa.
• Tamanho. Um pedido de 20 linhas que gerou 600 linhas merece uma pergunta.
• Código morto. Versões antigas deixadas ao lado das novas.

Há algum código no projeto que ficou sem uso por causa desta mudança, ou lógica duplicada em outro lugar? Não altere nada; apenas liste.

Erros comuns

• Aprovar porque parece limpo. Código bonito ainda pode pular uma checagem de permissão.
• Ler em vez de testar. Teste primeiro; leia depois.
• Testar só o caminho feliz. Tente entradas ruins, o usuário errado e o cenário deslogado.
• Ignorar alterações em arquivos não relacionados. Pergunte por que cada arquivo mudou.
• Confiar totalmente em uma autorrevisão. Use a revisão da IA como primeira etapa e confirme testando.
• Revisar uma semana de mudanças de uma vez. Revise pequenas mudanças conforme acontecem.

Checklist

• Sei quais arquivos mudaram e por quê, e nada não relacionado mudou.
• A mudança funciona no desktop e no celular, com entradas ruins, deslogado e como outro usuário.
• Toda rota de dados verifica login e propriedade no servidor.
• Nenhum segredo no código ou nos pacotes do navegador.
• A entrada é validada no servidor; as consultas usam parâmetros.
• Erros são registrados, não engolidos, e não são mostrados em detalhe ao usuário.
• Novos pacotes são reais e necessários; nenhuma função inventada ou código provisório permanece.
• Mudanças de alto risco passaram por uma leitura cuidadosa e, quando necessário, por uma segunda pessoa.

Revisando código no Mythex

• O modo Ask responde perguntas sobre o código sem editá-lo — ideal para pedidos como “explique cada mudança” e “quais rotas não têm checagem de permissão”. Veja Chat.
• A visualização de código mostra a árvore de arquivos, o editor e o terminal em todos os planos (somente leitura no Free, editável no Pro), para que você mesmo leia o que mudou. Veja Editor de código.
• /test faz o agente clicar na pré-visualização como um usuário e relatar os fluxos quebrados.
• Checkpoints permitem reverter uma mudança que não passou na revisão.

Se um desenvolvedor estiver revisando para você, como trabalhar com um desenvolvedor em um app criado com IA explica a passagem de trabalho; se a revisão encontrar um bug, veja como depurar um app criado com IA.

Perguntas