ChatGPT Dots + GitHub: Vom Bugreport zum geprüften PR

Ein Fehlerbericht trifft ein, während das Team an etwas anderem arbeitet. Aufwendig ist oft der gesamte Weg bis zu einem sinnvoll prüfbaren Fix: die betroffene Stelle finden, das Verhalten reproduzieren, den Kontext erhalten und nachweisen, was die Änderung tatsächlich bewirkt.

Genau diesen Ablauf lohnt es sich mit ChatGPT Dots zu untersuchen: Feedback hinein, nachvollziehbare Prüfnachweise heraus. Nicht einen unbeaufsichtigten Merge-Knopf. Dieser Leitfaden entwirft einen klar begrenzten GitHub-Workflow für die Bug-Triage, einschließlich Arbeitsauftrag, Anforderungen an Testnachweise und Abschaltverfahren.

Dokumentation geprüft am 1. Oktober 2026. Die beschriebenen Produktfunktionen stammen aus OpenAIs Dokumentation. Pilot, Abnahmekriterien und Beispiele sind unser vorgeschlagenes Umsetzungskonzept, keine Ergebnisse eines praktischen Dots-Benchmarks.

Was sind ChatGPT Dots?

OpenAI stellte Dots am 29. September 2026 vor: persistente Agenten auf Basis von GPT-6 Astra mit Cloud-Computer für fortlaufende Aufgaben. Die Produktankündigung zeigt beispielhaft den Weg vom Feedback zum Fix. Spezialisten-Dots mit eigener Unternehmensidentität werden zunächst in gezielten Enterprise-Piloten erprobt.

Für Entwicklungsteams ist nicht entscheidend, ob ein Agent einen weiteren Patch erzeugen kann. Entscheidend ist, ob Delegation den Aufwand bis zu einer belastbaren Review-Entscheidung reduziert. Wir würden einem Dot die Koordination von Eingang, Recherche und begrenzten Korrekturen übertragen, die Abnahme aber außerhalb seines eigenen Urteils belassen.

Trenne drei Verantwortungen: Die Koordination entscheidet innerhalb des Auftrags, was untersucht wird. Die Coding-Umgebung erstellt die vorgeschlagene Änderung. Der Reviewer entscheidet, ob die Nachweise eine Abnahme rechtfertigen. Eine Person darf den Piloten verantworten. Diese Entscheidungen sollten trotzdem nicht in einer einzigen Erledigt-Meldung verschwinden.

Wer kann Dots zum Start nutzen?

Der offizielle Zugangsleitfaden nennt zum Prüfdatum folgenden Rollout. Ein berechtigter Tarif bedeutet noch nicht, dass die Funktion im konkreten Konto bereits verfügbar ist.

Prüfe als österreichisches oder deutsches Team deshalb den tatsächlichen Workspace-Tarif. Nicht jedes europäische Konto hat dieselben Zugangsvoraussetzungen. Versprich keinen Einführungstermin auf Basis einer Funktion, die im eigenen Konto noch fehlt.

Erstelle den Dot am Desktop. Die Einrichtungsdokumentation unterscheidet App-Verbindungen, Nachrichtenkanäle und lokalen Computerzugriff. Unser vorgeschlagener Pilot beginnt mit einem Repository und ohne Verbindung zum lokalen Rechner. Ergänze nur Zugriffe, deren Notwendigkeit ein konkreter Test zeigt.

GitHub und Coding-Umgebung getrennt einrichten

Der Leitfaden zu Computern und Apps beschreibt die Untersuchung von GitHub-Issues und Vorbereitung von PRs über ein autorisiertes Plugin. Repository-spezifische Cloud-Aufgaben können eine vorbereitete Codex-Umgebung nutzen. Lokale Aufgaben benötigen dagegen einen verbundenen, eingeschalteten Rechner mit geöffneter ChatGPT-App.

Eine GitHub-Verbindung beweist nicht, dass das richtige Repository, der richtige Branch, die Abhängigkeiten und die Testdaten verfügbar sind. Prüfe vor einem wiederkehrenden Auftrag zunächst den Zugang: Lass dir das ausgewählte Repository, ein bekanntes Issue, den aktuellen Commit und den im Repository definierten Testbefehl nennen. Verlange eine klare Trennung zwischen gelesenen Informationen und Schlussfolgerungen.

