Ich habe begonnen, KI-Coding-Agenten weniger wie Chatfenster und mehr wie Arbeiter mit Verträgen zu behandeln. Der Unterschied ist nicht das Modell. Der Unterschied ist, ob der Agent weiß, was er weiterhin tun soll, wie er Fortschritte nachweisen kann und wann er aufhören soll.
Das ist der Punkt, an dem /loop und /goal wichtig sind.
Claude Code bietet jetzt beide Ideen direkt an: /goal für eine Abschlussbedingung und /loop für wiederholte Eingabeaufforderungen, während eine Sitzung geöffnet bleibt. OpenAI Codex hat /goal als dokumentierten Befehl, und OpenAI dokumentiert auch eval-gesteuerte Verbesserungsloops als Workflow. Das wichtige Detail: Ich würde OpenAI Codex nicht als mit dem gleichen offiziellen /loop-Slash-Befehl beschreiben, es sei denn, dieser erscheint in Ihrer installierten Befehlsliste. In den aktuellen Dokumenten, die ich überprüft habe, ist /goal offiziell; „loop“ ist das Muster.
Diese Unterscheidung ist wichtig, weil diese Werkzeuge von außen ähnlich aussehen, ich sie jedoch für unterschiedliche Aufgaben verwende.
Schnelle Antwort
Verwenden Sie /goal, wenn der Agent ein dauerhaftes Ergebnis anstreben soll, bis eine klare Bedingung erfüllt ist.
Verwenden Sie /loop, wenn der Agent eine Eingabeaufforderung in einem Intervall oder in einem selbstgesteuerten Rhythmus wiederholen soll, während die Sitzung geöffnet bleibt.
Verwenden Sie einen eval-gesteuerten Loop, wenn die Ausgabe bewertet und wiederholt verbessert werden kann: Codequalität, visuelle Qualität, Leistung, SEO, Migrationen, Tests oder jede Aufgabe, bei der jeder Durchgang gemessen werden kann.
Die praktische Regel ist einfach: ein Ziel braucht eine Ziellinie; eine Schleife braucht einen Rhythmus; beide brauchen eine Überprüfung.
Was Claude Code /goal macht
Claudes Befehlsreferenz beschreibt /goal [condition|clear] als eine Möglichkeit, eine Bedingung festzulegen, damit Claude über die Runden hinweg weiterarbeitet, bis diese Bedingung erfüllt ist. Die Hook-Dokumentation fügt ein nützliches Implementierungsdetail hinzu: /goal verhält sich wie eine eingebaute Abkürzung für eine sitzungsbezogene Stop-Bedingung.
In einfachem Englisch sagt /goal zu Claude:
Das ist mächtig, aber nur, wenn die Bedingung konkret ist.
Schwach:
text /goal Mach die App besser
Nützlich:
text /goal Behebe den Checkout-Bug, halte alle bestehenden Zahlungsfunktionen intakt und höre nur auf, wenn pnpm test, pnpm build und der Playwright-Checkout-Pfad alle bestehen.
Die zweite Version gibt Claude ein Ziel, Grenzen und einen Nachweis. Es kann den Weg entscheiden, aber nicht den Erfolg mitten im Prozess neu definieren.
Ich benutze /goal für Arbeiten wie:
In dem Moment, in dem eine Aufgabe mehrere nicht verwandte Ergebnisse hat, verwende ich nicht ein großes Ziel. Ich teile es auf. Ein Ziel pro Ergebnis ist sauberer und einfacher zu vertrauen.
Was Claude Code /loop macht
Claudes Befehlsreferenz listet /loop [interval] [prompt] als gebündelte Fähigkeit. Es führt eine Eingabeaufforderung wiederholt aus, während die Sitzung geöffnet ist. Sie können ein Intervall angeben, Claude selbst steuern lassen oder die Eingabeaufforderung weglassen und es eine konfigurierte Wartungsaufforderung verwenden lassen, wo verfügbar.
Das macht /loop operativer als /goal.
Beispiele:
text /loop 5m Überprüfe, ob das Vercel-Vorschau-Deployment bereit ist, dann überprüfe /blog und /api/health
text /loop Nimm den nächsten nicht überprüften Punkt in PRODUCTION_READINESS.md, behebe ihn, führe den relevanten Test aus und aktualisiere die Checkliste
text /loop alle 10m Überprüfe CI, fasse Fehler zusammen und höre erst auf, wenn der letzte Durchlauf grün ist
Der beste Anwendungsfall ist wiederholtes Überprüfen oder wiederholte kleine Arbeitseinheiten. In meinem hybriden KI-Code-Überprüfungsloop→ war das nützliche Muster nicht „schreibe für immer“. Es war: Nimm einen Punkt aus der Checkliste, implementiere ihn, bitte ein anderes Modell um eine Überprüfung, führe den Build aus, hake das Kästchen ab, wiederhole.
Das ist es, was /loop gefährlich macht, wenn Sie eine faule Eingabeaufforderung schreiben. Wenn die Eingabeaufforderung nicht sagt, was zu überprüfen ist, kann der Agent weiterhin plausible Arbeiten leisten, denen niemand vertrauen sollte.
Was OpenAI Codex /goal macht
OpenAI dokumentiert /goal für Codex sowohl in der App als auch in der CLI. Der Codex-Leitfaden rahmt es als ein dauerhaftes Ziel für langlaufende Arbeiten ein, insbesondere wenn die Aufgabe eine klare Erfolgsbedingung und einen Validierungsloop hat.
Die Codex-CLI-Befehlsreferenz listet /goal als den Befehl auf, um ein Ziel festzulegen, zu pausieren, fortzusetzen, anzuzeigen oder zu löschen. Die App-Dokumentation sagt dasselbe in Produktbegriffen: Ein Ziel ist beständig, sichtbar und kann pausiert oder fortgesetzt werden.
Ein gutes Codex-Ziel sieht fast identisch aus wie ein gutes Claude-Ziel:
text /goal Schließe die Migration auf Next.js 16 ab, ohne öffentliche Routen zu ändern. Höre nur auf, wenn pnpm build besteht, die Startseite lädt, /blog lädt und die geänderten Routen 200 zurückgeben.
Für Codex mag ich Ziele, die benennen:
OpenAIs eigene Anleitung für schwierige Probleme ist nah an dem, wie ich bereits arbeite: Geben Sie Codex ein Bewertungssystem, machen Sie fokussierte Verbesserungen, führen Sie die Bewertung erneut aus, überprüfen Sie Artefakte und machen Sie weiter, bis die Bewertung gut genug ist.
Das ist das Herz der agentischen Arbeit. Nicht Autonomie um ihrer selbst willen. Autonomie, die an Messung gebunden ist.
Hat OpenAI /loop?
Hier können die Leute mit der Formulierung nachlässig werden.
Claude Code hat einen dokumentierten /loop-Befehl. OpenAI Codex hat dokumentierte Loop-ähnliche Workflows: eval-loops, Reparaturschleifen, Zielmodus mit Validierung, Hooks und Automatisierungen. Aber in der aktuellen Codex-Slash-Befehlsreferenz, die ich überprüft habe, fand ich /goal, /plan, /review, /status, /mcp und viele andere, jedoch keinen offiziellen /loop-Befehl, der dem von Claude entspricht.
Also ist meine Formulierung:
Das ist keine Schwäche. Es ändert nur, wie ich es einrichte. In Codex drücke ich normalerweise die Schleife innerhalb des Ziels oder der Eingabeaufforderung aus:
text /goal Verbessere diese Komponente, bis der visuelle Regressionstest über 95 % liegt. Mache eine fokussierte Änderung nach der anderen, führe den Screenshot-Vergleich nach jeder Änderung durch, führe ein Protokoll über die Punktzahlen und höre auf, wenn das Ziel zweimal hintereinander erreicht wird.
Das gibt Codex den gleichen Betriebsrhythmus, ohne vorzugeben, dass es einen separaten /loop-Slash-Befehl gibt.
Mein praktisches Setup
Für ernsthafte Arbeiten verwende ich ein fünfstufiges Muster.
1. Ein schriftliches Ziel
Ich beginne mit einem kurzen Plan oder einer Checkliste. Es kann `PLAN.md`, `PRODUCTION_READINESS.md`, ein GitHub-Issue oder eine einfache Eingabeaufforderung sein. Das Format ist weniger wichtig als die Überprüfbarkeit.
Eine schwache Aufgabe sagt „verbessere das Artikelsystem.“
Eine starke Aufgabe sagt „verhindere die Veröffentlichung, wenn externe URLs 404, weiche 404, falschen Inhaltstyp zurückgeben oder auf das falsche Ziel umleiten; halte Entwurfsspeicherungen erlaubt; beweise mit Build und einem fokussierten Validierungsfall.“
Das ist die Art von Anweisung, auf die ein Agent weiterhin reagieren kann.
2. Ein Eigentümer-Modell
Wählen Sie, wer das Steuer übernimmt. Claude kann der Umsetzer sein. Codex kann der Umsetzer sein. Lassen Sie nicht beide gleichzeitig dieselben Dateien bearbeiten, es sei denn, Sie haben Arbeitsbäume oder eine strenge Übergabe. Autonomie ohne Eigentum wird zum Theater von Merge-Konflikten.
3. Eine zweite Meinung
Für risikoreichere Arbeiten mag ich immer noch die Überprüfung von Modell zu Modell. Ich habe über meine KI-Peer-Review-Brücke→ geschrieben, weil sie unterschiedliche Fehlerarten erfasst als ein einzelnes Modell, das sich selbst überprüft.
Der Prüfer kann schreibgeschützt sein. Er benötigt keinen Schreibzugriff, um nützlich zu sein. Er benötigt den Diff, das Ziel, die riskanten Dateien und die Erlaubnis zu sagen: „das ist falsch.“
4. Ein harter Validator
Tests schlagen Vertrauen. Builds schlagen Zusammenfassungen. Screenshots im Browser schlagen „es sollte gerendert werden.“ Protokolle schlagen Vibes.
Für Webarbeiten bedeutet das normalerweise:
bash pnpm build pnpm lint pnpm test
plus Routenprüfungen, Screenshots oder Playwright-Flows, wenn die Aufgabe benutzerorientiert ist.
Für Inhalts-Workflows bevorzuge ich URL-QA vor der Veröffentlichung: nicht nur „hat der Link 200 zurückgegeben“, sondern „hat er die Seite erreicht, die der Artikel behauptet hat?“ Das ist dasselbe Prinzip. Der Validator sollte das überprüfen, was der Leser tatsächlich erlebt.
5. Eine Stoppregel
Das ist der Teil, den die Leute überspringen.
Eine Schleife ohne Stoppregel wird teuer. Ein Ziel ohne Stoppregel wird vage. Eine Stoppregel sollte langweilig und wörtlich sein:
Diese letzte Zeile ist wichtig. Gute Agenten verbergen Unsicherheit nicht. Sie bringen sie ans Licht.
Wann ich jedes benutze
| Situation | Bestes Werkzeug | Warum |
|---|---|---|
| --- | ---: | --- |
| Eine große Aufgabe mit einer klaren Definition des Abschlusses | /goal | Der Agent kann weiterhin auf einen dauerhaften Endzustand hinarbeiten |
| Überprüfung des Bereitstellungsstatus alle paar Minuten | Claude /loop | Dieselbe Überprüfung muss wiederholt durchgeführt werden |
| Verbesserung eines generierten Artefakts gegen eine Punktzahl | Eval-Loop | Die Punktzahl sagt dem Agenten, ob der letzte Durchgang etwas verbessert hat |
| Aufräumen einer Checkliste Punkt für Punkt | /loop oder /goal | Verwenden Sie /loop für wiederholte Punkte, /goal für das endgültige Ergebnis |
| Forschung mit ungewisser Richtung | Normale Eingabeaufforderung oder Planmodus | Beginnen Sie nicht mit Autonomie, bevor das Ziel klar ist |
| Sensible Produktionsaktion | Menschliche Genehmigung | Agenten können die Aktion vorbereiten, sollten sie jedoch nicht stillschweigend ausführen |
Copy-Paste-Eingabeaufforderungen
Claude Code /goal
text /goal Beende diesen Bugfix, ohne unrelated behavior zu ändern. Lies zuerst AGENTS.md und die relevanten Routen-/Komponenten-Dateien. Mache kleine Commits in der Logik, führe pnpm build und den fokussierten Regressionstest aus und höre nur auf, wenn der ursprüngliche Bug nicht mehr reproduziert wird und alle Überprüfungen bestehen.
Claude Code /loop
text /loop Nimm den nächsten nicht überprüften Punkt in TODO.md, überprüfe zuerst die echten Dateien, mache einen fokussierten Fix, führe den relevanten Validierungsbefehl aus, aktualisiere das Kontrollkästchen erst nach der Überprüfung und berichte über jeden Blocker, anstatt ihn zu überspringen
OpenAI Codex /goal
text /goal Schließe die in PLAN.md beschriebene Migration ab. Bewahre das öffentliche Verhalten, halte nicht verwandte Dateien unverändert, führe die aufgeführten Validierungsbefehle nach jedem Meilenstein aus, führe ein kurzes Fortschrittsprotokoll und höre nur auf, wenn jeder Meilenstein abgeschlossen ist und der endgültige Build besteht.
Codex eval-gesteuerte Loop-Eingabeaufforderung
text Ich möchte dies als eval-gesteuerten Verbesserungsloop. Finde oder erstelle den Befehl, der die Ausgabe bewertet. Mache eine fokussierte Verbesserung nach der anderen, führe die Bewertung nach jeder Änderung erneut aus, überprüfe direkt alle generierten Artefakte, protokolliere Punktänderungen und iteriere weiter, bis die Zielpunktzahl zweimal hintereinander erreicht wird. Wenn die Punktzahl nicht mehr steigt, erkläre den Engpass und höre auf.
Häufige Fehler
Der erste Fehler besteht darin, /goal als motivierenden Satz zu verwenden. „Mach dies produktionsbereit“ ist kein Ziel. Es ist eine Stimmung.
Der zweite Fehler besteht darin, /loop ohne Validator zu verwenden. Wenn jede Iteration mit einer nicht überprüften Behauptung endet, ist die Schleife nur Wiederholung.
Der dritte Fehler besteht darin, nicht verwandte Arbeiten zu bündeln. „Behebe Authentifizierung, gestalte das Dashboard neu, aktualisiere die Preisgestaltung und bereinige SEO“ sollten vier Aufgaben sein, nicht ein heroischer autonomer Lauf.
Der vierte Fehler besteht darin, dem Agenten Schreibzugriff zu gewähren, bevor er die Repo-Regeln versteht. In meinen eigenen Projekten möchte ich, dass Agenten `AGENTS.md` lesen, die Bereitstellungsregeln respektieren, Geheimnisse vermeiden und überprüfen, bevor sie Erfolg beanspruchen. Die Kontrollschicht um das Modell ist ebenso wichtig wie das Modell selbst. Deshalb komme ich immer wieder auf MCP-Entwickler-Workflows→ zurück: Werkzeuge, Berechtigungen, Beweise und wiederholbare Aktionen sind das, was einen cleveren Chat in ein operatives System verwandelt.
Der eigentliche Punkt
Das Interessante an /loop und /goal ist nicht die Syntax des Slash-Befehls. Das Interessante ist der Wandel in der Verantwortung.
Eine normale Eingabeaufforderung sagt: Antworte mir.
Ein Ziel sagt: Beende dies und wisse, was beendet bedeutet.
Eine Schleife sagt: Überprüfe oder verbessere weiter, bis sich die Bedingung ändert.
So möchte ich, dass KI-Coding-Agenten arbeiten. Nicht als Magie. Nicht als unbeaufsichtigtes Chaos. Als Arbeiter mit einem Vertrag, einem Validator und einer klaren Stoppregel.
Wenn Sie Claude Code verwenden, ist /loop der schnellste Weg, um eine wiederholte operationale Überprüfung in etwas zu verwandeln, das der Agent handhaben kann, während Sie weiterarbeiten. /goal ist das bessere Werkzeug, wenn die Arbeit einen dauerhaften Endzustand hat.
Wenn Sie OpenAI Codex verwenden, gibt Ihnen /goal das dauerhafte Ziel, und die Schleife gehört in das Validierungsdesign: Tests, Auswertungen, Artefakte, Hooks, Fortschrittsprotokolle und eine Stoppbedingung, die der Agent nicht stillschweigend neu definieren kann.
Das ist das Muster, dem ich vertraue: nicht „lass die KI laufen“, sondern „lass die KI innerhalb eines Systems laufen, das ihr Nein sagen kann.“