Codex /goal Command: meine ehrliche Sicht auf autonomous coding

Codex /goal Command: meine ehrliche Sicht auf autonomous coding

Als ich Codex zum ersten Mal einen /goal gab und von meinem Schreibtisch wegging, kam ich vierzig Minuten später zurück und stellte fest, dass dieselbe Funktion elf Mal neu geschrieben worden war. Elf. Jede Version ein wenig anders. Keiner davon ist objektiv besser als der vorherige. Der agent befand sich in einer Schleife – nicht im produktiven Ralph-loop-Sinn, sondern im Sinne von „Ich habe keine Ahnung, wann ich aufhören soll“. Mein Ziel war es, „das Rendering schneller zu machen“. Das war die ganze Aufforderung. Das war das ganze Problem.

Ich hatte einem seit langem laufenden autonomen agent ein vages Ziel vorgegeben und war dann überrascht, als es abwanderte.

Der Befehl Codex /goal wurde Ende April in Version 0.128.0 veröffentlicht und ändert die Form dessen, was ein codierender agent tun soll. Die meisten Slash-Befehle sind reaktiv – Sie fragen, es antwortet, Sie fragen erneut. /goal ist das Gegenteil. Sie legen einmal ein Ziel fest und Codex durchläuft so lange Planen, Handeln, Testen, Bewerten und Wiederholen, bis entweder das Ziel nachweislich erreicht ist oder Sie ihm sagen, dass es damit aufhören soll. Es kommt dem „Feuer-und-Vergessen“-System, das ich verwendet habe, am nächsten und fühlt sich nicht völlig aus den Fugen geraten an.

Aber „fühlt sich nicht völlig aus den Fugen geraten“ macht in diesem Satz viel aus. Denn der Unterschied zwischen einem /goal-Lauf, der einen Leistungsgewinn von 25 % liefert, und einem, der elf Versionen derselben fehlerhaften Funktion erzeugt, ist nicht das Modell. Es ist auch nicht die Aufforderung. Es ist etwas Subtileres – und wenn man es einmal gesehen hat, kann man es nicht mehr übersehen.

Ich habe die letzten zwei Wochen in diesem Kommando verbracht. Hier erfahren Sie, was ich gelernt habe, was ich falsch gemacht habe und welches Framework ich jetzt verwende, um zu entscheiden, ob eine Arbeit in einen /goal-Lauf oder einen normalen Pull-Request gehört.

Was der Befehl Codex /goal eigentlich ist

Lassen Sie mich zunächst die Marketingsprache aus diesem Ding herausnehmen, da das OpenAI-Änderungsprotokoll – wie immer – äußerst knapp darüber ist, was geliefert wurde.

Der Befehl Codex /goal ist ein persistenter Zielmodus für Codex CLI. Sie geben ihm ein Ziel. Nach einer Antwort wird die Kontrolle nicht zurückgegeben. Es ordnet Ihren repo zu, plant, bearbeitet Dateien, führt Tests durch, wertet das Ergebnis anhand Ihrer Stoppkriterien aus und erklärt entweder das Ziel für abgeschlossen oder startet eine weitere Iteration. Der agent bleibt über viele Werkzeugaufrufe hinweg mit dem Thread verbunden. Aufgrund der Art und Weise, wie Codex den Status komprimiert und wiederverwendet, übersteht es Kontextbeschränkungen. Es protokolliert den Fortschritt. Es respektiert die Genehmigungsregeln.

Dies ist kein Chat. Es ist ein Arbeitsprozess mit einer Checkliste.

Es wurde als experimentelle Funktion ausgeliefert, was OpenAI bedeutet: „Das ist real, aber wir stellen es noch nicht auf die Homepage.“ Sie aktivieren es manuell in Ihrer Konfigurationsdatei, führen Codex in Ihrem Terminal aus und ein kleiner Satz neuer Slash-Befehle erscheint in der TUI.

Hier ist die tatsächliche Befehlsoberfläche ab Codex CLI 0.128.0:

• /goal <objective> – Legen Sie ein langfristiges Ziel fest und starten Sie die Schleife
• /goal pause – Beende den aktuellen Schritt und pausiere dann
• /goal resume – ein pausiertes Ziel fortsetzen
• /goal clear – das aktive Ziel vollständig löschen
• /goal (keine Argumente) – zeigt Fortschritt, Token-Nutzung und verstrichene Zeit an
• /side <prompt> – Öffnen Sie einen Nebenthread, um eine Frage zu stellen, ohne das Hauptziel zu beeinträchtigen; Mit der Escape-Taste zurückschalten

