Der blinde Richter: Bewertung von Claude Code vs. Codex in 36 Duellen

Thomas Ricouard (@Dimillian) hat es besser formuliert als jeder Benchmark: „Claude Code ist wie ein sehr, sehr mittelmäßiges Refactoring, von dem ich weiß, dass er es durchführen kann. Codex ist eine hochmoderne Architektur. Ich bin mir noch nicht sicher, ob er das tatsächlich umsetzen kann, ohne etwas kaputtzumachen.”¹

Ich hörte auf zu spekulieren und begann zu messen. Ich baute ein System, das Claude Code gegen Codex CLI bei derselben Aufgabe antreten lässt, die Ergebnisse zufällig als Alpha und Beta bezeichnet und beide Pläne blind in fünf Dimensionen bewertet, bevor enthüllt wird, welcher Agent welchen geschrieben hat. Sechsunddreißig Duelle später sagt die Anzeigetafel, dass Claude 8 von 12 entschiedenen Duellen gewonnen hat. Aber die Anzeigetafel ist nicht der Punkt. Der Punkt ist, was der blinde Richter nach der Bewertung produziert: eine Synthese, die die stärksten Elemente beider Pläne zu etwas Besserem kombiniert, als es ein einzelner Teilnehmer allein geliefert hat.

Kurzfassung

Sechsunddreißig Duelle. Blinde Bewertung in fünf Dimensionen (Korrektheit, Vollständigkeit, Einfachheit, Zerlegung, Umsetzbarkeit). Claude Code gewann 8, Codex CLI gewann 3, eines unentschieden, über 13 Duelle mit strukturierten Urteilsprotokollen (12 mit einem erklärten Gewinner). Das eigentliche Ergebnis ist kein Gewinner. Es ist der Syntheseschritt, der die besten Elemente aus beiden Plänen auswählt und ein Umsetzungsbriefing erstellt, das stärker ist als das jedes einzelnen Agenten. Der Begleitbeitrag Denken mit zehn Gehirnen behandelt kollaborative Deliberation.¹² Der blinde Richter behandelt kompetitive Evaluation. Die Methodik ist wichtiger als die Anzeigetafel.

Warum Vergleiche schwierig sind

Alle vergleichen gerade KI-Coding-Agenten. Niemand ist sich über die Ergebnisse einig.

Das Problem ist strukturell. Modellvergleiche degenerieren entlang dreier Achsen: Bauchgefühl (Sie haben eine Aufgabe mit jedem getestet und sind Ihrer Intuition gefolgt), Aktualitätsbias (der letzte Erfolg überschreibt alle vorherigen Fehlschläge) und aufgabenspezifische Stärken (das Modell, das bei Ihrem Refactoring gewinnt, verliert bei Ihrem Sicherheitsreview). Das sind keine schlechten Beobachtungen. Es sind schlechte Experimente.

Alex Finn (@AlexFinn) betreibt einen dualen Validierungs-Workflow, bei dem zwei Modelle gegenseitig ihre Ergebnisse prüfen.² Der Dual-Check-Ansatz fängt Fehler ab, die jedes einzelne Modell allein übersehen würde. Die Erkenntnis ist fundiert: unabhängige Bewertung deckt Meinungsverschiedenheiten auf, und in den Meinungsverschiedenheiten verstecken sich die Bugs.

@doodlestein betreibt 10+ Agenten gleichzeitig — Claude, Codex und Gemini — mit vorgefertigten Prompts, die er „Ideenzauberer” nennt, um dasselbe Problem aus verschiedenen Blickwinkeln anzugehen.³ Ein Planer, der in der Zerlegung hervorragend ist, könnte einen Korrektheitsfehler übersehen, den ein detailorientierterer Agent sofort erkennt.

Beide Workflows verbessern die Einzelmodell-Bewertung. Keiner eliminiert die größte Bedrohung: den Bestätigungsfehler. Wenn Sie wissen, welches Modell welchen Plan geschrieben hat, werden Sie das Modell, dem Sie mehr vertrauen, großzügiger bewerten. Jedes Mal. Nicht weil Sie nachlässig sind, sondern weil Voreingenommenheit unterhalb der bewussten Wahrnehmung wirkt. Das fehlende Stück ist die Verblindung. Wenn der Bewerter nicht weiß, welcher Agent welches Ergebnis produziert hat, hat der Bestätigungsfehler nichts, woran er sich festhalten kann.

