Comparer équitablement Claude Code et Codex sur un brief d’animation

Deux belles vidéos ne permettent pas de comparer équitablement deux agents de programmation. L’un a peut-être reçu de meilleures ressources, des consignes plus détaillées, une correction supplémentaire ou des outils auxquels l’autre n’avait pas accès. Une capture présentant les résultats côte à côte masque ces différences.

L’animation se prête particulièrement à ce type d’erreur. Un modèle peut produire une première image impressionnante tout en manquant les contraintes temporelles. Un autre peut livrer un projet sobre mais modifiable, qui résiste à une révision locale. Pour savoir lequel est le meilleur, il faut tenir compte du travail que vous vouliez déléguer.

Pour comparer Claude Code et Codex en motion design, partez de la même tâche de réception et des mêmes ressources, puis examinez le texte exact, le minutage, les commandes et les corrections nécessaires pour obtenir un résultat utilisable. Le cas détaillé ici suit une production de Codex pendant sa lecture, constate un défaut de navigation temporelle, puis montre sa correction. Claude Code n’a pas pu s’authentifier pour l’essai parallèle ; la comparaison entre modèles reste donc à réaliser.

Choisir une tâche qui révèle la capacité recherchée

« Crée une belle vidéo produit » laisse trop de place à l’interprétation. Un meilleur test associe un véritable besoin de communication à un livrable technique bien délimité. Par exemple, demandez une scène d’offre modifiable de six secondes, avec un texte tarifaire exact, une navigation temporelle déterministe et une plage de lecture commune aux informations.

La scène peut rester visuellement simple tout en testant des comportements importants. Le respect du texte vérifie la conservation des faits. Une pause stable vérifie le raisonnement temporel. Une commande de navigation vérifie que l’animation dépend du temps, et non d’une suite d’actions qui ne fonctionne qu’en repartant du début. Une révision locale vérifie que le code source reste maîtrisable.

Ne surchargez pas le premier test de toutes les fonctions imaginables. Si vous ajoutez narration, musique, sous-titres, données graphiques, plusieurs formats et interface complexe, les causes des échecs deviennent difficiles à isoler. Commencez par une petite tâche représentative, puis ajoutez-en une deuxième pour les capacités que la première ne permet pas d’observer.

Décidez si vous comparez la génération de code ou les processus complets des agents. Un test limité au code peut maintenir les outils constants en les désactivant et en demandant un document autonome. Un test de processus doit permettre à chaque agent d’examiner les ressources, de lancer le projet et de corriger les erreurs avec des autorisations comparables. Il s’agit d’expériences différentes, qui ne doivent pas être fondues dans un classement unique.

Pour une équipe qui adopte un outil, le test de processus est souvent plus pertinent. Le résultat utile n’est pas simplement du code source : c’est un livrable correct et modifiable, obtenu par une démarche praticable. Un petit test limité au code peut toutefois révéler les exigences et les problèmes d’environnement avant d’investir dans une comparaison plus large.

Figer le brief et les ressources

Utilisez exactement le même brief pour les deux essais. Enregistrez-le avant de solliciter l’un ou l’autre agent. Si vous découvrez une ambiguïté après le premier résultat, corrigez le brief pour les deux et considérez cette nouvelle paire comme un autre test, au lieu de réserver la précision à un seul agent.

Pour le test local accompagnant cet article, le brief demandait un document HTML autonome de 1280 par 720. La scène fictive s’intitulait Still Studio et devait afficher exactement « US$29 per month » et « US$348 billed annually ». Les deux lignes devaient apparaître entre zéro et 0,8 seconde, rester stables jusqu’à 4,8 secondes et disparaître avant six secondes.

Le brief demandait également des commandes visibles Play/Pause et de navigation temporelle, un état initial en pause à 2,4 secondes, une police sans empattement du système, aucune ressource distante et une mention indiquant qu’il s’agissait d’une étude fictive. Ces contraintes rendaient le résultat inspectable et évitaient les différences dues à des images ou à des polices externes.

