Come confrontare Claude Code e Codex in modo equo su un brief di motion design

Due video accattivanti non costituiscono un confronto equo fra due agenti di programmazione. Uno potrebbe aver ricevuto risorse migliori, un prompt più dettagliato, un ulteriore giro di correzioni o strumenti ai quali l’altro non aveva accesso. Una schermata affiancata nasconde queste differenze.

Nel motion design è particolarmente facile sbagliare valutazione. Un modello può produrre un primo fotogramma spettacolare e non rispettare i tempi richiesti. Un altro può realizzare un progetto sobrio ma modificabile, che regge una revisione locale. Quale sia migliore dipende dal lavoro che volevi delegare.

Per confrontare Claude Code e Codex nella motion graphics, parti dallo stesso compito di accettazione e dalle stesse risorse, poi esamina la fedeltà dei testi, i tempi, i controlli e le correzioni necessarie per ottenere un risultato utilizzabile. Il caso pratico segue un output di Codex durante la riproduzione, il malfunzionamento del controllo di ricerca temporale e una correzione. Claude Code non ha potuto autenticarsi per l’esecuzione abbinata; il confronto fra i due modelli rimane aperto.

Scegli un compito che riveli la capacità che ti serve

«Crea un bel video di prodotto» lascia troppo spazio all’interpretazione. Un test migliore contiene una vera esigenza di comunicazione e una consegna tecnica circoscritta. Per esempio, creare una scena di offerta modificabile di sei secondi, con prezzi scritti esattamente come richiesto, ricerca temporale deterministica e un intervallo di lettura comune.

La scena può essere visivamente semplice e verificare comunque comportamenti importanti. Il testo esatto controlla la conservazione dei fatti. Una pausa stabile verifica il ragionamento temporale. Un controllo di ricerca verifica che l’animazione dipenda dal tempo, anziché da una sequenza che funziona solo se riprodotta dall’inizio. Una revisione locale verifica che il sorgente resti controllabile.

Non sovraccaricare il primo test con ogni funzione possibile. Se includi voce narrante, musica, sottotitoli, dati per grafici, diversi rapporti d’aspetto e un’interfaccia complessa, diventa difficile attribuire le cause degli errori. Parti da un piccolo compito rappresentativo, poi aggiungine un secondo per le capacità che il primo non può rivelare.

Decidi se stai confrontando la generazione di codice o i flussi di lavoro completi degli agenti. Un test del solo codice può mantenere costanti gli strumenti disattivandoli e richiedendo un documento autonomo. Un test del flusso di lavoro dovrebbe consentire a ciascun agente di esaminare le risorse, eseguire il progetto e correggere gli errori con autorizzazioni comparabili. Sono esperimenti diversi e non vanno riuniti in un’unica classifica.

Per un team che sta adottando uno strumento, il test del flusso di lavoro è spesso più pertinente. Il risultato utile non è soltanto il codice sorgente: è un artefatto corretto e modificabile ottenuto attraverso un processo praticabile. Tuttavia, una prova più piccola sul solo codice può far emergere requisiti e problemi dell’ambiente prima di investire tempo in un confronto più ampio.

Congela il brief e le risorse

Usa esattamente lo stesso brief per entrambe le esecuzioni. Salvalo prima di invocare uno qualsiasi degli agenti. Se scopri un’ambiguità dopo aver visto il primo risultato, rivedi il brief per entrambi e considera la nuova coppia un altro test, anziché fornire il chiarimento a un solo agente.

Nella prova locale che accompagna questo articolo, il brief richiedeva un documento HTML autonomo da 1280 per 720. La scena fittizia si intitolava Still Studio e doveva mostrare le diciture esatte “US$29 per month” e “US$348 billed annually”. Le due righe dovevano entrare fra zero e 0.8 secondi, rimanere stabili fino a 4.8 secondi e uscire entro sei secondi.

Il brief richiedeva inoltre controlli Play/Pause e di ricerca temporale visibili, un tempo iniziale in pausa di 2.4 secondi, caratteri sans-serif di sistema, nessuna risorsa remota e un’etichetta che identificasse lo studio come fittizio. Questi vincoli servivano a rendere l’output esaminabile e a evitare differenze dovute a immagini o font esterni.

