Senior SWE-Bench: benchmark open source para evaluar agentes al nivel de ingenieros senior

• Senior SWE-Bench es un benchmark que busca evaluar a los agentes de código no con tareas junior excesivamente ordenadas, sino de una forma más cercana al desarrollo de funciones, corrección de bugs y problemas de rendimiento que normalmente asume un ingeniero senior
• Las tareas de funcionalidad usan instrucciones realistas que se leen como mensajes en lenguaje natural, y aumentan la confiabilidad de la evaluación con un agente de validación que crea pruebas de comportamiento según la solución enviada
• Las tareas de bugs se toman de PR que parten de reportes de usuarios y exigen investigación en tiempo de ejecución como levantar servicios, revisar logs, usar datos de profiling y seguir pasos de reproducción
• La puntuación evalúa un tasteful solve combinando consistencia en tiempo de ejecución con métricas de calidad basadas en las prácticas del codebase, y también puede validar prácticas importantes aunque no estén mencionadas en las instrucciones
• Incluso Claude Opus 4.8, el mejor modelo del leaderboard, apenas logra pass@1 de 24.0% con la configuración Mini-SWE-Agent max, lo que muestra que incluso los modelos punteros fallan en más del 75% de los casos al resolver problemas con la consistencia y el criterio esperados de un senior

---

Diseño de tareas más cercano a PR reales

• Senior SWE-Bench es un benchmark que busca reducir la brecha entre el uso real de los agentes de código como si fueran ingenieros senior y una evaluación que todavía suele parecerse a tareas para juniors
• Las tareas se toman de PR de varios repositorios, desde librerías hasta aplicaciones con múltiples servicios, y se enfocan en PR creados por ingenieros que escribieron cientos de commits en cada repositorio
• Los tipos principales de tareas se dividen en dos ramas
  • PR de funcionalidad con múltiples pasos y que abarcan varios stacks
  • PR de bugs y rendimiento que requirieron una investigación importante en tiempo de ejecución
• Hay 50 tareas públicas y otras 50 privadas
• Algunos repositorios incluidos son los siguientes
  • posthog 8
  • electric 6
  • gitea 6
  • better-auth 4
  • harbor 4
  • además de otros 7 repositorios

Tareas de funcionalidad: instrucciones más cercanas al lenguaje natural

• Las tareas de funcionalidad usan instrucciones realistas que se leen como mensajes en lenguaje natural, en lugar de requisitos excesivamente desglosados
• Para evaluar este tipo de tareas de forma estable, introducen un agente de validación (validation agent)
  • usa recetas diseñadas por expertos
  • escribe pruebas de comportamiento de acuerdo con la solución enviada
• Las instrucciones reflejan una comunicación natural con agentes, y la longitud mediana es de 31% de la de SWE-Bench Pro

Tareas de bugs: de reportes de usuarios a investigación en runtime

• Las tareas de bugs reflejan reportes de usuarios complejos, y exigen más investigación de causa raíz y reproducción que una simple corrección de código
• Las tareas pueden incluir trabajos como los siguientes
  • iniciar servicios
  • depurar problemas sutiles en runtime
  • revisar logs
  • usar datos de profiling
  • seguir pasos de reproducción
• Su origen son PR cuya resolución requirió una investigación considerable en tiempo de ejecución

Criterios de evaluación: medir consistencia y taste al mismo tiempo

• Senior SWE-Bench califica el tasteful solve combinando pruebas de consistencia en runtime con varias métricas de calidad
• Las métricas de calidad se basan en prácticas observadas del codebase
• Los verificadores y el agente de validación pueden probar prácticas importantes del codebase aunque no estén escritas en las instrucciones
• La condición de solve en el leaderboard incluye los siguientes puntos
  • Verifiers pass
  • Validation pass
  • Rubric > 0.5
  • Bloat < 2×
  • Practice > 2/5
  • Rel. taste > 2/5

Leaderboard: incluso el mejor modelo tiene un pass@1 bajo

• El leaderboard muestra los resultados según Tasteful solve rate(pass@1)
• Los principales resultados son los siguientes
  • Claude Opus 4.8, Mini-SWE-Agent max: 24.0%
  • Claude Sonnet 5, Mini-SWE-Agent max: 19.4%
  • GPT-5.5, Mini-SWE-Agent xhigh: 16.0%
  • Claude Opus 4.7, Mini-SWE-Agent max: 14.1%
  • GPT-5.4, Mini-SWE-Agent xhigh: 14.0%
  • GLM-5.2, Mini-SWE-Agent max: 12.5%
  • Kimi K2.6, Mini-SWE-Agent default: 8.2%
  • Claude Sonnet 4.6, Mini-SWE-Agent high: 8.2%
  • Gemini 3.1 Pro, Mini-SWE-Agent high: 6.1%
  • Gemini 3.5 Flash, Mini-SWE-Agent medium: 3.0%
