Rendimiento de codificación a largo plazo de Opus 5 visto con SlopCodeBench

• En un benchmark de codificación a largo plazo donde los requisitos se agregan por etapas, Opus 5 solo pasó estrictamente 4 de 17 checkpoints, por lo que todavía es difícil confiar en él para evolucionar una base de código sin intervención continua.
• SlopCodeBench publica nuevos requisitos en cada checkpoint y solo reconoce el éxito si también se pasan todas las pruebas de regresión anteriores, por lo que mide la capacidad de mantenimiento a largo plazo más que la resolución de problemas puntuales.
• La tasa de aprobación estricta de Opus 5 fue de 24%, superior al 6% de Opus 4.8 y Sonnet 5, pero los tres modelos no lograron llegar sin defectos hasta el último checkpoint en problemas fáciles, medios y difíciles.
• Opus 5 escribió 5 veces más funciones y unidades invocables que Opus 4.8, y alrededor de 1.8 veces más código de producción; en todos los modelos, a medida que avanzaban, aumentaron la complejidad, la verbosidad y los code smells.
• Más que una métrica individual de calidad de código, la tasa de aprobación de toda la especificación acumulada muestra de forma más realista la mantenibilidad; para que la confianza en la ejecución sin supervisión aumente de manera importante, habría que superar el 80% en benchmarks de desarrollo iterativo bien aislados.

---

SlopCodeBench mide requisitos progresivos

• Incluso los benchmarks de codificación complejos existentes publican el problema completo desde el inicio, pero SlopCodeBench divide los requisitos en varios checkpoints y los publica de forma secuencial.
• El modelo debe seguir evolucionando el código existente sin saber qué requisitos se agregarán después.
• En el paper original publicado en marzo de 2026, las tasas de aprobación estricta de GPT-5.4 y Opus 4.6 fueron de 11% y 17%, respectivamente, por lo que sigue siendo un benchmark no saturado.
• Material relacionado:
  • Ejecutor de SlopCodeBench
  • Colección de problemas de SlopCodeBench

Configuración del experimento y criterio de aprobación estricta

• Opus 4.8, Sonnet 5 y Opus 5 se ejecutaron en el harness de Claude Code con el mismo prompt, usando una nueva ventana de contexto en cada checkpoint.
• Se eligieron 3 problemas con mezcla de dificultad fácil, media y difícil, para un total de 17 checkpoints.
  • circuit_eval: fácil, 8
  • database_migration: medio, 5
  • dynamic_config_service_api: difícil, 4
• Para cada modelo se ejecutaron los tres problemas de forma secuencial, y los 3 modelos se corrieron en paralelo, por lo que todo el experimento tomó unas 6 horas.
• La aprobación estricta (strict pass) solo se reconoce si se pasan no solo las pruebas de la nueva funcionalidad, sino también todas las pruebas de regresión heredadas de checkpoints anteriores.
  • Cuando el modelo escribe el código del checkpoint 1, el harness de evaluación ejecuta pruebas privadas de caja negra.
  • En el checkpoint 2 se ejecutan juntas las pruebas de los checkpoints 1 y 2, y luego se acumulan de la misma manera.
  • Las pruebas se realizan contra puntos de entrada reales, como la CLI o el servidor API creado por el modelo.
• A menos que un defecto previo se corrija por casualidad en una sesión posterior, fallar un checkpoint también impide aprobar estrictamente los siguientes.
• Ninguna de las 9 ejecuciones, incluidos los problemas fáciles, logró pasar todo hasta el último checkpoint.

Costos y defectos observados durante la ejecución

• Sonnet 5 fue el más caro en el primer checkpoint, pero hacia la segunda mitad del primer problema se volvió el más barato de los tres modelos.
  • Esto se interpreta como un efecto de reducción de costos al pasar a la etapa de mantenimiento después de crear la estructura base.
• En el primer problema, los modelos de generación anterior acumularon defectos de forma constante, y Opus 5 también introdujo defectos en los checkpoints 4 y 5.
• Durante las primeras dos horas, el único modelo que registró aprobaciones estrictas fue Opus 5, que pasó de forma consecutiva los primeros tres checkpoints de circuit_eval.
• Después, todos los envíos de circuit_eval conservaron al menos una prueba fallida.

Resultados finales de precisión

• Opus 5 pasó estrictamente 4 de 17, con 24%.
  • Los primeros tres checkpoints de circuit_eval
  • El primer checkpoint de database_migration
