Wie relevant ist eine saubere Software-Architektur im Zeitalter der KI? | Zusammenfassung

Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Alexander von Zitzewitz baut seit 2005 mit hello2morrow Werkzeuge, die die innere Struktur von Software vermessen, allen voran Sonargraph. In dieser Folge diskutiert er mit Ralf D. Müller, ob eine saubere Architektur noch zählt, wenn KI den Code schreibt. Seine Antwort: Sie zählt mehr als vorher, weil die KI verstärkt, was sie im Code vorfindet. Die Folge verbindet die Theorie mit einer Live-Demo an Gradle und mit Erfahrungen aus einem eigenen MCP-Server.

Architektur heißt innere Struktur

Für Alexander ist Architektur die innere Struktur eines Systems: Welche Komponenten gibt es, in welche Richtung dürfen sie kommunizieren, welcher Teil einer Box ist von außen sichtbar. Boxen sind geschachtelt wie in einem UML-Komponentendiagramm, und die Struktur soll am Ende zyklenfrei sein. Dass auch große Projekte ohne diese Struktur funktionieren, bestreitet er nicht. Hibernate habe einen Zyklus aus 1.500 Klassen, Cassandra sehe ähnlich aus: „Das heißt, da gibt es keine Architektur. Da gibt es nur eine große Box und 500.000 Zeilen Code.” Sein Argument ist die Lesbarkeit: Wer neu dazukommt, muss herausfinden, wo ein Feature hingehört, und das dauert in einer solchen Codebasis „viel, viel Zeit”.

Zwei Säulen und der Big Ball of Mud

Eine gute Struktur steht für Alexander auf zwei Säulen: einer möglichst zyklenfreien Abhängigkeitsstruktur und einem Architekturmodell. Kleine Zyklen, etwa im Visitor-Pattern, stören ihn nicht. Das Problem beginnt, wenn Zyklen auf 20, 100 oder 1.000 Elemente wachsen: „Dann ziehst du an dieser Klasse und plötzlich hängen 999 andere Klassen dran.” Dann ist die Modularisierung dahin und die Abstraktionen verwässern. Solche Strukturen nennt Alexander nicht technische Schulden, sondern Technical Friction: „Weil technische Schulden impliziert, dass jemand ein Darlehen aufgenommen hat, also eine bewusste Entscheidung getroffen hat.” Die Zyklen entstehen unbewusst, weil kein Entwickler beim Einbau einer Abhängigkeit sieht, dass damit ein Zyklus über fünf Packages entsteht, und der Compiler es ihm nicht sagt.

Braucht KI noch Architektur?

Ralf stellt die Frage, die viele sich stellen: Wenn die KI den Code schreibt und pflegt, warum sollte mir die innere Struktur noch wichtig sein? Alexander nennt es eine Glaubensfrage und zitiert eine Stanford-Studie mit 120.000 Entwicklern, die im Durchschnitt nur rund zehn Prozent Produktivitätsgewinn durch KI fand. Manche Teams waren 200 bis 300 Prozent schneller, andere wurden langsamer. Die stärkste Korrelation: Die größten Gewinne gab es bei der besten Softwarestruktur. Sein Fazit: „KI verstärkt, was sie vorfindet. Baut auf dem auf, was schon da ist und benutzt dieselben Patterns, die sie schon im Code findet. Und wenn das Pattern Big Ball of Mud ist, dann produziert die KI mehr Big Ball of Mud.” In Tests brauchte Claude in schlecht strukturiertem Code außerdem erheblich mehr Tokens. Ralf kennt den Effekt aus einem eigenen AsciiDoc-Linter, bei dem die KI in jeder neuen Session ein anderes Test-Framework wählte, weil sie keine Entscheidung vorfand. Als gut strukturierte Beispiele nennt Alexander das Spring Framework, bei dem Jürgen Höller Abhängigkeiten streng reviewt habe, und weite Teile von Gradle, dessen Dependency-Management-Modul aber zum Big Ball of Mud tendiert.

Live-Demo: Gradle in Sonargraph

Alexander zeigt Gradle in Sonargraph. 15 Prozent der Codebasis liegen in Zyklen, der größte umfasst 92 Java-Files aus 16 Packages. Der Graph dazu sieht aus wie ein Big Ball of Mud, zeigt aber mit Packages als Farben eine verwaschene Trennlinie. Fasst man die Knoten nach Farbe zusammen, wird der Graph einfacher. Der Exploration View ordnet die Elemente untereinander an und zeichnet Abhängigkeiten als Bögen, die auf der linken Seite nach unten und auf der rechten Seite nach oben laufen. Ein Graph-Algorithmus sortiert die Knoten so, dass möglichst wenige Bögen auf der rechten Seite liegen. Hinter einem Bogen können 167 Abhängigkeiten stecken, die Dicke folgt einer logarithmischen Skala. Im Beispiel reichen zwei Bögen, dann bleibt im nach Packages partitionierten Graphen nur ein Zyklus aus drei Knoten übrig. Per Virtual Refactoring wird das Entfernen zur Aufgabe, die Alexander an Claude gibt: „Und 20 Minuten später hat Claude die Kanten weggehauen und dann kann man zum nächsten Schritt übergehen.” Das Ziel sind inkrementelle Verbesserungen, nicht ein einziges großes Change-Set.

