Seit ich einen immer größeren Teil der konkreten Umsetzung an Codex abgebe, beschäftige ich mich paradoxerweise intensiver mit Softwarearchitektur als früher. Auf den ersten Blick hätte ich eher das Gegenteil erwartet: Wenn eine KI große Teile des Codes erzeugen kann, müsste es doch eigentlich weniger wichtig werden, wie genau einzelne Komponenten aufgebaut sind. In der Praxis passiert bei mir jedoch genau das Gegenteil, denn je schneller Code entsteht und je mehr Arbeit ich parallelisieren kann, desto wichtiger werden klare Grenzen, Zuständigkeiten und nachvollziehbare Entscheidungen.
Wenn ich selbst eine Funktion entwickle, nehme ich während der Umsetzung ständig kleine Korrekturen vor, ohne darüber groß nachdenken zu müssen. Ich merke, dass eine Klasse zu viel Verantwortung bekommt, verschiebe einen Teil der Logik oder erinnere mich daran, dass eine bestimmte Komponente bewusst nicht auf eine andere zugreifen soll. Viele dieser Entscheidungen entstehen aus Erfahrung und aus dem Wissen, das ich über Monate oder Jahre über das Projekt aufgebaut habe. Codex besitzt dieses Wissen nicht automatisch, und genau deshalb muss ich heute Dinge expliziter machen, die früher teilweise einfach in meinem Kopf lagen.
Gute Architektur wird mit KI nicht weniger wichtig
Codex kann erstaunlich schnell funktionierenden Code erzeugen. Gerade darin liegt aber auch ein Risiko, denn eine falsche Architekturentscheidung wird damit ebenfalls sehr schnell in viele Dateien, Klassen und Abhängigkeiten übersetzt. Wenn ich erst nach mehreren umfangreichen Änderungen merke, dass die gewählte Richtung nicht zu meinem eigentlichen System passt, habe ich zwar sehr schnell viel Code erzeugt, aber trotzdem Arbeit produziert, die ich anschließend wieder zurückbauen muss.
Bei klassischer Entwicklung entsteht während des Programmierens automatisch eine gewisse Reibung. Eine schlechte Struktur fühlt sich irgendwann umständlich an, weil ich sie selbst bedienen muss, und eine falsche Abhängigkeit fällt mir möglicherweise auf, weil ich ständig zwischen zwei Bereichen hin- und herspringe. KI kann diese Reibung teilweise überdecken, weil Codex auch innerhalb einer schlechten Struktur sehr schnell weiterarbeiten kann.
Deshalb brauche ich Architektur heute weniger als Anleitung dafür, wie jede einzelne Codezeile aussehen soll, sondern stärker als Rahmen für automatisierte Entscheidungen. Codex darf innerhalb dieses Rahmens sehr frei arbeiten, sollte aber möglichst klar erkennen können, welche Grenzen nicht überschritten werden dürfen.
Zuständigkeiten müssen sichtbarer werden
Bei einem größeren System wie Kosmos reicht es nicht, dass jede Funktion irgendwo technisch funktioniert. Die einzelnen Module besitzen unterschiedliche Aufgaben, und gemeinsam genutzte Komponenten sollen nicht beliebig mit fachlicher Logik aufgeladen werden, nur weil das bei einer einzelnen Änderung gerade praktisch erscheint.
Gerade solche Grenzen sind für eine KI nicht automatisch offensichtlich. Wenn eine Lösung technisch einfacher wird, indem eine gemeinsame Komponente zusätzliche Verantwortung übernimmt, kann dieser Weg aus Sicht der aktuellen Aufgabe vollkommen plausibel erscheinen. Für die langfristige Architektur kann er trotzdem falsch sein.
Das Problem hängt direkt mit meinem noch ungelösten Thema Projektwissen zusammen. Der vorhandene Code zeigt Codex, wie das System heute aufgebaut ist, aber er erklärt nicht immer zuverlässig, welche Grenzen absichtlich existieren und welche scheinbar naheliegenden Abkürzungen bewusst vermieden werden sollen. Je größer ein Projekt wird, desto wichtiger wird deshalb eine zusätzliche Ebene, auf der solche Entscheidungen nachvollziehbar bleiben.
Architekturentscheidungen müssen nicht nur richtig, sondern erklärbar sein
Früher konnte ich mir erlauben, manche Entscheidung intuitiv zu treffen und später einfach weiter damit zu arbeiten. Heute möchte ich stärker festhalten, warum eine Struktur gewählt wurde, weil diese Begründung bei einer späteren Aufgabe wieder relevant werden kann.
Das bedeutet nicht, dass ich für jede Hilfsklasse ein Architekturpapier schreiben möchte. Wichtig werden vor allem Entscheidungen mit längerfristigen Auswirkungen: Warum gehört eine Funktion in ein bestimmtes Modul? Warum darf eine Komponente auf eine andere zugreifen, die Gegenrichtung aber nicht? Warum wurde eine scheinbar einfachere technische Lösung bewusst verworfen? Welche spätere Erweiterung wurde bei der heutigen Struktur bereits berücksichtigt?
Ausführlichere Spezifikationen helfen mir inzwischen dabei, solche Entscheidungen früher sichtbar zu machen, aber auch die Spezifikation einer einzelnen Aufgabe reicht nicht immer aus. Einige Regeln gehören nicht zu einer bestimmten Funktion, sondern zum gesamten Projekt und müssen deshalb langfristig auffindbar bleiben.
Ein großes Kontextfenster ersetzt keine Architektur
Es wäre verlockend, das Problem einfach mit mehr Kontext lösen zu wollen. Wenn Codex nur genügend Dateien, Dokumentationen und frühere Entscheidungen lesen kann, müsste es schließlich alles wissen, was für die Aufgabe notwendig ist.
Ganz so einfach sehe ich das inzwischen nicht mehr. Ein großes Kontextfenster kann sehr hilfreich sein, aber eine unklare Architektur wird dadurch nicht automatisch klarer. Wenn Verantwortlichkeiten nicht sauber getrennt sind und ähnliche Funktionen an verschiedenen Stellen unterschiedlich gelöst wurden, bekommt die KI lediglich mehr widersprüchliche Informationen.
Gute Architektur reduziert dagegen die Menge an Wissen, die für eine einzelne Änderung überhaupt notwendig ist. Wenn ein Modul eine klare Aufgabe besitzt und seine Schnittstellen sauber definiert sind, muss Codex nicht bei jeder Änderung das gesamte Projekt neu verstehen.
Damit bekommt Modularität für mich durch KI sogar einen zusätzlichen wirtschaftlichen Wert.
Architektur beeinflusst die Parallelisierung
Ich arbeite inzwischen mit mehreren KI-Arbeitssträngen parallel, und genau dabei wird Architektur besonders wichtig. Zwei Aufgaben lassen sich nur dann sinnvoll unabhängig voneinander bearbeiten, wenn ihre technischen Auswirkungen ausreichend getrennt sind.
Bei einem schlecht abgegrenzten System kann eine kleine Änderung an einer Stelle überraschend viele andere Bereiche betreffen. Dann muss ich entweder sehr viel Arbeit seriell ausführen oder akzeptieren, dass sich parallele Änderungen gegenseitig beeinflussen.
Für die Koordination paralleler Codex-Arbeiten habe ich deshalb bereits ein Konzept mit logischen Arbeitsbereichen entwickelt. Diese Bereiche funktionieren aber nur dann sinnvoll, wenn die zugrunde liegende Architektur überhaupt eine erkennbare Struktur besitzt. Wenn praktisch jede Funktion überall eingreifen kann, hilft auch die beste Aufgabenverwaltung nur begrenzt.
Architektur wird damit zu einer Voraussetzung dafür, agentische Arbeit sinnvoll zu parallelisieren.
KI zeigt Architekturprobleme manchmal schneller als klassische Entwicklung
Interessanterweise macht Codex schlechte Strukturen nicht nur problematischer, sondern manchmal auch sichtbarer. Wenn ein scheinbar klarer Auftrag plötzlich Änderungen in zehn völlig unterschiedlichen Bereichen des Projekts benötigt, ist das ein guter Anlass zu fragen, ob die fachlichen Grenzen tatsächlich sinnvoll gezogen wurden.
Natürlich bedeutet eine große Änderung nicht automatisch schlechte Architektur. Manche Funktionen sind nun einmal Querschnittsthemen und müssen mehrere Bereiche betreffen. Trotzdem fällt mir durch die technische Analyse von Codex häufiger auf, wenn eine Aufgabe weiter durch das System greift, als ich zunächst erwartet hätte.
Diese Information kann selbst wertvoll sein. Ich muss dann nicht nur entscheiden, wie die aktuelle Aufgabe umgesetzt wird, sondern kann überlegen, ob die vorhandene Struktur langfristig angepasst werden sollte.
Codex darf Architektur nicht einfach selbst erfinden
Damit komme ich wieder zu einer Grenze, die sich durch meine gesamte KI-Arbeitsweise zieht. Technische Detailentscheidungen darf Codex durchaus selbst treffen, aber grundlegende Architekturentscheidungen möchte ich nicht unbemerkt während einer einzelnen Aufgabe entstehen lassen.
Wenn eine Änderung eine neue zentrale Abhängigkeit einführen würde oder eine bestehende Modulgrenze grundsätzlich infrage stellt, ist das für mich keine normale Implementierungsentscheidung mehr. Dann möchte ich verstehen, warum diese Änderung notwendig ist und welche Alternativen existieren.
In meiner geplanten Prozesskette soll Codex bei solchen offenen Punkten lieber eine Aufgabe blockieren, statt innerhalb einer umfangreichen Umsetzung stillschweigend eine neue Architektur zu etablieren. Genau solche Grenzen werden umso wichtiger, je autonomer die technische Arbeit später ablaufen soll.
Agentische Systeme erhöhen den Anspruch noch einmal
Mit meinem Weg in Richtung agentischer Systeme und Multi-Agent-Strukturen wird dieses Thema noch wichtiger. Sobald nicht nur ein Codex-Chat an einem Projekt arbeitet, sondern unterschiedliche Agenten Aufgaben planen, umsetzen oder prüfen, kann ich noch weniger darauf vertrauen, dass alle dieselben impliziten Vorstellungen über die Architektur besitzen.
Dann muss die Struktur des Systems selbst verständlich genug sein, dass unterschiedliche technische Arbeiter unabhängig voneinander zu kompatiblen Ergebnissen kommen können. Ein Agent sollte erkennen können, welche Komponente für eine Aufgabe zuständig ist, ohne zunächst die gesamte Geschichte des Projekts rekonstruieren zu müssen.
Für mich bedeutet das, dass Softwarearchitektur zunehmend auch Arbeitsarchitektur wird. Sie beschreibt nicht nur, wie Software zur Laufzeit zusammenspielt, sondern beeinflusst auch, wie gut technische Arbeit aufgeteilt, automatisiert und später wieder zusammengeführt werden kann.
KI zwingt mich damit zu mehr Disziplin
Früher konnte ich kleinere architektonische Unsauberkeiten manchmal lange mit meinem eigenen Wissen kompensieren. Ich wusste, dass eine bestimmte Komponente eigentlich nicht ganz sauber geschnitten war, konnte aber trotzdem damit arbeiten, weil ich die Besonderheiten kannte.
Je mehr Arbeit ich an Codex und später an verschiedene Agenten abgebe, desto weniger möchte ich mich darauf verlassen.
Unausgesprochene Sonderregeln, historisch gewachsene Ausnahmen und Abhängigkeiten, die nur ich verstehe, werden zunehmend zu Hindernissen für Automatisierung.
Das ist für mich eine durchaus positive Nebenwirkung der KI-gestützten Entwicklung. Sie zwingt mich nicht nur dazu, Anforderungen klarer zu formulieren, sondern auch bestehende Strukturen kritischer zu betrachten.
Gute Architektur bedeutet für mich heute vor allem klare Entscheidungsräume
Ich möchte Codex nicht jede technische Entscheidung vorschreiben. Das würde einen großen Teil des Nutzens wieder beseitigen und mich letztlich zum Mikromanager meiner eigenen KI machen.
Die Architektur soll stattdessen möglichst deutlich festlegen, wo Entscheidungen frei getroffen werden können und wo verbindliche Grenzen existieren.
Innerhalb eines Moduls darf Codex eine passende interne Struktur wählen, wenn keine übergeordneten Regeln verletzt werden. Sobald eine Änderung andere Bereiche berührt oder zentrale Verantwortlichkeiten verschiebt, möchte ich dagegen bewusst beteiligt werden.
Dieser Ansatz gefällt mir zunehmend besser als eine möglichst detaillierte technische Vorgabe jeder einzelnen Umsetzung.
Ich definiere den Rahmen.
Codex kann sich darin bewegen.
Und wenn es den Rahmen verlassen muss, möchte ich wissen, warum.
Die Bedeutung von Architektur nimmt für mich deshalb eher zu
KI nimmt mir einen Teil der eigentlichen Implementierungsarbeit ab, aber sie nimmt mir nicht die Verantwortung für die langfristige Struktur meiner Software ab. Im Gegenteil: Je schneller und autonomer technische Änderungen entstehen können, desto wichtiger wird ein System, das solche Änderungen in sinnvolle Bahnen lenkt.
Deshalb sehe ich Architektur heute weniger als einmalige Planungsphase am Anfang eines Projekts und stärker als dauerhafte Grundlage für automatisierte Entwicklung.
Eine gute Architektur hilft Menschen dabei, Software zu verstehen.
Sie hilft aber zunehmend auch Agenten dabei, vernünftige Entscheidungen zu treffen.
Und wenn ich langfristig möchte, dass mehrere KI-Systeme zuverlässig an denselben Projekten arbeiten, könnte genau das einer der wichtigsten Qualitätsfaktoren überhaupt werden.