Le texte et le rapport entre les montants facturés sont importants. Un modèle qui modifie le montant annuel ne respecte pas une exigence factuelle, même si sa typographie est plus séduisante. Un modèle qui n’affiche la condition qu’à la fin ne respecte pas une exigence temporelle, même si les bons mots figurent dans le code source.

Si vous employez de vraies ressources produit, fournissez des copies identiques et préservez leur identité. Ne laissez pas un agent utiliser une capture plus récente ou un autre logo. Si une ressource ne peut être redistribuée, décrivez les conditions d’accès et limitez la comparaison à l’environnement autorisé.

Consigner l’environnement réellement utilisé

Le nom d’un outil ne décrit pas le système complet. Notez la version du CLI, le modèle indiqué par l’exécution, les réglages pertinents, les outils disponibles, les autorisations et le caractère nouveau ou poursuivi de la session. Le modèle par défaut peut changer : le modèle effectivement annoncé compte davantage qu’une supposition fondée sur le nom du produit.

Distinguez l’accès au compte des performances du modèle. Un échec de connexion, une limite de débit ou une interruption réseau peut affecter le processus pratique, mais ne renseigne pas sur la qualité d’une vidéo que le modèle n’a jamais produite. Conservez ces échecs dans le dossier sans les transformer en note créative.

L’essai Codex utilisait l’authentification ChatGPT par le fournisseur OpenAI. Son journal indique le CLI en version 0.163.0 et le modèle gpt-6.1-sol ; le résultat est un document HTML autonome.

L’authentification et la configuration méritent une attention explicite, car elles peuvent sélectionner des voies d’accès différentes. Consultez la documentation de l’outil et conservez la trace de la voie réellement utilisée ; n’exposez ni jetons ni fichiers privés du compte dans le dossier de comparaison. Documentation sur l’authentification de Claude Code

Conserver les sorties brutes avant de les corriger

Enregistrez la première réponse exactement telle que reçue, avec le brief et l’état d’exécution. Si vous devez retirer les délimiteurs Markdown pour ouvrir un document HTML, consignez cette transformation. Ne corrigez pas discrètement la syntaxe pour ensuite présenter le résultat comme le premier jet original.

Rangez les requêtes échouées séparément des livrables terminés, afin que le dossier distingue les échecs de préparation des défauts du résultat.

Pour une comparaison limitée au code, ouvrez le document renvoyé sans le modifier. Vérifiez la présence des mots demandés, le chargement de la scène sans dépendances distantes et la présence des commandes. Lisez ensuite toute la séquence, puis accédez directement à son apparition, à son maintien et à sa disparition.

Le code source contient aussi un curseur et une fonction de rendu pilotée par le temps. Les tests comportementaux ultérieurs ont révélé que ces commandes étaient présentes, mais pas toutes fonctionnelles. La lecture avançait effectivement depuis l’état initial au-delà de 3,1 secondes, atteignait six secondes et s’arrêtait. La navigation a révélé un autre défaut : le temps affiché restait à l’ancienne valeur au lieu d’atteindre celle demandée.

Évaluer le sens avant le style

Commencez par les exigences non négociables. Les faits exacts sont-ils présents ? Sont-ils correctement reliés ? Le spectateur peut-il lire la proposition entière pendant l’intervalle demandé ? Le résultat utilise-t-il les ressources fournies sans inventer de comportement d’interface ?

Examinez ensuite le comportement temporel. Accédez directement au milieu, au début, à la limite d’apparition, à la limite de disparition et à la fin. Une animation déterministe doit produire l’état attendu quel que soit le chemin suivi pour atteindre cet instant. Si l’état dépend de la lecture préalable des images précédentes, le code peut être inadapté à un rendu image par image fiable.

Comparez la qualité visuelle seulement après ces vérifications. Examinez la hiérarchie, les espacements, la typographie, la cohérence des mouvements et la manière dont la composition sert le message. Ancrez le jugement dans le brief. Une scène d’offre volontairement sobre ne devrait pas perdre simplement parce qu’une autre version multiplie les effets spectaculaires.