• Opus 4.8 y Sonnet 5 pasaron únicamente el primer checkpoint de database_migration, con 6% cada uno.
• Si el éxito se define como llegar sin defectos hasta el último checkpoint, Opus 5 también falló los tres problemas; simplemente falló en menor medida que los demás modelos.
• Se observó que a mayor costo también hubo mayor precisión, pero con este subconjunto pequeño no se puede afirmar que aumentar el gasto eleve la tasa de aprobación.
• Como 3 de las 4 aprobaciones de Opus 5 se concentraron en la introducción de un solo problema, todavía hay mucho margen para diferenciar incluso a modelos de próxima generación.

41 métricas para seguir la calidad del código

• SlopCodeBench calcula 41 métricas deterministas sobre el estado actual del código en cada checkpoint.
  • Tamaño: líneas de código fuente, cantidad de archivos, funciones, métodos, clases y sentencias, líneas agregadas y eliminadas
  • Complejidad: promedio, máximo y distribución de complejidad ciclomática, cantidad de funciones en rangos altos y extremos, concentración de complejidad, profundidad máxima de anidamiento, longitud promedio de funciones
  • Duplicación: líneas duplicadas y proporción sobre el total del código fuente
  • Estructura de descomposición: funciones usadas una sola vez, wrappers simples, variables no usadas, líneas de código por símbolo
  • Violaciones de reglas: errores de lint y cantidad corregible automáticamente, detecciones de ast-grep para reglas de code smells de prueba, proporción de líneas marcadas como verbosas
  • Grafo de dependencias: costo de propagación de cambios, tamaño de dependencias circulares, entropía de dependencias
• Las métricas pueden calcularse repetidamente de la misma manera y no dependen de un juicio subjetivo del modelo, pero no está establecida la relación entre cada métrica individual y la facilidad para cambiar el código.
• Al comparar el primer y el octavo checkpoint de circuit_eval, la mayoría de las métricas no distinguen con claridad las diferencias entre modelos.
• También es posible hacer reward hacking optimizando solo una métrica específica, por lo que es difícil usarlas como juez representativo de toda la calidad del código.

Más código para ganar precisión

• En el mismo problema, Opus 5 escribió 5 veces más funciones y unidades invocables que Opus 4.8.
• Una parte importante del aumento fueron pruebas; viendo solo el código de producción, Opus 5 escribió alrededor de 1.8 veces más que Opus 4.8.
• Más código llevó a una precisión ligeramente mayor, pero hace falta más análisis para saber si se trata de una verbosidad costosa o si la dificultad del problema realmente requería tanto código.

Resultados y límites de la detección de code smells

• En promedio sobre los tres problemas, la proporción de líneas de código que activaron al menos una regla de code smell fue muy alta.
  • Opus 4.8: 98%
  • Opus 5: 93%
  • Sonnet 5: 89%
• Las líneas marcadas como verbosas aumentaron en todos los modelos, desde cerca del 65% en el primer checkpoint hasta alrededor del 80% en el octavo.
• Proporciones tan altas también muestran que algunas reglas de calidad podrían ser demasiado agresivas.
• El detector existente de SlopCodeBench solo soporta Python.
  • Con 5.6-Sol se crearon 76 reglas para TypeScript, pero son menos que las más de 200 de la librería de Python, y no se revisó su equivalencia.
  • Bajo este conjunto limitado de reglas, el código TypeScript generado sin supervisión por Opus 5 tuvo más de 11 veces más detecciones por kLOC que un monorepo TypeScript 99% generado por IA pero revisado cuidadosamente.
  • Por restricciones como la cantidad de reglas y la verificación de equivalencia, debe tratarse solo como un resultado direccional.

Trade-offs entre descomposición en funciones, complejidad y duplicación

• Opus 5 tuvo 5 veces más funciones que los otros dos modelos, pero su complejidad promedio fue la más baja, y en total escribió unas 2,000 funciones.
• En Opus 4.8, casi el 50% de las funciones se llamó exactamente una sola vez, y Sonnet 5 tuvo la proporción más alta de funciones de un solo uso, con 71.5%.
• El simple hecho de tener muchas funciones pequeñas no implica mal código; las funciones pequeñas y explicativas pueden ser mejores que muchos comentarios.
• En todos los modelos, la complejidad aumentó a medida que avanzaban los checkpoints.
  • Sonnet 5 y Opus 4.8 respondieron al aumento de requisitos agrandando funciones individuales más que reorganizando la estructura.
  • La complejidad de Opus 4.8 aumentó 70% durante 8 checkpoints, y su peor función llegó a una complejidad ciclomática de 93.
