💬 NLP

RuBench: A Repository-Level Agentic Coding Benchmark with Natively Authored Russian Task Specifications

RuBench es un repositorio de evaluación de codificación agéntica a nivel de repositorio que presenta 25 especificaciones de tareas redactadas nativamente en ruso a partir de proyectos de código abierto reales, diseñado para evaluar agentes de codificación de grado de producto en tareas de mantenimiento reales mientras asegura la resistencia a la contaminación de datos y revela información crítica sobre los comportamientos de sistemas desplegados mediante un análisis estadístico riguroso y una auditoría de trayectorias.

Autores originales: Evgeny Shilov (Independent Researcher)

Publicado 2026-07-08

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Evgeny Shilov (Independent Researcher)

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás contratando a un equipo de mecánicos expertos para reparar una flota de coches de carreras complejos y personalizados. Hasta ahora, la mayoría de las pruebas para estos mecánicos se habían escrito en un inglés perfecto y formal, como un manual técnico. Pero en el mundo real, los clientes no hablan como un manual; hablan como personas. Dicentes cosas como: "Mi coche empezó a vibrar cada vez que pisaba el freno en un martes lluvioso", en su propio idioma nativo.

RuBench es una nueva prueba diseñada para ver si los asistentes de programación de IA pueden realmente entender estas solicitudes desordenadas del mundo real cuando están escritas en ruso, no en inglés.

Aquí tienes un desglose de cómo funciona la prueba, qué sucedió y el giro sorprendente que los investigadores descubrieron, utilizando analogías sencillas.

1. La Prueba: Un taller de reparaciones del "Mundo Real"

La mayoría de las pruebas anteriores entregaban a los agentes de IA una descripción limpia y en inglés de un error. RuBench es diferente:

Los Coches: La prueba utiliza cinco proyectos de software de código abierto reales y populares (como aiohttp o Laravel). Estos no son acertijos falsos; son bases de código vivas utilizadas por miles de desarrolladores.
Las Solicitudes: En lugar de un informe de error formal, los investigadores escribieron 25 nuevas solicitudes desde cero en ruso. Suenan como un dueño de negocio quejándose con un contratista: "El bot se bloquea cuando lo hacemos administrador; arréglalo, pero no rompas los chats existentes".
La Caja Misteriosa: Los investigadores ocultaron la "clave de respuestas" (la corrección de código real y las pruebas que demuestran que funciona). La IA tiene que descubrir la solución por sí misma. Solo los investigadores tienen la clave para comprobar si la IA tuvo éxito.
Novedad: Todos los errores se encontraron en actualizaciones de código realizadas después de que los modelos de IA fueran entrenados. Esto asegura que la IA no pudiera simplemente haber memorizado la respuesta de sus datos de entrenamiento.

2. Los Mecánicos: ¿Quién hizo el trabajo?

Los investigadores probaron cuatro diferentes "equipos de mecánicos" (combinaciones de herramientas de software y modelos de IA). Pasaron cada equipo por las 25 reparaciones tres veces para ver qué tan consistentes eran.

El Rendimiento Estrella: El equipo que utilizaba Claude Code con el modelo "Opus 4.8" fue el mejor. Corrigió con éxito aproximadamente el 79% de los problemas.
El Grupo Medio: El modelo "Sonnet 5" lo hizo casi igual de bien (75%), y el "GPT-5.5" (a través de Codex CLI) corrigió alrededor del 67%.
El Mecánico con Dificultades: El modelo "Haiku 4.5" (una versión más barata y rápida) solo corrigió aproximadamente el 53% de las tareas.

El Problema: Debido a que solo hubo 25 tareas, la diferencia entre los tres mejores equipos no fue "probada" estadísticamente como real —podría haber sido solo suerte—. Sin embargo, la brecha entre los mejores equipos y el problemático modelo Haiku fue enorme y clara. Los mejores equipos resolvieron una clase de problemas completamente diferente a la del grupo de abajo.

3. La Gran Sorpresa: La "Sustitución Silenciosa"

Esta es la parte más interesante del artículo. Los investigadores también probaron un quinto equipo utilizando un modelo nuevo llamado Fable 5.

Cuando examinaron de cerca los registros de la "caja negra" de lo que estaba haciendo la IA, descubrieron un secreto:

