Detector de Código de IA: Por que Seu Código É Sinalizado e Como Corrigir

Um detector de código de IA pontua um arquivo, um repositório ou uma submissão pela aparência de geração por máquina. Ele retorna uma pontuação no nível do documento, além de destaques por arquivo ou por função. Se a sua pontuação veio alta, a atitude útil não é discutir com o número. É encontrar quais linhas carregam o sinal e corrigi-las.

Esse veredito tem uma metade desconfortável. Os detectores fazem suposições a partir de padrões superficiais, e o código tem menos padrões superficiais do que a prosa. Um arquivo limpo, idiomático e bem comentado escrito por uma pessoa pode parecer exatamente com código gerado, porque o código gerado é treinado em pessoas que escrevem exatamente assim. Pontuações altas são comuns e não são prova de que você trapaceou.

O que um detector de código de IA realmente mede

Ele não lê sua intenção. Ele lê estatísticas.

A maioria dos detectores, tanto para prosa quanto para código, analisa duas coisas: quão previsível é cada próximo token (perplexidade) e quanto essa previsibilidade varia ao longo do documento (burstiness). O código humano é irregular. Você escreve um loop entediante, depois um helper estranho com um nome estranhamente específico, depois um comentário que menciona um número de ticket, depois quatro linhas de configuração copiada e colada. O código gerado tende a ser mais uniforme: comprimentos de identificadores consistentes, estilo de comentário consistente, estrutura consistente da primeira à última linha.

Essa uniformidade é o sinal. Então a correção não é tornar seu código pior. É deixar a irregularidade natural de um projeto real transparecer.

Mais uma coisa que vale a pena afirmar claramente: a saída de um detector é uma estimativa de probabilidade, não uma prova de autoria. O próprio FAQ do GPTZero descreve um valor de confiança como “a chance de o detector estar correto em sua classificação” e dá o exemplo de que 90% significa que, em 90% das vezes, em documentos semelhantes, o detector está correto (fonte: gptzero.me). Isso é uma afirmação sobre o comportamento da ferramenta, não sobre o seu arquivo. A documentação do Turnitin descreve ajustes para que nenhuma pontuação ou destaque seja atribuído na faixa de 1% a 19%, a fim de evitar falsos positivos (fonte: www.turnitin.com). Todo fornecedor está gerenciando abertamente o mesmo trade-off: detectar texto gerado, sem destruir trabalho honesto.

Por que meu próprio código é sinalizado como escrito por IA?

Quatro razões cobrem a maioria dos casos.

Código padrão é código padrão. Manipuladores CRUD, estruturas de teste, arquivos de configuração e cola de biblioteca padrão são quase idênticos, quer tenham sido digitados por uma pessoa ou por um modelo. Quase não há sinal de autoria a encontrar, então o detector recorre a suposições prévias.

Seu estilo é consistente. Se você nomeia tudo como data, result, handleX e comenta cada função no mesmo tom sucinto, você acidentalmente produziu a suavidade que parece gerada. Consistência normalmente é uma virtude. Aqui ela custa caro.

O arquivo é curto. Entradas curtas dão ao detector muito pouco com que trabalhar. Uma única função utilitária é, em sua maioria, suposição prévia, não evidência.

Você usou um modelo, para parte disso. A maior parte do código sinalizado em 2026 é misto: você escreveu a arquitetura, um assistente escreveu três funções auxiliares e você as editou levemente. As costuras são reais e aparecem como uma mudança de textura entre as seções.

Antes de reescrever qualquer coisa, pontue-a adequadamente. O detector de IA do DeAIze pontua o documento inteiro e destaca cada frase pela probabilidade de IA, para que você veja quais linhas carregam o sinal em vez de adivinhar. O plano gratuito oferece 200 palavras no cadastro, sem cartão.

A correção: edite as regiões sinalizadas, não o arquivo inteiro

Trate a pontuação como um linter. Você não reformata um repositório porque uma função emite um aviso.

1. Pontue primeiro, edite depois. Obtenha uma visão por linha ou por função. No DeAIze, isso é o destaque em nível de frase; em termos de código, aponta para as regiões, não para o arquivo.
2. Ordene por sinal, não por tamanho. Corrija as três regiões mais quentes antes de tocar em qualquer coisa fria. Reescrever código frio é esforço desperdiçado e adiciona risco.
3. Torne os comentários específicos. Esta é a edição de maior rendimento no código. Substitua // Initialize the client por uma nota que só o seu projeto poderia produzir: uma referência de ticket, um bug conhecido upstream, um motivo pelo qual um parâmetro é ignorado.
4. Quebre a simetria. Se toda função tem o mesmo formato de comentário, exclua alguns comentários. Se toda variável é uma palavra completa, encurte as óbvias. Se a estrutura é perfeitamente paralela, deixe um ramo ser tratado inline.
5. Mantenha suas próprias arestas. O TODO pela metade, a verificação defensiva que você adicionou após um incidente, a gambiarra levemente feia com uma data nela. Esses são sinais de autoria e são verdadeiros.
6. Pontue novamente e compare. Se o número mudou, mantenha a edição. Se não mudou, reverta-a. Nunca mantenha uma reescrita que piorou o código sem motivo.

Uma ilustração prática. Antes, um auxiliar sinalizado:

