Claude Code oder Codex – was denn nun? Die realistische Antwort: beide, ohne Unfall

„Und welches soll ich jetzt nehmen?“

Claude Code und OpenAIs Codex. Gerade wer beide angefasst hat, hängt bei dieser Frage fest. Auch ich dachte zuerst „Ich muss mich für eins entscheiden“.

Aber nach einem halben Jahr Nutzung war die Antwort ernüchternd schlicht. Nicht entweder-oder. Beide. Aber teile auf, wem du welche Arbeit gibst. Das ist alles.

Die Frage ist nicht „wer ist klüger“. Genauso wenig, wie man Messer und Schere vergleicht, wer von beiden der Größere ist. Gemüse: Messer. Papier: Schere. Werkzeuge haben eine Form, in der sie stark sind, und vergreifst du dich, schneidest du dir in den Finger. Heute geht es darum, „wem du welche Arbeit gibst“ – und um die Aufstellung, bei der man beide gleichzeitig laufen lassen kann, ohne dass es kracht.

Ich hetze nicht. Ich ziehe auch kein Fazit wie „der eine ist besser“. Ich reihe ehrlich die Minen auf, in die ich beim Betrieb dieser Seite tatsächlich getreten bin.

Erst mal: der Charakterunterschied der beiden

Den Vergleich der Klugheit lasse ich weg, ich rede über den Charakter.

Claude Code ist der Kumpel, der dein unordentliches Zimmer neben dir mit aufräumt. Es öffnet dein Repository, liest die Regeln, die du in CLAUDE.md geschrieben hast, und repariert im Dialog, indem es den Kontext verknüpft: „Wenn wir das hier anfassen, dann gleich auch das.“ Es nimmt die Umstände des bestehenden Codes gut auf. Deshalb ist es stark beim Refactoring bestehender Projekte und bei feinen Anpassungen lokal.

Codex ist eher der Auftragnehmer im Nebenraum, der die ihm übergebene Arbeit allein vorantreibt. Eine Aufgabe einfach rüberreichen und auf der Cloud-Seite laufen lassen, einen Pull Request werfen und in den Review geben – dieser Delegierstil passt gut. Auch OpenAI beschreibt Codex als Kumpel, dem man Code-Arbeit überlassen kann (OpenAI: Introducing Codex). Loslassen und übergeben, das kann es gut.

Grob gesagt: Claude Code „neben dir gemeinsam“, Codex „abgeben und warten“. Merkst du dir diesen Temperaturunterschied, geht dir die Aufgabenteilung mühelos ein.

Allerdings: Die hier genannten Modellnamen, Preise und die Grenze dessen, was geht, ändern sich ziemlich schnell. Beide aktualisieren rasch. Deshalb prüfe die endgültigen Stärken, Schwächen und Preise unbedingt offiziell auf dem neuesten Stand (OpenAIs Dokumentation und Claude Codes Dokumentation). Sieh diesen Artikel als „Landkarte der Denkweise“.

Welche Arbeit gibst du wem?

Mit der Landkarte allein ist es unhandlich, also lege ich meine tatsächliche Verteilung hin. Nur mein Gefühl im Moment, nicht die absolute Wahrheit.

Was du willst	Hauptzuständiger	Warum
Verzwicktes Refactoring im bestehenden Repository	Claude Code	Liest den Kontext drumherum und vermeidet Kollateralunfälle
Lokal im Dialog entwerfen und anpassen	Claude Code	Das Hin und Her von „Doch lieber so“ geht schnell
Klar abgrenzbare, eigenständige Aufgabe delegieren	Codex	Hinwerfen und zur nächsten Arbeit wechseln
Einen PR erstellen und in den Review geben	Codex	Fügt sich in den Fluss aus Delegieren und Review
Projektspezifische Regeln einhalten	Claude Code	Liest CLAUDE.md und setzt es um
Mehrere Aufgaben parallel drehen	Beide	Einem Dialog, dem anderen Delegieren, kein Stau

