SimpleOne mostra por que Claude e revisores de IA não distinguem código de IA de código humano

A SimpleOne propôs um teste simples: distinguir o código humano do gerado por IA. Descobriu-se que isso é difícil não só para desenvolvedores, mas também para o próprio revisor de IA, que verifica o código pelos mesmos padrões com os quais ele foi criado.

Por que é difícil

No artigo, a equipe reuniu vários pares de funções: validação de e-mail, requisição a uma API, carregamento de configuração e cálculo de desconto. Em cada par, uma versão foi escrita por uma pessoa e a outra, por um modelo. No papel, a tarefa parece simples: o código de IA costuma ter mais tipagem, mais comentários e uma pseudo-organização. Na prática, é pior. Alguns exemplos realmente se entregam pelo excesso de correção, mas já no terceiro ou quarto par fica claro que só pelo estilo nem sempre dá para identificar o autor.

O exemplo mais forte é a função de cálculo de desconto, em que a diferença entre as versões quase desaparece. Os dois trechos funcionam, os dois passam na verificação estática, os dois parecem razoáveis. Mas o erro de verdade não está dentro da função, e sim no ponto em que ela é chamada. Se o desconto deve ser fixado no momento da finalização do pedido, não se pode recalculá-lo a cada abertura da página. Isso já não é questão de sintaxe nem de best practices, mas de lógica de negócio e de contexto do projeto, que o revisor automático normalmente não tem.

O que entrega o código sintético

A SimpleOne destaca alguns sinais pelos quais o código de IA às vezes ainda pode ser identificado. Não se trata de erros grosseiros, mas de um estilo suspeitosamente "perfeito": o código parece organizado, mas se comporta como se tentasse impressionar o revisor em vez de resolver uma tarefa concreta de produção. Esses sinais apareceram com mais frequência nos exemplos de e-mail, API e configuração.

• Docstrings detalhadas demais, listando Args, Returns e cada exceção, mesmo para uma função minúscula.
• Edge cases e verificações extras que ninguém pediu e que não decorrem do enunciado da tarefa.
• Entidades inventadas em volta do código: exceções personalizadas, loggers ou campos obrigatórios que não existem no projeto.
• Fallbacks "seguros" como data.get('user', {}), que não quebram de imediato, mas mascaram o problema real.

Daí o principal risco: a IA muitas vezes não escreve um código abertamente ruim, e sim um código que parece convincente. Ele é tipado, formatado, comentado e contempla uma infinidade de cenários. Mas parte desses cenários foi tirada do nada, e parte das construções defensivas só complica a depuração. É fácil confundir esse código com um código de qualidade se você olha para a forma e não verifica como ele se encaixa em um sistema específico.

Onde a revisão falha

O problema descrito pela SimpleOne não se resume à qualidade de um único modelo. Se o Claude gera o código e outra ferramenta de IA o verifica pelos mesmos padrões, a equipe ganha um circuito fechado de confiança sintética. Tudo aparece em verde: há tipos, tratamento de erros e comentários. Mas a revisão pode não perceber que UserFetchError não existe no projeto, que secret_key surgiu do nada sem nenhum requisito, ou que um retorno "silencioso" de um dicionário vazio vai consumir horas na caça ao bug.

"O revisor de IA encontrou 2 de 5."

A equipe testou isso com bugs reais de produção. O revisor automático pegou apenas dois casos simples: uma variável não utilizada e a ausência de verificação de null. Passaram batidos os problemas que exigem contexto do projeto: um erro lógico em um cálculo, uma race condition em requisições paralelas e uma ordem incorreta de migrações.

A conclusão é prática: a IA funciona bem como primeiro filtro, mas não substitui uma pessoa em áreas críticas, nas quais é importante entender a lógica do domínio e as consequências das mudanças.

O que isso significa

O uso em massa de IA no desenvolvimento muda não só a velocidade de escrita do código, mas também o próprio processo de controle de qualidade. Verificar código gerado com outra ferramenta generativa é útil, mas insuficiente. Se a equipe não testa o revisor com bugs antigos e não mantém uma pessoa na cadeia de decisão, corre o risco de obter não qualidade, mas uma imitação muito plausível dela.