• Incluso los modelos de frontera más fuertes no logran completar más del 75% de las tareas que exigen la consistencia y el criterio esperados de un ingeniero senior

Alcance de las tareas y características del benchmark

• Los tipos de tarea se indican como feature, bug, perf y migrat
• Los stacks incluyen Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust, TS FE y otros
• Las tareas de funcionalidad pueden abarcar varios servicios y tocan en promedio 11 archivos por tarea
• Están diseñadas para exigir flujos de trabajo largos, por lo que incluso los agentes más fuertes necesitan cientos de pasos
• El SLOC y la cantidad de archivos de las soluciones de referencia se miden de la misma forma en los tres benchmarks
• La longitud de las instrucciones excluye el boilerplate del harness
• El número de tokens y de pasos de otros benchmarks se basa en las métricas reportadas por cada uno

[GN⁺]

Opiniones de Hacker News

• Por lo que vi en Twitter, en una clase de machine learning de Tsinghua University hubo un examen en el que les pidieron a los estudiantes crear cuestionarios en los que fallara la mayor cantidad posible de LLM.
  Me pregunto qué tal sería crear un benchmark de este tipo y asignarle puntajes ELO. Los modelos se enfrentarían entre sí proponiendo preguntas, bugs o implementaciones incompletas, y el rival tendría que responder, corregir o completar.

  • A esto se le podría llamar red generativa antagónica (GAN) :)
    https://en.wikipedia.org/wiki/Generative_adversarial_network
  • El problema es cómo evitar estrategias degeneradas. Por ejemplo, si das un hash SHA256 y pides adivinar la entrada original, es demasiado fácil crear un problema imposible.
    En una clase se podría poner la regla de que al menos un LLM debe poder responder, pero no sé cómo resolverlo en un duelo uno contra uno.
  • Creo que eso no fue en Tsinghua, sino en Fudan.

• Me pregunto cómo mantendrá este benchmark su relevancia con el paso del tiempo.
  Si el benchmark consiste en implementar funcionalidades de proyectos open source, es posible que los LLM ya tengan esos cambios en sus datos de entrenamiento y puedan dar una respuesta igual o ligeramente modificada.
  Por el contrario, si solo se incluyen en el benchmark cambios de código posteriores al corte de conocimiento del modelo, los problemas de los momentos T y T+1 serán distintos, reduciendo la comparabilidad a lo largo del tiempo.

• Si fuera Staff SWE Bench, creo que el LLM empezaría por cuestionar si realmente debería hacer eso, pondría en duda todo el proyecto y se negaría a fusionar el código, aunque aceptaría encantado borrarlo.

  • Suena a broma, pero en la práctica creo que negarse es una parte central del trabajo. No es simplemente decir “no, vete”, sino dar un paso atrás, pedir la visión general y evaluar si toda la organización realmente necesita ese proyecto a largo plazo y si puede sostenerlo; eso es casi el mínimo antes de empezar.
    Creo que un LLM también podría hacerlo bien, quizá incluso mejor que nosotros, pero tendría que entrenarse específicamente para eso. El problema es que no se me ocurre de dónde sacar esos datos de entrenamiento.
  • La versión Principal sería parecida, pero además diría que el único enfoque permitido es la forma en que se hacía en su empresa anterior.