En el 20% de las tareas, el modelo Fable 5 no realizó el trabajo en realidad.
En su lugar, el producto de software (Claude Code) sustituyó silenciosamente a Fable 5 por el modelo más antiguo y fuerte, Opus 4.8, en medio del trabajo.
¿Por qué? Fable 5 tiene salvaguardas de seguridad que son muy estrictas. Cuando vio una tarea que involucraba protocolos estándar de internet (como arreglar un encabezado web), su salvaguarda de seguridad se puso nerviosa y dijo: "No se me permite tocar esto", y el sistema automáticamente le entregó el trabajo a Opus 4.8 para terminarlo.

La Lección: Los investigadores se dieron cuenta de que cuando probamos productos de IA, no estamos probando solo el "cerebro" (el modelo); estamos probando el "cuerpo" (todo el paquete de software). Si el software cambia secretamente el cerebro a mitad de la tarea, los resultados de la prueba están mintiendo sobre lo que ese cerebro específico puede hacer.

4. El Veredicto

Éxito: Los agentes de IA de grado de producto ya son lo suficientemente buenos como para manejar trabajos de mantenimiento real especificados en un idioma que no es el inglés (ruso). La mejor configuración resolvió casi 8 de cada 10 tareas.
Realidad: Los modelos "baratos" (como Haiku) siguen siendo significativamente más débiles, resolviendo solo la mitad de los problemas.
Metodología: El artículo demuestra que para obtener resultados honestos, debemos observar todo el "diario" (trayectoria) de la IA para asegurarnos de que no hizo trampa cambiando de modelo o buscando las respuestas en internet.

En resumen, RuBench muestra que la IA está mejorando en su capacidad de hablar "humano" (en ruso), pero también reveló que el software que envuelve a estas IA a veces puede ser astuto, sustituyendo al trabajador por uno mejor sin avisar a nadie.

Resumen Técnico: RuBench 1.0

Planteamiento del Problema

Los actuales benchmarks de codificación agéntica a nivel de repositorio (por ejemplo, SWE-bench) no logran evaluar una capacidad crítica del mundo real: la capacidad de los agentes de codificación para interpretar y ejecutar tareas especificadas nativamente en lenguas no inglesas, particularmente en el estilo de las solicitudes de clientes en lugar de los problemas de GitHub curados. Los benchmarks "multilingües" existentes dependen por diseño de declaraciones en inglés o funcionan a nivel de fragmento/archivo único, careciendo de la complejidad del mantenimiento de un repositorio completo. Además, los benchmarks estáticos sufren de filtración de soluciones y memorización, y las evaluaciones suelen desacoplar el entorno del agente del modelo, ignorando cómo las configuraciones de productos desplegados (CLI + modelo + esfuerzo de razonamiento) afectan materialmente el comportamiento.

Metodología

RuBench 1.0 introduce un benchmark diseñado para medir la codificación agéntica a nivel de repositorio con especificaciones nativas en ruso.

Construcción del Benchmark

Minería de Tareas: Se extrajeron 25 tareas de commits de corrección fusionados entre febrero y junio de 2026 en cinco repositorios de código abierto activos: aiohttp, aiogram, Laravel, NestJS y Fastify. Estos abarcan Python, PHP, TypeScript y JavaScript.
Especificaciones Nativas: A diferencia de los benchmarks traducidos, cada tarea presenta una especificación escrita desde cero en ruso, imitando la solicitud de un dueño de negocio (describiendo síntomas, comportamiento requerido y restricciones) en lugar de la entrada de un rastreador de problemas de un desarrollador. Estas especificaciones no existen en la web pública antes de su lanzamiento.
Puerta de Frescura (Freshness Gate): Todas las 25 tareas son posteriores a los cortes de datos de entrenamiento de cada modelo evaluado (que oscilan entre julio de 2025 y enero de 2026), asegurando un argumento de contaminación tarea por tarea.
Oráculo Privado: La calificación es realizada por las suites de pruebas de regresión del mantenedor original, las cuales se mantienen reservadas para el lanzamiento público. Se ha incluido un manifiesto SHA-256 de estos oráculos para verificar la integridad sin revelar las pruebas.
Espacio de Trabajo: Los agentes reciben una instantánea del repositorio en el commit padre de la corrección, despojada del historial de git y de las pruebas del oráculo.

