ChatGPT · Loops und autonome Runs in Codex

Manche Programmierarbeit besteht aus demselben Schritt in Wiederholung, bis eine Bedingung erfüllt ist: Tests ausführen, Fehlermeldung lesen, Code patchen, Tests erneut ausführen. Genau dieses Muster sollte Codex automatisieren, nicht als einmalige Anfrage, sondern als agentischer Loop, der weiter editiert und ausführt, bis die Aufgabe tatsächlich erledigt ist.

Der agentische Loop, konkret

Sie wissen schon, dass ein Agent plant, handelt und beobachtet. In Codex ist dieser Loop in einem echten Workspace verankert: ein Checkout Ihres Repos, eine Shell und die Möglichkeit, Befehle auszuführen. Jede Runde sieht so aus:

1. Aufgabe und aktuellen Zustand des Repos lesen.
2. Über eine Aktion entscheiden (Datei editieren, Befehl ausführen).
3. Sie in der Sandbox ausführen und die Ausgabe erfassen.
4. Das Ergebnis mit dem Ziel vergleichen. Wenn nicht erreicht, erneut durchlaufen.

Der entscheidende Unterschied zu einem einzelnen Prompt ist der Schritt observe. Codex sieht stdout, Exit-Codes und Stack Traces und speist sie in die nächste Entscheidung ein. Deshalb funktioniert „mach, dass die Tests durchlaufen“: Die Testausgabe *ist* das Signal, das die nächste Änderung steuert.

Codex gibt es in zwei Formen, die dieselbe Engine nutzen: den CLI-/IDE-Agenten, der lokal gegen Ihren Working Tree läuft, und Codex cloud, das den Loop auf der Infrastruktur von OpenAI gegen ein verbundenes GitHub-Repo ausführt. In der Cloud-Variante finden autonome und geplante Runs statt. Aktuelle Details in der Codex-Dokumentation.

Wann ein Loop besser ist als eine einzelne Anfrage

Eine einzelne Anfrage ist richtig, wenn die Änderung abgegrenzt ist und Sie den Diff mit einem Blick prüfen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen. Greifen Sie zum Loop, wenn die Aufgabe eine überprüfbare Abbruchbedingung hat, die der Agent selbst prüfen kann:

• Iterieren, bis die Tests grün sind. Die Test-Suite definiert „fertig“. Der Agent braucht Sie zwischen den Versuchen nicht.
• Ein Backlog von Dateien abarbeiten. Jede Komponente von einer deprecated APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → wegmigrieren, Type Hints in einem Verzeichnis ergänzen oder ein Pattern in 40 Modulen anheben. Der Loop lautet: „für jede Datei: Änderung anwenden, deren Tests laufen lassen, weiter.“
• Fixen, bis Lint- und Typprüfungen durchlaufen. ruff, mypy, tsc: jedes liefert einen sauberen Exit-Code, gegen den Sie loopen können.

Der gemeinsame Nenner: Es gibt ein maschinell prüfbares Orakel. Wenn „fertig“ subjektiv ist („mach die UI schöner“), verbrennt ein Loop nur Budget auf der Jagd nach einem Ziel, das er nicht messen kann. Solche Aufgaben bleiben interaktive Sessions.

Iterieren, bis die Tests grün sind

Hier der kanonische Loop. Sie geben Codex das Ziel, den Befehl, der es verifiziert, und eine Obergrenze. Lokal ist das ein Prompt plus eine Config; in der Cloud richten Sie es pro Task ein. Dieses YAML ist die Art von Task-Spezifikation, die Sie einem geplanten Codex-Run mitgeben würden:

task: Fix the failing tests in the billing module.
repo: acme/payments
branch: fix/billing-tests
setup:
  - pip install -e ".[dev]"
verify:
  command: pytest tests/billing -q
  success_when: exit_code == 0
limits:
  max_iterations: 8
  max_wall_clock_minutes: 20
on_success:
  open_pull_request: true
  reviewers: [payments-team]

Der Loop, den der Agent tatsächlich ausführt, ist als Pseudocode trivial, und es lohnt sich, ihn zu sehen, damit Sie genau wissen, worauf ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → optimiert:

for attempt in range(max_iterations):
    result = run("pytest tests/billing -q")
    if result.exit_code == 0:
        commit("fix: billing tests green")
        break
    # Codex liest result.stdout, editiert die relevanten Dateien,
    # dann führt der Loop denselben Befehl erneut aus.
    apply_fix(diagnose(result.stdout))
else:
    report("gave up after max_iterations; latest diff attached")