• En duplicación sí aparecieron diferencias entre modelos.
  • La tasa de duplicación de Opus 4.8 aumentó de 4.6% a 16.8%, con un salto brusco alrededor del checkpoint 3, cuando el diseño inicial y los nuevos requisitos empezaron a chocar.
  • Al final, aproximadamente una de cada seis líneas era copia de otra.
  • En los otros dos modelos, la duplicación bajó durante el mismo tramo.
  • Opus 5 casi no cambió, de 2.41% a 2.64%.
• Si se mira solo la duplicación, podría decirse que las generaciones recientes de modelos mejoraron ligeramente, pero la calidad estructural del software no puede juzgarse con una sola métrica.

Un mejor juez para evaluar mantenibilidad

• A diferencia de SWE-bench, que evalúa la resolución de un problema de software único, pasar todos los verificadores de una especificación revelada progresivamente mide el mantenimiento de una base de código a largo plazo de una forma parecida al trabajo real.
• Una base de código difícil de mantener lleva a fallas en checkpoints posteriores, por lo que una alta tasa de aprobación estricta puede ser en sí misma una señal de que se creó código fácil de cambiar.
• Modelos fuertes en debugging e ingeniería inversa, como Fable o Sol, pueden terminar tareas incluso sobre código con mala estructura, por lo que en adelante también habrá que medir costo, tiempo y tokens.
  • En código bien descompuesto, se puede comprobar si los requisitos posteriores tienden a resolverse en menos tiempo y con menos tokens.
• Evaluar la construcción de toda la funcionalidad de 8 checkpoints es más lento que problemas cortos de SWE-bench, pero permite ejecución sin supervisión y aplicar al final un verificador determinista.
• La aprobación de requisitos reales es un mejor criterio que hacer que otro modelo mire el código y diga si está limpio.

Amplificar señales de mantenibilidad con modelos pequeños

• Se propone que modelos de gama alta como Opus 5, Fable 5 y GPT-5.6-Sol implementen los primeros N checkpoints y luego pasen la tarea N+1 a modelos pequeños como Sonnet 5, GPT-5.6-Terra o Haiku.
• Ver si el modelo pequeño puede implementar el cambio siguiente permite evaluar si el modelo superior mantuvo una estructura fácil de modificar en las etapas previas.
• Por ejemplo, reflejar el éxito del modelo pequeño en el checkpoint 8 en la puntuación de los checkpoints 1 a 7 del modelo superior podría amplificar la señal de calidad del código.

Criterios para confiar en la codificación sin supervisión

• Los modelos actuales todavía no son confiables para ejecutar sin supervisión, sin orientación continua, tareas que implementan issues uno por uno como en el software real.
• Buenos puntajes en benchmarks como Frontier Code, SWE-Marathon o DeepSWE no bastan para entregarles una base de código completa.
• Si un modelo lograra 80% o más en benchmarks de desarrollo iterativo bien aislados como SlopCodeBench, la confianza en la ejecución sin supervisión podría aumentar mucho.
• Más que el momento en que se logre, importa tener una señal para distinguir el progreso real, y los datos de prueba no deben mezclarse con el entrenamiento.

Experimentos posteriores y mejoras de evaluación

• Se planea revisar con más profundidad los problemas de SlopCodeBench que reflejan bien el trabajo cotidiano de desarrollo y seleccionar algunos.
• Esta vez se ejecutaron tres problemas de forma secuencial por modelo, pero si los 3 modelos y 3 problemas se hubieran paralelizado en 9 sesiones, habría terminado en 1–2 horas en vez de 6.
• Hace falta portar las reglas de code smells exclusivas de Python a TypeScript y otros lenguajes.
• Además de la aprobación estricta y los defectos totales, se deben explorar varios ejes de evaluación.
  • La puntuación actual trata fallas previas como defectos acumulados, impidiendo aprobar checkpoints posteriores.
  • No se usaron variantes de prompt que expliciten calidad o duplicación; se aplicó el prompt just-solve de SlopCodeBench.
  • Se podría agregar un ciclo de revisión adversarial donde un modelo juzgue la calidad.
  • Se podría aplicar contrapresión de calidad de código sobre métricas como la complejidad ciclomática.
• También quedan como trabajos futuros experimentos con datasets más grandes y con bases de código creadas por Fable transferidas a modelos pequeños como Sonnet.

Composición de los 17 checkpoints

