Ziele und Workflows: lange Aufgaben durch Coding-Agenten
Ich shippe meine Arbeit seit einer Weile durch Coding-Agenten, und der schwerste Teil ist die Übergabe: Wie beschreibe ich eine Aufgabe so, dass ein Agent zwanzig Minuten ohne mein Zutun daran arbeiten kann? Drei Werkzeuge, die ich nutze, antworten unterschiedlich darauf. Claude Code gibt dem Agenten eine Zielbedingung und lässt ihn laufen. Codex hat überhaupt kein Goal-Primitiv. ZCode verwandelt den ganzen Plan in ein Skript, das ich freigebe, bevor irgendwas ausgeführt wird. Ein Production-500 auf dieser Seite hat mir die Unterschiede im September konkret vor Augen geführt.
Was bringt dir ein Ziel in Claude Code?#
Der Befehl /goal nimmt eine Abschlussbedingung, und von diesem Punkt an arbeitet Claude Code „toward a goal until a condition holds“, also so lange, bis die Bedingung erfüllt ist (Claude-Code-Doku). Nach jedem Zug prüft ein schnelles Modell, ob die Bedingung hält. Wenn nicht, startet der Agent einen weiteren Zug, statt die Kontrolle an mich zurückzugeben. Die Bedingung löscht sich selbst, sobald sie erfüllt ist.
/goal all tests in test/auth pass and the lint step is clean
Eine solche Bedingung funktioniert, weil sie prüfbar ist. Die Doku empfiehlt genau diese Form: dicke Aufgaben mit überprüfbarem Endzustand, eine Modul-Migration etwa, die läuft, bis jede Aufrufstelle kompiliert und die Tests grün sind. Ein vages Ziel („mach die Tests besser“) würde endlos laufen oder früher stoppen, und zwar mit hoher Selbstsicherheit.
Darüber sitzt die Orchestrierung. Mit /effort ultracode plant Claude für jede substanzielle Aufgabe einen Workflow, statt sich Zug für Zug durchzuarbeiten (Workflows-Doku). Dynamische Workflows sind JavaScript-Skripte, die viele Subagenten orchestrieren, und der Satz, der zählt, steht in der Doku: „A workflow moves the plan into code“. Das Skript hält die Schleife, die Verzweigungen und die Zwischenergebnisse, der Modellkontext trägt nur noch das Endergebnis. Bevor etwas läuft, zeigt ein Freigabe-Prompt die Phasen, und ich kann das Rohskript lesen, im Editor bearbeiten oder abbrechen.
Codex: das Ziel lebt in deinem Kopf#
Codex hat auf das Gegenteil gesetzt. Ich habe beim Schreiben in die CLI-Quellen gesehen (openai/codex): kein --goal-Flag, kein Goal-Subkommando. Was Codex stattdessen hat, ist eine disziplinierte Ein-Agent-Schleife. Es baut und aktualisiert Pläne nebenbei, jeder Befehl kann eine Freigabe anfordern, und resume, fork und review lassen mich einen Thread wieder aufnehmen oder abzweigen. Strukturierte Output-Schemas zwingen einem Zug ein Format auf, Sandbox-Modi begrenzen, was ein Lauf anfassen darf.
Die Stopp-Bedingung halte bei Codex also ich. Ich schreibe sie in den Prompt, ich lese die Plan-Updates, ich entscheide, wann der Thread fertig ist. Das ist mehr Arbeit im Moment und weniger Maschinerie, der man vertrauen muss. Für kurze Aufgaben der bessere Deal.
Dieselbe Aufgabe in drei Formen#
| Claude Code | Codex | ZCode | |
|---|---|---|---|
| Ziel-Primitiv | /goal-Bedingung, geprüft von einem schnellen Modell pro Zug | keines, die Stopp-Bedingung lebt in meinem Plan | das Workflow-Skript liefert genau ein Endergebnis |
| Plan-Gate | Skript vor dem Lauf freigeben, lesen, editieren | Freigaben pro Befehl, Plan-Updates im Strom | Plan-Modus, explizite Freigabe vor der Ausführung |
| Orchestrierung | Skript mit agent(), pipeline(), parallel() | eine Agent-Schleife, Threads | Skript mit Subagenten, Schleifen mit Gates auf echter Befehlsausgabe |
| Wiederverwendung | Lauf als /command ins Repo oder Home-Dir sichern | resume und fork eines bestehenden Threads | gespeicherte Workflows, benannte Subagenten kommen aus dem Cache |
ZCode, das Werkzeug, in dem ich gerade diesen Text schreibe, sitzt dem Workflow-Modell von Claude Code am nächsten. Seine Läufe bestehen aus benannten Phasen, Subagenten mit typierten Ergebnissen und Gates, die aus echter Befehlsausgabe entscheiden: Ein durchgefallener Check ist dort ein Datenpunkt, kein Absturz. Der Schritt Plan-dann-Freigabe kommt in allen drei zuerst.
Ein Production-500 durch die Mühle#
Diese Woche lieferten vier Blog-Kategorie-URLs auf dieser Seite HTTP 500 in Produktion. Die Aufgabe klang trivial. Dasselbe Deployment hatte gerade ein anderes Crawl-Problem behoben, also war meine erste Hypothese falsch.
Durch einen Planungsagenten sah der Lauf so aus. Zuerst der Plan: die 500er reproduzieren, auflisten, was sich zuletzt geändert hat, jeweils eine falsifizierbare Vermutung aufstellen. Gates auf dem Weg: Die Container-Logs mussten den echten Fehler zeigen, keine Inferenz, bevor irgendein Fix geschrieben wurde. Die Log-Zeile zeigte einen ENOENT beim Lesen einer CSS-Datei beim Modul-Load, sie killte Hypothese eins und produzierte die echte: Die Datei lag im Repo, erreichte aber nie die Docker-Run-Stage. Der Fix war eine COPY-Zeile. Die Verifikation lief vor jedem Deploy: Image lokal bauen, die vier URLs abfragen, 404 für leere Hubs erwarten, 200 für den Rest.
Genau diese Form kodiert ein Ziel gut. keine 500er für irgendeine Blog-URL, die vier Hubs antworten mit 200 oder 404 ist nach jedem Zug prüfbar, und ein schnelles Modell kann den Agenten daran halten, während ich etwas anderes tue. Was das Ziel nicht kodiert, ist der Diagnoseweg, und dort verdient die Workflow-Ebene ihr Geld: eine Phase für die Reproduktion, eine Phase für Hypothesen mit Gate auf echter Log-Ausgabe, eine Phase für den Fix, eine Phase für die Verifikation.
Die Verantwortung bleibt an diesem Tisch#
Alle drei Werkzeuge sagen das in ihrem Design deutlich. Claude Code zeigt mir das Skript und wartet. Codex fragt pro Befehl. ZCode startet ohne freigegebenen Plan gar nicht erst. Das menschliche Gate ist keine Formalie, denn der Agent optimiert auf genau die Bedingung hin, die ich geschrieben habe, und eine falsche Bedingung produziert selbstbewusste Arbeit in die falsche Richtung, komplett mit Prüfungen, die grün bleiben. Ohne genug Fachwissen, um den Plan zu beurteilen, fänge ich die fehlenden Randfälle nicht, das Loch in der Sandbox nicht, die Prüfung nicht, die aus dem falschen Grund grün ist.
Das Finanzamt akzeptiert „der Agent sagte, die Zahlen stimmen“ nicht, und Produktion akzeptiert es auch nicht. Die finale Entscheidung und die Verantwortung bleiben an diesem Tisch, deshalb ist Review Teil der Aufgabe, nie ein Extra (wie ich über Agenten-Disziplin im echten Betrieb denke). Das Werkzeugumfeld reift weiter, von Protokollschichten wie ACP und MCP bis zu Suche, der ein Agent vertrauen kann. Die Gates werden besser. Die Person am Gate bin immer noch ich.