Alle Artikel
KI-Unternehmen

Dots und Codex: Wer koordiniert, wo die Arbeit läuft

LLM Rumors··7 Min. Lesezeit·...
OpenAIChatGPT DotsCodexKI-AgentenCloud-EntwicklungEntwicklerwerkzeugeAufgabenkoordinationGit-Worktrees

Deutsche Übersetzung: . Englisches Original

KI-generierte redaktionelle Illustration eines mechanischen Verteiltisches, der unbeschriftete Arbeitspakete zu einer Cloud-Werkbank und einem separaten lokalen Computer leitet. Sie veranschaulicht Aufgabenverteilung, keine tatsächliche Produktoberfläche.

TL;DR: Betrachten Sie Dots und Codex als 2 zusammenarbeitende Rollen: Koordination und Ausführung. OpenAI dokumentiert, dass ein Dot Aufgaben an Codex delegieren kann; das Verbinden eines persönlichen Computers überträgt jedoch keine Sitzung seines Cloud-Browsers.[1][2] Wählen Sie den Arbeitsplatz ausdrücklich und prüfen Sie anschließend geänderte Dateien oder das fertige Ergebnis, statt den Abschluss einer Aufgabe mit ihrer Lieferung gleichzusetzen.

Das teuerste Missverständnis in einem Agentenablauf kann ganz einfach sein: „auf meinem Computer“ bedeutet für die Beteiligten Unterschiedliches. Ein Nutzer sendet eine Anfrage vom Telefon. Ein Koordinator organisiert die Arbeit in der Cloud. Eine Programmieraufgabe verändert Dateien auf einem verbundenen Rechner. Das Gespräch ist mobil; das Repository ist es nicht.

Die aktuelle Dokumentation von OpenAI beschreibt Dots und Codex als Ergänzungen. Dots können Verantwortlichkeiten verfolgen und delegieren; Codex bietet Entwicklungsabläufe mit einer konkreten Projektumgebung.[1][4] Unsere Analyse vom 5. Oktober: Der nützliche Vergleich betrifft den Ausführungsort und die Verantwortung für Ergebnisse. Die Frage, welches Produkt intelligenter ist, überspringt die betriebliche Entscheidung, die bestimmt, ob die Arbeit überhaupt stattfinden kann.

HINWEIS

Warum das jetzt wichtig ist

Ein Agent kann eine Aufgabe koordinieren, ohne ihre Ausführungsumgebung zu besitzen. Benennen Sie vor der Delegation das Repository oder die Quelldateien, den Computer oder die Cloud-Umgebung, das erwartete Ergebnis und die nötigen Abnahmebelege. Diese Entscheidungen machen einen allgemeinen Auftrag überprüfbar.

Titelbild: KI-generierte redaktionelle Illustration zur Verteilung von Arbeit zwischen Umgebungen. Sie ist keine OpenAI-Oberfläche, kein Bereitstellungsdiagramm und keine Messung der Produktleistung.

Der Koordinator: Dem Dot eine Verantwortung geben

Der Einstiegsleitfaden für Dots beschreibt die Delegation von Auftragsteilen an ChatGPT Work oder Codex und die Prüfung dieser Arbeit unter Activity.[1] Daraus ergibt sich eine sinnvolle Arbeitsteilung: Ein Dot kann das fortlaufende Anliegen betreuen, während eine konkrete Programmieraufgabe eine begrenzte Änderung übernimmt.

Nehmen wir einen beispielhaften Fehler im Bezahlvorgang. Bitten Sie den Dot, das Problem zu verfolgen, relevante Meldungen zu sammeln und einen Änderungsvorschlag zu koordinieren. Geben Sie der Programmieraufgabe das Repository, den Ausgangszustand, Reproduktionsschritte und Abnahmekriterien. Die Koordination soll diese Eingaben mit dem Ergebnis verbinden, einschließlich neuer Informationen, die nach Beginn der Umsetzung eintreffen.

Der strategische Wert liegt darin, den Aufmerksamkeitsaufwand des Verantwortlichen zu senken. Ein Koordinator, der eine ungelöste Abhängigkeit erkennt, kann nützlicher sein als ein weiterer Agent, der Code schreibt. Dafür braucht es aber eine disziplinierte Übergabe: Die Teilaufgabe benötigt genügend Kontext für die richtige Änderung, ohne das gesamte Geschäftsgespräch rekonstruieren zu müssen.

Cloud-Arbeit: Browser und Entwicklungsumgebung unterscheiden

