DeepSWE revela qué modelos realmente saben programa

Durante los últimos años, los rankings de programación automática empezaron a sufrir un problema conocido: demasiados modelos parecían estar demasiado cerca. En las tablas públicas, sistemas de familias distintas aparecían separados por pocos puntos, como si todos hubieran llegado a una meseta común. Pero muchos desarrolladores contaban otra historia. En el trabajo diario, las diferencias no se sentían pequeñas. Un agente podía entender una consigna ambigua, navegar una base de código desconocida, modificar la pieza correcta y no romper nada. Otro, con una nota parecida en el leaderboard, podía perderse en un archivo lateral, arreglar el síntoma equivocado o entregar un parche que pasaba un test estrecho pero no resolvía el problema.

DeepSWE nace para atacar esa distancia entre el ranking y la experiencia real. DataCurve lo presenta como una evaluación de tareas largas de ingeniería de software, construida desde cero sobre 113 desafíos, 91 repositorios activos y cinco lenguajes: TypeScript, Go, Python, JavaScript y Rust. La cifra importante no es solo la cantidad. La apuesta metodológica está en el tipo de tarea: consignas breves, soluciones extensas, verificadores escritos a mano y problemas originales que no dependen de commits públicos ya existentes.

La diferencia parece técnica, pero el impacto es muy concreto. Si una prueba usa problemas extraídos de pull requests ya publicados, el modelo puede haber visto parte del arreglo durante su entrenamiento o puede encontrar rastros del parche en el entorno. Si el test solo comprueba una firma interna o una ruta mínima, una solución incompleta puede pasar. Si la consigna viene excesivamente detallada, el agente no tiene que hacer ingeniería, solo obedecer una receta. DeepSWE intenta cerrar esas tres puertas al mismo tiempo: evita soluciones públicas previas, obliga a explorar repositorios variados y verifica comportamiento observable, no coincidencias superficiales con la estructura esperada por quien escribió la prueba.

La prueba que cambia el terreno

El rasgo más disruptivo de DeepSWE es su rechazo a la comodidad de las tareas heredadas. Cada desafío se escribe desde cero. La solución de referencia también se crea específicamente para la evaluación, no se copia ni se adapta desde un pull request previo. Algunas consignas pueden estar inspiradas en issues abiertos, pero el arreglo final no proviene de un parche público. Además, esas soluciones no se integran de vuelta a los repositorios originales. La intención es clara: medir resolución, no memoria.

Esto no significa que el benchmark quede blindado para siempre. Desde el momento en que una evaluación se publica, sus datos pasan a formar parte del paisaje informativo que futuros sistemas podrían encontrar. DataCurve intenta reducir ese riesgo con diseño original y una marca canaria explícita en la página de datos, pero la contaminación es un problema estructural de toda evaluación pública. Lo relevante es que DeepSWE no nace apoyado sobre soluciones ya disponibles en GitHub. Ese punto lo coloca en una posición distinta frente a bancos de prueba construidos a partir de commits, issues y tests que ya circulaban en la web.

La segunda innovación está en el tamaño real del trabajo. Según DataCurve, los prompts de DeepSWE son mucho más cortos que los de SWE-Bench Pro, pero las soluciones de referencia agregan muchas más líneas de código. La prueba no le entrega al agente un manual de instrucciones con nombres de funciones, fragmentos de código y caminos casi marcados. Le da una solicitud relativamente natural, parecida a la que un desarrollador escribiría en una herramienta de asistencia, y espera que el sistema localice el área relevante, entienda la arquitectura y produzca una modificación coherente.

Ese contraste altera la naturaleza del examen. Un prompt largo puede simplificar la búsqueda, porque transforma el trabajo en ejecución de instrucciones. Un pedido más breve obliga a leer el proyecto. El agente tiene que descubrir dónde está la lógica, qué contrato público debe respetar, qué tests existentes conviene ejecutar y qué efecto lateral podría romper una parte no mencionada de la aplicación. En otras palabras, DeepSWE intenta medir lo que ocurre cuando el copiloto deja de ser un autocompletador glorificado y debe comportarse como un ingeniero junior con acceso a una terminal, poca paciencia humana disponible y una base de código que no perdona.

Lo que mide cuando mide

La gran batalla de DeepSWE no está solo en el corpus, sino en el verificador. En programación, un test puede mentir de dos formas. Puede aprobar una solución equivocada, lo que infla el resultado. También puede rechazar una solución válida, lo que castiga al modelo por no haber imitado exactamente la forma esperada por el autor de la prueba. En ambos casos, el ranking deja de medir capacidad y empieza a medir suerte, fuga de información o afinidad con una implementación particular.

DataCurve afirma haber auditado 30 tareas al azar de DeepSWE y 30 de SWE-Bench Pro, con tres ejecuciones por tarea y diez configuraciones de agentes de frontera. Luego usó un juez basado en modelo para revisar trayectorias, definición de tarea, solución de referencia y resultado del verificador. La conclusión publicada es fuerte: el desacuerdo entre el analizador y el verificador aparece en 32% de los ensayos de SWE-Bench Pro y en 1,4% de los de DeepSWE. Traducido al castellano menos solemne: en una parte considerable de los casos, el semáforo rojo o verde del benchmark anterior no estaría contando bien lo que ocurrió.

