A IA acelera o desenvolvimento, mas gera 1,7x mais bugs

• A análise de 470 PRs de código aberto mostrou que o código escrito por IA contém em média 1,7x mais problemas do que o código escrito por humanos
• Erros lógicos, pior legibilidade e vulnerabilidades de segurança apareceram com muito mais frequência no código de IA; em especial, os problemas de legibilidade aumentaram mais de 3x
• Omissão de tratamento de erros, falhas de concorrência e inconsistências de nomenclatura são frequentes no código de IA, ampliando a carga de revisão e o risco operacional
• As causas apontadas incluem falta de compreensão da lógica de negócio, busca por precisão superficial e preferência por padrões ineficientes
• O relatório destaca a necessidade de reforçar a gestão da qualidade do código gerado por IA e de adotar revisão de código, segurança e testes orientados à IA

---

Visão geral do relatório AI vs Human Code Generation Report

• A CodeRabbit conduziu um estudo para analisar empiricamente a diferença de qualidade entre código escrito por IA e por humanos
  • Foram analisados 470 PRs open source no GitHub; destes, 320 foram coescritos com IA e 150 escritos apenas por humanos
  • Todos os resultados foram normalizados como número de issues a cada 100 PRs, e a frequência por tipo de problema foi medida por meio de comparação estatística de proporções
• Em resumo, a IA aumenta a produtividade, mas também eleva a taxa de erros
  • Em média, PRs escritos por IA tiveram 10,83 problemas, enquanto PRs escritos por humanos tiveram 6,45
  • Em especial, erros de maior gravidade foram encontrados com mais frequência no código gerado por IA

Limitações do estudo

• Como não foi possível confirmar diretamente se o código foi escrito por IA, PRs com o sinal de coautoria por IA (co-authored-by) foram classificados como PRs de IA
  • PRs sem esse sinal foram considerados escritos por humanos, mas uma separação perfeita não foi possível
• Apesar dessa limitação, as diferenças estatísticas no padrão de problemas entre os dois grupos apareceram de forma significativa
• A metodologia completa foi divulgada ao final do relatório

10 principais descobertas

• Nem todos os tipos de erro aparecem apenas na IA, mas a taxa de erros do código de IA foi maior na maioria das categorias
  • Humanos e IA cometem os mesmos tipos de erro, mas a IA os produz com mais frequência e em maior escala

• 1. Aumento de 1,7x no total de issues

  • Em média, 10,83 issues por PR escrito por IA, contra 6,45 em PRs escritos por humanos
  • PRs com concentração anormal de issues (outliers) são muito mais frequentes no código de IA, aumentando a carga de revisão

• 2. Aumento de erros de alta gravidade

  • Problemas graves e críticos foram 1,4x a 1,7x mais frequentes

• 3. Aumento de 75% em problemas de lógica e correção

  • Incluem erros de lógica de negócio, dependências incorretas, falhas no fluxo de controle e erros de configuração
  • O custo de correção é alto e há grande chance de virar incidente em produção

• 4. Mais de 3x mais problemas de legibilidade

  • Convenções de nomenclatura, estrutura do código e consistência de expressão ficam visivelmente piores
  • Mesmo quando o código parece organizado à primeira vista, violações de padrões locais ocorrem com frequência

• 5. Omissão de tratamento de erros e caminhos de exceção dobra

  • Faltam com frequência checagens de null, condições de guarda e lógica de tratamento de exceções
  • Esse é um tipo de problema diretamente ligado a falhas reais de serviço

• 6. Problemas de segurança aumentam em até 2,74x

  • Exemplos típicos incluem tratamento inadequado de senhas e vulnerabilidades de referência a objetos
  • Não são vulnerabilidades exclusivas, mas a maioria das falhas de segurança é ampliada

• 7. Problemas de desempenho são menos numerosos, mas se concentram na IA

  • Chamadas excessivas de I/O foram cerca de 8x mais frequentes
  • A IA tende a preferir código voltado à clareza, sacrificando eficiência

• 8. Erros de concorrência e dependência quase dobram

  • Erros de ordem, fluxo incorreto de dependências e uso inadequado de controle de concorrência são frequentes

• 9. Problemas de formatação aumentam 2,66x

  • Há muitos erros formais como indentação, espaços e inconsistência de estilo
  • Mesmo com formatadores e linters automáticos, o ruído aumenta no código de IA

• 10. Inconsistência de nomenclatura dobra

  • Nomes pouco claros, termos inconsistentes e identificadores genéricos elevam a carga cognitiva dos revisores

Causas dos problemas

• A IA carece de compreensão da lógica de negócio
  • Como gera código com base em padrões estatísticos, deixa escapar regras do sistema
• Geração focada em precisão superficial
  • O código parece correto visualmente, mas contém falhas na proteção do fluxo de controle ou na ordem das dependências
