Claude Code und Codex mit demselben Motion-Briefing fair vergleichen

Zwei attraktive Videos sind noch kein fairer Vergleich zweier Coding-Agenten. Einer hat möglicherweise bessere Assets, einen ausführlicheren Prompt, eine zusätzliche Reparaturrunde oder Zugriff auf Werkzeuge erhalten, die dem anderen fehlten. Ein Screenshot mit beiden Ergebnissen nebeneinander verbirgt diese Unterschiede.

Bei Motion-Arbeiten kann diese Fehleinschätzung besonders leicht entstehen. Ein Modell liefert vielleicht einen beeindruckenden ersten Frame, verfehlt aber die zeitlichen Vorgaben. Ein anderes erstellt ein schlichtes, jedoch editierbares Projekt, das eine lokale Änderung übersteht. Welches besser ist, hängt von der Aufgabe ab, die du delegieren wolltest.

Für einen Vergleich von Claude Code und Codex bei Motion-Grafiken beginne mit derselben Abnahmeaufgabe und denselben Assets. Prüfe anschließend exakte Texte, Timing, Bedienelemente und den Reparaturaufwand bis zu einem brauchbaren Ergebnis. Das durchgearbeitete Beispiel verfolgt eine Codex-Ausgabe durch Wiedergabe, einen Fehler beim Ansteuern von Zeitpunkten und dessen Reparatur. Für den parallelen Durchlauf mit Claude Code war keine Authentifizierung möglich; ein direkter Modellvergleich steht deshalb noch aus.

Wähle eine Aufgabe, die die benötigte Fähigkeit sichtbar macht

„Erstelle ein schönes Produktvideo“ lässt zu viel Interpretationsspielraum. Ein besserer Test enthält eine echte Kommunikationsanforderung und einen klar begrenzten technischen Lieferumfang. Erstelle beispielsweise eine sechs Sekunden lange, editierbare Angebotsszene mit exakt vorgegebenen Preistexten, deterministischen Zeitsprüngen und einem gemeinsamen Leseintervall.

Die Szene kann visuell einfach sein und trotzdem wichtige Verhaltensweisen testen. Exakte Texte prüfen die Bewahrung von Fakten. Eine stabile Standphase prüft zeitliches Schlussfolgern. Ein Schieberegler für die Zeit prüft, ob die Animation zeitgesteuert ist oder auf einer Abfolge beruht, die nur beim Abspielen von Anfang an funktioniert. Eine lokale Änderung prüft, ob der Quelltext steuerbar bleibt.

Überlade den ersten Test nicht mit jeder denkbaren Funktion. Wenn du Sprechertext, Musik, Untertitel, Diagrammdaten, mehrere Seitenverhältnisse und eine komplexe Oberfläche aufnimmst, lassen sich Fehler nur schwer zuordnen. Nutze zuerst eine kleine repräsentative Aufgabe und ergänze dann eine zweite für Fähigkeiten, die die erste nicht sichtbar machen kann.

Entscheide, ob du Codegenerierung oder vollständige Agenten-Workflows vergleichst. In einem reinen Codetest lassen sich Werkzeuge konstant halten, indem du sie deaktivierst und ein eigenständiges Dokument verlangst. Ein Workflow-Test sollte jedem Agenten erlauben, Assets zu untersuchen, das Projekt auszuführen und Fehler mit vergleichbaren Berechtigungen zu reparieren. Das sind unterschiedliche Experimente, die nicht in einer gemeinsamen Rangliste aufgehen sollten.

Für ein Team, das ein Werkzeug einführen möchte, ist der Workflow-Test oft relevanter. Das nützliche Ergebnis ist nicht bloß Quelltext, sondern ein korrektes, editierbares Artefakt, das in einem praktikablen Prozess entsteht. Eine kleinere reine Codeprobe kann jedoch Anforderungen und Umgebungsprobleme aufdecken, bevor du Zeit in einen größeren Vergleich investierst.

Friere Briefing und Assets ein

Verwende für beide Durchläufe wortwörtlich dasselbe Briefing. Speichere es, bevor du einen der Agenten aufrufst. Entdeckst du nach dem ersten Ergebnis eine Unklarheit, überarbeite das Briefing für beide und behandle das neue Paar als weiteren Test, statt nur einem Agenten die Klarstellung zu geben.

