Je größer ein Softwareprojekt wird, desto deutlicher merke ich, dass guter Codezugriff allein noch kein vollständiges Projektverständnis ergibt. Codex kann mein Repository durchsuchen, Klassen analysieren, Abhängigkeiten verfolgen und sich relativ schnell ein Bild davon machen, wie eine bestimmte Funktion technisch aufgebaut ist. Trotzdem gibt es eine zweite Ebene von Wissen, die sich nicht zuverlässig aus dem aktuellen Quellcode herauslesen lässt: Warum wurde etwas genau so gebaut, welche Alternativen wurden bewusst verworfen, welche späteren Erweiterungen wurden bei einer Entscheidung bereits berücksichtigt und welche Regeln gelten, obwohl sie technisch nirgendwo erzwungen werden?
Für mich ist genau dieses Projektwissen inzwischen eines der größten noch ungelösten Probleme bei KI-gestützter Softwareentwicklung. Bei kleinen Aufgaben fällt es kaum auf, weil Codex den unmittelbar benötigten Kontext meistens direkt aus den betroffenen Dateien ableiten kann. Bei einem gewachsenen System wie Kosmos sieht das anders aus, denn dort hängen Module, gemeinsame Komponenten, langfristige Entscheidungen und fachliche Regeln miteinander zusammen, die teilweise über Monate entstanden sind.
Je stärker ich die eigentliche Umsetzung an KI abgebe, desto wichtiger wird deshalb die Frage, wie dieses Wissen zuverlässig von einer Aufgabe zur nächsten erhalten bleibt.
Code enthält viel Wissen, aber nicht die ganze Geschichte
Ein gut strukturiertes Repository verrät bereits eine Menge. Klassennamen, Schnittstellen, Tests und Abhängigkeiten zeigen, wie das System heute aufgebaut ist, und Kommentare oder Dokumentationen können zusätzliche Entscheidungen erklären. Trotzdem beschreibt der vorhandene Code in erster Linie das Ergebnis früherer Entscheidungen, nicht unbedingt deren Gründe.
Wenn beispielsweise zwei technische Lösungen denkbar gewesen wären und ich mich bewusst für die aufwendigere Variante entschieden habe, weil eine spätere Erweiterung berücksichtigt werden sollte, kann Codex möglicherweise erkennen, dass diese Struktur existiert. Ob es auch versteht, warum sie existiert, ist eine andere Frage.
Das wird spätestens dann relevant, wenn eine neue Aufgabe eine vermeintlich einfachere Lösung nahelegt. Technisch könnte diese Änderung sauber aussehen und trotzdem genau die Eigenschaft beseitigen, wegen der die bestehende Architektur ursprünglich so gewählt wurde.
Ausführlichere Spezifikationen sind für mich deshalb wieder deutlich wichtiger geworden, denn sie halten zumindest einen Teil dieser Überlegungen außerhalb meines eigenen Kopfes fest. Trotzdem löst auch eine gute Spezifikation nur das Wissen über das aktuelle Thema und nicht automatisch die gesamte Geschichte eines großen Projekts.
Bei klassischer Einzelentwicklung war mein Kopf ein Teil der Architektur
Als ich Software weitgehend allein und ohne Coding-Agent entwickelte, war dieser Zustand weniger auffällig. Viele Zusammenhänge musste ich nicht dokumentieren, weil ich mich selbst daran erinnerte. Wenn ich Monate später wieder an dieselbe Stelle kam, wusste ich häufig noch, weshalb eine bestimmte Entscheidung gefallen war oder welche Erweiterung damals bereits berücksichtigt wurde.
Natürlich funktioniert auch menschliches Gedächtnis nicht perfekt. Trotzdem war der Wissensträger derselbe Mensch, der später die nächste Änderung entwickelte.
Mit Codex entsteht eine andere Situation.
Eine neue Aufgabe beginnt nicht mit meinem vollständigen Projektgedächtnis. Codex analysiert den verfügbaren Kontext erneut und muss daraus rekonstruieren, was für die aktuelle Arbeit relevant ist. Genau dabei können Informationen verloren gehen, die zwar für mich selbstverständlich sind, aber weder direkt im Code noch in der Aufgabenbeschreibung stehen.
Der Unterschied zwischen meiner klassischen Entwicklung bei Sara und der heutigen Arbeit an Kosmos und Linea zeigt sich deshalb nicht nur beim Schreiben des Codes. Ich muss Wissen, das früher einfach in meinem Kopf existierte, heute wesentlich bewusster nach außen bringen.
Ein riesiges Kontextfenster löst das Problem nur teilweise
Die naheliegende technische Antwort auf fehlenden Kontext lautet oft: Dann braucht die KI eben ein größeres Kontextfenster.
Das hilft zweifellos. Wenn mehr Dateien, Dokumentationen und vorherige Entscheidungen gleichzeitig verfügbar sind, steigt die Chance, dass relevante Zusammenhänge erkannt werden. Für mich löst das die grundsätzliche Frage aber nicht.
Mehr Kontext ist nicht automatisch besserer Kontext.
Ein großes Projekt kann sehr viele Informationen enthalten, von denen für eine konkrete Aufgabe nur ein kleiner Teil wichtig ist. Wenn ich einfach alles in denselben Kontext kippe, muss das Modell relevante Entscheidungen zwischen einer großen Menge Nebensächlichem wiederfinden. Gleichzeitig wächst das Risiko, dass veraltete Dokumentation, historische Zwischenstände oder inzwischen verworfene Konzepte genauso präsent sind wie aktuelle Regeln.
Ich brauche deshalb langfristig nicht einfach möglichst viel Projektwissen.
Ich brauche das richtige Projektwissen für die jeweilige Aufgabe.
Entscheidungen müssten dauerhaft auffindbar bleiben
Besonders wichtig sind für mich Architektur- und Produktentscheidungen, die langfristige Auswirkungen besitzen.
Warum gehört eine Funktion zu einem bestimmten Modul?
Warum darf ein bestimmter Zustand nicht automatisch korrigiert werden?
Warum wird eine Information bewusst als „unbekannt“ angezeigt, statt einen wahrscheinlich richtigen Wert zu schätzen?
Warum existiert an einer Stelle eine manuelle Freigabe, obwohl eine vollständige Automatisierung technisch möglich wäre?
Solche Regeln lassen sich nicht immer sinnvoll direkt im Code ausdrücken. Trotzdem müssen sie bei späteren Änderungen berücksichtigt werden.
Genau deshalb denke ich zunehmend darüber nach, Projektwissen nicht nur als klassische Dokumentation, sondern als strukturierten Bestandteil des Entwicklungsprozesses zu betrachten. Wenn eine wichtige Entscheidung getroffen wird, sollte sie so gespeichert werden, dass Codex sie später bei einer thematisch passenden Aufgabe wiederfinden kann.
Das klingt zunächst nach normaler Dokumentation, geht für mich aber einen Schritt weiter. Eine Dokumentation ist für einen Menschen geschrieben, der sie bei Bedarf liest. Projektwissen für Agenten müsste zusätzlich so organisiert sein, dass ein System selbstständig erkennen kann, welcher Teil davon für die aktuelle Aufgabe relevant ist.
ChatGPT und Codex besitzen unterschiedliche Teile des Wissens
Die Trennung zwischen ChatGPT und Codex funktioniert für meine Arbeitsweise sehr gut, erzeugt aber gleichzeitig genau an dieser Stelle eine Wissensgrenze.
ChatGPT kennt die ausführliche Diskussion, in der ein Konzept entstanden ist. Dort wurden möglicherweise zahlreiche Varianten verworfen, Sonderfälle besprochen und Gründe für einzelne Entscheidungen ausführlich erklärt.
Codex bekommt anschließend die konsolidierte Spezifikation und kennt dafür den tatsächlichen Code.
Beide Systeme besitzen also unterschiedliche Teile des Gesamtbildes.
Das ist grundsätzlich sinnvoll, weil Codex nicht jede verworfene Diskussion benötigt und ChatGPT nicht permanent das vollständige Repository analysieren muss. Trotzdem muss die Übergabe gut genug sein, damit wichtige Gründe nicht zwischen beiden Ebenen verloren gehen.
Die Markdown-Spezifikation ist dafür heute meine wichtigste Schnittstelle. Langfristig reicht mir dieses einzelne Dokument pro Thema aber wahrscheinlich nicht aus.
Agenda könnte zusätzlich Wissen aus der Umsetzung liefern
Mit meiner Prozesskette über Agenda entsteht noch eine weitere mögliche Quelle für Projektwissen.
Dort lässt sich nachvollziehen, welche Aufgaben aus einem Konzept entstanden sind, welche davon blockiert waren, wo Codex während der Umsetzung auf Probleme gestoßen ist und welche Entscheidungen später getroffen wurden. Gerade diese Informationen können für zukünftige Arbeiten sehr wertvoll sein.
Wenn eine Aufgabe beispielsweise nur deshalb auf eine bestimmte Weise umgesetzt wurde, weil eine vorhandene Komponente eine technische Einschränkung besitzt, sollte diese Erkenntnis nicht ausschließlich in einer abgeschlossenen Agenda-Historie verschwinden.
Sie könnte Teil des dauerhaften Projektwissens werden.
Damit entsteht allerdings sofort die nächste Schwierigkeit: Nicht jedes technische Detail einer einzelnen Aufgabe ist langfristig relevant. Ein System müsste also unterscheiden, welche Erkenntnisse dauerhaft wichtig sind und welche nur zur einmaligen Fehleranalyse gehörten.
Auch das möchte ich nicht vollständig einer KI überlassen, ohne nachvollziehen zu können, was am Ende gespeichert wird.
Projektwissen darf nicht unbemerkt veralten
Ein weiteres Problem ist die Aktualität.
Eine Architekturentscheidung kann heute richtig sein und in einem Jahr nicht mehr gelten. Ein Modul wird umgebaut, eine alte Einschränkung fällt weg oder eine neue technische Grundlage verändert den bisherigen Ansatz.
Wenn veraltetes Projektwissen trotzdem weiterhin als verbindliche Regel behandelt wird, kann es neue Entwicklungen sogar behindern.
Das bedeutet, dass Projektwissen einen Lebenszyklus benötigt.
Entscheidungen müssen geändert oder als überholt markiert werden können. Vielleicht muss nachvollziehbar bleiben, welche neue Entscheidung die alte ersetzt hat. Gleichzeitig darf eine KI nicht einfach eigenständig beschließen, eine dokumentierte Vorgabe sei vermutlich nicht mehr wichtig und könne ignoriert werden.
Damit nähert sich das Thema erstaunlich stark klassischem Wissensmanagement an, nur dass der primäre Nutzer nicht mehr ausschließlich ein Mensch ist.
Multi-Agent-Systeme verschärfen das Problem
Je stärker ich mich in Richtung agentischer Systeme und Multi-Agent-Strukturen bewege, desto wichtiger wird ein gemeinsames Projektwissen.
Wenn mehrere Agenten nacheinander oder parallel an demselben System arbeiten, kann ich nicht voraussetzen, dass jeder von ihnen dieselben vorherigen Gespräche gesehen hat. Ein Agent bereitet vielleicht Aufgaben vor, ein anderer setzt sie um und ein weiteres System prüft später das Ergebnis.
Alle benötigen unterschiedliche Ausschnitte desselben Wissens.
Der Test-Agent sollte beispielsweise die fachlichen Erwartungen kennen, aber möglichst nicht jeden Gedanken des Umsetzungsprozesses übernehmen, weil sonst die gewünschte Unabhängigkeit verloren geht. Ein Deployment-Agent benötigt wiederum Informationen über technische Voraussetzungen und Rückfallwege, aber nicht zwingend die komplette Produktdiskussion.
Damit wird Projektwissen nicht zu einem einzigen großen Dokument, sondern zu einer Informationsquelle, aus der jede Rolle genau den passenden Ausschnitt benötigt.
Genau dort wird das Thema für mich architektonisch interessant.
Lokale KI würde das Problem ebenfalls nicht automatisch lösen
Auch ein zukünftiger lokaler Codex-Ersatz würde diese Frage nicht einfach beseitigen.
Natürlich könnte ein lokales System dauerhaft auf meine Repositories und Dokumentationen zugreifen, ohne dass ich mir Gedanken über die Übertragung an einen externen Dienst machen müsste. Das wäre ein großer Vorteil.
Trotzdem müsste auch dieses System wissen, welche Informationen relevant, aktuell und verbindlich sind.
Ein lokales Modell mit Zugriff auf zehn Jahre ungefilterte Projektdokumentation besitzt nicht automatisch ein besseres Verständnis als ein externes Modell mit einer gut aufbereiteten Auswahl aktueller Informationen.
Die eigentliche Herausforderung liegt deshalb weniger im Speicherort.
Sie liegt in der Struktur des Wissens.
Vielleicht muss Projektwissen ein eigenes Produktmerkmal werden
Ich beginne deshalb, Projektwissen zunehmend nicht mehr als Nebenprodukt der Entwicklung zu betrachten.
Wenn ich eine Software langfristig mit Agenten entwickeln möchte, muss die Fähigkeit, wichtige Entscheidungen dauerhaft nachvollziehbar zu halten, möglicherweise genauso bewusst geplant werden wie Tests oder Deployment.
Ein Projekt besteht dann nicht mehr nur aus Quellcode, Datenbank, Tests und Dokumentation.
Es besitzt zusätzlich eine Wissensschicht darüber, die erklärt, welche Regeln gelten und warum bestimmte Strukturen entstanden sind.
Genau diese Schicht könnte später entscheidend dafür sein, wie zuverlässig ein Agent auch nach Monaten noch Veränderungen durchführen kann, ohne alte Entscheidungen unbeabsichtigt zu zerstören.
Gelöst habe ich das heute noch nicht
Momentan arbeite ich mit einer Kombination aus guten Spezifikationen, vorhandenem Repository, Projektdokumentation und dem Kontext, den Codex für eine konkrete Aufgabe selbst analysiert.
Damit komme ich bereits erstaunlich weit.
Trotzdem sehe ich gerade bei Kosmos immer deutlicher, dass diese Lösung mit wachsender Größe an Grenzen stößt. Je mehr Module, Agenten, Aufgaben und langfristige Entscheidungen zusammenkommen, desto schwieriger wird es, relevante Zusammenhänge jedes Mal erneut aus verschiedenen Quellen zu rekonstruieren.
Deshalb gehört Projektwissen für mich zu den großen offenen Punkten meiner heutigen KI-Arbeitsweise.
Die Frage lautet nicht mehr nur:
Wie gebe ich einer KI möglichst viel Kontext?
Die wesentlich interessantere Frage ist:
Wie baue ich ein Projekt so auf, dass eine KI auch in einigen Jahren noch zuverlässig herausfinden kann, was sie für genau diese Aufgabe wissen muss und warum diese Informationen gelten?
Eine endgültige Antwort darauf habe ich noch nicht.
Aber ich bin ziemlich sicher, dass sie für langfristig agentische Softwareentwicklung wichtiger sein wird als einfach nur das nächste noch größere Kontextfenster.