Der Cloud-Computer eines Dots besitzt eigene Dateien und Browsersitzungen.[2] Codex Cloud führt dagegen Programmieraufgaben aus einer konfigurierten Umgebung aus, mit getrennten Arbeitsbereichen und der Prüfung geänderter Dateien sowie Testergebnisse.[4] „Cloud“ benennt einen Ort, keine bestimmte Fähigkeit.

Der aktuelle Leitfaden für Codex-Cloud-Umgebungen nennt Computer- und Browserbedienung ausdrücklich als nicht unterstützt. Er erklärt außerdem, dass Repository-Skills verfügbar sind, persönliche lokale Skills jedoch nicht synchronisiert werden.[5] Die Browserfähigkeit eines Dots kann deshalb nicht auch in seiner delegierten Entwicklungsumgebung vorausgesetzt werden.

Unsere praktische Schlussfolgerung: Teilen Sie die Arbeit an der Ressourcengrenze. Recherche in einem geeigneten Browser kann eine Quellenübersicht liefern. Eine Entwicklungsumgebung kann diese Übersicht verarbeiten und ein Repository verändern. Benötigt ein Schritt eine Desktop-Anwendung, wählen Sie eine Umgebung, die diese tatsächlich bereitstellt. Delegation sollte Anweisungen und Belege bewusst übertragen, statt den Übergang hinter dem Wort Cloud zu verstecken.

Lokale Arbeit: Den Ausgangszustand des Repositorys erhalten

OpenAI dokumentiert Einrichtungsskripte lokaler Umgebungen für neue Worktrees und wiederverwendbare Projektaktionen wie Testläufe.[6] Laut Worktree-Leitfaden bleiben Repository und Befehle auf dem Computer oder in der entfernten Entwicklungsumgebung, die das Projekt enthält.[7] Ein neuer Checkout ist ein Arbeitsplatz, kein Beleg dafür, dass Abhängigkeiten oder nicht eingecheckte Ressourcen bereitstehen.

Bei unserem hypothetischen Fehler ist lokale Ausführung sinnvoll, wenn die Reproduktion von installierten Werkzeugen oder Dateien des Entwicklers abhängt. Ein Worktree kann den Änderungsvorschlag von der laufenden Entwicklung trennen. Bitten Sie den ausführenden Agenten, seinen Checkout und die Ausgangsrevision zu benennen, damit der Prüfer weiß, welche Version getestet wurde. Wertvoll ist eine Änderung gegen eine bekannte Ausgangsbasis, keine frei schwebende Sammlung bearbeiteter Dateien.

Ein sinnvoller Auftrag sagt außerdem, was erhalten bleiben muss. Vorhandene Änderungen, generierte Dateien und projektspezifische Einrichtung können für das Ergebnis relevant sein. Klare Anweisungen ersparen der Koordination später eine vermeidbare Wiederherstellung.

Fernsteuerung: Das Telefon ist die Bedienoberfläche

Laut Remote-Leitfaden nutzt Fernzugriff die Dateien, Zugangsdaten, Berechtigungen und Werkzeuge des verbundenen Rechners und ermöglicht die Prüfung von Diffs und Testergebnissen.[8] Auch die Worktree-Dokumentation erklärt, dass Worktrees nicht auf dem Telefon laufen.[7] Mobiler Zugriff verändert die Steuerung der Arbeit; der Ausführungsort muss sich dadurch nicht ändern.

Die Dots-Dokumentation macht eine weitere Unterscheidung: Nach einem Cloud-Browser-Problem kann der Versuch auf einem verbundenen Computer eine separate lokale Aufgabe erstellen, ohne die Browsersitzung zu übertragen.[2] Betrachten Sie das als Arbeitsplatzwechsel. Eine Anmeldung oder offene Seite auf einem Rechner belegt nicht, was eine andere Aufgabe sehen kann.

Das ist für die Planung entscheidend. Halten Sie einen Rechner verfügbar, wenn eine Aufgabe von ihm abhängt, und verlangen Sie eine Statusmeldung mit dem ausführenden Host. Ist der lokale Schritt blockiert, kann ein nützlicher Koordinator weiterhin Quellenmaterial vorbereiten oder Anforderungen klären. Er sollte die Abhängigkeit melden, statt zu behaupten, der Fernzugriff habe sie beseitigt.

Aufgabenverantwortung: Kontext muss die Übergabe überstehen

