Como Rever Código Gerado por IA

Para rever código gerado por IA, comece pelo que mudou — que ficheiros e porquê — e teste o comportamento antes de ler qualquer linha. Depois, verifique as áreas onde o código de IA mais vezes falha: falta de verificações de permissões no servidor, segredos expostos ao navegador, dados não validados, pacotes ou funções que não existem e edições a coisas que nunca pediu para tocar.

A IA escreve código que normalmente funciona e muitas vezes parece organizado. Isso facilita aprovar sem verificar de facto. Este guia é uma rotina de revisão que funciona quer leia código com fluência quer não o leia de todo.

Ajuste a revisão ao risco

Nem todas as alterações precisam da mesma atenção.

Passo 1: Veja o que mudou

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

• Se o projeto estiver no Git, veja o diff: os ficheiros e linhas alterados desde o último commit. Veja como usar o Git numa app criada com IA.
• Ou pergunte diretamente à IA:

Lista todos os ficheiros que alteraste na última alteração e, para cada um, explica numa frase o que mudou e porquê.

Sinais de alerta nesta fase: ficheiros não relacionados com o pedido, ficheiros apagados, alterações a configurações ou dependências que não pediu.

Passo 2: Teste primeiro o comportamento

Ler o código diz-lhe o que deve fazer; testar diz-lhe o que faz de facto. Antes de ler:

• Experimente a alteração como um utilizador normal, em desktop e num ecrã do tamanho de um telemóvel.
• Experimente com dados errados: campos vazios, textos muito longos, números negativos, uma data no passado.
• Experimente com a sessão terminada e como outro utilizador.
• Repita os fluxos mais importantes: registo, início de sessão, a ação principal, pagamento.

Se o teste falhar, já poupou tempo de leitura — reporte com clareza e deixe a IA corrigir. Veja como escrever um bom relatório de erro.

Passo 3: Verifique as permissões no servidor

É a coisa mais importante a verificar. As ferramentas de IA costumam esconder um botão na página, mas deixam o servidor pronto a executar a ação para quem a pedir.

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

• Verifica se o utilizador tem sessão iniciada?
• Verifica se este utilizador tem permissão para aceder a este registo?
• Essa verificação está no servidor, e não apenas na página?

Para cada rota de API que acrescentaste ou alteraste, diz-me que verificação de permissões faz no servidor, citando a linha. Assinala qualquer rota sem essa verificação.

Depois, teste: inicie sessão como o utilizador A, anote o ID de um registo, inicie sessão como o utilizador B e peça esse registo. A lista de verificação de segurança para apps criadas com IA tem o teste completo.

Passo 4: Procure segredos expostos

• Procure nos ficheiros alterados qualquer coisa que pareça uma chave ou palavra-passe.
• Confirme que as chaves secretas são lidas de variáveis de ambiente e usadas apenas no código do servidor.
• Atenção aos prefixos públicos como VITE_ ou NEXT_PUBLIC_ em variáveis secretas — esses valores são incluídos no código que corre no navegador.

Veja como manter as chaves de API seguras.

Passo 5: Verifique os dados e os erros

• Validação no servidor. As verificações do navegador podem ser ignoradas. Campos obrigatórios, tamanhos, formatos e valores permitidos devem ser verificados também pelo servidor.
• As consultas à base de dados usam parâmetros, e não texto construído ao juntar dados do utilizador numa consulta.
• Os erros não são engolidos. Um try/catch que não faz nada esconde falhas. Os erros devem ser registados, e o utilizador deve ver uma mensagem simples.
• Nenhum detalhe interno é mostrado aos utilizadores — rastos de execução e erros da base de dados pertencem aos registos.

Passo 6: Confirme que é real

Os modelos de IA por 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 parecem erros de escrita 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 nunca viu, confirme na documentação oficial.
• Código de exemplo: procure TODO, mock, fake, dados de exemplo fixos ou funções que devolvem sempre o mesmo valor.

Acrescentaste novos pacotes? Para cada um, indica o nome exato, para que serve e se conseguimos dispensá-lo.

Passo 7: Confirme que encaixa

O código pode funcionar e, mesmo assim, tornar a app mais difícil de alterar mais tarde:

• Duplicação. A mesma lógica copiada para vários sítios vai divergir.
• Consistência. Deve seguir os padrões que o resto da app já usa.
• Tamanho. Um pedido de 20 linhas que produziu 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 alteração, ou lógica duplicada noutro sítio? Não mudes nada; apenas lista.

Erros comuns

• Aprovar porque parece limpo. Código arrumado pode, ainda assim, não ter uma verificação de permissões.
• Ler em vez de testar. Teste primeiro; leia depois.
• Testar apenas o caminho feliz. Experimente dados errados, o utilizador errado e a sessão terminada.
• Ignorar alterações de ficheiros não relacionados. Pergunte porque é que todos os ficheiros mudaram.
• Confiar totalmente numa autorrevisão. Use a revisão da IA como primeira passagem e confirme testando.
• Rever uma semana de alterações de uma vez. Reveja alterações pequenas à medida que acontecem.

Lista de verificação

• Sei que ficheiros mudaram e porquê, e nada não relacionado foi alterado.
• A alteração funciona em desktop e em telemóvel, com dados errados, com a sessão terminada e como outro utilizador.
• Cada rota de dados verifica o início de sessão e a propriedade no servidor.
• Sem segredos no código nem nos pacotes enviados ao navegador.
• Os dados são validados no servidor; as consultas usam parâmetros.
• Os erros são registados e não engolidos, e não são mostrados em detalhe aos utilizadores.
• As novas dependências são reais e necessárias; não restam funções inventadas nem código de exemplo.
• As alterações de maior risco tiveram uma leitura cuidadosa e, se necessário, uma segunda pessoa a rever.

Rever código no Mythex

• O modo Perguntas responde a perguntas sobre o código sem o editar — ideal para pedidos como "explica cada alteração" e "que rotas não têm verificação de permissões". Veja Chat.
• A vista de código mostra a árvore de ficheiros, o editor e o terminal em todos os planos (só de leitura no plano Free, editável no Pro), para que possa ler o que mudou. Veja Editor de código.
• /test faz com que o agente percorra a pré-visualização como um utilizador e reporte os fluxos partidos.
• Os pontos de restauro permitem reverter uma alteração que não passa na revisão.

Se um programador estiver a rever por si, como trabalhar com um programador numa app criada com IA explica a passagem de testemunho; se a revisão revelar um erro, veja como depurar uma app criada com IA.

Perguntas