Das blinde Bewertungsprotokoll

Das /duel-System arbeitet in fünf Phasen:

1. Parallele Ausführung. Beide Agenten erhalten denselben Aufgaben-Prompt und Projektkontext. Claude Code läuft in einem Prozess, Codex CLI in einem anderen. Keiner sieht die Ausgabe des anderen.
2. Zufällige Bezeichnung. Ein Münzwurf weist einen Agenten „Alpha” und den anderen „Beta” zu. Das System schreibt die Zuordnung in agent-mapping.json und versiegelt sie. Weder der Richter noch ich sehen die Zuordnung bis nach der Bewertung.
3. Blinde Bewertung. Ein Richter-Agent liest beide Pläne und bewertet jeden in fünf Dimensionen, 0–4 Punkte pro Dimension, maximal 20 Punkte insgesamt. Der Richter sieht nur „Alpha-Plan” und „Beta-Plan”.
4. Gewinnerempfehlung. Der Richter erklärt einen Gewinner (oder unentschieden) mit einem Konfidenzniveau und schriftlicher Begründung.
5. Synthese. Der Richter kombiniert die stärksten Elemente beider Pläne zu einem verfeinerten Umsetzungsbriefing. Die Synthese ist das eigentliche Ergebnis.

Die fünf Bewertungsdimensionen:

Die zentrale Designentscheidung: Die Synthese ist keine 50/50-Mischung. Sie gewichtet stark die Kernstrategie des Gewinners und wählt gezielt echte Erkenntnisse des Verlierers aus. Frühe Versuche mit gleichgewichteter Synthese produzierten inkohärente Pläne, die die schlechtesten Eigenschaften beider erbten. Gewichtete Synthese produziert Pläne, die strukturell solide (vom Gewinner) und gründlich gehärtet (durch die validen Grenzfälle des Verlierers) sind.

Fallstudie: Das Sicherheitsbehebungs-Duell

Im Februar 2026 fand ein Drei-Agenten-Sicherheitsaudit 7 KRITISCHE und 7 HOHE Befunde in ResumeGeni, einer FastAPI-Anwendung mit Supabase-Authentifizierung und Stripe-Zahlungen.⁴ Ich hatte bereits zwei triviale Korrekturen ausgeliefert. Neun blieben übrig. Ich führte ein Duell durch, um den Behebungsplan zu erstellen.

Beide Agenten erhielten dasselbe Briefing: die Befundliste mit Dateipfaden und Zeilennummern, den Architekturkontext, die Einschränkung, dass ein bewährtes Korrekturmuster bereits in einer Datei existierte, und die Anforderung, einen phasenweisen Deployment-Plan zu erstellen.

Alphas Plan: 11 Stories für 9 Befunde, organisiert in drei Deployment-Wellen. Eine Test-Baseline-Story (SEC-01) blockierte alle nachfolgenden Arbeiten. Deployment-Gates mit spezifischen Metriken: Authentifizierungserfolgsrate, 5xx-Monitoring, Webhook-Ablehnungszähler. Gründliche Diskussion verworfener Alternativen. Stories verwendeten eine Was/Warum/Erfolg-Struktur mit Zeilenbereichen.

Betas Plan: Direkte 1:1-Zuordnung von Befunden zu Stories. Drei Deployment-Wellen: Kritische als einzelne Einheit, Hochprioritäre als unabhängig deploybar, Bereinigung. Untersuchung-vor-Korrektur für den Middleware-Befund. Spezifische Zeilennummern, Funktionsnamen, Import-Pfade und curl-Befehle zur Verifikation pro Story.

Die Korrektheitslücke erzählte die Geschichte. Beta erkannte zwei Dinge, die Alpha vollständig übersah.

