El Juez Ciego: Puntuando Claude Code vs Codex en 36 Duelos

Thomas Ricouard (@Dimillian) lo expresó mejor que cualquier benchmark: “Claude Code es como una refactorización bastante mediocre que sé que puede ejecutar. Codex es una arquitectura de vanguardia. Aún no estoy seguro de si realmente puede hacerlo sin romper cosas.”¹

Dejé de preguntarme y empecé a medir. Construí un sistema que enfrenta a Claude Code contra Codex CLI en la misma tarea, etiqueta las salidas aleatoriamente como Alpha y Beta, y puntúa ambos planes a ciegas en cinco dimensiones antes de revelar qué agente escribió cuál. Treinta y seis duelos después, el marcador dice que Claude ganó 8 de 12 duelos decididos. Pero el marcador no es lo importante. Lo importante es lo que el juez ciego produce después de puntuar: una síntesis que combina los elementos más fuertes de ambos planes en algo mejor de lo que cualquiera de los dos contendientes entregó por separado.

TL;DR

Treinta y seis duelos. Evaluación ciega en cinco dimensiones (Corrección, Completitud, Simplicidad, Descomposición, Accionabilidad). Claude Code ganó 8, Codex CLI ganó 3, uno indeciso, a lo largo de 13 duelos con manifiestos de juicio estructurados (12 con un ganador declarado). El resultado real no es un ganador. Es el paso de síntesis que selecciona los mejores elementos de ambos planes y produce un informe de implementación más fuerte que cualquiera de los dos agentes por separado. El artículo complementario Pensando Con Diez Cerebros cubre la deliberación colaborativa.¹² El juez ciego cubre la evaluación competitiva. La metodología importa más que el marcador.

Por qué la comparación es difícil

Todo el mundo está comparando agentes de codificación con IA en este momento. Nadie se pone de acuerdo en los resultados.

El problema es estructural. Las comparaciones de modelos se degradan en tres ejes: impresiones subjetivas (probó una tarea en cada uno y siguió su instinto), sesgo de recencia (el último éxito sobrescribe todos los fracasos anteriores) y fortalezas específicas por tarea (el modelo que gana en su tarea de refactorización pierde en su revisión de seguridad). Estas no son malas observaciones. Son malos experimentos.

Alex Finn (@AlexFinn) ejecuta un flujo de validación dual donde dos modelos verifican la salida del otro.² El enfoque de verificación dual detecta errores que cualquiera de los modelos por separado pasaría por alto. La idea es sólida: la evaluación independiente revela desacuerdos, y los desacuerdos son donde se esconden los errores.

@doodlestein ejecuta más de 10 agentes simultáneamente — Claude, Codex y Gemini — usando prompts predefinidos que llama “magos de ideas” para atacar el mismo problema desde diferentes ángulos.³ Un planificador que sobresale en descomposición podría pasar por alto un error de corrección que un agente más orientado al detalle detecta de inmediato.

Ambos flujos mejoran respecto a la evaluación de un solo modelo. Ninguno elimina la mayor amenaza: el sesgo de confirmación. Si sabe qué modelo escribió qué plan, puntuará más generosamente al modelo en el que más confía. Siempre. No porque sea descuidado, sino porque el sesgo opera por debajo de la conciencia. La pieza faltante es el cegamiento. Si el evaluador no sabe qué agente produjo qué salida, el sesgo de confirmación no tiene a qué aferrarse.

El Protocolo de Evaluación Ciega

El sistema /duel funciona en cinco fases:

1. Ejecución en paralelo. Ambos agentes reciben el mismo prompt de tarea y contexto del proyecto. Claude Code se ejecuta en un proceso, Codex CLI en otro. Ninguno ve la salida del otro.
2. Etiquetado aleatorio. Un lanzamiento de moneda asigna un agente a “Alpha” y el otro a “Beta”. El sistema escribe el mapeo en agent-mapping.json y lo sella. Ni el juez ni yo vemos el mapeo hasta después de la puntuación.
3. Puntuación ciega. Un agente juez lee ambos planes y puntúa cada uno en cinco dimensiones, de 0 a 4 por dimensión, máximo 20 puntos en total. El juez solo ve “plan Alpha” y “plan Beta”.
4. Recomendación del ganador. El juez declara un ganador (o indeciso) con un nivel de confianza y razonamiento escrito.
5. Síntesis. El juez combina los elementos más fuertes de ambos planes en un informe de implementación refinado. La síntesis es el resultado real.

