SimpleOne mostrou por que Claude e revisores de AI não distinguem código gerado por AI de código humano

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

Por Que é Difícil

No artigo, o time reuniu vários pares de funções: validação de e-mail, requisição para API, carregamento de configuração e cálculo de desconto. Em cada par, uma versão foi escrita por um humano, a outra por um modelo. No papel, a tarefa parece simples: código de IA geralmente tem mais tipagem, comentários e pseudo-exatidão.

Na prática, é pior. Alguns exemplos realmente se entregam através da correção excessiva, mas já no terceiro ou quarto par, fica claro: nem sempre é possível distinguir o autor apenas pelo estilo. O exemplo mais forte é a função de cálculo de desconto, onde a diferença entre as versões quase desaparece.

Ambos os fragmentos são funcionais, ambos passam nas verificações estáticas, ambos parecem razoáveis. Mas o erro real se esconde não dentro da função, mas no lugar onde ela é chamada. Se o desconto deve ser fixado no momento do fechamento do pedido, recalculá-lo sempre que a página for aberta não pode ser feito.

Isso não é mais uma questão de sintaxe ou melhores práticas, mas de lógica de negócios e contexto do projeto, que um revisor automático geralmente não possui.

O Que Entrega o Sintético

SimpleOne destaca vários sinais pelos quais o código de IA às vezes ainda pode ser detectado. Não se trata de erros grosseiros, mas de um estilo suspeito "perfeito": o código parece arrumado, mas se comporta como se estivesse tentando impressionar o revisor, em vez de resolver uma tarefa específica de produção. Esses sinais apareceram mais frequentemente nos exemplos com e-mail, API e config.

• Docstrings excessivamente detalhadas com enumeração de Args, Returns e cada exceção, mesmo para uma função minúscula.
• Casos extremos desnecessários e verificações que ninguém pediu e que não seguem da declaração da tarefa.
• Entidades inventadas ao redor do código: exceções customizadas, loggers ou campos obrigatórios que não existem no projeto.
• Fallbacks "seguros" como data.get('user', {}), que não falham imediatamente, mas mascaram o problema real.

Daí vem o risco principal: IA frequentemente escreve não código ostensivamente ruim, mas código que parece convincente. É tipado, formatado, comentado e leva em conta muitos cenários. Mas alguns desses cenários são inventados, e algumas das construções defensivas apenas complicam a depuração. Esse código é fácil de aceitar como de alta qualidade se você olhar para a forma e não verificar como foi integrado em um sistema específico.

Onde a Revisão Falha

O problema que SimpleOne descreve não se reduz à qualidade de um modelo. Se Claude gera código e outra ferramenta de IA o verifica de acordo com os mesmos padrões, o time obtém um ciclo fechado de confiança sintética. Tudo parece verde: há tipos, há tratamento de erros, há comentários. Mas a revisão pode perder que UserFetchError não existe no projeto, secret_key de repente apareceu sem requisitos, e um retorno "silencioso" de um dicionário vazio consumirá horas procurando um bug.

"O revisor de IA encontrou 2 em 5."

O time testou isso em bugs reais de produção. O revisor automático capturou apenas dois casos simples: uma variável não utilizada e uma verificação de null ausente. O que perdeu foram coisas que exigiam contexto do projeto: um erro lógico no cálculo, uma race condition com requisições paralelas e uma ordem de migração incorreta. A conclusão é prática: IA funciona bem como um primeiro filtro, mas não substitui um humano em áreas críticas onde é importante entender a lógica de domínio e as consequências das mudanças.

O Que Isso Significa

O uso generalizado de IA no desenvolvimento muda não apenas a velocidade da escrita de código, mas também o próprio processo de controle de qualidade. Verificar código gerado com outra ferramenta generativa é útil, mas não suficiente. Se o time não testar o revisor contra bugs antigos e não manter um humano na cadeia de tomada de decisão, corre o risco de obter não qualidade, mas uma imitação muito convincente dela.