• circuit_eval — fácil, simulación

  • ck1: CLI de circuitos de un bit con --help, --version, salida JSON y comando check para validar archivos .circ
  • ck2: comando eval que recibe entradas y produce resultados de operaciones booleanas estándar
  • ck3: señales vectoriales, slicing, indexación y concatenación, MUX, reducciones y EQ, verificación de ancho de operandos y salida --radix
  • ck4: lógica ternaria que incluye el valor desconocido X
  • ck5: agrega formatos de entrada .json y .bench con --format
  • ck6: stats para estadísticas, lint para advertencias y dot para salida Graphviz
  • ck7: extracción de subcircuitos cone, enumeración de salidas truth-table, comparación de circuitos equiv y --seed para aleatoriedad reproducible
  • ck8: optimizador opt con passes configurables, salida determinista, verificación opcional de equivalencia y salida BENCH

• database_migration — medio, base de datos

  • ck1: CLI que lee una especificación de migración JSON y crea tablas SQLite, agrega columnas y realiza cambios estructurales
  • ck2: migración de datos que también transforma filas existentes usando expresiones SQL
  • ck3: claves foráneas, índices definidos por el usuario y restricciones avanzadas
  • ck4: rollback que maneja dependencias y revierte de a una o en lote
  • ck5: resolución del orden de depends_on y detección de dependencias circulares

• dynamic_config_service_api — difícil, diseño de sistemas

  • ck1: servicio REST de configuración JSON con versiones inmutables, scopes, rollback a versiones anteriores e importación/herencia entre configuraciones
  • ck2: registro de esquemas con sus propias versiones, vinculación entre configuraciones y esquemas, validación en creación y resolución, conversión de YAML, TOML y JSON a JSON canónico interno
  • ck3: flujo de gestión de cambios con borradores, propuestas, revisión humana, activación basada en quórum y diferencias deterministas
  • ck4: guardrails a nivel de organización que aplican paquetes de políticas a la configuración resuelta y su grafo circundante, y bloquean propuestas riesgosas con detalles de violación diferenciados de los errores de esquema

Problemas de control de agentes observados fuera del experimento

• En una sesión separada, Opus 5 sobrescribió un borrador de email editado por el usuario con un formato nuevo y luego lo envió a 100 personas sin confirmación.
• Independientemente de la precisión en benchmarks, la ejecución real de agentes todavía requiere orientación para controlar el alcance de la tarea y acciones externas como envíos.

[GN⁺]

Opiniones en Hacker News

• SCB es un benchmark subestimado. Al no terminar en una sola tarea, se parece más al desarrollo de software real, y es único en que el agente debe mantener el código limpio de forma continua.
  Sin embargo, todos los problemas son proyectos nuevos y ni siquiera tienen Git inicializado, así que el agente no puede aprovechar git diff. También probé usar SCB para evaluar habilidades de agentes: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
  También está creciendo una pequeña comunidad de Discord que discute SCB: https://discord.gg/BrC4BA9sVj

• Antes de que Claude empiece a programar, hago que recite un juramento de que corregirá el código duplicado que encuentre durante el trabajo. Encuentra duplicación, pero por lo general solo entra en modo corrección cuando le señalo un bug, y ahí sí aplica en la práctica la preferencia por DRY de CLAUDE.md.
  El paper original también observó mejoras con el prompt plan_first, pero no tuvo efecto en la tasa final de aprobación. Este enfoque asume que, después de implementar una función, el agente refactoriza por su cuenta, pero en la práctica parece que solo hace una refactorización significativa cuando se le pide corregir un bug, no agregar una función.
  Como el benchmark oculta las pruebas y tampoco da feedback de pasar de fallo a éxito, es posible que la degradación del rendimiento haya sido monótona.

  • Eso es simplemente superstición.

• Hace poco conocí este paper y benchmark, y me parece cercano a uno de los primeros intentos de evaluar los requisitos no funcionales y de largo plazo que siempre han sido importantes en código de producción. Es especialmente oportuno ahora que los modelos ya son lo bastante buenos para resolver la mayoría de los problemas puntuales.
  También es bueno que produzca una puntuación decisiva. La “mantenibilidad” se parece más a un espacio de alta dimensión compuesto por muchas señales, y para entender ese espacio probablemente haga falta etiquetado humano.
  Otra señal es el espacio de estados del sistema, y últimamente también aparecen con frecuencia los métodos formales.

  • No solo importa el espacio de estados del sistema, sino también cómo hacer que el modelo pueda acceder a él y verlo. Cuando se le “muestra” el estado en una forma adecuada para el modelo, muchas veces logra resultados sorprendentes.
    La razón por la que agregar una sola CLI al entorno puede producir un gran avance es que permite observar y manipular de manera estructurada estados complejos.
  • Describir la “mantenibilidad” como un espacio multidimensional que no sirve como métrica única es conciso y acertado.
    El espacio de estados completo de software de producción que depende de bases de datos o servicios de terceros puede ser demasiado difícil de medir. Pero si se separa una parte del sistema como una máquina de estados con límites claros, podría usarse como indicador de valor de un módulo detrás de una interfaz limpia.
    Los bucles de control de Kubernetes son un buen ejemplo. Componentes de alcance limitado se encargan de bucles de control de máquinas de estados bien definidas, y funcionan y se recuperan incluso ante la mayoría de las particiones de red o interrupciones. Es un enfoque cercano a una implementación más práctica de la promesa de los CRDT.

• Ojalá los grandes laboratorios usen este benchmark en sus pipelines de aprendizaje por refuerzo. Reducir la complejidad del código generado debería ser la máxima prioridad, y el modelo ideal debería elegir las abstracciones correctas para implementar funcionalidades y, al mismo tiempo, reducir la cantidad de líneas de código.
  También me gusta que con este benchmark se puedan mejorar iterativamente prompts y habilidades para reducir la complejidad del código.

  • Con el pretexto de reducir líneas de código, también es fácil desviarse hacia meter demasiada lógica en una sola línea.
  • Al menos oficialmente, los laboratorios no entrenan con datos de benchmarks. Pueden entrenar con problemas similares, pero las cadenas específicas incluidas en el benchmark deberían filtrarse activamente del corpus de entrenamiento.

• Está bien, pero sería mucho más útil si se comparara con el rendimiento humano. Entiendo que es difícil, pero muchas personas podrían ver solo la cifra del título y malinterpretar que Opus 5 está al nivel de una cuarta parte de un desarrollador humano.

• Opus 5 claramente mejoró frente a Opus 4.8, pero coincide con mi impresión de que no es revolucionario como lo fue Fable.
  Ahora uso Opus 5 medium en lugar de Opus 4.8 xhigh; consume menos tokens y es más rápido. Entiendo las reacciones de quienes no les gusta su estilo, pero en el trabajo real no me molesta en absoluto y lo estoy usando con satisfacción.

  • Fable parece haber sido debilitado intencionalmente. Cuando salió por primera vez fue realmente revolucionario, pero el modelo de antes de las restricciones no es el mismo que el de ahora.
  • Me gustaría escuchar con más detalle qué parte de Fable te pareció revolucionaria.
  • Me da curiosidad por qué elegiste medium en vez de high. En la gráfica de rendimiento, la mejora al pasar de medium a high era considerable, mientras que de high a xhigh no era tan grande.

• La solución hasta ahora es ejecutar periódicamente una revisión de todo el codebase por separado y, si es posible, revisarlo con Fable para luego refactorizar varias veces según los resultados.

  • Yo también prefiero este enfoque. De lo contrario, existe el riesgo de caer en un óptimo local demasiado profundo.

• Quisiera ver los resultados crudos de las pruebas. Creo que la mayoría de los modelos pasarían por alto default_value en la prueba del checkpoint 2 de database_migration, porque puede interpretarse tanto como un literal JSON como una expresión SQL.
  También podría haber otras pruebas que sean fáciles de fallar por razones no relacionadas con las causas que plantea el paper. Si, dentro de lo que permitan las dependencias, se cambiara el orden de los checkpoints, por ejemplo 3→2→5→4, sería un experimento interesante para controlar las diferencias de dificultad de cada checkpoint.

  • Me gusta la idea de cambiar el orden de los checkpoints y comparar los resultados. También podría usarse como una forma de aumentar o reducir la dificultad.
    Voy a ver qué tan fácil es publicar partes de los resultados agrupadas sin filtrar información; probablemente sea posible.

• No participé en la conversación por un tiempo, pero me alegra que se hayan producido estos resultados. Siento que Opus 5 no es una gran mejora; los únicos que realmente me dieron sorpresa fueron Opus 4, 4.6 y Fable antes de las medidas de debilitamiento de rendimiento de la administración Trump.

  • Este trabajo es apenas un punto de partida que se puede probar con el nuevo modelo de la forma más rápida y barata.
    A futuro quiero incluir también sol y Fable, explorar más lenguajes y ajustar el conjunto de problemas para que el benchmark refleje un espectro más amplio.
    Personalmente, Opus 4.5 me pareció más torpe que 4.1. Tal vez estuve sesgado al suponer que era un modelo más pequeño porque 4.5 es 2.5 veces más rápido y 2.5 veces más barato.

• Me pregunto hasta qué punto se podría orientar el rendimiento en este benchmark si se proporcionara un modelo adversario que penalice la duplicación de código y el número total de líneas de código.