Zusammenarbeit mit Codex bei langfristigen Aufgaben

Codex kann über längere Zeiträume hinweg arbeiten, besonders wenn ein /goal ihm ein beständiges Ziel vorgibt. Die größere Herausforderung ist es, die Orientierung zu behalten, während es stunden- oder tagelang arbeitet, neue Implementierungsdetails aufdeckt und mehrere Arten der Überprüfung durchläuft.

Frühe Annahmen ändern sich oft, sobald die Implementierung beginnt. Das Kollaborationsmodell muss das Ziel bewahren, während es sowohl dir als auch Codex den Spielraum gibt, den Plan zu überarbeiten, sobald neue Erkenntnisse vorliegen.

In den letzten Wochen habe ich fünf Praktiken angewandt:

1. Codex die Arbeit planen und den Fahrplan pflegen lassen.
2. Den Haupt-Thread auf die Koordination fokussieren.
3. Den Fahrplan prüfen und den Code nach jedem Meilenstein reviewen.
4. Lokale Threads für Computer-Use-Tests nutzen.
5. Fortschritte durch prägnante Updates und Dashboards melden.

Generiert mit GPT Image 2 in Codex

1. Codex die Arbeit planen und den Fahrplan pflegen lassen

Ich beginne normalerweise mit einem Gespräch, nicht mit dem /plan-Modus. Ich beschreibe, was ich bauen möchte, äußere grobe Gedanken, teile Einschränkungen mit und lasse Codex Fragen stellen, bis es genug Kontext hat, um einen ersten Plan vorzuschlagen.

Das hält die frühe Diskussion flexibel. Ich muss keine halb ausgearbeiteten Ideen in ein formales Pflichtenheft verwandeln, bevor Codex helfen kann. Es kann mich interviewen, mir widerspiegeln, was es verstanden hat, Lücken identifizieren und das Gespräch nach und nach in einen umsetzbaren Plan verwandeln.

Sobald das Projekt Gestalt annimmt, bitte ich Codex, das aktuelle Ziel zu setzen. Der Ziel-Modus gibt Codex ein beständiges Ziel, sodass es über mehrere Schritte hinweg auf dasselbe Ergebnis hinarbeiten kann, bis das Ziel erreicht, blockiert oder ersetzt ist.

Ich kann das Ziel selbst mit /goal setzen, aber normalerweise bitte ich Codex darum. Der Ziel-Modus wird über das Harness bereitgestellt, sodass Codex unser Gespräch, den Projektkontext und alles, was es bisher gelernt hat, zu einem klaren Ziel zusammenfassen kann. Es kann auch die erforderlichen Nachweise definieren, bevor es das Ziel als erreicht betrachtet.

Bei größeren Projekten bitte ich Codex, den übergeordneten Fahrplan in GOALS.md zu schreiben. Dies ist eine Projektkonvention und keine integrierte Codex-Funktion; die Datei kann beliebig benannt werden.

Ich organisiere GOALS.md normalerweise nach Meilensteinen anstatt nach einer flachen Aufgabenliste. Jeder Meilenstein hält fest:

• das angestrebte Ergebnis
• die aktuell im Umfang enthaltene Arbeit
• wichtige Entscheidungen
• bekannte Blocker
• die erforderlichen Nachweise, bevor es weitergeht

Codex pflegt die Datei, während sich das Projekt entwickelt. Neue Erkenntnisse können den Umfang eines Meilensteins ändern, einen weiteren hinzufügen oder die für den Abschluss erforderlichen Nachweise verändern.

Es ist immer nur ein Ziel im Ziel-Modus aktiv. Wenn Meilensteine abgeschlossen sind, aktualisiert Codex GOALS.md, aktiviert das nächste Ziel und arbeitet weiter darauf hin.

2. Den Haupt-Thread auf die Koordination fokussieren

Sobald der Fahrplan existiert, konzentriere ich den Haupt-Thread auf das Ziel, die Einschränkungen, Entscheidungen und den aktuellen Projektstatus.

Er entscheidet, was als Nächstes passieren soll, delegiert abgegrenzte Aufgaben und bewertet die Ergebnisse. Er muss nicht jedes Implementierungsdetail mit sich herumtragen.

Ein Worker kann eine Stunde damit verbringen, unbekannten Code zu lesen, mehrere Ansätze auszuprobieren oder einen fehlschlagenden Test zu verfolgen. Der Koordinator benötigt nur die Informationen, die das gesamte Projekt betreffen:

• was der Worker gelernt hat
• was sich geändert hat
• die unterstützenden Nachweise
• was als Nächstes passieren soll

Codex kann diese Arbeit an einen Subagenten delegieren oder einen separaten Thread erstellen. Funktionell können sie dieselbe Aufgabe ausführen. Ich verwende einen separaten Thread, wenn ich die Arbeit später noch einmal aufgreifen möchte, da sie in der Codex-App sichtbar bleibt und eine eigene Historie behält.

