Cómo comparar de forma justa Claude Code y Codex con un encargo de animación

Dos vídeos atractivos no constituyen una comparación justa de dos agentes de programación. Uno puede haber recibido mejores recursos, instrucciones más detalladas, una ronda adicional de correcciones o acceso a herramientas que el otro no tenía. Una captura que los muestra uno junto al otro oculta esas diferencias.

En animación es especialmente fácil equivocarse al comparar. Un modelo puede producir un primer fotograma impresionante y, aun así, incumplir los tiempos exigidos. Otro puede crear un proyecto sencillo pero editable que resiste una modificación puntual. Cuál es mejor depende del trabajo que pretendías delegar.

Para comparar Claude Code y Codex en gráficos animados, empieza por la misma tarea de aceptación y los mismos recursos; después, comprueba el texto exacto, los tiempos, los controles y el esfuerzo de corrección necesario para obtener un resultado utilizable. El caso práctico sigue un resultado de Codex durante la reproducción, un fallo del control de desplazamiento temporal y su reparación. Claude Code no pudo autenticarse para la ejecución equivalente; la comparación entre modelos sigue pendiente.

Elige una tarea que revele la capacidad que necesitas

«Crea un vídeo de producto bonito» deja demasiado margen de interpretación. Una prueba mejor combina una necesidad de comunicación real con una entrega técnica acotada. Por ejemplo, crear una escena editable de una oferta de seis segundos, con un texto de precios exacto, desplazamiento temporal determinista y un intervalo de lectura compartido.

La escena puede ser visualmente sencilla y seguir poniendo a prueba comportamientos importantes. La exactitud del texto comprueba la conservación de los hechos. Una pausa estable comprueba el razonamiento temporal. Un control de desplazamiento comprueba si la animación depende del tiempo o de una secuencia que solo funciona al reproducirla desde el principio. Una modificación puntual comprueba si el código fuente sigue siendo controlable.

No sobrecargues la primera prueba con todas las funciones posibles. Si incluyes narración, música, subtítulos, datos de gráficos, varias relaciones de aspecto y una interfaz compleja, será difícil atribuir los fallos a una causa. Utiliza primero una tarea pequeña y representativa; después, añade una segunda para las capacidades que la primera no pueda revelar.

Decide si comparas la generación de código o los flujos completos de los agentes. Una prueba solo de código puede mantener constantes las herramientas desactivándolas y solicitando un documento autónomo. Una prueba del flujo de trabajo debe permitir que cada agente inspeccione los recursos, ejecute el proyecto y corrija errores con permisos comparables. Son experimentos distintos y no deberían mezclarse en una clasificación única.

Para un equipo que vaya a adoptar una herramienta, la prueba del flujo de trabajo suele ser más pertinente. El resultado útil no es únicamente código fuente, sino un artefacto correcto y editable, producido mediante un proceso viable. Aun así, una prueba más pequeña, solo de código, puede descubrir problemas de requisitos y de entorno antes de dedicar tiempo a una comparación mayor.

Fija el encargo y los recursos

Utiliza exactamente el mismo encargo en ambas ejecuciones. Guárdalo antes de invocar a cualquiera de los agentes. Si detectas una ambigüedad al ver el primer resultado, revisa el encargo para ambos y trata la nueva pareja como otra prueba, en lugar de aclarársela únicamente a uno.

En la prueba local que acompaña a este artículo, se solicitó un documento HTML autónomo de 1280 por 720. La escena ficticia se titulaba Still Studio y debía mostrar exactamente «US$29 per month» y «US$348 billed annually». Ambas líneas debían entrar entre los cero y los 0.8 segundos, permanecer estables hasta los 4.8 segundos y salir antes de los seis segundos.

El encargo también pedía controles visibles de Play/Pause y desplazamiento temporal, un tiempo inicial pausado de 2.4 segundos, tipografía sans serif del sistema, ningún recurso remoto y una etiqueta que identificara el estudio como ficticio. Estas restricciones permitían inspeccionar el resultado y evitaban diferencias provocadas por imágenes o fuentes externas.