Der Befehl /side ist der Teil, über den niemand spricht, und er ist insgeheim die beste Funktion im Paket. Mehr dazu später.

Bevor ich nun darauf eingehe, wie man irgendetwas davon verwendet, gibt es in dem Quellvideo, das ich mir angesehen habe, etwas, das falsch ist, und Sie werden sich einen frustrierenden Nachmittag ersparen, wenn Sie es jetzt wissen.

Das einzige Konfigurationsdetail, das jeder falsch macht

Die exemplarische Vorgehensweise, der ich ursprünglich gefolgt bin, sagte mir, ich solle Ziele in config.yml aktivieren. Ich verbrachte verwirrte zwanzig Minuten damit, mich zu fragen, warum nichts passierte, bevor ich die eigentliche Codex-Dokumentation überprüfte.

Codex CLI verwendet kein YAML. Es verwendet TOML.

Die Datei heißt ~/.codex/config.toml und das Flag befindet sich unter einer [features]-Tabelle. Der minimale Aktivierungsblock sieht folgendermaßen aus:

[features]
goals = true

Sie können dies auch über die Befehlszeile tun – codex features enable goals schreibt denselben Wert in dieselbe Datei. Speichern Sie in jedem Fall die Datei, starten Sie Codex neu und die Befehle /goal und /side werden in der Schrägstrich-Befehlspalette angezeigt. Wenn dies nicht der Fall ist, haben Sie entweder die falsche Datei bearbeitet oder Sie verwenden eine Codex-Version, die älter als 0.128.0 ist. Führen Sie zur Bestätigung codex --version aus.

Sobald features.goals = true global festgelegt ist, funktioniert die Funktion sowohl in der Codex CLI- als auch in der Codex-App. Sie müssen es nur einmal im CLI aktivieren und es wird weitergegeben.

Kleines Detail. Großer Unterschied zwischen „Das funktioniert“ und „Ich verschwende eine Stunde“.

Nachdem wir das geklärt haben, reden wir über das, worauf es wirklich ankommt – nämlich den Zeitpunkt, an dem Sie überhaupt zu diesem Befehl greifen sollten, denn die Antwort lautet „viel seltener, als Sie denken.“

Die zwei Arten der Codierungsarbeit – und warum /goal für eine davon falsch ist

Hier ist das mentale Modell, bei dem ich eine Woche lang missbräuchlich gelandet bin.

Fast jede Programmierarbeit, die ich mache, fällt in eine von zwei Kategorien. Von außen sehen die Kategorien ähnlich aus. Ein leitender Ingenieur kann sie normalerweise in etwa dreißig Sekunden unterscheiden. Ein kodierender agent – und ehrlich gesagt, viele junge Ingenieure – können sie überhaupt nicht unterscheiden. Und /goal ist nur für eines davon das richtige Werkzeug.

Kategorie eins: genau definierte Arbeit. Sie kennen die Eingabe. Sie kennen die Ausgabe. Sie wissen ungefähr, wie das Diff aussieht, bevor Sie beginnen. „Integrieren Sie den Notion API, damit wir Kundenbriefings mit der Datenbank eines Projekts synchronisieren können.“ „Fügen Sie einen Stripe-Webhook-Handler hinzu, der sich in unserer vorhandenen Ereignistabelle protokolliert.“ „Migrieren Sie das Benutzermodell von E-Mail-basierten zu UUID-basierten Primärschlüsseln.“ Diese Aufgaben haben eine Form. Es gibt eine begrenzte Anzahl an Dateien, die geändert werden müssen, eine klare Definition von „erledigt“ und der Pfad ist größtenteils mechanisch, wenn man zehn Minuten lang darüber nachgedacht hat.

Für diese Art von Arbeit ist /goal übertrieben und grenzt an schädlich. Sie wollen keine selbstbewertende Schleife. Sie wollen einen sauberen PR. Sie wollen, dass der agent genau das tut, was Sie verlangt haben, die Kontrolle zurückgibt und Sie reviewen lässt. Der normale Codex-Workflow – ein Prompt, eine Antwort, normale Review – erledigt das sehr gut. Ich beschreibe diese Schleife in meiner Analyse des Codex- und Claude-Code-Zwei-Agenten-Workflows, und 90 % meiner echten Arbeit lebt weiterhin dort.

