- 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- oder Task-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, git und verschiedener MCP-Server ist es gut trainiert
- Mit der
/chrome-Erweiterung lassen sich Bugs verifizieren, sie kann aber langsam und instabil sein
- 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
- 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-review mit Codex’ /review vergleichen
- 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
- 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 den apps/-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 das worktree-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: fork gesetzt 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 /commit in 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-loop weitergemacht, bis alle Schritte abgeschlossen sind; lokal erzeugt /codex-review einen codex --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-all und führt 1) Push zum Remote 2) Warten auf alle erfolgreichen CI-Läufe 3) Ausführen von /address-bugs sowie optional Wiederholung von Schritt 1 aus/focus: Liest plans-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-json gebeten — 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)
-
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
--yolo Sorge 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
/review sollte 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: fork in 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
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;
--yolo ist 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
Noch keine Kommentare.