Claude plant, Codex programmiert: wie ich LLMs zum Programmieren nutze

Meine Projekte entstehen inzwischen mit zwei KI-Agenten in festen Rollen. Claude ist mein Ansprechpartner: Mit ihm kläre ich, was gebaut wird, er stellt Rückfragen und schreibt den Auftrag. Codex ist der Umsetzer und schreibt den Code.

Am Anfang steht eine kurze, aber möglichst umfassende Projektbeschreibung von mir. Claude schreibt daraus eine technische Spec und spiegelt mir dabei schon Fragen und Unklarheiten: was fehlt, was sich widerspricht, wo ich entscheiden muss. Erst wenn ich die Spec abgesegnet habe, legt Codex mit dem Programmieren los.

Danach ist wieder Claude dran. Er prüft, was Codex gebaut hat, und sammelt die offenen Fragen für mich. Ich beantworte sie gebündelt, probiere aus und gebe Feedback. So ist zum Beispiel das Taktikbrett aus „Hockey wie Schach“ entstanden.

Mehrere Claude-Konten nebeneinander

Ich arbeite mit mehreren Claude-Konten. Erreicht eines sein Nutzungslimit, läuft die Arbeit im nächsten weiter, und Projekte bleiben sauber getrennt.

In Claude Code geht das mit einer Umgebungsvariable: CLAUDE_CONFIG_DIR zeigt pro Konto auf ein eigenes Verzeichnis, mit eigener Anmeldung, eigenen Einstellungen und eigenem Verlauf (Anleitung). Dazu ein Alias pro Konto:

alias claude1='CLAUDE_CONFIG_DIR=~/.claude claude'
alias claude2='CLAUDE_CONFIG_DIR=~/.claude-konto2 claude'

Einmal claude2 auth login, danach laufen beide Konten gleichzeitig in zwei Terminals, ohne Ab- und Anmelden. Jedes Verzeichnis ist aber eine frische Umgebung: Skills, MCP-Server, Hooks und Memory richtet man pro Konto ein oder teilt sie per Symlink (Beispiel).

Eine AGENTS.md für beide

Die Spielregeln stehen in einer AGENTS.md im Repository. Codex liest sie zu Beginn jeder Sitzung (Doku). Claude Code sucht CLAUDE.md, also zeigt ein Symlink auf dieselbe Datei: ln -s AGENTS.md CLAUDE.md. So gelten für beide Agenten dieselben Regeln.

Im Kern steht darin, wer was tut und wie mit Unklarheiten umzugehen ist:

# AGENTS.md

## Rollen
- Claude ist Ansprechpartner: macht aus meiner Projektbeschreibung eine technische
  Spec in docs/spec.md und legt mir Fragen und Unklarheiten vor.
- Codex startet erst, wenn ich die Spec freigegeben habe.
- Codex setzt um: programmiert den Auftrag mit Tests, in kleinen Schritten.
- Claude prüft danach Code und Tests gegen den Auftrag und sammelt offene Fragen.

## Unklarheiten
- Nicht anhalten. Triff eine plausible Annahme, programmiere damit weiter und
  schreib die Annahme in docs/fragen.md.
- Fragen gesammelt am Ende eines Schritts stellen, nicht einzeln zwischendurch.
- Nur anhalten, wenn etwas nicht rückgängig zu machen ist: Daten löschen,
  veröffentlichen, Geld ausgeben.

## Festhalten
- Entscheidungen gehören in docs/spec.md, nicht nur in den Chat.

Der Ablauf: planen, bauen, prüfen, fragen

Ablauf: vier Stationen, ein Kreis.

Der Kreis läuft, bis es passt. Jede Entscheidung landet dabei in der Spec, nicht nur im Chat.

Erst bauen, dann fragen

Die wichtigste Regel: Der Agent programmiert mit Best Guesses los und lässt sich nicht von Kleinigkeiten aufhalten. Eine Rückfrage wartet, bis ich Zeit habe. Eine falsche Annahme ist im Review oft in einer Minute korrigiert.

Deshalb landet jede Annahme in einer Liste, und Claude legt sie mir gesammelt vor. Ich entscheide in einem Durchgang statt zehnmal zwischendurch. Was richtig geraten war, nicke ich ab, der Rest wird ein kleiner Fix.

Drei Rechner, drei Aufgaben

Die Agenten laufen auf drei Rechnern, jeder mit eigener Aufgabe.

Rechner	Aufgabe	Was dort läuft
Mac mini (M4 Pro)	Arbeitsplatz & CI	Claude Code, Codex, CI-Server
Tower	hier wird programmiert	über Tailscale kann ich mir die ersten Versionen anschauen
Server	Entwicklungsserver	hier laufen alle Projekte, quasi meine eigene eigava.de-Umgebung

Die Idee ist, dass ich mithilfe von Tailscale von überall auf den Tower zugreifen kann und dort in den Ordnern der ganze Code läuft. Ich kann entweder am Mac mini eine Claude-Instanz starten und ihm sagen: Mach das in dem Repo auf dem Tower, dann kümmert er sich darum. Oder ich gehe direkt auf den Tower. Wenn Codex am Tower fertig programmiert hat, kann ich mir das Ergebnis anschauen und Feedback geben. Wenn das alles passt, kommt es auf den Server. Dort laufen dann die meisten Live-Anwendungen, wenn sie nicht bei Cloudflare Pages gehostet werden.

Ausblick: mehrere Varianten statt einer

Das Ziel ist der nächste Schritt dieser Regel. Wenn Inferenz günstig genug ist, baut der Agent bei einer offenen Frage nicht eine Variante, sondern mehrere, und ich wähle aus.

Technisch geht das schon heute: Jede Variante entsteht in einem eigenen Git-Worktree, also einem eigenen Arbeitsordner desselben Repositorys. Was fehlt, ist der Preis. Drei Varianten kosten dreimal so viel Rechenzeit.