Eine für langfristige Projekte entwickelte Kollaborationsstruktur, um zwischen mehreren KI-Modellen zu wechseln

In der KI-Zusammenarbeit sollte sich das Gedächtnis nicht im Chat, sondern im Repository befinden

In den vergangenen Monaten habe ich bei Entwicklungsarbeiten häufig abwechselnd verschiedene KI-Modelle wie Modelle der GPT-5-Reihe, Claude, Copilot und Gemini verwendet. Früher reichte oft ein einziges Tool aus, doch inzwischen ist es ganz natürlich geworden, je nach Art der Aufgabe das besser geeignete Modell auszuwählen.

Zum Beispiel sind für Architekturentwürfe große Modelle wie GPT-5.4 stabiler, beim Schreiben von Code sind Modelle der Claude-Sonnet-/Opus-Reihe mitunter präziser, und für Frontend-Design oder die Exploration von Ideen kann es effizienter sein, andere Modelle zu nutzen. Da sich Modelle zudem sehr schnell weiterentwickeln, bleibt man eher nicht bei einem bestimmten Tool, sondern wechselt die Auswahl je nach Situation fortlaufend.

Genau hier beginnen die Probleme.
Jedes Mal, wenn man das Modell wechselt oder eine neue Session beginnt, erinnert sich die KI überhaupt nicht an das Projekt. Am Ende wiederholt man immer wieder dieselben Erklärungen. Was dieses Projekt ist, wie weit es gerade fortgeschritten ist, welche Entscheidungen bereits getroffen wurden, welche Struktur beibehalten werden soll und was man nicht tun darf – all diesen grundlegenden Kontext muss man ständig erneut vermitteln.

Anfangs war das nur lästig, aber je größer das Projekt wurde, desto deutlicher stiegen die Kosten dafür. Vor allem beim Wechsel zwischen mehreren Modellen hatte ich das Gefühl, mehr Zeit mit dem erneuten Erklären des Kontexts als mit der eigentlichen Entwicklung zu verbringen. So stellte sich ganz natürlich die folgende Frage:

„Sollte sich das Gedächtnis in der KI-Zusammenarbeit im Chat befinden – oder sollte das Projekt selbst das Gedächtnis besitzen?“

Ein Problem, das sich nicht mit Prompt Engineering lösen lässt

Wenn es darum geht, KI gut zu nutzen, ist oft von Prompt Engineering die Rede. Aber bei langfristigen Projekten zeigt sich ein wichtigeres Problem als der Prompt selbst: der fehlende Erhalt des Kontexts.

Ein Prompt ist eine Methode, eine einzelne Anfrage gut zu formulieren; ein Projekt hingegen ist ein Prozess, in dem viele Arbeitsschritte aufeinander folgen. Damit ein Projekt stabil vorankommt, müssen mindestens die folgenden Informationen kontinuierlich erhalten bleiben:

• Aktuelle Anforderungen
• Bisher getroffene Entscheidungen
• Arbeitsplan
• Abgeschlossene Aufgaben
• Änderungshistorie
• Nächste Aufgaben

Wenn diese Informationen nicht erhalten bleiben, wiederholt selbst ein sehr gutes Modell dieselben Fehler. Deshalb begann ich nicht damit, bessere Prompts zu schreiben, sondern Methoden zu entwickeln, um den Kontext selbst zu verwalten. Dieser Ansatz wird meist als Context Engineering bezeichnet, und auch ich habe, nachdem ich auf ähnliche Probleme gestoßen war, begonnen, dieses Konzept auf die Zusammenarbeit auf Projektebene anzuwenden.

Nicht der Chat, sondern das Repository sollte das Gedächtnis besitzen

Als Erstes änderte ich den Ort, an dem der Kontext gespeichert wird. Bisher lag der gesamte Kontext im Chat, aber Chats verschwinden, sobald die Session endet. Deshalb entwickelte ich eine Struktur, in der der Kontext innerhalb des Projekt-Roots gespeichert wird.

Ich habe einen Ordner namens .cowork/ angelegt, in dem der Projektstatus festgehalten wird. Zum Beispiel Dinge wie requirements, architecture decision record, Aufgabenlisten, Testprotokolle, Release-Protokolle und Session-Logs.

Zu Beginn einer Session wird immer der aktuelle Zustand gelesen, dann ein Plan erstellt, freigegeben, ausgeführt und das Ergebnis dokumentiert. Gespräche sind flüchtig, Dokumente bleiben. Dadurch kann das Projekt auch dann fortgesetzt werden, wenn das Modell wechselt.

Die Regel Plan → Approve → Execute

