Tem algo estranho acontecendo com a forma como desenvolvedores usam inteligência artificial. Os números de adoção estão nas alturas. Quase todo mundo usa. E quase ninguém confia no que sai do outro lado.

Não estamos falando de uma minoria cética resistindo à mudança. Estamos falando da maioria dos desenvolvedores que abre o Copilot, o Cursor ou o ChatGPT todo dia, aceita as sugestões, e depois fica com aquela sensação de que precisa revisar tudo de novo. Esse descompasso entre uso e confiança diz muito sobre onde a IA para código está de verdade.

O paradoxo da adoção sem confiança

O Stack Overflow Developer Survey de 2025 trouxe um dado que resume bem a situação: 80% dos desenvolvedores usam ferramentas de IA nos seus workflows. No mesmo levantamento, a confiança na precisão dessas ferramentas caiu de 40% para 29% em relação ao ano anterior. A favorabilidade geral em relação à IA também recuou, de 72% para 60%.

Isso não é um grupo de pessoas testando uma novidade com ceticismo saudável. São profissionais que já incorporaram IA na rotina e, com o tempo, passaram a confiar menos. A exposição prolongada não gerou familiaridade reconfortante. Gerou desconfiança informada.

Outro levantamento de 2026 aponta que 92% dos desenvolvedores usam ferramentas de IA em alguma parte do workflow. Desses, 46% dizem não confiar na precisão do output. Apenas 3% relatam alta confiança. Quando o resultado parece duvidoso, 75% recorrem a colegas humanos em vez de tentar refinar o prompt.

O que os números dizem

Vale olhar os dados com mais cuidado, porque os números contam histórias diferentes dependendo de onde você foca.

Pelo lado da produtividade, 81% dos usuários do GitHub Copilot relatam completar tarefas mais rápido. A estimativa média de ganho fica entre 10% e 30%, com alguns estudos apontando economia de 30% a 60% do tempo em tarefas de codificação e testes.

Pelo lado da qualidade, a história muda. Uma análise da GitClear sobre 211 milhões de linhas de código mostrou que código gerado por IA tem 4 vezes mais clonagem e uma taxa de churn 41% maior. A porcentagem de linhas associadas a refatoração caiu de 24% em 2020 para menos de 10% em 2024. Linhas classificadas como copy/paste subiram de 8,3% para 12,3% no mesmo intervalo.

Ou seja: o código sai rápido, mas sai pior. E ninguém está parando para refatorar.

O problema do "quase certo"

A frustração número um dos desenvolvedores entrevistados pelo Stack Overflow, citada por 45% dos respondentes, é lidar com soluções de IA que estão "quase certas, mas não exatamente". E 66% reportam gastar mais tempo corrigindo esse tipo de código do que gastariam com código claramente errado.

Isso faz sentido. Código completamente errado falha nos testes, quebra no build, aparece na hora. Código quase certo passa nos testes, funciona na demo, e quebra em produção às três da manhã num cenário de borda que ninguém testou.

O quase certo é pior que o errado porque cria uma falsa sensação de segurança. O desenvolvedor olha o output, parece razoável, os testes passam, e segue em frente. O bug fica latente. E quando surge, o contexto original já se perdeu.

Para piorar, apenas 48% dos desenvolvedores dizem sempre revisar o código gerado por IA antes de commitar. A outra metade está empurrando código semi-revisado para produção, criando o que pesquisadores chamam de "dívida de verificação".

O custo invisível: segurança e dívida técnica

Se a qualidade funcional já preocupa, a segurança é um problema ainda mais sério.

O GenAI Code Security Report da Veracode analisou código produzido por mais de 100 LLMs em 80 tarefas reais de programação. O resultado: 45% do código gerado continha vulnerabilidades alinhadas com o OWASP Top 10.

Alguns números específicos assustam. Em Java, a taxa de falha de segurança passou de 70%. Entre todos os exemplos analisados, 86% falharam em proteger contra cross-site scripting (CWE-80) e 88% eram vulneráveis a ataques de log injection (CWE-117).