El texto y la relación entre los importes de facturación son importantes. Un modelo que cambia el importe anual incumple un requisito factual, por atractiva que sea su tipografía. Un modelo que solo muestra la condición al final incumple un requisito temporal, aunque las palabras correctas figuren en el código fuente.

Si utilizas recursos reales de producto, proporciona copias idénticas y conserva su identidad. No permitas que un agente use una captura más reciente o un logotipo distinto. Si un recurso no puede redistribuirse, describe el requisito de acceso y mantén la comparación dentro del entorno autorizado.

Registra el entorno que se ejecutó realmente

El nombre de una herramienta no identifica el sistema completo. Registra la versión de la CLI, el modelo declarado por la ejecución, los ajustes relevantes, las herramientas disponibles, los permisos y si la sesión era nueva o continuada. El modelo predeterminado puede cambiar con el tiempo, por lo que importa más el modelo declarado que una suposición basada en el nombre del producto.

Separa el acceso a la cuenta del rendimiento del modelo. Un inicio de sesión fallido, un límite de uso o una interrupción de red pueden afectar al flujo de trabajo práctico, pero no revelan la calidad de un vídeo que el modelo nunca llegó a producir. Conserva esos fallos en el registro sin convertirlos en una puntuación creativa.

La ejecución de Codex utilizó autenticación de ChatGPT a través del proveedor OpenAI. Su registro identifica la versión 0.163.0 de la CLI y el modelo gpt-6.1-sol; el resultado es un documento HTML independiente.

La autenticación y la configuración requieren atención explícita porque pueden seleccionar distintas vías de acceso. Consulta la documentación de la propia herramienta y conserva la vía utilizada realmente; no expongas tokens ni archivos privados de cuenta en un paquete de evaluación. Documentación de autenticación de Claude Code

Conserva los resultados originales antes de repararlos

Guarda la primera respuesta exactamente como la recibiste, junto con el encargo y el estado de la ejecución. Si necesitas quitar las delimitaciones de Markdown para abrir un documento HTML, registra esa transformación. No repares la sintaxis en silencio para luego presentar el resultado como el primer borrador original.

Guarda las solicitudes fallidas por separado de los artefactos terminados, de modo que el registro distinga los fallos de configuración de los defectos del resultado.

Para comparar únicamente código, abre el documento devuelto sin editarlo. Comprueba si aparecen las palabras exigidas, si la escena carga sin dependencias remotas y si están presentes los controles. Después, reproduce la secuencia completa y desplázate directamente a su entrada, su pausa y su salida.

El código fuente también contiene un control deslizante y una función de renderizado basada en el tiempo. Las pruebas de comportamiento posteriores descubrieron que esos controles existían, pero no todos funcionaban. La reproducción real avanzó desde el estado inicial más allá de los 3.1 segundos, llegó a los seis segundos y se detuvo. El desplazamiento temporal reveló otro defecto: el tiempo mostrado conservaba el valor anterior en lugar de pasar al solicitado.

Evalúa el significado antes que el estilo

Empieza por los requisitos innegociables. ¿Están los datos exactos? ¿Se relacionan correctamente? ¿Puede el espectador leer la afirmación completa durante el intervalo exigido? ¿Utiliza el resultado los recursos proporcionados sin inventar comportamientos de la interfaz?

Después, comprueba el comportamiento temporal. Ve directamente al punto medio, al inicio, al límite de entrada, al límite de salida y al final. Una animación determinista debería producir el estado esperado independientemente del recorrido seguido para llegar a ese instante. Si el estado depende de haber reproducido los fotogramas anteriores, el código puede no servir para renderizar fotogramas de manera fiable.

Solo entonces compara la calidad visual. Considera la jerarquía, los espacios, la tipografía, la coherencia del movimiento y hasta qué punto la composición sirve al mensaje. Basa el juicio en el encargo. Una escena de oferta deliberadamente sobria no debería perder simplemente porque otra versión añade más espectáculo.

