Como comparar Claude Code e Codex de forma justa em um briefing de motion

Dois vídeos atraentes não constituem uma comparação justa entre dois agentes de programação. Um deles pode ter recebido recursos melhores, um prompt mais detalhado, uma rodada extra de correções ou acesso a ferramentas indisponíveis para o outro. Uma captura de tela lado a lado esconde essas diferenças.

É particularmente fácil cometer esse erro em trabalhos de motion. Um modelo pode produzir um primeiro quadro impressionante e descumprir os requisitos de tempo. Outro pode entregar um projeto simples, mas editável, que continua funcionando após uma alteração local. A melhor opção depende do trabalho que você pretendia delegar.

Para comparar Claude Code e Codex em motion graphics, comece com a mesma tarefa de aceitação e os mesmos recursos; depois examine o texto exato, os tempos, os controles e o esforço de correção necessário para obter um resultado utilizável. O caso prático acompanha uma saída do Codex durante a reprodução, uma falha no controle de navegação temporal e sua correção. Não foi possível autenticar o Claude Code para a execução correspondente; a comparação entre modelos continua em aberto.

Escolha uma tarefa que revele a capacidade de que você precisa

“Faça um vídeo de produto bonito” deixa espaço demais para interpretação. Um teste melhor combina uma necessidade real de comunicação com uma entrega técnica delimitada. Por exemplo: criar uma cena de oferta editável de seis segundos, com texto de preço exato, navegação temporal determinística e um intervalo comum para leitura.

A cena pode ser visualmente simples e ainda testar comportamentos importantes. O texto exato verifica a preservação dos fatos. Uma permanência estável verifica o raciocínio temporal. O controle de navegação verifica se a animação é orientada pelo tempo, em vez de depender de uma sequência que só funciona quando reproduzida desde o início. Uma alteração local verifica se o código-fonte continua controlável.

Não sobrecarregue o primeiro teste com todos os recursos possíveis. Se incluir narração, música, legendas, dados de gráficos, várias proporções e uma interface complexa, será difícil atribuir as falhas a uma causa. Comece com uma tarefa pequena e representativa; depois acrescente uma segunda tarefa para capacidades que a primeira não consegue revelar.

Decida se está comparando geração de código ou fluxos completos de agentes. Um teste apenas de código pode manter as ferramentas constantes, desativando-as e solicitando um documento autossuficiente. Um teste de fluxo de trabalho deve permitir que cada agente examine os recursos, execute o projeto e corrija erros com permissões comparáveis. São experimentos diferentes e não devem ser fundidos em um único ranking.

Para uma equipe adotando uma ferramenta, o teste de fluxo de trabalho costuma ser mais relevante. O resultado útil não é somente o código-fonte: é um artefato correto e editável, produzido por um processo viável. Ainda assim, um teste menor, apenas de código, pode revelar problemas de requisitos e ambiente antes de você investir tempo em uma comparação maior.

Fixe o briefing e os recursos

Use exatamente o mesmo briefing nas duas execuções. Salve-o antes de acionar qualquer agente. Se descobrir uma ambiguidade depois de ver o primeiro resultado, revise o briefing para ambos e trate o novo par como outro teste, em vez de esclarecer a questão apenas para um agente.

No teste local que acompanha este artigo, o briefing solicitava um documento HTML autossuficiente de 1280 por 720. A cena fictícia se chamava Still Studio e precisava exibir exatamente “US$29 per month” e “US$348 billed annually”. As duas linhas deveriam entrar entre zero e 0.8 segundos, permanecer estáveis até 4.8 segundos e sair até seis segundos.

O briefing também pedia controles visíveis de Play/Pause e navegação temporal, estado inicial pausado em 2.4 segundos, tipografia sans-serif do sistema, nenhum recurso remoto e uma identificação de estudo fictício. Essas restrições tornavam a saída inspecionável e evitavam diferenças decorrentes de imagens ou fontes externas.

