Lokale Coding-Agenten arbeiten mit Ihnen im Takt. Der Cloud-Agent von OpenAI Codex arbeitet dagegen asynchron: Sie beschreiben eine Aufgabe, Codex startet einen eigenen Container mit Ihrem Repository und liefert nach einiger Zeit einen Diff oder Pull Request. Weil jede Aufgabe isoliert läuft, können Sie mehrere gleichzeitig anstoßen. Das klingt nach mehr Durchsatz, verlangt aber eine andere Arbeitsweise. Dieser Artikel zeigt, wie Sie Umgebungen einrichten, welche Aufgaben sich eignen und wie Sie die Flut an Ergebnissen sinnvoll prüfen.
So arbeitet der Cloud-Agent
Sie verbinden Codex mit GitHub und wählen ein Repository. Für jede Aufgabe erzeugt Codex eine frische Umgebung aus einem Container-Image, klont den Code, führt Ihr Setup-Skript aus und beginnt dann mit der eigentlichen Arbeit. Am Ende sehen Sie die Änderungen, die ausgeführten Befehle und die Testergebnisse und können daraus direkt einen Pull Request erstellen.
Aufgaben lassen sich aus der Codex-Oberfläche in ChatGPT, aus der IDE-Extension, aus der CLI oder per Erwähnung von @codex in GitHub starten. Für eine Aufgabe können Sie außerdem mehrere Lösungsversuche parallel anfordern und den besten auswählen. Das ist besonders bei kniffligen Bugs hilfreich, bei denen der erste Ansatz nicht immer der beste ist.
Die Umgebung richtig vorbereiten
Die Qualität der Ergebnisse hängt stark davon ab, ob der Agent bauen und testen kann. Ein Setup-Skript, das Abhängigkeiten installiert und die Testumgebung vorbereitet, ist deshalb Pflicht. Während der Agent arbeitet, ist der Internetzugriff standardmäßig gesperrt. Sie können ihn freischalten und auf bestimmte Domains begrenzen, sollten das aber bewusst und sparsam tun.
Umgebungsvariablen und Secrets lassen sich hinterlegen. Secrets stehen dabei nur dem Setup-Skript zur Verfügung, nicht dem Agenten selbst. Das ist sinnvoll, denn so kann etwa ein privates Paket installiert werden, ohne dass der Token im späteren Arbeitsschritt erreichbar ist. Ergänzen Sie eine AGENTS.md mit Testbefehlen, Code-Konventionen und Hinweisen zur Projektstruktur.
Aufgaben richtig schneiden
Parallelität lohnt sich nur, wenn die Aufgaben unabhängig sind. Gute Kandidaten sind klar umrissene Bugs mit reproduzierbarem Test, kleine Refactorings in getrennten Modulen, fehlende Tests für bestehende Funktionen, Dokumentationslücken oder Abhängigkeits-Updates. Schlechte Kandidaten sind Architekturänderungen und alles, was viele gemeinsame Dateien berührt.
Formulieren Sie jede Aufgabe so, als würden Sie sie an eine neue Kollegin geben: Ziel, betroffene Dateien, Akzeptanzkriterien und der Befehl, mit dem das Ergebnis geprüft wird. Je präziser die Beschreibung, desto seltener landen Sie in langen Korrekturschleifen.
Hilfreich ist auch eine einheitliche Vorlage für Aufgabenbeschreibungen, die im Team geteilt wird. Sie zwingt dazu, Akzeptanzkriterien vorab zu klären, und macht die Ergebnisse vergleichbarer. Nach einigen Wochen erkennen Sie schnell, welche Aufgabentypen der Agent zuverlässig löst und welche besser lokal bearbeitet werden.
Ein Arbeitsablauf, der skaliert
- Sammeln Sie morgens drei bis fünf unabhängige Aufgaben aus dem Backlog und schreiben Sie präzise Beschreibungen.
- Starten Sie alle Aufgaben im Cloud-Agenten und wenden Sie sich in der Zwischenzeit anderer Arbeit zu.
- Prüfen Sie zuerst die Testergebnisse und Befehlsprotokolle jeder Aufgabe, erst dann den Diff.
- Geben Sie bei kleinen Abweichungen eine Folgeanweisung in derselben Aufgabe, statt neu zu beginnen.
- Erstellen Sie Pull Requests nur für Ergebnisse, die Sie selbst verstanden haben, und lassen Sie sie regulär reviewen.
Grenzen und nächster Schritt
Der Engpass verschiebt sich vom Schreiben zum Prüfen. Wer zehn Aufgaben parallel startet, muss auch zehn Diffs gewissenhaft lesen. Planen Sie Review-Kapazität deshalb von Anfang an mit ein und beginnen Sie lieber mit wenigen parallelen Aufgaben.
Hinzu kommen Konflikte: Zwei Aufgaben, die unabhängig erschienen, berühren am Ende doch dieselbe Konfigurationsdatei. Mergen Sie die Ergebnisse deshalb nacheinander und lassen Sie die Tests nach jedem Merge erneut laufen. Und behalten Sie im Blick, dass der Cloud-Agent nur so gut ist wie Ihre Testabdeckung – wo Tests fehlen, fehlt auch die Sicherheit, dass ein grüner Lauf wirklich korrekt bedeutet.
Wie Sie den Cloud-Agenten in Ihren Entwicklungsprozess einbinden, zeigen unsere AI Code Engineers in den Codex-Workshops von neooutput – mit Ihrer echten Codebasis und Ihren Review-Regeln. Ein kostenloses 15-Minuten-Erstgespräch ist der einfachste Einstieg.
Häufige Fragen
Hat der Cloud-Agent Zugriff auf meine Secrets?
Secrets, die Sie in der Umgebung hinterlegen, stehen nur während des Setup-Skripts zur Verfügung. Der Agent selbst arbeitet ohne sie. Prüfen Sie dennoch, welche Daten im Repository liegen, denn darauf hat der Agent vollen Zugriff.
Wie viele Aufgaben sollte ich parallel starten?
So viele, wie Sie gewissenhaft prüfen können. Für den Einstieg sind drei bis fünf unabhängige Aufgaben realistisch. Mehr lohnt sich erst, wenn Tests und Review-Prozess gut eingespielt sind.
Kann ich lokal weiterarbeiten, was die Cloud begonnen hat?
Ja. Sie können die Änderungen einer Cloud-Aufgabe lokal übernehmen, etwa über die IDE-Extension oder als Branch aus dem Pull Request, und dort mit der Codex CLI oder einem anderen Werkzeug fortsetzen.