Utiliza una rúbrica breve con dimensiones informadas por separado, en lugar de una puntuación total misteriosa. La exactitud factual, los tiempos, la facilidad de edición, la comunicación visual y la fiabilidad de la entrega pueden arrojar resultados distintos. Una única nota oculta la contrapartida que el equipo necesita comprender.

Qué encontró realmente la prueba posterior

El fallo del desplazamiento temporal se pudo reproducir después de que la reproducción llegara a los seis segundos. La tecla Home no llevaba el resultado a cero. Enviar eventos de entrada para 0.8, 4.8 y 5.4 segundos también dejaba el resultado en seis segundos. Esto importa porque un editor necesita inspeccionar un estado concreto sin reproducir toda la secuencia. Una línea de tiempo visible no basta.

La causa era el orden de los eventos. El manejador de entrada llamaba a pause() antes de leer el valor solicitado en el deslizador. En esta implementación, pausar también volvía a renderizar el estado anterior en el control. Por tanto, la lectura posterior recuperaba el valor anterior. Los cálculos de la animación podían ser correctos mientras el control utilizado para inspeccionarla estaba roto.

El autor reparó una copia separada leyendo el valor solicitado antes de pausar y aplicándolo después; se conserva la salida original del modelo.

// Preserve the requested value before pause() renders the old state.
const requestedTime = Number(seek.value);
pause();
state.time = Math.max(0, Math.min(motion.duration, requestedTime));
render();

La copia reparada respondió a las teclas Home y End con cero y seis segundos. En los instantes 0.8 y 4.8 segundos, ambas líneas de precios tenían opacidad completa y ningún desplazamiento. A los 5.4 segundos, ambas tenían una opacidad de 0.5 y un desplazamiento hacia arriba de 18 píxeles.

Editar directamente las líneas contenteditable a US$39 per month y US$468 billed annually dejó ambas visibles a los 2.4 segundos. La siguiente prueba de recepción debería guardar, recargar y renderizar esos cambios.

Leer el tiempo mostrado es la forma más rápida de distinguir un fallo de reproducción de uno de desplazamiento temporal. Aquí, el original avanza con normalidad al reproducirse y después rechaza una solicitud posterior de un estado específico. La reparación cambia el orden del manejador de eventos y conserva las curvas de entrada y salida. En una prueba entre agentes, esto se convierte en una tarea de reparación precisa: corregir el desplazamiento temporal, conservar la duración de seis segundos y ambas líneas de precios, y después comprobar Home, End y un instante intermedio.

Aplica la misma modificación puntual

El primer borrador es solo la mitad de la tarea. Pide a ambas ejecuciones que hayan terminado correctamente la misma modificación: por ejemplo, cambiar el equivalente mensual y el cargo anual, conservar la disposición y los tiempos, y mantener visibles ambas afirmaciones a la vez. Así compruebas si el agente puede modificar una parte acotada sin reescribir innecesariamente el resto.

Conserva el código fuente original y compáralo con la revisión. Comprueba qué cambió en el texto, la geometría, los tiempos, los controles y las referencias a recursos. Un resultado visualmente similar puede ocultar un control de desplazamiento averiado o un final desplazado. Un cambio amplio en el código también puede ser aceptable si el comportamiento resultante es correcto, pero merece inspeccionarse.

Fija de antemano el margen permitido para las correcciones. Si un agente recibe tres instrucciones cada vez más específicas y el otro solo una, informa de esa diferencia en lugar de presentar la pareja final como primeros intentos equivalentes. La ayuda forma parte del coste de llegar a un resultado utilizable.

En una prueba del flujo completo, deja que los agentes ejecuten e inspeccionen sus propios artefactos con permisos comparables. Registra las herramientas que usan realmente y cualquier intervención humana necesaria. Un agente que detecta y corrige un error de carga está realizando un trabajo útil que una comparación basada únicamente en capturas pasaría por alto.

Mide el coste sin inventar precisión

El tiempo transcurrido es fácil de registrar y de malinterpretar. La solicitud a Codex de este caso tardó unos 179 segundos, incluidos el arranque y los tiempos de espera agotados durante la detección de modelos que figuran en el registro. No es una medición limpia de la velocidad de generación. Presentarlo como «Codex tarda tres minutos en animar» exageraría lo medido.