O texto e a relação entre os valores de cobrança são importantes. Um modelo que altera o valor anual descumpre um requisito factual, mesmo que sua tipografia seja mais atraente. Um modelo que só mostra a condição no final descumpre um requisito temporal, mesmo que as palavras corretas existam no código-fonte.

Se usar recursos reais do produto, forneça cópias idênticas e preserve suas identidades. Não deixe um agente usar uma captura mais recente ou outro logotipo. Se um recurso não puder ser redistribuído, descreva a exigência de acesso e mantenha a comparação no ambiente autorizado.

Registre o ambiente que realmente foi executado

O nome de uma ferramenta não identifica o sistema completo. Registre a versão da CLI, o modelo informado pela execução, as configurações relevantes, as ferramentas disponíveis, as permissões e se a sessão era nova ou uma continuação. O modelo padrão pode mudar ao longo do tempo; por isso, o modelo informado importa mais do que uma suposição baseada no nome do produto.

Separe acesso à conta de desempenho do modelo. Uma falha de login, um limite de uso ou uma interrupção de rede pode afetar o fluxo prático, mas não revela a qualidade de um vídeo que o modelo nunca produziu. Mantenha essas falhas no registro sem convertê-las em uma nota de criatividade.

A execução do Codex usou autenticação do ChatGPT pelo provedor OpenAI. Seu registro identifica a versão 0.163.0 da CLI e o modelo gpt-6.1-sol; a saída é um documento HTML independente.

Autenticação e configuração exigem atenção explícita porque podem selecionar caminhos de acesso diferentes. Consulte a documentação da própria ferramenta e preserve o caminho realmente usado; não exponha tokens nem arquivos privados de conta no pacote de avaliação. Documentação de autenticação do Claude Code

Preserve as saídas brutas antes de corrigi-las

Salve a primeira resposta exatamente como foi recebida, junto com o briefing e o estado da execução. Se precisar remover delimitadores de bloco Markdown para abrir um documento HTML, registre essa transformação. Não corrija a sintaxe silenciosamente para depois chamar o resultado de primeiro rascunho original.

Armazene solicitações malsucedidas separadamente dos artefatos concluídos, para que o registro do teste distinga falhas de configuração de defeitos na saída.

Em uma comparação apenas de código, abra o documento recebido sem editá-lo. Confira se as palavras exigidas aparecem, se a cena carrega sem dependências remotas e se os controles estão presentes. Depois reproduza a sequência inteira e navegue diretamente para a entrada, a permanência e a saída.

O código-fonte também contém um controle deslizante e uma função de renderização orientada pelo tempo. Testes posteriores de comportamento constataram que os controles estavam presentes, mas nem todos funcionavam. A reprodução real avançou do estado inicial para além de 3.1 segundos, chegou a seis segundos e parou. A navegação temporal revelou outro defeito: o tempo exibido permanecia no valor antigo, em vez de mudar para o solicitado.

Avalie o significado antes do estilo

Comece pelos requisitos inegociáveis. Os fatos exatos estão presentes? Estão relacionados corretamente? O espectador consegue ler a afirmação completa no intervalo exigido? A saída usa os recursos fornecidos sem inventar comportamentos da interface?

Depois examine o comportamento temporal. Navegue diretamente para o meio, o início, o limite de entrada, o limite de saída e o fim. Uma animação determinística deve produzir o estado esperado independentemente do caminho percorrido até aquele instante. Se o estado depender de quadros anteriores terem sido reproduzidos, o código-fonte pode ser inadequado para renderizar quadros de forma confiável.

Só depois dessas verificações compare a qualidade visual. Considere hierarquia, espaçamento, tipografia, coerência dos movimentos e a contribuição da composição para a mensagem. Mantenha o julgamento ancorado no briefing. Uma cena de oferta deliberadamente contida não deve perder apenas porque outra versão adiciona mais espetáculo.