Las cinco dimensiones de puntuación:

La decisión de diseño clave: la síntesis no es una mezcla 50/50. Pondera fuertemente la estrategia central del ganador mientras selecciona ideas genuinas del perdedor. Los primeros intentos de síntesis con peso igualitario produjeron planes incoherentes que heredaban las peores propiedades de ambos. La síntesis ponderada produce planes que son estructuralmente sólidos (del ganador) y completamente reforzados (de los casos límite válidos del perdedor).

Caso de Estudio: El Duelo de Remediación de Seguridad

En febrero de 2026, una auditoría de seguridad con tres agentes encontró 7 hallazgos CRÍTICOS y 7 ALTOS en ResumeGeni, una aplicación FastAPI con autenticación Supabase y pagos con Stripe.⁴ Ya había desplegado dos correcciones triviales. Quedaban nueve. Ejecuté un duelo para generar el plan de remediación.

Ambos agentes recibieron el mismo informe: la lista de hallazgos con rutas de archivos y números de línea, el contexto de arquitectura, la restricción de que un patrón de corrección probado ya existía en un archivo, y el requisito de producir un plan de despliegue por fases.

Plan de Alpha: 11 historias para 9 hallazgos, organizadas en tres oleadas de despliegue. Una historia de línea base de pruebas (SEC-01) bloqueaba todo el trabajo posterior. Puertas de despliegue con métricas específicas: tasa de éxito de autenticación, monitoreo de 5xx, conteo de rechazos de webhooks. Discusión exhaustiva de alternativas descartadas. Las historias usaban una estructura Qué/Por qué/Éxito con rangos de líneas.

Plan de Beta: Mapeo directo 1:1 de hallazgos a historias. Tres oleadas de despliegue: Críticos como una unidad única, Alta prioridad como desplegables independientes, Limpieza. Investigación antes de corrección para el hallazgo del middleware. Números de línea específicos, nombres de funciones, rutas de importación y comandos curl para verificación por historia.

La brecha de corrección contó la historia. Beta detectó dos cosas que Alpha pasó por alto completamente.

Primero: el hallazgo del middleware (C3) señaló get_user(jwt=...) como un vector de contaminación de sesión. Beta identificó correctamente que get_user() es una llamada de verificación sin estado. gotrue-py solo llama a _save_session() en verify_otp y exchange_code_for_session, no en get_user. Alpha lo trató como algo que definitivamente necesitaba la misma corrección que los otros dos routers, lo que añadiría sobrecarga innecesaria por solicitud en cada petición autenticada. Beta dijo: investigar primero, corregir solo si se confirma.

Segundo: los routers de magic link y passkeys usan tanto admin.generate_link() (que requiere el singleton SERVICE_KEY) como verify_otp() (que necesita un cliente fresco por solicitud). El plan de Alpha aplicó el patrón de cliente fresco de manera uniforme. Un implementador que siguiera ese plan rompería las operaciones de administración. Beta señaló explícitamente la división: cliente fresco para verify_otp, singleton compartido para admin.generate_link().

Las puntuaciones:

Alpha era Codex. Beta era Claude. Alta confianza.⁴

La síntesis combinó la precisión técnica de Beta con el rigor operativo de Alpha. Aquí hay una historia del resultado de la síntesis, mostrando cómo fusionó ambos planes:

Historia 1.1 (C1 — Singleton compartido de Magic Link): En magic_link.py, agregar _create_auth_client(). Usar cliente anónimo fresco SOLO para verify_otp (línea 224). Mantener singleton compartido para admin.generate_link() (línea 213) que necesita SERVICE_KEY.