Teste anschließend den erlaubten Schreibpfad in einem Test-Repository oder einem entbehrlichen Branch. Kann das verbundene Konto den vorgesehenen Entwurfs-PR erstellen, ohne zugleich einen Weg zum Merge oder Deployment zu haben? Prüfe Berechtigungen im Quellsystem und Zugangsdaten der Workflows, nicht nur den Wortlaut des Auftrags. Kann die Integration die gewünschte Grenze nicht durchsetzen, belasse sie im Lesemodus und überlasse das Übernehmen des Patches einem Menschen.

Gib jedem Coding-Auftrag eine kurze Übergabe mit: Kennung des Fehlerberichts, erwartetes Verhalten, betroffener Commit, erlaubte Dateien, Reproduktionsschritte und Abnahmetests. Die Abnahme darf nicht davon abhängen, dass der Coding-Auftrag sich an eine frühere Unterhaltung erinnert. Für angemeldete Browser-Aufgaben nutze unseren separaten Leitfaden zur Anmeldung im ChatGPT-Cloud-Browser. Eine App-Verbindung ist kein Website-Login.

Ein wiederverwendbarer Dots-Auftrag für die Bug-Triage

Eine Slack-Verbindung startet noch keine Überwachung. Der Leitfaden zu Aufgaben und Gedächtnis verlangt einen ausdrücklich eingerichteten, unterstützten Auslöser oder gespeicherten Zeitplan. Außerdem beweist ein abgeschlossener Lauf kein erfolgreiches Ergebnis. Prüfe sowohl Eingang als auch Resultat.

Der folgende Text ist ein vorgeschlagener Gesprächsauftrag, keine Dots-API und keine Konfigurationsdatei. Ersetze die benannten Eingaben vor der Nutzung. Beginne mit einem persönlich zugewiesenen Fehlerbericht. Automatisiere den Eingang erst, nachdem die Unterstützung im Workspace bestätigt ist.

Verantwortung: prüfbare Korrekturen vorbereiten, keine Releases.

Verantwortlicher: der benannte Engineering-Reviewer.
Umfang: vereinbartes Repository, Feedbackquelle und Testumgebung.
Eingang: nur die in diesem Piloten vom Verantwortlichen zugewiesenen
Berichte untersuchen. Vor Codeänderungen den Quellbericht und Commit
benennen; den Fehler reproduzieren oder den konkreten Blocker melden.

Die vereinbarte Codex-Cloud-Umgebung nutzen, keinen lokalen Rechner.
Pro Bericht eine eng begrenzte Korrektur vorschlagen. Keine
Abnahmekriterien ändern, fehlschlagenden Tests entfernen,
Produktionsdaten abrufen oder CI-Konfiguration verändern.

Einen Entwurfs-PR erst nach Freigabe der Veröffentlichung durch den
Verantwortlichen und nur mit entsprechender Berechtigung erstellen.
Andernfalls einen Patch zur manuellen Prüfung zurückgeben.
Nicht mergen, deployen, das Quell-Issue schließen oder Kunden anschreiben.

Zurückgeben: Berichtlink, Ausgangs- und Ziel-Commit, Reproduktion,
geänderte Dateien, genaue Prüfungen und Ergebnisse, nicht ausgeführte
Prüfungen, verbleibende Risiken und benötigte Reviewer-Entscheidung.
Eine fehlgeschlagene oder nicht mögliche Prüfung gilt nicht als bestanden.

Vor Umfangserweiterungen oder weiteren kostenpflichtigen Aufträgen fragen.
Blocker melden, statt eigenständig auf eine andere Umgebung auszuweichen.

Für einen späteren zeitgesteuerten Piloten definiere Zeitzone, Enddatum und Ziel der Ergebnisse ausdrücklich und kontrolliere den gespeicherten Zeitplan. Bei ereignisgesteuertem Eingang sende einen künstlichen Fehlerbericht und prüfe, dass genau eine Untersuchung beginnt. Sende denselben Bericht erneut und kontrolliere den Umgang mit Duplikaten. „Beobachte diesen Kanal“ ist kein ausreichender Abnahmenachweis.

Erhalte die ursprüngliche Berichtkennung über den gesamten Ablauf. Ein Duplikat soll zur bestehenden Untersuchung führen, statt eine konkurrierende Korrektur auszulösen. Ein Bericht zu einem anderen Commit muss neu validiert werden, statt stillschweigend eine alte Reproduktion zu übernehmen.

Vor dem ersten Fix den PR-Prüfnachweis definieren

