Pair Programming für Claude und Codex — ohne Copy-Paste

In den letzten Monaten sah mein Entwicklungsworkflow so aus: Claude Code und Codex liefen nebeneinander. Gleicher Prompt, gleiches Ziel, beide erkundeten die Codebase unabhängig voneinander. Wenn es ans Planen ging, entwarf Claude den Plan und ich kopierte ihn rüber zu Codex zum Review. Codex fand Dinge, die Claude übersehen hatte — Edge Cases, falsche Annahmen, übersehene Dateien. Die Ergebnisse trug ich zurück, ließ Claude überarbeiten, kopierte die Überarbeitung wieder zu Codex, iterierte, bis sich beide einig waren. Manchmal stagedte ich Änderungen aus der Vorrunde, damit Codex die Diffs besser sehen konnte. Dann schaute ich mir das Ergebnis selbst an.

Das hat richtig gut funktioniert. Die zwei Modelle finden unterschiedliche Dinge. Claude ist besser in Synthese und Kommunikation. Codex liest genauer — es verfolgt Code-Pfade, prüft Edge Cases, erklärt nicht zu früh „fertig”. Sie ermitteln unabhängig voneinander, und genau das macht die Ergebnisse besser.

Aber das Hin-und-Her-Kopieren war furchtbar.

Links gingen verloren, Formatierungen zerfielen, aber das war nicht das eigentliche Problem. Das eigentliche Problem war, dass jede Übergabe von mir abhing. Output kopieren, in die andere Session einfügen, warten, zurückkopieren, wieder einfügen. Meine Aufmerksamkeit steckte in dieser Schleife fest, obwohl sie woanders viel nützlicher gewesen wäre. Das war der echte Schmerzpunkt — ein Workflow, der ohne mich nicht weiterlief.

Ich wollte den Workflow selbst gar nicht ändern. Ich wollte nur aufhören, der menschliche Nachrichtenbus zu sein.

Der Harness-Artikel, der alles bestätigt hat

Dann bin ich auf Anthropics Harness design for long-running application development gestoßen, erwähnt in einem YouTube-Video. Ich hab den ganzen Artikel gelesen, und er hat zwei Dinge gleichzeitig bewirkt.

Erstens hat er bestätigt, was ich schon erlebt hatte: eine separate Session die Arbeit unabhängig prüfen zu lassen — ohne den Anchoring Bias, der entsteht, wenn man selbst gebaut hat — liefert bessere Ergebnisse. Genau das hatte ich mit Claude und Codex gesehen.

Zweitens hat er diese Erfahrung in ein klareres System überführt. Ich hatte mich hauptsächlich auf den „anderes Modell”-Aspekt konzentriert. Der Artikel machte den „unabhängiger Evaluator”-Teil viel expliziter. Sogar eine andere Claude-Session hilft, wenn sie unabhängig genug ist. Die Trennung an sich ist das Entscheidende.

Und ehrlich gesagt ergibt das ja auch Sinn: Wenn die ursprüngliche Session den Code für falsch gehalten hätte, hätte sie ihn nicht so geschrieben. Es ist derselbe Vorteil, den Pair Programming schon immer hatte — ein zweites Augenpaar fängt auf, was das Gehirn des Autors ausblendet. Da unterscheiden sich diese LLMs gar nicht so sehr von uns.

Diese Kombination — bestätigt durch Erfahrung, dann geschärft durch den Artikel — war der Moment, in dem es Klick gemacht hat. Das war nicht nur eine persönliche Eigenart in meiner Arbeitsweise. Es schien allgemein nützlich zu sein. Also hab ich den Workflow in ein richtiges Plugin verwandelt und es TandemKit genannt.

Das Koordinationsproblem, das wirklich gelöst werden musste

Mein erster Entwurf hatte vier Top-Level-Sessions: Planner, Generator und zwei Evaluators — einer Claude, einer Codex. Sie koordinierten sich über einfache Textdateien. Wenn eine Session fertig war, schrieb sie eine Sync-Datei, und die andere wartete im Hintergrund, bis sich diese Datei änderte. In Claude hat das einwandfrei funktioniert. Aber Codex wollte einfach nicht zuverlässig warten. Egal was ich versuchte — verschiedene File-Watching-Ansätze, verschiedene Signaling-Mechanismen — Codex hat entweder verpasst, dass es dran war, oder das Warten komplett übersprungen.