Il testo e il rapporto fra le condizioni di fatturazione sono importanti. Un modello che modifica l’importo annuale non rispetta un requisito fattuale, anche se la sua tipografia è più attraente. Un modello che mostra la condizione soltanto alla fine non rispetta un requisito temporale, anche se nel sorgente sono presenti le parole corrette.

Se usi risorse di un prodotto reale, fornisci copie identiche e preservane l’identità. Non consentire a un agente di usare una schermata più recente o un logo diverso. Se una risorsa non può essere ridistribuita, descrivi i requisiti di accesso e mantieni il confronto all’interno dell’ambiente autorizzato.

Registra l’ambiente effettivamente usato

Il nome di uno strumento non identifica il sistema completo. Registra la versione della CLI, il modello dichiarato dall’esecuzione, le impostazioni pertinenti, gli strumenti disponibili, le autorizzazioni e se la sessione era nuova o ripresa. Il modello predefinito può cambiare nel tempo: quello dichiarato conta più di una supposizione basata sul nome del prodotto.

Distingui l’accesso all’account dalle prestazioni del modello. Un accesso fallito, un limite di frequenza o un’interruzione di rete possono influire sul flusso di lavoro pratico, ma non rivelano la qualità di un video che il modello non ha mai prodotto. Conserva questi insuccessi nel resoconto senza trasformarli in un punteggio creativo.

L’esecuzione di Codex ha usato l’autenticazione ChatGPT tramite il provider OpenAI. Il log indica la versione CLI 0.163.0 e il modello gpt-6.1-sol; l’output è un documento HTML autonomo.

Autenticazione e configurazione richiedono attenzione esplicita perché possono selezionare percorsi di accesso diversi. Consulta la documentazione dello strumento e conserva il percorso effettivamente usato; non esporre token o file privati dell’account nel pacchetto del benchmark. Documentazione sull’autenticazione di Claude Code

Conserva gli output grezzi prima di correggerli

Salva la prima risposta esattamente come è stata ricevuta, insieme al brief e allo stato dell’esecuzione. Se devi rimuovere le delimitazioni Markdown per aprire un documento HTML, registra la trasformazione. Non correggere silenziosamente la sintassi per poi chiamare il risultato prima bozza originale.

Archivia le richieste fallite separatamente dagli artefatti completati, affinché il resoconto distingua i problemi di configurazione dai difetti dell’output.

Per un confronto del solo codice, apri il documento restituito senza modificarlo. Controlla che compaiano le parole richieste, che la scena si carichi senza dipendenze remote e che i controlli siano presenti. Poi riproduci l’intera sequenza e raggiungi direttamente l’ingresso, la fase stabile e l’uscita.

Il sorgente contiene anche un input di tipo range e una funzione di rendering basata sul tempo. I successivi test comportamentali hanno rilevato che questi controlli erano presenti, ma non tutti funzionanti. La riproduzione effettiva è avanzata dallo stato iniziale oltre 3.1 secondi, ha raggiunto sei secondi e si è arrestata. La ricerca temporale ha rivelato un difetto distinto: il tempo mostrato restava al valore precedente anziché passare a quello richiesto.

Valuta il significato prima dello stile

Parti dai requisiti irrinunciabili. I fatti esatti sono presenti? Sono collegati correttamente? Lo spettatore riesce a leggere l’affermazione completa nell’intervallo richiesto? L’output usa le risorse fornite senza inventare comportamenti dell’interfaccia?

Esamina poi il comportamento temporale. Vai direttamente al punto centrale, all’inizio, al limite d’ingresso, al limite d’uscita e alla fine. Un’animazione deterministica dovrebbe produrre lo stato previsto indipendentemente dal percorso seguito per raggiungere quell’istante. Se lo stato dipende dalla riproduzione dei fotogrammi precedenti, il sorgente potrebbe non essere adatto a un rendering affidabile dei fotogrammi.

Solo dopo questi controlli confronta la qualità visiva. Considera gerarchia, spaziatura, tipografia, coerenza del movimento e quanto bene la composizione serve il messaggio. Ancora il giudizio al brief. Una scena d’offerta volutamente sobria non dovrebbe perdere solo perché un’altra versione aggiunge più spettacolo.

