Datacurve lanzó DeepSWE, un benchmark de ingeniería de software de horizonte largo con 113 tareas a través de 91 repositorios en 5 lenguajes. Puntajes top reportados: GPT-5.5 al 70%, GPT-5.4 al 56%, Claude Opus 4.7 al 54%, Gemini 3.1 Pro al 10%. El titular lee "GPT-5.5 gana". La historia interesante para constructores está en la página de metodología, no en el leaderboard.
Los cuatro avances declarados del benchmark: tareas escritas desde cero en lugar de adaptadas de PRs o commits existentes, con un GUID deep-swe-canary embebido para que la contaminación pueda detectarse si el corpus filtra en el pretraining; cobertura abarcando 91 repos y 5 lenguajes; prompts aproximadamente la mitad de la longitud de los de SWE-bench Pro pero soluciones requiriendo 5.5x más código y ~2x más tokens de salida; verifiers escritos a mano que prueban comportamiento del software en lugar de detalles de implementación. Todos los modelos corren a través de mini-swe-agent para un scaffold común. Los ejemplos de tareas son no triviales — "Agregar operaciones XML diff, patch, y merge a etree", "Agregar generación trap coredump a wasmi", "Corregir ordenamiento PromQL de labels a través de valores tipados y no tipados" — trabajo que tomaba horas a ingenieros antes de la era agentic. Niveles de presupuesto de razonamiento asimétricos en la comparación: GPT-5.5 corrió en xhigh, Claude Opus 4.7 en max, Gemini 3.1 Pro sin etiqueta.
Dos lecturas relevantes para constructores. Primera: la brecha de 60 puntos entre GPT-5.5 y Gemini 3.1 Pro es lo suficientemente grande para sospechar sesgo estructural del benchmark hacia el idioma de tool-use de un modelo, especialmente en un eval nuevo donde las convenciones de harness importan. Los puntajes SWE-bench Verified se estrecharon cuando el campo tuvo tiempo de re-correr en múltiples scaffolds; DeepSWE probablemente seguirá el mismo arco. Segunda: Datacurve está en el negocio de servicios de datos, así que un benchmark que rankea modelos foundation es también un anuncio para la compañía que lo construyó. Eso no invalida el eval, pero significa que el leaderboard pide re-ejecución independiente antes de ser load-bearing. La elección del harness mini-swe-agent es un scaffold — OpenHands, Aider, harnesses estilo Claude Code producirán diferentes ordenamientos relativos en las mismas tareas.
Si envías agentes que usan código el lunes por la mañana: lee la sección de metodología de cualquier nuevo benchmark SWE antes de tratar los números como ordenamiento. Busca el GUID canary, la divulgación del scaffold, la normalización del presupuesto de razonamiento, y si el eval vive en un contenedor Docker que puedes correr tú mismo. Apuesta a la tendencia metodológica, no al titular del leaderboard.