ChatGPT und Codex erfüllen in meiner heutigen Arbeitsweise bewusst unterschiedliche Aufgaben. ChatGPT nutze ich vor allem für Konzeptarbeit, während Codex näher an der technischen Umsetzung arbeitet. Diese Trennung funktioniert für mich sehr gut, erzeugt aber gleichzeitig ein Problem, das mit wachsenden Projekten immer deutlicher wird: Beide Systeme kennen unterschiedliche Teile derselben Geschichte.
ChatGPT kennt die Diskussion, aus der ein Konzept entstanden ist. Dort wurden vielleicht über Stunden oder sogar mehrere Gespräche hinweg Fragen beantwortet, Varianten verworfen, Sonderfälle betrachtet und Entscheidungen getroffen. Codex kennt dagegen das tatsächliche Repository, die vorhandene Architektur und den aktuellen technischen Zustand des Projekts.
Für eine gute Umsetzung brauche ich beides.
Die eigentliche Herausforderung besteht deshalb nicht nur darin, ein gutes Konzept zu entwickeln oder Codex ausreichend Zugriff auf den Code zu geben. Ich muss eine zuverlässige Verbindung zwischen beiden Ebenen schaffen.
ChatGPT kennt das Warum
Wenn ich ein größeres Thema mit ChatGPT erarbeite, entsteht weit mehr Kontext, als am Ende in einer kurzen Aufgabenbeschreibung stehen könnte. Eine einzelne Entscheidung kann beispielsweise erst nach zehn vorherigen Fragen sinnvoll geworden sein, weil unterschiedliche Alternativen ausgeschlossen wurden oder sich während des Gesprächs neue Randbedingungen ergeben haben.
Das macht ChatGPT für meine Konzeptarbeit so wertvoll. Ich kann eine zunächst grobe Idee sehr ausführlich hinterfragen lassen, ohne sofort in technischen Details zu landen, und dabei schrittweise herausfinden, was ich eigentlich bauen möchte.
Am Ende weiß ChatGPT deshalb häufig sehr gut, warum eine bestimmte Entscheidung gefallen ist.
Vielleicht soll eine Funktion ausdrücklich nicht automatisch handeln, obwohl das technisch möglich wäre. Vielleicht wurde eine scheinbar einfachere Variante bewusst verworfen, weil sie später eine wichtige Erweiterung erschweren würde. Vielleicht soll ein bestimmter Wert lieber als unbekannt angezeigt werden, statt eine wahrscheinlich richtige Schätzung zu liefern.
Solche Entscheidungen sind fachlich wichtig, aber im späteren Code nicht zwangsläufig offensichtlich.
Codex kennt dafür das tatsächliche Projekt
Codex besitzt wiederum einen Vorteil, den ChatGPT in meiner Konzeptphase normalerweise nicht hat: Es kann das Repository analysieren und sehen, wie das Projekt tatsächlich aufgebaut ist.
Eine fachlich gute Idee kann auf eine technische Realität treffen, die im vorherigen Gespräch nicht vollständig berücksichtigt wurde. Vielleicht existiert bereits eine ähnliche Funktion, die wiederverwendet werden sollte. Vielleicht hängt eine Änderung an mehreren Modulen oder gemeinsamen Komponenten. Vielleicht wurde die Architektur seit der letzten Konzeptdiskussion verändert.
Deshalb möchte ich Codex nicht einfach eine fertige Lösung diktieren.
Ich gebe ihm das fachliche Ziel und die wichtigen Rahmenbedingungen, erwarte aber gleichzeitig, dass es diese gegen den tatsächlichen Projektstand prüft.
Genau an dieser Stelle treffen zwei unterschiedliche Arten von Wissen aufeinander: das konzeptionelle Wissen aus ChatGPT und das technische Wissen aus dem Repository.
Die Markdown-Datei ist heute meine wichtigste Brücke
Der wichtigste Übergabemechanismus zwischen beiden Systemen ist bei mir derzeit eine strukturierte Markdown-Datei.
Wenn die Konzeptarbeit ausreichend weit fortgeschritten ist, lasse ich aus dem Gespräch keine einfache Zusammenfassung erzeugen, sondern eine Spezifikation, die Codex tatsächlich als Arbeitsgrundlage verwenden kann. Darin stehen nicht sämtliche Fragen und Antworten des vorherigen Chats, sondern die Entscheidungen, die nach der Diskussion gelten sollen.
Ausführliche Spezifikationen sind für mich gerade deshalb wieder attraktiver geworden, weil sie nicht mehr nur Dokumentation für später sind. Sie übertragen Wissen von einer KI-gestützten Arbeitsphase in die nächste.
Die Datei muss dabei einen schwierigen Mittelweg treffen. Wenn sie zu knapp ist, fehlen wichtige Gründe und Abgrenzungen. Wenn sie dagegen jedes verworfene Detail der gesamten Diskussion enthält, wird es für Codex schwieriger, den tatsächlich verbindlichen Stand zu erkennen.
Das Ziel ist also nicht maximale Länge, sondern möglichst wenig Informationsverlust.
Nicht jede Begründung gehört in die Übergabe
Eine Entscheidung kann im Chat sehr lange diskutiert worden sein, ohne dass Codex den vollständigen Weg dorthin kennen muss.
Wenn beispielsweise fünf mögliche Varianten betrachtet wurden und am Ende eindeutig feststeht, welche davon verwendet werden soll, reicht häufig die gewählte Variante zusammen mit den wirklich relevanten Gründen und Abgrenzungen.
Anders sieht es aus, wenn eine verworfene Alternative später sehr naheliegend erscheinen könnte.
Dann kann es sinnvoll sein, ausdrücklich festzuhalten, warum sie nicht verwendet werden soll. Andernfalls analysiert Codex das Projekt möglicherweise völlig korrekt und schlägt genau die Lösung erneut vor, die in der Konzeptphase bereits bewusst ausgeschlossen wurde.
Diese Unterscheidung ist für mich noch keine exakt definierte Wissenschaft. Sie entsteht aus Erfahrung.
Je häufiger Informationen bei der Übergabe fehlen oder Codex Entscheidungen erneut hinterfragt, desto deutlicher wird, welche Art von Kontext dauerhaft in die Spezifikation gehört.
Codex muss das Konzept trotzdem hinterfragen dürfen
Eine Spezifikation darf für mich nicht bedeuten, dass Codex sie technisch blind umsetzt.
ChatGPT kann bei der Konzeptarbeit Annahmen treffen, die sich im tatsächlichen Projekt als falsch herausstellen. Vielleicht gibt es eine technische Einschränkung, die im Gespräch nicht bekannt war, oder die vorhandene Architektur legt eine andere Umsetzung nahe.
Dann erwarte ich von Codex, dass es diesen Konflikt erkennt.
Die richtige Reaktion ist aber nicht, stillschweigend das Konzept zu verändern.
Wenn sich eine fachliche Entscheidung ändern müsste, möchte ich das wissen.
Genau darin liegt eine wichtige Grenze meiner Automatisierung: Codex darf technische Lösungen an den vorhandenen Code anpassen, aber es soll nicht unbemerkt die fachliche Bedeutung einer Anforderung verändern, nur weil eine andere Umsetzung einfacher wäre.
In solchen Situationen führt der Weg zurück in die Konzeptphase.
Die Verbindung funktioniert also in beide Richtungen
Auf den ersten Blick wirkt der Prozess wie eine einfache Übergabe:
ChatGPT → Markdown-Spezifikation → Codex
In der Praxis ist er eher eine Schleife.
ChatGPT hilft mir, ein Konzept zu entwickeln. Codex prüft dieses Konzept gegen das bestehende Projekt. Dabei können technische Erkenntnisse entstehen, die in der ursprünglichen Diskussion noch nicht bekannt waren. Diese Erkenntnisse können wiederum dazu führen, dass ich eine fachliche Entscheidung überdenken muss.
Dann geht es zurück.
Das Konzept wird angepasst, die Spezifikation aktualisiert und Codex arbeitet mit dem neuen Stand weiter.
Genau deshalb möchte ich die Markdown-Datei auch nicht als statisches Pflichtenheft betrachten. Sie ist der jeweils aktuelle gemeinsame Nenner zwischen Konzept und Umsetzung.
Bei kleinen Aufgaben ist dieser Aufwand oft unnötig
Natürlich brauche ich für eine kleine Änderung keine lange Konzeptphase.
Wenn ein Button falsch ausgerichtet ist oder ein eindeutig reproduzierbarer Fehler an einer klar begrenzten Stelle behoben werden soll, wäre es absurd, dafür erst eine ausführliche Spezifikation mit ChatGPT zu erarbeiten.
Die Trennung wird vor allem bei Aufgaben wichtig, die fachliche Entscheidungen enthalten oder mehrere Teile eines größeren Projekts betreffen.
Je größer die Auswirkungen einer Änderung sind, desto wertvoller wird ein sauberer Übergang zwischen Konzeptwissen und Codekontext.
Das ist auch der Grund, warum ich diese Arbeitsweise bei Kosmos stärker brauche als bei sehr kleinen Einzelaufgaben. Mit wachsender Projektgröße wird Projektwissen selbst zu einem Problem, weil immer mehr relevante Entscheidungen außerhalb der unmittelbar betroffenen Dateien existieren.
Agenda fügt eine weitere Wissensgrenze hinzu
Mit Agenda entsteht inzwischen noch ein zusätzlicher Übergang.
Ein größeres Konzept wird nicht zwangsläufig direkt umgesetzt. Codex kann daraus zunächst einzelne Aufgaben erzeugen, die später separat bearbeitet werden.
Damit muss das Wissen noch einmal sinnvoll aufgeteilt werden.
Eine einzelne Agenda-Aufgabe sollte genügend Kontext enthalten, damit sie später verständlich bearbeitet werden kann, ohne jedes Mal wieder die komplette ursprüngliche Spezifikation lesen zu müssen. Gleichzeitig darf sie nicht so isoliert formuliert sein, dass wichtige Zusammenhänge zu anderen Aufgaben verloren gehen.
In meiner Prozesskette von der Idee bis zum Deployment gibt es deshalb mehrere Stellen, an denen Wissen von einer Phase in die nächste übertragen wird.
Je stärker ich diese Kette automatisieren möchte, desto wichtiger wird die Qualität dieser Übergaben.
Multi-Agent-Systeme machen das Problem noch interessanter
Beim Aufbau agentischer Systeme und erster Multi-Agent-Strukturen wird aus dieser Übergabefrage langfristig ein grundsätzliches Architekturthema.
Ein Agent, der Aufgaben plant, braucht andere Informationen als ein Agent, der Code verändert. Ein Test-Agent sollte wiederum die fachliche Erwartung kennen, aber möglichst wenig von der Denkweise übernehmen, die zur konkreten Implementierung geführt hat.
Damit kann es sogar sinnvoll sein, Wissen bewusst nicht vollständig weiterzugeben.
Das ist für mich ein spannender Gegensatz.
Auf der einen Seite möchte ich Informationsverlust verhindern.
Auf der anderen Seite brauche ich bei bestimmten Rollen eine gewisse Unabhängigkeit.
Ein guter Test-Agent soll nicht deshalb denselben Fehler übersehen, weil er vorher sämtliche Begründungen des Umsetzungsagenten gelesen hat.
Die Frage lautet also irgendwann nicht mehr nur: Wie bekomme ich möglichst viel Kontext von A nach B?
Sondern: Welchen Kontext braucht B tatsächlich?
Langfristig brauche ich mehr als Markdown-Dateien
Für meinen aktuellen Prozess funktionieren Markdown-Spezifikationen erstaunlich gut. Ich kann sie lesen, archivieren, versionieren und direkt an Codex übergeben.
Trotzdem glaube ich nicht, dass sie langfristig die vollständige Lösung für große agentische Systeme sein werden.
Wenn immer mehr Entscheidungen, Projekte und Agenten zusammenkommen, brauche ich wahrscheinlich eine strukturiertere Wissensschicht, aus der ein System gezielt die relevanten Informationen für eine Aufgabe abrufen kann.
Projektwissen müsste dann dauerhaft gespeichert, auffindbar und vor allem aktuell gehalten werden. Eine alte Architekturentscheidung darf nicht Jahre später noch wie eine verbindliche Regel behandelt werden, wenn sie inzwischen bewusst ersetzt wurde.
Damit wird die Wissensübergabe zunehmend selbst zu einem Teil der Softwarearchitektur.
Die eigentliche Schnittstelle ist nicht ChatGPT oder Codex
Je länger ich damit arbeite, desto klarer wird mir deshalb, dass die wichtigste Schnittstelle nicht eines der beiden Produkte ist.
Die entscheidende Schnittstelle ist die Beschreibung meiner Entscheidungen.
ChatGPT kann mir helfen, sie zu entwickeln.
Codex kann daraus technische Arbeit ableiten.
Agenda kann daraus ausführbare Aufgaben machen.
Andere Agenten können später Tests oder Deployments übernehmen.
Aber alle diese Systeme benötigen eine Form, in der nachvollziehbar bleibt, was eigentlich gelten soll.
Genau dort liegt für mich momentan einer der wichtigsten Unterschiede zwischen gelegentlicher KI-Nutzung und einem dauerhaft KI-gestützten Entwicklungsprozess.
Die Herausforderung besteht nicht darin, möglichst viele KI-Systeme einzusetzen.
Sie besteht darin, dafür zu sorgen, dass zwischen ihnen nicht jedes Mal das verloren geht, was ich vorher mühsam entschieden habe.