Kategorie zwei: Sondierungsarbeit. Hier ist das Ziel bekannt, der Weg jedoch nicht. „Reduzieren Sie die P95-Latenz auf diesem API um 20 %.“ „Reduzieren Sie unseren Speicherbedarf im Worker-Pool.“ „Finden und beheben Sie die Layoutverschiebung, die dazu geführt hat, dass unser Lighthouse-Score auf Mobilgeräten einen Krater verursacht.“ Sie können das gewünschte Ergebnis mit einer Metrik beschreiben. Allerdings kann man den Unterschied nicht im Voraus beschreiben. Die Lösung könnte eine Konfigurationsänderung, eine Abfrageoptimierung, ein Code-Refactoring, ein Algorithmusaustausch sein – oder eine Kombination aus allen vieren, die nach der Ausführung von Profilern nacheinander entdeckt werden.

Dafür wurde /goal entwickelt. Die Argumentationsschleife – planen, handeln, testen, bewerten, iterieren – ist genau die richtige Form für die Erkundung. Sie legen ein überprüfbares Ziel fest und lassen den agent mahlen. Es versucht etwas. Die Tests geben Aufschluss darüber, ob die Änderung die Metrik verschoben hat. Wenn ja, wird versucht, weiter voranzutreiben. Wenn nicht, macht es einen Rückzieher und versucht einen anderen Winkel.

Die Geschichte um 25 % FPS-Verbesserung, die in den Codex-Demos herumgereicht wird? Das ist Kategorie zwei. Jemand gab Codex ein Renderleistungsproblem mit einem klar messbaren Ziel und ließ es stundenlang laufen. Sie wussten nicht, welche Optimierung landen würde, bevor sie begannen. Der agent hat herausgefunden, was er ausprobieren und was er behalten sollte.

Die tiefere Einsicht hier, die ich auf die harte Tour lernen musste: Die meisten Ingenieure denken standardmäßig in der ersten Kategorie, selbst wenn sie an Problemen der zweiten Kategorie arbeiten. Sie versuchen, die Lösung zu spezifizieren, bevor sie den Suchraum verstanden haben. /goal zwingt Sie dazu, das umzudrehen – Sie müssen sich auf das Ziel festlegen, ohne sich auf die Route festzulegen. Das ist unangenehm. Hier liegt auch die Hebelwirkung.

Aber es funktioniert nur, wenn Ihr Ziel real ist. Das bringt uns zu der Disziplin, die über jeden einzelnen Torlauf entscheidet.

Die Überprüfbarkeit von Zielen ist das A und O

Beobachten Sie, was passiert, wenn Sie Codex ein vages Ziel geben.

Ich habe /goal make the search faster in einem kleinen Laravel-Nebenprojekt ausprobiert. Codex begann mit der Ausführung der vorhandenen Suche und erhielt eine Basislinie (gut). Dann wurde ein Index für die am häufigsten abgefragte Spalte hinzugefügt (gut). Anschließend wurde ein erneuter Benchmarking durchgeführt und eine Verbesserung um 14 % (gut) festgestellt. Dann ging es weiter. Es wurde das Caching der Abfrageergebnisse hinzugefügt. Dann wurde der Suchcontroller umgestaltet. Dann wurde eine Redis-Ebene hinzugefügt. Dann wurde eine Migration der Volltextsuche zu Meilisearch vorgeschlagen. Es hörte zu keinem Zeitpunkt auf, weil ich ihm zu keinem Zeitpunkt gesagt hatte, was „schnell genug“ bedeutet.

Codex fügt zu Beginn jeder Iteration eine Systemanweisung ein, die im Wesentlichen besagt: „Behandeln Sie Unsicherheit als nicht erreicht.“ Es ist eine Schutzmaßnahme gegen falsche Behauptungen über die Fertigstellung. Aber es geht in beide Richtungen. Wenn Ihr Ziel wirklich nicht überprüfbar ist – wenn es keine Metrik, keine Checkliste, keinen Test gibt, der ein sauberes Bestehen zurückgeben kann – dann behandelt der agent das Ziel als dauerhaft nicht erreicht. Es wird so lange iterieren, bis Ihnen die Token, die Geduld oder das Geld ausgehen.

Der Fix ist einfach zu beschreiben und überraschend schwer umzusetzen. Jeder von Ihnen festgelegte /goal muss zwei Dinge enthalten:

1. Ein konkretes Ziel. Entweder eine Metrik („P95 unter 250 ms“), ein bestandener Test („alle e2e-Tests in tests/checkout/ grün“) oder eine überprüfbare Checkliste („Dashboard-Seitenleiste zeigt den Filament-Admin-Link, automatisierte Tests bestehen, keine neuen Konsolenfehler im Build-Protokoll“).
2. Eine Definition von erledigt, die der agent selbst überprüfen kann. Nein „bis es gut aussieht.“ Nein „bis die Leistung akzeptabel ist.“ Der agent muss in der Lage sein, einen Befehl auszuführen, ein Ergebnis zu beobachten und allein auf der Grundlage dieser Beobachtung zu entscheiden.

