Governe a Qualidade do Código de IA por Baseline, Não por Anedota

Em uma única semana, duas evidências chegaram parecendo defender coisas opostas. Uma é um estudo de 300.000 commits gerados por IA mostrando que código escrito por máquina injeta dívida estrutural em escala. A outra é uma desmontagem estatística cuidadosa da afirmação viral de que “o Claude quebrou o rsync”, que ruiu no instante em que alguém rodou um teste de significância sobre ela.

As duas não se contradizem. Apontam para a mesma regra. A forma de julgar a qualidade do código de IA precisa ser um baseline e uma estatística, não uma captura de tela e uma sensação.

O Dataset de 300 Mil Commits

Um artigo intitulado “Debt Behind the AI Boom” (arXiv:2603.28592), reportado pela TheNextWeb, analisou mais de 300.000 commits gerados por IA em mais de 6.000 repositórios. O achado é difícil de descartar pelo tamanho da amostra. Mais de 15% desses commits introduziram pelo menos um novo problema. Desses novos problemas, cerca de 90% eram code smells: as falhas estruturais de manutenibilidade que não quebram um teste, mas elevam silenciosamente o custo de toda mudança futura.

É uma evidência com cara de causal numa escala que a área ainda não tinha. Não é a anedota de um engenheiro sobre uma tarde frustrante. É uma população.

E importa porque code smell é exatamente o modo de falha que nenhum review de commit isolado captura. Um smell não é um bug. O CI está verde. A funcionalidade roda. O dano aparece três trimestres depois, quando a próxima mudança naquele arquivo leva o dobro do tempo que deveria e ninguém sabe dizer por quê.

Então a tese de que a IA injeta dívida é real e medida. Guarde esse pensamento.

O Pânico do rsync

Na mesma semana, outra história foi na direção contrária. Espalhou-se a afirmação de que o Claude, da Anthropic, havia aumentado a taxa de bugs no rsync, uma peça de infraestrutura que roda em quase todo lugar. Tinha o formato que todo ciclo de indignação deseja: uma ferramenta querida, um vendor de IA poderoso, um gráfico de aparência alarmante.

Então Alexis Purslane de fato rodou os números. A análise cobriu 36 releases do rsync. As releases associadas ao Claude tiveram severidade média de 1,65 problema por dez commits. A média histórica era 2,95. Ou seja, as releases do Claude foram, se algo, mais limpas que a média de longo prazo.

E o mais importante: a diferença aparente não sobreviveu a um teste de significância. Um teste de permutação retornou p=46%. Um teste exato de Fisher retornou p=74%. Nenhum chega perto de um limiar que você aceitaria como sinal. A história do “a IA piorou o rsync” era ruído fantasiado de tendência.

O detalhe que deveria envergonhar quem compartilhou o pânico: a pior release de todo o dataset foi a v3.4.1, com 39,39 no índice de severidade. Ela antecede por completo a entrada do Claude. Não gerou indignação alguma. Ninguém fez um gráfico. Era pior que qualquer coisa que a IA tocou, e ficou invisível porque não cabia numa narrativa.

A Mesma Regra, nas Duas Direções

Junte as duas e a lição de governança não é “IA escreve código ruim” nem “IA está tudo bem”. É esta. Tanto quem soou o alarme quanto quem o descartou estavam rodando o mesmo experimento sem controle, só que com priores diferentes.

O artigo dos 300 mil commits é confiável porque é ponderado por severidade e tem escala populacional. Ele conta novos problemas, classifica-os e compara contra um baseline de como o código estava antes. A desmontagem do rsync é confiável pela razão idêntica, no sentido inverso: pegou uma afirmação assustadora, estabeleceu um baseline histórico, ponderou por severidade e testou se a diferença era real.

Boa medição capturou dívida estrutural onde ela existia e descartou dívida estrutural onde ela não existia. É esse o trabalho inteiro. Um processo de governança que só consegue confirmar seus medos não é um processo de governança. É um espelho.

Confiança Não É Evidência

Existe uma razão para os times caírem na anedota, e não é preguiça. É que as pessoas dentro do trabalho se sentem seguras.

Pesquisadores de Stanford descobriram que desenvolvedores usando IA escreveram código menos seguro enquanto estavam mais confiantes de que ele era seguro. A confiança andou na direção errada em relação à qualidade. É a combinação perigosa: não o erro, mas o erro acompanhado de certeza.

O experimento randomizado da METR, de 2025, fez o mesmo ponto por outro ângulo. Dezesseis desenvolvedores open-source experientes esperavam que a IA os acelerasse em cerca de 20%. Medidos contra um controle, ficaram mais lentos. A sensação de velocidade e a velocidade medida apontaram para lados opostos.

Se engenheiros qualificados não conseguem sentir as próprias regressões de segurança nem a própria desaceleração, nenhuma quantidade de code review por intuição vai capturar uma taxa de injeção de 90% de code smells. O instrumento precisa ser externo. Precisa ser um número que não liga para como a sprint pareceu.

Construa o Portão como CI

A tradução prática é esta. Trate a qualidade do código de IA do jeito que você já trata testes: como um portão com limiar, não como uma conversa.

Um portão de verdade tem quatro propriedades. Compara contra um baseline, para que “isto está pior?” tenha uma resposta definida. Pondera por severidade, para que uma vulnerabilidade crítica e uma implicância de nomenclatura não valham um voto cada. Aplica um teste estatístico antes de declarar tendência, para que um tremor de três releases não dispare uma reorganização. E roda automaticamente a cada lote de mudança gerada por IA, para que ninguém precise lembrar de desconfiar.

A maioria dos times não tem nada disso para a saída de IA. Eles têm para a saída humana, na forma de CI, linters e limiares de cobertura, porque construíram essa disciplina ao longo de trinta anos. O trabalho agora é apontar os mesmos instrumentos para o novo autor e recusar avaliá-lo por anedota só porque o autor é um modelo.

Faça Isto Agora

Monte um baseline ponderado por severidade de novos problemas introduzidos por mudança, segmentado entre autoria de IA e autoria humana, e deixe acumular por algumas semanas antes de concluir qualquer coisa.

Adicione uma checagem de significância antes que alguém apresente uma tendência de qualidade de IA à liderança. Se uma afirmação não passa num teste de permutação ou de Fisher contra o seu baseline, ela não vira slide. Essa única regra teria matado o pânico do rsync e teria elevado o achado dos 300 mil commits, que é exatamente a triagem que você quer.

E pare de aceitar confiança como evidência em code review. Os resultados de Stanford e da METR não são casos extremos. São a taxa-base. O engenheiro que tem certeza de que o código de IA está ok é justamente aquele que o seu portão existe para checar.

A semana nos deu um par limpo de exemplos: dívida estrutural que era real e medida, e dívida estrutural que era imaginada e viral. A única coisa que separou sinal de ruído foi se alguém se deu ao trabalho de definir um baseline e rodar o teste. Torne isso o padrão e você deixa de discutir sobre capturas de tela.

---

Fontes

• TheNextWeb. “Complexity Is the Ceiling.” Junho de 2026.
• Alexis Purslane. “Did Claude Increase Bugs in rsync?.” Junho de 2026.
• arXiv. “Debt Behind the AI Boom.” 2026.

A Victorino ajuda times de engenharia a criar portões de medição para código gerado por IA: contato@victorino.com.br | www.victorino.com.br