Der Punkt ist die letzte Zeile. Kein Entweder-oder, sondern Rollenteilung. Ich bin bei einem Zweihänder gelandet: Mit Claude Code feile ich vor dem Bildschirm am Entwurf, und den abtrennbaren Kleinkram werfe ich Codex zu, damit der ihn im Nebenraum vorantreibt.

Und jetzt der Kern. Egal welches du nimmst, die Denkweise der Sicherung ist dieselbe. Statt die klügere KI zu wählen, baut man zuerst die Aufstellung, bei der man sich beim Hinfallen nicht verletzt. Das nenne ich Harness – das Gerüst und Sicherungsseil der KI. Wer es vom Konzept her verstehen will, schaut in den vollständigen Leitfaden zu Harness Engineering.

Das Gerüst lässt sich gut in vier Schichten denken. Nicht schwierig.

deine Anfrage
  ↓
KI (Claude Code / Codex)
  ↓
[1] Rechte-Schicht    Was darf sie tun, was wird gestoppt
[2] Ablauf-Schicht    In welcher Reihenfolge
[3] Prüf-Schicht      Womit bestätigt man danach das "OK"
[4] Recovery-Schicht  Wie kommt man bei einem Fehler zurück
  ↓
Dateien / Shell / externe Dienste / Deployment

Fehlen diese vier, fällt man – ob mit Claude Code oder Codex – ungefähr an derselben Stelle hin.

In diesen Situationen zahlt sich die Kombination aus (drei)

1. Entwerfen mit Claude Code, Massenarbeit mit Codex

Arbeit, die ein „Hin und Her“ braucht – etwa das Datenmodell für ein neues Feature –, feile ich mit Claude Code vor dem Bildschirm aus. Die simple Arbeit danach, „noch acht Dateien derselben Form“, trenne ich ab und werfe sie Codex zu. Die Zeit, in der man den Kopf braucht, und die Zeit, in der man nur wartet, trennen sich sauber.

2. Das Hauptwerk mit Claude Code, der Review mit Codex

Manchmal willst du den mit Claude Code geschriebenen Code von einem anderen Auge geprüft haben, oder? Dann lasse ich Codex den PR-Review drehen. Schreibt und reviewt dieselbe KI, verschiebt sich der Blickwinkel kaum; so kommen mehr Anmerkungen. Als „erstes Sieb“ vor dem menschlichen Review gar nicht schlecht.

3. Gefährliche Operationen drückt am Ende immer der Mensch – egal welches

Das ist das Wichtigste. Deployment, Produktions-DB aktualisieren, Mail senden, git push, npm publish. Nur diese „irreversiblen Operationen“ legst du so an, dass am Ende ein Mensch den Knopf drückt – ob mit Claude Code oder Codex. Erzeugen und Entwürfe dürfen automatisch laufen. Aber Operationen, die nach draußen fliegen, stoppst du. Erzwingst du das gerüstseitig, kracht es nachts nicht.

