Programación
Compara la corrección, la calidad y la utilidad práctica del código generado.
En este genero, las capacidades que mas se intentan medir son Correccion, Integridad, Calidad del codigo.
A diferencia de system design, aqui pesa mas si el codigo realmente funciona que las decisiones de arquitectura de alto nivel.
Una puntuacion alta aqui no garantiza mejor juicio de producto, mejor arquitectura ni mejores explicaciones para principiantes.
Para que sirve un modelo fuerte en este genero
implementacion, depuracion, refactorizacion y apoyo practico al programar.
Lo que este genero por si solo no alcanza a mostrar
si el modelo es mejor para arquitectura, documentos para stakeholders o ideacion abierta.
Programación: la familia GPT-5 domina la cima, casi siempre con pocas muestras
OpenAI
OpenAI
OpenAI
Puntuacion media por modelo
Como ponderamos
Sobre 32 respuestas de programación evaluadas, los tres primeros puestos son de la familia GPT-5. GPT-5.5 ocupa el puesto 1 con una media de 8,85 y un registro perfecto, pero se apoya en una sola muestra, así que conviene leerlo como una señal prometedora más que como un resultado consolidado. El mejor resultado con respaldo sólido es GPT-5 mini en el puesto 2: 8,22 sobre 5 muestras, 5 primeros puestos y un 100 % de victorias, una barrida limpia a coste de gama ligera.
La media y el orden divergen, porque la tasa de victorias (primeros puestos directos) pesa más que la media bruta. GPT-5.4 promedia 8,41 sobre 8 muestras, el mayor volumen de evidencia aquí, con un 75 % de victorias y el puesto 3. Gemini 2.5 Pro logra la misma media de 8,41 pero queda 5.º, porque no ganó ninguno de sus 3 enfrentamientos. Si te importa la calidad absoluta más que quién gana cara a cara, GPT-5.4 y Gemini 2.5 Pro están más cerca de lo que sugiere su puesto.
La zona media la lidera Claude Sonnet 4.6 (media 7,7, 50 % sobre 4 muestras), por detrás del grupo GPT-5 entre 0,5 y 1,1 puntos. Las gamas más ligeras quedan más abajo: Gemini 2.5 Flash (7,31), Flash-Lite (7,17) y Claude Haiku 4.5 (6,48) están entre 1,5 y 2,4 puntos del líder. Con la Corrección ponderada al máximo (35), por delante de Calidad de código y Completitud (20 cada una), esas brechas apuntan a una corrección más débil en las tareas difíciles, no solo al estilo.
La mayor salvedad es el tamaño de muestra. GPT-5.5 se apoya en 1 muestra y la mayoría se mueven entre 3 y 8, así que las medias pueden oscilar con unos pocos prompts. La diferencia de 2,37 puntos entre el primero y el último es real, pero el orden fino dentro del grupo de 8 puntos (GPT-5.5, GPT-5.4, GPT-5 mini, Gemini 2.5 Pro) debe leerse como provisional. Son medidas dependientes de las condiciones, no un veredicto sobre qué modelo programa mejor en general.
En resumen
Para programar con garantías hoy, GPT-5 mini es la elección más defendible (100 % de victorias sobre 5 muestras a coste de gama ligera), mientras que GPT-5.4 es la opción de gama alta mejor evidenciada (8,41 sobre 8 muestras). Toma el liderazgo de una sola muestra de GPT-5.5 como prometedor pero no probado.
Este analisis se basa en las puntuaciones de benchmark medidas por Orivel para este genero y se actualiza periodicamente. Las puntuaciones son medidas que dependen de las condiciones, no una verdad absoluta.
Ranking de modelos fuertes en este genero
Este ranking se ordena por la puntuacion media solo dentro de este genero.
Ultima actualizacion: 12 Jun 2026 09:39
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
| Modelos clasificados | Detalle | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Ver la evaluacion y la puntuacion de GPT-5 mini |
| #2 | GPT-5.4 | OpenAI |
75%
|
84
|
6 | 8 | Ver la evaluacion y la puntuacion de GPT-5.4 |
| #3 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | Ver la evaluacion y la puntuacion de GPT-5.5 |
| #4 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Ver la evaluacion y la puntuacion de Claude Sonnet 4.6 |
| #5 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Ver la evaluacion y la puntuacion de Gemini 2.5 Pro | |
| #6 | Gemini 2.5 Flash |
0%
|
73
|
0 | 4 | Ver la evaluacion y la puntuacion de Gemini 2.5 Flash | |
| #7 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver la evaluacion y la puntuacion de Gemini 2.5 Flash-Lite | |
| #8 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 4 | Ver la evaluacion y la puntuacion de Claude Haiku 4.5 |
Que se evalua en Programación
Criterios y pesos usados para este ranking por genero.
Correccion
35.0%
Este criterio se incluye para comprobar Correccion en la respuesta. Tiene mas peso porque este aspecto cambia mucho el resultado global del genero.
Integridad
20.0%
Este criterio se incluye para comprobar Integridad en la respuesta. Tiene un peso importante porque afecta la calidad de forma visible, aunque no sea lo unico que importa.
Calidad del codigo
20.0%
Este criterio se incluye para comprobar Calidad del codigo en la respuesta. Tiene un peso importante porque afecta la calidad de forma visible, aunque no sea lo unico que importa.
Valor practico
15.0%
Este criterio se incluye para comprobar Valor practico en la respuesta. Tiene menos peso porque acompana el objetivo principal, pero no define por si solo este genero.
Seguimiento de instrucciones
10.0%
Este criterio se incluye para comprobar Seguimiento de instrucciones en la respuesta. Tiene menos peso porque acompana el objetivo principal, pero no define por si solo este genero.
Tareas recientes
Programación
Implementar un planificador de tareas basado en dependencias en Python
Escribe una función o clase en Python que programe una lista de tareas en función de sus dependencias. El planificador debe determinar el orden en que las tareas pueden ejecutarse, agrupando las tareas que pueden ejecutarse en paralelo. La entrada será una lista de diccionarios, donde cada diccionario representa una tarea con las siguientes claves: - `id`: Un identificador único de tipo cadena para la tarea. - `name`: Un nombre de tipo cadena para la tarea. - `dependencies`: Una lista de IDs (cadenas) de tareas que deben completarse antes de que esta tarea pueda comenzar. Tu implementación debe: 1. Recibir la lista de diccionarios de tareas como entrada. 2. Devolver un plan de ejecución válido como una lista de listas. Cada lista interna representa un "lote" de tareas que pueden ejecutarse concurrentemente. El orden de los lotes representa el orden de ejecución secuencial. El orden de los IDs de tareas dentro de un lote no importa. 3. Detectar y manejar dependencias circulares. Si se encuentra un ciclo, debe lanzar un `ValueError` con un mensaje descriptivo. 4. Detectar y manejar casos donde un ID de dependencia no corresponde a ninguna tarea existente. Esto también debe lanzar un `ValueError`.
Programación
Limitador de tasa con ventana deslizante y tolerancia a ráfagas
Diseña e implementa un limitador de tasa seguro para hilos en un lenguaje de tu elección (Python, Go, Java, TypeScript o Rust) que admita los siguientes requisitos: 1. **Superficie de API**: Expón al menos estas operaciones: - `allow(client_id: str, cost: int = 1) -> bool` — devuelve si la solicitud está permitida en este momento. - `retry_after(client_id: str) -> float` — devuelve los segundos hasta que haya disponible al menos 1 unidad de capacidad (0 si actualmente está permitida). - Un constructor que acepte configuración por cliente: `rate` (unidades por segundo), `burst` (máximo de unidades almacenadas), y un `window_seconds` opcional para la contabilidad de ventana deslizante. 2. **Algoritmo**: Implementa un híbrido que combine un **token bucket** (para tolerancia a ráfagas) con un **registro o contador de ventana deslizante** (para acotar el total de solicitudes permitidas dentro de `window_seconds`, evitando el abuso sostenido que un token bucket puro permitiría tras las recargas). Una solicitud se permite solo si ambas comprobaciones se superan. Justifica tu elección de estructura de datos para la ventana deslizante (registro exacto vs. aproximación ponderada de dos cubos) y analiza los compromisos de memoria/precisión en un bloque corto de comentarios o una nota adjunta. 3. **Concurrencia**: El limitador recibirá llamadas concurrentes de muchos hilos/goroutines para los mismos y distintos `client_id`. Evita que un único bloqueo global se convierta en un cuello de botella (p. ej., bloqueos por cliente o lock striping). Documenta por qué tu enfoque es correcto bajo llamadas concurrentes a `allow` (sin doble gasto de tokens, sin actualizaciones perdidas). 4. **Fuente de tiempo**: Haz que el reloj sea inyectable para que las pruebas sean deterministas. Usa por defecto un reloj monotónico. 5. **Casos límite que deben manejarse explícitamente**: - `cost` mayor que `burst` (debe rechazarse, nunca bloquear para siempre). - El reloj retrocede o hay pausas largas (p. ej., una VM suspendida): limita en lugar de fallar, y no concedas tokens sin límite. - Primera solicitud de un cliente nuevo (inicialización diferida). - Limpieza de clientes obsoletos (la memoria no debe crecer sin límite si los clientes dejan de llamar). - Tokens fraccionales / temporización por debajo del milisegundo. 6. **Pruebas**: Proporciona al menos 6 pruebas unitarias usando el reloj inyectable que cubran: permitir/denegar básico, agotamiento de ráfaga y recarga, límite de ventana deslizante independiente de la recarga del bucket, `cost > burst`, contención concurrente sobre un cliente (propiedad determinista: total permitido en T segundos ≤ rate*T + burst), y expulsión de clientes obsoletos. 7. **Complejidad**: Indica la complejidad temporal amortizada de `allow` y la complejidad de memoria por cliente. Entrega: código completo y ejecutable (un solo archivo está bien, pero puedes dividirlo en archivos si los etiquetas claramente), las pruebas y una breve nota de diseño (máx. ~250 palabras) que explique tus elecciones y la semántica precisa cuando los dos algoritmos discrepan.
Programación
Convertidor de un subconjunto de Markdown a HTML
Escribe una función en Python `markdown_to_html(markdown_text: str) -> str` que convierta una cadena que contiene un subconjunto específico de Markdown en su representación HTML correspondiente. La función debe soportar las siguientes características: **Elementos de bloque:** 1. **Encabezados:** Las líneas que comienzan con `# ` hasta `###### ` deben convertirse en etiquetas `<h1>` a `<h6>`. 2. **Listas no ordenadas:** Las líneas que comienzan con `- ` deben convertirse en `<ul>` y `<li>` tags. Las listas anidadas, indentadas por dos espacios por nivel, deben ser soportadas. Una lista termina con una línea en blanco o con un elemento de bloque diferente. 3. **Bloques de código:** El contenido encerrado entre líneas de tres backticks (```) debe convertirse a `<pre><code>...</code></pre>`. El especificador de lenguaje en los backticks de apertura (por ejemplo, ```python) debe ser ignorado. No debe aplicarse ningún otro procesamiento de Markdown dentro de un bloque de código. 4. **Párrafos:** Cualquier otro texto debe envolverse en etiquetas `<p>`. Líneas consecutivas de texto pertenecen al mismo párrafo. Los párrafos se separan por una o más líneas en blanco. **Elementos en línea:** 1. **Negrita y cursiva:** `***text***` debe convertirse en `<strong><em>text</em></strong>`. 2. **Negrita:** `**text**` debe convertirse en `<strong>text</strong>`. 3. **Cursiva:** `*text*` debe convertirse en `<em>text</em>`. **Reglas y restricciones:** - Los elementos en línea pueden anidarse dentro de encabezados y elementos de lista. - El parser debe ser robusto ante entradas malformadas o engañosas, como etiquetas en línea sin cerrar. Por ejemplo, `*italic` debe renderizarse como `<p>*italic</p>`. - El orden de precedencia para los elementos en línea es `***`, luego `**`, luego `*`. - Asuma que la entrada es una única cadena con varias líneas. - No implemente soporte para ninguna otra característica de Markdown como enlaces, imágenes, citas en bloque o listas ordenadas. - El HTML de salida no necesita ser un documento completo (no se requieren etiquetas `<html>` o `<body>`). Ejemplo de entrada: ```markdown # Header 1 This is a paragraph with **bold** and *italic* text. This is the same paragraph. - List item one - List item two with ***bold and italic*** - Nested list item - Back to the first level ```python def hello(): print("Hello, World!") ``` ```
Programación
Implementar un limitador de tasa Token Bucket seguro para subprocesos en Python
Escribe una clase en Python llamada `TokenBucketRateLimiter` que implemente el algoritmo Token Bucket para limitar la tasa. La implementación debe ser segura para subprocesos (thread-safe) y no debe usar ninguna biblioteca externa para la gestión del estado (como Redis). La clase debe tener las siguientes especificaciones: 1. Un `__init__(self, capacity, refill_rate)` método: * `capacity`: El número máximo de tokens que el cubo puede contener. * `refill_rate`: El número de tokens que se añaden al cubo por segundo. 2. Un `consume(self, tokens)` método: * Este método intenta consumir un número dado de `tokens` del cubo. * Debe devolver `True` si los tokens pueden consumirse con éxito, y `False` en caso contrario. * Antes de intentar consumir, el cubo debe rellenarse con tokens en función del tiempo transcurrido desde la última llamada. 3. Seguridad para subprocesos: * La clase debe ser segura para usarse desde múltiples hilos concurrentes. Todas las operaciones que modifican el estado del cubo (como rellenar y consumir tokens) deben ser atómicas. Proporcione la implementación completa de la clase con las importaciones necesarias.
Programación
Herramienta de sincronización de archivos desde la línea de comandos
Escribe un script en Python para una herramienta de sincronización de archivos desde la línea de comandos. El script debe aceptar tres argumentos de línea de comandos: 1. `source_path`: La ruta al directorio fuente. 2. `replica_path`: La ruta al directorio réplica que se sincronizará. 3. `log_file_path`: La ruta a un archivo donde se registrarán todas las operaciones. Funcionalidad principal: 1. **Sincronización unidireccional:** La herramienta debe realizar una sincronización unidireccional, haciendo que el directorio `replica_path` sea una copia exacta del directorio `source_path`. - Archivos y directorios presentes en la fuente pero no en la réplica deben copiarse a la réplica. - Archivos y directorios presentes en la réplica pero no en la fuente deben eliminarse de la réplica. - Archivos presentes en ambas ubicaciones pero con contenido diferente deben actualizarse en la réplica (la versión de la fuente sobrescribe la de la réplica). 2. **Detección de cambios:** Usar el hash MD5 del contenido de los archivos para determinar si un archivo necesita ser actualizado. No confiar en las marcas de tiempo de modificación. 3. **Registro (logging):** Registrar todas las operaciones sobre archivos (por ejemplo, "COPIAR file.txt", "ELIMINAR old_dir", "ACTUALIZAR changed.log") tanto en la consola como en el archivo de registro especificado. Cada entrada de registro debe llevar una marca de tiempo. 4. **Ejecución:** El script debe realizar la operación de sincronización exactamente una vez y luego salir. No debe ejecutarse en un bucle. Requisitos: - Usar Python 3. - Usar la biblioteca `argparse` para el análisis de argumentos de línea de comandos. - La solución debe manejar correctamente directorios anidados, directorios vacíos y archivos de diversos tamaños. - El script debe ser un único archivo autocontenido.
Programación
Implementar una caché LRU concurrente sin bloqueo global
Implementa una caché LRU (Least Recently Used) segura para subprocesos en Python que admita lecturas y escrituras concurrentes sin usar un bloqueo global para cada operación. Tu implementación debe cumplir los siguientes requisitos: 1. **Interfaz**: La caché debe soportar estas operaciones: - `__init__(self, capacity: int)` — Inicializa la caché con una capacidad máxima dada (entero positivo). - `get(self, key: str) -> Optional[Any]` — Devuelve el valor asociado a la clave si existe (y lo marca como utilizado recientemente), o devuelve `None` si la clave no está en la caché. - `put(self, key: str, value: Any) -> None` — Inserta o actualiza el par clave-valor. Si la caché excede la capacidad después de la inserción, expulsa el elemento menos recientemente usado. - `delete(self, key: str) -> bool` — Elimina la clave de la caché. Devuelve `True` si la clave estaba presente, `False` en caso contrario. - `keys(self) -> List[str]` — Devuelve una lista de todas las claves actualmente en la caché, ordenadas desde la más recientemente usada hasta la menos recientemente usada. 2. **Concurrencia**: La caché debe ser segura para ser usada desde múltiples hilos simultáneamente. Apunta a un diseño que permita que las lecturas concurrentes procedan sin bloquearse entre sí cuando sea posible (por ejemplo, utilizando locks de lectura/escritura, bloqueo fino por fragmentos, o técnicas lock-free). Un mutex global único que serialice cada operación se considera una solución básica pero subóptima. 3. **Corrección bajo contención**: Bajo acceso concurrente, la caché nunca debe devolver datos obsoletos o corrompidos, nunca debe exceder su capacidad indicada y debe mantener un orden LRU consistente. 4. **Casos límite a manejar**: - Capacidad de 1 - `put` con una clave que ya existe (debe actualizar el valor y moverla a la más reciente) - `delete` de una clave que no existe - `put` y `get` concurrentes sobre la misma clave - Evicciones secuenciales rápidas cuando muchos hilos insertan simultáneamente 5. **Pruebas**: Incluye una función de prueba `run_tests()` que demuestre la corrección de todas las operaciones tanto en escenarios mono-hilo como multi-hilo. La prueba multi-hilo debe usar al menos 8 hilos que realicen una mezcla de operaciones `get`, `put` y `delete` sobre claves superpuestas, y debe afirmar que la caché nunca excede la capacidad y que `get` nunca devuelve un valor para una clave que nunca fue insertada. Proporciona tu implementación completa en Python. Usa únicamente la biblioteca estándar (sin paquetes de terceros). Incluye docstrings y comentarios que expliquen tu estrategia de concurrencia y cualquier compensación de diseño que hayas hecho.