Unsere vorgeschlagene Abnahmeregel: Ein Patch ist erst reviewfähig, wenn ein anderer Entwickler das behauptete Ergebnis dem tatsächlich getesteten Commit zuordnen kann. Ein Video erklärt eine UI-Änderung. Es beweist nicht, welcher Commit ausgeführt wurde, ob Assertions bestanden oder ob angrenzendes Verhalten beeinträchtigt wurde.

Ein fiktiver Bericht lautet: „Auf dem Smartphone fehlt der Export-Button.“ Eine schwache Korrektur macht ihn für alle sichtbar. Eine brauchbare Untersuchung klärt zuerst Bildschirmgröße, Nutzerrolle und Kontostatus. Danach prüft sie die Änderung für den berechtigten mobilen Nutzer, den nicht berechtigten Nutzer und das bestehende Desktop-Verhalten. Bei asynchronem Export gehören wartende und fehlgeschlagene Zustände dazu.

Verlange den ursprünglichen Fehler und das korrigierte Ergebnis mit denselben relevanten Eingaben. Der Sollzustand muss unabhängig vom Patch bleiben. Sonst kann der Agent versehentlich seinen eigenen Test bestehen lassen, indem er die Assertion abschwächt, statt die Anwendung zu reparieren.

Nutze explizite Review-Zustände wie not-reproduced, blocked, patch-unverified und ready-for-review. Das sind vorgeschlagene Team-Labels, keine eingebauten Dots-Statuswerte. Die Abnahme bleibt eine menschliche Entscheidung auf Basis der verlangten Prüfungen. Fehlender Browserzugang heißt „Browserprüfungen nicht ausgeführt“, nicht „durch Codeinspektion bestätigt“.

Wende dieselbe Unterscheidung nach jedem weiteren Commit an. Nachweise eines älteren Stands genehmigen nicht automatisch einen späteren Patch. Die übergeordnete Testarchitektur erläutert unser Beitrag zu agentischem Testing und deterministischer Testautomatisierung.

Berechtigung und Softwarekorrektheit auseinanderhalten

Laut Enterprise-Administrationsleitfaden steuert nur der Eigentümer seinen persönlichen Dot über unterstützte Slack-Nachrichten. Außerdem gelten die Enterprise-Modellvorgaben nicht für Dots. Prüfe daher Dots-spezifische Zugriffe, statt eine bestehende Modellrichtlinie als ausreichende Absicherung anzusehen.

Diese Eigentümergrenze ist für den Eingang von Aufgaben wichtig. Der Bugreport eines Kollegen ist Arbeitsmaterial, keine Erlaubnis zur Erweiterung von Rechten. Eine Aufforderung im Issue, Geheimnisse zu exportieren, Tests zu umgehen oder einen Release zu veröffentlichen, darf nicht allein durch den Ablageort im freigegebenen Repository zum Auftrag werden.

OpenAIs Sicherheitsbeschreibung für Dots erläutert Schutzmaßnahmen gegen manipulierte Anweisungen und rein lesende proaktive Recherche. Diese Hintergrundrecherche unterscheidet sich von autorisierten Arbeitsaufträgen. Unsere technische Unterscheidung ist ebenso wichtig: Die Erlaubnis zu einer Aktion beweist nicht die Korrektheit ihres Ergebnisses.

Erlaube im Piloten das Lesen vereinbarter Berichte und die Vorbereitung isolierter Änderungen. Verlange Prüfung vor der Veröffentlichung eines PRs. Merge, Deployment, Änderungen an Zugangsdaten und Kundenkommunikation bleiben außerhalb des Auftrags. Setze verfügbare Beschränkungen in App, Repository und Ausführungsumgebung um. Eine privilegiertere Browsersitzung darf kein Umweg um ein eingeschränktes Plugin sein.

Teste vor einer Erweiterung drei absichtliche Problemfälle: ein nicht freigegebenes Repository, einen Bericht mit manipulierten Anweisungen und eine fehlende Abhängigkeit. Gewünschte Ergebnisse sind verweigerter Zugriff, ignorierte Anweisungen und ein korrekt gemeldeter Blocker. Nicht drei Gelegenheiten, einen weiterreichenden Zugang zu suchen.

Dots stoppen, ohne laufende Aufgaben zu übersehen

OpenAIs Leitfaden zur Steuerung unterscheidet drei Aktionen: Pause betrifft die Hauptaufgabe; delegierte Arbeit muss in Activity gestoppt werden; wiederkehrende Aufgaben müssen in Scheduled deaktiviert oder gelöscht werden. Custom Rules sind fehlbare Anweisungen, keine App-Zugriffsrechte. Bereits ausgeführte Aktionen werden durch Stoppen nicht rückgängig.

