Los LLM escriben código correcto y también inflado: dos métricas para medirlo
El análisis de un empleado de Earendil propone dos métricas —verbosidad y erosión— para cuantificar el código de relleno de los agentes, y recuerda que los modelos punteros sacan un 0% en pruebas iterativas.
Los LLM ya escriben código formalmente correcto casi siempre. El problema es lo que va dentro: abstracciones que no hacían falta, duplicados y decisiones discutibles que se van acumulando hasta volver el proyecto inmanejable. Un empleado de Earendil ha publicado un análisis sobre cómo medir ese relleno, y su conclusión incómoda es que el sistema dominante en la industria —poner a un modelo a juzgar código— no funciona.
Quien haya usado un agente para programar ya lo habrá notado: cada funcionalidad nueva puede disparar el número de líneas, y en proyectos que suman millones de LOC al mes la persona pierde el control. La salida fácil es confiar en que el propio agente ordene el desaguisado. El autor, formado en física, no lo tiene tan claro: los agentes tampoco saben lidiar con su propio relleno. Y cuenta que al revisar la literatura y lo que hacen otras empresas se encontró con una industria que decide a base de intuiciones.
Jueces que no juzgan
El método más extendido es pedirle a un modelo una nota del 1 al 10. Según el análisis, eso equivale a un generador de números aleatorios. La variante más elaborada, presentar dos soluciones A y B y pedir que elija, tiene otro problema: si renombras las soluciones, el modelo cambia de preferencia. Con modelos grandes el efecto se atenúa, pero no desaparece.
Poner a una persona a revisar da mejores resultados, con el coste de que no escala para entrenar modelos ni para comparar proveedores.
Queda la opción más simple: contar el cambio en el número de líneas. Al autor le ha resultado sorprendentemente eficaz, con la trampa conocida de la ley de Goodhart: en cuanto alguien optimice esa cifra, deja de medir nada.
Verbosidad y erosión
El banco de pruebas SlopCodeBench propone dos métricas que separan bien el código heredado del generado por agentes. La verbosidad divide las líneas marcadas por AST-Grep más las clonadas entre el total de LOC, y mide cuánto sobra. La erosión calcula la masa de cada función como su complejidad ciclomática multiplicada por la raíz de sus líneas de código, y devuelve qué fracción de esa masa se concentra en funciones con complejidad superior a 10: cuánto peso soportan unas pocas funciones monstruosas.
Los números que da el paper: en repositorios establecidos la verbosidad media es 0,15 ± 0,06 y la erosión 0,31 ± 0,17. En código de agentes, 0,33 ± 0,10 y 0,68 ± 0,20. Aproximadamente el doble. En proyectos propios escritos con ayuda de modelos, el autor ha visto verbosidad de hasta 0,4 y erosión de 0,75.
Lo interesante es cómo evalúa SlopCodeBench. En lugar de soltar todas las instrucciones al principio y comprobar con tests ocultos, plantea rondas de instrucciones y pruebas, y borra el contexto del modelo entre puntos de control. Se parece más a cómo se usa un agente de verdad, con decisiones malas que se acumulan. En la tasa estricta —pasar todas las pruebas en todos los controles— los modelos de última generación sacan un 0%. Argumenta el autor que eso debería hacer pensar a quien añade cientos de miles de líneas al día.