Vergleichen Sie diese beiden Eingabeaufforderungen. Gleiche Absicht. Völlig anderes Verhalten:

• Schlecht: /goal speed up the dashboard
• Gut: /goal Reduce dashboard initial paint from current 2.4s baseline to under 1.0s on the staging environment. Success criteria: Lighthouse performance score above 90 on /dashboard, all existing e2e tests in tests/dashboard/ continue to pass, no new TypeScript errors in the build.

Der erste ist ein Wunsch. Der zweite ist ein Vertrag. Codex kann Verträge erfüllen. Es kann keine Wünsche erfüllen – und schlimmer noch, es wird so tun, als würde es es versuchen.

Wenn ich nicht sicher bin, wie ich den Vertrag schreiben soll, mache ich etwas, das in den Dokumenten zu OpenAI Ich beschreibe das Problem. Ich frage Codex, welche überprüfbaren Erfolgskriterien es vorschlagen würde. Ich argumentiere damit. Ich verschärfe die Kriterien. Dann, und nur dann, öffne ich einen sauberen Thread und führe /goal mit dem verfeinerten Vertrag aus. Dieser Brainstorming-Schritt erfordert vielleicht zehn Minuten Arbeit und hat mir Stunden verschwendeter Token-Ausgaben erspart.

Was Codex tatsächlich tut, sobald das Ziel beginnt

Lassen Sie mich durch die Schleife gehen, denn die Mechanik ist wichtig.

Wenn Sie /goal <objective> eingeben, macht Codex etwas, das unscheinbar aussieht, aber die Grundlage für alles Danach ist: Es kartiert das repository. Es liest Dateistrukturen, wichtige Konfigurationen und Package-Manifeste. Es skizziert ein Modell davon, was Ihr Projekt ist und wie es verdrahtet ist. Das ist nicht kostenlos – es kostet Tokens –, aber es ist der Unterschied zwischen einem agent, der plausibel aussehenden Code schreibt, und einem, der Code schreibt, der wirklich in Ihre Codebase passt. Warum dieses anfängliche Laden von Kontext zählt, erkläre ich in meinem Beitrag zu context engineering, und /goal ist einer der klarsten Ausdrücke dieses Prinzips in aktuellen AI-Tools.

Dann plant es. Codex skizziert eine Abfolge von Schritten, die seiner Meinung nach zum Ziel führen werden. Es wählt den ersten Schritt. Es läuft. Das „Ausführen“ kann alles sein – Bearbeiten von Dateien, Ausführen von Shell-Befehlen, Ausführen von Tests, Drücken eines API, Lesen von Protokollen. Dann wird ausgewertet. Hat der Schritt die Metrik verschoben? Hat es die Tests bestanden? Hat es einen Checklistenpunkt erfüllt?

Wenn ja, wird der nächste Schritt ausgewählt. Wenn nein, wird eine Variante ausprobiert oder ein Rückzieher gemacht und ein anderer Blickwinkel ausprobiert. Die Schleife geht weiter.

Sie können dies in Echtzeit beobachten und es ist wirklich hypnotisch. Es gibt einen Rhythmus. Lesen, schreiben, testen, beobachten, entscheiden. Der agent wartet nicht auf Sie. Es funktioniert einfach.

Während es funktioniert, können Sie Befehle erteilen. /goal pause beendet den aktuellen Schritt und stoppt die Schleife sauber – keine halb angewendeten Bearbeitungen, keine verwaisten Werkzeugaufrufe. /goal resume macht dort weiter, wo es aufgehört hat. /goal ohne Argumente zeigt Ihnen eine Fortschrittsübersicht, die ausgegebenen Token und die verstrichene Zeit an, ohne dass irgendetwas unterbrochen wird.

Und dann ist da noch /side.

/side <prompt> öffnet einen kurzlebigen Nebenthread, der das Hauptziel nicht stört. Die Hauptschleife läuft weiter. Sie können Codex eine Frage stellen: „Moment mal, was ist nochmal der Unterschied zwischen einem entprellten und einem gedrosselten Scroll-Handler?“ – und erhalten Sie eine Antwort in einem separaten Kontext und kehren Sie dann zum Hauptthread zurück, um den Lauf des Ziels weiter zu beobachten. Das klingt geringfügig. Das ist es nicht. Vor /side unterbrach jede Unterbrechung den Fluss von agent. Mit /side können Sie Entscheidungen auf ihre Richtigkeit überprüfen, nach nicht zusammenhängenden Informationen suchen oder sogar ein kleines klärendes Experiment starten, ohne den Kontext des Hauptziels zu verfälschen.

