SWE-Duel: los agentes de programación se plantan bugs entre sí y GPT-5.5 corrige el 98,3%

Los benchmarks estáticos de programación envejecen rápido: sus tareas acaban en los conjuntos de entrenamiento y los agentes más potentes tocan techo. Los autores del preprint SWE-Duel (arXiv cs.CL) proponen otro enfoque: una evaluación sin contenido preparado de antemano. Dos agentes crean tareas el uno para el otro y se revisan mutuamente. En el torneo de 1500 turnos participaron 11 combinaciones de «modelo + harness» sobre 15 repositorios en cinco lenguajes. GPT-5.5 con Codex CLI se llevó el primer puesto: corrige el 98,3% de los defectos que le llegan a revisión.

Cómo funciona un turno del duelo

En cada turno, el agente Red trabaja con un repositorio real en tres sesiones con el contexto aislado. Primero idea e implementa una nueva funcionalidad junto con sus pruebas. Después le introduce un bug sutil y escribe pruebas selladas que lo detectan. El resultado es un pull request.

La tarea solo entra en el conjunto si se cumplen dos condiciones. Primera: el PR pasa las pruebas de la funcionalidad y las pruebas existentes del repositorio, y falla exactamente en las pruebas del bug. Segunda: una sesión nueva del mismo agente debe arreglar el bug a ciegas. Esta segunda condición descarta las tareas irresolubles: si el autor no es capaz de corregir su propio bug plantado, la tarea no cuenta.

A continuación entra en juego Blue. No se le avisa de que el PR contiene un bug; simplemente hace la revisión. Solo se le da la victoria si su corrección pasa los tres conjuntos de pruebas. Después los agentes intercambian los roles. Así, la dificultad no queda fijada en el momento del lanzamiento, sino que crece con la fuerza de los participantes.

Quién gana y cómo

Los líderes ganan de formas distintas. Los autores distinguen dos perfiles: el mejor resolutor y el mejor autor de tareas.

• GPT-5.5 + Codex CLI: primer puesto, mejor resolutor, corrige el 98,3% de los defectos verificables.
• Claude Opus 4.8 + mini-swe-agent: segundo puesto, mejor autor de tareas, con una tasa de victorias de Red del 27,3%.
• Escala del torneo: 11 participantes, 15 repositorios, cinco lenguajes, 1500 turnos.
• Dentro de una misma familia de modelos, las tareas de la versión más reciente vencen a un resolutor de referencia fijo en el 42,9% de los casos; las de las versiones anteriores, en el 4,0%.

La última cifra es, quizá, la más interesante. Apunta, de forma preliminar, a que la dificultad de las tareas crece junto con la capacidad del modelo para inventarlas. Para un benchmark que debe «crecer solo», esta es la propiedad clave. Si se confirma en más familias de modelos, el techo de saturación dejará de ser un problema: los autores más fuertes prepararán automáticamente exámenes más difíciles.

Conviene recordar, además, que los participantes aquí son pares de «modelo + harness». La clasificación refleja la calidad de toda la combinación, no solo de los pesos del modelo. Los propios autores califican de preliminar el resultado sobre el aumento de la dificultad, y es una salvedad honesta: los datos proceden de un único torneo.

Qué se puede llevar a la práctica

La idea se puede aplicar sin necesidad de una arena con 11 participantes. Un equipo que esté eligiendo un agente de programación puede probarlo en su propio repositorio con el esquema del duelo. Un agente escribe una funcionalidad con sus pruebas y esconde un bug, y un segundo agente, o una sesión nueva, intenta encontrarlo y corregirlo. Un leaderboard público no mostrará algo así: en vuestras tareas, el modelo puede que ya esté «cosido» al entrenamiento.

Las conclusiones prácticas son estas. Separad las métricas: la capacidad de arreglar código ajeno y la de inventar tareas difíciles miden habilidades distintas, y los líderes en ambas no coinciden. El filtro de admisión de tareas (pasa todas las pruebas salvo la del bug y se resuelve a ciegas) merece adoptarse como plantilla independiente de control de calidad para cualquier evaluación sintética. Y al comparar productos, fijaos en la combinación concreta de modelo y harness, no solo en el nombre del modelo.