Verstärkende Software-Architektur

Bevor wir uns der Frage widmen, wie wir Softwarearchitektur mit Hilfe von LLMs verbessern können, ist da noch ein Damoklesschwert, das es aus dem Weg zu räumen gilt. Brauchen wir in einer Welt mit Machine Learning und generativer KI überhaupt noch klassische Software (im folgenden Software 1.0) und Software-Architekturen?

Auch wenn KI-Systeme immer größere Teile des Codes ausmachen, gibt es Bereiche, die wir zumindest heute nicht einem probabilistischen System überlassen können: Physiksimulationen, Buchführung und überall dort, wo kein Platz für Halluzinationen ist, sondern exakte kalkulatorische Ergebnisse gefordert sind. Und für wenig komplexe Aufgaben ist Software 1.0 nach wie vor um Größenordnungen schneller als Software 2.0 (klassisches Machine Learning und große Sprachmodelle). "1+1" können beide, aber nicht in derselben Zeit: die Integer Addition in C dauert etwa 0,3 ns, eine lineare Regression liegt bei rund 100 ns und ein LLM mit sieben Milliarden Parametern benötigt dafür ungefähr 14 GFLOPs pro Token, auf einem 3 GHz Kern also fast eine Sekunde.

Sobald die Aufgabe komplexer wird, also mehr Dimensionen und Wechselwirkungen enthält, wandert das Optimum allerdings in Richtung Software 2.0. Rein regelbasiert ist vieles zwar theoretisch machbar, praktisch aber wegen des Entwicklungsaufwands und der Pflege oft nicht wirtschaftlich. Alle drei Softwarearten haben ihre Daseinsberechtigung, je nach Problemraum und Qualitätsanforderung.

Tatsächlich können KI-Systeme sogar Software 1.0 produzieren. Somit entsteht Software 3.0, die von großen Sprachmodellen erschaffen wurde und nicht mehr durch Menschen eingetippt werden muss [1].

Wenn Implementierung zunehmend von Systemen der dritten Kategorie unterstützt wird, stellt sich die Frage, worin der Wert von Architektur und Design liegt. Architektur und Design sind eine künstliche Abstraktionsebene über die eigentliche Logik. Der Computer braucht sie nicht, er führt Anweisungen aus. Wir Menschen brauchen sie allerdings, um Systeme und Teilsysteme zu verstehen und um innerhalb unserer kognitiven Grenzen gute Entscheidungen zu treffen [2].

Arbeiten auf einer Abstraktionsebene reduziert die geistige Last. Statt das gesamte System im Kopf zu halten, operieren wir analog der Fähigkeiten unseres Arbeitsgedächtnisses im Idealfall mit fünf oder weniger Elementen gleichzeitig [3].

Jetzt stellt sich die Frage: "Brauchen wir diese Beschreibung für Menschen noch, wenn künftig KI-Agenten große Teile der Implementierung übernehmen?" Ja, gerade dann. Ein künstlicher Architekt ist weit davon entfernt, unausgesprochene Annahmen oder Zwischentöne eines Kunden zuverlässig zu lesen. Was nicht gesagt wurde, was als selbstverständlich gilt, was im Kontext mitschwingt, muss herausgearbeitet und explizit gemacht werden. 

In einem Vergleichsexperiment entwarfen verschiedene LLMs zwar Architekturdiagramme, übersahen jedoch Randfälle, ignorierten reale Restriktionen und trafen keine bewussten Abwägungen. Die Kernerkenntnis: Automatische Entwürfe ohne Erfahrungswissen bleiben unvollständig. Architekturentscheidungen sind eng mit Domänen-Know-how, Geschäftskontext und Qualitätsanforderungen verknüpft. Hier bleiben menschliche Architekt:innen unverzichtbar [5].

KI-Agenten, die bei der Architekturarbeit unterstützen können, basieren auf textuellen Trainingsdaten. Sie werden dadurch zu Abbildern von Internetforen, Artikeln und Büchern und damit auch Abbildern der dahinterliegenden Denkhaltungen. Dadurch fungieren die menschlichen Abstraktionen als semantische Anker ebenfalls für LLMs und Agenten. [6].

Damit spannt Architektur die Brücke zwischen begrenzten kognitiven Fähigkeiten bei Menschen und begrenztem Kontext, "knowledge cut-off" und anderen Einschränkungen bei LLMs. Sie schafft eine gemeinsame, eindeutige Oberfläche, auf der Anforderungen, Qualitätsziele und Entwurfsentscheidungen greifbar werden.

Mehrere Architekturen auszuarbeiten war lange zu teuer und zu langsam. Das ändert sich, wenn Implementierung und Analyse stärker automatisiert werden. Wenn ein Agent viele Teile der Ausarbeitung übernimmt, kippt die Kostenkurve. Dann ist es plötzlich realistisch, drei und mehr Kandidaten nebeneinander zu prüfen, anstatt einen zu idealisieren. Genau dort entsteht Wert. Nicht in der perfekten Vorhersage, sondern in der geregelten Schleife aus Erzeugen, Prüfen und Verbessern.

