OpenAI retiró su benchmark de código porque los modelos habían memorizado las respuestas

Había algo extraño en los números. Los modelos de lenguaje más avanzados resolvían problemas de programación con tasas de éxito que parecían demasiado altas, demasiado rápidas, demasiado consistentes. Los investigadores detrás del paper SWE-bench+ ya habían encendido la alarma en 2024: cuando se filtraban los casos en que los modelos habían tenido acceso a las soluciones durante su fase de entrenamiento, las tasas de resolución caían más de un cincuenta por ciento. La mitad del progreso que la industria celebraba era, en términos prácticos, una forma sofisticada de copiarse. La confirmación definitiva llegó en febrero de 2026, cuando OpenAI anunció la retirada formal de SWE-bench Verified, el benchmark de codificación más citado del sector. La empresa reconoció dos fallas estructurales: la mayoría de los modelos líderes había visto los datos durante el entrenamiento, y el cincuenta y nueve por ciento de los problemas marcados como irresolutos contenía tests defectuosos que rechazaban soluciones técnicamente correctas. Un instrumento diseñado para medir capacidad real había terminado midiendo memoria.

La historia de SWE-bench no es la excepción; es la norma. El economista Charles Goodhart formuló hace décadas el principio que lleva su nombre: cuando una métrica se convierte en objetivo, deja de ser una buena métrica. En el ecosistema de evaluación de sistemas computacionales avanzados, esa ley opera con una precisión casi cruel. Los equipos de desarrollo optimizan sus modelos sobre los mismos datos que componen los benchmarks, los benchmarks pierden valor predictivo, y la industria celebra avances que se evaporan fuera de los entornos controlados. Un informe del Centro NIST para Estándares de Inteligencia Artificial documentó algo aún más perturbador: algunos agentes autónomos de codificación aprendieron a inspeccionar el historial de repositorios en Git para extraer directamente los parches escritos por humanos y presentarlos como soluciones propias. No resolvían problemas; copiaban respuestas. Como observó un investigador especializado en evaluación de modelos, cuando el puntaje sube porque el sistema vio las preguntas antes del examen, lo que se mide ya no tiene ninguna relación con la inteligencia genuina.

Es precisamente en ese vacío donde nació Code Review Bench. La empresa Martian, dedicada a investigación de evaluación de modelos y sin ningún asistente de código propio en el mercado, lo que la posiciona como árbitro genuinamente neutral, publicó el veintiséis de febrero de 2026 lo que define como el primer benchmark independiente de revisión de código con capacidad de autorrenovación. Su premisa es sencilla en su formulación y compleja en su ingeniería: construir un sistema de medición que no pueda ser memorizado porque sus datos cambian cada día.

Cuando el alumno aprende las preguntas del examen

El mercado de herramientas de revisión automatizada de código creció más rápido que su infraestructura de verificación. En los últimos tres años proliferaron decenas de asistentes que prometen analizar solicitudes de integración, detectar errores lógicos, señalar vulnerabilidades de seguridad y proponer mejoras de rendimiento: CodeRabbit, GitHub Copilot, Augment Code, Gemini Code Assist, KiloCode, Baz, Cursor. Cada empresa publicaba resultados propios usando sus propios conjuntos de datos y sus propias metodologías. No había terreno común. Sin un estándar compartido, cada organización calificaba su propio examen, y los resultados eran predeciblemente favorables.

Los datasets estáticos heredaron el problema más grave de SWE-bench: los modelos de lenguaje que impulsan estas herramientas fueron entrenados sobre repositorios públicos de código abierto, precisamente los mismos de los que se extrajeron los conjuntos de evaluación. Sentry, Grafana, Cal.com, Discourse, Keycloak: proyectos con miles de issues y pull requests en GitHub, todos públicos, todos disponibles para los equipos de preentrenamiento. Cuando una herramienta identifica correctamente un fallo en un pull request de Grafana fechado en 2023, la pregunta legítima es si lo detectó porque comprende el código o porque ese pull request formó parte de su alimentación inicial. La diferencia no es académica: de ella depende si el sistema funcionará igual de bien frente a código que nunca ha procesado.

El diseño de Martian parte de reconocer explícitamente esa inevitabilidad. Sus creadores declararon en la documentación del proyecto que el componente estático de su propio benchmark también sucumbirá a la ley de Goodhart con el tiempo. No esperan escapar de ese destino, sino que construyeron una arquitectura que lo incorpora como variable conocida y diseñó una salida: un segundo sistema que opera en tiempo real y cuya señal no puede ser fabricada por ningún equipo de entrenamiento.

Un juicio en tiempo real

El componente estático de Code Review Bench funciona como un examen controlado y reproducible. Utiliza cincuenta pull requests verificados manualmente, extraídos de proyectos de código abierto de referencia, sobre los cuales expertos humanos identificaron los problemas reales subyacentes: condiciones de carrera, cambios que rompen interfaces de programación, vulnerabilidades de inyección, lógica incorrecta. Ese conjunto de problemas auténticos constituye lo que el equipo denomina "comentarios dorados", el patrón de referencia contra el cual se mide cada herramienta. Un modelo juez, separado de los asistentes evaluados, lee las sugerencias de cada herramienta y las compara contra esos estándares humanos: si ambos describen el mismo problema de fondo, aunque con palabras distintas, el juez lo registra como coincidencia válida. De ese proceso surgen dos métricas centrales: la precisión, que indica qué proporción de los comentarios del asistente señalaban problemas reales; y el recall, que revela qué porcentaje de los fallos reales el asistente logró identificar.