Use uma pequena rubrica com dimensões relatadas separadamente, em vez de um total misterioso. Precisão factual, tempos, editabilidade, comunicação visual e confiabilidade da entrega podem apontar em direções diferentes. Uma nota única esconde a escolha que a equipe realmente precisa entender.

O que o teste posterior realmente encontrou

A falha de navegação temporal era reproduzível depois que a reprodução chegava a seis segundos. A tecla Home não levava a saída a zero. Enviar eventos de entrada para 0.8, 4.8 e 5.4 segundos também deixava a saída em seis segundos. Isso importa porque um editor precisa inspecionar um estado específico sem reproduzir toda a sequência novamente. Uma linha do tempo visível não basta.

A causa era a ordem dos eventos. O manipulador de entrada chamava pause() antes de ler o valor solicitado no controle deslizante. Nessa implementação, pausar também renderizava o estado antigo de volta no controle. Assim, a leitura seguinte recuperava o valor antigo. Os cálculos da animação podiam estar corretos enquanto o controle usado para inspecioná-la estava quebrado.

O autor corrigiu uma cópia separada, lendo o valor solicitado antes de pausar e aplicando-o depois; a saída original do modelo foi preservada.

// 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();

A cópia corrigida respondeu às teclas Home e End com zero e seis segundos. Em 0.8 e 4.8 segundos, as duas linhas de preço estavam com opacidade total e sem deslocamento. Em 5.4 segundos, ambas tinham opacidade de 0.5 e deslocamento de 18 pixels para cima.

A edição direta das linhas contenteditable para US$39 per month e US$468 billed annually manteve ambas visíveis em 2.4 segundos. O próximo passo de um teste de recebimento deve ser salvar, recarregar e renderizar essas alterações.

Ler o tempo exibido é a maneira mais rápida de distinguir um defeito de reprodução de um defeito de navegação temporal. Aqui, o original avança normalmente ao ser reproduzido e depois recusa uma solicitação de estado específico. A correção altera a ordem do manipulador de eventos e preserva as curvas de entrada e saída. Em um teste pareado de agentes, isso se torna uma tarefa precisa de reparo: corrigir a navegação temporal, preservar a duração de seis segundos e as duas linhas de preço e verificar Home, End e um instante intermediário.

Faça a mesma alteração local

O primeiro rascunho é apenas metade da tarefa. Dê às duas execuções bem-sucedidas a mesma revisão: por exemplo, alterar o equivalente mensal e a cobrança anual, preservar o layout e os tempos e manter as duas afirmações visíveis juntas. Isso testa se o agente consegue modificar uma parte delimitada sem reescrever o restante desnecessariamente.

Preserve o código-fonte original e compare a revisão com ele. Confira o que mudou em texto, geometria, tempos, controles e referências de recursos. Uma saída visualmente semelhante pode ocultar um controle de navegação quebrado ou um encerramento deslocado. Uma grande diferença no código-fonte também pode ser aceitável se o comportamento resultante estiver correto, mas merece inspeção.

Defina previamente o orçamento de correções permitido. Se um agente receber três prompts cada vez mais específicos e o outro receber um, relate essa diferença, em vez de apresentar o par final como primeiras tentativas equivalentes. A assistência faz parte do custo de chegar a um resultado utilizável.

Em um teste de fluxo completo, permita que os agentes executem e inspecionem seus próprios artefatos com permissões comparáveis. Registre as ferramentas realmente usadas e qualquer intervenção humana necessária. Um agente que percebe e corrige um erro de carregamento está realizando um trabalho útil que uma comparação apenas por capturas de tela não mostraria.

Meça o custo sem inventar precisão

O tempo decorrido é fácil de registrar e de interpretar mal. A solicitação ao Codex levou cerca de 179 segundos, incluindo a inicialização e tempos esgotados na descoberta de modelos relatados no registro. Isso não é uma medição isolada da velocidade de geração. Dizer que “o Codex leva três minutos para animar” extrapolaria o que foi medido.