Esa historia hereda los números de línea precisos de Beta y la división crítica entre cliente admin/anón, envuelta en una estructura que encaja en la secuencia de despliegue de tres oleadas de Alpha. La síntesis completa mantuvo el enfoque de investigación primero de Beta para C3, los comandos curl de verificación específicos de Beta, las puertas de despliegue de Alpha (monitoreo de tasa de éxito de autenticación, seguimiento de 5xx) y la estrategia de pruebas de regresión de Alpha (suite E2E Playwright de autenticación después de la Oleada 1, webhook de prueba de Stripe después de la Oleada 2). El resultado: un plan de 3 oleadas con 12 historias, ejecutable en un día, con barandillas operativas que ninguno de los planes por separado proporcionaba.

El Marcador (y Por Qué Engaña)

A lo largo de 36 duelos, 13 produjeron manifiestos de juicio estructurados. Un manifiesto declaró indeciso, dejando 12 con un ganador claro:

Claude: 8. Codex: 3. Indeciso: 1.¹¹

No trate el marcador como un benchmark de modelos. No lo es.

Las victorias de Claude se concentran en tareas de revisión, verificación y seguridad: 7 de 8 victorias son de alta confianza en tareas que involucran revisión de código, análisis de seguridad o evaluación técnica. La única victoria de alta confianza de Codex fue en una tarea de revisión de código donde su rigurosidad procedimental y cadenas de dependencias explícitas superaron el enfoque menos estructurado de Claude. Las otras dos victorias fueron de baja confianza. El patrón: Claude produce planes más accionables y técnicamente precisos. Codex produce un proceso operativo más fuerte y una cobertura teórica más amplia.

Ricouard tenía razón. La calidad de planificación versus la confiabilidad de ejecución es un eje real.¹ Pero el marcador refleja mi mezcla de tareas (con énfasis en revisión de seguridad y arquitectura), no algún ranking objetivo de modelos. Alguien que ejecute duelos en desarrollo de funcionalidades desde cero o automatización de infraestructura probablemente vería resultados diferentes. El análisis de Nathan Lambert sobre la era post-benchmark hace el mismo argumento: los benchmarks tradicionales ya no transmiten una señal significativa cuando los márgenes finos entre Opus 4.6 y Codex 5.3 dependen de la forma de la tarea y la metodología de evaluación.¹⁰

El marcador dice algo sobre mi flujo de trabajo. No dice qué modelo es “mejor”.

La Síntesis Es el Producto

El plan ganador no es lo importante. La síntesis sí lo es.

Cada duelo produce tres artefactos: Plan Alpha, Plan Beta y la Síntesis. La síntesis sigue una estructura consistente: adoptar la estrategia central del ganador, incorporar los casos límite válidos del perdedor, eliminar alcance innecesario de ambos. No es diplomática. No divide la diferencia. Toma decisiones explícitas sobre qué elementos mantener y cuáles descartar, con justificación escrita para cada uno.

En el duelo de expansión del corpus de empleos, el plan de Claude activaba primero la infraestructura existente (scripts semilla para 8.780 tableros conocidos que el sistema aún no estaba consultando), luego expandía a nuevas plataformas ATS, y después construía sistemas de descubrimiento.⁶ El plan de Codex comenzaba con una auditoría del código base y una especificación de instrumentación antes de ingestar un solo empleo. Claude ganó en simplicidad y accionabilidad. Pero Codex identificó algo que Claude pasó por alto: la necesidad de una máquina de estados de ciclo de vida de tableros (activo/fallando/en cuarentena). Codex también señaló una auditoría de regresión de deduplicación para evitar que la expansión de volumen enmascarara una explosión de duplicados. La síntesis mantuvo la secuenciación de activar primero de Claude e incorporó la observabilidad y el seguimiento de ciclo de vida de Codex como Fase 1.5, después de que la siembra inicial entregara resultados medibles. El mismo patrón apareció en el duelo de diseño del sistema de ingestión de empleos, donde el plan de Claude reutilizó APScheduler existente y tablas de registro mientras Codex propuso un esquema de procedencia de dos tablas más exhaustivo. La síntesis adoptó la arquitectura pragmática de Claude y seleccionó la mejora de hash de deduplicación de Codex.⁷

En el duelo de revisión ATS, Claude encontró crasheos P0 en tiempo de ejecución (desajustes de firmas de métodos en el programador que romperían silenciosamente el seguimiento de empleos) que Codex pasó por alto completamente.⁵ Codex encontró prevención de solapamiento del programador y vectores de abuso de endpoints administrativos que Claude no señaló. La síntesis comenzó con las correcciones P0 de Claude y las complementó con el endurecimiento operativo de Codex.

