Medindo a Desleixo do Código: Métricas de Verbosidade e Erosão

Os LLMs tornaram-se muito bons em gerar código que passa nos testes. Mas código correto ainda pode ser desleixado: cheio de linhas duplicadas, abstrações desnecessárias e escolhas de design ruins. Como o autor observa, "só porque o código é formalmente correto não significa que não esteja introduzindo abstrações desnecessárias, criando duplicatas ou simplesmente tomando decisões ruins no geral". O resultado é uma explosão no número de linhas de código (LOC) que é difícil para os humanos acompanharem e — ao contrário de algumas alegações — os agentes também não conseguem gerenciar a desleixo.

Por que o LLM-como-juiz não funciona

O artigo descarta a abordagem comum da indústria de usar IA para julgar a qualidade do código. Pedir a um modelo para avaliar o código de 1 a 10 é "basicamente equivalente a um gerador de números aleatórios". Comparações pareadas (A vs. B) são instáveis: simplesmente renomear as soluções pode inverter a preferência do modelo. Rubricas e testes escritos por LLM ajudam, mas "ainda estão longe de realmente se livrar da desleixo".

A métrica mais simples: mudança no LOC

Surpreendentemente eficaz: apenas rastrear a mudança no número de linhas de código. O autor observa a ironia: "se começássemos a otimizar para isso, deixaria de ser uma medida significativa".

Verbosidade

Mede linhas duplicadas e desnecessariamente verbosas. É a fração de linhas sinalizadas pelo AST-Grep ou marcadas como clones, dividida pelo LOC total:

Verbosidade = |linhas sinalizadas pelo AST-Grep ∪ linhas de clone| / LOC

Erosão

Mede quanto da massa de uma base de código está concentrada em algumas funções grandes e complexas. Primeiro, defina a massa de uma função:

massa(f) = CC(f) * sqrt(SLOC(f))

Onde CC(f) é a complexidade ciclomática e SLOC(f) são as linhas de código fonte. Então a erosão é a fração da massa total detida por funções com complexidade ciclomática maior que 10:

Erosão = ∑_{f: CC(f) > 10} massa(f) / ∑_f massa(f)

Essas duas medidas — introduzidas pelo artigo SlopCodeBench — separaram bem bases de código legadas do desleixo gerado por LLM nos testes do autor.

Conclusões

• Juízes LLM são não confiáveis para qualidade de código; a preferência muda ao renomear.
• A mudança no LOC é um sinal de desleixo surpreendentemente forte, mas quebra se otimizado diretamente.
• A verbosidade combina sinalizações do AST-Grep e detecção de clones sobre o LOC.
• A erosão captura a massa de complexidade em funções com CC > 10.

Para equipes que entregam código gerado por LLM em escala, essas métricas oferecem uma alternativa quantitativa à avaliação baseada em vibes.