Die Schleife selbst ist überschaubar. Wir formulieren Anforderungen und Ziele. Wir erzeugen mehrere Entwürfe mit klaren Unterschieden. Wir messen entlang definierter Metriken und dokumentieren Entscheidungen. Danach beginnt die nächste Runde. Wer möchte, kann das in einem Diagramm als Landschaft mit Tälern und Hügeln sehen. Die meisten Wege führen zunächst in lokale Täler, wie im Diagramm verdeutlicht wird. Der Trick ist, die Erkundung breit zu starten und die Auswahl dann zu fokussieren.

Zur Verdeutlichung des Vorgehens wird im Folgenden die Methodik anhand eines Fallbeispiels, aus einem aktuellen Projekt verdeutlicht.

1. Kandidaten erzeugen

Beim Arbeiten mit LLMs ist es ein probates Mittel, nicht direkt die Aufgabe durch das LLM durchführen zu lassen, sondern das LLM zu nutzen, um eigene Ansätze und Domänenwissen explizit zu machen. Dies verringert die Gefahr, das Gehirn abzuschalten und sich blind auf das zu verlassen, was LLM als richtig ansieht [10].

Prompt-Beispiel:

Stelle mir zu meinen Produktanforderungen eine Frage nach der anderen. Die Fragen sollen divers sein und Themen wie Domänenwissen, Nutzer:innen-Gruppen und Anforderungen abdecken. Ziel ist es, Schritt für Schritt eine Spezifikation für meine Software zu erarbeiten. Nachdem dich der Benutzer dazu auffordert, speichere die Ergebnisse als prd.md.
[Ausgangsanforderungen hier einfügen]

Statt nur eine Architekturidee zu verfolgen, starten wir bewusst mit mehreren, klar unterscheidbaren Entwürfen. Das reduziert die Gefahr, sich in einem lokalen Optimum festzulegen.

Prompt-Beispiel:

Generiere drei alternative Architekturansätze für das folgende prd.md. Achte darauf, dass sich die Ansätze im Stil möglichst unterscheiden.

Die LLM-Ausgabe dient als Ausgangspunkt. Der "Human-in-the-Loop"-Review, also die Verifizierung durch Architekt:innen ist dabei unverzichtbar, um Plausibilität, Konsistenz und Domänenkontext sicherzustellen.

2. Nutzungsszenarien ableiten

Architekturen entfalten ihren Wert erst im Kontext realer Nutzung. Deshalb erzeugen wir aus Stakeholder:innen- und Nutzungsperspektive konkrete Szenarien.

Prompt-Beispiel:

Leite aus folgendem PRD drei Nutzungsszenarien ab, die kritisch für die Systemlatenz sind. Beschreibe pro Nutzergruppe je den wichtigsten latenzkritischen Workload bzw. Interaktion. Speichere den Performanz-relevantesten Use Case in use_case.md.

Auch hier kuratieren Architekt:innen die Ergebnisse: Was relevant ist, wird übernommen, was unplausibel erscheint, verworfen oder angepasst.

3. Architekturen in Simulation überführen

Damit die Entwürfe vergleichbar werden, übersetzen wir sie in eine standardisierte Darstellung – einen gerichteten azyklischen Graph (DAG) der Verarbeitungsschritte.

Prompt-Beispiel:

Transformiere die Architektur archs/arch_02.md und den use_case.md in einen DAG. 
Speichere das Ergebnis im JSON-Format unter dags/dag_02.json.

4. Latenz simulieren

Die DAGs werden in ein LQN-Modell (Layered Queueing Network) übersetzt [11]. Damit können wir Ankunftsraten, Bedienzeiten und Parallelität abbilden. Das Simulationstool berechnet Besuchshäufigkeiten, Auslastungen und Antwortzeiten (mittels Erlang-C-Formel [12] und Mean Value Analysis [13]). Das Ergebnis ist eine End-to-End-Latenzanalyse, die Aufschluss über die zu erwartenden Latenzen des Systems gibt.

Aufruf:

uv run python performance_simulation.py dag_02.json

5. Agentischer Loop: Architekturen verbessern

Im letzten Schritt werden die Simulationsergebnisse nun zurück an das LLM gegeben, mit der Aufforderung, diese zur Optimierung der Architektur heranzuziehen. Somit entsteht ein agentischer Loop, in dem LLMs gezielte Verbesserungen wie Caching-Strategien, Edge-Verlagerungen oder Entkopplung von Services vorschlagen. Aus diesen Vorschlägen können nun wieder DAGs generiert und analysiert werden, wie in den Schritten 3-5 beschrieben.

Prompt-Beispiel:

Verbessere die Architektur archs/arch_02.md mit den folgenden Simulationsergebnissen: [Hier Simulationsergebnisse einfügen].
Ziel: bessere Latenz bei gleicher Robustheit. 
Speichere die neue Version als archs/arch_02_v2.md.

6. Ergebnisse vergleichen

Im Projekt wurden drei grundlegende Architekturstile generiert. Microservices und Serverless wurden ein- bzw. zweimal optimiert. Die Tabelle zeigt die End-to-End-Latenzen und die Anzahl an Komponenten, die das System ausmachen.

Die Ergebnisse zeigen: Serverless in der heutigen Form ist unvereinbar mit der Latenz-kritischen Anwendung. Erst durch komplexe Optimierungen (Caching, Edge, Streaming) wird es konkurrenzfähig. Allerdings um den Preis deutlich erhöhter Komplexität. Microservices mit Caching erreichten im Vergleich die niedrigsten Latenzen bei moderater Komplexität.