70% dos desenvolvedores sabem que IA escreve código com falhas — e ainda assim o colocam em produção

70% dos desenvolvedores sabem que IA escreve código com vazamentos — E ainda assim o implementam em produção

Uma nova pesquisa revela um paradoxo: 70% dos desenvolvedores consideram o código de IA inseguro, mas 30% deles ainda o implementam em produção — sem verificações adicionais.

Números sem sensacionalismo

A pesquisa cobriu desenvolvedores que usam ativamente assistentes de IA — GitHub Copilot, ChatGPT, Claude e outras ferramentas. O quadro é consistente: a maioria reconhece os riscos, mas a pressão de prazos e a ilusão de confiabilidade prevalecem. 70% admitem que a IA produz consistentemente código com vulnerabilidades, erros de lógica, padrões de segurança desatualizados ou arquitetura claramente ruim.

Um em cada três deles implementa tal código em ambientes de produção — sem revisão, sem análise estática, às vezes sem testes. Não se trata de casos isolados de negligência — é sintoma de um problema sistêmico. O autor de uma coluna no Habr, ex-membro da equipe PVS-Studio, fala diretamente: para ele isso não é uma descoberta.

Tinha conversas sobre expectativas infladas de ferramentas de IA há um ano. O novo é que a indústria de repente começou a discutir o problema como algo inesperado.

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

A raiz do problema está na natureza mesma dos modelos de linguagem. A IA gera código confiante, sem ressalvas. A sintaxe está correta, a estrutura é familiar, o linter está silencioso. O desenvolvedor vê um resultado "parece que funciona" — e diminui a percepção crítica. Este é um fenômeno psicológico bem estudado: quanto mais autoritária a fonte, mais fraco o ceticismo. A IA produz resultados instantaneamente — o que adicionalmente cria a impressão de que "o modelo já verificou tudo". Na prática, não é assim.

"Expectativas são infladas, e há confiança excessiva em código gerado

— assim como em textos em geral".

Um modelo de linguagem não conhece a lógica empresarial de um sistema particular, não entende quais dados virão durante a operação real. Pode reproduzir padrões vulneráveis — injeções SQL, padrões inseguros, falta de validação de entrada — simplesmente porque apareciam frequentemente no corpus de treinamento. Alucinações em código não são raras mas uma consequência natural. O problema é agravado pelo progresso das próprias ferramentas. Desenvolvedores observam melhorias mês após mês e tendem a extrapolar: "costumava cometer erros, agora notavelmente melhor". Mas "melhor" não é igual a "seguro" — essa lacuna é a fonte de incidentes.

Perguntas que deviam ter sido feitas antes

Agora a indústria passa por uma reconsideração tardia. Os times se fazem perguntas que deviam ter sido levantadas quando os assistentes de IA foram implantados pela primeira vez:

• É necessária uma lista de verificação separada para revisar código gerado por IA?
• Como configurar CI/CD para detectar automaticamente erros típicos de geradores?
• Como você ensina júniores que já se acostumaram a confiar no autocompletado?
• Que papel devem desempenhar os analisadores estáticos em um pipeline com IA?
• Como você explica à gerência que "gerado em 10 segundos" não é o mesmo que "pronto para implementar"?

A maioria dos times tateia respostas por tentativa e erro — às vezes ao custo de incidentes reais em produção.

O que isso significa

O problema não é com a IA como tecnologia. O problema é com o posicionamento: as ferramentas são vendidas como substituição de desenvolvedor, mas funcionam como um rascunho que requer verificação. Até que os times desenvolvam uma cultura de revisão obrigatória de código de IA — as estatísticas só piorarão. A solução é velha e chata: análise estática, revisão de código obrigatória, cobertura de testes e compreensão clara de que velocidade de geração não é igual à qualidade do resultado. As ferramentas para isso existem há muito tempo. A questão está na disciplina de sua aplicação.