Para una comparación más útil, separa, cuando las herramientas lo permitan, la preparación, el tiempo de solicitud, la reparación, el renderizado y la revisión humana. El tiempo total hasta obtener un artefacto utilizable puede importar más que la latencia de respuesta. Un primer borrador rápido que requiere varias correcciones cuidadosas puede costar más esfuerzo que uno correcto y más lento.

No deduzcas el coste en dinero a partir del tiempo transcurrido o del número de tokens sin conocer el contexto de facturación real. El uso por suscripción, la facturación por API, la entrada en caché y los ajustes del modelo pueden diferir. Si no puedes obtener una cifra de coste fiable, informa de los datos de uso observables y deja el coste sin medir.

Incluye los fallos en el relato operativo, pero clasifícalos. Preparar la autenticación es distinto de que un modelo produzca código inválido. Un fallo de una dependencia de renderizado es distinto de un diseño ilegible. Esta distinción hace útil la comparación tanto para elegir una herramienta como para definir el flujo que la acompaña.

Repite tareas representativas antes de extraer una conclusión amplia. Una única escena pequeña puede revelar un tipo de fallo. No permite establecer que un agente sea, en general, mejor para lanzamientos de producto, explicaciones técnicas, gráficos, localización y cualquier futura tarea de animación.

Haz visible la ayuda humana

Una comparación justa debería registrar el trabajo que realiza el operador entre solicitudes. Instalar un paquete que falta, localizar un recurso, corregir un nombre de archivo o explicar un error pueden mejorar considerablemente el resultado final. Si esa ayuda queda oculta, la comparación atribuye al agente la contribución humana.

Decide qué ayuda forma parte de la prueba. En un flujo realista, puede ser razonable que un operador responda a una pregunta sobre el producto o apruebe el acceso a un archivo. En una prueba controlada de generación de código, cualquier reparación manual del código cambia el artefacto evaluado. Ningún enfoque es intrínsecamente incorrecto; el problema es presentar uno como si fuera el otro.

Conserva un registro breve de intervenciones. Puede indicar que el operador proporcionó la misma captura a ambos sistemas, aclaró una frase de facturación para ambos o reparó un servidor local antes de abrir cualquiera de los resultados. Si solo uno necesitó una corrección, regístralo también. Ese trabajo adicional puede ser relevante para la decisión del equipo, aunque las imágenes finales parezcan igual de buenas.

Separa el aprendizaje del operador del rendimiento del agente a lo largo de ejecuciones repetidas. Tras probar el primer sistema, el operador puede comprender mejor la tarea y orientar al segundo de forma más útil. Alternar el orden de ejecución o fijar todas las entradas antes de empezar ayuda a reducir esa ventaja. Un estudio local pequeño no puede eliminar todas las fuentes de variación, pero sí hacerlas visibles.

Esta transparencia resulta especialmente valiosa en animación, porque el acabado visual invita a juzgar deprisa. Un resultado que exigió ajustes manuales cuidadosos de tiempos no debería describirse como una generación intacta de un solo intento. Los lectores pueden admirarlo y, al mismo tiempo, comprender cómo se hizo.

Publica un resultado que otros puedan inspeccionar

Una comparación creíble incluye el encargo, el conjunto de recursos o las instrucciones para obtenerlos, el registro del entorno, las salidas originales, las instrucciones de revisión, los ajustes de renderizado y las comprobaciones observadas. Los lectores deberían poder entender de dónde sale tu conclusión sin tener que confiar en una imagen comparativa atractiva.

Mantén el resultado al nivel de los requisitos: el texto exacto cumplía en el estado inicial, la reproducción llegó al final y el desplazamiento temporal falló antes de la reparación. Una ejecución posterior con ambos agentes puede utilizar el mismo encargo y las mismas comprobaciones para comparar cómo diagnostican y revisan el artefacto.

Inspecciona la salida original, la reparación independiente y los registros de comportamiento.