// Function to calculate the total price
def calculate_total_price(items):
    # Initialize total
    total = 0
    # Iterate through items
    for item in items:
        total += item.price
    # Return the total
    return total

Depois, mesmo comportamento, menos simetria:

def order_total(items):
    # No discount logic here on purpose - pricing service owns that (TICKET-4412)
    return sum(i.price for i in items if not i.voided)

A segunda versão é mais curta, mais idiomática e carrega uma razão que o leitor pode verificar. É isso que um autor real deixa para trás. Não é ofuscação e não altera o que o código faz. Observe que isto é uma ilustração, não um antes/depois medido.

O que nossos próprios testes dizem sobre as taxas de detecção

Executamos nosso detector em dois corpora em 2026-09-28, com um limite de sinalização de 30%. Uma amostra de referência de 709 passagens de referência de 61 guias DeAIze selecionados porque seus metadados não os marcavam como gerados obteve média de 26% e mediana de 25%, com variação de 0% a 69%; 239 das 709 passagens pontuaram no limite ou acima dele. A autoria humana não foi verificada de forma independente, portanto essas contagens não podem estabelecer uma taxa de falsos positivos para humanos. Saída de modelo não editada, 12 passagens DeepSeek geradas a partir de prompts fixos sem edição, obteve média de 33% e mediana de 34%, variação de 4% a 46%.

Leia isso de novo, porque é a versão honesta. Passagens de referência, cuja autoria humana não foi verificada de forma independente, e saída de modelo DeepSeek não editada ficaram em faixas sobrepostas, e as médias estavam mais próximas do que a maioria das pessoas espera. A detecção não é um separador limpo. É um sinal ruidoso que você precisa interpretar, e é exatamente por isso que o destaque por frase importa mais do que o número principal. Para uma visão mais ampla de por que as pontuações variam entre ferramentas, consulte Precisão do Detector de IA.

Quando esta é a escolha errada

Não use nada disso para passar trabalho que você não fez. Se a tarefa, o contrato ou a revisão de código diz que o código deve ser seu, uma pontuação de detector de código de IA é o menor dos seus problemas quando alguém ler o diff e pedir que você explique uma função que você não consegue explicar.

Você também deve pular todo este exercício se:

• A política proíbe totalmente o auxílio de IA. Editar para diminuir uma pontuação não torna uma submissão não autorizada autorizada. Pergunte, depois divulgue.
• O código é gerado de ponta a ponta e você não o entende. Reescrever os comentários não vai te salvar em uma apresentação. Aprenda o código ou não o submeta.
• Você está sendo acusado, não avaliado. Se um processo formal foi iniciado, o movimento certo é documentação e seus rascunhos, não uma reescrita. Academic Integrity Hearing AI cobre o que os painéis realmente avaliam.
• Sua equipe compartilha um único guia de estilo. Impor voz pessoal em um repositório compartilhado para agradar um detector é uma troca ruim. Corrija apenas as regiões sinalizadas.

Uma breve lista de verificação antes de reenviar

• Você sabe quais regiões foram sinalizadas, não apenas a pontuação geral.
• Cada edição manteve o comportamento idêntico, e você tem os testes para provar isso.
• Os comentários agora carregam razões específicas do projeto, números de tickets ou datas.
• Você removeu comentários padronizados que não acrescentavam nada.
• Você reavaliou e pode dizer o que mudou.
• Você consegue explicar cada linha da submissão em voz alta, sem anotações.

Se você usou um modelo para partes do arquivo, diga isso onde a divulgação é esperada. Uma breve nota sobre quais partes foram assistidas e como você as verificou é quase sempre um resultado melhor do que uma pontuação limpa que você não consegue defender.

Como isso se encaixa no fluxo de trabalho mais amplo

O código é um caso especial porque os padrões superficiais são mais tênues. A maior parte do mesmo método se aplica à prosa, e o guia humanizar texto de IA aborda o ciclo com mais profundidade: pontue o texto, reescreva apenas as frases sinalizadas, mantenha uma reescrita somente quando a similaridade semântica indicar que o significado foi preservado, depois repontue e relate antes e depois. No parágrafo de exemplo usado no site, uma pontuação de IA de 92% tornou-se 4%.

Para código, o ciclo é mais simples e você faz a maior parte manualmente. Os detectores são ajustados para serem cautelosos. A documentação do Turnitin observa que, se identificarem 50% de um documento como provavelmente escrito por IA, ele pode conter até 65% de escrita por IA (fonte: www.turnitin.com) — os fornecedores ampliam o intervalo porque a estimativa pontual não é confiável. Trate cada pontuação de código da mesma forma: um motivo para investigar, nunca um motivo para entrar em pânico, e nunca um veredito por si só.

Nota de medição: os números neste artigo vêm da nossa própria observação local do detector em 2026-09-28 — n = 709 passagens de referência de 61 guias selecionados por metadados versus n = 12 passagens de modelo DeepSeek não editadas, pontuação mediana de IA de 25% e 34%, respetivamente. A autoria humana não foi verificada de forma independente; passagens do mesmo guia estão correlacionadas, portanto estes números não estabelecem uma taxa de falsos positivos para humanos. Método: metodologia. Evidência datada: observação do corpus, 2026-09-28.