Protocolo Experimental

Configuraciones: El estudio evalúa cuatro configuraciones de producto desplegadas (agente CLI + modelo + conjunto de esfuerzo de razonamiento al máximo):
- Claude Code con Opus 4.8
- Claude Code con Sonnet 5
- Claude Code con Haiku 4.5
- Codex CLI con GPT-5.5
- Hors concours: Claude Code con Fable 5 (lanzamiento del 2 de julio de 2026).
Ejecución: Cada configuración se ejecuta tres veces de forma independiente por tarea en espacios de trabajo aislados con acceso a la red (requerido para la instalación de paquetes).
Métricas: El rendimiento se reporta como pass@1 (fracción de ejecuciones exitosas entre 3 ensayos) promediado sobre 25 tareas. La incertidumbre se cuantifica mediante intervalos de confianza de Wilson del 95% a nivel de tarea y comparaciones de bootstrap emparejadas (10,000 remuestreos).
Auditorías de Validez: Las trayectorias son auditadas para detectar escapes del oráculo y, crucialmente, para la sustitución de modelos (asegurando que el modelo que ejecuta coincida con el modelo solicitado).

Resultados Clave

Rendimiento: La mejor configuración, Claude Code + Opus 4.8, resolvió el 78.7% de las tareas (media sobre 3 ejecuciones). La más débil, Claude Code + Haiku 4.5, resolvió el 53.3%.
Significancia Estadística: Con $N=25$ , el límite de resolución del benchmark es de aproximadamente 25 puntos porcentuales. Solo se encontraron brechas estadísticamente resolubles (donde el intervalo de bootstrap excluye el cero) entre el modelo más débil (Haiku 4.5) y los demás. Las diferencias entre las tres mejores configuraciones (Opus 4.8, Sonnet 5, GPT-5.5) estuvieron dentro de los márgenes de ruido.
Costo y Eficiencia:
- Sonnet 5 logró una resolución del 74.7% con un 78% del costo de Opus 4.8 ($2.42 vs $3.12 por tarea).
- Codex CLI + GPT-5.5 fue el más eficiente en tokens (16k tokens de salida frente a 33k para Opus 4.8) pero resolvió menos tareas (66.7%).
Hallazgo de Sustitución de Salvaguarda: Una auditoría de la configuración hors concours Claude Code + Fable 5 reveló que en 5 de 25 tareas (20%), el producto sustituyó silenciosamente el modelo solicitado (Fable 5) por Opus 4.8 debido a disparadores de salvaguarda internos (específicamente para correcciones rutinarias del protocolo HTTP). Esto resultó en una clasificación de "fallback de salvaguarda" para esas tareas, demostrando que el producto desplegado, y no solo el modelo, es la unidad de medida.

Significancia y Reivindicaciones

El artículo reclama tres contribuciones primarias:

Un Nuevo Protocolo de Benchmark: RuBench es el primer benchmark a nivel de repositorio que utiliza especificaciones redactadas nativamente en una lengua distinta al inglés con oráculos privados y una puerta de frescura, abordando la brecha en la evaluación de la recuperación de la intención en lenguas nativas.
Medición Honesta de la Incertidumbre: Al reportar intervalos de confianza a nivel de tarea y comparaciones emparejadas, el estudio reconoce explícitamente las limitaciones estadísticas de los benchmarks de muestra pequeña ( $N=25$ ), evitando afirmaciones excesivamente confiadas sobre clasificaciones donde las brechas no son estadísticamente resolubles.
Regla de Validez a Nivel de Producto: El descubrimiento de la sustitución silenciosa de modelos establece una regla de validez: una evaluación solo es válida si la trayectoria confirma que el modelo ejecutado coincide con el modelo solicitado. Esto resalta que las evaluaciones de "agentes" a menudo miden la lógica de salvaguarda y enrutamiento del proveedor en lugar de la capacidad bruta del modelo.

Los autores concluyen que, si bien los agentes de grado de producto pueden manejar trabajos de mantenimiento real especificados en ruso (78.7% de éxito para el nivel superior), el campo está actualmente más separado por el "nivel económico" (Haiku) que por los modelos de frontera, y que las evaluaciones futuras deben auditar las trayectorias para asegurar la integridad del modelo que se está probando.