• Esto explica por qué siempre he sentido que Opus 4.8 está muy por delante de GPT 5.5. Es realmente bueno recibiendo requisitos incompletos y rellenando los huecos de una forma razonable para el proyecto.

  • Para empezar, no entiendo por qué dar requisitos incompletos. Ambos modelos son buenos analizando supuestos y casos límite y haciendo preguntas de aclaración, pero parece que solo lo hacen cuando se les pide explícitamente, por ejemplo usando técnicas como “brainstorming”.
    Creo que ninguno de los dos métodos de evaluación incentiva lo suficiente a los modelos a cuestionar todos los supuestos y hacer preguntas. Quizá sea porque a los usuarios les puede molestar, pero creo que esa etapa es casi indispensable.
    Toda la familia GPT-5 fue muy meticulosa, lo que me resultó útil para revisiones de código y matemáticas. Es importante para mi trabajo, pero parece estorbar en el código “estético”; por ejemplo, tiende a defenderse incluso contra casos límite muy poco probables.
    También parece haber un compromiso entre flexibilidad y seguimiento de instrucciones. En mi experiencia, Opus a veces ignora instrucciones pero rellena mejor los huecos, mientras que GPT-5.5 sigue mejor las instrucciones, pero por eso mismo parece más rígido.
  • El mejor benchmark es el benchmark que haces tú mismo.
    En mi experiencia, Opus no estuvo abrumadoramente por delante ni fue claramente mejor. En todo caso, GPT 5.5 tiene Instant, Medium, High, Extra High y Pro; en la tabla parece que lo comparan con Extra High, así que me pregunto si no deberían compararlo con Pro.
  • No sé si vivo dentro de una burbuja rara, pero para mí GPT 5.5 es mucho mejor que Opus 4.8. Me da curiosidad cómo lo evalúan y qué tipo de tareas hacen.
    Hay tareas específicas en las que Opus es mejor, como desarrollo frontend y diseño, pero fuera de eso 5.5 simplemente lo supera por mucho.
  • Puede ser mejor para los vibe coders, que siempre especifican menos. Pero la cuestión es a partir de qué punto el modelo decide que “faltan requisitos” y termina implementando algo que va más allá de una especificación que en realidad sí era suficiente.
  • Yo observé lo mismo. Opus 4.8 se sintió mucho más maduro, y hacía contrapreguntas o incluso se oponía cuando una solicitud le generaba dudas. En cambio, GPT 5.5 acepta con gusto y hace lo que se le pide, pero muchas veces hay que insistirle varias veces.
    4.8 también necesita más de un prompt a veces, pero la calidad de salida es mucho mayor y aporta más insights.
    Eso sí, Fable 5 es otra cosa.

• La mejor tasa de resolución actual es 24% con Opus 4.8; ¿qué puntaje debería obtener un humano competente?

  • Probablemente más que eso, porque un humano también podría usar lo mismo que usa el mejor modelo.
    Por otro lado, me pregunto si el modelo obtendría una puntuación más alta si pudiera dirigir humanos a voluntad.
  • Si asumimos que todos estos problemas ya fueron resueltos, creo que sería 100%. Claro que no necesariamente los resolvió todos la misma persona, pero mientras el modelo debe ser bueno en muchos codebases distintos, un humano puede especializarse y aprender un producto.
    Creo que compararlo con una persona acostumbrada a trabajar en el producto es justo.
    Me interesa más ver cómo le va a Fable.

• El valor de un rol senior está en aplicar soluciones y estrategias conocidas a problemas nuevos. No sé si un benchmark que nunca cambia puede seguir siendo un desafío nuevo por mucho tiempo.
  Un buen benchmark debería usar todo TRIZ para generar primero una enorme masa de problemas y luego ver si la AI infiere la solución óptima.

• Me alegra ver un nuevo benchmark público de Snorkel. Están haciendo cosas bastante sofisticadas por allá.

• Es interesante que Sonnet 5 esté bastante cerca de Opus 4.8.

• Si este enfoque funciona, ¿no significa que también se podrían automatizar las entrevistas técnicas?

• El enfoque de hacer que un LLM emita juicios subjetivos con algo como “You are a senior SWE-Bench reviewer, make no mistakes.” parece fundamentalmente defectuoso.
  No sé cuál sería una mejor forma manteniendo la viabilidad.

  • Lo más importante es que esto en realidad puede interferir con el trabajo. Si el LLM comete un error, podría verse incentivado a minimizarlo y seguir adelante en lugar de reconocerlo y corregirlo.
  • En realidad, este enfoque consiste en insertar contexto sobre cómo debe comportarse el LLM. “senior reviewer” es el estilo de respuesta deseado, y “SWE-Bench” es el contexto y el dominio en el que debe operar el LLM.
    Es una práctica común en prompts de sistema y ayuda a enmarcar la respuesta.
    Por ejemplo, si dices “un pirata que escribe una canción marinera sobre programación”, “un periodista que escribe un artículo de física” o “un ingeniero de software senior que conoce PostgreSQL a la perfección”, obtendrás respuestas distintas.
    En el primer caso podría salir algo al estilo de Wellerman como “There once was a program that was set to C ...”.
    Pero la parte de “make no mistakes” me parece sospechosa. Sería interesante comparar los resultados con y sin esa frase, y probar otras formas de obtener el mismo comportamiento deseado.
  • La reprimenda de “make no mistakes” se ve bastante ridícula. En YouTube ya se burlaron mucho de eso, pero es fácil imaginar una forma en que podría funcionar, por ejemplo si simplemente se interpreta como “revisa tu trabajo”.
    Claro que no parece haber lugares que hagan públicamente este tipo de mediciones comparativas y permitan llegar a una conclusión razonable.