Für die lokale Probe zu diesem Artikel verlangte das Briefing ein eigenständiges HTML-Dokument mit 1280 mal 720 Pixeln. Die fiktive Szene trug den Titel Still Studio und musste exakt die Aussagen „US$29 per month“ und „US$348 billed annually“ zeigen. Beide Zeilen sollten zwischen null und 0.8 Sekunden erscheinen, bis 4.8 Sekunden stabil bleiben und bis zur sechsten Sekunde verschwinden.

Außerdem verlangte das Briefing sichtbare Play/Pause- und Zeitsteuerungen, einen anfänglich pausierten Zeitpunkt bei 2.4 Sekunden, eine serifenlose Systemschrift, keine externen Assets und eine Kennzeichnung als fiktive Studie. Diese Vorgaben sollten die Ausgabe überprüfbar machen und Unterschiede durch externe Bilder oder Schriften vermeiden.

Text und Abrechnungsverhältnis sind entscheidend. Ein Modell, das den Jahresbetrag verändert, hat eine Faktenanforderung verfehlt, selbst wenn seine Typografie attraktiver ist. Ein Modell, das die Bedingung erst am Ende zeigt, hat eine zeitliche Vorgabe verfehlt, selbst wenn die richtigen Wörter im Quelltext stehen.

Wenn du echte Produkt-Assets einsetzt, stelle identische Kopien bereit und bewahre ihre Identität. Lass nicht einen Agenten einen neueren Screenshot oder ein anderes Logo verwenden. Darf ein Asset nicht weitergegeben werden, beschreibe die Zugriffsvoraussetzung und führe den Vergleich innerhalb der autorisierten Umgebung durch.

Dokumentiere die tatsächlich ausgeführte Umgebung

Der Name eines Werkzeugs bezeichnet nicht das vollständige System. Halte CLI-Version, das vom Durchlauf gemeldete Modell, relevante Einstellungen, verfügbare Werkzeuge, Berechtigungen und einen neuen oder fortgesetzten Sitzungszustand fest. Das Standardmodell kann sich im Laufe der Zeit ändern; deshalb ist das gemeldete Modell wichtiger als eine Annahme aufgrund des Produktnamens.

Trenne Kontozugriff und Modellleistung. Ein fehlgeschlagener Login, ein Ratenlimit oder eine Netzwerkunterbrechung kann den praktischen Workflow beeinträchtigen. Daraus ergibt sich aber keine Aussage über die Qualität eines Videos, das das Modell nie produziert hat. Bewahre solche Fehler im Protokoll, ohne sie in eine kreative Bewertung umzuwandeln.

Der Codex-Durchlauf nutzte die ChatGPT-Authentifizierung über den OpenAI-Provider. Sein Protokoll nennt CLI-Version 0.163.0 und das Modell gpt-6.1-sol; die Ausgabe ist ein eigenständiges HTML-Dokument.

Authentifizierung und Konfiguration verdienen ausdrückliche Aufmerksamkeit, weil sie unterschiedliche Zugangswege auswählen können. Ziehe die eigene Dokumentation des Werkzeugs heran und halte den tatsächlich genutzten Weg fest. Veröffentliche keine Tokens oder privaten Kontodateien in einem Benchmark-Paket. Dokumentation zur Authentifizierung von Claude Code

Bewahre unveränderte Ausgaben vor jeder Reparatur auf

Speichere die erste Antwort exakt wie empfangen, zusammen mit Briefing und Ausführungsstatus. Musst du Markdown-Codezäune entfernen, um ein HTML-Dokument zu öffnen, dokumentiere diese Umwandlung. Repariere Syntax nicht stillschweigend, um das Ergebnis anschließend als ursprünglichen Erstentwurf auszugeben.

Speichere fehlgeschlagene Anfragen getrennt von fertiggestellten Artefakten, damit das Testprotokoll Einrichtungsfehler von Ausgabemängeln unterscheidet.