Dies wird besonders nützlich, sobald mehrere Arbeiten parallel laufen. Der Haupt-Thread kann das Projekt weiter koordinieren, während jede Untersuchung, Implementierung oder Überprüfung leicht einsehbar bleibt.

3. Den Fahrplan prüfen und den Code nach jedem Meilenstein reviewen

GOALS.md spiegelt wider, was zum Zeitpunkt der letzten Aktualisierung durch Codex bekannt war. Bis zum Ende eines Meilensteins hat das Projekt normalerweise etwas Neues entdeckt.

Bevor es weitergeht, bitte ich einen anderen Thread, den Fahrplan mit dem aktuellen Stand zu vergleichen:

• Ist der Meilenstein tatsächlich abgeschlossen?
• Ist das nächste Ziel noch das richtige?
• Fehlen irgendwelche Meilensteine?
• Hat neue Erkenntnis die Reihenfolge der Arbeit geändert?
• Gilt die Definition von „erledigt" noch?

Ich führe diese Prüfung am Ende jedes Meilensteins durch, sowie immer dann, wenn neue Erkenntnisse die Richtung des Projekts wesentlich ändern.

Ich führe auch /review für die Implementierung durch.

Angenommen, die Implementierung und die Remote-Tests für einen Anmeldevorgang sind abgeschlossen. Die Fahrplanprüfung könnte feststellen, dass niemand den Vorgang in einem echten, angemeldeten Browser getestet hat. Gleichzeitig könnte /review ergeben, dass der neue Pfad ein Token falsch speichert, obwohl die Remote-Tests bestanden haben.

Der Koordinator aktualisiert GOALS.md, delegiert die Token-Korrektur, fügt die fehlende Browser-Überprüfung hinzu und aktiviert erst dann den nächsten Meilenstein.

Ich behalte Prüfungen und Reviews normalerweise in separaten Threads. Ein Subagent könnte die gleiche Arbeit erledigen, aber ein separater Thread hinterlässt einen sichtbaren Nachweis, auf den ich später zurückgreifen kann.

4. Lokale Threads für Computer-Use-Tests nutzen

Die meisten meiner Codex-Sitzungen laufen auf einer Remote-Instanz, sodass die Arbeit weitergehen kann, während mein Laptop zugeklappt ist. Einige Überprüfungen hängen dennoch von meinem lokalen Rechner ab:

• ein angemeldeter Browser
• lokale Anmeldeinformationen
• Xcode
• macOS-Berechtigungen
• der iOS-Simulator

Der Remote-Koordinator kann einen lokalen Thread für eine dieser Überprüfungen erstellen. Ich wende das Remote-Diff an oder checke den entsprechenden Branch oder Commit aus, damit der lokale Thread den korrekten Code testet.

Der lokale Thread bedient den Browser oder die Anwendung und gibt Screenshots, Logs und Erkenntnisse zurück. Wenn eine Überprüfung fehlschlägt, behebt ein Remote-Worker das Problem und der lokale Thread testet erneut.

Eine typische Schleife sieht so aus:

1. Ein Remote-Worker implementiert den Anmeldevorgang.
2. Remote-Tests bestehen.
3. Ein lokaler Thread verwendet die Codex Chrome-Erweiterung.
4. Der Browser-Test deckt einen Redirect-Fehler auf.
5. Ein Remote-Worker behebt ihn.
6. Der lokale Thread wiederholt die Überprüfung.

Das Projekt bleibt standardmäßig remote. Mein Rechner beteiligt sich nur an den Überprüfungen, die ihn erfordern. Der Remote-Thread kann auch weiterhin darauf warten, dass der lokale Thread wieder verfügbar wird, wenn ich meinen Laptop wieder öffne.

5. Fortschritte durch prägnante Updates und Dashboards melden

Worker-Threads berichten normalerweise über eine einzelne Aufgabe. Wenn ich zum Projekt zurückkehre, benötige ich einen Überblick über den Gesamtzustand:

• was ist abgeschlossen
• was hat sich geändert
• was bleibt noch
• was benötigt eine Entscheidung

Ich bitte Codex, immer dann zu berichten, wenn sich der Projektzustand ändert, und zwar in drei kurzen Abschnitten:

**Was ist erledigt

Was kommt als Nächstes

Gibt es Blocker**

Das ist fast so, als hätte man täglich ein Standup mit Codex, wenn auch stündlich.

Codex kann dasselbe Update über Slack senden, entweder als Direktnachricht oder in einem dedizierten Projektkanal.

Während ich in der Codex-App bin, verwende ich auch /side, um nach dem Rechten zu sehen, ohne den Haupt-Thread zu unterbrechen. Vom Side-Thread aus kann ich eine Zusammenfassung darüber anfordern, was abgeschlossen wurde, was noch aussteht und ob etwas meine Hilfe benötigt – zum Beispiel ein manueller Klick, eine Genehmigung oder ein weiterer Clickops-Schritt.