Diese einzelne Funktion hat mich dazu gebracht, /goal für längere Läufe zu vertrauen. Die Fähigkeit zu fragen, ohne sie zu unterbrechen, verändert die Beziehung von „Ich muss mich voll und ganz engagieren und hoffen“ zu „Ich kann beaufsichtigen, ohne zu sabotieren“.

Das Verdichtungsproblem, das niemand kommen sieht

Hier wird es technisch und der Unterschied zwischen einem produktiven und einem zum Scheitern verurteilten /goal-Lauf wird deutlich.

Langfristige agents sammeln Kontext. Jeder Tool-Aufruf, jede gelesene Datei, jedes Testergebnis – alles häuft sich im Gesprächsverlauf. Irgendwann klickt man auf das Kontextfenster des Modells und etwas muss nachgeben. Codex erledigt dies mit der Eingabeaufforderung compaction. Frühere Wendungen werden in einem engeren Briefing zusammengefasst und dann von dort aus fortgesetzt.

Verdichtung klingt einfach. Das ist es nicht.

Guter compaction bewahrt, worauf es ankommt: das Ziel, den aktuellen Stand der Arbeit, die Dinge, die funktioniert haben, die Dinge, die fehlgeschlagen sind und warum, die Einschränkungen, die Präferenzen des Benutzers. Nach einem guten compaction macht der agent dort weiter, wo er aufgehört hat, und die Arbeit fühlt sich kontinuierlich an. Schlechter compaction entfernt hart erkämpften Kontext – den spezifischen Grund, warum ein früherer Ansatz fehlgeschlagen ist, die Konfigurationsauswahl, die einen Benchmark gültig gemacht hat, den Kompromiss, den der Benutzer explizit gewählt hat. Nach einem fehlerhaften compaction versucht der agent erneut fehlgeschlagene Ansätze, stellt geklärte Fragen erneut und weicht langsam von der ursprünglichen Absicht ab.

Ich habe das bei einem echten Projekt beobachtet. Codex führte einen /goal aus, um eine Datenbankabfragepipeline zu optimieren. Etwa beim dritten compaction ging die Tatsache verloren, dass ich mich ausdrücklich gegen die Denormalisierung entschieden hatte. Es deutete erneut auf eine Denormalisierung hin. Ich habe es mitbekommen, weil ich zugeschaut habe, aber wenn ich AFK gewesen wäre, hätte der agent eine Stunde damit verbracht, einen Weg zu gehen, den ich bereits blockiert hatte.

Es gibt gute Recherchen aus der Community darüber, wie Codex compaction tatsächlich unter der Haube funktioniert – Simon Zhous Untersuchung und die umfassendere Zusammenfassung der compaction-Forschung sind beide Ihre Zeit wert, wenn Sie Details zum Maschinenraum wünschen. Die Kurzfassung: Die Qualität von compaction hängt davon ab, wie der agent-Kabelbaum zusammenfasst, was er bewahrt und was er verwirft. Codex ist darin einigermaßen gut, aber nicht perfekt, und längere Ziele betonen es mehr.

Die praktische Implikation für /goal-Benutzer ist gering, aber wichtig: Schreiben Sie Ihre Zieldefinition in der Art von Sprache, die compaction überlebt. Verwenden Sie bestimmte Nummern. Verwenden Sie benannte Dateien und Funktionen. Geben Sie Einschränkungen explizit mit „nicht“ statt mit „nicht lieber“ an. Alles, was Sie einmal sagen und davon ausgehen, dass sich der agent daran erinnert, ist gefährdet. Alles, was Sie in die Zieldefinition selbst einbacken, wird an jeder Iterationsgrenze erneut eingefügt, was bedeutet, dass es jeden compaction überlebt.

Ich schreibe jetzt meine Zieldefinitionen so, als würde ich einen Vertrag schreiben, der zu Beginn jedes Meetings vorgelesen werden muss, denn genau das geschieht.

Die Umwelt ist wichtiger als die Modellwahl

Das ist der Teil von /goal, der mich am meisten überrascht hat.

Ich ging davon aus, dass der Unterschied zwischen einem guten und einem mittelmäßigen Lauf davon abhängt, für welches Modell ich mich entschieden habe. Das war nicht der Fall. Die mit Abstand größte Variable in der /goal-Qualität ist die Umgebung, in der der agent arbeiten darf.

