For/Goal getestet: Claude Code vs Codex bauten meine App in 32 Min.

For/Goal getestet: Claude Code vs Codex bauten meine App in 32 Min.

Ich habe den Timer an einem Mittwoch um 14:47 Uhr gestartet. Um 15:19 Uhr hatten zwei Terminalfenster auf meinem linken Monitor jeweils das Gerüst einer funktionierenden Next.js-Anwendung fertiggestellt – Onboarding-Ablauf, Dashboard, Landingpage, Authentifizierungsbildschirme, die gesamte Form eines echten Produkts. Zweiundsechzig Roadmap-Aufgaben. Beide Apps. Jeweils zweiunddreißig Minuten. Ich hatte meinen Kaffee nachgefüllt.

Dies ist der Teil, in dem die Demo-Leute auf Twitter normalerweise einen 30-sekündigen Zeitraffer ausschneiden und Schluss machen. Ich möchte Ihnen die tatsächlichen Nähte zeigen. Weil die for/goal-Funktion – die lang andauernde autonome Schleife, die in Claude Code 2.1.139 gelandet ist und in Codex CLI 0.128.0 ausgeliefert wird – nur wie Magie aussieht. Darunter verbirgt sich ein ganz bestimmtes Rezept, und dieses Rezept ist der Unterschied zwischen einem Agenten, der eine echte App in einer halben Stunde ausliefert, und einem Agenten, der sich ewig wiederholt und dieselbe kaputte Funktion neu schreibt, bis Sie den Prozess aus Mitleid abbrechen.

Ich habe for/goal fast jeden Tag ausgeführt, seit die Funktion eingestellt wurde. Zwei parallele Projekte. Gleiche Produktspezifikation. Dieselbe Sechs-Phasen-Roadmap. Ein Lauf in Claude Code, einer in Codex. Beide fertig. Beide haben etwas produziert, das ich morgen einem Kunden vorführen könnte. Sie haben auch sehr unterschiedliche Apps mit derselben Eingabeaufforderung erstellt, und die Unterschiede sagen Ihnen genau, zu welchem ​​Agenten Sie wann greifen müssen.

Das ist die Aufschlüsselung, die ich mir gewünscht hätte, bevor ich angefangen habe.

Was For/Goal eigentlich ist – und warum es nicht nur ein weiterer Slash-Befehl ist

Lassen Sie mich zunächst die Marketingsprache klären.

For/goal ist ein persistenter Zielmodus. Man legt einmal ein Ziel fest, der Agent arbeitet es über viele Runden hinweg ab – mal Stunden, mal einen ganzen Tag – und ein zweites, kleineres Modell prüft nach jeder Runde, ob das Ziel tatsächlich erreicht wird. Wenn der Validator „Nein“ sagt, erhält das Hauptmodell dieses „Nein“ plus eine Begründung aus einem Satz und arbeitet weiter. Wenn der Prüfer „Ja“ sagt, endet die Schleife und Ihr Terminal gibt die Kontrolle zurück. Das ist die ganze Form davon.

In Claude Code lautet der Befehl buchstäblich /goal. Es wurde in der Version 2.1.139 ausgeliefert, die Anfang Mai 2026 veröffentlicht wurde. Der Validator läuft auf dem Modell, das Sie als Ihr kleines, schnelles Modell konfiguriert haben – standardmäßig Haiku – und die Token-Kosten des Validators werden separat vom Budget für die Hauptrunde abgerechnet, was wichtig ist, wenn Sie sechs Stunden lang ein Ziel verfolgen.

In Codex CLI ist die Befehlsoberfläche die gleiche Idee. Codex ruft das Schleifenprimitiv for/goal auf, und die Schrägstrichbefehle in Version 0.128.0 sind /goal, /goal pause, /goal resume, Gleiche Architektur: Das Hauptmodell erledigt die Arbeit, das kleine Modell beurteilt die Fertigstellung.

Dies ist mechanisch gesehen eine Weiterentwicklung des Ralph-Loop-Musters – des Bash-Einzeilers, den Ingenieure wie Adam Tuttle und das Snarktank-Repo in den letzten zwölf Monaten in eine Methodik verwandelt haben. Ralph war ein while true-Wrapper um Ihren Codierungsagenten, mit einem Verifizierungsbefehl am anderen Ende der Pipe. For/goal übernimmt diese Idee und integriert sie in den Agenten selbst, mit einer echten Supervisor-Architektur und einem zustandsbewussten Stopp-Hook.

Hier ist der Teil, für dessen Verinnerlichung ich drei Durchgänge brauchte: Das ist kein Chat mehr. Es ist ein Arbeitsprozess mit einer Checkliste. Du redest nicht mit ihm. Sie legen das Ziel fest und überprüfen, ob das Ziel erreichbar ist. Der Agent erledigt den Rest.