Öffne bei einem reinen Codevergleich das zurückgegebene Dokument ohne Bearbeitung. Prüfe, ob die verlangten Wörter erscheinen, die Szene ohne externe Abhängigkeiten lädt und die Bedienelemente vorhanden sind. Spiele dann die gesamte Sequenz ab und springe direkt zu Einblendung, Standphase und Ausblendung.

Der Quelltext enthält außerdem einen Bereichsregler und eine zeitgesteuerte Renderfunktion. Nachfolgende Verhaltenstests zeigten, dass diese Bedienelemente zwar vorhanden waren, aber nicht vollständig funktionierten. Bei echter Wiedergabe lief die Zeit vom Anfangszustand über 3.1 Sekunden hinaus, erreichte sechs Sekunden und stoppte. Das direkte Ansteuern eines Zeitpunkts offenbarte einen anderen Fehler: Die angezeigte Zeit blieb beim alten Wert, statt zum angeforderten zu wechseln.

Bewerte zuerst die Bedeutung, dann den Stil

Beginne mit unverhandelbaren Anforderungen. Sind die Fakten exakt vorhanden? Stehen sie in der richtigen Beziehung zueinander? Kann der Zuschauer die vollständige Aussage im verlangten Intervall lesen? Verwendet die Ausgabe die bereitgestellten Assets, ohne Verhalten der Oberfläche zu erfinden?

Prüfe dann das zeitliche Verhalten. Springe direkt in die Mitte, an den Anfang, zur Grenze der Einblendung, zur Grenze der Ausblendung und ans Ende. Eine deterministische Animation sollte unabhängig vom Weg zum Zeitpunkt den erwarteten Zustand erzeugen. Hängt der Zustand davon ab, dass frühere Frames abgespielt wurden, eignet sich der Quelltext möglicherweise nicht für zuverlässiges Einzelbild-Rendering.

Erst nach diesen Prüfungen solltest du die visuelle Qualität vergleichen. Berücksichtige Hierarchie, Abstände, Typografie, Kohärenz der Bewegung und die Frage, wie gut die Komposition der Botschaft dient. Verankere dein Urteil im Briefing. Eine bewusst zurückhaltende Angebotsszene sollte nicht allein deshalb verlieren, weil eine andere Version mehr Spektakel hinzufügt.

Verwende ein kleines Bewertungsraster mit getrennt ausgewiesenen Dimensionen statt einer undurchsichtigen Gesamtnote. Faktentreue, Timing, Editierbarkeit, visuelle Kommunikation und zuverlässige Lieferung können unterschiedlich ausfallen. Ein einzelner Wert verdeckt den Zielkonflikt, den ein Team tatsächlich verstehen muss.

Was der Folgetest tatsächlich ergab

Der Fehler beim Ansteuern von Zeitpunkten ließ sich reproduzieren, nachdem die Wiedergabe sechs Sekunden erreicht hatte. Die Taste Home setzte die Ausgabe nicht auf null. Auch Eingabeereignisse für 0.8, 4.8 und 5.4 Sekunden ließen sie bei sechs Sekunden stehen. Das ist relevant, weil ein Editor einen bestimmten Zustand untersuchen muss, ohne die gesamte Sequenz erneut abzuspielen. Eine sichtbare Zeitleiste reicht nicht aus.

Die Ursache lag in der Ereignisreihenfolge. Der Eingabe-Handler rief pause() auf, bevor er den angeforderten Reglerwert auslas. In dieser Implementierung schrieb das Pausieren beim Rendern auch den alten Zustand zurück in den Regler. Das anschließende Auslesen lieferte deshalb den alten Wert. Die Animationsberechnung konnte korrekt sein, während das Bedienelement zu ihrer Prüfung defekt war.

Der Autor reparierte eine separate Kopie, indem er den angeforderten Wert vor dem Pausieren auslas und anschließend anwendete; die ursprüngliche Modellausgabe bleibt erhalten.

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

Die reparierte Kopie reagierte auf Home und End mit null beziehungsweise sechs Sekunden. Bei 0.8 und 4.8 Sekunden hatten beide Preiszeilen volle Deckkraft und keine Verschiebung. Bei 5.4 Sekunden hatten beide eine Deckkraft von 0.5 und waren um 18 Pixel nach oben verschoben.