Erstens: Der Middleware-Befund (C3) markierte get_user(jwt=...) als Vektor für Session-Kontamination. Beta identifizierte korrekt, dass get_user() ein zustandsloser Verifikationsaufruf ist. gotrue-py ruft _save_session() nur in verify_otp und exchange_code_for_session auf, nicht in get_user. Alpha behandelte es als definitiv derselben Korrektur bedürftig wie die anderen beiden Router, was unnötigen Pro-Request-Overhead bei jeder authentifizierten Anfrage hinzufügen würde. Beta sagte: erst untersuchen, nur bei Bestätigung beheben.

Zweitens: Die Magic-Link- und Passkeys-Router verwenden sowohl admin.generate_link() (das den SERVICE_KEY-Singleton erfordert) als auch verify_otp() (das einen frischen Per-Request-Client benötigt). Alphas Plan wandte das Fresh-Client-Muster einheitlich an. Ein Entwickler, der diesem Plan folgt, würde Admin-Operationen zerstören. Beta rief die Aufteilung explizit auf: frischer Client für verify_otp, gemeinsamer Singleton für admin.generate_link().

Die Bewertungen:

Alpha war Codex. Beta war Claude. Hohe Konfidenz.⁴

Die Synthese kombinierte Betas technische Präzision mit Alphas operativer Stringenz. Hier ist eine Story aus dem Syntheseergebnis, die zeigt, wie beide Pläne zusammengeführt wurden:

Story 1.1 (C1 — Magic Link Shared Singleton): In magic_link.py _create_auth_client() hinzufügen. Frischen Anon-Client NUR für verify_otp verwenden (Zeile 224). Gemeinsamen Singleton für admin.generate_link() beibehalten (Zeile 213), der den SERVICE_KEY benötigt.

Diese Story erbt Betas präzise Zeilennummern und die kritische Admin/Anon-Client-Aufteilung, eingebettet in eine Struktur, die sich in Alphas Drei-Wellen-Deployment-Sequenz einfügt. Die vollständige Synthese behielt Betas Untersuchung-zuerst-Ansatz für C3, Betas spezifische curl-Verifikationsbefehle, Alphas Deployment-Gates (Monitoring der Authentifizierungserfolgsrate, 5xx-Tracking) und Alphas Regressionsteststrategie (E2E Playwright-Auth-Suite nach Welle 1, Stripe-Test-Webhook nach Welle 2). Das Ergebnis: ein 3-Wellen-Plan mit 12 Stories, umsetzbar innerhalb eines Tages, mit operativen Leitplanken, die kein Plan allein geboten hätte.

Die Anzeigetafel (und warum sie in die Irre führt)

Über 36 Duelle hinweg produzierten 13 strukturierte Urteilsprotokolle. Ein Protokoll erklärte unentschieden, womit 12 mit einem klaren Gewinner blieben:

Claude: 8. Codex: 3. Unentschieden: 1.¹¹

Behandeln Sie die Anzeigetafel nicht als Modell-Benchmark. Das ist sie nicht.

Die Siege von Claude konzentrieren sich auf Review-, Verifikations- und Sicherheitsaufgaben: 7 von 8 Siegen sind Hochkonfidenz-Ergebnisse bei Aufgaben, die Code-Review, Sicherheitsanalyse oder technische Evaluation beinhalten. Codex’ einziger Hochkonfidenz-Sieg kam bei einer Code-Review-Aufgabe, bei der seine prozedurale Gründlichkeit und expliziten Abhängigkeitsketten Claude’s weniger strukturierten Ansatz übertrafen. Die anderen beiden Siege waren mit niedriger Konfidenz. Das Muster: Claude produziert umsetzbarere, technisch präzisere Pläne. Codex produziert stärkere operative Prozesse und breitere theoretische Abdeckung.