Utilisez une petite grille dont les dimensions sont rapportées séparément, plutôt qu’un total mystérieux. Exactitude factuelle, minutage, facilité de modification, communication visuelle et fiabilité de livraison peuvent diverger. Une note unique masque l’arbitrage que l’équipe a réellement besoin de comprendre.

Ce que le test complémentaire a réellement constaté

L’échec de navigation était reproductible une fois la lecture arrivée à six secondes. La touche Home ne ramenait pas le résultat à zéro. L’envoi d’événements d’entrée pour 0,8, 4,8 et 5,4 secondes laissait également le résultat à six secondes. C’est important, car un monteur doit pouvoir examiner un état particulier sans relire toute la séquence. La présence visuelle d’une timeline ne suffit pas.

La cause tenait à l’ordre des événements. Le gestionnaire appelait pause() avant de lire la valeur demandée sur le curseur. Dans cette implémentation, la mise en pause réaffichait également l’ancien état dans la commande. La lecture suivante récupérait donc l’ancienne valeur. Les calculs d’animation pouvaient être corrects tandis que la commande permettant de les examiner était défectueuse.

L’auteur a corrigé une copie distincte en lisant la valeur demandée avant la mise en pause, puis en l’appliquant après ; la sortie originale du modèle est conservée.

// 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 copie corrigée répondait aux touches Home et End en affichant zéro et six secondes. À 0,8 et 4,8 secondes, les deux lignes tarifaires étaient entièrement opaques et sans translation. À 5,4 secondes, elles avaient toutes deux une opacité de 0.5 et une translation de 18 pixels vers le haut.

La modification directe des lignes contenteditable en US$39 per month et US$468 billed annually laissait les deux visibles à 2,4 secondes. Un test de réception devrait ensuite enregistrer ces modifications, recharger le document et les rendre.

Lire le temps affiché est le moyen le plus rapide de distinguer un défaut de lecture d’un défaut de navigation. Ici, l’original avance normalement pendant la lecture, puis refuse une demande ultérieure visant un état précis. La correction modifie l’ordre du gestionnaire d’événements en préservant les courbes d’apparition et de disparition. Dans un test parallèle d’agents, cela devient une tâche de réparation précise : corriger la navigation, conserver les six secondes et les deux lignes tarifaires, puis vérifier Home, End et un instant intermédiaire.

Effectuer la même révision locale

Le premier jet ne représente que la moitié du travail. Donnez aux deux essais réussis la même révision : par exemple, changer l’équivalent mensuel et le montant annuel, conserver la composition et le minutage, et maintenir les deux indications visibles ensemble. Vous vérifiez ainsi si l’agent sait réviser une partie délimitée sans réécrire inutilement le reste.

Conservez le code original et comparez la révision à celui-ci. Examinez les modifications du texte, de la géométrie, du minutage, des commandes et des références de ressources. Un résultat visuellement proche peut dissimuler une navigation cassée ou une fin décalée. Une différence de code importante peut aussi être acceptable si le comportement obtenu est correct, mais elle mérite un examen.

Fixez à l’avance le budget de correction autorisé. Si un agent reçoit trois consignes de plus en plus précises et l’autre une seule, indiquez cette différence au lieu de présenter la paire finale comme deux premières tentatives équivalentes. L’assistance fait partie du coût nécessaire pour parvenir à un résultat utilisable.

Pour un test de processus complet, laissez les agents lancer et examiner leurs propres livrables avec des autorisations comparables. Notez les outils réellement utilisés et les interventions humaines nécessaires. Un agent qui remarque et corrige une erreur de chargement accomplit un travail utile qu’une comparaison de captures manquerait.

Mesurer le coût sans inventer de précision

