70% dos desenvolvedores sabem que a IA escreve código falho — e mesmo assim o colocam em produção

Um novo estudo revelou um paradoxo: 70% dos desenvolvedores consideram o código de IA inseguro, mas 30% deles o implantam em produção mesmo assim, sem verificações adicionais.

Números sem sensacionalismo

A pesquisa ouviu desenvolvedores que usam ativamente assistentes de IA, como GitHub Copilot, ChatGPT, Claude e outras ferramentas. O quadro é consistente: a maioria tem consciência dos riscos, mas a pressão dos prazos e a ilusão de confiabilidade falam mais alto.

70% admitem que a IA produz de forma recorrente código com vulnerabilidades, erros de lógica, padrões de segurança ultrapassados ou arquitetura simplesmente ruim. Um em cada três implanta esse código em ambientes reais, sem revisão, sem análise estática e, às vezes, sem testes. Não são casos isolados de negligência, mas sintoma de um problema sistêmico.

O autor de uma coluna no Habr, egresso da equipe da PVS-Studio, diz sem rodeios: para ele, isso não é uma descoberta. Ele já falava das expectativas infladas em relação às ferramentas de IA um ano atrás. A novidade é que o setor passou a discutir o problema de repente, como se fosse inesperado.

Por que o código da IA parece confiável

A raiz do problema está na própria natureza dos modelos de linguagem. A IA gera código com segurança e sem ressalvas. A sintaxe está correta, a estrutura é familiar, o linter não reclama. O desenvolvedor vê um resultado que "parece funcionar" e baixa a guarda crítica. É um fenômeno psicológico bem estudado: quanto mais autoridade tem a fonte, mais fraco é o ceticismo.

A IA entrega o resultado na hora, o que reforça a sensação de que "o modelo já verificou tudo". Na prática, não verificou.

"As expectativas estão infladas, e há confiança excessiva no código

gerado, assim como nos textos em geral."

Um modelo de linguagem não conhece a lógica de negócio de um sistema específico nem entende quais dados chegarão na operação real. Ele pode reproduzir padrões vulneráveis, como injeções de SQL, defaults inseguros e falta de validação de entrada, simplesmente porque esses padrões apareciam com frequência no corpus de treinamento. Alucinações em código não são raras; são regra.

O avanço das próprias ferramentas agrava o problema. Os desenvolvedores veem melhorias de mês a mês e tendem a extrapolar: "antes errava, agora está bem melhor". Mas "melhor" não é sinônimo de "seguro", e é nessa lacuna que nascem os incidentes.

Perguntas que deveriam ter sido feitas antes

O setor passa agora por uma reflexão tardia. As equipes se fazem perguntas que deveriam ter surgido na adoção inicial dos assistentes de IA:

• É preciso um checklist específico para revisar código gerado por IA?
• Como configurar o CI/CD para detectar automaticamente os erros típicos dos geradores?
• Como treinar os juniores que já se acostumaram a confiar no autocompletar?
• Que papel os analisadores estáticos devem ter em um pipeline com IA?
• Como explicar à gerência que "gerado em 10 segundos" não significa "pronto para deploy"?

A maioria das equipes busca respostas na base da tentativa e erro, às vezes ao custo de incidentes reais em produção.

O que isso significa

O problema não é a IA como tecnologia. O problema é o posicionamento: as ferramentas são vendidas como substitutas do desenvolvedor, mas funcionam como um rascunho que exige verificação. Enquanto as equipes não criarem uma cultura de revisão obrigatória do código de IA, as estatísticas só vão piorar.

A solução é velha e chata: análise estática, code review obrigatório, cobertura de testes e a compreensão clara de que velocidade de geração não é qualidade do resultado. As ferramentas para isso existem há muito tempo. A questão é a disciplina para aplicá-las.