Ricouard hatte recht. Planungsqualität versus Ausführungszuverlässigkeit ist eine reale Achse.¹ Aber die Anzeigetafel spiegelt meinen Aufgabenmix wider (schwerpunktmäßig Sicherheits- und Architektur-Reviews), nicht irgendein objektives Modell-Ranking. Jemand, der Duelle bei Greenfield-Funktionsentwicklung oder Infrastrukturautomatisierung durchführt, würde wahrscheinlich andere Ergebnisse sehen. Nathan Lamberts Analyse der Post-Benchmark-Ära macht denselben Punkt: Traditionelle Benchmarks vermitteln kein aussagekräftiges Signal mehr, wenn die feinen Unterschiede zwischen Opus 4.6 und Codex 5.3 von Aufgabenform und Bewertungsmethodik abhängen.¹⁰

Die Anzeigetafel sagt etwas über meinen Workflow aus. Sie sagt nicht, welches Modell „besser” ist.

Die Synthese ist das Produkt

Der gewinnende Plan ist nicht der Punkt. Die Synthese ist es.

Jedes Duell produziert drei Artefakte: Plan Alpha, Plan Beta und die Synthese. Die Synthese folgt einer konsistenten Struktur: die Kernstrategie des Gewinners übernehmen, die validen Grenzfälle des Verlierers einarbeiten, unnötigen Umfang aus beiden entfernen. Sie ist nicht diplomatisch. Sie teilt nicht den Unterschied auf. Sie trifft explizite Entscheidungen darüber, welche Elemente behalten und welche verworfen werden, mit schriftlicher Begründung für jede.

Im Duell zur Job-Korpus-Erweiterung aktivierte Claude’s Plan zuerst die bestehende Infrastruktur (Seed-Skripte für 8.780 bekannte Boards, die das System noch nicht abfragte), expandierte dann zu neuen ATS-Plattformen und baute dann Entdeckungssysteme.⁶ Codex’ Plan begann mit einem Codebase-Audit und einer Instrumentierungsspezifikation, bevor ein einziger Job erfasst wurde. Claude gewann bei Einfachheit und Umsetzbarkeit. Aber Codex identifizierte etwas, das Claude übersah: die Notwendigkeit einer Board-Lebenszyklus-Zustandsmaschine (aktiv/fehlerhaft/quarantänisiert). Codex markierte außerdem ein Deduplizierungs-Regressionsaudit, um zu verhindern, dass die Volumenerweiterung eine Duplikatexplosion verdeckt. Die Synthese behielt Claude’s Aktivierung-zuerst-Sequenzierung und integrierte Codex’ Beobachtbarkeits- und Lebenszyklus-Tracking als Phase 1.5, nachdem die initiale Befüllung messbare Ergebnisse geliefert hatte. Dasselbe Muster trat im Duell zum Job-Erfassungssystem auf, wo Claude’s Plan den bestehenden APScheduler und Registry-Tabellen wiederverwendete, während Codex ein gründlicheres Zwei-Tabellen-Provenienz-Schema vorschlug. Die Synthese übernahm Claude’s pragmatische Architektur und wählte gezielt Codex’ Verbesserung des Deduplizierungs-Hashs aus.⁷

Im ATS-Review-Duell fand Claude P0-Laufzeitabstürze (Methodensignatur-Mismatches im Scheduler, die stillschweigend das Job-Tracking unterbrechen würden), die Codex vollständig übersah.⁵ Codex fand Scheduler-Überlappungsprävention und Admin-Endpoint-Missbrauchsvektoren, die Claude nicht markierte. Die Synthese begann mit Claude’s P0-Korrekturen und ergänzte sie mit Codex’ operativer Härtung.

Das Muster über 36 Duelle: Das Richtermodell produziert konsistent Synthesen, die stärker sind als der Plan jedes einzelnen Teilnehmers. Der Richter ist nicht klüger. Die adversariale Struktur erzwingt vollständige Abdeckung.⁹ Jeder Agent identifiziert unabhängig Risiken und Grenzfälle. Der Richter sieht sie alle. Die Synthese erbt die Vereinigung der Erkenntnisse beider Agenten minus ihrer individuellen blinden Flecken.

