Midiendo la dejadez del código: métricas de verbosidad y erosión

Los LLMs se han vuelto muy buenos generando código que pasa las pruebas. Pero el código correcto aún puede ser chapucero: lleno de líneas duplicadas, abstracciones innecesarias y malas decisiones de diseño. Como señala el autor: "el hecho de que el código sea formalmente correcto no significa que no esté introduciendo abstracciones innecesarias, creando duplicados o simplemente tomando malas decisiones en general". El resultado es una explosión en las líneas de código (LOC) que es difícil de seguir para los humanos y, en contra de algunas afirmaciones, los agentes tampoco pueden manejar esa chapucería.

Por qué el LLM como juez no funciona

El artículo descarta el enfoque común en la industria de usar IA para juzgar la calidad del código. Pedirle a un modelo que califique el código del 1 al 10 es "básicamente equivalente a un generador de números aleatorios". Las comparaciones por pares (A vs. B) son inestables: simplemente renombrar las soluciones puede cambiar la preferencia del modelo. Las rúbricas y las pruebas escritas por LLMs ayudan, pero "siguen estando muy lejos de eliminar realmente la chapucería".

La métrica más simple: cambio en LOC

Sorprendentemente efectivo: simplemente rastrear el cambio en el número de líneas de código. El autor señala la ironía: "si empezamos a optimizar para eso, dejaría de ser una medida significativa".

Verbosidad

Mide líneas duplicadas e innecesariamente verbosas. Es la fracción de líneas marcadas por AST-Grep o marcadas como clones, dividida por el total de LOC:

Verbosidad = |Líneas marcadas por AST-Grep ∪ líneas clonadas| / LOC

Erosión

Mide cuánto de la masa de una base de código se concentra en unas pocas funciones grandes y complejas. Primero define la masa de una función:

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

Donde CC(f) es la complejidad ciclomática y SLOC(f) son las líneas de código fuente. Entonces la erosión es la fracción de la masa total que tienen las funciones con complejidad ciclomática mayor que 10:

Erosión = ∑_{f: CC(f) > 10} masa(f) / ∑_f masa(f)

Estas dos medidas, introducidas por el artículo SlopCodeBench, separaron bastante bien las bases de código heredadas del código chapucero generado por LLMs en las pruebas del autor.

Conclusiones

• Los jueces LLM no son confiables para la calidad del código; la preferencia cambia al renombrar.
• El cambio en LOC es una señal de chapucería sorprendentemente fuerte, pero se rompe si se optimiza directamente.
• La verbosidad combina las marcas de AST-Grep y la detección de clones sobre LOC.
• La erosión captura la masa de complejidad en funciones con CC > 10.

Para los equipos que entregan código generado por LLMs a escala, estas métricas ofrecen una alternativa cuantitativa a la evaluación basada en sensaciones.