Assistentes de AI no coding: a qualidade está caindo?

Nos últimos meses, percebi uma tendência preocupante no desempenho dos assistentes de IA para codificação. Após dois anos de melhoria consistente, ao longo de 2025, a maioria dos modelos básicos atingiu um platô e, ultimamente, parece estar realmente degradando. Uma tarefa que levava cinco horas com IA e dez sem ela, agora leva sete a oito horas ou mais. Cheguei até a reverter para versões mais antigas de grandes modelos de linguagem (LLMs).

Eu uso ativamente código gerado por LLMs no meu trabalho como CEO da Carrington Labs, uma fornecedora de modelos de previsão de risco para credores. Meu time tem um sandbox onde criamos, implantamos e executamos código gerado por IA sem intervenção humana. Os usamos para extrair recursos úteis para construir modelos, aplicando uma espécie de "seleção natural" no desenvolvimento de recursos. Isso me dá uma oportunidade única de avaliar o desempenho dos assistentes de codificação.

Até recentemente, o problema mais comum com assistentes de IA para codificação era a sintaxe ruim, seguida por lógica falha. O código criado por IA frequentemente produzia erros de sintaxe ou se enredava em estrutura incorreta. Isso podia ser frustrante: a solução geralmente envolvia revisão detalhada do código manualmente e encontrar o erro. Mas, em última análise, isso era corrigível.

Porém, LLMs lançados recentemente, como o GPT-5, empregam um modo de falha muito mais insidioso. Frequentemente, geram código que não realiza a tarefa pretendida, mas parece executar com sucesso à primeira vista, evitando erros de sintaxe ou falhas óbvias. Isso é conseguido removendo verificações de segurança, criando saída fictícia que corresponde ao formato desejado, ou usando outros truques para evitar falhas em tempo de execução.

Qualquer desenvolvedor dirá que tal falha silenciosa é muito pior do que uma queda. Resultados incorretos frequentemente se escondem silenciosamente no código até aparecerem muito depois. Isso cria 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 intencionalmente projetadas para falhar de forma rápida e alta.

Notei esse problema episodicamente nos últimos meses, mas recentemente conduzi um teste simples, mas sistemático, para determinar se a situação realmente está piorando. Escrevi código em Python que carregava um dataframe e depois procurava por uma coluna inexistente.

Obviamente, esse código nunca seria executado com sucesso. Python gera uma mensagem de erro clara explicando que a coluna "index_value" não foi encontrada. Qualquer pessoa vendo essa mensagem verificaria o dataframe e notaria que a coluna está faltando.

Enviei essa mensagem de erro para nove versões diferentes do ChatGPT, principalmente variações do GPT-4 e do GPT-5 mais novo. Pedi a cada um que corrigisse o erro, especificando que eu precisava apenas do código completo, sem comentários.

Isso é, é claro, uma tarefa impossível – o problema está nos dados ausentes, não no código. Portanto, a melhor resposta seria uma recusa direta ou, na melhor das hipóteses, código que me ajudasse a depurar o problema. Conduzi 10 testes para cada modelo e classifiquei o resultado como útil (onde se presumia que a coluna provavelmente estava faltando no dataframe), inútil (algo como simplesmente repetir minha pergunta) ou contraproducente (como criar dados fictícios para evitar o erro).

O GPT-4 deu uma resposta útil todas as 10 vezes. Em três casos, ignorou minhas instruções de retornar apenas o código, explicando que a coluna provavelmente estava faltando no meu conjunto de dados e que eu precisaria resolver esse problema lá. Em seis casos, tentou executar o código, mas adicionou uma exceção que ou lançava um erro, ou preencheria uma nova coluna com uma mensagem de erro se a coluna não fosse encontrada (na 10ª vez, simplesmente repetiu meu código original).

O GPT-5, por contraste, encontrou uma solução que funcionava toda vez: simplesmente pegava o índice real de cada linha (em vez do fictício "index_value") e adicionava 1 a ele para criar new_column. Este é o pior resultado possível: o código executa com sucesso e à primeira vista parece estar fazendo tudo corretamente, mas o valor resultante é essencialmente um número aleatório. Em um exemplo real, isso criaria uma dor de cabeça muito maior mais tarde no código.

Eu estava curioso se esse problema era específico da família de modelos gpt. Não testei cada modelo existente, mas para verificar, repeti meu experimento nos modelos Claude do Anthropic. Encontrei a mesma tendência: modelos Claude mais antigos, quando confrontados com esse problema insolúvel, essencialmente encolhem os ombros, enquanto modelos mais novos às vezes resolvem o problema e às vezes apenas varrem para debaixo do tapete.

Não tenho informações privilegiadas sobre por que novos modelos falham de forma tão prejudicial. Mas tenho um palpite fundamentado. Acredito que isso é resultado de como os LLMs são treinados em código. Modelos mais antigos foram treinados em código praticamente da mesma forma que outro texto. Grandes volumes de código presumivelmente funcional foram aceitos como dados de treinamento, que foram usados para definir os pesos do modelo. Isso nem sempre era perfeito, como qualquer um que usou IA para codificação no início de 2023 se lembra, com frequentes erros de sintaxe e lógica falha. Mas certamente não removeu verificações de segurança e encontrou maneiras de criar dados plausíveis mas falsos, como o GPT-5 fez no meu exemplo acima.

Mas uma vez que assistentes de IA para codificação apareceram e foram integrados em ambientes de codificação, criadores de modelos perceberam que tinham uma fonte poderosa de dados de treinamento rotulados: o comportamento dos próprios usuários. Se um assistente propôs código sugerido, o código foi executado com sucesso e o usuário aceitou o código, isso era um sinal positivo, evidência de que o assistente tinha feito tudo corretamente. Se o usuário rejeitava o código ou o código não era executado, isso era um sinal negativo, e quando retreinando o modelo, o assistente era direcionado em uma direção diferente.

Esta é uma ideia poderosa que indiscutivelmente contribuiu para a melhoria rápida dos assistentes de IA para codificação durante um certo período. Mas à medida que mais e mais programadores inexperientes começaram a aparecer, isso também começou a envenenar os dados de treinamento. Assistentes de IA para codificação que encontraram maneiras de conseguir que os usuários aceitassem seu código continuaram a fazê-lo cada vez mais, mesmo que "isso" significasse desabilitar verificações de segurança e criar dados plausíveis mas inúteis. Enquanto a sugestão fosse aceita, era considerada boa, e era improvável que a dor subsequente pudesse ser rastreada até a fonte.

A geração mais recente de assistentes de IA para codificação foi ainda mais longe, automatizando cada vez mais do processo de codificação com recursos semelhantes ao piloto automático. Isso apenas acelera o processo de suavização, pois há menos pontos onde um humano pode ver o código e entender que algo está errado. Em vez disso, o assistente provavelmente continuará iterando em uma tentativa de alcançar a execução bem-sucedida. Ao fazer isso, provavelmente aprende as lições erradas.

Acredito firmemente em inteligência artificial e considero os assistentes de IA para codificação desempenhando um papel importante na aceleração do desenvolvimento e democratização do processo de criação de software. Mas a perseguição por ganhos de curto prazo e dependência de dados de treinamento baratos, abundantes, mas finalmente de baixa qualidade continuará a resultar em resultados de modelo que são piores do que inúteis. Para melhorar modelos novamente, empresas de IA no espaço de codificação precisam investir em dados de alta qualidade, possivelmente até pagando especialistas para anotar código gerado por IA. Caso contrário, modelos continuarão a produzir lixo, aprender com esse lixo e, consequentemente, produzir ainda mais lixo, comendo seus próprios rabos.