Ich war beim fünften oder sechsten Workaround dafür, als ich entdeckt habe, dass OpenAI gerade ein offizielles Codex-Plugin für Claude Code veröffentlicht hatte — codex-plugin-cc. Claude konnte Codex jetzt intern aufrufen, die Antwort sehen und dieselbe Codex-Session später fortsetzen. Genau das, was ich brauchte.

Das hat den Claude-Codex-Austausch aber nicht unsichtbar gemacht. Alles wird weiterhin in Markdown-Dateien unter TandemKit/ geschrieben, eine Datei pro Runde. Die komplette Mission-History bleibt auf der Festplatte — jede Recherche, jeder Convergence-Austausch, jedes Evaluationsergebnis.

Dieses Archiv ist auch nützlich. Wenn Wochen später etwas Merkwürdiges auftaucht, liefert die Git-History nicht nur eine Commit-Message — sie liefert die ganze Konversation hinter dem Commit, sodass man tatsächlich nachvollziehen kann, warum eine Entscheidung getroffen wurde. Es ist auch super, um den Workflow selbst zu verbessern: Alte Missions durchzulesen ist oft der schnellste Weg zu erkennen, dass eine Regel in AGENTS.md oder einen lokalen Skill gehört.

Was sich geändert hat, war die Infrastruktur. Statt ein fragiles viertes Terminal zu jonglieren, ruft TandemKit jetzt einen persistenten Codex-Subagent on demand über codex-plugin-cc auf und setzt ihn fort, wann immer es einen weiteren unabhängigen Durchlauf braucht.

Was eine Mission eigentlich ist

Ich nutze KI-Agenten jetzt seit fast einem Jahr täglich, und eine Mission ist die Arbeitsgröße, bei der ich immer wieder lande: groß genug, um von separater Planung, Generierung und Evaluation zu profitieren, aber klein genug, dass das Ganze innerhalb eines Satzes von Sessions noch implementiert und vollständig verifiziert werden kann.

Wenn die Arbeit kleiner ist — ein schneller Einzeiler-Fix, ein kleines Refactoring, ein simples Umbenennen — nutze ich einfach direkt Claude Code. TandemKits Multi-Session-Schleife verbraucht mehr Tokens und mehr Aufwand, als so eine Änderung verdient.

Wenn die Arbeit größer ist, teile ich sie vorher auf. Da kommt PlanKit ganz natürlich ins Spiel: Es führt Ideen durch Ideas → Roadmap → Features → Missions. Wenn etwas den Status „Mission” erreicht, ist es kein vager Feature-Topf mehr — es ist bereits in ein session-großes Arbeitsstück zugeschnitten.

Eine aktuelle Mission in der Praxis

Ich wollte App Store Connect Localization-Support zu TranslateKit hinzufügen, meinem KI-gestützten Tool für App-Lokalisierung. Die Idee war simpel: Statt App-Metadaten manuell in App Store Connect zu pflegen, könnten Entwickler Namen, Untertitel, Beschreibungen und Keywords für alle ihre Lokalisierungen direkt in TranslateKit bearbeiten — synchronisiert über Apples API.

Das war zu groß für eine Mission. Also hab ich es in zwei aufgeteilt: eine Mission für die App Store Connect API-Anbindung — JWT-Authentifizierung, Credential-Handling, Metadaten abrufen, Metadaten aktualisieren — und eine Mission für die UI-Änderungen, um das Ganze in der App sichtbar zu machen. Datenschicht zuerst, UX-Schicht danach.

Beim Planen haben Claude und Codex Edge Cases aufgedeckt, die ich nicht durchdacht hatte. Zum Beispiel: Was passiert, wenn der User eine neue Sprache hinzufügen will, aber es noch keine neue App Store Connect Version gibt? Bereits veröffentlichte Versionen lassen sich nicht bearbeiten, also muss das System entscheiden — Änderungen lokal cachen, den User auffordern zuerst eine Version zu erstellen, oder anbieten plattformübergreifend automatisch eine zu erstellen.

Und wenn TandemKit eine neue Version anlegt, welche Nummer soll sie bekommen? In die History schauen und raten? Den User bitten eine einzutippen? Gängige Nächste-Version-Optionen zur Auswahl anbieten? Das sind Produktentscheidungen, keine Implementierungsdetails, und die gehören in die Spec, bevor auch nur eine Zeile Code existiert.

Bei der Evaluation der API-Mission hat Claude das Feature zunächst als bestanden markiert, weil der Happy Path funktionierte und die Tests für existierende Versionen grün waren. Codex verfolgte den weniger offensichtlichen Branch und fand die eigentliche Lücke: Wenn keine editierbare App Store Connect Version existierte, erstellte der Code zwar den neuen Version-Record, versuchte aber nie den Localization-Write im selben Flow erneut. Der „neue Sprache”-Pfad sah also erfolgreich aus, tat aber im Stillen nichts, bis der User nochmal Sync auslöste — genau die Art von Code-Path-Bug, die ein zweites Modell findet.