Laut OpenAI haben delegierte Aufgaben eigene Gespräche, erhalten ausgewählte Anweisungen und Kontext und bleiben ihrem ursprünglichen Computer oder ihrer Cloud-Umgebung zugeordnet. Das Wechseln des beim Dot ausgewählten Computers verschiebt eine bestehende Aufgabe nicht.[3] Die Zuständigkeit folgt der Aufgabe, nicht dem zuletzt beim Koordinator ausgewählten Ort.

Unsere Empfehlung: Fordern Sie eine kurze Ausführungsübersicht mit Aufgabenkennung, Arbeitsort, vorgesehenem Ergebnis und aktuellem Hindernis an. Verwenden Sie sie für Folgeanweisungen. „Arbeite weiter“ ist bei mehreren Aufgaben mehrdeutig; „Setze die Fehlerkorrektur im bestehenden Repository fort und wiederhole den Regressionstest“ ist ausführbar.

Für die Steuerung gilt dieselbe Logik. Die Dots-Kontrollen von OpenAI unterscheiden zwischen dem Pausieren der Hauptaufgabe, dem Stoppen delegierter Arbeit und dem Abbrechen eines Zeitplans.[9] Prüfen Sie bei veränderten Prioritäten die tatsächlichen Aufgaben. Ein stiller Koordinator beweist nicht, dass alle ausführenden Agenten angehalten wurden.

Abnahme: Der Arbeit bis zum Ergebnis folgen

Die Dokumentation der Desktop-App betont die Prüfung tatsächlicher Dateien. Der Dots-Aufgabenleitfaden warnt davor, einen abgeschlossenen Lauf als Beleg für die Lieferung zu verstehen.[10][3] Das ist der Verantwortlichkeitstest für dieses gesamte Zusammenspiel.

Fordern Sie für das Bezahlbeispiel den Diff, das relevante Testergebnis und eine reproduzierbare Demonstration an. Für einen Bericht sind es das gespeicherte Dokument und Quellennotizen. Für eine Analyse sind es das Eingabezeitfenster, die Berechnung und eine prüfbare Tabelle. Das sind redaktionelle Beispiele für Abnahmebelege, keine Behauptungen, dass das Produkt jeden dieser Belege automatisch erzeugt.

ACHTUNG

Abschluss ist eine zu prüfende Aussage

Unsere Empfehlung: Stellen Sie fest, wo das Ergebnis gespeichert wurde, öffnen Sie es und prüfen Sie es anhand des Auftrags. Die Zusammenfassung des Koordinators, der Abschlussstatus des ausführenden Agenten und ein nutzbares Ergebnis sind getrennte Belege.

Die entscheidende Entwicklung ist nicht, dass Dots Codex ersetzen. Eine Koordinationsschicht macht die Ausführung leichter steuerbar. Der Vorteil liegt bei Teams, die wissen, wo Arbeit läuft, und an ihrem Ende Belege verlangen.

Quellen

Zum Lesen aller Spalten seitlich scrollen.

Nr.QuelleAnbieterDatumBeitrag
1Mit dem Dot beginnenOpenAIAbgerufen 05.10.2026Delegation an Work und Codex, Prüfung über Activity.
2Computer und Apps verbindenOpenAIAbgerufen 05.10.2026Getrennte Ressourcen für Cloud-Browser und lokale Aufgaben.
3Dots: Aufgaben und GedächtnisOpenAIAbgerufen 05.10.2026Aufgabenkontext, ursprüngliche Umgebung und Grenzen des Abschlussstatus.
4Codex CloudOpenAIAbgerufen 05.10.2026Konfigurierte Projektumgebungen und getrennte Aufgabenarbeitsbereiche.
5Cloud-UmgebungenOpenAIAbgerufen 05.10.2026Aktuelle Browsergrenzen sowie Repository-Skills und lokale Skills.
6Lokale UmgebungenOpenAIAbgerufen 05.10.2026Einrichtungsskripte für Worktrees und Projektaktionen.
7Git-WorktreesOpenAIAbgerufen 05.10.2026Repository und Ausführung bleiben auf dem Projektrechner.
8FernverbindungenOpenAIAbgerufen 05.10.2026Fernzugriff auf Host-Werkzeuge und Prüfergebnisse.
9Den Dot steuernOpenAIAbgerufen 05.10.2026Pause, Stopp delegierter Aufgaben und Zeitplanabbruch unterscheiden sich.
10ChatGPT-Desktop-AppOpenAIAbgerufen 05.10.2026Dateien im Desktop-Arbeitsbereich erstellen und prüfen.

Zuletzt aktualisiert: 5. Oktober 2026