ChatGPT und Codex stammen für mich zwar aus derselben technologischen Welt, trotzdem benutze ich sie inzwischen sehr unterschiedlich. Ich könnte versuchen, möglichst viele Aufgaben direkt in Codex zu erledigen oder umgekehrt jede Idee zuerst ausführlich in ChatGPT zu diskutieren, aber in der Praxis hat sich eine klare Trennung für mich als deutlich sinnvoller erwiesen.
ChatGPT ist für mich vor allem der Ort, an dem ich denke, hinterfrage, Varianten diskutiere und Entscheidungen vorbereite. Codex kommt danach ins Spiel, wenn aus einer Idee konkrete technische Arbeit werden soll.
Diese Trennung ist nicht von Anfang an so geplant gewesen. Sie hat sich aus meiner täglichen Arbeit ergeben, weil ich gemerkt habe, dass beide Werkzeuge ihre Stärken an unterschiedlichen Stellen des Prozesses haben und ich bessere Ergebnisse bekomme, wenn ich sie nicht wie austauschbare Chatfenster behandle.
ChatGPT beginnt dort, wo die Idee noch unscharf ist
Größere Themen beginnen bei mir häufig mit einer zunächst groben Idee in ChatGPT. Zu diesem Zeitpunkt weiß ich oft ziemlich genau, welches Problem ich lösen möchte, aber noch nicht, wie das fertige Ergebnis in jedem Detail aussehen soll.
Genau dann ist ChatGPT für mich besonders hilfreich.
Ich kann eine Idee beschreiben, ohne bereits sämtliche Entscheidungen getroffen zu haben, und sie anschließend Schritt für Schritt auseinandernehmen lassen. Dabei interessieren mich nicht nur Antworten, sondern vor allem Fragen.
Was passiert in einem Sonderfall?
Welche Daten müssen dauerhaft gespeichert werden?
Welche Entscheidung habe ich bisher nur stillschweigend vorausgesetzt?
Was passiert, wenn ein Vorgang unterbrochen wird?
Welche spätere Erweiterung könnte eine heutige Architekturentscheidung beeinflussen?
Je länger ein solches Gespräch läuft, desto deutlicher wird meistens, welche Teile einer Idee tatsächlich bereits klar waren und welche nur deshalb klar wirkten, weil ich sie selbst noch nicht kritisch hinterfragt hatte.
Ich möchte in dieser Phase noch keinen Code
Gerade bei größeren Themen halte ich es inzwischen für einen Fehler, zu früh über konkrete Implementierungsdetails zu sprechen.
Wenn ich noch nicht entschieden habe, wie sich ein Produkt fachlich verhalten soll, hilft mir eine Diskussion über Klassen, Datenbanken oder Frameworks nur begrenzt. Im ungünstigsten Fall lenkt die erste technische Lösung sogar die weiteren Produktentscheidungen, obwohl eigentlich die Technik dem gewünschten Verhalten folgen sollte.
Deshalb versuche ich, ChatGPT in dieser Phase bewusst auf der Konzeptseite zu halten.
Natürlich können technische Randbedingungen eine Rolle spielen. Wenn eine Idee aufgrund vorhandener Systeme, Sicherheitsanforderungen oder anderer Abhängigkeiten bestimmte Grenzen besitzt, muss ich diese berücksichtigen. Trotzdem möchte ich zunächst verstehen, was entstehen soll, bevor ich mich darauf festlege, wie es umgesetzt wird.
Diese Trennung fällt mir mit ChatGPT leichter, weil dort kein Repository darauf wartet, sofort verändert zu werden.
Aus dem Gespräch entsteht irgendwann eine Spezifikation
Wenn ein Thema ausreichend weit geklärt ist, lasse ich aus dem Gespräch eine strukturierte Markdown-Datei erzeugen.
Das ist für mich ein wichtiger Übergangspunkt.
Die Datei enthält nicht einfach das komplette Gespräch in chronologischer Reihenfolge. Stattdessen wird aus vielen Fragen, Antworten, Korrekturen und Entscheidungen eine zusammenhängende Spezifikation, die beschreibt, welches Ziel erreicht werden soll, welche fachlichen Regeln gelten, welche Grenzen bestehen und welche offenen Punkte noch übrig sind.
Damit bekommt das Ergebnis eine Form, die sich an ein anderes Werkzeug übergeben lässt.
Und genau hier beginnt für mich die Arbeit mit Codex.
Codex bekommt die Idee erst, wenn sie ausreichend konkret ist
Codex arbeitet in meinem Prozess näher an der Realität des vorhandenen Projekts.
Während ChatGPT mit mir diskutiert, was ich eigentlich haben möchte, kann Codex anschließend prüfen, wie sich dieses Ziel technisch in den bestehenden Code integrieren lässt.
Das ist ein entscheidender Unterschied.
Eine Spezifikation kann fachlich vollständig sinnvoll sein und trotzdem technische Konsequenzen haben, die im vorherigen Gespräch gar nicht sichtbar waren. Vielleicht existiert bereits eine ähnliche Funktion. Vielleicht muss eine gemeinsame Komponente verändert werden. Vielleicht würde die naheliegende Lösung gegen eine bestehende Architekturentscheidung verstoßen.
Codex kann diese Zusammenhänge direkt im Repository untersuchen.
Deshalb möchte ich an dieser Stelle keine zweite abstrakte Konzeptdiskussion, sondern eine technische Übersetzung meiner vorherigen Entscheidungen.
Codex darf technische Entscheidungen treffen
Diese Trennung bedeutet nicht, dass ich jede einzelne technische Entscheidung vorher in ChatGPT festlege.
Im Gegenteil.
Wenn Codex bei der Umsetzung zwischen zwei gleichwertigen internen Lösungen entscheiden muss und sich aus der vorhandenen Architektur klar ergibt, welche besser passt, darf es diese Entscheidung selbst treffen.
Ich möchte nicht vor jeder kleinen Implementierungsfrage erneut eine Grundsatzdiskussion beginnen.
Die Grenze liegt für mich eher dort, wo eine technische Entscheidung das fachliche Verhalten verändert.
Wenn eine Frage lautet, ob eine bestimmte Hilfsmethode intern auf die eine oder andere Weise aufgebaut wird, interessiert mich das häufig nur begrenzt.
Wenn die Entscheidung dagegen beeinflusst, was ein Benutzer tun darf, welche Daten gespeichert werden oder wie sich ein Produkt in einer bestimmten Situation verhält, ist das keine reine Implementierungsfrage mehr.
Dann möchte ich wieder selbst entscheiden.
Codex ist damit nicht einfach der ausführende Teil von ChatGPT
So einfach ist die Trennung allerdings auch nicht.
Codex soll nicht blind eine Markdown-Datei abarbeiten.
Es muss die Spezifikation gegen das reale Projekt prüfen und darf dabei durchaus feststellen, dass eine Annahme aus der Konzeptphase technisch nicht passt oder dass eine vorhandene Struktur eine andere Lösung nahelegt.
In diesem Fall entsteht eine Rückkopplung.
Das Konzept kommt wieder zurück.
Ich treffe eine neue Entscheidung.
Die Spezifikation wird angepasst.
Erst danach geht die Umsetzung weiter.
Damit entsteht kein starrer Übergabeprozess, bei dem ChatGPT irgendwann „fertig“ ist und Codex anschließend nur noch ausführt. Beide Bereiche können mehrfach durchlaufen werden.
Der Unterschied besteht darin, welche Art von Problem ich jeweils wo lösen möchte.
Agenda schafft noch eine weitere Trennung
Bei größeren Themen endet die Arbeit mit Codex inzwischen nicht zwingend direkt im Quellcode.
Mit Agenda habe ich eine zusätzliche Ebene zwischen Planung und konkreter Ausführung geschaffen. Codex kann ein umfangreiches Konzept analysieren und daraus mehrere sinnvoll getrennte Aufgaben ableiten, die anschließend in Agenda gespeichert werden.
Damit entsteht eine interessante Staffelung.
ChatGPT hilft mir, die Idee fachlich auszuarbeiten.
Codex übersetzt diese Idee in technische Arbeit.
Agenda hält fest, welche Aufgaben daraus entstanden sind, welche voneinander abhängen und welche überhaupt ausgeführt werden dürfen.
Erst danach übernimmt Codex wieder die eigentliche Umsetzung einer freigegebenen Aufgabe.
Dass Codex an zwei Stellen auftaucht, ist dabei kein Widerspruch. Im ersten Schritt arbeitet es eher analysierend und planend am Repository, im zweiten Schritt setzt es eine bereits klar abgegrenzte Aufgabe um.
Mehrere Chats machen die Trennung noch nützlicher
Ich arbeite inzwischen häufig mit mehreren ChatGPT- und Codex-Arbeitssträngen parallel. Gerade dabei hilft mir die klare Rollenverteilung.
Ein ChatGPT-Gespräch kann ein neues Konzept entwickeln, während Codex ein bereits ausgearbeitetes Thema analysiert. Gleichzeitig kann eine andere Codex-Arbeit eine freigegebene Agenda-Aufgabe umsetzen.
Dadurch laufen verschiedene Phasen derselben grundsätzlichen Arbeitsweise gleichzeitig, ohne dass ich jedes Thema selbst vollständig nacheinander abarbeiten muss.
Für mich ist das inzwischen einer der größten Vorteile der gesamten KI-gestützten Arbeitsweise.
Nicht nur eine einzelne Aufgabe wird schneller.
Mehrere unterschiedliche Phasen können gleichzeitig weiterlaufen.
ChatGPT kennt dafür nicht automatisch meinen Code
Die Trennung hat natürlich auch Nachteile.
ChatGPT kennt nicht automatisch den vollständigen Stand meines Repositories. Wenn ich eine technische Annahme im Konzept treffe, kann sie falsch oder veraltet sein.
Deshalb möchte ich ChatGPT nicht so behandeln, als hätte es jederzeit vollständiges Projektwissen.
Gerade bei größeren Projekten muss Codex anschließend prüfen, ob das Konzept tatsächlich zur vorhandenen Struktur passt.
Das ist für mich eine wichtige Sicherheitsstufe.
Die Konzeptphase darf kreativ und offen sein. Die technische Planung muss anschließend wieder auf dem tatsächlichen System aufsetzen.
Codex kennt dafür nicht automatisch meine gesamte Diskussion
Umgekehrt besitzt Codex nicht automatisch all die Überlegungen, die zu einer bestimmten Entscheidung geführt haben.
Wenn ich nur das Endergebnis übergebe, fehlt möglicherweise der Kontext, warum eine bestimmte Anforderung so wichtig ist oder warum eine scheinbar einfachere Alternative bewusst verworfen wurde.
Genau deshalb wird die Qualität der Markdown-Spezifikation für mich immer wichtiger.
Sie muss nicht jede einzelne Frage aus dem vorherigen Chat enthalten, aber sie sollte die Entscheidungen so dokumentieren, dass Codex nicht wieder dieselben Grundsatzfragen neu beantworten muss.
Je besser diese Übergabe funktioniert, desto weniger Informationen gehen zwischen den beiden Werkzeugen verloren.
Für mich ist die Trennung inzwischen ein fester Bestandteil der Arbeitsweise
Ich könnte wahrscheinlich vieles direkt in einem einzigen System erledigen.
Das wäre auf den ersten Blick einfacher.
In meiner Praxis gefällt mir die bewusste Trennung trotzdem besser, weil sie mich zwingt, unterschiedliche Arten von Arbeit nicht miteinander zu vermischen.
In ChatGPT darf eine Idee noch unfertig sein.
Dort darf ich Varianten ausprobieren, Entscheidungen zurücknehmen und mich hundert Fragen lang mit einem Detail beschäftigen.
Wenn das Ergebnis anschließend zu Codex geht, sollte dagegen deutlich klarer sein, welches Ziel tatsächlich erreicht werden soll.
Codex darf dann herausfinden, wie dieses Ziel innerhalb des vorhandenen technischen Systems sinnvoll umgesetzt wird.
Für mich sind ChatGPT und Codex deshalb keine zwei Oberflächen für dieselbe Aufgabe.
Sie markieren zwei unterschiedliche Denkebenen meiner Arbeit.
Und je stärker ich meine Prozesse automatisiere, desto wichtiger wird genau diese Unterscheidung.