Der Fix war klein: den Write nach der Version-Erstellung erneut versuchen, Tests für diesen Branch hinzufügen. Aber ohne den zweiten Durchlauf wäre er durchgerutscht.

Drei Sessions, autonome Schleife

DU  -- Planung
  |
  `--> [1] Planner Session
             Claude ---------> Codex (Hintergrund)
              |    <- Findings - |
              `---- konvergieren ┘
                         |
                      Spec.md  <-- du genehmigst, bevor es weitergeht

DU  -- beide Sessions starten, dann zurücklehnen
  |
  |--> [2] Generator Session
  |          implementiert gegen Spec.md
  |          committet bei Meilensteinen
  |
  `--> [3] Evaluator Session
             Claude ---------> Codex (Hintergrund)
              |    <- Findings - |
              `---- konvergieren ┘
                         |
                 FAIL -> Generator behebt -> Schleife
                 PASS -> Review Briefing -> du

Der Planner ist der einzige interaktive Schritt. Sobald du Spec.md freigibst, laufen Generator und Evaluator eigenständig, bis du entweder ein FAIL zum Fixen oder ein PASS mit Review Briefing bekommst.

Wie Claude und Codex sich tatsächlich einigen

Der naheliegende Ansatz wäre Scoring: Beide Modelle bewerten die Arbeit, man mittelt die Scores, bestanden ab einem bestimmten Schwellenwert. Aber Scores verstecken Fehler. Eine 8/10 kann bedeuten, dass zwei kritische Kriterien komplett durchgefallen sind und der Rest okay war.

Deshalb evaluiert TandemKit Kriterium für Kriterium. Jedes Finding bekommt zwei Dimensionen:

• Agreement Level: agreed, partially agreed oder disputed

• Severity Level: HIGH, MEDIUM oder LOW

Claude und Codex ermitteln unabhängig und schreiben ihre Findings in Dateien. Dann liest Claude, was Codex gefunden hat, erstellt eine zusammengeführte Evaluation — behält bei, wo es übereinstimmt, erklärt wo es anderer Meinung ist — und Codex reviewt diesen Merge. Bei jeder Uneinigkeit werden die tatsächlichen Quelldateien nochmal gelesen, statt aus dem Gedächtnis zu argumentieren.

Die Convergence-Regel ist simpel: Die Schleife läuft weiter, bis keine HIGH- oder MEDIUM-Findings mehr in den Buckets „partially agreed” oder „disputed” übrig sind. Wenn dieselbe Meinungsverschiedenheit drei Runden überlebt, hört TandemKit auf zu iterieren und präsentiert dir beide Positionen.

Normalerweise 2–4 Runden.

Warum nicht Agent Teams

Du fragst dich vielleicht: Hat Claude Code nicht Agent Teams für genau das? Doch, aber Agent Teams braucht API-Billing — nicht in Claude Max enthalten — und kann kein Codex einbinden.

Wenn Claude Max dich schon 100+ $/Monat kostet, sind 20 $/Monat für ChatGPT Plus ein vernünftiger Aufschlag — du bekommst ein unabhängiges zweites Modell, plus Bildgenerierung für UI-Mockups, Icons und andere Grafiken, die Claude nicht erzeugt.

Alles ist Plain Text

Jede Recherche, jeder Convergence-Austausch, jede Evaluationsrunde wird als lesbare Datei in deinem Projekt gespeichert:

TandemKit/001-ConnectAPIClient/
├── Spec.md
├── Planner-Discussion/
│   ├── Claude-01.md    ← Claudes Recherche
│   ├── Codex-01.md     ← Codex' unabhängige Findings
│   └── Claude-02.md    ← konvergierter Plan
├── Generator/
│   └── Round-01.md
└── Evaluator/
    ├── Round-01.md     ← FAIL: Version erstellt, Lokalisierungs-Write nicht wiederholt
    └── Round-02.md     ← PASS

Einfach die Dateien öffnen und du kannst die gesamte Argumentationskette nachvollziehen.

Erste Schritte

Die README auf GitHub beschreibt den kompletten Setup-Ablauf und zeigt, wie die Sessions einander übergeben. Wenn das nach dem Workflow klingt, den du bisher von Hand zusammengestückelt hast, ist das der richtige Startpunkt: