En pocas palabras: Opus 5 encabezó SlopCodeBench con 24% de strict pass (4 de 17 checkpoints), el cuádruple de Opus 4.8 y Sonnet 5, que quedaron en 6% (1 de 17). Escribió 29.065 líneas de código, el 51% tests. Ningún modelo terminó limpio.
El benchmarking de Opus 5 en SlopCodeBench dejó un número que conviene mirar de cerca: Opus 5 logró un 24% de strict pass rate (4 de 17 checkpoints), contra un 6% de Opus 4.8 y de Sonnet 5 (1 de 17 cada uno). Ningún modelo terminó los tres problemas sin arrastrar defectos.
SlopCodeBench es un benchmark de generación de código que no te tira el problema completo de entrada, sino que lo va revelando en checkpoints que aparecen de a poco, para simular el mantenimiento real de un proyecto a lo largo del tiempo. Mide lo que llama “strict pass”: un checkpoint cuenta solo si los tests nuevos quedan verdes y, además, ninguno de los tests heredados se rompe. La evaluación de Opus 5 se publicó en el repositorio de HumanLayer.
En 30 segundos
- Opus 5 sacó 24% de strict pass (4 de 17 checkpoints), cuádruple que Opus 4.8 y Sonnet 5, que quedaron en 6% (1 de 17).
- Escribió 5 veces más código: 29.065 líneas contra unas 9.000 de los otros, y el 51% eran tests.
- Ningún modelo llegó al final limpio. Todos acumularon defectos en los checkpoints tardíos.
- Se probaron 3 problemas: circuit_eval (fácil, 8 checkpoints), database_migration (medio, 5) y dynamic_config_service_api (difícil, 4).
- Conclusión del autor: “cada dólar compró corrección, nadie compró suficiente”. Más compute rindió más aciertos, pero con retorno decreciente.
¿Por qué SlopCodeBench es más exigente que SWE-bench y otros benchmarks?
La diferencia clave es el tiempo. La mayoría de los benchmarks de código te dan el problema entero de una y miden si el modelo lo resuelve en un solo tiro. SlopCodeBench divide cada problema en checkpoints que se revelan uno tras otro, y en cada uno el modelo tiene que agregar funcionalidad sin romper lo que ya andaba. Eso captura algo que los tests de una sola pasada no ven: la degradación de calidad cuando el código crece.
Cualquiera que haya laburado en un proyecto de más de tres meses sabe de qué hablamos. El primer commit es prolijo. El problema empieza en el checkpoint 5, cuando tenés que tocar algo que escribiste hace dos semanas y no te acordás por qué estaba así.
SWE-bench y compañía son útiles, pero miden un instante. Acá el foco es otro: cómo se comporta un modelo a lo largo del ciclo de vida de un problema, con tests heredados que actúan de red de seguridad. Un fallo en el checkpoint 4 que no se arregla arrastra el 5, el 6 y el 7. Es una métrica dura, y por eso los números bajan tanto. Esto se conecta con lo que analizamos en aspectos de seguridad en sistemas IA.
¿Cuánto sacó Opus 5 en los 17 checkpoints de SlopCodeBench?
Opus 5 pasó 4 de 17 checkpoints en modo strict, un 24%. Opus 4.8 y Sonnet 5 pasaron 1 de 17 cada uno, un 6%. Los tres problemas evaluados fueron circuit_eval (fácil, 8 checkpoints), database_migration (medio, 5) y dynamic_config_service_api (difícil, 4).
Ojo con un detalle que ordena la lectura. Un 24% acá no significa que Opus 5 falle el 76% de las veces cuando lo usás para laburar. El benchmark es mucho más duro que un problema típico de tu día. Lo que mide es cuántas veces el modelo puede sumar una feature sin regresiones, algo que en la práctica corregís con una revisión de dos minutos. Que Opus 5 cuadruplique a sus antecesores igual dice bastante sobre la dirección de la mejora.
¿Por qué Opus 5 escribió 5 veces más código que los otros modelos?
Opus 5 generó 29.065 líneas contra unas 9.000 de Opus 4.8 y Sonnet 5. Pero el reparto importa más que el total: el 51% de esas líneas eran tests, contra un 11% en Opus 4.8 y un 24% en Sonnet 5. O sea, Opus 5 no solo escribió más, escribió mucho más código de verificación.
¿Es verbosidad al pedo o es prolijidad? Habría que ver caso por caso. Escribir tests de más no te resuelve el problema, pero tampoco te lo empeora, y en un benchmark que penaliza regresiones, tener red propia ayuda. Tema relacionado: cómo se compara con ChatGPT.
El dato de los “slop detectors” matiza el entusiasmo. En Opus 5, el 93% de las líneas activó algún detector de código sospechoso, contra un 98% en Opus 4.8 y un 89% en Sonnet 5. Traducido: escribir más tests no lo volvió más limpio que Sonnet en esa métrica puntual. Volumen y prolijidad no son la misma cosa.
| Métrica | Opus 5 | Opus 4.8 | Sonnet 5 |
|---|---|---|---|
| Strict pass rate | 24% (4/17) | 6% (1/17) | 6% (1/17) |
| Líneas generadas | 29.065 | ~9.000 | ~9.000 |
| % de líneas que son tests | 51% | 11% | 24% |
| % de líneas en slop detectors | 93% | 98% | 89% |
| Señal de complejidad | ~2.000 funciones, media baja | +70% complejidad ciclomática (peor función: 93) | Duplicación de 4,6% a 16,8% |
¿Cómo cambió la complejidad del código a lo largo de los checkpoints?
Los tres modelos aumentaron la complejidad a medida que avanzaban los checkpoints, pero por caminos distintos. Opus 5 mantuvo una complejidad media baja, aunque llegó a escribir cerca de 2.000 funciones (muchas funciones chicas). Opus 4.8 tomó el camino opuesto: aumentó un 70% su complejidad ciclomática y su peor función trepó a 93, un número que a cualquier revisor le hace saltar la alarma. Sonnet 5, por su lado, disparó la duplicación de código del 4,6% al 16,8%.
Acá hay un tradeoff clásico. Muchas funciones chicas son más fáciles de leer de a una, pero te llenan el proyecto de superficie. Pocas funciones grandes concentran la lógica, hasta que una llega a complejidad 93 y ya nadie la quiere tocar. No hay ganador obvio, solo formas distintas de acumular deuda.
¿Sirve Opus 5 para escribir código sin supervisión humana?
Para ciclos cortos con revisión humana, funciona bien. Para dejarlo suelto en modo “lights-off” sin nadie mirando, los datos sugieren cautela. En circuit_eval, Opus 5 pasó limpio los primeros tres checkpoints y recién empezó a acumular defectos en el 4 y el 5. Es el patrón esperable: arranca prolijo y se va ensuciando cuando el problema crece. En capacidades de razonamiento avanzado profundizamos sobre esto.
Y ahí está el riesgo de la automatización sin steering. Le pedís una feature, la agrega, anda; le pedís otra sobre la base anterior, la agrega, anda; a la quinta la base ya tiene tres decisiones raras que nadie revisó, el modelo construye encima de sus propios atajos y de golpe una regresión se cuela en un test heredado que ni mirabas. En el benchmark eso te cuesta el checkpoint. En producción te cuesta un incidente.
La recomendación práctica es directa. Usalo como copiloto rápido, revisá cada tanda, no lo dejes iterar solo sobre su propio output por horas. El 24% no es un veredicto sobre su utilidad diaria, es una señal sobre su mantenibilidad sin control.
¿Gastar más compute da mejor código?
Sí, pero con retorno decreciente. La frase con la que el autor cierra el análisis lo resume: “every dollar bought correctness, nobody bought enough of it” (cada dólar compró corrección, nadie compró suficiente). Opus 5 salió más caro que Sonnet, y también resolvió más checkpoints. Sonnet arrancó más barato, pero sobre el final los costos se emparejaron.
La lectura es que existe correlación entre inversión y corrección, sin punto de saturación visible en el rango probado. Más compute compró más aciertos. Nadie llegó a comprar los suficientes como para terminar los problemas sin defectos. Para equipos que corren estos modelos sobre su propia infraestructura, el mensaje es que el gasto extra no se tira, pero tampoco te garantiza cero errores.
Qué significa para equipos de desarrollo en Latinoamérica
Para un equipo chico o mediano de la región, el aprendizaje es concreto y barato de aplicar. Opus 5 es una mejora real sobre la generación anterior en tareas de código que se sostienen en el tiempo, y lo demuestra cuadruplicando el strict pass. Pero el flujo de trabajo tiene que incluir revisión humana en cada iteración, sobre todo si tu proyecto va a seguir creciendo. Ya lo cubrimos antes en competidores como Google Gemini.
Si venís pensando en armar un pipeline agéntico que escriba y despliegue solo, tomalo con pinzas. Los checkpoints tardíos son donde se paga la falta de control.
Errores comunes al leer los resultados de este benchmark
- Leer el 24% como tasa de falla real. No es que Opus 5 falle 3 de cada 4 tareas de tu día. SlopCodeBench es mucho más exigente que un problema típico; la métrica castiga cualquier regresión heredada.
- Confundir volumen con calidad. Que Opus 5 escriba 5 veces más líneas no lo vuelve mejor por sí solo. De hecho, activó slop detectors en el 93% de sus líneas, más que Sonnet 5.
- Mirar solo el primer checkpoint. En circuit_eval, Opus 5 pasó limpio los primeros tres y se ensució en el cuarto. La foto inicial engaña; el problema aparece cuando el código madura.
- Suponer que más plata resuelve todo. El compute extra compró corrección, sí, pero ningún modelo terminó sin defectos. No hay presupuesto que te salte la revisión humana.
Preguntas Frecuentes
¿Qué es SlopCodeBench?
SlopCodeBench es un benchmark de generación de código que divide cada problema en checkpoints revelados de forma progresiva, en vez de dar el enunciado completo de una. Mide “strict pass”: un checkpoint aprueba solo si los tests nuevos pasan y ningún test heredado se rompe. Sirve para evaluar mantenibilidad a lo largo del tiempo, no resolución en un solo tiro.
¿Cuánto sacó Opus 5 en SlopCodeBench?
Opus 5 alcanzó un 24% de strict pass rate, es decir 4 de 17 checkpoints. Cuadruplicó a Opus 4.8 y a Sonnet 5, que sacaron 6% cada uno (1 de 17). Aun así, ningún modelo completó los tres problemas evaluados sin acumular defectos.
¿Opus 5 es mejor que Sonnet 5 para escribir código?
En este benchmark, Opus 5 pasó más checkpoints en modo strict (24% contra 6%). Pero Sonnet 5 activó menos slop detectors (89% contra 93%) y salió más barato al inicio. Opus 5 conviene cuando la corrección sostenida importa más que el costo; Sonnet compite bien en tareas más cortas.
¿Se puede usar Opus 5 sin revisión humana?
No es recomendable dejarlo en modo automático sin supervisión. Los datos muestran que Opus 5 arranca limpio pero acumula defectos en los checkpoints tardíos, cuando el código crece. Para desarrollo real, funciona bien en ciclos cortos con revisión en cada iteración.
¿Este benchmark refleja el uso real de un desarrollador?
SlopCodeBench es más duro que el trabajo diario típico, así que sus porcentajes no se traducen directo a tu experiencia. Su valor es medir degradación a lo largo del tiempo, algo que otros benchmarks de una sola pasada no capturan. Es una señal de mantenibilidad, no una tasa de falla cotidiana.
Conclusión
El benchmarking de Opus 5 en SlopCodeBench confirma un salto real frente a la generación anterior: cuádruple strict pass rate y mucho más código de verificación. Pero también deja en claro que ningún modelo, ni el más caro, resolvió los problemas sin arrastrar defectos hacia los checkpoints finales. La mejora es genuina y el techo sigue lejos.
Qué hacer con esto. Si usás Opus 5, aprovechá su fortaleza en ciclos cortos y revisá cada tanda antes de construir encima. No lo dejes iterar solo sobre su propio output durante horas, porque ahí es donde el benchmark muestra que se acumula la deuda. La automatización sin control todavía no llegó, y los datos lo dicen sin vueltas.