Los LLM se han vuelto casi perfectos generando código, pero eso no es el final de la historia. 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. Esta no es una observación revolucionaria; la mayoría de las personas que han hecho vibe-coding en un proyecto se han dado cuenta de que cada característica adicional a veces puede llevar a una explosión de líneas de código (LOC). Esto resulta en una pérdida de agencia humana, porque en proyectos que agregan millones de LOC por mes, es difícil para los humanos mantenerse al día. Algunas personas podrían decir que eso no es un problema en absoluto, porque confían en que sus agentes lo manejen. Tengo malas noticias para ti: los agentes tampoco pueden realmente lidiar con la dejadez.

Viniendo de una formación en física, siempre tuve un enfoque experimental/cuantitativo para resolver problemas. Cuando comencé en Earendil, con la tarea de descubrir cómo medir la dejadez del código, mi instinto natural fue primero sumergirme en la literatura y luego ver qué estaban haciendo otras compañías. Para ser franco, con la excepción de algunos artículos de investigación perspicaces, me decepcionó lo "basado en vibraciones" que parece estar la industria en este momento. En mi investigación y en X, fui constantemente bombardeado con mensajes como "Agentes de codificación de extremo a extremo", "IA que no solo sugiere código, sino que lo envía" o "Evaluación a nivel humano sin costo a nivel humano". Los cuales, como todos los buenos cuentos, tienen una pizca de verdad. Los LLM son capaces de escribir código casi perfectamente correcto. Esto se debe a la escalabilidad y verificabilidad del código. Es bastante sencillo dejar que los LLM generen código y luego dejar que ese código sea verificado por pruebas ocultas, lo que resulta en una señal de recompensa clara. En marcado contraste con eso, verificar la "dejadez" de este código a menudo requiere intuición y gusto humanos, y es una tarea extremadamente difícil en general.

Creo que la mejor manera de ilustrar por qué es eso es repasar las posibles formas de medir la dejadez. IA como juez: Esta es probablemente la forma más común de evaluar la calidad del código en la industria y, según mis observaciones, rara vez funciona. La forma más ingenua de hacerlo, es decir, preguntar a los modelos qué tan bueno es el código en una escala de 1 a 10, es básicamente equivalente a un generador de números aleatorios. El enfoque más sofisticado, es decir, intentar dar al modelo juez dos soluciones A y B, y luego dejar que decida cuál prefiere, tiene la desventaja de que el modelo cambia su preferencia cuando renombras las soluciones. Estoy siendo un poco sarcástico aquí y el efecto no es tan pronunciado con modelos más grandes, pero el punto principal sigue en pie. Pedir a los LLM que juzguen el código que escriben no es un sustituto de una evaluación adecuada. Aunque hay algunos enfoques interesantes con rúbricas o los LLM escribiendo pruebas, todavía están muy lejos de eliminar realmente la dejadez.

Humanos juzgan a la IA: Si ignoramos el hecho de que hay una gran diversidad en la calidad de los ingenieros de software, esta sería la mejor solución para asegurar que el código siga siendo legible para humanos. Con la desventaja de que esto no es escalable para entrenar IA o tener grandes benchmarks con múltiples proveedores de modelos y harnesses. El método más simple: En mi investigación y pruebas, simplemente tomar el cambio en el número de LOC ha sido una métrica sorprendentemente efectiva para la dejadez, con la irónica advertencia de que si comenzáramos a optimizar para ello, dejaría de ser una medida significativa. Las siguientes dos medidas me fueron introducidas por el artículo Slop Code Bench, y parecían prometedoras porque podían separar bases de código heredadas del slop de LLM bastante bien. Verbosidad: Intenta medir la cantidad de líneas duplicadas e innecesariamente verbosas. Erosión: Intenta medir cuánto de la masa de una base de código se concentra en unas pocas funciones grandes y complejas.

Entidades clave: Compañías: Earendil