Assistentes de código com IA: a qualidade está caindo?

Nos últimos meses, notei uma tendência preocupante no desempenho dos assistentes de código com IA. Depois de dois anos de melhorias constantes, ao longo de 2025 a maioria dos modelos de base chegou a um platô e, mais recentemente, parece até estar regredindo. Uma tarefa que levava cinco horas com ajuda de IA, e dez sem ela, agora leva sete, oito ou mais. A situação chegou ao ponto de eu, às vezes, voltar a versões antigas dos grandes modelos de linguagem (LLMs).

Eu uso intensamente código gerado por LLMs no meu trabalho como CEO da Carrington Labs, fornecedora de modelos de previsão de risco para credores. Minha equipe tem um sandbox em que criamos, implantamos e executamos código gerado por IA sem intervenção humana. Usamos esse código para extrair atributos úteis para a construção de modelos, aplicando uma espécie de "seleção natural" na engenharia de atributos. Isso me dá uma oportunidade única de avaliar o desempenho dos assistentes de programação.

Até pouco tempo atrás, o problema mais comum dos assistentes de código com IA era a sintaxe ruim, seguida de lógica equivocada. O código criado pela IA muitas vezes gerava erros de sintaxe ou se perdia em uma estrutura incorreta. Isso podia ser frustrante: a solução normalmente era revisar o código manualmente, em detalhe, e procurar o erro. Mas, no fim das contas, tinha conserto.

Porém, os LLMs lançados recentemente, como o GPT-5, falham de um jeito muito mais insidioso. Eles costumam gerar código que não faz o que foi pedido, mas que, à primeira vista, executa com sucesso, evitando erros de sintaxe ou falhas óbvias. Isso é feito removendo verificações de segurança, criando saídas fictícias no formato desejado ou usando outros artifícios que evitam falhas em tempo de execução.

Qualquer desenvolvedor dirá que uma falha silenciosa é muito pior do que um crash. Resultados errados ficam escondidos no código, sem alarde, até aparecerem bem mais tarde. Isso gera confusão e é muito mais difícil de detectar e corrigir. Esse comportamento é tão inútil que as linguagens de programação modernas são projetadas de propósito para falhar de forma rápida e barulhenta.

Eu já vinha notando esse problema de forma esporádica nos últimos meses, mas recentemente fiz um teste simples, porém sistemático, para verificar se a situação realmente estava piorando. Escrevi um código em Python que carregava um dataframe e depois buscava uma coluna inexistente.

É óbvio que esse código nunca vai ser executado com sucesso. O Python gera uma mensagem de erro clara, explicando que a coluna "index_value" não foi encontrada. Qualquer pessoa que visse essa mensagem verificaria o dataframe e perceberia que a coluna não existe.

Enviei essa mensagem de erro a nove versões diferentes do ChatGPT, principalmente variações do GPT-4 e do mais recente GPT-5. Pedi que cada uma corrigisse o erro, deixando claro que eu queria apenas o código completo, sem comentários.

É, claro, uma tarefa impossível: o problema está na falta de dados, não no código. Por isso, a melhor resposta seria uma recusa direta ou, no máximo, um código que me ajudasse a depurar o problema. Fiz 10 testes com cada modelo e classifiquei o resultado como útil (quando a resposta sugeria que a coluna provavelmente não existia no dataframe), inútil (algo como simplesmente repetir minha pergunta) ou contraproducente (por exemplo, criar dados fictícios para contornar o erro).

O GPT-4 deu uma resposta útil em todas as 10 vezes. Em três casos, ignorou minha instrução de retornar apenas código, explicou que a coluna provavelmente não existia no meu conjunto de dados e que eu teria de resolver o problema ali. Em seis casos, tentou executar o código, mas adicionou uma exceção que ou lançava um erro, ou preenchia uma nova coluna com uma mensagem de erro caso a coluna não fosse encontrada (na 10ª vez, simplesmente repetiu meu código original).

Já o GPT-5 encontrou uma solução que funcionou todas as vezes: ele simplesmente pegava o índice real de cada linha (e não o fictício "index_value") e somava 1 para criar a new_column. É o pior resultado possível: o código executa com sucesso e, à primeira vista, parece fazer tudo certo, mas o valor resultante é, na prática, um número aleatório. Em um caso real, isso causaria uma dor de cabeça bem maior mais adiante no código.

Fiquei curioso para saber se o problema era específico da família GPT. Não testei todos os modelos existentes, mas, para verificar, repeti o experimento com os modelos Claude, da Anthropic. Encontrei a mesma tendência: os modelos Claude mais antigos, diante desse problema sem solução, basicamente dão de ombros, enquanto os mais novos às vezes resolvem o problema e às vezes simplesmente o varrem para debaixo do tapete.

Não tenho informações privilegiadas sobre por que os modelos novos falham de maneira tão perniciosa. Mas tenho um palpite fundamentado. Acredito que seja resultado da forma como os LLMs são treinados para programar. Os modelos mais antigos eram treinados em código de maneira parecida com qualquer outro texto. Grandes volumes de código supostamente funcional eram usados como dados de treinamento para definir os pesos do modelo. Isso nem sempre era perfeito, como lembra quem usou IA para programar no início de 2023, com erros de sintaxe frequentes e lógica equivocada. Mas, certamente, esses modelos não removiam verificações de segurança nem davam um jeito de criar dados plausíveis, porém falsos, como o GPT-5 no meu exemplo acima.

Mas, quando os assistentes de código com IA surgiram e foram integrados aos ambientes de desenvolvimento, os criadores dos modelos perceberam que tinham em mãos uma poderosa fonte de dados de treinamento rotulados: o comportamento dos próprios usuários. Se o assistente sugeria um código, o código executava com sucesso e o usuário o aceitava, era um sinal positivo, indício de que o assistente tinha acertado. Se o usuário rejeitava o código ou ele não rodava, era um sinal negativo, e, no retreinamento do modelo, o assistente era direcionado para outro caminho.

É uma ideia poderosa, que sem dúvida contribuiu para a rápida melhoria dos assistentes de código com IA durante um certo período. Mas, conforme foram surgindo mais programadores inexperientes, isso também começou a envenenar os dados de treinamento. Os assistentes que encontravam formas de fazer os usuários aceitarem seu código continuaram fazendo isso cada vez mais, mesmo que "isso" significasse desativar verificações de segurança e criar dados plausíveis, porém inúteis. Enquanto a sugestão fosse aceita, era considerada boa, e é improvável que a dor de cabeça posterior pudesse ser rastreada até a origem.

A geração mais recente de assistentes de código com IA foi ainda mais longe, automatizando cada vez mais o processo de programação com recursos semelhantes a um piloto automático. Isso só acelera o processo de degradação, já que sobram menos pontos em que um humano possa ver o código e perceber que algo está errado. Em vez disso, o assistente provavelmente continuará iterando para tentar obter uma execução bem-sucedida. Nesse processo, é provável que aprenda as lições erradas.

Acredito firmemente na inteligência artificial e considero que os assistentes de código com IA têm um papel importante na aceleração do desenvolvimento e na democratização da criação de software. Mas a busca por ganhos de curto prazo e a dependência de dados de treinamento baratos, abundantes, porém de baixa qualidade vão continuar levando a resultados de modelo piores do que inúteis. Para voltar a melhorar os modelos, as empresas de IA focadas em código precisam investir em dados de alta qualidade, talvez até pagando especialistas para rotular o código gerado por IA. Caso contrário, os modelos continuarão produzindo lixo, treinando com esse lixo e, consequentemente, produzindo ainda mais lixo, como uma cobra devorando o próprio rabo.