Ein /goal-Lauf ist nur so gut wie die Signale, die dem agent zur Verfügung stehen. Wenn das Ziel „P95-Latenz um 20 % reduzieren“ lautet und der agent keine Möglichkeit hat, die P95-Latenz zu messen, ist das Ziel in der Praxis nicht überprüfbar, egal wie sauber Sie es geschrieben haben. Der agent wird raten. Es optimiert das, was es sehen kann, hofft, dass es mit dem korreliert, was es nicht sehen kann, und führt zu Änderungen, die die tatsächliche Metrik möglicherweise verändern oder auch nicht.

Umfangreiche Umgebungen erzeugen großartige /goal-Läufe. Reich bedeutet:

• Echte Protokolle. Anwendungsprotokolle, strukturiert und abfragbar, idealerweise aus einer Staging-Umgebung, die das Produktionsverhalten widerspiegelt.
• Ein Staging- oder Testcluster. Wird verteilt, wenn das Ziel etwas mit dem Netzwerk zu tun hat. Der agent muss in der Lage sein, eine Änderung vorzunehmen, bereitzustellen und zu beobachten.
• Kosten- und Leistungskennzahlen. Live, abfragbar, mit klaren Baselines. Wenn der agent keine aktuellen Nummern abrufen kann, kann er nicht entscheiden, ob dies erledigt ist.
• Flammendiagramme und Profiler. Für Performance-Arbeiten ist dies nicht verhandelbar. Der agent wird keinen heißen Pfad finden, indem er den Quellcode allein liest.
• Vollständiger Zugriff auf die Codebasis mit der Berechtigung zum Ändern, Ausführen von Tests und Überprüfen des Git-Status. Ein /goal-Lauf, der für jeden Befehl um Erlaubnis bitten muss, verbraucht mehr Zeit für Genehmigungsaufforderungen als für den Fortschritt.

Für risikoreiche oder ressourcenintensive Ziele – alles, was die CPU stundenlang belastet, eine Datenbank belastet oder eine lange Benchmark-Suite ausführt – führe ich sie nicht auf meinem lokalen Computer aus. Ich starte ein Cloud-VPS, klone den repo dort, führe Codex in einer SSH-Sitzung aus und lasse es funktionieren. Dabei geht es nicht nur um Ressourcenkosten. Es geht darum, dass mein Laptop-Lüfter sechs Stunden lang nicht schreit, während eine Benchmark-Schleife läuft. Es geht darum, die Umgebung zu isolieren, damit „der agent etwas kaputt gemacht hat“ in Schach gehalten wird.

Wenn Sie die Ausführung von cloud-based Ich beschreibe das breitere Muster in meinem langjährigen Artikel zum agent-Kabelbaum, und /goal fügt sich so sauber in dieses Muster ein wie alles, was ich bisher gesehen habe.

Die Scrappy-Branch-Falle – und die PRD-Schleife, die das Problem behebt

Hier ist das Widersprüchlichste, was ich über /goal-Läufe gelernt habe, und es ist die Lektion, von der ich wünschte, dass sie mir jemand gegeben hätte, bevor ich angefangen habe.

Die Ausgabe eines erfolgreichen /goal-Laufs ist fast nie Code, den Sie versenden sollten.

Dieser Satz wird falsch klingen, wenn Sie ihn nicht gelebt haben. Lass es mich erklären.

Ein /goal-Lauf ist von Natur aus explorativ. Der agent sucht nach einer Lösung, die er nicht im Voraus kennt. Der Weg, den es nimmt, umfasst Sackgassen, Debug-Druckanweisungen, hartcodierte Werte, die zum Testen verwendet werden, Kommentare wie // TODO: revisit this hack und Verknüpfungen, die lokal funktionierten, aber die Codeüberprüfung nicht überstehen. Der agent ist nicht faul. Es geht darum, genau das zu tun, was Erkundungsarbeit ausmacht, wenn ein Mensch sie macht: etwas zum Laufen bringen, den Ansatz validieren und dann aufräumen. Außer /goal gehen vor der Aufräumphase normalerweise die Zeit, die Token oder Ihre Geduld aus.

Das Ergebnis ist das, was ich jetzt als „schäbigen branch“ bezeichne. Es funktioniert. Es verschiebt die Metrik. Es erfüllt die Zieldefinition. Es ist auch häufig ein absolutes Chaos.

Als ich /goal zum ersten Mal ausführte, versuchte ich, diese branches direkt zusammenzuführen. Immer ein Fehler. Zwei Wochen später würde ich Debug-Ausdrucke im Produktionscode finden. Ich würde einen Hack finden, der von einer bestimmten Datei abhängt, die nur im Arbeitsverzeichnis von agent vorhanden ist. Ich würde Ansätze finden, die das unmittelbare Ziel lösen, aber subtile technische Schulden mit sich bringen.

