
Código de IA acerta testes mas acumula lixo estrutural, aponta estudo
O problema
Modelos de linguagem se tornaram quase perfeitos em gerar código, mas isso não encerra a questão. Um código formalmente correto pode introduzir abstrações desnecessárias, duplicações e decisões ruins. Em projetos desenvolvidos com vibe coding, cada recurso adicional pode levar a uma explosão de linhas de código (LOC). O resultado é perda de agência humana: em projetos que somam milhões de LOC por mês, é difícil para pessoas acompanharem. A análise afirma que agentes também não conseguem lidar sozinhos com esse “slop”.
Por que medir é difícil
O pesquisador, vindo da física, adotou abordagem experimental e quantitativa ao tentar medir a qualidade do código. Ele relata que, fora alguns papers relevantes, a indústria parece baseada em “vibes”, com mensagens sobre agentes de codificação ponta a ponta e avaliação em nível humano. LLMs escrevem código quase perfeitamente correto porque código é escalável e verificável: gerar e depois checar com testes escondidos produz sinal de recompensa claro. Medir a “sujeira” do código, porém, exige intuição e gosto humano, tarefa extremamente difícil.
Métodos de avaliação
A IA como juiz é a forma mais comum, mas raramente funciona. Perguntar a modelos a qualidade de 1 a 10 equivale a um gerador aleatório. Na comparação A/B, o modelo pode mudar de preferência se as soluções forem renomeadas; o efeito é menor em modelos maiores, mas a crítica permanece. Pedir que LLMs julguem seu próprio código não substitui uma avaliação adequada; rubricas e testes escritos por LLMs ainda estão longe de eliminar o slop.
Humanos julgando a IA seria a melhor solução para manter legibilidade, mas não escala para treinar IA ou criar grandes benchmarks com vários provedores.
A métrica mais simples - variação no número de LOC - foi surpreendentemente eficaz, mas deixaria de ser significativa se fosse otimizada. O SlopCodeBench propõe duas medidas: verbosidade, que divide linhas sinalizadas por AST-Grep e linhas clonadas pelo total de LOC; e erosão, que calcula a fração da massa das funções com complexidade ciclomática maior que 10 sobre a massa total, em que massa(f) = CC(f) × raiz de SLOC(f).
Evidências
No SlopCodeBench, a verbosidade média de repositórios estabelecidos foi 0,15 ± 0,06, contra 0,33 ± 0,10 no código de agentes. A erosão foi 0,31 ± 0,17 nos repositórios e 0,68 ± 0,20 no código de agentes. Em média, o código dos agentes é cerca de duas vezes mais verboso e erodido que o código humano. Projetos vibe-coded do próprio pesquisador chegaram a verbosidade de até 0,4 e erosão de até 0,75, sugerindo que os resultados não são artefato da avaliação.
Avaliação iterativa e conclusão
Diferentemente de outros benchmarks, o SlopCodeBench cria múltiplas rodadas de instruções e testes, apagando o contexto entre checkpoints para imitar o uso real por agentes. Decisões ruins se acumulam. Na taxa estrita, em que todos os testes precisam passar em todos os checkpoints, até modelos de ponta atingem 0% de aprovação. Isso serve de alerta para quem adiciona dezenas ou centenas de milhares de LOC por dia, embora existam ressalvas sobre testes rígidos demais ou enunciados ambíguos; a tendência geral se mantém. O pesquisador diz que a avaliação ainda não testou Fable 5.1 ou Astra, mas incluiu GPT 5.6 sol xhigh e outros. Ele conclui que medir slop é difícil e que intuição e gosto humanos continuam, implícita ou explicitamente, presentes. Direções futuras incluem acoplamento entre funções, churn de código e coesão. Como resume uma citação mencionada, medir progresso de programação por linhas de código é como medir progresso de um avião pelo peso.