Zwei Dinge machen das sicher, statt es außer Kontrolle geraten zu lassen. Erstens ist verify.command die *einzige* Definition von Erfolg, der Agent kann sich also nicht nach Gefühl zum Sieger erklären. Zweitens endet der Loop entweder bei grünen Tests oder an einer harten Obergrenze. Es gibt keinen Weg, auf dem er endlos läuft.

Autonome und geplante Runs starten

In Codex cloud verbinden Sie ein GitHub-Repo und starten dann Tasks, die laufen, ohne dass Sie dabeisitzen. Es gibt drei Wege, einen auszulösen:

• On demand. Aufgabe beschreiben, Repo und Branch wählen, und Codex fährt eine Umgebung hoch, führt den Loop aus und öffnet am Ende einen PR.
• Geplant. Codex unterstützt wiederkehrende Runs, derselbe Mechanismus wie hinter geplanten Tasks in ChatGPT. Ein nächtlicher Job „die komplette Suite auf main laufen lassen, Flakes fixen, einen PR öffnen“ ist der Klassiker.
• Event-getrieben, über die API. Einen Run aus CI oder per Webhook auslösen (etwa ein neues Issue mit dem Label codex), mit der Responses API und Tools, oder mehrstufige Steuerung mit dem Agents SDK orchestrieren.

Das Mental Model: Ein On-demand-Run ist Ihr Startknopf. Ein geplanter Run ist ein Cron-Job, der zufällig ein Agent ist. Beide legen ihre Arbeit in einen Branch und einen Pull Request, niemals direkt auf `main`.

Ein Beispiel für ein geplantes Backlog

Angenommen, Sie migrieren eine Codebase von einem deprecated Logging-Call weg. Sie wollen nicht 40 Dateien babysitten. Planen Sie einen nächtlichen Run:

„Ersetze in bis zu 6 Dateien, die noch old_logger verwenden, diesen gemäß docs/logging.md durch structlog, führe pytest für jedes berührte Modul aus und öffne einen PR mit dem Titel chore: migrate logging (batch). Überspringe Dateien, bei denen die Tests nach der Änderung fehlschlagen, und vermerke sie in der PR-Beschreibung.“

Diese Spezifikation hat eine Batch-Größe (Kostenkontrolle), einen Verify-Schritt pro Datei (Korrektheit) und ein explizites Notausgang für die harten Fälle (keine kaputte Änderung erzwingen). Über eine Woche leert sich das Backlog selbst, ein prüfbarer PR nach dem anderen.

Abbruchbedingungen: was einen Loop tatsächlich beendet

Ein unbeaufsichtigter Loop braucht mehr als einen Ausgang. Planen Sie alle davon ein:

• Erfolgsbedingung erfüllt. Der Verify-Befehl liefert Exit-Code 0. Das ist der Happy Path.
• Iterationsgrenze. max_iterations stoppt die Spirale „editieren, noch rot, wieder editieren“. Wenn acht Versuche die Tests nicht grün bekommen, schaffen es mehr Versuche selten.
• Wall-Clock-/Budgetgrenze. Eine Zeit- oder TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen →-Obergrenze. Wenn Codex nicht konvergiert, soll es *günstig* stoppen und Ihnen einen Diff übergeben, statt weiterzumahlen.
• Erkennung von Stagnation. Wenn zwei aufeinanderfolgende Versuche dieselbe Fehlerausgabe produzieren, hängt der Agent fest. Ein guter Loop behandelt das als Stopp, nicht als Grund, denselben Fix noch einmal zu probieren.

Nennen Sie jede Grenze explizit. Der Failure Mode autonomer Runs ist meist kein schlechtes Edit; es ist ein Agent, der sich an einem unlösbaren Problem abarbeitet, während die Uhr läuft.

Kostengrenzen und die Sandbox

Jeder Codex-cloud-Run läuft in einem isolierten Container: eine frische Umgebung mit Ihrem Repo, ohne Zugriff auf Ihre anderen Systeme, sofern Sie ihn nicht gewähren. Diese Isolation ist Ihre erste Kosten- und Sicherheitsgrenze, denn ein Loop, der Production nicht anfassen kann, kann keinen Production-Incident auslösen.

Steuern Sie Ausgaben auf zwei Ebenen:

• Pro Run: die Iterations- und Zeitgrenzen von oben. Eine Obergrenze von 20 Minuten für einen nächtlichen Job begrenzt den Worst Case.
• Pro Account: setzen Sie Usage Limits in den Billing-Einstellungen der OpenAI-Plattform, damit ein falsch konfigurierter Zeitplan nicht eine Woche lang unbemerkt die Nächte durchläuft.