Usa una piccola griglia di valutazione con dimensioni riportate separatamente, anziché un unico totale misterioso. Accuratezza fattuale, tempi, modificabilità, comunicazione visiva e affidabilità della consegna possono dare esiti diversi. Un solo punteggio nasconde il compromesso che un team ha davvero bisogno di capire.

Che cosa ha effettivamente rilevato il test successivo

Il problema della ricerca temporale era riproducibile dopo che la riproduzione aveva raggiunto sei secondi. Il tasto Home non riportava l’output a zero. Anche l’invio di eventi di input per 0.8, 4.8 e 5.4 secondi lasciava l’output a sei secondi. È importante, perché chi monta deve poter esaminare uno stato preciso senza riprodurre l’intera sequenza. Una timeline visibile non basta.

La causa era l’ordine degli eventi. Il gestore dell’input chiamava pause() prima di leggere il valore richiesto del cursore. In questa implementazione, mettere in pausa riportava anche il vecchio stato nel controllo attraverso il rendering. La lettura successiva recuperava quindi il vecchio valore. La matematica dell’animazione poteva essere corretta mentre il controllo usato per esaminarla era guasto.

L’autore ha corretto una copia separata leggendo il valore richiesto prima di mettere in pausa e applicandolo dopo; l’output originale del modello è conservato.

// 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 corretta rispondeva ai tasti Home ed End con zero e sei secondi. A 0.8 e 4.8 secondi, entrambe le righe di prezzo avevano opacità piena e nessuna traslazione. A 5.4 secondi, entrambe avevano opacità 0.5 e una traslazione verso l’alto di 18 pixel.

La modifica diretta delle righe contenteditable in US$39 per month e US$468 billed annually le lasciava entrambe visibili a 2.4 secondi. Un test di ricezione dovrebbe poi salvare, ricaricare e renderizzare queste modifiche.

Leggere il tempo visualizzato è il modo più rapido per distinguere un difetto della riproduzione da un difetto della ricerca. Qui l’originale avanza normalmente quando viene riprodotto, poi rifiuta una richiesta successiva di uno stato preciso. La correzione cambia l’ordine del gestore degli eventi, conservando le curve di ingresso e uscita. In un test abbinato fra agenti, questo diventa un compito di correzione preciso: riparare la ricerca, conservare la durata di sei secondi ed entrambe le righe di prezzo, poi verificare Home, End e un istante intermedio.

Richiedi la stessa revisione locale

La prima bozza è soltanto metà del compito. Dai a entrambe le esecuzioni riuscite la stessa revisione: per esempio, cambiare l’equivalente mensile e l’addebito annuale, conservare impaginazione e tempi, e mantenere visibili insieme le due affermazioni. Questo verifica se l’agente sa rivedere una parte circoscritta senza riscrivere inutilmente il resto.

Conserva il sorgente originale e confronta la revisione con esso. Controlla che cosa è cambiato nei testi, nella geometria, nei tempi, nei controlli e nei riferimenti alle risorse. Un output visivamente simile può nascondere un controllo di ricerca guasto o una conclusione spostata. Anche una differenza ampia nel sorgente può essere accettabile se il comportamento risultante è corretto, ma merita esame.

Stabilisci in anticipo il budget consentito per le correzioni. Se un agente riceve tre prompt sempre più specifici e l’altro uno solo, riporta la differenza invece di presentare la coppia finale come due primi tentativi equivalenti. L’assistenza fa parte del costo per arrivare a un risultato utilizzabile.

In un test completo del flusso di lavoro, lascia che gli agenti eseguano ed esaminino i propri artefatti con autorizzazioni comparabili. Registra gli strumenti effettivamente usati e ogni intervento umano necessario. Un agente che rileva e corregge un errore di caricamento svolge un lavoro utile che un confronto di sole schermate non coglierebbe.

Misura il costo senza inventare precisione

Il tempo trascorso è facile da rilevare e facile da interpretare male. La richiesta Codex qui ha impiegato circa 179 secondi, inclusi l’avvio e i timeout di individuazione dei modelli riportati nel log. Non è una misura pulita della velocità di generazione. Scrivere «Codex impiega tre minuti per animare» attribuirebbe alla misura più di quanto dimostri.