Grep reicht nicht: der MCP-Server als Quelle der Wahrheit

Ohne Werkzeug analysiert die KI Abhängigkeiten mit Grep, weil sie kein internes Dependency-Modell der Software hat. Auf Package-Ebene reicht das, bei Zyklen zwischen Java-Files versagt es. Auch das Language Server Protocol hilft nicht, weil ihm die semantische Phase fehlt, die Abhängigkeiten auflöst. hello2morrow hat deshalb einen MCP-Server gebaut, der das Dependency-Modell aus Sonargraph in Sekunden aufbaut. „Der ist die Quelle der Wahrheit”, sagt Alexander, und Claude „muss nie mehr Grep benutzen”. In einem Experiment mit dem Open-Source-Projekt jPOS, das über 4.000 Tests mitbringt, entfernte Claude Kante für Kante, ließ die Tests laufen und fragte den MCP-Server, ob die Struktur noch stimmt. Das Dependency Inversion Pattern mit Interfaces dreht dabei die Richtung einer Abhängigkeit um.

ArchUnit kommt zu spät

Für die zweite Säule, das Architekturmodell, vergleicht Alexander seinen Ansatz mit ArchUnit. ArchUnit prüft erst, nachdem der Agent den Code geschrieben hat, und beschreibt kein Modell, sondern eine Menge von Verboten, die man vorher alle vorhersehen muss. Ein Architekturmodell erlaubt dagegen zu messen, ob jede Klasse zu einer Komponente gehört, und Verletzungen zu beweisen. Der MCP-Server beantwortet zwei Fragen, bevor die erste Zeile Code entsteht: Ist diese Kante konform mit der Architektur, und erzeugt oder vergrößert sie einen Zyklus? Sprachmittel wie public und private reichen dafür nicht, weil sie nur auf Package-Ebene wirken, und Java-Module lassen sich nicht schachteln. Sein Wunsch: „die Sprache für das nächste Jahrtausend, dann würde die definitiv Architektur-Constraints mit drin haben”.

Die Architektur-DSL und Zügel

Alexander zeigt die textuelle Architektur-DSL von Sonargraph: Artefakte mit Include-Mustern, Relaxed Layering zwischen Geschwistern und Interfaces, die nur eine Teilmenge einer Komponente nach außen sichtbar machen. Claude verstand die Sprache nach wenigen Erklärungen, macht aber bei subtilen Dingen wie dem Pattern Matching Fehler. Deshalb steckt die Sprache im MCP-Server, der Zügel heißt, „der Zügel fürs Pferd, fürs Wildpferd, das in die falsche Richtung rennen will”. Er unterstützt Python, Java und C#. Auf den Prompt, eine Layered Architecture nach Domains zu erzeugen, schrieb Claude eine komplette Architekturspezifikation und hielt sich beim Codieren daran. In Alexanders eigenem Projekt verwischte Claude ohne klare Regeln die Grenzen zwischen den Sprachmodulen, bis er die Architektur von Hand nachschärfte.

Mehrere Agenten, CLAUDE.md und die CI-Pipeline

Richtig wichtig wird ein gemeinsames Architekturmodell, wenn mehrere Entwickler mit mehreren Agenten am selben System arbeiten. Regeln in CLAUDE.md sind für Claude nur eine Suggestion, eine formale DSL ist präzise und messbar. Im Vergleich baute sich Claude allein ein kleines Architektur-Framework auf Basis von Import-Statements; mit MCP-Server brauchte jeder Schritt weniger Tokens. Als Sicherheitsnetz gehört die Prüfung in die CI-Pipeline, wo Sonargraph Build dieselbe Sprache versteht. Grenzen gibt es bei dynamischen Abhängigkeiten: Python liefert kein vollständiges Modell, Reflection in Java bleibt unsichtbar. Zur Frage aus dem Chat, ob nicht alle nur Greenfield bauen, verweist Alexander auf die erste Hälfte der Folge: Genau bei der Modernisierung bestehender Systeme kommt man mit KI und Dependency-Modell „in die Nähe von dem magischen Fix-It-Button”.

Fazit

Die Folge beantwortet die Titelfrage mit einem klaren Ja. Eine saubere Struktur hilft Menschen und KI aus demselben Grund: Beide müssen verstehen, wo etwas hingehört. Alexanders Schlusswort: „das fundamentale Problem, wie bauen wir sauber strukturierte Software, das fundamentale Problem hat sich seit 30 Jahren nicht geändert. Es ist immer noch dasselbe.” Mit KI werde es noch wichtiger: „Je besser die Struktur, desto besser die Ergebnisse.”