Nach direkter Bearbeitung der contenteditable-Zeilen zu US$39 per month und US$468 billed annually blieben beide bei 2.4 Sekunden sichtbar. Ein Abnahmetest sollte als Nächstes diese Änderungen speichern, neu laden und rendern.

Das Ablesen der angezeigten Zeit ist der schnellste Weg, einen Wiedergabefehler von einem Fehler beim Zeitsprung zu unterscheiden. Hier läuft das Original bei der Wiedergabe normal weiter, verweigert aber anschließend die Anfrage nach einem bestimmten Zustand. Die Reparatur ändert die Reihenfolge im Ereignis-Handler und lässt die Ein- und Ausblendkurven unverändert. Für einen parallelen Agententest ergibt sich daraus eine präzise Reparaturaufgabe: Zeitsprünge reparieren, die Dauer von sechs Sekunden und beide Preiszeilen erhalten und danach Home, End sowie einen Zwischenzeitpunkt prüfen.

Nimm dieselbe lokale Änderung vor

Der Erstentwurf ist nur die halbe Aufgabe. Gib beiden erfolgreichen Durchläufen dieselbe Änderung: beispielsweise den monatlichen Vergleichsbetrag und die jährliche Belastung ändern, Layout und Timing bewahren und beide Aussagen gemeinsam sichtbar halten. Damit testest du, ob der Agent einen begrenzten Teil ändern kann, ohne den Rest unnötig neu zu schreiben.

Bewahre den ursprünglichen Quelltext auf und vergleiche die Überarbeitung damit. Prüfe Änderungen an Text, Geometrie, Timing, Bedienelementen und Asset-Verweisen. Eine optisch ähnliche Ausgabe kann einen defekten Zeitregler oder ein verschobenes Ende verbergen. Auch eine umfangreiche Quelltextänderung kann akzeptabel sein, wenn das resultierende Verhalten stimmt; sie sollte jedoch untersucht werden.

Lege das erlaubte Reparaturbudget vorher fest. Bekommt ein Agent drei zunehmend konkrete Prompts und der andere nur einen, weise diesen Unterschied aus, statt das letzte Paar als gleichwertige Erstversuche darzustellen. Unterstützung ist Teil des Aufwands bis zu einem brauchbaren Ergebnis.

Lass die Agenten in einem vollständigen Workflow-Test ihre eigenen Artefakte mit vergleichbaren Berechtigungen ausführen und untersuchen. Dokumentiere die tatsächlich verwendeten Werkzeuge und erforderlichen menschlichen Eingriffe. Ein Agent, der einen Ladefehler bemerkt und behebt, leistet nützliche Arbeit, die ein reiner Screenshot-Vergleich übersehen würde.

Miss Aufwand ohne vorgetäuschte Präzision

Die verstrichene Zeit lässt sich leicht erfassen und leicht fehlinterpretieren. Die Codex-Anfrage dauerte hier etwa 179 Sekunden, einschließlich Startzeit und der im Protokoll gemeldeten Zeitüberschreitungen bei der Modellerkennung. Das ist keine saubere Messung der Generierungsgeschwindigkeit. „Codex braucht drei Minuten zum Animieren“ würde mehr behaupten, als tatsächlich gemessen wurde.

Für einen nützlicheren Vergleich trenne Einrichtung, Anfragezeit, Reparaturzeit, Renderzeit und menschliche Prüfzeit, soweit die Werkzeuge das erlauben. Die Gesamtzeit bis zu einem brauchbaren Artefakt kann wichtiger sein als die Antwortlatenz. Ein schneller Erstentwurf mit mehreren sorgfältigen Reparaturen kann mehr Aufwand verursachen als ein langsameres korrektes Ergebnis.

Leite ohne den tatsächlichen Abrechnungskontext keine Dollarkosten aus Laufzeit oder Tokenzahl ab. Abonnementnutzung, API-Abrechnung, zwischengespeicherte Eingaben und Modelleinstellungen können sich unterscheiden. Fehlt eine vertrauenswürdige Kostenangabe, berichte die beobachtbaren Nutzungsinformationen und lass die Kosten ungemessen.