Per un confronto più utile, separa configurazione, tempo della richiesta, correzione, rendering e revisione umana dove gli strumenti lo consentono. Il tempo totale per ottenere un artefatto utilizzabile può contare più della latenza di risposta. Una prima bozza rapida che richiede diverse correzioni attente può costare più lavoro di una più lenta ma corretta.

Non dedurre un costo in denaro dal tempo trascorso o dal conteggio dei token senza conoscere il contesto di fatturazione effettivo. Uso in abbonamento, fatturazione API, input in cache e impostazioni del modello possono differire. Se non riesci a ottenere un costo attendibile, riporta le informazioni di utilizzo osservabili e lascia il costo non misurato.

Includi gli insuccessi nel quadro operativo, ma classificali. La configurazione dell’autenticazione è diversa da un modello che produce codice non valido. Un errore di dipendenza del rendering è diverso da un design illeggibile. La distinzione rende il confronto utile per scegliere sia lo strumento sia il flusso di lavoro che lo sostiene.

Ripeti compiti rappresentativi prima di trarre una conclusione generale. Una singola scena piccola può rivelare una modalità di errore. Non può stabilire che un agente sia generalmente migliore per lanci di prodotto, spiegazioni tecniche, grafici, localizzazione e ogni futuro lavoro di motion design.

Rendi visibile l’assistenza umana

Un confronto equo dovrebbe registrare il lavoro dell’operatore fra una richiesta e l’altra. Installare un pacchetto mancante, trovare una risorsa, correggere un nome di file o spiegare un errore può migliorare sensibilmente il risultato finale. Se quell’aiuto è invisibile, il confronto attribuisce all’agente il contributo umano.

Decidi quale assistenza appartiene al test. In un flusso realistico, un operatore può ragionevolmente rispondere a una domanda sul prodotto o approvare l’accesso a un file. In una prova controllata di generazione del codice, qualunque riparazione manuale del sorgente cambia l’artefatto valutato. Nessuno dei due approcci è intrinsecamente sbagliato; il problema è presentare l’uno come l’altro.

Conserva un breve registro degli interventi. Può indicare che l’operatore ha fornito la stessa schermata a entrambi i sistemi, ha chiarito una frase di fatturazione per entrambi o ha corretto un server locale prima di aprire i risultati. Se soltanto un sistema ha avuto bisogno di una correzione, registra anche questo. Il lavoro aggiuntivo può contare nella decisione del team, anche quando i risultati visivi finali sembrano altrettanto validi.

Separa l’apprendimento dell’operatore dalle prestazioni dell’agente nelle esecuzioni ripetute. Dopo aver testato il primo sistema, l’operatore può capire meglio il compito e guidare più utilmente il secondo. Alternare l’ordine di esecuzione o congelare tutti gli input prima di iniziare aiuta a ridurre questo vantaggio. Un piccolo studio locale non può eliminare ogni fonte di variazione, ma può renderla visibile.

Questa trasparenza è particolarmente preziosa nel motion design, perché la cura visiva invita a giudizi rapidi. Un risultato che ha richiesto attente regolazioni manuali dei tempi non dovrebbe essere descritto come una generazione in un solo tentativo e senza interventi. I lettori possono comunque apprezzarlo sapendo come è stato realizzato.

Pubblica un risultato che gli altri possano esaminare

Un confronto credibile include brief, risorse o istruzioni per acquisirle, registro dell’ambiente, output grezzi, prompt di revisione, impostazioni di rendering e controlli osservati. I lettori dovrebbero poter capire da dove proviene la conclusione senza doversi fidare di un’immagine di confronto accattivante.

Mantieni il risultato al livello del requisito: il testo esatto era corretto nello stato iniziale, la riproduzione ha raggiunto la fine e la ricerca temporale non funzionava prima della correzione. Una successiva esecuzione abbinata potrà usare lo stesso brief e gli stessi controlli per confrontare come gli agenti diagnosticano e rivedono l’artefatto.

Esamina l’output originale, la correzione indipendente e i registri del comportamento.