• Não conformidade com convenções específicas do repositório
  • Regras de nomenclatura, estrutura e formatação acabam distorcidas em uma forma generalizada
• Enfraquecimento de padrões de segurança
  • Sem instruções explícitas, a IA tende a reproduzir padrões de código antigos ou vulneráveis
• Preferência por simplicidade em vez de eficiência
  • Há tendência ao uso de I/O repetitivo e estruturas não otimizadas

Como as equipes de engenharia podem responder

• Adotar IA exige não só ganho de velocidade, mas também redesenhar o sistema de garantia de qualidade

• 1. Fornecer contexto suficiente à IA

  • É preciso explicitar regras de negócio, padrões de configuração e restrições de arquitetura para reduzir erros
  • Incluir no prompt diretrizes e esquemas específicos do repositório

• 2. Impor estilo de código com base em políticas

  • Prevenir problemas de legibilidade com formatadores no CI, linters e guias de estilo

• 3. Adicionar proteções de correção

  • Testes obrigatórios, checagem de null/type, padronização do tratamento de exceções e condições de guarda explícitas

• 4. Reforçar padrões de segurança por padrão

  • Centralizar credenciais, bloquear uso direto de senhas e executar SAST e linters de segurança automaticamente

• 5. Induzir padrões eficientes

  • Processamento em lote de I/O, escolha adequada de estruturas de dados e fornecimento de dicas de desempenho

• 6. Adotar checklist de PR orientado à IA

  • Na revisão, verificar os seguintes itens:
    • cobertura de caminhos de erro
    • correção do controle de concorrência
    • validação de valores de configuração
    • forma de tratamento de senhas

• 7. Automatizar a revisão de código gerado por IA

  • Para evitar bugs ignorados devido ao aumento da fadiga na revisão, é sugerido o uso de ferramentas de code review para IA (CodeRabbit)
    • Padronização da qualidade da revisão e redução do tempo de análise e da carga cognitiva

Conclusão

• Ferramentas de programação com IA são aceleradores poderosos, mas acelerar sem proteções é arriscado
• O código gerado por IA apresenta maior variabilidade, taxa de erro e gravidade
• É essencial usar a IA como ferramenta complementar, não como substituta, além de reforçar qualidade, segurança e testes
• Para garantir velocidade e qualidade ao mesmo tempo, é necessário um gerenciamento de engenharia intencional
• O uso de ferramentas de revisão de código com IA pode ajudar de forma prática a manter a qualidade

[cshj55]

1,7x é menos do que eu imaginava...?

[ds2ilz]

Também senti algo parecido ao programar com IA. Olhando para as causas organizadas, acho que isso acontece porque, ao programar, a pessoa já parte de conhecimentos básicos como padrões, convenções de nomenclatura, tratamento de edge cases, guard conditions etc., e isso não é fornecido de forma suficiente no contexto.
Por isso, eu criei um arquivo de regras reunindo só esse tipo de coisa e, quando vou programar, mando sempre ler esse arquivo e segui-lo. Aí, melhorando apenas o arquivo de regras, o resultado final acaba ficando consideravelmente melhor.

[princox]

Fico com medo de aparecer alguém com a opinião de tipo: "produziu coisa pra caramba, então 1,7x a mais nem sai caro, né..."

[kimjoin2]

Mas foi rápido, né? Isso me faz lembrar daquele meme kkk

[GN⁺]

Comentários no Hacker News

• Acho que já existia "vibe coding" antes da IA

  • Já vi muitos desenvolvedores simplesmente saírem colocando null checks por todo lado sem pensar por que o objeto era null
  • Essa abordagem pode servir em alguns contextos, mas se o sistema inteiro for construído assim, a manutenção vira um pesadelo
  • O vibe coding com IA parece acelerar esse estilo de "ver na tela o resultado que você quer sem saber por que funciona"
  • Já trabalhei numa empresa assim, e os null checks acabavam engolindo exceções, então os erros ficavam silenciosamente escondidos
    • O time se elogiava como se fosse brilhante, mas na prática era um sistema rodando com código copiado e colado do StackOverflow e uma arquitetura MVP antiga
    • Nesse ambiente, pensar de forma independente era quase impossível
    • Ainda assim, ferramentas como Claude Code aumentam bastante a produtividade em codebases bem projetadas
  • Copiar e colar do StackOverflow e parar no nível de "se está mais ou menos funcionando, tá bom" é exatamente vibe coding
    • A IA só automatizou esse processo
  • Em vez de "ver o que quer ver", a descrição mais correta é "colocar qualquer coisa na tela"
    • Um null check colocado sem pensar pode causar depois erros sutis de dados, e aí fica muito difícil rastrear a causa
  • Também concordo que o vibe coding torna o desenvolvedor dependente de StackOverflow ainda mais rápido
    • Aumenta o número de desenvolvedores que não resolvem problemas por conta própria
    • E, além disso, a confiabilidade fica ainda menor do que antes
  • O que mais me irrita ao usar IA é que ela tende a seguir exatamente um estilo de código mediano de cada linguagem
    • Eu sigo o princípio de que, se você não cria dados errados, não precisa tratá-los depois, mas a IA vive quebrando isso
    • Quase nunca faz definições de tipos nem mantém invariants, e tenta resolver tudo com strings e inteiros
    • Por isso eu uso IA de forma interrompida, mais no estilo tab-complete, e corrijo pessoalmente os erros estruturais
    • Depois da correção, a IA passa a seguir a direção certa, então se a integração com IDE e LSP melhorar, isso pode ficar muito mais útil