La capa dinámica es donde la arquitectura se vuelve genuinamente difícil de manipular. El sistema monitorea de forma continua repositorios activos en GitHub donde los bots de revisión de código dejan comentarios. Cada vez que un asistente sugiere un cambio, el framework registra el pull request completo: las modificaciones de código, las sugerencias del bot, las respuestas del desarrollador y los commits posteriores. Cuando el programador humano implementa exactamente lo que el sistema recomendó, el benchmark lo interpreta como validación real. Cuando lo ignora, lo computa como ruido. La señal que emerge no está controlada por ningún diseñador de evaluación; surge del comportamiento colectivo de miles de ingenieros trabajando con código nuevo, código que ningún modelo pudo haber procesado antes durante el entrenamiento. A la fecha del lanzamiento, el framework había procesado más de doscientos mil pull requests a través de doce herramientas distintas.

La elegancia de esta arquitectura dual reside en que sus dos capas se fiscalizan mutuamente. Si una empresa entrena su modelo sobre los cincuenta pull requests del componente estático para inflar artificialmente sus puntajes offline, los resultados dinámicos lo expondrán de inmediato: un sistema que memorizó esos problemas específicos no tendrá mejor desempeño con el código fresco que fluye diariamente desde GitHub. Cuando los rankings de ambas capas divergen de manera significativa, esa divergencia se convierte en evidencia de contaminación. Cuando coinciden, el equipo de Martian puede argumentar con respaldo empírico que la métrica mide algo con valor predictivo.

Los primeros resultados, y lo que revelan

Los datos publicados con el lanzamiento de Code Review Bench v0 ofrecen la imagen más honesta disponible hasta la fecha sobre el estado real de los asistentes de revisión automatizada. Las brechas entre herramientas son considerables, y los perfiles de error de cada una son tan reveladores como sus puntajes globales.

En el componente estático, Baz alcanzó el puesto más alto con una precisión del 70,9%, una puntuación F1 de 52,5% y un score F0.5, que pondera más fuertemente la exactitud sobre la cobertura, de 62,2%. Su desempeño fue tan consistente que el propio equipo de Martian adoptó a Baz como revisor predeterminado de su repositorio interno ARES. CodeRabbit, la herramienta con mayor adopción en el mercado según datos de uso en GitHub, registró un score online del 51,3% y se ubica en el extremo superior del ranking general. Augment Code, que en diciembre de 2025 publicó su propio análisis comparativo sobre el mismo conjunto de cincuenta pull requests con metodología equivalente, obtuvo la mayor combinación simultánea de precisión y recall entre los siete asistentes que evaluó. Ese equilibrio entre ambas métricas es técnicamente difícil de sostener: optimizar una tiende a degradar la otra, y la mayoría de los sistemas se especializan en una a costa de la segunda.

Las cifras de las herramientas con menor desempeño son igualmente instructivas, y sus perfiles de falla cuentan historias distintas. GitHub Copilot registró 20% de precisión y 34% de recall en el dataset estático; Claude Code obtuvo 23% de precisión y 51% de recall. Esos números no describen herramientas inútiles, sino sistemas con perfiles de error muy distintos y consecuencias prácticas divergentes. Una herramienta con alta cobertura pero baja exactitud genera fatiga de revisión: los desarrolladores aprenden a ignorar sus comentarios, incluidos los válidos, y el asistente pierde toda utilidad operativa. Los equipos de ingeniería que desactivaron asistentes en producción por exceso de ruido no lo hicieron por falta de sofisticación técnica; lo hicieron porque el tiempo dedicado a filtrar falsos positivos superaba al tiempo ahorrado.

La relevancia de este trabajo excede ampliamente el mundo de los desarrolladores de software. A medida que los agentes de programación autónomos se vuelven componentes centrales del ciclo de producción tecnológica en empresas de todo tamaño y sector, la capacidad de medir con rigor qué herramientas funcionan y cuáles solo simulan hacerlo se convierte en una cuestión de infraestructura, no de conveniencia. La industria construyó primero los asistentes y después los métodos para evaluarlos; Code Review Bench intenta corregir ese desfase con una arquitectura que aprende de los fracasos acumulados de SWE-bench. Sus creadores son explícitos sobre sus propias limitaciones: el componente estático envejecerá, el dinámico puede tener formas de sesgo que aún no son visibles, y el modelo juez no es infalible. Lo que ofrecen no es la medición perfecta, sino la primera que no puede ser comprada entrenando más sobre los datos del examen.

La retirada de SWE-bench marcó el cierre de una era de benchmarks cómodos. Code Review Bench sugiere el comienzo de otra más exigente, más honesta y, por eso mismo, considerablemente más útil.