Nimm Fehlschläge in die betriebliche Betrachtung auf, aber ordne sie ein. Die Einrichtung der Authentifizierung ist etwas anderes als ungültiger Code eines Modells. Eine fehlgeschlagene Renderabhängigkeit unterscheidet sich von einem unlesbaren Design. Diese Unterscheidung macht den Vergleich sowohl für die Werkzeugwahl als auch für den unterstützenden Workflow nützlich.

Wiederhole repräsentative Aufgaben, bevor du weitreichende Schlussfolgerungen ziehst. Eine einzelne kleine Szene kann einen Fehlertyp offenlegen. Sie kann nicht belegen, dass ein Agent generell besser bei Produktstarts, technischen Erklärungen, Diagrammen, Lokalisierung und allen künftigen Motion-Aufgaben ist.

Mache menschliche Unterstützung sichtbar

Ein fairer Vergleich sollte die Arbeit dokumentieren, die der Bediener zwischen Anfragen erledigt. Ein fehlendes Paket installieren, ein Asset finden, einen Dateinamen korrigieren oder einen Fehler erklären kann das Endergebnis wesentlich verbessern. Bleibt diese Hilfe unsichtbar, schreibt der Vergleich den menschlichen Beitrag dem Agenten zu.

Entscheide, welche Unterstützung zum Test gehört. In einem realistischen Workflow kann ein Bediener sinnvollerweise eine Produktfrage beantworten oder Dateizugriff genehmigen. Bei einer kontrollierten Codegenerierungsprobe verändert jede manuelle Quelltextreparatur das bewertete Artefakt. Keiner der beiden Ansätze ist grundsätzlich falsch; problematisch ist, den einen als den anderen auszugeben.

Führe ein kurzes Eingriffsprotokoll. Darin kann stehen, dass der Bediener beiden Systemen denselben Screenshot bereitgestellt, für beide eine Abrechnungsformulierung präzisiert oder vor dem Öffnen beider Ergebnisse einen lokalen Server repariert hat. Brauchte nur ein System eine Reparatur, halte auch das fest. Der Mehraufwand kann für die Entscheidung des Teams relevant sein, selbst wenn die fertigen Ergebnisse gleich gut aussehen.

Trenne bei wiederholten Durchläufen den Lerneffekt des Bedieners von der Agentenleistung. Nach dem ersten System versteht der Bediener die Aufgabe möglicherweise besser und gibt dem zweiten hilfreichere Hinweise. Eine wechselnde Reihenfolge oder das Einfrieren aller Eingaben vor dem Start hilft, diesen Vorteil zu verringern. Eine kleine lokale Studie kann nicht jede Schwankungsquelle beseitigen, aber sie kann sie sichtbar machen.

Gerade bei Motion-Arbeiten ist diese Transparenz wertvoll, weil visuelle Ausarbeitung zu schnellen Urteilen einlädt. Ein Ergebnis, das sorgfältige manuelle Timing-Anpassungen brauchte, sollte nicht als unveränderte Generierung in einem einzigen Versuch bezeichnet werden. Leser können es weiterhin bewundern und zugleich nachvollziehen, wie es entstand.

Veröffentliche ein überprüfbares Ergebnis

Ein glaubwürdiger Vergleich enthält Briefing, Asset-Satz oder Beschaffungsanweisungen, Umgebungsprotokoll, unveränderte Ausgaben, Änderungsprompts, Render-Einstellungen und beobachtete Prüfungen. Leser sollten die Grundlage deiner Schlussfolgerung verstehen können, ohne einem attraktiven Vergleichsbild vertrauen zu müssen.

Bleibe mit dem Ergebnis auf der Ebene der Anforderung: Exakte Texte waren im Anfangszustand korrekt, die Wiedergabe erreichte das Ende, und Zeitsprünge scheiterten vor der Reparatur. Ein späterer paralleler Durchlauf kann dasselbe Briefing und dieselben Prüfungen nutzen, um zu vergleichen, wie die Agenten das Artefakt diagnostizieren und überarbeiten.

Originalausgabe, unabhängige Reparatur und Verhaltensprotokolle ansehen.