Eines der häufigsten Probleme in der KI-Zusammenarbeit war für mich, dass ein Modell sofort den Code verändert. Frühere Entscheidungen werden ignoriert, die Struktur wird beschädigt oder Änderungen weichen von der bereits abgestimmten Richtung ab.

Deshalb habe ich eine Arbeitsregel eingeführt: Immer die Reihenfolge Plan → Approve → Execute einhalten. Zuerst wird ein Plan erstellt, dann prüft ihn ein Mensch, und erst danach wird er ausgeführt. Schon diese eine Regel hat die Zahl der Fehler in langfristigen Projekten deutlich reduziert.

Artifact is Memory

Das wichtigste Prinzip in diesem Framework lässt sich mit dem Satz „Artifact is Memory“ zusammenfassen. Das Gedächtnis sollte nicht im Chat liegen, sondern in den Projektergebnissen.

Nur so lässt sich der Projektstatus aufrechterhalten, auch wenn sich Modell, Session, Tool oder IDE ändern. Gerade in Umgebungen, in denen mehrere Modelle parallel genutzt werden, ist dieses Prinzip deutlich wichtiger, als man zunächst denkt.

Mit Projektergebnissen sind hier nicht nur Dinge gemeint, die von Anfang an als Dokument geschrieben wurden. Auch in den Gesprächen mit der KI entstehen fortlaufend Informationen, die tatsächlich im Projekt verbleiben sollten – etwa verfeinerte Anforderungen, Architekturentscheidungen, Arbeitspläne oder Review-Ergebnisse. Das Problem ist, dass solche Inhalte leicht als einmaliger Kontext verbraucht werden, solange sie im Chat bleiben.

Deshalb halte ich es für wichtig, sinnvolle Inhalte aus den Gesprächen mit der KI automatisch zu klassifizieren und zu dokumentieren, um sie anschließend wieder als Projektergebnisse zu verwenden. Es geht also nicht einfach darum, Gesprächslogs anzusammeln, sondern die Kernaussagen aus den Gesprächen in Formen wie Entscheidungsprotokollen, Anforderungsdokumenten, Arbeitsplänen oder Session-Logs aufzubereiten und in wiederverwendbarer Form zu hinterlassen.

So bleiben Gespräche nicht bei einer einmaligen Schnittstelle stehen, sondern werden in Arbeitsmaterial umgewandelt, das das Projekt kontinuierlich vorantreibt. Letztlich ist nicht das Gespräch selbst das, was man sich merken muss, sondern das daraus extrahierte strukturierte Ergebnis.

Probleme, die beim Arbeiten mit mehreren Modellen entstehen

Heutzutage nutzt man kaum noch nur ein einziges Modell. Da jedes Modell andere Stärken hat, verwendet man je nach Arbeitsphase unterschiedliche Modelle, und Aufgaben wie Design, Code-Änderungen, Reviews oder Kontextanalyse werden über mehrere Sessions und mehrere Modelle hinweg wiederholt.

Wenn der Kontext dabei nur im Chat liegt, muss man beim Modellwechsel jedes Mal das Projekt erneut erklären. Deshalb habe ich eine Struktur geschaffen, in der sich der Kontext nicht im Chat, sondern im Repository befindet.

Was ich gebaut habe: cowork-context-framework

Ich habe diesen Prozess zu einem Framework zusammengeführt. Es handelt sich um eine Struktur, die den Kontext im Projekt speichert, Sessions wiederherstellt, Entscheidungen dokumentiert, Aufgaben nachverfolgt und es ermöglicht, auch nach einem Modellwechsel nahtlos weiterzuarbeiten.

• GitHub: https://github.com/lim8603/cowork-context-framework

Zuvor habe ich es in Form eines Templates genutzt und in realen Projekten angewendet, wodurch es bis zu einem gewissen Grad validiert wurde. Auf Basis dieser Erfahrungen habe ich die Struktur geordnet und zu einem Framework weiterentwickelt. Für langfristige Projekte mit KI halte ich dies für eine sinnvolle minimale Kollaborationsstruktur.

Ich bin neugierig, ob jemand etwas Ähnliches ausprobiert hat

• Personen, die Erfahrungen damit haben, mehrere KI-Modelle gemeinsam zu nutzen
• Personen, die wegen unterbrochener Sessions dieselben Erklärungen mehrfach geben mussten
• Personen, die Strukturen wie agent / workflow / harness gebaut haben
• Personen, die Projektkontext separat verwaltet haben

Falls jemand ähnliche Erfahrungen gemacht hat, würde ich gern seine Meinung hören.