Was einfach klingt. Das ist nicht der Fall, und ich zeige Ihnen, warum.

Das Setup: Ein PRD, zwei Agenten, zweiundsechzig Aufgaben

Bei der Test-App handelte es sich um ein Tool zur Inhaltsüberprüfung – eine Mischung aus einem Arbeitsbereich im Notion-Stil und einer Videoanmerkungswarteschlange. Nichts Weltbewegendes. Ich habe es ausgewählt, weil der Umfang groß genug war, um interessant zu sein (es brauchte Authentifizierung, ein Arbeitsbereichskonzept, eine Überprüfungswarteschlange, einen Onboarding-Ablauf und eine Einstellungsseite), aber klein genug, dass ich jede vom Agenten erstellte Datei lesen und Ihnen sagen konnte, was tatsächlich vorhanden war.

Die Spezifikation umfasste fünf Dateien im Projektstamm, bevor ich etwas anderes berührte:

• prd.md – das Produktanforderungsdokument. Ungefähr 1.400 Wörter. Zielgruppe, Problem, die drei Kernaufgaben, die die App erfüllen musste, das Datenmodell in einfachem Englisch und eine Liste von Elementen, die außerhalb des Geltungsbereichs liegen, damit der Agent nicht in Funktionen abdriftet, die ich nicht wollte. - productroadmap.mmd – eine Mermaid-Roadmap mit sechs Phasen und zweiundsechzig Blattaufgaben. Phase 1 war Gerüstbau und Authentifizierung, Phase 2 war das Arbeitsbereichskonzept, Phase 3 war die Überprüfungswarteschlange und so weiter bis Phase 6, in der es um Feinschliff und Onboarding ging. - design.md – Front-End-Richtung. Farbpalette, Typografiestapel, Einstellungen für die Layoutdichte („dichte Tabellenansichten über Kartenraster für Warteschlangenseiten“) und eine Liste der Komponenten, die ich erwartet hatte (Datentabellen, Schiebefelder, Befehlspalette). - claude.md – Claude Codes Regeldatei auf Projektebene.

Stack angeheftet an Next.js 15 App Router, TypeScript strict, Tailwind v4, shadcn/ui, kein Redux, keine Styled-Components, Serveraktionen für Mutationen. - agents.md – Die entsprechende Regeldatei von Codex mit denselben Einschränkungen, geschrieben im bevorzugten Format von Codex.

Das Ziel, das ich jedem Agenten gab, war Wort für Wort identisch:

Erstellen Sie die in prd.md beschriebene vollständige App und folgen Sie dabei den Aufgaben in productroadmap.mmd, bis alle Aufgaben abgeschlossen und überprüft sind. Verwenden Sie design.md für die Front-End-Designrichtung. Neuer Next.js-App-Build. Mit aktivierter automatischer Genehmigung ausführen. Fahren Sie fort, bis der Validator bestätigt, dass jede Roadmap-Aufgabe überprüft wurde und die App erstellt und sauber ist.

Dieser Zielsatz macht eine Menge Arbeit. Lassen Sie mich herausfinden, was es dafür sorgt, dass es einen 30-minütigen autonomen Lauf übersteht, denn ich habe drei frühere Versuche mit schwächeren Phrasen verbrannt, bevor ich hier ankam.

Der Ausdruck „bis alle Aufgaben abgeschlossen und überprüft sind“ ist die Stoppbedingung. Es weist den Validator auf eine konkrete zu überprüfende Sache hin – die Roadmap-Datei –, anstatt ihn zu bitten, die Qualität zu bewerten, was eine Aufgabe ist, die kleine Modelle furchtbar erledigen. „Fresh Next.js App Build“ ist die Obergrenze des Umfangs. Dem Agenten wird gesagt: „Versuchen Sie nicht, etwas zu integrieren, was bereits in diesem Verzeichnis vorhanden ist. Der gesamte Baum gehört Ihnen.“ Und „Mit aktivierter automatischer Genehmigung ausführen“ ist die Berechtigungserteilung – ohne sie stoppt insbesondere Claude Code alle vierzig Sekunden und fragt, ob ein Paket installiert werden kann.

In einigen Abschnitten werden Sie sehen, was passiert, wenn eine dieser Klauseln fehlt. Bleiben Sie dran für den Abschnitt über Fehler in der zweiten Halbzeit.

So schreiben Sie ein For/Goal-Ziel, das tatsächlich abgeschlossen wird

Dies ist der Teil, den ich langsamer angehen möchte, da der Unterschied zwischen einem Ziellauf, der abgeschlossen wird, und einem Ziellauf, der sich für immer wiederholt, fast immer im Zielsatz selbst liegt.

Ein funktionierendes for/goal-Ziel besteht aus vier Teilen in dieser Reihenfolge:

1. Was erreicht werden soll. Ein messbarer Endzustand. Nicht „mache es schön“. Nicht „den UX verbessern.“ Etwas, das der Prüfer lesen und mit Ja oder Nein beantworten kann, ohne ein Urteil zu fällen. „Alle zweiundsechzig Roadmap-Aufgaben sind in der Datei als abgeschlossen markiert.“ „Produktionsaufbau läuft.“ „Alle Playwright-Tests grün.“

2. Was zu ändern ist. Geltungsbereich. Welche Dateien, welche Verzeichnisse, welche Oberflächen der Agent berühren darf. Wenn Sie dies überspringen, werden autonome Agenten auf dem Weg zum Ziel benachbarten Code umgestalten, und Sie erhalten ein 30-seitiges Diff mit neun Dateien, die Sie nie berühren wollten.

3. Was validiert werden soll. Der eigentliche Befehl oder das Signal, nach dem der Validator suchen soll. „pnpm build verlässt Null.“ „Die Roadmap-Datei enthält keine ungeprüften Elemente.“ Dies wird dem kleinen, schnellen Modell nach jeder Runde zugeführt.

4. Wann angehalten werden soll. Die Exit-Bedingung. Normalerweise dasselbe wie das Validierungssignal, aber manchmal braucht man Gürtel und Hosenträger – „Stopp, wenn der Validator bestätigt UND die Integrationstests mindestens einmal ausgeführt wurden.“

Ein Ziel, das größer ist als eine einzelne Eingabeaufforderung, aber kleiner als ein unbefristeter Rückstand. Das ist der Sweetspot der Größe. „Diese Funktion umgestalten“ ist zu klein – fordern Sie es einfach auf. „SaaS erstellen“ ist zu groß – der Agent hat keine Ahnung, was „erledigt“ bedeutet, und wird in die Irre führen. „Erstellen Sie die in prd.md beschriebene App, bis jede Aufgabe in

Randbemerkung: Ich habe es an einem Wochenendmorgen getestet, der fast ausschließlich von Espresso und Sturheit angetrieben wurde. An einem Montag mit besserem Schlaf wären die Ergebnisse möglicherweise anders ausgefallen. Aber ich bezweifle es. Die Zielsetzungsdisziplin ist wichtiger als das Modell, auf das Sie sie verweisen, und das ist die unerwartete Lektion der letzten zwei Monate.

Führen Sie einen aus: Claude Code auf /goal

Ich habe zuerst /goal in Claude Code gedrückt. Den Torsatz eingefügt. Beobachtet.

Die erste Runde war eine Planungsrunde. Claude Code liest prd.md, liest productroadmap.mmd, liest Persistenz. Verfügen Sie über Anmeldeinformationen oder sollte ich mit Scheindaten und Stub-Clients erstellen, damit die App offline läuft?“

Diese einzelne Frage ist der ranghöchste Ingenieursmoment, den ich je gesehen habe, als ein Agent in freier Wildbahn produzierte. Es stellte fest, dass die App ohne externe Anmeldedaten nicht fertiggestellt werden konnte, erkannte, dass ich keine bereitgestellt hatte, und schlug einen Fallback vor, der es ermöglichen würde, etwas Lauffähiges zu liefern, anstatt abzuwürgen. Ich sagte ihm, es solle offline mit Mocks und einer klar markierten TODO-Liste von Integrationspunkten bauen, und es ging weiter.

Von da an lief es neunundzwanzig Minuten lang ohne weitere Frage.