• As críticas ao vibe coding fazem sentido, mas na verdade a qualidade do código já era péssima antes da IA

  • A maior parte do código já era entregue devagar e com baixa qualidade
  • Se entregar mais rápido aumenta a velocidade de validar ideias, tem gente que acha aceitável tolerar certo nível de erro
  • Hoje em dia é cada vez mais comum a diretoria perguntar "por que uma funcionalidade desse tamanho leva meses?"
  • Mas o motivo de funcionalidades pequenas demorarem tanto não é o algoritmo, e sim a infraestrutura e a estrutura de colaboração
    • A IA não consegue resolver esses problemas de base
  • O custo de manutenção e a complexidade se acumulam com o tempo como juros compostos
    • Vibe coding pode servir para projetos de curto prazo, mas não é adequado para sistemas de longo prazo
  • Acho importante equilibrar o desenvolvedor intencional com o desenvolvedor vibe
    • A IA fortalece demais o lado vibe e acaba quebrando o equilíbrio do sistema
  • Mais importante que qualidade de código é o entendimento compartilhado entre o problema de negócio e a solução técnica
    • Mesmo com qualidade baixa, é mais importante saber claramente o porquê disso e quais são os trade-offs
  • Mas não dá para ver como algo positivo quando alguém que não entende de software diz ao desenvolvedor que ele está fazendo tudo errado

• Dizer que "código de IA gera 1,7x mais problemas" fala apenas do número de bugs encontrados

  • Na prática, como os PR reviews muitas vezes não são bem feitos, vários problemas no código gerado por IA também passam batido
  • Também há pesquisas dizendo que code review deveria focar mais em entendimento e compartilhamento da estrutura do que em caça a bugs
  • Por outro lado, há quem diga que código gerado por IA é mais comentado e mais fácil de ler, então acaba sendo revisado com mais cuidado
    • Em código escrito por humanos, há mais comentários do tipo "não sei o que é isso, mas se apagar quebra"

• Outro dia o Copilot me sugeriu uma implementação de IComparable em .NET e isso me poupou alguns minutos

  • Só que ele trocou os nomes das variáveis para x e y, e eu passei uma hora debugando
  • Se eu tivesse escrito aquilo sozinho, não teria cometido esse erro
  • Mesmo assim, no fim das contas o resultado ficou quase igual ao código que eu escreveria

• Já vimos uma situação parecida antes

  • Se você ignora tratamento de erro e edge cases, consegue entregar muito mais rápido, mas no fim isso vira uma bomba de bugs
  • A IA dá a sensação de empurrar isso ao extremo
  • Até apareceu a piada de que, se for assim, talvez fosse melhor migrar logo para Erlang ou Elixir

• Foi interessante ver uma empresa baseada em LLM dizer que a IA é menos ruim do que parece

  • Mas a Coderabbit é uma empresa de code review com LLM, então ela tem até incentivo para dizer "a IA é bagunçada, então você precisa revisar com IA"
  • Eu também uso Copilot como ferramenta de review, e review com IA quase sempre acerta, então ajuda bastante antes da revisão humana

• Eu uso bastante o CodeRabbit, mas ainda há muitos falsos positivos

  • Às vezes ele aponta "falta validação de dados" mesmo quando o código já foi validado
  • Ainda assim, se você disser que ele está errado, a ferramenta aprende isso e aceita

• "1,7x mais" e "aumentou 1,7x" não são a mesma coisa

  • Mas essa discussão de números no fim parece uma briga sem sentido

• Agentic AI coding é só uma ferramenta; se for usada do jeito errado, obviamente vai produzir resultado errado

  • Como exemplo de uso bem-sucedido, recomendo o caso do justhtml em Python
  • Mas essa lógica de preto no branco de que "se você não sabe usar, então é incompetente" é problemática
    • Você achar IA útil ou não é, no fim, apenas uma diferença de experiência

• A frase do título, "código de IA gera 1,7x mais problemas", é imprecisa

  • Na prática, "problemas" inclui não só bugs, mas também questões de formatação e naming
  • O número de bugs em si não está especificado na matéria