- Das entscheidende Kriterium bei der Wahl eines Coding-Agenten verlagert sich von der reinen Modellleistung hin zur verfügbaren Zeit des Nutzers und der Dauer autonomer Ausführung; Claude Code und Codex werden je nach Situation parallel eingesetzt
- Opus hat Stärken bei Context-Window-Management und Tool-Nutzung und ist vorteilhaft für schnelle Erkundung und Planung, weil mehrere Sub-Agenten gleichzeitig ausgeführt werden können
- Codex übertrifft Opus bei der Code-Korrektheit, hat aber den Nachteil geringerer Verarbeitungsgeschwindigkeit, da die Delegation von Aufgaben zwischen Context Windows schwach ausgeprägt ist
- Durch Skill-Automatisierung wurde schrittweise ein Loop aus Planung → Implementierung → Review → Bugfixing aufgebaut; wirksam ist ein Ansatz, der wiederkehrende manuelle Arbeit schrittweise automatisiert, statt alles von Anfang an zu entwerfen
- Langfristig geht die Entwicklung in Richtung einer Zukunft, in der Agenten 24/7 autonom arbeiten, doch Grenzen der Context Windows und Resistenz gegen Prompt Injection bleiben die wichtigsten Hürden
Hintergrund
- Es wurde an der Web-Version von Codex gearbeitet; im Juli 2025 erfolgte der Austritt bei OpenAI
- Nach dem YC Lightcone Podcast wurde dieser Text zusammengestellt, um detaillierte Strategien für den Einsatz von Coding-Agenten zu ordnen
- Die Kriterien zur Agentenauswahl verschieben sich von Modellleistung hin zu autonomer Ausführungszeit und geschäftlicher Wichtigkeit
- Claude Max, ChatGPT Pro und Cursor Pro+ sind alle abonniert; gemessen an der Produktivität ist das sehr kosteneffizient
Kernprinzip: Kontext verstehen
- Wer Coding-Agenten gut nutzen will, muss Kontext (context) unbedingt verstehen
- Egal wie leistungsfähig ein Agent ist, am Ende führt er next token prediction aus, und alle Tokens müssen in das Context Window passen
- Daraus ergeben sich zentrale Prinzipien:
- Probleme müssen in passend große Teile für das Context Window aufgeteilt werden; zu große Probleme dauern lange und liefern schlechtere Resultate
- Compaction ist eine verlustbehaftete Technik; der Agent entscheidet, welche Informationen aufgenommen und welche weggelassen werden, und mit mehr Compaction sinkt tendenziell die Leistung
- Wenn man Kontext in das Dateisystem auslagert, etwa über Planungsdokumente, kann der Agent selektiv lesen und sich erinnern, ohne den gesamten Gesprächskontext zu füllen
- Es ist wichtig, in der „smarten Hälfte“ des Context Windows zu bleiben; da das Training auf kurzen Kontextdaten besser funktioniert, entstehen bessere Ergebnisse, wenn das Window weniger gefüllt ist — Dex Horthy beschreibt das als außerhalb der „dumb zone” zu bleiben
- Wenn der Agent relevante Dateien oder Pakete übersieht, kann er in unerwartete Richtungen laufen; „progressive disclosure“ der Codebase-Struktur und Architektur hilft dabei — OpenAI hat dazu einen Blogpost veröffentlicht, wie mehrere Markdown-Dateien strukturiert werden: Wie OpenAI mehrere Markdown-Dateien strukturiert
- Modellleistung und Geschwindigkeit hängen nicht nur von der Rohleistung des Modells ab, sondern auch von der Fähigkeit, mehrere Context Windows zu verwalten und an Sub-Agenten/Teams zu delegieren
Opus: Kontextverwaltung, Tool-Nutzung, menschlicher Eindruck
- Claude Code wird als Hauptwerkzeug für Planung, Terminal-Orchestrierung und Verwaltung von git/GitHub-Aufgaben verwendet
- Opus ist darauf trainiert, über mehrere Context Windows hinweg sehr effizient zu arbeiten; dadurch fühlt sich Claude Code schneller an als Codex
- Es ist häufig zu beobachten, dass Opus mehrere Sub-Agenten gleichzeitig startet, etwa über
Explore- oderTask-Aufrufe- Das Explore-Tool verwendet Haiku, verarbeitet daher große Token-Mengen schnell und übergibt relevanten Kontext an Opus
- Auch für die Nutzung lokaler Tools wie
gh,gitund verschiedener MCP-Server ist es gut trainiert- Mit der
/chrome-Erweiterung lassen sich Bugs verifizieren, sie kann aber langsam und instabil sein
- Mit der
- Das Berechtigungsmodell von Claude Code ist leichter verständlich als das von Codex — das Codex-Modell neigt dazu, Befehle in bash zu skripten, was das Whitelisting einzelner CLI-Tools erschwert
- Feine UX-Vorteile von Claude Code: Terminaltitel werden aufgabenbezogen aktualisiert, die Statusleiste zeigt das aktuelle PR an, dazu kommen kleine Statusmeldungen
- Opus ist besser als Codex darin, für Menschen verständliche PR-Beschreibungen und detaillierte Architekturdiagramme zu erzeugen
- Wenn Erklärungen zur Codestruktur benötigt werden, wird meist Claude Code verwendet
- Bei der Planung ist Opus „kreativer“ und schlägt Dinge vor, die der Nutzer nicht erwähnt hat, oder weist auf mehrdeutige Bereiche hin
Codex: überragende Code-Korrektheit
- Die Domäne, in der Codex glänzt, ist die Korrektheit des Codes (correctness); auch andere Entwickler mit intensiver Modellnutzung sehen das so
- Läuft Codex mit GPT-5.3-Codex-xhigh oder high, enthält der erzeugte Code deutlich weniger Bugs
- Häufige Fehler von Opus:
- Eine React-Komponente besteht zwar Unit-Tests, aber es wird vergessen, sie im obersten
<App>hinzuzufügen - Ein offensichtlicher off-by-one-Fehler wird nicht erkannt
- Subtile dangling references oder Race Conditions
- Eine React-Komponente besteht zwar Unit-Tests, aber es wird vergessen, sie im obersten
- Lange Zeit wurde angenommen, der Unterschied zwischen beiden Modellen sei vernachlässigbar; nach ausreichend vielen PRs mit automatischen Reviews von Codex und Cursor Bugbot wurde jedoch die Codequalität der OpenAI-Modelle als überlegen eingeschätzt
- Für einen direkten A/B-Test kann man einen Branch auschecken und dann Claude Codes
/code-reviewmit Codex’/reviewvergleichen
- Für einen direkten A/B-Test kann man einen Branch auschecken und dann Claude Codes
- Codex ist jedoch langsam — der Hauptgrund ist die schwache Delegation von Aufgaben zwischen Context Windows; auch die Latenz zwischen Tokens wird subjektiv als höher empfunden
- Mit experimenteller Sub-Agent-Unterstützung (
/experimental-Toggle) funktioniert es zwar, aber nicht so reibungslos wie bei Claude und mit noch unzureichender Parallelität
- Mit experimenteller Sub-Agent-Unterstützung (
- Das Ergebnis ist ein Muster, bei dem mit Claude Code begonnen wird und dann für die eigentliche Codierung zu Codex gewechselt wird
Nützliche Tools und Setups
- Aktuell wird an einer Greenfield-Codebase gearbeitet, die deutlich kleiner und tokeneffizienter ist als eine Produktions-Codebase
- Repo-Struktur: In allen Repos gibt es einen
plans/-Ordner mit nummerierten Plandokumenten, Dienste sind über denapps/-Ordner getrennt, das TypeScript-Monorepo wird mit turborepo verwaltet und für schnelle Installationen wird bun verwendet - Ghostty: das Terminal von Mitchellh, schnell, nativ und kontinuierlich verbessert — früher wurden mehrere Claude-/Codex-Instanzen mit tmux betrieben, heute stattdessen mehrere Pane in demselben Terminal-Tab
- Next.js auf Vercel, API auf Cloudflare Durable Objects: eine Struktur, die die Datenbank vorab partitioniert, bei Bedarf aufweckt und weniger Sorgen um konkurrierende Schreibzugriffe macht — aus Infrastruktursicht passend für ein Zeitalter, in dem Agenten mit kleinen Datenstücken arbeiten
- Cloudflare erweitert dies mit der Bibliothek cloudflare/actors in Richtung einer Kopplung von Compute und kleinem co-located Storage
- Worktrees: Weil der Code leichtgewichtig ist, werden parallele Worktrees genutzt; in jedem erfolgt lokale Verifikation via
bun install→bun run dev— dafür gibt es dasworktree-Skill, das zugehörige Pläne, Umgebungsvariablen und Updates kopiert und einen neuen Branch startet- Vor Coding-Agenten wurden meist nur Branches verwendet, aber die Kombination aus Worktree und Claude Code ist sehr nützlich
- Plan, Implement, Review: Das Modell wird fast immer dazu gebracht, mit einem Plan zu beginnen — 1) Kontext wird über ein einzelnes Context Window hinaus externalisiert 2) es wird möglich, zu reviewen oder nachzufragen, was gemacht wurde — wenn der Agent stoppt, kann der Plan in einem neuen Context Window fortgesetzt werden
- Preview deploys: Jeder Branch erhält ein neues Web- und API-Deployment, was parallele Ausführung und schnelles Testen erleichtert — ohne dieses Feature wäre das Arbeiten schwierig
- Cursor Bugbot und Codex Code Review: Code wird auf Architekturebene verstanden und punktuell geprüft, aber es werden zunehmend nicht mehr alle Zeilen jedes PRs gelesen — Agenten sind besser darin, subtile Bugs zu finden
- Früher wurden Claude Code, Cursor Bugbot und Codex alle drei genutzt, doch Claude Code fand praktisch keine relevanten Probleme; daher ist Cursor die Standardoption, Codex wird ebenfalls als stark bewertet
Skills: der Schlüssel zur Automatisierung
- Mehrere Skills sowie gemeinsame AGENTS.md/CLAUDE.md sind in einem Repo namens claudefiles definiert
- Regel zum Hinzufügen von Skills: nicht vorschnell ergänzen, sondern erst nach mehreren Wiederholungen und stabilisiertem Workflow
- AGENTS/CLAUDE.md ist nützlich, um die allgemeine Richtung des Modells zu steuern; Skills haben zwei Zwecke:
- Workflow-Chaining und Automatisierung — Planung → schrittweise Implementierung → Review werden jeweils als Skill angelegt und über ein Meta-Skill in Reihenfolge ausgeführt
- Aufteilung des Context Windows — wenn bei einem Skill-Aufruf in Claude Code
context: forkgesetzt wird, kann er in einem neuen Context Window laufen; so werden „Master-Orchestrator“ und Sub-Agenten getrennt
- Skills sind sehr kontexteffizient; anders als MCP-Aufrufe mit Tausenden Tokens benötigen sie meist nur ~50–100 Tokens
Entwicklung der Skill-Automatisierung
- Anfangs bestand Interesse an der Idee eines Skill-Marktplatzes (Installation für Frontend-Design, Security-Checks, Architektur-Reviews usw.), doch im Verlauf der Arbeit wurden die meisten von anderen geschriebenen Skills aufgegeben
- Stattdessen erfolgte der Wechsel dazu, zunächst manuell zu arbeiten und dann zu überlegen, wie sich das automatisieren lässt
- Evolutionsprozess der Skills:
/commit: Statt dem Modell Commit und Push auf verschiedene Weise zu erklären, wurde alles in einem Skill gebündelt — direkt von Claude Code übernommen/worktree: Damit der Agent in einem separaten Worktree arbeitet, wird auf Basis der Plannummer (z. B. 00034-add-user-auth) ein neuer Worktree erzeugt/implement: Wiederkehrende Arbeit aus Ausführung eines Planschritts und anschließendem/commitin einem Skill zusammengefasst/implement-all: Verknüpft den aktuellen Worktree-Pfad mit der Plannummer und implementiert alle Schritte automatisch — bei nächtlichen Läufen wird mit/ralph-loopweitergemacht, bis alle Schritte abgeschlossen sind; lokal erzeugt/codex-revieweinencodex --review-Prozess/address-bugs: Sucht über die GitHub-API nach Cursor- und Codex-Kommentaren seit dem letzten Commit und versucht, Bugs zu verifizieren und zu beheben/pr-pass: Läuft nach Abschluss von/implement-allund führt 1) Push zum Remote 2) Warten auf alle erfolgreichen CI-Läufe 3) Ausführen von/address-bugssowie optional Wiederholung von Schritt 1 aus/focus: Liestplans-Verzeichnis, offene PRs und Worktrees aus, frischt das Gedächtnis auf und hilft bei der Nachverfolgung der Arbeit
- Wäre versucht worden, diesen Prozess von Anfang an komplett zu entwerfen, wäre das wohl nicht gelungen; entscheidend war der schrittweise Aufbau durch das Entdecken kleiner Bereiche zur Automatisierung über die Zeit
Weitere Tools
- Die Codex App wurde kürzlich ausprobiert und hinterließ einen positiven Eindruck bei Details und kleinen Touches — ein vollständiger Wechsel erfolgt aber nicht, da die Flexibilität von CLI-Tools bevorzugt wird
- Cowork wurde ebenfalls getestet, ließ sich aber schwer zuverlässig zum Laufen bringen; in beiden Fällen macht das Sandboxing-Modell einen großen Unterschied
- Für asynchrone Arbeit wird gelegentlich die Weboberfläche genutzt, insgesamt verlagert sich die Nutzung aber immer stärker auf die CLI — im Kontrast zu vor sechs Monaten, als überwiegend Cursor und eingebaute Agenten-/Erweiterungsfunktionen genutzt wurden
- pencil.dev wird für Frontend-UI-Arbeit verwendet — interessant ist das Deployment-Modell, das per Shell-out auf lokales Claude Code setzt und bestehende Abos wiederverwendet
- Es wird der Bedarf an einem stärker formalisierten Issue-Tracker gespürt; Dex von David Cramer und beads von Steve Yegge wirken vielversprechend, erscheinen derzeit aber noch unnötig komplex
- Automatisierte e2e-MCPs wie Playwright werden aktuell nicht verwendet
Hinweise an die Labs
-
Feedback an Anthropic
- Modell: Opus wirkt menschlich, nutzt Engineering-Tools gut, teilt Kontext gut auf und schlägt Dinge vor, „die der Nutzer vielleicht vergessen hat“, hat aber Defizite bei der Code-Korrektheit — gewünscht ist ein „Opus Strict“-Modus, der per stärkerem RL das Basismodell verbessert
- Gestartet wird mit Opus, aber der Code wird von Codex geschrieben; bei Budgetgrenzen würde Codex gewählt
- Produkt-Harness: Es gibt fast nichts zu kritisieren, die Ideen von Boris und Cat sind ausgezeichnet
- Gewünscht wird die Übernahme eines Standards für agent skills — Verzeichnis-Symlinks zwischen verschiedenen CLIs sind umständlich
- Es wird um Offenlegung des Ausgabeformats von
--stream-jsongebeten — Interesse besteht daran, Claude Code im Sandbox-Modus stellvertretend für Nutzer laufen zu lassen, aber Formatänderungen und die Pfadkonfiguration sind problematischer als bei anderen CLI-Tools (Codex, Cursor, Gemini)
- Modell: Opus wirkt menschlich, nutzt Engineering-Tools gut, teilt Kontext gut auf und schlägt Dinge vor, „die der Nutzer vielleicht vergessen hat“, hat aber Defizite bei der Code-Korrektheit — gewünscht ist ein „Opus Strict“-Modus, der per stärkerem RL das Basismodell verbessert
-
Feedback an OpenAI
- Modell: Höchste Priorität hat die Verbesserung von Aufteilung über Context Windows hinweg und Delegation an Sub-Agenten — auch das von Opus bei der Planung erreichte Konzept „mehr als verlangt liefern“ wäre nützlich
- Detailliertes Feedback zum Produkt-Harness:
- Das Sandboxing-Modell ist im Vergleich zu Claude Code schwerer zu verstehen — weil das Modell zum Skripting neigt, entstehen viele Genehmigungsanfragen, was bei
--yoloSorge bereitet - Gewünscht ist eine in die CLI eingebaute Benutzerführung wie bei Claude Code — damit man zu Skill-Orten, unterstützten Feldern und Sandboxing-Einstellungen Fragen stellen kann
/reviewsollte von einem paketierten Befehl in ein allgemeines Skill umgewandelt werden, damit das Modell es dynamisch aufrufen kann- Gewünscht wird, dass beim Ausführen der Terminal-Tab-Titel aufgabenbezogen geändert wird — sonst entsteht Verwirrung bei Dutzenden
codex-Tabs - Es braucht spezifisches Training für PR- und Commit-Beschreibungen — die knappe Art von Codex ist gut, aber die Erklärungen sollten ausführlicher werden
- Gewünscht wird Unterstützung für
context: forkin Skill-Definitionen - Links, die in einem Pane umbrochen werden, sollten weiterhin anklickbar bleiben
- In der unteren Statusleiste sollte der aktuelle Worktree/PR/Branch-Name angezeigt werden
- Das Sandboxing-Modell ist im Vergleich zu Claude Code schwerer zu verstehen — weil das Modell zum Skripting neigt, entstehen viele Genehmigungsanfragen, was bei
Ausblick
- Es wird auf Steve Yegges Beitrag Gas Town verwiesen — die These: Tokens sollten immer maximal genutzt werden, Worker-Pools 24/7 laufen, und man müsse erwarten, viele Pläne zu machen und wieder zu verwerfen
- Unabhängig davon, ob die Abstraktion exakt stimmt, wird die Richtung als absolut richtig eingeschätzt
- Die ideale Zukunft: Laptop oder Cloud-Sandbox verarbeitet im Hintergrund fortlaufend Ideen, während der Nutzer Richtung vorgibt, recherchiert oder Ergebnisse reviewt
- Arbeit mit Coding-Agenten fühlt sich ähnlich wie die Rolle eines Engineering Managers an, nur dass man sich nicht um Motivation oder Persönlichkeit der Agenten kümmern muss
- Dieser Zukunft ist man inzwischen ziemlich nahe — auf Twitter wird viel übertrieben, aber in der Praxis werden vor dem Schlafengehen tatsächlich 3–4 Aufgaben in Codex gestartet und morgens reviewed
- Für einen echten 24/7-Betrieb von Agenten reicht es aber noch nicht
- Zwei Hürden blockieren größeren Fortschritt:
- Größe/Orchestrierung von Context Windows — ein Agent kann nicht endlos im selben Context Window komprimieren und recyceln; es braucht intelligentere Harnesses oder Delegationsmechanismen
- Resistenz gegen Prompt Injection — Agenten fragen schon nach wenigen Minuten nach Freigaben;
--yoloist nicht vertrauenswürdig, auch wenn es eine Teilmenge akzeptabler Berechtigungen/Domänen gibt
- Beim ersten Problem verschiebt Cursor die Grenzen von Agent-Swarms über viele Context Windows hinweg, das zweite ist ein aktives Forschungsfeld
- Sandbox-Ausführung ist derzeit der beste Workaround, aber die Einrichtung bleibt mühsam; wenn ein Agent gleichzeitig offenen Internetzugang und privilegierte Daten hat, ist er anfällig für Simon Willisons „Lethal Trifecta“
- Als Solo-Engineer ist bereits jetzt die richtige Idee der Engpass, und künftig werden immer stärker Ideen, Architektur und Projekt-Sequenzierung zu den limitierenden Faktoren für großartige Produkte
4 Kommentare
Auch die Architektur...?
Wenn Codex nur eine Sub-Agent-Funktion hätte, würde ich wohl schon wechseln.
Aber vielleicht interessiert es sie einfach nicht..
https://developers.openai.com/codex/multi-agent
Es scheint noch experimentell zu sein, aber man arbeitet wohl daran.
In der codex cli kann man mit dem Befehl
/experimentalexperimentelle Funktionen aufrufen; dabei wird auch Multi-agents angeboten.› [x] Multi-agents Ask Codex to spawn multiple agents to parallelize the work and win in efficiency.
Ich weiß nicht, ob das genau in die gleiche Richtung geht wie der von Ihnen erwähnte Sub-Agent, aber schauen Sie es sich doch einmal an.