O detalhe que me pega: a maioria dos modelos maiores não teve desempenho significativamente melhor que modelos menores nessas métricas, embora exceções recentes como GPT-5 tenham alcançado taxas de aprovação acima de 70%. Isso sugere que o problema não é de escala ou capacidade. É estrutural. LLMs aprendem padrões estatísticos de código existente, e código existente já tem um histórico ruim de segurança.

No lado prático, um relatório de 2026 da Aikido Security revelou que código gerado por IA é responsável por 1 em cada 5 brechas de segurança. Dos 450 profissionais entrevistados (desenvolvedores, engenheiros de AppSec e CISOs), 69% encontraram vulnerabilidades introduzidas por código de IA nos próprios sistemas.

A ilusão de velocidade

Talvez o dado mais revelador venha de um estudo da METR (Model Evaluation & Threat Research), publicado em julho de 2025. Pesquisadores recrutaram 16 desenvolvedores experientes de projetos open-source com mais de 22 mil stars e mais de 1 milhão de linhas de código. Cada desenvolvedor recebeu tarefas do seu próprio repositório, incluindo bug fixes, features e refatorações.

O estudo usou um desenho de controle randomizado: para cada tarefa, a IA era permitida ou proibida aleatoriamente. Os desenvolvedores usaram Cursor Pro com Claude 3.5/3.7 Sonnet quando a IA estava liberada. Todos tinham dezenas a centenas de horas de experiência com prompts.

Os resultados: desenvolvedores levaram 19% mais tempo para completar tarefas com IA do que sem IA. A amostra é pequena (16 devs) e os próprios pesquisadores reconhecem limitações de generalização, mas é o primeiro ensaio controlado randomizado publicado sobre o tema.

Mas eles achavam que estavam mais rápidos. Antes do estudo, esperavam um ganho de 24%. Depois, estimaram ter sido 20% mais rápidos. Na realidade, foram quase 20% mais lentos.

Isso não é preguiça ou incompetência. É que a sensação de produtividade que vem de ver código sendo gerado instantaneamente mascara o tempo real gasto em revisão, debugging e correção. O ato de gerar código é rápido. O ato de garantir que o código funciona continua levando o mesmo tempo de sempre. Ou mais.

O que fazer na prática

Nada disso significa abandonar ferramentas de IA. Significa parar de usá-las no piloto automático.

Algumas práticas que fazem diferença concreta:

  • Revisar sempre. Parece óbvio, mas metade dos devs não faz. Tratar código de IA com o mesmo rigor de um pull request de um colega júnior: ler linha por linha, questionar decisões, verificar edge cases
  • Focar em tarefas onde IA de fato brilha: boilerplate, testes unitários, documentação, scaffolding. Para lógica de negócio complexa e código sensível a segurança, escrever na mão ainda compensa
  • Medir de verdade. O estudo da METR mostrou que percepção de velocidade engana. Se seu time quer saber se IA está ajudando, precisa medir tempo real de entrega, taxa de bugs e churn de código. Não basta perguntar "vocês se sentem mais produtivos?"
  • Rodar análise de segurança no código gerado. SAST (Static Application Security Testing) e dependency scanning não são opcionais quando quase metade do código de IA tem vulnerabilidades conhecidas
  • Manter a habilidade de programar sem IA. Desenvolvedores que dependem exclusivamente de autocomplete perdem a capacidade de raciocinar sobre problemas. É como usar GPS o tempo inteiro e não saber mais ler um mapa

Conclusão

O paradoxo de 2026 não é que devs usam IA apesar de não confiarem nela. O paradoxo é que continuam usando da mesma forma apesar de acumularem evidências de que precisam mudar a abordagem.

Os dados estão na mesa. Código de IA sai rápido, mas gera mais bugs, mais clonagem, mais vulnerabilidades e mais dívida técnica. Desenvolvedores acham que estão mais rápidos, mas medições objetivas mostram o contrário. A confiança cai ano a ano enquanto a adoção sobe.

IA para código funciona. Mas funciona como uma ferramenta elétrica: nas mãos certas, com as proteções certas, acelera o trabalho. Sem cuidado, o estrago é proporcional à potência.

Referências pesquisadas nesta publicação