El patrón a lo largo de 36 duelos: el modelo juez produce consistentemente síntesis más fuertes que el plan de cualquiera de los dos contendientes. El juez no es más inteligente. La estructura adversarial fuerza una cobertura completa.⁹ Cada agente identifica independientemente riesgos y casos límite. El juez los ve todos. La síntesis hereda la unión de las percepciones de ambos agentes menos sus puntos ciegos individuales.

El patrón se conecta con un hallazgo más amplio de la deliberación multiagente: la independencia es el mecanismo. Diez agentes de deliberación evaluando una decisión desde diferentes perspectivas detectan sesgos que cualquier agente individual pasaría por alto. Dos agentes en duelo atacando la misma tarea desde diferentes arquitecturas detectan brechas de implementación que cualquiera de los dos agentes por separado desplegaría. El paso de síntesis es el mismo en ambos sistemas: combinar evaluaciones independientes en un solo artefacto que se beneficia de todas las perspectivas.

Documento la capa de orquestación que soporta ambos sistemas por separado. Lo que importa aquí es que el duelo y la deliberación cumplen funciones complementarias. La deliberación responde “¿deberíamos construir esto?” El duelo responde “¿cuál es la forma más fuerte de construirlo?”

Cuándo Usar Duelos vs. Cuándo Deliberar

Ambos sistemas usan evaluación independiente y síntesis. Sirven para diferentes tipos de decisiones.

Mi patrón: deliberar el diseño, duelar el plan de implementación, ejecutar la síntesis.

Una decisión de remediación de seguridad pasa primero por deliberación (“¿Es esta la priorización correcta? ¿Estamos pasando por alto problemas sistémicos?”), luego por duelo (“¿Cuál es el plan por fases más fuerte para ejecutar estas correcciones?”), y luego ejecución a partir de la síntesis del juez. El sistema de deliberación y el sistema de duelo comparten infraestructura pero sirven propósitos distintos en el pipeline de decisiones.

Lo Que Hice Mal

Los primeros duelos no tenían etiquetado ciego. Leía ambos planes sabiendo qué modelo escribió cuál. El sesgo de confirmación era real y medible: consistentemente puntuaba más alto a Claude en Accionabilidad antes del cegamiento, y luego vi que la brecha se reducía (aunque no desaparecía) después de introducir la asignación aleatoria Alpha/Beta. El protocolo de cegamiento no es opcional.

Comencé con tres dimensiones de puntuación (Corrección, Completitud, Accionabilidad). Dos duelos después, me di cuenta de que estaba confundiendo la estructura del plan con el contenido del plan. Agregar Simplicidad (¿está sobreingeniado?) y Descomposición (¿están los pasos bien ordenados?) separó esas preocupaciones y produjo puntuaciones más útiles.

Los primeros intentos de síntesis mezclaban ambos planes por igual. Los resultados eran incoherentes: la estrategia de pruebas de Alpha injertada en la secuencia de despliegue de Beta, sin que las suposiciones de ninguno de los planes se sostuvieran. La síntesis ponderada, donde el juez adopta explícitamente el marco del ganador e incorpora selectivamente las ideas del perdedor, fue el avance decisivo.

N=36 en mi mezcla de tareas no es un benchmark de modelos. Es una evaluación de herramientas de flujo de trabajo. El sistema de duelo me dice qué agente produjo el plan más fuerte para mi tarea específica en mi código base específico. Extrapolar a “Claude es mejor que Codex” sería el mismo razonamiento basado en impresiones que el sistema existe para eliminar.

Uso Claude para juzgar duelos entre Claude y Codex. Reconozco el conflicto.⁸ La mitigación es estructural: etiquetado ciego, dimensiones estructuradas, y el hecho de que Codex ganó 3 duelos y estuvo cerca en varios otros. Una prueba más fuerte ejecutaría los mismos duelos a través de un juez que no sea Claude (Gemini o GPT) y compararía las distribuciones de puntuación. Aún no lo he hecho. Hasta que lo haga, la división 8-3 debería llevar un asterisco: el juez y uno de los contendientes comparten la misma familia de modelos.

Referencias