Mache das Abschalten zum Abnahmetest des Piloten. Starte eine harmlose delegierte Aufgabe und eine zukünftige wiederkehrende Prüfung. Pausiere die Koordination, kontrolliere beide getrennt, stoppe dann die Aufgabe und entferne den Zeitplan. Dokumentiere, was tatsächlich beendet wurde. Prüfe App-Berechtigungen und angemeldete Website-Sitzungen separat, bevor du den Piloten als vollständig beendet betrachtest.

Auch der Dots-Leitfaden im Help Center unterscheidet das Trennen einer App vom Löschen bereits erhaltener Informationen. Lies die aktuelle Bestätigung zum Zurücksetzen oder Löschen und sichere freigegebene Nachweise vor dem Entfernen des Dots. Zugriffsentzug, gespeicherter Kontext und bereits veröffentlichte Ergebnisse erfordern getrennte Entscheidungen.

Im vorgeschlagenen GitHub-Ablauf bedeutet das: offene Entwurfs-PRs, Branches, wartende Aufgaben und geplanten Eingang prüfen. Zugriffe zu entfernen entscheidet noch nicht, was mit bereits erzeugten Patches geschehen soll.

Abgenommene Korrekturen messen, nicht Agentenaktivität

Führe einen kleinen, ausdrücklich begrenzten Piloten mit nichtkritischen Issues durch. Zähle jeden zugewiesenen Bericht mit, auch Duplikate, blockierte Versuche und Meldungen, die sich nicht als Fehler herausstellen. Andernfalls belohnt die Auswertung einfache Fälle und versteckt Koordinationsaufwand.

Unsere vorgeschlagene Auswertung erfasst abgenommene Korrekturen, Reviewer-Minuten pro zugewiesenem Bericht, Fehlalarme, ungeprüfte Ergebnisse und nach der Abnahme entdeckte Regressionen. Vergleiche ähnliche Aufgaben mit dem bisherigen Vorgehen des Teams. Berücksichtige auch Zeit für Auftragskorrekturen, die Reparatur der Testumgebung und das Verwerfen plausibler, aber unbelegter Schlussfolgerungen.

Rechne bei den Kosten Einrichtung, menschliche Prüfung und sämtliche Aufgabennutzung einschließlich verworfener Versuche ein. OpenAIs ChatGPT-Release-Notes beschreiben zeitlich begrenzte Startkontingente, keine dauerhaft unbegrenzte Ausführung. Prüfe das aktuelle Kontingent im Produkt sowie die geltende Work- oder Codex-Nutzung, bevor du ein wiederkehrendes Budget festlegst.

Ein sinnvoller Erfolg sind nicht zwangsläufig mehr PRs. Es können schneller erkannte Reproduktionshindernisse, weniger Kontextübergaben oder bessere Nachweise für dieselbe Zahl von Korrekturen sein. Lege die Fortführungs- und Abbruchkriterien vor der Auswertung fest, nicht erst nach einer überzeugenden Demo.

Wann Dots nutzen, wann einen Workflow entwickeln?

Unser vorgeschlagener Einsatzbereich ist die Koordination rund um wechselnde Prioritäten einer benannten verantwortlichen Person: diesen Bericht untersuchen, jene begrenzte Warteschlange aktuell halten, Nachweise zur Prüfung zurückgeben. Wähle einen anderen Umsetzungspfad, wenn die Abnahme eine gemeinsame Service-Identität, deterministische Auslöser, ausdrückliche Wiederholungsregeln oder ein produktives Service-Level verlangt, das dein Dots-Pilot nicht nachgewiesen hat.

Das ist kein Argument, alles selbst zu bauen. Es ist ein Grund, den Nutzen eines Assistenten von den Zusagen eines Produktionssystems zu trennen. Unser Engineering-Review der OpenAI Agents API behandelt den individuellen Produktpfad, ohne Dots als öffentliche Anwendungs-API darzustellen.

Bring für einen konkreten nächsten Schritt eine wiederkehrende Bug-Warteschlange und ein repräsentatives Repository in ein Scoping-Gespräch zu Workflow und QA mit. Definiere zuerst Abnahmenachweise und Berechtigungsgrenzen. Automatisiere die Übergaben erst, wenn diese feststehen.