Steuern Sie außerdem, was der Loop erreichen kann. Netzwerkzugriff in der Codex-Umgebung ist konfigurierbar; für einen Job zum Testfixen braucht der Agent Ihr Repo und Package-Installationen, nicht das offene Internet. Beschränken Sie die Umgebung auf das, was die Aufgabe erfordert. Ein Loop mit weniger Fähigkeiten ist ein Loop mit weniger Möglichkeiten, Sie zu überraschen.

Review-Gates: vertrauen, aber den Diff prüfen

Die wichtigste Sicherheitseigenschaft: ein autonomer Codex-Run produziert einen Pull Request, keinen Merge. Die Ausgabe des Loops landet auf einem Branch und wartet auf einen Menschen. Ihre bestehenden GitHub-Schutzmechanismen gelten weiter, und Sie sollten sich darauf stützen:

• Erforderliche Reviews. Branch Protection heißt, ein Codex-PR kann ohne menschliche (oder CI-)Freigabe nicht gemergt werden. Behandeln Sie den Agenten als Contributor, dessen PRs immer ein Review brauchen.
• CI als zweites Orakel. Der Agent hat die Tests lokal in seiner Sandbox laufen lassen; CI führt sie in Ihrer echten PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → noch einmal aus. Wenn CI widerspricht, war das „grün“ des Loops umgebungsspezifisch, und Sie haben es gerade erwischt.
• Abgegrenzte Diffs. Grenzen für die Batch-Größe (sechs Dateien, ein Modul) halten PRs klein genug, um sie wirklich zu reviewen. Ein autonomer Diff über 3.000 Zeilen ist nicht reviewbar und verfehlt den Zweck.

Denken Sie an einen funnelfunnelDie Customer Journey von der Aufmerksamkeit bis zum Kauf, typischerweise Awareness, Interest, Consideration, Decision, Action, wobei sich die Zahl der Interessenten auf jeder Stufe verringert.Vollständige Definition ansehen →: der Loop iteriert innerhalb der Sandbox frei, aber der Ausgang ist ein enges, prüfbares Gate. Freiheit *innen*, Kontrolle *an der Grenze*.

Einen Codex-PR schnell lesen

Weil der Run jede Aktion protokolliert, kommen seine PRs mit einer Spur: welche Befehle er ausgeführt hat, welche Ausgabe er gesehen hat und warum er jedes Edit gemacht hat. Prüfen Sie beim Review drei Dinge: Passt der Diff zum genannten Ziel, ist der Verify-Befehl wirklich durchgelaufen (und nicht deaktiviert oder mit @skip versehen), und ist die Änderung auf das begrenzt, was Sie verlangt haben. Ein Loop, der „Tests bestehen lässt“, indem er den fehlschlagenden Test löscht, ist der klassische Trick. Lesen Sie darauf hin.

Alles zusammengesetzt

Ein gut gestalteter autonomer Run liest sich wie ein Vertrag. Ziel, eine maschinell prüfbare Definition von „fertig“, harte Grenzen für Iterationen und Zeit, eine enge Umgebung und ein Ausgang nur über PR. Geben Sie Codex alle fünf, und Sie können es über Nacht allein arbeiten lassen, mit derselben Zuversicht, die Sie einem Junior Engineer mit einem gut spezifizierten Ticket geben würden: Entweder erledigt es das Ticket oder es sagt Ihnen, warum nicht.

Key Takeaways

• Nutzen Sie einen Loop nur, wenn „fertig“ maschinell prüfbar ist. Tests grün, Lint sauber, ein Exit-Code der Typprüfung. Ist das Ziel subjektiv, bleibt es interaktiv.
• Setzen Sie immer drei Grenzen: Erfolgsbedingung, Iterationslimit und Zeit-/Budgetobergrenze. Der gefährliche Failure Mode ist ein Agent, der sich an einem unlösbaren Problem abarbeitet, nicht ein einzelnes schlechtes Edit.
• Planen Sie wiederkehrende Arbeit (Backlog-Migrationen, nächtliche Testfixes) mit Batch-Größen und Verifikation pro Element, damit jeder Run die Queue in kleinen, reviewbaren PRs abbaut.
• Halten Sie die Sandbox eng. Gewähren Sie nur den Repo-Zugriff und das Netzwerk, die die Aufgabe braucht; setzen Sie Usage Limits auf Account-Ebene, damit ein falsch konfigurierter Zeitplan keine Kosten auftürmen kann.
• Der Ausgang ist ein Pull Request, niemals ein Merge. Erzwingen Sie Branch Protection, lassen Sie die Tests in CI erneut laufen und lesen Sie den Diff immer auf den Trick „fehlschlagenden Test gelöscht“ hin.