Benchmarking Opus 5 en SlopCodeBench
Los resultados de SlopCodeBench sugieren que el nuevo modelo Claude Opus 5 de Anthropic ofrece solo mejoras modestas frente a Opus 4.x en tareas de programación multietapa, al tiempo que a menudo genera código más complejo y “más desordenado”. Los comentaristas sostienen que los LLM actuales siguen teniendo dificultades con la mantenibilidad a largo plazo, el refactorizado y evitar abstracciones innecesarias, y que el diseño del harness y los prompts pueden ser tan importantes como el modelo subyacente. Muchos piden mejores benchmarks, baselines humanos y señales de RL que recompensen explícitamente la simplicidad y la salud del código, especialmente porque algunos desarrolladores dicen preferir modelos antiguos o Fable de Anthropic para trabajos complejos y sostenidos.
Reacción general ante Opus 5 frente a modelos anteriores
- Muchos dicen que Opus 5 se siente solo un poco mejor que Opus 4.8, no un salto “wow”.
- Algunos prefieren el comportamiento y el tono de 4.8; Opus 5 se describe como demasiado seguro de sí mismo, verboso y escolástico, generando “slop” y reseñas pedantes.
- Una minoría informa ganancias reales de productividad, especialmente al usar Opus 5 medium como sustituto más rápido y barato de 4.8 x-high, reservando Fable para las tareas más difíciles.
SlopCodeBench y la mantenibilidad del código
- SlopCodeBench es elogiado como un benchmark poco común que prueba el comportamiento longitudinal: múltiples añadidos de funciones y cómo evoluciona la calidad del código.
- Se señala la tasa de éxito estricta de Opus 5 de ~24% frente a ~17% de Opus 4.6; algunos lo ven como una mejora modesta pero real, otros como algo todavía inaceptablemente bajo.
- Preocupación clave: los modelos añaden muchas funciones y complejidad con el tiempo; el RL/los benchmarks actuales rara vez penalizan la complejidad, así que los modelos no aprenden a simplificar.
Harnesses, prompts y flujos de trabajo de agentes
- Varios sostienen que el “slop” suele ser un problema del harness/del system prompt: agentes con demasiada libertad y sin restricciones sobre dónde editar acumulan desorden.
- Las “skills” estáticas o los flujos de trabajo en plantilla a veces perjudican el rendimiento en SlopCodeBench, probablemente porque desperdician contexto y fuerzan flujos subóptimos en tareas greenfield.
- Otros informan éxito con:
- Restringir las ediciones a costuras estrechas.
- “Turnos de refactor” dedicados o pases periódicos de revisión de todo el codebase.
- Instrucciones explícitas que prefieren la simplicidad y el código DRY en los archivos de configuración del proyecto.
Comportamiento del modelo, degradación y benchmarking
- Algunos usuarios sienten que los modelos (incluido Fable) se degradan después del lanzamiento, posiblemente por cambios motivados por costes como la cuantización; otros citan rastreadores públicos que muestran una mejora mayormente monótona.
- Existe preocupación de que los laboratorios puedan tratar de forma especial las entradas similares a benchmarks, haciendo que los benchmarks públicos sean menos fiables.
- Los participantes piden suites de evaluación más robustas (incluidas métricas de mantenibilidad) y señalan que la mayoría de los equipos no tiene la experiencia para construirlas.
¿Realmente importa el “slop”?
- Un hilo pregunta si la fealdad/complejidad importa si los defectos se mantienen bajos y los clientes están contentos.
- Las respuestas lo vinculan directamente al coste de cambio a largo plazo y a la eficiencia de los agentes de IA: el código desordenado es más difícil de modificar tanto para humanos como para modelos.
- Al parecer, artículos recientes (mencionados pero no detallados) encuentran que el código “más limpio” mejora la navegación y la eficiencia del agente.