Eine Zusammenfassung vom Side-Thread erhalten

Den Side-Thread bitten, meine Anweisungen an den Haupt-Thread weiterzuleiten

Ich kann dann eine Anweisung präzisieren, einen Blocker auflösen, Kontext hinzufügen oder den Side-Thread bitten, aktualisierte Anweisungen zurück an den Haupt-Thread zu senden.

Für Projekte mit mehreren Meilensteinen oder parallelen Arbeitsabläufen pflege ich auch eine progress-dashboard.html. Dies ist ein benutzerdefiniertes Projekt-Artefakt und keine integrierte Codex-Oberfläche. Es kann anzeigen:

• das aktive Ziel
• abgeschlossene Meilensteine
• Nachweise
• Blocker
• Entscheidungen
• aktuelle Updates

Wenn ich nach mehreren Stunden zurückkomme, kann ich den Projektstatus verstehen, ohne jeden Worker-Thread lesen zu müssen. Codex kann das Dashboard auch als Site bereitstellen, sodass es remote zugänglich bleibt.

Zusammenfassung

Ich verwende diese Struktur, wenn ein Projekt wahrscheinlich neue Informationen zutage fördert, mehrere unabhängige Arbeitspakete umfasst oder Nachweise aus mehr als einer Umgebung erfordert.

Der Arbeitsablauf folgt einem einfachen Kreislauf. Codex verwandelt das erste Gespräch in einen Fahrplan, aktiviert einen Meilenstein, delegiert die Arbeit und überprüft das Ergebnis, bevor es weitergeht. Lokale Threads kümmern sich um die Überprüfungen, die meinen Rechner erfordern, während Updates und Dashboards mir helfen, zum Projekt zurückzukehren, ohne alles von Grund auf neu rekonstruieren zu müssen.

Der wichtige Punkt ist, den Projektstatus aktuell genug zu halten, damit die nächste Entscheidung widerspiegelt, was Codex tatsächlich gelernt hat.

Probier es aus

Füge dies in einen neuen Codex-Thread ein:

Koordiniere dies als ein langlaufendes Projekt.

Beginne damit, mich zu interviewen, was ich bauen möchte. Lass mich grobe Ideen und Einschränkungen im Gespräch beschreiben und verwandle diese Diskussion dann in einen ersten Plan.

Erstelle GOALS.md als gemeinsamen Fahrplan. Organisiere ihn nach Meilensteinen, mit dem angestrebten Ergebnis, Umfang, Entscheidungen, Blockern und den erforderlichen Nachweisen für jeden.

Setze und pflege jeweils ein Ziel im Ziel-Modus. Das aktive Ziel sollte dem aktuellen Meilenstein entsprechen.

Halte diesen Thread auf das Ziel, die Einschränkungen, Entscheidungen und den Projektstatus fokussiert. Delegiere die Implementierung an Subagenten oder neue Threads.

Verlange von den Workern, dass sie Schlussfolgerungen, Änderungen und Nachweise zurückgeben, nicht vollständige Transkripte.

Verwende separate Threads, wenn ich die Arbeit später möglicherweise einsehen, fortsetzen oder überprüfen möchte. Verwende Subagenten für abgegrenzte Arbeiten, die keine eigene sichtbare Historie benötigen.

Verwende nach jedem Meilenstein einen separaten Thread, um GOALS.md mit dem aktuellen Stand zu vergleichen und /review für die Implementierung durchzuführen. Aktualisiere den Fahrplan, bevor du das nächste Ziel aktivierst.

Verwende lokale Threads für Computer-Use-Tests, die von meinem Browser, Desktop-Anwendungen, Berechtigungen, Anmeldeinformationen oder Gerätezustand abhängen.

*Wenn sich der Projektzustand ändert, berichte nur: - Was ist erledigt - Was kommt als Nächstes - Gibt es Blocker*

Pflege progress-dashboard.html, wenn das Projekt mehrere Meilensteine oder Worker umfasst. Erkläre den Abschluss erst, wenn die vereinbarten Nachweise vorliegen.

Alternativ kannst du auch einen Appshot dieses Artikels machen und Codex bitten:

Erstelle eine wiederverwendbare Codex-Fähigkeit namens orchestrate-projects aus diesem Artikel.

Behalte diese Praktiken bei:

*- Lass Codex mich interviewen und die ersten Pläne erstellen - Verwende GOALS.md als meilensteinbasierten Fahrplan - Behalte jeweils ein Ziel im Ziel-Modus aktiv - Halte den Haupt-Thread auf die Koordination fokussiert - Prüfe den Fahrplan und führe /review nach jedem Meilenstein durch - Verwende separate Threads für Arbeiten, die ich möglicherweise wieder aufgreifen möchte - Verwende lokale Threads für Computer-Use-Tests - Berichte Fortschritte durch prägnante Updates, Slack und progress-dashboard.html*