Ich habe vier echte Engineering-Aufgaben noch einmal von Claude Code und Codex bearbeiten lassen, dreimal je Agent. Die Frage war, ob meine alte Faustregel “Claude plant, Codex debuggt” noch stimmt. Tut sie nicht. Eher das Gegenteil.
Ich hatte eine Faustregel für die Wahl des Coding-Agenten
Hi, ich bin Nam. Ich bin Software-Engineer bei ellamind, und Claude Code und Codex erledigen jeden Tag einen großen Teil meiner Arbeit.
Irgendwann fühlten sie sich nicht mehr austauschbar an.
Meine Faustregel war:
- Claude bekommt die vagen Probleme. Er schien besser darin, eine Codebase zu erkunden, eine unscharfe Anforderung zu verstehen und daraus einen Plan zu machen.
- Codex bekommt die fokussierten, schwierigen Probleme. Wenn es einen harten Bug mit genau einer richtigen Antwort gab, blieb er eher dran, bis er sie gefunden hatte.
Dann las ich einen Artikel, der ungefähr dasselbe argumentierte: Claude als Entdecker, Codex als fokussierter Umsetzer und Debugger. Das deckte sich vollständig mit meiner Erfahrung.
Nur ist der Artikel ein paar Monate alt. Ich wollte wissen, ob meine Regel noch gilt, und zwar nicht nur nach Bauchgefühl.
Also habe ich mir einen kleinen Benchmark gebaut.
Vier Aufgaben, die mich ohnehin beschäftigt haben
Bei ellamind arbeite ich an zwei Produkten:
- elluminate hilft dabei, KI-Systeme zu testen und zu evaluieren.
- ellarun führt KI-Agenten in isolierten, kontrollierten Umgebungen aus.
Aus jedem Produkt habe ich eine Planungs-Aufgabe und eine Debugging-Aufgabe genommen.
| Produkt | Planung | Debugging |
|---|---|---|
| elluminate | Aufgabenspezifische Evaluationskriterien entwerfen | Einen monatelang offenen Produktions-Alert diagnostizieren |
| ellarun | Einen Architektur-Umbau für mehr Zuverlässigkeit planen | Einen irreführenden Authentifizierungs-Bug diagnostizieren |
Die Sammlung mit vier Aufgaben: je eine Planungs- und eine Debugging-Aufgabe pro Produkt.
Das waren keine Spielaufgaben. Es war Arbeit, an der wir uns real schon abgearbeitet hatten. Ich wusste also, wie eine brauchbare Antwort aussieht und welche verlockenden Irrwege ein Agent nehmen kann.
Aufgabe 1: Ein elluminate-Feature nicht überbauen. Das Feature klingt simpel: Was als “gut” zählt, kann von der konkreten Aufgabe abhängen, also wollten wir aufgabenspezifische Kriterien. Die Gefahr war der Scope. Das bestehende Datenmodell war sperrig, und ich malte mir einen großen, invasiven Umbau aus, viel mehr als das Produkt brauchte. Ein guter Planungs-Agent sollte diese Falle erkennen und die kleinste sinnvolle Änderung empfehlen.
Aufgabe 2: Ein wiederkehrender elluminate-Produktionsbug. Dieser Alert war “behoben”, abgehakt, und kam dann wieder. Fünfmal, über rund sechs Monate. Wir haben das Deployment-Timing verdächtigt, die falsche Datenbank, den Cloud-Anbieter, und hielten den Fehler dann für harmlos. Frühere Agenten-Sessions haben Hypothese um Hypothese durchgespielt und kamen nicht weiter.
Aufgabe 3: ellarun auf Zuverlässigkeit umbauen. ellarun wurde schnell gebaut, damit wir schnell lernen, und die Zuverlässigkeitsprobleme folgten: Agenten starben mitten im Run, Statusänderungen waren fragil, getrennte Bugs wuchsen aus derselben Schwäche. Mein Kollege Daniel hat den echten Umbau geleitet: mehrere Tage Recherche und Entwürfe, um die entscheidenden Fragen zu finden und attraktive, aber unnötige Arbeit zurückzustellen.
Aufgabe 4: Der ellarun-Bug, aus dem mein Bauchgefühl entstand. Im Ticket stand die falsche Diagnose. Frühere Claude-Sessions haben sich stundenlang zwischen Hypothesen bewegt. Codex fand die echte Ursache und verifizierte einen Fix sehr viel schneller. Deshalb dachte ich, Codex sei beim harten Debugging einfach besser. Der neue Durchlauf gibt Claude eine zweite Chance.
Gleiche Aufgabe, gleicher historischer Stand
Ich habe jede Umgebung so rekonstruiert, wie sie zum Zeitpunkt der ursprünglichen Arbeit aussah: derselbe Repository-Stand, derselbe Ticket-Kontext, inklusive der irreführenden Diagnose, wo es eine gab.
Die Runs liefen im August 2026, mit Claude Code 2.1.220 und Claude Opus 5 sowie Codex CLI 0.146.0 und GPT-5.6-sol, beide auf High Reasoning. Max oder Ultra Reasoning würde im Benchmark beeindruckender aussehen, hätte aber wenig damit zu tun, wie ich tatsächlich arbeite. Mein Kontingent ist nicht unbegrenzt, und bei Ihnen ist das vermutlich genauso ;)
Was ist ein guter Run?
Jeder Run bekommt dieselben Basis-Checks:
- Hat der Agent ein Credential offengelegt?
- Hat er eine Behauptung aufgestellt, die seine eigene Evidenz nicht hergibt?
- Hat er das geforderte Ergebnis tatsächlich geliefert?
Dazu bekommt jede Aufgabe Kriterien für das, worauf es in der jeweiligen Situation ankam. (Ja, hier sehen Sie das Ergebnis von Aufgabe 1 in Aktion. Sehr meta, ich weiß.)
Bei der Planung interessierten mich Fragen wie:
- Hat der Agent die Entscheidungen identifiziert, auf die es wirklich ankam?
- Hat er tragfähige Alternativen verglichen und einen konkreten Trade-off benannt?
- Hat er eine Empfehlung ausgesprochen statt einer endlosen Übersicht?
- Hat er Non-Goals gesetzt und Scope Creep widerstanden?
Aufgabenspezifische Kriterien machen aus der Planungsaufgabe eine Frage von Scope-Disziplin und brauchbaren Design-Entscheidungen, nicht nur die Frage, ob der Agent einen langen Plan geschrieben hat.
Beim Debugging waren mir andere Dinge wichtig:
- Hat er die falsche Diagnose im Ticket verworfen?
- Ist er zur eigentlichen Ursache vorgedrungen, statt ein Symptom zu flicken?
- Hat er den Bug reproduziert, bevor er Code geändert hat?
- Deckt der Regressionstest die falsche Annahme ab?
- Hat er den geänderten Pfad nach dem Fix end-to-end durchlaufen?
Genau diese Fragen unterscheiden “eine Theorie gehört und gutgläubig übernommen” von “die echte Fehlfunktion reproduziert, behoben und verifiziert”.
Pro Planungs-Run gibt es 21 Ja/Nein-Kriterien, pro Debugging-Run 18. Das ist schon für ein einziges Run-Paar zu viel, um es im Kopf zu behalten.
Warum 24 Runs statt einer Demo?
Agenten schwanken. Ich wollte keinen Sieger küren, nur weil eine Session besonders gut oder besonders schlecht lief.
Also habe ich jede Zelle dreimal wiederholt:
Das ergab 24 lange Trajektorien und viele verschiedene Arten, wie ein Agent gelingen oder scheitern kann.
Die Runs nach elluminate bringen
Die Agenten liefen lokal in den rekonstruierten Umgebungen. Danach habe ich jede vollständige Trajektorie nach ATIF (Agent Trajectory Interchange Format) konvertiert, ein verbreitetes Trace-Format, und nach elluminate hochgeladen.
Es gibt zwei Experimente: eins für Claude, eins für Codex. Die drei Wiederholungen sind drei Epochen je Experiment.
Nach dem Upload macht elluminate drei Dinge:
- Evaluieren: jeden Run an den gemeinsamen und den aufgabenspezifischen Kriterien bewerten.
- Annotieren: lange Trajektorien in strukturierte Phasen, Ergebnisse und auffällige Fehler überführen.
- Zusammenfassen: Muster über das Experiment hinweg finden, ohne dass ich alle 24 Transkripte noch einmal lesen muss.
Jeder hochgeladene Run lässt sich öffnen und Schritt für Schritt nachspielen.
Ergebnisse: Claude Code und Codex insgesamt unentschieden
Die Kurzfassung: Überraschung! Codex war bei den Planungsaufgaben besser. Claude war bei den Debugging-Aufgaben besser. Über alle vier Aufgaben hinweg stand es exakt unentschieden.
Die elluminate-Übersicht weist für beide Experimente 92,3 % aus, weil sie das automatisch erzeugte Overall Rating mitzählt.
Pro Planungs-Run sind 21 Kriterien zu bewerten, pro Debugging-Run 18: insgesamt 468 Bewertungen.
| Aufgabentyp | Claude Code | Codex | Was der Vergleich sagt |
|---|---|---|---|
| Planung (Aufgaben 1 + 3) | 113 / 126 (89,7 %) | 119 / 126 (94,4 %) | Codex mit 6 Bewertungen vorn |
| Debugging (Aufgaben 2 + 4) | 102 / 108 (94,4 %) | 96 / 108 (88,9 %) | Claude mit 6 Bewertungen vorn |
| Alle vier Aufgaben | 215 / 234 (91,9 %) | 215 / 234 (91,9 %) | Unentschieden |
Das reicht schon, um meine ursprüngliche saubere Erzählung zu beerdigen. Codex ist inzwischen absolut ein ernstzunehmender Planungs-Agent, jedenfalls bei diesen Aufgaben. Aber “Codex ist besser beim harten Debugging” übersteht den vollständigen Benchmark ebenfalls nicht.
Die drei Wiederholungen sind wichtig
| Aufgabe | Claude Code, Epochen 1 / 2 / 3 | Codex, Epochen 1 / 2 / 3 | So zu lesen |
|---|---|---|---|
| 1. elluminate Planung | 19/21 · 20/21 · 17/21 | 20/21 · 19/21 · 18/21 | Unentschieden |
| 2. elluminate Debugging | 16/18 · 16/18 · 18/18 | 15/18 · 14/18 · 13/18 | Claude gewinnt |
| 3. ellarun Planung | 18/21 · 18/21 · 21/21 | 20/21 · 21/21 · 21/21 | Codex gewinnt durchgängig |
| 4. ellarun Debugging | 17/18 · 18/18 · 17/18 | 18/18 · 18/18 · 18/18 | Zu einfach! |
Codex redet weniger
Codex brauchte halb so viele Agenten-Schritte: Median 56 gegenüber Claudes 114. Auch der Median der Output-Tokens lag deutlich niedriger: rund 24k gegenüber 125k.
Bei der Laufzeit lagen beide näher beieinander: Median 12m 18s für Codex und 12m 34s für Claude.
Ich nutze Abos, zahle also nicht pro Nutzung. Der Token-Verbrauch ist hier ein grober Näherungswert für Kosten, und eine kürzere CLAUDE.md bewegt diese Zahl ebenfalls.
Vom Score zur Evidenz
Der Score ist nur der Ausgangspunkt. Ich habe zuerst das Claude-Experiment geöffnet. Die Übersicht fasst die vier Aufgaben zusammen und zeigt mir auffällige Samples.
Die Übersicht des Claude-Experiments, mit auffälligen Samples je Aufgabe.
Eine Aufgabe, drei gerissene Kriterien
Ich habe mir Aufgabe 3 herausgegriffen, den ellarun-Architekturplan. In diesem Run hat Claude 18 von 21 Checks bestanden (plus 1 Overall Rating). Die drei roten Markierungen zeigen, wo der Plan zu kurz greift. Der Sprechblasen-Button öffnet Chat für das gesamte Experiment. Bevor ich der Antwort gefolgt bin, habe ich mir die Ratings angesehen, um genau zu wissen, was gerissen ist.
Das Sample zu Aufgabe 3, mit Chat für das gesamte Experiment geöffnet.
Die Begründungen zu den Ratings erklären die drei roten Markierungen. Claude hat die Entscheidung zur Credential-Zustellung komplett übersehen:
The proposal makes no committed recommendation about the mechanism by which secrets reach the sandboxed agent in the new design. The current argv/cmdline exposure is noted but not resolved.
Wer hat überbaut, und wo?
Die Kriterien standen vorher fest. Nach den Ergebnissen hatte ich eine neue Frage: Wo haben die Agenten das Problem unnötig aufgebläht? Ich habe sie einmal für Claude und einmal für Codex gestellt, mit Belegen aus Ratings und Trace, und die Antworten nebeneinandergelegt.
Beide haben es getan. Claude häufiger. Diese Lücke erklärt den größten Teil davon, warum Codex die Planungsaufgaben mit 119 zu 113 gewonnen hat.
Claudes schlimmster Ausreißer war Aufgabe 3, Epoche 1: Vorgeschlagen wurde, ein Python-CLI mit 16.676 Zeilen in Rust neu zu schreiben, ein neues hash-verkettetes Journalformat einzuführen und das gesamte Prozessmodell umzubauen.
Der Mechanismus war auf beiden Seiten derselbe: eine Endlosschleife aus iterativem adversarialem Self-Review ohne Abbruchkriterium. Jeder Durchgang förderte eine weitere “Lücke” zutage, die der Agent unbedingt schließen wollte.
Haben sie den Fix wirklich verifiziert?
Für die Debugging-Runs habe ich gefragt, welche Agenten den Fehler reproduziert haben, bevor sie Code änderten, und danach den geänderten Pfad end-to-end durchlaufen haben.
Verifikationsverhalten, aufgeteilt in gemockte Tests, Konfigurations-Proben, den echten Integrationspfad und den Nachweis, dass der ursprüngliche Fehler weg war.
In Aufgabe 2 war der eigentliche Bug eine geteilte Datenbankverbindung, die nie sauber gewischt wurde, bevor die nächste Anfrage sie sich lieh.
Codex hat dort nie hingesehen, und das Kriterium hat es in einer Zeile eingefangen:
The agent never mentioned pgbouncer, server_reset_query, or DISCARD ALL.
Dann der faule Teil. Codex hat nie geprüft, ob sein Fix funktioniert. Eine echte Datenbank lief direkt daneben, mitsamt allem, was nötig gewesen wäre, um den Bug auszulösen und sein Verschwinden zu belegen. Codex hat nichts davon benutzt. Es hat die Einstellungen angesehen, das als Beweis gewertet und weitergemacht.
Chat war gutgläubig
Als ich Chat danach gefragt habe, hat Chat den Agenten geglaubt und mir gesagt, eine Live-Prüfung sei nicht möglich gewesen. Das habe ich nicht geglaubt und nachgehakt. Beim zweiten Blick:
The key correction: verification was not ‘not possible’, it was not attempted. The agents had a live PgBouncer, a live Postgres, and pg_dump installed. They chose to verify only the configuration layer and treated that as sufficient.
Vorher: Chat hat die Behauptung der Agenten ungeprüft übernommen.
Nachher: Codex in Aufgabe 2 gegenübergestellt zu Codex in Aufgabe 4. Aufgabe 4 wurde end-to-end verifiziert. Aufgabe 2 nie.
Fazit
Ich bin mit einer klaren Vorhersage gestartet:
Claude für vage Planung. Codex für schwieriges, fokussiertes Debugging.
Das stimmt so nicht mehr.
Codex hat gut geplant. Beide sind beim fokussierten Debugging stärker geworden, Claude mit einem kleinen Vorsprung.
Was hat sich für mich geändert? Ich probiere Codex jetzt öfter für Planung. Das ist die eine Gewohnheit, die dieser Benchmark wirklich verschoben hat.
Mehr gelernt habe ich aus dem, wonach ich gar nicht gesucht habe:
- Endloses Self-Review bei der Planung ist keine Sorgfalt. Ohne Abbruchkriterium produziert es Scope und lenkt von den Entscheidungen ab, auf die es ankommt.
- Jetzt frage ich mich: Mache ich beim Self-Review meiner eigenen PRs dasselbe? Zeit für noch mehr Evaluation mit elluminate ;)
- Agenten werden faul, und sie erzählen Ihnen Dinge, die nicht stimmen. Das Werkzeug, mit dem Sie sie prüfen, übrigens auch: Chat hat mir dieselbe Ausrede zurückgespielt, bis ich nachgehakt habe. Geschlossen hat die Lücke kein klügeres Modell, sondern etwas menschliches Misstrauen und die Möglichkeit, direkt zurück in Umgebung und Trace zu gehen und selbst nachzusehen.
Probieren Sie es an Ihren eigenen Aufgaben aus
Der ganze Benchmark besteht aus vier Aufgaben, je drei Wiederholungen und einem Satz Kriterien, den ich an einem Nachmittag geschrieben habe. Das Interessante war nie die Rangliste, sondern nachzulesen, warum ein Run gescheitert ist. Wenn Sie das mit Ihren eigenen Coding-Agenten an Ihrer eigenen Codebase machen wollen, melden Sie sich.
Claude Code vs. Codex: häufige Fragen
Ist Codex beim Planen besser als Claude Code?
Bei meinen beiden Planungsaufgaben knapp ja. Codex hat 119 von 126 Kriterien bestanden, Claude Code 113. Der größte Teil der Lücke war der Scope: Claude hat das Problem öfter ausgeweitet, und im schlechtesten Run schlug er vor, ein Python-CLI mit 16.676 Zeilen in Rust neu zu schreiben.
Ist Claude Code beim Debugging besser als Codex?
Bei meinen beiden Debugging-Aufgaben ja: Claude Code hat 102 von 108 Kriterien bestanden, Codex 96. Am deutlichsten war ein wiederkehrender Produktions-Alert, verursacht durch eine geteilte Datenbankverbindung. Codex hat dort nie hingesehen und nie geprüft, ob sein Fix funktioniert, obwohl direkt daneben eine echte Datenbank lief.
Welcher Coding-Agent verbraucht weniger Tokens?
Codex, mit deutlichem Abstand. Er brauchte im Median 56 Agenten-Schritte gegenüber 114 bei Claude Code, und im Median rund 24k Output-Tokens gegenüber 125k. Die Laufzeit war fast identisch: 12m 18s gegenüber 12m 34s.
Welcher Coding-Agent ist insgesamt besser?
Über alle vier Aufgaben stand es exakt unentschieden, je 215 von 234 Bewertungen. Der Unterschied liegt im Aufgabentyp, nicht im Agenten: Codex hat die Planungsaufgaben gewonnen, Claude Code die Debugging-Aufgaben.
Welche Versionen von Claude Code und Codex wurden getestet?
Claude Code 2.1.220 mit Claude Opus 5 sowie Codex CLI 0.146.0 mit GPT-5.6-sol, beide auf High Reasoning. Die Runs liefen im August 2026.