Das Muster war immer das gleiche: Wählen Sie die nächste ungeprüfte Roadmap-Aufgabe aus, lesen Sie die relevanten Dateien, schreiben oder ändern Sie den Code, führen Sie eine gezielte Validierung durch (pnpm tsc --noEmit für Typänderungen, Der Prüfer antwortete nach jeder Runde außer der letzten mit „Nein“. Das „Nein“ kam mit einem einzeiligen Grund zurück – „Phase 3 Aufgabe 4 noch nicht geprüft“ oder „Build wurde zuletzt vor zwanzig Minuten bestanden, überprüfen Sie, ob er nach den neuen Komponenten immer noch erfolgreich ist“ – und die nächste Runde begann mit diesem Grund als erster Eingabe.

In der neunundzwanzigsten Minute sagte der Prüfer „Ja“. Claude Code wurde angehalten, zusammengefasst, was es erstellt hat, und die TODO-Integrationspunkte aufgelistet, die es blockiert hatte. Ich habe das Repo überprüft. Zweiundsechzig Aufgaben wurden abgehakt. Build bestanden. Fusselfrei.

Dann habe ich die eigentliche App gelesen.

Die Zielseite war voller Texte. Echte Überschriftenhierarchie. Ein Testimonials-Block mit drei zitierten Personas, die der im PRD beschriebenen Zielgruppe entsprachen. Eine Preistabelle mit drei Ebenen, die jeweils an einer zu erledigenden Aufgabe aus der Spezifikation verankert sind. Das Dashboard war textlastig, aber klar strukturiert – eine Seitenleiste mit dem Arbeitsbereich-Umschalter, eine obere Leiste mit dem Befehlspaletten-Auslöser und ein Hauptfenster, das standardmäßig die Überprüfungswarteschlange anzeigte. Die Überprüfungswarteschlange selbst war eine dichte Tabelle mit sortierbaren Spalten, genau das, wonach design.md gefragt hatte. Es gab einen Onboarding-Ablauf mit drei Schritten und einer sauberen Mikrokopie.

Die Authentifizierung wurde verspottet. Die Anmeldung wurde nach einer vorgetäuschten Verzögerung zum Dashboard umgeleitet. Die Sitzung wurde in einem Cookie mit einem TODO-Kommentar gespeichert, der auf den Supabase-Integrationspunkt verweist. Über die Checkout-Schaltfläche von Stripe wurde ein Modal geöffnet, in dem erklärt wurde, was passieren würde, wenn die Integration verkabelt würde. Jede externe Integration war eine klar markierte Naht, kein gebrochener Anruf.

Dies war die Version, die ich einem Kunden schickte, um ihm zu zeigen, wie seine Idee aussieht. Es würde den Kontakt mit einem zahlenden Benutzer nicht überleben – allein die Authentifizierung ist ein Sicherheitsvorfall, der nur darauf wartet, passiert –, aber es würde den Kontakt mit einem Demo-Meeting am Dienstag auf jeden Fall überleben.

Insgesamt verstrichen: 32 Minuten, 14 Sekunden. Zwei Haiku-Validator-Durchläufe kosteten mich 47 Cent. Die Ausgaben für Hauptagenten-Token beliefen sich laut Kostenrechner auf 11,20 US-Dollar für Sonnet 4.6.

Führen Sie Zwei aus: Codex CLI auf /goal

Ich habe das Verzeichnis geleert, die Spezifikationsdateien wiederhergestellt und /goal in Codex gedrückt.

Codex hat die Env-Vars-Frage nicht gestellt. Es hat gerade erst begonnen.

Dies ist der erste Punkt, an dem die beiden Agenten auf eine wichtige Weise voneinander abweichen. Codex ging davon aus, dass es über eine Lizenz verfügte, überall dort mit Mocks zu bauen, wo externe Creds fehlten. Was ich ihm am Ende sowieso gesagt hätte. Aber das Verhalten von Claude Code, das zur Bestätigung pausiert, ist für Produktionsarbeiten die bessere Standardeinstellung. Das Verhalten von Codex, einfach zu entscheiden, ist der schnellere Weg, wenn die Spezifikation eindeutig ist, und das ist meistens der Fall.

Das Codex-Ausführungsmuster war auf der Schleifenebene fast identisch mit dem von Claude Code – planen, handeln, validieren, wiederholen –, aber die Art und Weise, wie die Arbeit sequenziert wurde, war anders. Claude Code ging Phase für Phase vor und schloss Phase 1 vollständig ab, bevor Phase 2 berührt wurde Codex zerlegt die Arbeit lieber. Zuerst wird die Silhouette des fertigen Produkts erstellt und dann geformt.

Minute einunddreißig, der Münzprüfer sagte ja. Ich habe die App gelesen.

Optisch war die Codex-App die hübschere. Sauberere Typografie (es hat Geist dem Inter vorgezogen, das Claude Code standardmäßig verwendet hat, was mit der Front-End-Design-Konversation übereinstimmt, die ich bei den meisten erfahrenen Produktdesignern im Jahr 2026 zu beobachten beginne). Die Zielseite enthielt echte Produktbilder – Codex zog Platzhalterbilder aus einer sauberen Unsplash-Sammlung, anstatt Image-Komponenten mit fehlerhaften SRC-Attributen zu löschen, wie es Claude Code einmal in einem früheren Test tat. Die Registerkarten waren sauberer, die Symbole abgerundet und das Farbakzentsystem übernahm auf jeder Seite konsistent rote Akzente aus der Designdatei.

Funktionell hat Codex einige Dinge getan, die Claude Code nicht getan hat. Die Überprüfungswarteschlange verfügte über eine Inline-Bearbeitung – Sie konnten auf ein Statusfeld klicken und es ändern, ohne die Seite zu verlassen. Das Filtersystem in der Warteschlange verfügte über drei funktionierende Filter sowie ein Dropdown-Menü für die gespeicherte Ansicht. Die Einstellungsseite verfügte über eine Tooltip-Ebene, die jedes Feld erläuterte. Es gab einen Demo-Arbeitsbereich, der vorab mit gefälschten Inhalten gefüllt war, sodass im leeren Zustand jeder Seite etwas anstelle eines Platzhalters „Füge deinen ersten Artikel hinzu“ angezeigt wurde.

Die Verluste, weil es immer Verluste gibt: Zwei Symbole waren kaputt – Codex verwies auf lucide-react-Symbolnamen, die in der aktuellen Version nicht existieren, und ich musste sie manuell austauschen. Der Authentifizierungs-Fallback war clever, aber fragil – der Mock-Client hatte eine 50-prozentige Chance, den Demo-Benutzer bei der Sitzungsprüfung zurückzugeben, was meiner Meinung nach ein Artefakt der Art und Weise war, wie Codex den Stub geschrieben hat, und kein bewusstes Design. Der Text der Landingpage war im Vergleich zu dem von Claude Code spärlich – Codex legte Wert auf visuellen Feinschliff und ließ den Worten freien Lauf.

Insgesamt verstrichen: 32 Minuten, 42 Sekunden. Ungefähr die gleichen Token-Ausgaben. Ungefähr die gleiche Aufgabenerledigungsrate.

Zwei Agenten. Gleiche Spezifikation. Gleiche Schleifenarchitektur. Verschiedene Produkte.

Das Nebeneinander: Wofür jeder Agent optimiert wurde

Hier ist der Vergleich, den ich mir gewünscht hätte, bevor ich mit diesem Experiment begonnen habe.

1,20 Haupt- + 0,47-Dollar-Validator | Ungefähr gleichwertig |

Wenn Sie nach der Überschrift suchen: Claude Code hat eine bessere Produktgeschichte geschrieben, Codex hat eine bessere Produkthülle geschrieben. Die App von Claude Code würde auf einer Landingpage besser konvertieren; Die App von Codex würde sich in einer Produktdemo besser anfühlen. Welches für Sie wichtig ist, hängt ganz davon ab, was Sie versenden.

Für meinen eigenen Workflow habe ich begonnen, nach Claude Code für for/goal-Läufe zu greifen, bei denen die Ausgabe kommunizieren muss – Zielseiten, Marketingseiten, alles, was so gelesen werden muss, wie eine Person es geschrieben hat. Ich greife nach Codex auf for/goal-Läufen, bei denen sich die Ausgabe verhalten muss – Dashboards, Tools, interne Apps mit viel Interaktionsfläche. Diese Heuristik hat sich seitdem über etwa ein Dutzend Durchläufe bewährt.

Was das für die Art und Weise bedeutet, wie ich baue

Lassen Sie mich herauszoomen, da die Implikation hier größer ist als die Auswahl des Agenten.

Seit etwa achtzehn Monaten ist das vorherrschende Muster in der AI-unterstützten Entwicklung die Call-and-Response-Schleife. Sie prompten, der Agent erledigt eine Sache, Sie prüfen, Sie prompten erneut. Selbst die besten Workflows, die ich gebaut habe - und über die meisten davon habe ich geschrieben, darunter der Claude Code und Codex Zwei-Agenten-Workflow und der Claudeex Planning Loop - waren Varianten von Call-and-Response mit einem zweiten Paar Augen.

For/goal durchbricht dieses Muster. Der Agent bittet nicht um Erlaubnis. Der Agent verfügt über ein Ziel, ein Budget und einen Validator, und Ihre Aufgabe vor dem Lauf besteht darin, das Ziel klar genug zu schreiben, damit der Validator erkennen kann, wann es erreicht wurde. Ihre Aufgabe während des Laufs ist es, woanders zu sein. Ihre Aufgabe nach dem Lauf besteht darin, die Ausgabe zu lesen und zu entscheiden, was gut ist.

Das ist ein anderer Muskel. Es handelt sich dabei eher um das Verfassen eines Briefings für einen Auftragnehmer als um die Paarprogrammierung. Die Fähigkeit liegt in der Spezifikation, nicht in der Eingabeaufforderung. Wenn Ihr PRD scharf, Ihre Roadmap granular und Ihr Designdokument konkret ist, macht Sie for/goal auf eine Weise schnell, wie es die vorherige Generation von Codierungsagenten nicht konnte. Wenn einer dieser drei Punkte vage ist, erzeugt for/goal einen wunderbar abgeschlossenen Lauf, der das falsche Produkt versendet.

Der Grund, warum dies wichtig ist: Zum ersten Mal ist der Engpass beim AI-unterstützten Bauen nicht das Modell. Es ist die Vorbereitungsarbeit. Und in die Vorbereitungsarbeit investieren die meisten Ingenieure – mich selbst eingeschlossen – zu wenig, weil es sich nicht wie Bauen anfühlt. Der Wandel for/goal besteht darin, dass die Vorbereitungsarbeit zum Gebäude wird. Der Code ist der Spezifikation nachgelagert, und in der Spezifikation lebt jetzt das technische Urteil.

Ich hätte Ihnen vor sechs Monaten gesagt, dass die Zukunft des Codierens in der Orchestrierung mit mehreren Agenten liegt – Claude Code im Gespräch mit Codex im Gespräch mit Gemini, mit Übergaben, Überprüfungsschleifen und Konsensentscheidungen. Ich denke immer noch, dass das ein Teil davon ist. Aber for/goal hat mir klar gemacht, dass es eine einfachere Zukunft gibt, die parallel läuft: ein genau spezifiziertes Ziel, ein fähiger Agent, eine überprüfbare Stoppbedingung. Keine Orchestrierung. Keine Übergaben. Nur ein Ziel und eine Schleife.

Es ist weniger interessant, über diese Zukunft Gedankenartikel zu schreiben. Es ist interessanter, das Produkt einzusenden.

Die Fehler, die ich gemacht habe (und die du machen wirst)

Drei Fehler aus meinen ersten zehn for/goal-Läufen, falls Sie die Nachhilfe überspringen möchten.

**Fehler eins: Ich habe für Der Agent lief zwei Stunden lang, erstellte sechs verschiedene Versionen einer Einstellungsseite und stoppte nie, weil es kein konkretes Signal gab, das der Validator prüfen konnte. Die Lösung: Richten Sie den Validator immer auf eine Datei oder einen Befehl, niemals auf ein Gefühl.

Fehler zwei: Ich habe vergessen, die automatische Genehmigung zu aktivieren. Ohne sie wird insbesondere Claude Code eine Pause einlegen und bei jeder Paketinstallation, jedem Dateilöschen und jedem Shell-Befehl außerhalb einer kleinen Whitelist um Erlaubnis bitten. Bei einem Lauf mit 62 Aufgaben bedeutet dies, dass der Agent etwa vierzig Mal anhält, um nachzufragen, was den ganzen Sinn der langfristigen Autonomie hinfällig macht. Aktivieren Sie es explizit in Ihrem Zielsatz – „Mit aktivierter automatischer Genehmigung ausführen“ – oder legen Sie es in Ihrer Konfiguration fest, bevor Sie beginnen.

Fehler drei: Ich habe den Agenten die Spezifikation während des Laufs erfinden lassen. Ich gab ihm eine einseitige Zusammenfassung und sagte: „Finde den Rest heraus.“ Es hat es herausgefunden. Der Rest war nicht das, was ich wollte. For/goal ist kein Ersatz für das Durchdenken dessen, was Sie bauen. Es ist ein Ersatz für das Eintippen dessen, was Sie bereits durchdacht haben. Das sind unterschiedliche Fähigkeiten. Der erste lebt noch bei dir.

Es gibt eine tiefere Version von Fehler drei, über den niemand schreibt: Langzeitagenten sind sehr gut darin, jede Spezifikation bis zum Ende richtig aussehen zu lassen. Das Endprodukt wird poliert aussehen, seinen eigenen Validator bestehen, scheinbar jede Aufgabe erfüllen – und genau so gut sein wie die Spezifikation, mit der Sie begonnen haben, nicht besser. Wenn die Spezifikation dünn war, handelt es sich bei dem polierten Produkt um ein dünnes Produkt, das ein sauberes Hemd trägt. Der Agent wird schwaches Produktdenken nicht zurückdrängen. Das liegt immer noch an dir.

Dies ist der Teil von for/goal, der am gewöhnungsbedürftigsten ist, insbesondere für Ingenieure, die das Erstellen durch Iteration mit einem Teamkollegen gelernt haben. Der Teamkollege ist jetzt der Validator, und der Validator liest eine Roadmap-Datei, nicht Ihr Roadmap-Denken. Wenn die Roadmap falsch ist, wird die Schleife zuverlässig das Falsche erstellen. Die Arbeit, die früher bei der Implementierung anfiel, muss jetzt erledigt werden, bevor Sie beim Ziel die Eingabetaste drücken. Dieser mentale Wandel ist die einzige Fähigkeit, die die Ingenieure, die zweiwöchige Features an einem Nachmittag erledigen, von den Ingenieuren unterscheidet, die zweiwöchige Features in acht Stunden frustrierender Schleifen erledigen.

Ich bin immer noch dabei, mich anzupassen. Die Disziplin, eine Roadmap zu schreiben, die ein Agent gewissenhaft ausführen kann, unterscheidet sich grundlegend von der Disziplin, eine Roadmap zu schreiben, die Sie ausführen können, weil Sie und der Agent auf unterschiedliche Weise scheitern. Du lässt dich treiben. Der Agent nicht. Sie kompensieren Unklarheiten, indem Sie im Augenblick urteilen. Der Agent gleicht Unklarheiten aus, indem er oft falsche Details erfindet. Die Roadmap muss also enger sein als die, die Sie selbst schreiben würden. Das ist die neue Form der Arbeit.

Wann Sie nach For/Goal greifen sollten – und wann nicht

Drei Kategorien von Arbeiten, in denen for/goal seinen Lebensunterhalt verdient:

First-Pass-App-Gerüst aus einer klaren Spezifikation. Genau das Experiment in diesem Beitrag. Sie haben ein PRD, eine Roadmap, ein Designdokument. Sie möchten eine lauffähige Hülle, bei der die meisten Oberflächen vorhanden sind. For/goal ist hier unschlagbar. Zweiunddreißig Minuten, wofür ein junger Ingenieur den größten Teil einer Woche brauchen würde.

Long-Horizon-Refaktoren mit messbaren Endzuständen. „Migrieren Sie jede Komponente in diesem Verzeichnis von der Klassen- in die Funktionssyntax, bis pnpm tsc --noEmit erfolgreich ist.“ „Konvertieren Sie alle useEffect-Datenabrufe in Serveraktionen, bis kein useEffect irgendwo in der Codebasis auf fetch verweist.“ Alles mit einer messbaren Stoppbedingung und einem mechanischen Weg. Die Ralph-Loop-Leute machen das schon seit einem Jahr; for/goal macht es einfach zu einem erstklassigen Feature.

Fehlerbehebungskampagnen. „Beheben Sie jeden TypeScript-Fehler im Repo, ohne das Laufzeitverhalten zu ändern.“ Der Validator prüft die Fehleranzahl. Der Agent arbeitet es auf Null herunter. Geht nach Hause.

Drei Kategorien, in denen for/goal das falsche Werkzeug ist:

Alles, was eine Produktbeurteilung während des Fluges erfordert. „Verbessern Sie den Onboarding-Ablauf.“ Das ist kein Ziel, das ist eine Meinung. Der Agent wird etwas produzieren. Es wird nicht das produzieren, was Sie wollten, es sei denn, Sie haben zuerst in die Spezifikation geschrieben, was Sie wollten. Fordern Sie es einfach auf.

Alles, was Produktionssysteme betrifft. For/goal ist für Umgebungen gedacht, in denen das schlechteste Ergebnis ist: „Der Agent hat meinen Nachmittag verschwendet.“ Nicht „der Agent hat eine Datenbank gelöscht.“ Automatische Genehmigung plus Produktionszugriff ist eine Fehlerkategorie, die keiner von uns begehen möchte.

Alles, wo der Validator die Qualität bewerten muss. Kleine Modelle können nicht antworten: „Ist dieser Code gut?“ zuverlässig. Sie können antworten: „Beendet dieser Befehl Null?“ zuverlässig. Gestalten Sie Ihre Validierungsfrage danach, was kleine Modelle gut können – ja/no Entscheidungen mit konkreten Signalen – oder Ihre Schleife stoppt entweder früh oder gar nicht.

Wenn Ihre Arbeit nicht in diese drei „guten“ Kategorien passt, möchten Sie wahrscheinlich die reguläre Chat-Schleife Claude Code oder For/goal ist das Spezialwerkzeug, zu dem ich zwei- oder dreimal pro Woche greife, nicht der tägliche Treiber.

Was ich das nächste Mal anders laufen lassen würde

Drei kleine Dinge, die ich in meinem nächsten for/goal-Experiment ändern werde.

Ich würde neben prd.md eine tests.md-Datei hinzufügen und den Agenten bitten, Integrationstests für die kritischen Pfade als Phase 0 vor jedem UI zu schreiben. Die Tests werden dann zum Stoppsignal des Validators, das viel stärker ist als „alle Roadmap-Aufgaben abgehakt“. Im Moment vertraut die Schleife darauf, dass der Agent selbst prüft, ob die Roadmap vollständig ist. Wenn die Tests wahr wären, könnte der Agent sich nicht selbst belügen.

Ich würde das Designdokument verschärfen. Mein design.md bestand aus etwa dreihundert Präferenzwörtern. Das nächste besteht aus sechshundert Wörtern mit bestimmten Komponentenmustern – genaue Abstandsmarkierungen, genaue Schriftskalierung, genaue Tastenhierarchie. Ich möchte dem Agenten weniger Spielraum für Design-Urteile geben, denn die Momente, in denen Claude Code und

Ich würde das gleiche Ziel in beiden Agenten und einem dritten ausführen – Gemini 3 Pro über seinen neuen CLI, den ich bei dieser Laufzeit noch nicht einem Stresstest unterzogen habe. Wenn zwei Agenten hinsichtlich derselben Spezifikation so stark voneinander abweichen, möchte ich wissen, was mir ein dritter Agent bringt. Das ist ein Beitrag für nächsten Monat.

Der Mentalitätswandel, klar ausgedrückt

Darauf komme ich immer wieder zurück.

Vor sechs Monaten musste ich beim Erstellen einer App mit Hilfe eines Agenten Code schreiben. Der Agent beschleunigte die Arbeit. Ich war der Motor.

Heute, mit for/goal, bedeutet das Erstellen einer App, dass ich mit Hilfe eines Agenten eine Spezifikation schreibe, die Spezifikation dann einem anderen Agenten übergebe und lese, was zurückkommt. Der Agent ist der Motor. Ich bin der Architekt.

Dieser Satz ist leicht zu tippen, aber schwer zu leben. An den meisten Tagen öffne ich immer noch standardmäßig den Editor und schreibe die erste Komponente selbst, weil ich diesen Schritt schon zehntausend Mal gemacht habe. Die Disziplin, dies nicht zu tun – eine zusätzliche Stunde in der Spezifikationsdatei zu bleiben, die Validatorfrage anstelle der Implementierung zu schreiben – ist die neue Fähigkeit. Die Ingenieure, die es zuerst entwickeln, sind diejenigen, die fünf Produkte in der Zeit ausliefern, die früher für die Auslieferung eines einzigen benötigt wurde.

Die beiden Terminals auf meinem linken Monitor um 15:19 Uhr an diesem Mittwochnachmittag waren im Nachhinein nicht besonders beeindruckend. Der beeindruckende Teil waren die vier Stunden, die ich am Tag damit verbracht habe, das PRD, die Roadmap und das Designdokument zu schreiben. Die Agenten erledigten in einer halben Stunde, wofür ich eine Woche gebraucht hätte. Das Denken, das die halbe Stunde möglich machte, nahm noch den Tag in Anspruch.

Das ist der Handel. Ich bin mir ziemlich sicher, dass ich es will.

Häufig gestellte Fragen

Was ist for/goal in Claude Code und Codex?

For/goal ist ein persistenter Zielmodus, bei dem der Agent über viele Runden hinweg autonom arbeitet, bis ein kleines Validierungsmodell bestätigt, dass eine definierte Abschlussbedingung erfüllt ist. In Claude Code wird es als /goal in Version 2.1.139 ausgeliefert; In Codex CLI steckt dasselbe Grundelement hinter /goal und zugehörigen Schrägstrichbefehlen in Version 0.128.0. Die vollständige Mechanik finden Sie oben unter „Was For/Goal tatsächlich ist“.

Wie lange kann ein for/goal-Lauf dauern?

For/goal-Läufe sind durch das von Ihnen festgelegte Budget – Runden, Token oder Arbeitszeit – und nicht durch eine feste Obergrenze begrenzt. Ich habe gesehen, dass sowohl 32-minütige Gerüstausführungen als auch Refaktorierungsausführungen über Nacht erfolgreich waren. Die praktische Obergrenze ist Ihr symbolisches Budget und Ihre Bereitschaft, die Schleife ohne Aufsicht weiterlaufen zu lassen.

Ist for/goal dasselbe wie die Ralph-Schleife?

For/goal ist eine Weiterentwicklung des Ralph-Loop-Musters. Ralph war ein Bash-while true-Wrapper um einen Codierungsagenten mit einem externen Verifizierungsschritt; for/goal integriert die gleiche Idee in den Agenten selbst mit einer integrierten Supervisor-Architektur und einem zustandsbewussten Stopp-Hook. Gleiche Form, sauberere Mechanik, bessere Validator-Integration.

Benötige ich einen PRD, um for/goal zu verwenden?

Sie benötigen ein klares, dateibasiertes Ziel. Ein PRD plus eine Roadmap ist die zuverlässigste Kombination, aber Sie können for/goal auch auf eine Testsuite, einen Build-Befehl oder eine messbare Metrik verweisen. Die Regel lautet: Der Validator muss antworten können: „Ist das Ziel erreicht?“ mit einer Ja-oder-Nein-Entscheidung, die auf einem konkreten Signal basiert, nicht auf einem Qualitätsurteil.

Was ist besser für for/goal – Claude Code oder Codex?

Keines von beiden ist unbedingt besser. In meinen Tests erzeugt Claude Code einen kommunikativeren Output – Zielseiten, Marketingoberflächen, kopierintensive Seiten, die sich lesen, als hätte eine Person sie geschrieben. Codex erzeugt eine interaktionsreichere Ausgabe – Dashboards, interne Tools, Oberflächen mit bearbeitbaren Zellen und Filtern wirken sofort ausgefeilter. Wählen Sie aus, was Sie versenden möchten.

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