Die Grenzziehung der Rechte hältst du am besten in einer Datei, dann musst du nicht grübeln. Bei Claude Code schreibst du sie in .claude/settings.json.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(node scripts/content-trend-report.mjs *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Der Trick: Schreib das Verbot nicht nach „klingt irgendwie gefährlich“. rm -rf, git reset --hard, das Lesen von .env, die Deployment-Befehle für die Produktion. Schreib sie mit konkretem Befehlsnamen. Wie man das genauer aufbaut, ist in Claude Code settings der Einstieg. Die Praxis von Approval und Sandbox habe ich im Leitfaden zu Approval und Sandbox zusammengefasst.

Auf der Codex-Seite gibt es denselben Gedanken. Mit Sandbox (abgeschotteter Arbeitsplatz) und Approval (Freigabe) trennst du „bis hierhin allein, ab hier den Menschen fragen“. Die Namen der Einstellungen unterscheiden sich, aber was man will, ist dasselbe. Hast du die Denkweise des Harness einmal verinnerlicht, lässt sie sich anwenden, auch wenn das Werkzeug wechselt.

Drei Fehler, die ich selbst gebaut habe

Ehrlich gesagt: Die Kombination krachte anfangs ziemlich oft.

Der erste. Ich gab beiden dieselbe Arbeit, und es wurde ein Umschreib-Wettkampf. Eine Datei, die ich gerade mit Claude Code reparierte, warf ich auch Codex mit „Repariere das hier“ zu. Natürlich überschrieb die eine Änderung die andere, und ich wusste nicht mehr, was richtig war. Heute teile ich den Anfass-Bereich auf: „Diese Datei ist gerade auf der Claude-Code-Seite.“ Nicht zwei am selben Schneidebrett gleichzeitig. Selbstverständlich, eigentlich.

Der zweite. Die Aufgabe an Codex war zu vage. Wirfst du eine kontextabhängige Bitte wie „Repariere das mal schön“ an die Delegier-Seite, kommt nichts Gescheites heraus. Delegieren ist Auftragsarbeit, also lautet die eiserne Regel: erst in eine eigenständig abschließbare Form zerteilen, dann übergeben. Umgekehrt: Arbeit, die Kontext braucht, treibst du nicht mit Gewalt im Delegieren voran, sondern im Dialog mit Claude Code. Die Form der Bitte bestimmt die Wahl des Werkzeugs.

Der dritte. Ich drehte es mit „prüf ich später selbst“ – und an einem vollen Tag brach es zusammen. Eine veröffentlichte URL blieb 404, ein Werbetag blieb verschwunden, und ich merkte es nicht, während es weiterlief. Die Sichtkontrolle lässt man, wenn man im Stress ist, garantiert ausfallen. Also lasse ich, was maschinell prüfbar ist, von der Maschine machen. Ob eine veröffentlichte Seite lebt, klopfe ich seither mit so einem kleinen Skript ab.

// scripts/verify-published-page.mjs
const url = process.argv[2];

if (!url) {
  throw new Error("Nutzung: node scripts/verify-published-page.mjs <url>");
}

const response = await fetch(url, { redirect: "follow" });
if (!response.ok) {
  throw new Error(`Seite lieferte ${response.status}: ${url}`);
}

const html = await response.text();
const checks = [
  ["title", /<title>.+<\/title>/i],
  ["description", /<meta name="description"/i],
  ["main content", /<article|data-pagefind-body|blog-post/i],
];

for (const [name, pattern] of checks) {
  if (!pattern.test(html)) {
    throw new Error(`${name} fehlt auf ${url}`);
  }
}

console.log(`OK: ${url}`);

Keine perfekte Prüfung. Aber den blöden Unfall der Sorte „gemeint, es sei veröffentlicht, war aber 404“ oder „ein wichtiger Tag war weg“ stoppt sie. Die KI neigt dazu, nur die letzte Zeile des Fehlerlogs zu lesen und am falschen Ende zu reparieren. Deshalb wirkt es, vorher im Code festzulegen, was als OK gilt.

Wenn du anfangen willst, dann hier

Bau nicht gleich den voll automatisierten Zweihänder. Es gibt eine Reihenfolge.

Zuerst: Teil die heutige Arbeit einmal in eine „Kopf-braucht“-Seite und eine „kann-warten“-Seite. Den Teil, der Urteil braucht, im Dialog mit Claude Code. Die abgetrennte simple Arbeit delegierst du an Codex. Allein das verändert die gefühlte Geschwindigkeit.

Als Nächstes kipp alle gefährlichen Operationen auf „den Menschen fragen (ask)“. Deployment, Push, Senden, Produktions-DB warten anfangs kommentarlos auf Freigabe. Nur was sich als sicher erwiesen hat, stufst du später auf automatisch hoch. Erweitern kann man später. Anfangs eng.

Und halt dir eine Vorlage für die direkt übergebbare Bitte bereit, dann eierst du nicht jedes Mal. Hier meine Vorlage fürs Delegieren an Codex. Kopieren und die Lücken füllen.

# Aufgabe (in einer eigenständig abschließbaren Einheit)
<z. B.: Unit-Tests zu den Datumsformat-Funktionen unter src/utils/ hinzufügen>

# Erlaubter Bereich
- anfassen: <z. B.: nur src/utils/date.ts und tests/date.test.ts>
- nicht anfassen: <z. B.: alle anderen Dateien. Konfigurationsdateien und .env nicht lesen>

# Abschlussbedingung (das gilt als OK)
- npm run test läuft komplett durch
- die Signatur bestehender Funktionen nicht ändern
- außer neuen Dateien das Diff minimal halten

# Verboten
- kein git push (nur PR/Diff vorlegen)
- keine Abhängigkeiten eigenmächtig hinzufügen
- keinerlei Operationen für Produktion, Deployment oder Senden

Der Clou ist, „nicht anfassen“ und „Verboten“ schriftlich festzuhalten. Die delegierte KI fasst aus Eifer manchmal auch unnötige Stellen an, also zäunst du von Anfang an ein. Das ist auch eine Maßnahme gegen den Unfall, dass die Anweisung in einem externen Dokument als Arbeitsbefehl missverstanden wird (Prompt Injection). Wie man solche gefährlichen Bitten vermeidet, habe ich ausführlich in Praxischeck gegen gefährliche Prompts aufgeschrieben.

Was beim Ausprobieren herauskam

Mein Fazit nach einem halben Jahr Kombination beim Betrieb dieser Seite.

Am meisten gewirkt hat – überraschenderweise – nicht das „Verbot“, sondern die „Grenze, die man auf ask lässt“. Artikelentwürfe, Übersetzung, Vorschläge fürs Refactoring lassen sich mit Claude Code wie mit Codex automatisieren, ohne dass leicht etwas schiefgeht. Aber nur bei Deployment, git push, Mailversand und dem Aktualisieren der Produktions-URL lässt man die menschliche Bestätigung. Allein das eisern zu verteidigen, ließ die Schreckmomente schlagartig seltener werden.

Umgekehrt ein klarer Fehlschlag: die Methode, alle Schritte in einen langen Prompt zu stopfen. Aus Gier, alles in einem Rutsch machen zu lassen, wurde die Sitzung schwer und blieb unterwegs leicht stehen. Lieber kurze Anweisungen, und die Ausführungsregeln verlagerst du auf die Gerüstseite (settings oder Freigabelinie). Das ist überwältigend reproduzierbarer.

Und das Gefühl zur Aufgabenteilung. Dass ich „mich für eins entscheiden“ losgelassen habe, hat am meisten gebracht. So wie man Messer und Schere zugleich in der Hand hat, bewege ich mit Claude Code das „neben mir“ und mit Codex das „im Nebenraum“ gleichzeitig. Das Gefühl, dass mit nur einem Hirn die Arbeit doppelt vorangeht, lässt einen nicht mehr los, wenn man es einmal gekostet hat. Aber, noch mal: Stärken, Preise und Modelle beider aktualisieren schnell, prüf also offiziell den neuesten Stand, bevor du ernsthaft investierst.

Fazit

Meine Antwort auf „Claude Code oder Codex?“ lautet: „Beide. Aber teile auf, welche Arbeit du gibst und welche Operation du stoppst.“

• Neben dir gemeinsam reparieren: Claude Code; abgeben und warten: Codex
• Arbeit, die Kontext braucht: Dialog; abtrennbare Arbeit: Delegieren
• Egal welches du nimmst, die Denkweise der Sicherungen (Rechte, Ablauf, Prüfung, Recovery) ist dieselbe
• Gefährliche Operationen (Deployment, Senden, Produktions-DB) drückt am Ende der Mensch

Verwandle die Zeit, in der du über die Werkzeugwahl grübelst, in die Zeit, ein Gerüst zu bauen. Die Qualität der Arbeit entscheidet sich nicht daran, welche KI klüger ist, sondern an der Aufstellung drumherum.

Willst du Rechtevergabe, CI und Team-Regeln gemeinsam aufsetzen, habe ich sofort nutzbare Vorlagen in der Materialübersicht gesammelt. Wer auf das eigene Repository zugeschnittene Begleitung möchte, meldet sich über Schulung und Beratung.