Para uma comparação mais útil, separe configuração, tempo de solicitação, tempo de correção, tempo de renderização e tempo de revisão humana, quando as ferramentas permitirem. O tempo total até um artefato utilizável pode importar mais que a latência da resposta. Um primeiro rascunho rápido que exija várias correções cuidadosas pode consumir mais esforço que um resultado correto mais lento.

Não deduza o custo em dinheiro a partir do tempo decorrido ou de uma contagem de tokens sem o contexto real de cobrança. Uso por assinatura, cobrança de API, entrada em cache e configurações do modelo podem variar. Se não conseguir um valor de custo confiável, informe os dados de uso observáveis e deixe o custo sem medição.

Inclua as falhas no relato operacional, mas classifique-as. Configurar a autenticação é diferente de um modelo produzir código inválido. Uma falha em dependência de renderização é diferente de um design ilegível. Essa distinção torna a comparação útil para escolher tanto a ferramenta quanto o fluxo de apoio.

Repita tarefas representativas antes de chegar a uma conclusão abrangente. Uma única cena pequena pode revelar um tipo de falha. Ela não estabelece que um agente seja melhor em geral em lançamentos de produto, explicações técnicas, gráficos, localização e todo trabalho futuro de motion.

Deixe a assistência humana visível

Uma comparação justa deve registrar o trabalho que o operador realiza entre solicitações. Instalar um pacote ausente, localizar um recurso, corrigir um nome de arquivo ou explicar um erro pode melhorar substancialmente o resultado final. Quando essa ajuda fica invisível, a comparação atribui ao agente a contribuição humana.

Decida qual assistência faz parte do teste. Em um fluxo realista, um operador pode responder a uma pergunta sobre o produto ou aprovar o acesso a um arquivo. Em um teste controlado de geração de código, qualquer reparo manual no código-fonte altera o artefato avaliado. Nenhuma abordagem é inerentemente errada; o problema é apresentar uma como se fosse a outra.

Preserve um registro breve das intervenções. Ele pode informar que o operador forneceu a mesma captura aos dois sistemas, esclareceu uma expressão de cobrança para ambos ou reparou um servidor local antes de abrir qualquer resultado. Se apenas um sistema precisou de reparo, registre isso também. O trabalho extra pode ser relevante para a decisão da equipe, mesmo quando os visuais finais parecem igualmente bons.

Separe o aprendizado do operador do desempenho do agente ao longo de execuções repetidas. Depois de testar o primeiro sistema, o operador pode compreender melhor a tarefa e oferecer orientação mais útil ao segundo. Alternar a ordem de execução ou fixar todas as entradas antes de começar ajuda a reduzir essa vantagem. Um pequeno estudo local não elimina toda fonte de variação, mas pode torná-las visíveis.

Essa transparência é especialmente valiosa em motion porque o acabamento visual convida a julgamentos rápidos. Um resultado que exigiu ajustes manuais cuidadosos de tempo não deve ser descrito como uma geração intocada em uma única tentativa. Os leitores ainda podem admirá-lo sabendo como foi feito.

Publique um resultado que outras pessoas possam inspecionar

Uma comparação confiável inclui briefing, conjunto de recursos ou instruções de obtenção, registro do ambiente, saídas brutas, prompts de revisão, configurações de renderização e verificações observadas. Os leitores devem conseguir entender de onde vem sua conclusão sem precisar confiar em uma imagem atraente de comparação.

Mantenha o resultado no nível dos requisitos: o texto exato passou no estado inicial, a reprodução chegou ao fim e a navegação temporal falhou antes da correção. Uma execução pareada posterior pode usar o mesmo briefing e as mesmas verificações para comparar como os agentes diagnosticam e revisam o artefato.

Inspecione a saída original, a correção independente e os registros de comportamento.