Der Fix ist ein Workflow, kein Konfigurationsflag. Sobald ein /goal-Lauf erfolgreich abgeschlossen wurde, betrachte ich das Ergebnis als Proof of Concept und nicht als Ergebnis. Ich habe mir das Diff sorgfältig durchgelesen. Ich extrahiere die Einsicht – die tatsächliche Technik, die das Problem gelöst hat. Dann schreibe ich einen kurzen PRD, in dem ich beschreibe, was ich gelernt habe: den Ansatz, die Kompromisse, die Einschränkungen, die Teile, die funktioniert haben, und die Teile, die bereinigt werden müssen.

Dann werfe ich den schäbigen branch weg.

Ich eröffne einen neuen Thread, gebe Codex den PRD als saubere Spezifikation und führe eine normale Aufgabe aus – Arbeit der Kategorie eins, nach meiner früheren Definition –, um die gleichen Erkenntnisse gegen eine saubere Codebasis zu implementieren. Das Ergebnis ist dramatisch besser. Keine Debug-Drucke. Keine Hacks. Kein angesammeltes Narbengewebe aus der Explorationsphase. Nur eine saubere Umsetzung eines Ansatzes, der sich inzwischen bewährt hat.

Dieses Zwei-Phasen-Muster – Erkundung über /goal, dann Implementierung über den normalen Workflow – ist das AI-Codierungsmuster mit der höchsten Hebelwirkung, das ich dieses Jahr gefunden habe. Es spiegelt wider, wie gute menschliche Ingenieure tatsächlich an schwierigen Problemen arbeiten. Sie erkunden. Du lernst. Du wirfst den Dorn weg. Sie bauen das Original.

Einige Ingenieure in der Ralph-loop-Community haben in ähnlicher Weise über PRD-gesteuertes autonomous coding geschrieben, und die Konvergenz ist kein Zufall. Das Muster funktioniert, weil es zwei Arten von Erkenntnissen trennt, die der agent nicht gleichzeitig ausführen sollte: herausfinden, was erstellt werden soll, und es gut erstellen.

Mein Entscheidungsrahmen für /goal im Vergleich zum normalen Workflow

Nach zwei Wochen des Testens ist hier der Entscheidungsbaum, den ich jetzt verwende, bevor ich nach /goal greife:

Frage 1: Können Sie den Unterschied beschreiben, bevor Sie beginnen?

• Wenn ja → Standard-Workflow. Schreiben Sie eine gezielte Aufforderung, erhalten Sie eine gezielte Antwort und überprüfen Sie den PR. /goal fügt hier nichts hinzu.
• Wenn nein → weiter zu Frage 2.

Frage 2: Können Sie das Ziel als überprüfbares, messbares Ergebnis beschreiben?

• Wenn ja → /goal liegt auf dem Tisch. Weitermachen.
• Wenn nein → Sie sind nicht bereit. Brainstormen Sie das Ziel im normalen Modus, bis Sie einen sauberen Vertrag schreiben können.

Frage 3: Hat der agent Zugriff auf die Signale, die er überprüfen muss?

• Wenn ja → ist /goal das richtige Werkzeug. Führen Sie es aus.
• Wenn nein → zuerst die Umgebung reparieren. Fügen Sie Metriken hinzu. Fügen Sie einen Staging-Cluster hinzu. Fügen Sie echte Protokolle hinzu. Dann noch einmal bewerten.

Frage 4: Behandeln Sie die Ausgabe nach Abschluss des Laufs als Lieferergebnis oder als Spitze?

• Behandeln Sie es wie eine Spitze. Stets. Destillieren Sie die Einsicht in einen PRD. Führen Sie einen sauberen Implementierungsdurchlauf anhand der verfeinerten Spezifikation durch. Versenden Sie das.

Das ist es. Das ist der Rahmen. Es hat mir echtes Geld in Form von Tokens und echte Stunden bei der Aufräumarbeit gespart, und es ist die Linse, durch die ich jetzt jede /goal-Demo auf Twitter lese.

Wenn Ihnen jemand mitteilt, dass sein /goal-Lauf den Code direkt an den Hauptserver gesendet hat, würde ich sehr höflich fragen, wie seine Fehlerrate in zwei Wochen aussieht. Weil ich dort war. Der erste Lauf ist berauschend. Beim Aufräumen lebt die Lektion.

Wohin das meiner Meinung nach als nächstes kommt

/goal ist experimentell. Es wird sich schnell weiterentwickeln. Ein paar Dinge, die ich mir ansehe:

Die Grenze zwischen /goal-Exploration und strukturierter Aufgabenausführung wird verschwimmen. Das oben beschriebene PRD-Schleifenmuster wird wahrscheinlich in das Tool selbst integriert – destillieren, umgestalten, implementieren – und nicht als darüber hinausgehender manueller Workflow weiterleben. Sobald das passiert, bricht die Kluft zwischen „Ich hatte eine Idee“ und „Ich habe einen sauberen PR“ dramatisch zusammen.

Das Umweltproblem wird durch bessere Standardeinstellungen gelöst. Im Moment ist es eine einrichtungsintensive Aufgabe, einen /goal mit genügend Signalen zum Laufen zu bringen, um seine eigene Arbeit zu überprüfen. Die meisten Projekte haben es nicht. Die nächste Welle von agent-Tools wird mit verwalteten Staging-Umgebungen, integrierter Observability und Zielvorlagen für gängige Optimierungsziele ausgeliefert. Wir sind noch nicht da. Wir werden es bald sein.

Die Qualitätsunterschiede zwischen AI Codierungstools werden zu einem wichtigen Auswahlfaktor. Derzeit wählen die meisten Ingenieure basierend auf dem Modell eine Codierung agent aus. In einem Jahr werden sie ihre Auswahl danach treffen, wie das Geschirr den Kontext über stundenlange autonome Läufe hinweg verwaltet. Codex, Claude Code, Anthropic verwaltet agents – das Modell ist nicht der Graben. Das Geschirr ist.

Wenn Sie diesen Bereich weiter verfolgen möchten, schreibe ich jede Woche über neue AI-Codierungstools, und in der Codex/Claude Code-Berichterstattung landen die meisten praktischen Lektionen.

Häufig gestellte Fragen

Wie aktiviere ich den Befehl Codex /goal?

Fügen Sie [features] gefolgt von goals = true zu Ihrer ~/.codex/config.toml-Datei hinzu, speichern Sie und starten Sie Codex CLI neu. Alternativ können Sie codex features enable goals ausführen, wodurch derselbe Wert automatisch geschrieben wird. Überprüfen Sie dies, indem Sie codex --version ausführen und bestätigen, dass Sie Version 0.128.0 oder höher verwenden. /goal und /side werden nach der Aktivierung in der Slash-Befehlspalette angezeigt.

Kann der Befehl Codex /goal sicher unbeaufsichtigt ausgeführt werden?

Es ist sicherer als das Ausführen einer beliebigen Ralph-Schleife, aber ich würde es nicht völlig unbeaufsichtigt auf produktionsnahem Code laufen lassen. Verwenden Sie einen Cloud-VPS oder eine isolierte Umgebung, legen Sie ein Token-Budget fest und prüfen Sie den resultierenden branch sorgfältig. Behandeln Sie die Ausgabe als einen Spitzenwert und nicht als Ergebnis – siehe den schäbigen Abschnitt branch oben.

Wann sollte ich /goal im Vergleich zu einer normalen Codex-Eingabeaufforderung verwenden?

Verwenden Sie /goal nur für Erkundungsarbeiten, bei denen Sie das Ziel, aber nicht die Route kennen – Leistungsoptimierungen, Latenzreduzierungen, Untersuchungen zur Fehlersuche. Verwenden Sie für jede Aufgabe normale Eingabeaufforderungen, bei denen Sie den Unterschied beschreiben können, bevor Sie beginnen. Die meisten echten Programmierarbeiten fallen in die zweite Kategorie.

Was ist der Unterschied zwischen /goal und /side in Codex CLI?

/goal legt ein dauerhaftes Ziel fest und startet eine lang andauernde autonome Schleife. /side eröffnet eine vorübergehende Nebenkonversation, die ein aktives Ziel nicht stört – Sie können Fragen stellen, Informationen nachschlagen oder kleine Experimente durchführen, während das Hauptziel weiterläuft. Wechseln Sie mit der Escape-Taste zurück zum Hauptthread.

Warum wird mein /goal-Lauf nie beendet?

Fast immer, weil das Ziel nicht überprüfbar ist. Codex fügt „Unsicherheit als nicht erreicht behandeln“ in jede Iteration ein, sodass ein vages Ziel wie „es schneller machen“ auf unbestimmte Zeit wiederholt wird. Schreiben Sie das Ziel als konkreten Vertrag um – spezifische Metrik, benannte Tests, explizite Checkliste – und die Schleife endet korrekt, wenn die Kriterien erfüllt sind.

Lasst uns zusammenarbeiten

Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.

• Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Unternehmenslösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io