Los LLM escriben código casi perfecto, pero el código generado es el doble de verboso y erosionado que el humano

If coding is solved, what now?: Measuring the sloppiness of code

Los LLM generan código formalmente correcto, pero introducen abstracciones innecesarias y duplicados. Medir esa 'sloppiness' es difícil porque requiere intuición humana. En Earendil, Sebastian explora métricas como verbosity y erosion, y descubre que el código de agentes duplica los valores humanos. En SlopCodeBench, incluso modelos de última generación logran 0% de tasa de éxito estricta, lo que debería alertar a quienes añaden miles de líneas al día.

Los agentes tampoco pueden lidiar realmente con el slop.
  1. dang

    Todos: por favor, no publiquen reacciones genéricas y reflejas a los títulos. Eso está cubierto por esta pauta, entre otras, en https://news.ycombinator.com/newsguidelines.html:

    "Por favor, no elijan lo más provocador de un artículo o publicación para quejarse en el hilo. Encuentren algo interesante a lo que responder en su lugar."

    He quitado la parte provocadora del título de arriba, pero por favor recuerden que queremos comentarios reflexivos, no reflejos, en los hilos de HN.

    https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor....

  2. dherman

    Realmente me alegra ver que la gente esté investigando enfoques cuantitativos para dar feedback a los agentes sobre la calidad del código. ¡Esta publicación parece un buen comienzo!

    Mi principal comentario para los autores sería que los problemas más importantes de descuido son propiedades globales, no locales. En mi experiencia, un agente, como un humano, tiene capacidad finita de atención, pero si se topa con descuido local que le estorba, puede arreglarlo según lo necesite. Los problemas de deuda técnica que importan suelen ser problemas globales que no son tan fáciles de arreglar: requieren análisis global y refactorización global.

    No sé la respuesta, pero creo que vamos a necesitar formas de medir propiedades arquitectónicas, como la separación de responsabilidades, una estratificación arquitectónica clara, interfaces bien definidas, etc.

  3. toddwprice

    Programar está resuelto, quizás, con un gasto ilimitado de tokens en un modelo de frontera. Queda por ver si eso será prohibitivamente caro para siempre. En mi empresa, maximizamos tokens mientras la situación era buena. Pero cuando tuvimos que cambiar al plan empresarial de Anthropic y empezar a pagar por token, la cosa se puso realmente fea. Ahora estamos retrocediendo a niveles de costo sensatos y descubriendo que, ¿adivinen qué?, el poder humano podría ser más rentable. La IA, por supuesto, es una herramienta inmensa para aprovechar, pero sigue siendo demasiado cara para crear bucles y dejarla correr. Esto cambiará con el tiempo, por supuesto, pero asumir que es un problema resuelto es una tontería. Quizás si resolvemos la fusión fría, sí. Hasta entonces, la evolución está ganando la guerra contra la entropía.

  4. justinmarsan

    Haber llegado a las mismas conclusiones que el autor me llevó a crear mi primer agente para hacer revisión de arquitectura, y así fue como aprendí sobre las métricas detrás de las buenas prácticas que había estado siguiendo durante años. LCOM, complejidad ciclomática, ese tipo de cosas...

    Es tan fácil enviar mucho código que debería ponerse más esfuerzo en asegurar que el código sea correcto, con bucles de retroalimentación auto-mejorables que involucren a los desarrolladores y herramientas dedicadas...

    Pero, de nuevo, hace un tiempo todo era sobre ingeniería de prompts, y ahora puedes expresar tu idea vagamente y obtener un resultado más o menos funcional, así que esto probablemente evolucionará rápido también...

  5. FiberBundle

    ¿Alguien sabe realmente si hay un límite a la complejidad que los LLM son capaces de manejar en una base de código? Es muy obvio que no escriben código adecuado para que la gente lo entienda (y va a empeorar cada vez más cuanto más se use RL para entrenar estos modelos), pero si no hay un punto en el que los LLM también tengan dificultades debido a la complejidad que introducen, entonces no estoy seguro de que realmente importe ya para una gran parte del software no crítico para la seguridad. Realmente espero que lo haya, porque dirigirlos es, siento, una de las últimas competencias a través de las cuales aún puedo aportar valor, pero ¿hay realmente evidencia de que estos modelos tengan más dificultades con código mal mantenido?

  6. drsopp

    Se invoca la ley de Goodhart aquí sin discusión. ¿Estamos seguros de que optimizar para el mínimo LOC que pase todas las pruebas necesarias produce código descuidado? Y: ¿qué es código descuidado de todos modos? Si pudiéramos definirlo, ¿podríamos arrojar la definición al contexto y decirle al LLM que lo evite?

  7. conqrr

    Programar no es solo el programa ejecutándose en memoria, también es el proceso de distribuir el modelo mental de comprensión entre el equipo.

    Si los humanos cada vez se mantienen más fuera de la programación, ¿entonces quién sostiene el modelo mental?

    Si la IA sostiene el modelo mental, por definición los prompts humanos pasarán por un canal con pérdida. Esto también es cierto sin IA. La calidad del software depende directamente de buenos desarrolladores que traduzcan del lenguaje de negocio/PM a decisiones técnicas.

    Entonces, ¿está resuelto programar ahora? Ya estaba resuelto hace décadas.

  8. glouwbug

    Una buena medida es la comunicación. Si hay un entendimiento común, entonces el origen no importa necesariamente.

Más de este día

2026-09-11