Le temps écoulé est facile à relever et à mal interpréter. Ici, la requête Codex a duré environ 179 secondes, démarrage et délais d’expiration de découverte des modèles signalés dans le journal compris. Ce n’est pas une mesure propre de la vitesse de génération. Dire que « Codex met trois minutes à animer » dépasserait ce qui a été mesuré.

Pour une comparaison plus utile, séparez préparation, temps de requête, temps de correction, temps de rendu et temps de revue humaine lorsque l’outillage le permet. Le temps total nécessaire pour obtenir un livrable utilisable peut compter davantage que la latence de réponse. Un premier jet rapide exigeant plusieurs réparations délicates peut demander plus d’efforts qu’un résultat correct obtenu plus lentement.

Ne déduisez pas un coût en dollars du temps écoulé ou du nombre de jetons sans connaître la facturation réelle. Usage par abonnement, facturation API, entrées en cache et réglages du modèle peuvent différer. Sans montant fiable, rapportez les informations d’usage observables et laissez le coût non mesuré.

Incluez les échecs dans le récit opérationnel, mais classez-les. Un problème d’authentification est différent d’un modèle produisant du code invalide. Une dépendance de rendu défaillante est différente d’un design illisible. Cette distinction aide à choisir à la fois l’outil et le processus qui l’accompagne.

Répétez des tâches représentatives avant de tirer une conclusion générale. Une petite scène unique peut révéler un mode de défaillance. Elle ne peut établir qu’un agent est globalement meilleur pour les lancements produit, les explications techniques, les graphiques, la localisation et tous les futurs travaux d’animation.

Rendre visible l’assistance humaine

Une comparaison équitable doit consigner ce que fait l’opérateur entre les requêtes. Installer un paquet manquant, retrouver une ressource, corriger un nom de fichier ou expliquer une erreur peut améliorer sensiblement le résultat final. Si cette aide est invisible, la comparaison attribue la contribution humaine à l’agent.

Décidez quelles formes d’aide font partie du test. Dans un processus réaliste, l’opérateur peut légitimement répondre à une question produit ou approuver l’accès à un fichier. Dans un test contrôlé de génération de code, toute réparation manuelle du code modifie le livrable évalué. Aucune approche n’est intrinsèquement mauvaise ; le problème consiste à présenter l’une pour l’autre.

Conservez un bref journal des interventions. Il peut indiquer que l’opérateur a fourni la même capture aux deux systèmes, précisé une formulation de facturation pour les deux ou réparé un serveur local avant d’ouvrir les résultats. Si un seul système a nécessité une correction, consignez-le aussi. Ce travail supplémentaire peut compter dans la décision de l’équipe même si les visuels finaux sont aussi réussis l’un que l’autre.

Distinguez l’apprentissage de l’opérateur des performances de l’agent au fil des essais. Après avoir testé le premier système, l’opérateur peut mieux comprendre la tâche et mieux guider le second. Alterner l’ordre des essais ou figer toutes les entrées avant de commencer aide à limiter cet avantage. Une petite étude locale ne peut éliminer toutes les variations, mais elle peut les rendre visibles.

Cette transparence est particulièrement précieuse en animation, où le soin visuel invite aux jugements rapides. Un résultat ayant exigé des ajustements manuels minutieux du minutage ne doit pas être décrit comme une génération en une seule passe sans retouche. Les lecteurs peuvent l’apprécier tout en comprenant comment il a été obtenu.

Publier un résultat que d’autres peuvent examiner

Une comparaison crédible comprend le brief, les ressources ou les instructions pour les obtenir, le relevé d’environnement, les sorties brutes, les consignes de révision, les paramètres de rendu et les vérifications observées. Les lecteurs doivent comprendre l’origine de votre conclusion sans se fier à une séduisante image comparative.

Formulez le résultat au niveau des exigences : le texte exact était correct dans l’état initial, la lecture atteignait la fin et la navigation échouait avant correction. Un essai parallèle ultérieur pourra reprendre le même brief et les mêmes contrôles pour comparer le diagnostic et la révision des agents.

Examiner la sortie originale, la correction indépendante et les relevés de comportement.