La diferencia metodológica aparece con nitidez en los falsos positivos. SWE-Bench Pro, según la auditoría, puede aceptar soluciones que pasan por una filtración del historial Git o por tests demasiado estrechos. DeepSWE intenta evitarlo con tareas originales, clones superficiales que no contienen el arreglo dorado y verificadores orientados al comportamiento final. Si el agente implementa una función hueca que satisface una firma pero no cambia la conducta visible, debería fallar. Si resuelve el problema con una estructura distinta a la solución de referencia, debería pasar.

Los falsos negativos son igual de importantes. Un benchmark puede rechazar una respuesta correcta porque el test importaba un helper privado que el agente no creó, aunque haya resuelto el problema de otra manera. También puede fallar porque faltan fixtures asociados al commit original o porque se incluyen tests no relacionados con el cambio pedido. DeepSWE intenta reducir ese ruido al escribir verificadores desde la especificación de la tarea, no desde el accidente histórico de un pull request particular.

Este enfoque tiene un efecto adicional: permite observar estilos de falla. DataCurve no se queda en el porcentaje final. Analiza trayectorias y clasifica errores como requisitos omitidos, fallas de integración, regresiones, lógica equivocada, archivos incorrectos o supuestos no verificados. Esa taxonomía importa porque dos modelos con la misma nota pueden ser peligrosos de maneras diferentes. Uno puede fallar por no leer un requisito paralelo. Otro puede escribir demasiado código defensivo. Otro puede probar poco. Para un equipo de ingeniería, saber cómo falla un sistema puede valer más que saber cuánto falla.

Resultados, costos y grietas visibles

El leaderboard publicado por DataCurve muestra una separación marcada. gpt-5.5 aparece arriba con 70% más o menos 4 puntos. Detrás figuran gpt-5.4 con 56% más o menos 5 y claude-opus-4.7 con 54% más o menos 5. Luego el corte se vuelve más brusco: claude-sonnet-4.6 cae a 32%, gemini-3.5-flash queda en 28%, gpt-5.4-mini y kimi-k2.6 aparecen en 24%, y el resto desciende hasta cifras de un dígito en algunos casos. La lectura de DataCurve es que DeepSWE abre una brecha más amplia que SWE-Bench Pro entre modelos de frontera.

La distancia no prueba por sí sola que una evaluación sea superior. Un benchmark también puede separar modelos porque está sesgado hacia una familia, un harness o un tipo de tarea. Por eso DataCurve dedica espacio a justificar el uso de mini-swe-agent. Todos los modelos corren con el mismo andamiaje: una herramienta bash compartida y un prompt común. Esa decisión sacrifica parte del realismo, porque en la práctica los desarrolladores usan Codex CLI, Claude Code, Gemini CLI, Cursor u otros entornos nativos. Pero ofrece una ventaja analítica: reduce la posibilidad de que el ranking mida la ingeniería del envoltorio en vez del modelo.

El propio informe reconoce el límite. Algunos sistemas fueron entrenados para herramientas específicas de edición, como apply_patch o editores de reemplazo estructurado. Al obligarlos a pasar por bash, DeepSWE puede estar por debajo de su techo nativo. Aun así, el piloto comparativo publicado por DataCurve indica que mini-swe-agent igualó o superó a harnesses nativos en una pequeña muestra de tareas de SWE-Bench Pro. No es una demostración definitiva, pero sí un argumento razonable para usar un entorno común sin destruir la comparación.

El análisis de costos agrega otra capa. DataCurve mide tokens de salida, duración de pared y costo por ensayo. La conclusión publicada es incómoda para la intuición simple: gastar más tokens, tardar más o pagar más no garantiza resolver más tareas. gpt-5.5 alcanza el mejor resultado con una mediana de 47.000 tokens de salida y 20 minutos por ensayo. gpt-5.4 y gpt-5.5 aparecen como configuraciones especialmente eficientes en costo dentro del gráfico publicado. Para una empresa que evalúa agentes de programación, esto cambia la pregunta. Ya no se trata de elegir el modelo con el número más alto, sino de cruzar precisión, latencia, gasto, tasa de regresión y patrón de falla.

La sección cualitativa del informe es una de las más reveladoras. DataCurve observa que algunas configuraciones de Claude tienden a omitir ramas paralelas en consignas multipartes: implementan el caso sincrónico y olvidan el asincrónico, o cubren un tipo de comentario y no el otro. También señala que Claude Opus 4.7 explora mejor el entorno cuando la historia del repositorio contiene pistas, lo que en SWE-Bench Pro puede transformarse en un comportamiento problemático si el commit dorado está disponible en el historial. GPT, según la lectura de DataCurve, sigue de manera más literal el contrato visible del prompt y del repositorio, con menor tasa de requisitos omitidos en DeepSWE.

La evaluación, entonces, no debería leerse como sentencia final. Es una herramienta más precisa para una zona específica del trabajo: cambios largos, repositorios diversos, verificación conductual y agentes obligados a explorar. Su valor está en que desplaza el centro de gravedad. Ya no pregunta si un sistema puede resolver un ticket empaquetado con todos los indicios necesarios, sino si puede operar con una consigna razonablemente humana y producir una modificación que sobreviva al contacto con un proyecto real.

Ese corrimiento importa porque la programación asistida está dejando de ser una demostración de laboratorio. El problema ya no es que el agente escriba una función bonita en una pantalla vacía. El problema es que entre en una base viva, no se maree con la arquitectura, encuentre el punto de intervención, pruebe lo que cambió y no deje una bomba en otra carpeta. DeepSWE no clausura la discusión, pero la empuja hacia donde debía ir: menos examen de memoria, más ingeniería de verdad.