Das Muster verbindet sich mit einer breiteren Erkenntnis aus der Multi-Agenten-Deliberation: Unabhängigkeit ist der Mechanismus. Zehn Deliberationsagenten, die eine Entscheidung aus verschiedenen Perspektiven bewerten, erkennen Verzerrungen, die jeder einzelne Agent übersieht. Zwei duellierenden Agenten, die dieselbe Aufgabe aus verschiedenen Architekturen angreifen, erkennen Implementierungslücken, die jeder Agent allein ausliefern würde. Der Syntheseschritt ist in beiden Systemen derselbe: unabhängige Bewertungen zu einem einzelnen Artefakt kombinieren, das von allen Perspektiven profitiert.

Ich dokumentiere die Orchestrierungsschicht, die beide Systeme unterstützt, separat. Was hier zählt, ist, dass Duellieren und Deliberation komplementäre Funktionen erfüllen. Deliberation beantwortet: „Sollen wir das bauen?” Duellieren beantwortet: „Was ist der stärkste Weg, es zu bauen?”

Wann duellieren, wann deliberieren

Beide Systeme nutzen unabhängige Bewertung und Synthese. Sie dienen unterschiedlichen Entscheidungstypen.

Mein Muster: das Design deliberieren, den Umsetzungsplan duellieren, die Synthese ausführen.

Eine Sicherheitsbehebungsentscheidung durchläuft zuerst die Deliberation („Ist dies die richtige Priorisierung? Übersehen wir systemische Probleme?”), dann das Duellieren („Was ist der stärkste phasenweise Plan zur Umsetzung dieser Korrekturen?”), dann die Ausführung anhand der Richtersynthese. Das Deliberationssystem und das Duellsystem teilen sich die Infrastruktur, dienen aber unterschiedlichen Zwecken in der Entscheidungspipeline.

Was ich falsch gemacht habe

Frühe Duelle hatten keine blinde Bezeichnung. Ich las beide Pläne und wusste, welches Modell welchen geschrieben hatte. Bestätigungsfehler waren real und messbar: Ich bewertete Claude bei der Umsetzbarkeit durchweg höher vor der Verblindung und sah dann die Lücke schrumpfen (wenn auch nicht verschwinden) nach Einführung der zufälligen Alpha/Beta-Zuweisung. Das Verblindungsprotokoll ist nicht optional.

Ich begann mit drei Bewertungsdimensionen (Korrektheit, Vollständigkeit, Umsetzbarkeit). Nach zwei Duellen erkannte ich, dass ich Planstruktur mit Planinhalt vermischte. Das Hinzufügen von Einfachheit (Ist das überentwickelt?) und Zerlegung (Sind die Schritte gut geordnet?) trennte diese Anliegen und produzierte nützlichere Bewertungen.

Erste Syntheseversuche mischten beide Pläne gleichmäßig. Die Ergebnisse waren inkohärent: Alphas Teststrategie auf Betas Deployment-Sequenz aufgepfropft, wobei die Annahmen keines Plans hielten. Gewichtete Synthese, bei der der Richter explizit das Rahmenwerk des Gewinners übernimmt und selektiv Erkenntnisse des Verlierers einarbeitet, war der Durchbruch.

N=36 bei meinem Aufgabenmix ist kein Modell-Benchmark. Es ist eine Bewertung eines Workflow-Werkzeugs. Das Duellsystem sagt mir, welcher Agent den stärkeren Plan für meine spezifische Aufgabe in meiner spezifischen Codebase produziert hat. Auf „Claude ist besser als Codex” zu extrapolieren, wäre dasselbe Bauchgefühl-basierte Schlussfolgern, das das System zu eliminieren existiert.

Ich verwende Claude als Richter für Duelle zwischen Claude und Codex. Ich erkenne den Konflikt an.⁸ Die Absicherung ist strukturell: blinde Bezeichnung, strukturierte Dimensionen und die Tatsache, dass Codex 3 Duelle gewann und bei mehreren anderen nah dran war. Ein stärkerer Test würde dieselben Duelle durch einen Nicht-Claude-Richter (Gemini oder GPT) laufen lassen und Bewertungsverteilungen vergleichen. Das habe ich noch nicht getan. Bis dahin sollte die 8:3-Aufteilung ein Sternchen tragen: Der Richter und ein Teilnehmer gehören zur selben Modellfamilie.

Referenzen