Ich verwende Codex oder Claude Code nicht mehr direkt.
Ich nutze OpenClaw als meine Orchestrierungsschicht. Meine Orchestratorin Zoe startet die Agents, schreibt ihre Prompts, wählt das passende Modell für jede Aufgabe, überwacht den Fortschritt und pingt mich auf Telegram, wenn PRs bereit zum Mergen sind.
Belege aus den letzten 4 Wochen:
- 94 Commits an einem Tag. Mein produktivster Tag – ich hatte 3 Kundentermine und habe meinen Editor kein einziges Mal geöffnet. Der Durchschnitt liegt bei etwa 50 Commits pro Tag.
- 7 PRs in 30 Minuten. Von der Idee bis zur Produktion geht es rasend schnell, weil das Coden und die Validierungen größtenteils automatisiert sind.
- Commits → MRR: Ich nutze das für eine echte B2B-SaaS, die ich gerade entwickle – kombiniert mit Founder-led Sales, um die meisten Feature-Anfragen noch am selben Tag auszuliefern. Geschwindigkeit verwandelt Leads in zahlende Kunden.
Mein Git-Verlauf sieht aus, als hätte ich gerade ein Entwicklerteam eingestellt. In Wirklichkeit bin nur ich, der vom direkten Umgang mit Claude Code zum Managen eines OpenClaw-Agents übergegangen ist, der eine ganze Flotte anderer Claude Code- und Codex-Agents steuert.
Erfolgsquote: Das System erledigt fast alle kleinen bis mittleren Aufgaben beim ersten Versuch, ohne dass ich eingreifen muss.
Kosten: ~100 $/Monat für Claude und 90 $/Monat für Codex, aber man kann mit 20 $ einsteigen.
Hier ist, warum das besser funktioniert als die direkte Nutzung von Codex oder Claude Code:
>Codex und Claude Code haben sehr wenig Kontext über dein Unternehmen.
Sie sehen Code. Sie sehen nicht das Gesamtbild deines Geschäfts.
OpenClaw ändert das. Es fungiert als Orchestrierungsschicht zwischen dir und allen Agents – es hält meinen gesamten Geschäftskontext (Kundendaten, Besprechungsnotizen, frühere Entscheidungen, was funktioniert hat, was nicht) in meinem Obsidian-Vault und übersetzt historischen Kontext in präzise Prompts für jeden Coding-Agent. Die Agents bleiben auf den Code fokussiert. Der Orchestrator bleibt auf der hohen strategischen Ebene.
So funktioniert das System auf hoher Ebene:
Letzte Woche hat Stripe über ihr Hintergrund-Agent-System namens „Minions" geschrieben – parallele Coding-Agents, die von einer zentralen Orchestrierungsschicht unterstützt werden. Ich habe aus Versehen dasselbe gebaut, aber es läuft lokal auf meinem Mac Mini.
Bevor ich dir erkläre, wie du das einrichtest, solltest du wissen, WARUM du einen Agent-Orchestrator brauchst.
Warum eine einzelne KI nicht beides kann
Kontextfenster sind ein Nullsummenspiel. Du musst entscheiden, was hineinkommt.
Fülle sie mit Code → kein Platz für Geschäftskontext. Fülle sie mit Kundengeschichte → kein Platz für die Codebasis. Deshalb funktioniert das zweistufige System: Jede KI bekommt genau das, was sie braucht.
OpenClaw und Codex haben drastisch unterschiedlichen Kontext:
Spezialisierung durch Kontext, nicht durch verschiedene Modelle.
Der vollständige 8-Schritte-Workflow
Lass mich ein echtes Beispiel aus der letzten Woche durchgehen.
Schritt 1: Kundenanfrage → Scoping mit Zoe
Ich hatte ein Gespräch mit einem Agenturkunden. Sie wollten Konfigurationen, die sie bereits im Team eingerichtet hatten, wiederverwenden können.
Nach dem Gespräch habe ich die Anfrage mit Zoe besprochen. Da alle meine Besprechungsnotizen automatisch mit meinem Obsidian-Vault synchronisiert werden, war auf meiner Seite keine Erklärung nötig. Wir haben das Feature gemeinsam abgesteckt – und landeten bei einem Vorlagensystem, mit dem sie ihre bestehenden Konfigurationen speichern und bearbeiten können.
Dann macht Zoe drei Dinge:
- Lädt Guthaben auf, um den Kunden sofort zu entblocken – sie hat Admin-API-Zugriff
- Zieht die Kundenkonfiguration aus der Produktionsdatenbank – sie hat schreibgeschützten Prod-DB-Zugriff (den werden meine Codex-Agents nie haben), um ihr bestehendes Setup abzurufen, das dann in den Prompt aufgenommen wird
- Startet einen Codex-Agenten – mit einem detaillierten Prompt, der den gesamten Kontext enthält
Schritt 2: Agent starten
Jeder Agent bekommt seinen eigenen Worktree (isolierten Branch) und eine eigene tmux-Sitzung:
1# Create worktree + spawn agent2git worktree add ../feat-custom-templates -b feat/custom-templates origin/main3cd ../feat-custom-templates && pnpm install45tmux new-session -d -s "codex-templates" \6 -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \7 "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"
Der Agent läuft in einer tmux-Sitzung mit vollständigem Terminal-Logging per Skript.
So starten wir Agents:
1# Codex2codex --model gpt-5.3-codex \3 -c "model_reasoning_effort=high" \4 --dangerously-bypass-approvals-and-sandbox \5 "Your prompt here"67# Claude Code8claude --model claude-opus-4.5 \9 --dangerously-skip-permissions \10 -p "Your prompt here"
Früher habe ich codex exec oder claude -p verwendet, aber neulich bin ich auf tmux umgestiegen:
tmux ist weitaus besser, weil die Umleitung während der Aufgabe mächtig ist. Agent geht in die falsche Richtung? Töte ihn nicht:
1# Wrong approach:2tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter34# Needs more context:5tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter
Die Aufgabe wird in .clawdbot/active-tasks.json nachverfolgt:
1{2 "id": "feat-custom-templates",3 "tmuxSession": "codex-templates",4 "agent": "codex",5 "description": "Custom email templates for agency customer",6 "repo": "medialyst",7 "worktree": "feat-custom-templates",8 "branch": "feat/custom-templates",9 "startedAt": 1740268800000,10 "status": "running",11 "notifyOnComplete": true12}
Wenn abgeschlossen, wird es mit PR-Nummer und Checks aktualisiert. (Mehr dazu in Schritt 5)
1{2 "status": "done",3 "pr": 341,4 "completedAt": 1740275400000,5 "checks": {6 "prCreated": true,7 "ciPassed": true,8 "claudeReviewPassed": true,9 "geminiReviewPassed": true10 },11 "note": "All checks passed. Ready to merge."12}
Schritt 3: Überwachung in einer Schleife
Ein Cron-Job läuft alle 10 Minuten, um alle Agents zu beaufsichtigen. Das fungiert im Wesentlichen als verbesserter Ralph Loop, mehr dazu später.
Aber er fragt die Agents nicht direkt ab – das wäre teuer. Stattdessen führt er ein Skript aus, das das JSON-Register liest und prüft:
1.clawdbot/check-agents.sh
Das Skript ist zu 100 % deterministisch und extrem token-effizient:
- Prüft, ob tmux-Sitzungen noch leben
- Prüft auf offene PRs in verfolgten Branches
- Prüft CI-Status via gh cli
- Startet fehlgeschlagene Agents automatisch neu (max. 3 Versuche), wenn CI fehlschlägt oder kritisches Review-Feedback vorliegt
- Alarmiert nur, wenn etwas menschliche Aufmerksamkeit braucht
Ich starre nicht auf Terminals. Das System sagt mir, wann ich hinschauen soll.
Schritt 4: Agent erstellt PR
Der Agent committed, pusht und öffnet einen PR mittels \gh pr create --fill\. An diesem Punkt werde ich NICHT benachrichtigt – ein PR allein ist noch nicht fertig.
Definition von „fertig" (sehr wichtig, dass dein Agent das weiß):
- PR erstellt
- Branch mit Main synchronisiert (keine Merge-Konflikte)
- CI erfolgreich (Lint, Types, Unit-Tests, E2E)
- Codex-Review bestanden
- Claude Code-Review bestanden
- Gemini-Review bestanden
- Screenshots enthalten (bei UI-Änderungen)
Schritt 5: Automatisierte Code-Review
Jeder PR wird von drei KI-Modellen reviewed. Sie entdecken unterschiedliche Dinge:
- Codex Reviewer – Herausragend bei Randfällen. Macht das gründlichste Review. Findet Logikfehler, fehlende Fehlerbehandlung, Race Conditions. Die Falsch-Positiv-Rate ist sehr niedrig.
- Gemini Code Assist Reviewer – Kostenlos und unglaublich nützlich. Findet Sicherheitsprobleme, Skalierbarkeitsprobleme, die andere Agents übersehen. Und schlägt spezifische Korrekturen vor. Absolut sinnvoll zu installieren.
- Claude Code Reviewer – Meistens nutzlos – tendiert zu übermäßiger Vorsicht. Viele „Erwägen Sie, hinzuzufügen…"-Vorschläge, die meist Overengineering sind. Ich überspringe alles, außer es ist als kritisch markiert. Es findet selten eigenständig kritische Probleme, validiert aber, was die anderen Reviewer melden.
Alle drei posten Kommentare direkt auf dem PR.
Schritt 6: Automatisierte Tests
Unsere CI-Pipeline führt eine Menge automatisierter Tests aus:
- Lint- und TypeScript-Checks
- Unit-Tests
- E2E-Tests
- Playwright-Tests gegen eine Preview-Umgebung (identisch mit Produktion)
Letzte Woche habe ich eine neue Regel hinzugefügt: Wenn der PR UI ändert, muss ein Screenshot in der PR-Beschreibung enthalten sein. Sonst schlägt CI fehl. Das verkürzt die Review-Zeit drastisch – ich kann auf einen Blick sehen, was sich geändert hat, ohne durch die Vorschau klicken zu müssen.
Schritt 7: Menschliches Review
Jetzt bekomme ich die Telegram-Benachrichtigung: „PR #341 bereit zum Review."
Zu diesem Zeitpunkt:
- CI bestanden
- Drei KI-Reviewer haben den Code genehmigt
- Screenshots zeigen die UI-Änderungen
- Alle Randfälle sind in Review-Kommentaren dokumentiert
Mein Review dauert 5-10 Minuten. Viele PRs merge ich, ohne den Code zu lesen – der Screenshot zeigt mir alles, was ich brauche.
Schritt 8: Merge
PR wird gemerged. Ein täglicher Cron-Job räumt verwaiste Worktrees und das Task-Register-JSON auf.
Der Ralph Loop V2
Das ist im Wesentlichen der Ralph Loop, aber besser.
Der Ralph Loop zieht Kontext aus dem Gedächtnis, generiert Ausgabe, bewertet Ergebnisse, speichert Erkenntnisse. Aber die meisten Implementierungen führen jedes Mal denselben Prompt aus. Die destillierten Erkenntnisse verbessern zukünftige Abrufe, aber der Prompt selbst bleibt statisch.
Unser System ist anders. Wenn ein Agent scheitert, startet Zoe ihn nicht einfach mit demselben Prompt neu. Sie betrachtet den Fehler mit vollem Geschäftskontext und findet heraus, wie sie ihn entblocken kann:
- Agent hatte Kontextfenster voll? „Konzentriere dich nur auf diese drei Dateien."
- Agent ist in die falsche Richtung gelaufen? „Stopp. Der Kunde wollte X, nicht Y. Hier ist, was er im Meeting gesagt hat."
- Agent braucht Klarstellung? „Hier ist die E-Mail des Kunden und was sein Unternehmen macht."
Zoe beaufsichtigt Agents bis zur Fertigstellung. Sie hat Kontext, den die Agents nicht haben – Kundengeschichte, Besprechungsnotizen, was wir schon versucht haben, warum es fehlgeschlagen ist. Sie nutzt diesen Kontext, um bei jedem erneuten Versuch bessere Prompts zu schreiben.
Aber sie wartet auch nicht darauf, dass ich Aufgaben zuweise. Sie findet proaktiv Arbeit:
- Morgens: Scannt Sentry → findet 4 neue Fehler → startet 4 Agents zur Untersuchung und Behebung
- Nach Meetings: Scannt Besprechungsnotizen → markiert 3 Feature-Anfragen, die Kunden erwähnt haben → startet 3 Codex-Agents
- Abends: Scannt Git-Log → startet Claude Code zum Aktualisieren von Changelog und Kundendokumentation
Ich mache nach einem Kundentermin einen Spaziergang. Komme zurück zu Telegram: „7 PRs bereit zum Review. 3 Features, 4 Bugfixes."
Wenn Agents erfolgreich sind, wird das Muster protokolliert. „Diese Prompt-Struktur funktioniert für Abrechnungsfeatures." „Codex braucht die Typdefinitionen von Anfang an." „Immer die Testdateipfade angeben."
Die Belohnungssignale sind: CI bestanden, alle drei Code-Reviews bestanden, menschlicher Merge. Jeder Fehlschlag löst die Schleife aus. Mit der Zeit schreibt Zoe bessere Prompts, weil sie sich erinnert, was ausgeliefert wurde.
Den richtigen Agent auswählen
Nicht alle Coding-Agents sind gleich. Kurzübersicht:
Codex ist mein Arbeitstier. Backend-Logik, komplexe Bugs, Multi-File-Refaktorisierungen, alles, was Reasoning über die Codebasis hinweg erfordert. Es ist langsamer, aber gründlich. Ich verwende es für 90 % der Aufgaben.
Claude Code ist schneller und besser bei Frontend-Arbeit. Es hat auch weniger Berechtigungsprobleme, daher ist es großartig für Git-Operationen. (Früher habe ich es mehr für den täglichen Betrieb genutzt, aber Codex 5.3 ist jetzt einfach besser und schneller.)
Gemini hat eine andere Superkraft – Gespür für Design. Für schöne UIs lasse ich Gemini zuerst eine HTML/CSS-Spezifikation erstellen und reiche diese dann an Claude Code weiter, um sie in unserem Komponentensystem zu implementieren. Gemini entwirft, Claude baut.
Zoe wählt den richtigen Agent für jede Aufgabe aus und leitet Ausgaben zwischen ihnen weiter. Ein Fehler im Abrechnungssystem geht an Codex. Ein Button-Stil-Fix geht an Claude Code. Ein neues Dashboard-Design beginnt mit Gemini.
Wie du das einrichtest
Kopiere diesen gesamten Artikel in OpenClaw und sage: „Implementiere diesen Agent-Swarm-Aufbau für meine Codebasis."
Es wird die Architektur lesen, die Skripte erstellen, die Verzeichnisstruktur einrichten und die Cron-Überwachung konfigurieren. Erledigt in 10 Minuten.
Kein Kurs, den ich dir verkaufen will.
Der unerwartete Engpass
Hier ist die Grenze, an die ich gerade stoße: RAM.
Jeder Agent braucht seinen eigenen Worktree. Jeder Worktree braucht sein eigenes
ode_modules\. Jeder Agent führt Builds, Typchecks, Tests aus. Fünf gleichzeitig laufende Agents bedeuten fünf parallele TypeScript-Compiler, fünf Test-Runner, fünf Sätze von Abhängigkeiten, die im Speicher geladen werden.
Mein Mac Mini mit 16 GB ist bei 4–5 Agents am Limit, bevor er anfängt auszulagern – und ich muss Glück haben, dass sie nicht gleichzeitig bauen.
Also habe ich einen Mac Studio M4 Max mit 128 GB RAM (3.500 $) gekauft, um dieses System zu betreiben. Er kommt Ende März und ich werde berichten, ob es sich lohnt.
Als Nächstes: Das Ein-Personen-Millionen-Dollar-Unternehmen
Wir werden ab 2026 eine Unmenge an Ein-Personen-Millionen-Dollar-Unternehmen sehen. Die Hebelwirkung ist enorm für diejenigen, die verstehen, wie man rekursiv selbstverbessernde Agents baut.
So sieht das aus: Ein KI-Orchestrator als Erweiterung deiner selbst (wie Zoe für mich), der Arbeit an spezialisierte Agents delegiert, die verschiedene Geschäftsfunktionen übernehmen. Entwicklung. Kundensupport. Betrieb. Marketing. Jeder Agent konzentriert sich auf das, was er gut kann. Du behältst den Fokus und die volle Kontrolle.
Die nächste Generation von Unternehmern wird kein Team von 10 Leuten einstellen, um das zu tun, was eine Person mit dem richtigen System schaffen kann. Sie werden so bauen – klein bleiben, schnell sein, täglich ausliefern.
Es gibt im Moment so viel KI-generierten Schrott. So viel Hype um Agents und „Mission Controls", ohne irgendetwas wirklich Nützliches zu bauen. Schicke Demos ohne echten Nutzen.
Ich versuche das Gegenteil: weniger Hype, mehr Dokumentation des Aufbaus eines echten Unternehmens. Echte Kunden, echte Einnahmen, echte Commits, die in die Produktion gehen, und auch echte Verluste.
Was baue ich? Agentic PR – ein Ein-Personen-Unternehmen, das es mit den etablierten PR-Anbietern aufnimmt. Agents, die Startups helfen, Presseberichterstattung zu bekommen, ohne ein zehntausend Dollar teures Retainer-Modell.
Wenn du sehen willst, wie weit ich das treibe, folge mir.
