Como Revisar Código Gerado por IA: Encontre o Erro na Função Convincente

Como Revisar Código Gerado por IA: Encontre o Erro na Função Convincente

Um assistente escreve uma função de poucas linhas. Ela é legível, usa a API certa e passa no exemplo óbvio. Você a colocaria em produção? A revisão mais útil começa pela pergunta: que promessa o código precisa cumprir? Depois, experimente um valor perto do limite dessa promessa.

Vamos revisar uma função JavaScript fictícia, gerada por IA, que decide se uma URL pertence a example.com ou a um subdomínio. example.com é um domínio reservado para exemplos. O código é didático, não um sistema de controle de acesso pronto para produção. Ele roda em Node.js sem dependências.

A resposta que parece certa

O pedido foi: “Aceite URLs HTTPS de example.com e seus subdomínios. Rejeite outros servidores e URLs inválidas.” Uma resposta gerada poderia ser:

1function isAllowedUrl(raw) {
2  const url = new URL(raw);
3  return url.hostname.endsWith('example.com');
4}

Ela aceita https://example.com e https://docs.example.com. Por isso passa numa demonstração rápida. Mas endsWith('example.com') examina um sufixo de texto, não o limite de um domínio. A função também não confere o protocolo https: e new URL lança uma exceção quando a entrada não é uma URL.

O caso escondido é https://notexample.com: o nome termina com as mesmas letras. A função devolve true quando a regra pede false. Quem testa só um subdomínio normal pode não perceber.

Transforme a promessa em testes

Esta tabela reúne acertos, imitação de domínio, protocolo errado e entrada inválida:

A versão original falha nos três últimos casos: aceita o domínio parecido e HTTP, além de lançar uma exceção em vez de devolver false. É uma descoberta melhor que “o código parece inseguro”: a falha pode ser reproduzida.

Uma versão corrigida que você pode executar

Salve como review.mjs e rode node review.mjs. Os testes fazem parte do exemplo; se algum falhar, o processo termina com erro:

1import assert from 'node:assert/strict';
2
3function isAllowedUrl(raw) {
4  try {
5    const url = new URL(raw);
6    const host = url.hostname;
7    return url.protocol === 'https:' &&
8      (host === 'example.com' || host.endsWith('.example.com'));
9  } catch {
10    return false;
11  }
12}
13
14assert.equal(isAllowedUrl('https://example.com'), true);
15assert.equal(isAllowedUrl('https://docs.example.com'), true);
16assert.equal(isAllowedUrl('https://notexample.com'), false);
17assert.equal(isAllowedUrl('http://example.com'), false);
18assert.equal(isAllowedUrl('not a URL'), false);
19console.log('5 checks passed');

5 checks passed

O ponto inicial em .example.com importa: distingue um subdomínio de um nome que apenas termina nas mesmas letras. A verificação do protocolo implementa a exigência de HTTPS; try/catch dá um resultado previsível para texto inválido. Esses testes conferem a regra apresentada, não todas as políticas possíveis para URLs. Um aplicativo real talvez precise definir portas, credenciais, redirecionamentos, mudanças de DNS e o lugar em que a URL será usada. Escreva essas exigências antes de tratar a função como barreira de segurança.

Revise além do exemplo feliz

Para qualquer mudança gerada por IA, faça quatro perguntas:

1. Resolve o problema pedido? Compare o código com a exigência real, inclusive erros e entradas fora da demonstração.
2. Você consegue reproduzir o comportamento? Rode as verificações do projeto e acrescente um teste para o limite importante. Guarde o teste que falhou depois de corrigir o defeito.
3. Em que o código toca? Examine dependências novas, rede, arquivos, segredos e dados controlados por usuários. Uma auditoria de pacotes aponta vulnerabilidades conhecidas, mas não prova que a lógica está certa.
4. A mudança cabe no projeto? Leia a alteração inteira, os pontos de uso, o fluxo dos dados e as convenções existentes. Testes verdes podem ignorar uma exigência que ninguém escreveu.

O guia do GitHub para revisar código gerado por IA recomenda verificações automáticas e revisão humana do contexto e da intenção. A documentação do npm audit explica o que o relatório de dependências cobre; ele ajuda quando pacotes foram adicionados, mas não revisa esta regra de URL.

O princípio é simples: trate o código gerado como uma proposta que faz uma promessa. Descubra qual é a promessa, teste-a e assuma a decisão de usar o código. Para uma visão geral, leia O Que É Vibe Coding? e Como Testar um Assistente de IA.

Fontes e leitura adicional

• GitHub Docs: revisão de código gerado por IA
• npm Docs: auditoria de dependências