SWE-bench es un benchmark para evaluar modelos y agentes de IA en ingeniería de software real. En lugar de problemas inventados, utiliza issues reales de repositorios populares de código abierto escritos en Python.

Cómo funciona

Cada tarea tiene una issue, que es la descripción de un bug o una mejora, y el código del proyecto en el estado anterior a la corrección. El agente debe leer el repositorio, entender el problema y generar un patch.

Luego, se ejecutan los tests del proyecto con el patch aplicado. Si los tests que antes fallaban pasan y los que funcionaban siguen funcionando, la tarea cuenta como resuelta.

El resultado suele ser el porcentaje de tareas resueltas. Existen variantes, como subconjuntos revisados por humanos para garantizar que las tareas sean justas.

Como el resultado depende tanto del modelo como del agente que lo rodea, la puntuación mezcla ambos. Las herramientas de búsqueda en código, la ejecución de tests y el número de intentos cambian el marcador.

Ejemplo práctico

Una issue indica que una función de fechas devuelve el mes incorrecto en años bisiestos. El agente abre el repositorio, localiza la función, escribe la corrección y ejecuta los tests.

Terminal
pytest tests/test_datas.py

Si todo pasa y nada más se rompe, esa tarea suma un punto. Repetido en cientos de tareas, esto genera la nota final.

Para qué sirve

SWE-bench sirve para comparar agentes de código en un escenario más cercano al trabajo diario. Cuando una empresa anuncia un nuevo modelo, es común citar la puntuación en este test.

Para quienes eligen herramientas, indica qué modelos manejan mejor proyectos existentes. Pero el marcador no garantiza el mismo resultado en tu código, así que prueba con tus propias tareas.

Al comparar puntuaciones, verifica qué variante se usó, qué agente se ejecutó y la fecha, porque los rankings cambian rápido.

Diferencia entre SWE-bench y HumanEval

HumanEval pide una función pequeña y aislada. SWE-bench pide una corrección dentro de un proyecto real, con varios archivos y tests existentes. El segundo es más exigente y más parecido al día a día de un dev.