Programación
Compara la corrección, la calidad y la utilidad práctica del código generado.
En este género, las capacidades que más se intentan medir son Corrección, Integridad, Calidad del código.
A diferencia de system design, aquí pesa más si el código realmente funciona que las decisiones de arquitectura de alto nivel.
Una puntuación alta aquí no garantiza mejor juicio de producto, mejor arquitectura ni mejores explicaciones para principiantes.
Para qué sirve un modelo fuerte en este género
implementación, depuración, refactorización y apoyo práctico al programar.
Lo que este género por sí solo no alcanza a mostrar
si el modelo es mejor para arquitectura, documentos para stakeholders o ideación abierta.
Programación: Claude Fable 5 debuta en lo más alto, GPT-5 mini es la elección más defendible
Anthropic
OpenAI
OpenAI
Puntuación media por modelo
Cómo ponderamos
Claude Fable 5 llegó a este género y se llevó de inmediato el primer puesto, ganando su duelo inicial con la actuación más sólida de la tabla. GPT-5.6 también ha ganado todo lo que ha disputado hasta ahora. Ambos registros son a la vez impresionantes y escasos: un debut ganador demuestra que un modelo puede ganar aquí, no que vaya a seguir haciéndolo. El orden exacto de la cima debe leerse como una señal temprana.
El registro más defendible del género pertenece a GPT-5 mini: ha afrontado más encargos de programación que cualquiera de los líderes y no ha perdido ninguno. Para un modelo de gama ligera, una racha invicta frente a rivales de frontera es la mejor historia de valor de esta tabla. GPT-5.5, en cambio, firma una de las mejores medias del género pero ha repartido sus duelos — buen código que no siempre venció al código de enfrente. Claude Sonnet 5 logró una media sólida en su estreno y aun así lo perdió, de modo que su posición infravalora por ahora la calidad de su salida.
La corrección domina la evaluación aquí, con la completitud y la calidad del código después, así que la clasificación castiga los bugs sutiles con más dureza que el estilo. La familia Gemini aún no ha convertido ningún enfrentamiento en este género y también ocupa el fondo en medias. Todo esto refleja las tareas y jueces concretos de Orivel: la programación abarca desde algoritmos hasta diseño de API, y un puñado de encargos no puede cubrir ese espacio.
En resumen
GPT-5 mini es la elección defendible hoy — invicto en el mayor número de duelos y a coste de gama ligera. Claude Fable 5 y GPT-5.6 parecen aún más fuertes, pero con evidencia temprana. Atención a si GPT-5.5 empieza a convertir sus respuestas de calidad en victorias.
Este análisis se basa en las puntuaciones de benchmark medidas por Orivel para este género y se actualiza periódicamente. Las puntuaciones son medidas que dependen de las condiciones, no una verdad absoluta.
Ranking de modelos fuertes en este género
Este ranking se ordena por la puntuación media solo dentro de este género.
Última actualización: 25 Jul 2026 01:19
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
| Modelos clasificados | Detalle | ||||||
|---|---|---|---|---|---|---|---|
| #1 | Claude Fable 5 | Anthropic |
100%
|
91
|
1 | 1 | Ver la evaluación y la puntuación de Claude Fable 5 |
| #2 | GPT-5.6 | OpenAI |
100%
|
86
|
2 | 2 | Ver la evaluación y la puntuación de GPT-5.6 |
| #3 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Ver la evaluación y la puntuación de GPT-5 mini |
| #4 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | Ver la evaluación y la puntuación de GPT-5.5 |
| #5 | Claude Sonnet 5 NUEVO | Anthropic |
0%
|
83
|
0 | 1 | Ver la evaluación y la puntuación de Claude Sonnet 5 |
| #6 | Gemini 2.5 Pro |
0%
|
74
|
0 | 5 | Ver la evaluación y la puntuación de Gemini 2.5 Pro | |
| #7 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver la evaluación y la puntuación de Gemini 2.5 Flash-Lite | |
| #8 | Gemini 2.5 Flash |
0%
|
68
|
0 | 5 | Ver la evaluación y la puntuación de Gemini 2.5 Flash |
Qué se evalúa en Programación
Criterios y pesos usados para este ranking por género.
Corrección
35.0%
Este criterio se incluye para comprobar Corrección en la respuesta. Tiene más peso porque este aspecto cambia mucho el resultado global del género.
Integridad
20.0%
Este criterio se incluye para comprobar Integridad en la respuesta. Tiene un peso importante porque afecta a la calidad de forma visible, aunque no sea lo único que importa.
Calidad del código
20.0%
Este criterio se incluye para comprobar Calidad del código en la respuesta. Tiene un peso importante porque afecta a la calidad de forma visible, aunque no sea lo único que importa.
Valor práctico
15.0%
Este criterio se incluye para comprobar Valor práctico en la respuesta. Tiene menos peso porque acompaña al objetivo principal, pero no define por sí solo este género.
Seguimiento de instrucciones
10.0%
Este criterio se incluye para comprobar Seguimiento de instrucciones en la respuesta. Tiene menos peso porque acompaña al objetivo principal, pero no define por sí solo este género.
Tareas recientes
Programación
Analizador de registros del servidor web
Escriba una función de Python analyze_logs(log_data) que reciba una cadena multilínea que contenga entradas de registro del servidor web. La función debe analizar estos registros, realizar un análisis y devolver un diccionario que resuma los resultados. Cada línea de registro válida sigue este formato: [TIMESTAMP] LEVEL IP_ADDRESS "REQUEST_METHOD /path" RESPONSE_CODE BYTES_SENT Ejemplo de una línea válida: [2023-10-27T10:00:00Z] INFO 192.168.1.1 "GET /index.html" 200 1543 Su función debe: Analizar únicamente las líneas de registro válidas, ignorando de forma elegante cualquier línea malformada o vacía. Calcular las siguientes métricas: total_requests: El recuento total de entradas de registro válidas. error_rate: El porcentaje de solicitudes con un LEVEL de ERROR, redondeado a dos decimales. top_3_ips: Una lista de tuplas, donde cada tupla contiene una dirección IP y su recuento de solicitudes, para las 3 IP más frecuentes. La lista debe estar ordenada en orden descendente por recuento de solicitudes. busiest_hour: La hora del día (un entero de 0 a 23) que tuvo más solicitudes. La marca de tiempo está en formato ISO 8601 (UTC). Devolver un diccionario con las claves total_requests, error_rate, top_3_ips y busiest_hour que contenga los valores calculados. Maneje los siguientes casos límite: Si la cadena de entrada log_data está vacía, devuelva un diccionario con valores a cero o vacíos según corresponda (por ejemplo, total_requests: 0, top_3_ips: []). Si hay menos de 3 direcciones IP únicas, la lista top_3_ips debe contener todas las IP únicas, ordenadas por recuento. Si hay un empate por la hora con más actividad, es aceptable devolver cualquiera de las horas empatadas.
Programación
Limitador de tasa con ventana deslizante y cuotas justas multi-tenant
Implementa una biblioteca reutilizable de limitación de tasa en un lenguaje de tu elección (Python, Go, TypeScript, Java o Rust) que haga cumplir cuotas de solicitudes por cliente usando un algoritmo de ventana deslizante, además de una política de reparto justo entre múltiples tenants. Requisitos funcionales: Proporciona una clase o módulo con un método como allow(tenant_id, client_id, now_ms) que devuelva si una solicitud está permitida y, cuando se deniegue, cuántos milisegundos faltan hasta que se permita la siguiente solicitud (retry_after_ms). Cada cliente está limitado a un número máximo de solicitudes dentro de una ventana de tiempo deslizante (por ejemplo, 100 requests per 60,000 ms). La configuración debe ser ajustable por tenant. Implementa una verdadera ventana deslizante (ponderada o basada en registro), no una ventana de cubos fijos por calendario, de modo que los picos que cruzan los límites de los cubos se manejen correctamente. Añade un límite global por tenant de modo que todos los clientes de un tenant combinados no puedan exceder un techo a nivel de tenant, y cuando el tenant esté saturado, la capacidad restante se comparta de forma justa entre los clientes activos en lugar de ser monopolizada por un solo cliente. El limitador debe ser seguro bajo acceso concurrente desde múltiples hilos o tareas async. La memoria no debe crecer de forma ilimitada: el estado obsoleto de clientes debe expulsarse o compactarse con el tiempo. Entregables: La implementación completa con una API pública clara y documentación en línea de las decisiones clave. Una breve explicación (en comentarios o una sección en prosa corta) del algoritmo de ventana deslizante que elegiste y sus concesiones de precisión/memoria. Un conjunto de pruebas que cubra los casos límite principales descritos a continuación. Casos límite a tratar explícitamente en el código y las pruebas: Solicitudes exactamente en el límite de la ventana. Un cliente que queda inactivo y luego vuelve después de que la ventana haya transcurrido por completo. Solicitudes concurrentes en carrera contra el mismo contador de cliente. Reloj que va hacia atrás o marcas de tiempo duplicadas. Saturación del tenant y redistribución justa entre clientes en competencia. Expulsión de estado obsoleto de clientes sin eliminar clientes activos. Indica cualquier suposición que hagas (single-process vs distributed, disponibilidad de reloj monotónico, etc.). Si asumes un solo proceso, describe brevemente cómo se extendería el diseño a un despliegue distribuido.
Programación
Implementar un simulador determinista de libro de órdenes límite
Escribe una solución de un solo archivo en Python 3.11 que implemente la función process_events(events: list[dict]) -> dict. No uses paquetes externos. La función debe simular un pequeño libro de órdenes límite de un intercambio para un único instrumento. Recibe una lista de diccionarios de eventos en el orden de entrada y devuelve un diccionario con exactamente estas claves: trades, rejected, book. Tipos de evento: Evento de nueva orden: Required fields: type="new", id, side, order_type, qty. side es "buy" o "sell". order_type es "limit" o "market". qty es un entero positivo. Una orden limit también requiere price, un número entero positivo de céntimos. Campo opcional tif es time-in-force: "GTC", "IOC", o "FOK". Si está ausente, use "GTC" para órdenes limit y "IOC" para órdenes market. Las órdenes market no pueden tener tif="GTC" y no pueden quedarse en el libro. Evento de cancelación: Required fields: type="cancel", id. Cancela la cantidad restante de una orden resting actualmente en el libro con ese id. Reglas de emparejamiento: El libro tiene bids y asks. Las órdenes limit de compra resting son bids; las órdenes limit de venta resting son asks. La prioridad precio-tiempo es obligatoria: mejor precio primero; para el mismo precio, la orden resting aceptada antes va primero. Una orden buy casa con asks resting mientras pueda cruzar: una market buy cruza cualquier ask; una limit buy cruza asks con ask price <= buy limit price. Una orden sell casa con bids resting mientras pueda cruzar: una market sell cruza cualquier bid; una limit sell cruza bids con bid price >= sell limit price. La cantidad de cada trade es min(cantidad restante del entrante, cantidad restante del resting). El precio del trade es siempre el price limit de la orden maker resting, nunca el precio de la orden entrante. Debe adjuntarse inmediatamente un registro de trade cuando ocurra, con exactamente estas claves: buy_id, sell_id, price, qty, taker_id, maker_id. Las órdenes resting parcialmente ejecutadas conservan su prioridad original con la cantidad restante. Las órdenes completamente ejecutadas salen del libro. Comportamiento time-in-force: Las órdenes limit GTC descansan (rest) cualquier resto no ejecutado en el libro. Las órdenes IOC se ejecutan tanto como sea posible inmediatamente, luego cancelan cualquier resto. Las órdenes FOK deben ser completamente llenables inmediatamente según el libro actual y las reglas de cruce. Si no son completamente llenables, no producen trades y no cambian el libro. Si son completamente llenables, se ejecutan normalmente. Las órdenes FOK nunca descansan en el libro. Reglas de validación y rechazo: Si un evento está malformado, recházalo sin cambiar el libro. Adjunta un registro de rechazo a rejected con claves input_index, event, reason. La reason puede ser una cadena corta y legible por humanos. Rechaza una nueva orden si su id ya fue usado por cualquier orden new previamente aceptada, incluso si esa orden anterior ya se ejecutó por completo o fue cancelada. Rechaza eventos cancel para ids desconocidos o ids que ya no estén resting. Rechaza qty y price que no sean enteros, cero o negativos. En Python, bool no debe ser aceptado como entero para estos campos. Ignora campos extra en eventos que por lo demás sean válidos. Formato de retorno: trades: lista de registros de trade en orden de ejecución. rejected: lista de registros de rechazo en orden de entrada. book: un diccionario con claves bids y asks. book["bids"] debe listar todos los bids resting ordenados por precio descendente, luego por tiempo de resting original, cada uno como {"id": id, "price": price, "qty": remaining_qty}. book["asks"] debe listar todos los asks resting ordenados por precio ascendente, luego por tiempo de resting original, cada uno como {"id": id, "price": price, "qty": remaining_qty}. Tu respuesta debe ser código Python ejecutable completo que defina process_events. Puedes incluir clases/funciones auxiliares y una pequeña sección de auto-prueba protegida por if name == "main":, pero la función principal no debe leer desde stdin ni escribir en stdout.
Programación
Implementar la aplicación atómica de JSON Patch en Python
Escribe una implementación en Python 3.11 de una función llamada apply_json_patch(document, patch) que aplique una secuencia de operaciones al estilo JSON Patch a un valor compatible con JSON y devuelva el valor parcheado. El documento de entrada puede ser cualquier combinación de dict, list, str, int, float, bool y None. El parche es una lista de diccionarios de operaciones. La implementación no debe mutar el documento original ni ningún objeto anidado accesible desde él. Si alguna operación es inválida, la función debe lanzar una excepción personalizada llamada JsonPatchError y dejar el documento original sin cambios. Las operaciones soportadas son add, remove, replace, move, copy y test. Usa rutas JSON Pointer con tokens separados por barras (slash), donde la cadena vacía identifica el documento entero, los tokens decodifican ~1 como / y ~0 como ~, y cualquier otro uso de ~ es inválido. Para objetos, un token de ruta es una clave. Para arrays, un token de ruta debe ser un entero no negativo sin ceros a la izquierda excepto el token único 0; solo para add, el token final puede ser - para añadir al final. La operación add inserta en arrays en un índice de 0 hasta len(array), añade al final con '-', establece una clave en un objeto, o reemplaza el documento completo si la ruta es la cadena vacía. La operación remove requiere que el objetivo exista y lo elimina. La operación replace requiere que el objetivo exista y lo reemplaza. La operación move requiere from y path, elimina el valor en from y lo añade en path, y debe rechazar mover un valor dentro de uno de sus propios descendientes. La operación copy requiere from y path y copia profundamente (deep-copy) el valor de origen al destino. La operación test requiere value y tiene éxito solo si el objetivo actual es igual en profundidad a value, incluyendo la igualdad normal de Python para números y la igualdad exacta para cadenas, booleanos y None. Cada diccionario de operación debe contener exactamente los campos requeridos para esa operación además del campo op; campos desconocidos o faltantes son errores. La función debe ser determinista, razonablemente eficiente y depender únicamente de la biblioteca estándar de Python. Incluye cualquier función o clase auxiliar necesaria. No escribas un programa de línea de comandos ni uses paquetes externos.
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: Recibir la lista de diccionarios de tareas como entrada. 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. Detectar y manejar dependencias circulares. Si se encuentra un ciclo, debe lanzar un ValueError con un mensaje descriptivo. 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: 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. 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. 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). Fuente de tiempo: Haz que el reloj sea inyectable para que las pruebas sean deterministas. Usa por defecto un reloj monotónico. 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. 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. 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.