Surge: Opus con xhigh sumó 11,3 puntos, mientras que complementos como Superpowers aportaron como máximo 3

En los últimos meses, los feeds se han llenado de complementos para agentes de programación: skills, plugins y orquestas formadas por decenas de subagentes. Suena convincente, pero ¿ayuda de verdad? El equipo de Surge lo comprobó con un benchmark y obtuvo un resultado que no gustará a muchos: la mejora más eficaz resultó ser también la más aburrida.

Cómo se realizó la prueba

Ejecutaron Opus 5.5 en Claude Code con 100 tareas reales de ingeniería procedentes del benchmark sudo L7. Este no solo comprueba que “las pruebas hayan pasado”, sino también el criterio de ingeniería propio de un nivel staff: si el agente encontró la causa raíz, verificó escenarios relacionados y evitó romper funciones cercanas.

La comparación incluyó Claude Code sin modificaciones, Superpowers (más de 311K estrellas en GitHub), Compound Engineering (más de 25K estrellas) y los plugins integrados /goal y /code-review. Como referencia se utilizó Opus puro con medium.

Resultados

• Superpowers: +2,4 puntos con un coste aproximado de 1,1× respecto a la referencia.
• /goal + /code-review: +3,3 puntos con 1,8×.
• Compound Engineering: aproximadamente 8× el coste y una mejora estadísticamente insignificante.
• Opus con xhigh y sin ningún complemento: +11,3 puntos con 3,5×.

Donde más mejoró xhigh fue en verificación y exhaustividad (+14,9) y en perseverancia (+9,8). Es decir, el modelo no se volvió “más inteligente”; simplemente dejó de detenerse ante la primera solución plausible.

Un ejemplo del informe

Un editor de vídeo falla cuando no existe el primer clip. Con medium, el agente corrige el punto evidente, informa de que todo ha salido bien y obtiene 14 puntos de 100 por $0,12. Con xhigh, detecta que la corrección desvía la ejecución a un fallback donde también se presupone la existencia del clip, encuentra el segundo error y obtiene 100 puntos de 100 por $0,41. La diferencia de precio es mínima; la diferencia de calidad, enorme.

Un caso aún más ilustrativo fue la tarea de “añadir un enlace de Zoom y el código de acceso al correo de confirmación”. Una de las soluciones —los autores no indican cuál— cargó 37 skills adicionales y puso en marcha 17 agentes: cinco para revisar el plan, cinco para simplificarlo y siete para revisar el código. Ninguno detectó lo fundamental: el correo se envía antes del pago, de modo que quienes no hayan pagado también recibirán el código de acceso. Más agentes no equivalen a más atención si todos observan la misma tarea de la misma manera.

Qué hacer en la práctica

1. Antes de instalar otro framework, aumenta el nivel de effort. Es un solo ajuste, no una nueva dependencia.
2. Calcula el coste por tarea resuelta, no por ejecución. El costoso xhigh suele resultar más barato que varias iteraciones con correcciones.
3. Si utilizas skills, mide su aportación en tus propias tareas. Las estrellas de GitHub no son un indicador de calidad.
4. En áreas críticas, como pagos y control de acceso, no dependas de las revisiones de agentes. Una persona debe verificar la lógica de negocio.

Limitaciones

Se trata de un único benchmark, un solo modelo y un solo entorno de ejecución. El proveedor seleccionó las tareas, y las diferencias entre configuraciones en muestras pequeñas podrían ser ruido. Es posible que la orquestación funcione mejor con otros modelos o en proyectos largos y con muchos pasos. Además, xhigh cuesta 3,5 veces más y puede ser excesivo para cambios rutinarios.

Pero la dirección está clara: empieza por la palanca más sencilla. Si el modelo se equivoca porque trabaja con prisas, añadir agentes no resolverá el problema; solo te dará una factura mayor y una sensación de control.