Softwarearchitektur im Zeitalter der KI
🇬🇧 Read in English~7 min read
software-architekturkillmmicroservicesagentic-systemsobservabilitydevops
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Architektur war immer die langsame Schicht der Software. Anforderungen wechselten wöchentlich, Frameworks jährlich, aber die Form des Systems — die Grenzen, die Abhängigkeitsrichtungen, die Entscheidungsprotokolle — die änderte sich in Jahren. Der Forschungskorpus erzählt heute eine andere Geschichte. Von 20.301 Software-Development-Papers, die im vergangenen Jahr aufgenommen wurden, befassen sich 576 direkt mit Softwarearchitektur — und 74 Prozent davon erschienen allein im Jahr 2026. Das Feld wächst nicht. Es explodiert.
Zwei Transformationen überlagern sich in diesen Papers, und sie zeigen in entgegengesetzte Richtungen. KI verändert, wie Architektur entsteht. Und Architektur erweist sich als die Disziplin, die entscheidet, ob KI-gebaute Software den Produktionsbetrieb überlebt.
Klassifikation meines eigenen Korpus. Der blaue Balken — KI und LLM explizit in einer Architektur-Rolle — existierte vor 2024 praktisch nicht.
Das Anker-Paper des Korpus ist Architecture Without Architects, und der Titel ist bereits der Befund. KI-Coding-Agenten treffen tausende kleine Strukturentscheidungen — diese Logik kommt in dieses Modul, dieser Service ruft jenen auf, diese Abhängigkeit zeigt in diese Richtung — und fast keine davon durchläuft eine menschliche Review-Schleife. Die Entscheidungen passieren weiterhin. Sie werden nur nicht mehr protokolliert, diskutiert oder verantwortet.
Die traditionelle Antwort auf dieses Problem war das Architecture Decision Record. Der Korpus enthält weiterhin ADR-Forschung — 19 Papers — und 30 Papers zur Architektur-Rekonstruktion, der Kunst, Struktur aus Code zurückzugewinnen. Doch beide Disziplinen setzen voraus, dass Entscheidungen eine Spur hinterlassen. Wenn ein Agent eine Zerlegung in vierzig Sekunden erzeugt, ist die Spur ein Chat-Log, das niemand archiviert.
Der Korpus quantifiziert die Verschiebung: KI-nahe Architektur-Papers gehen von praktisch null vor 2025 auf 24 Prozent der Kategorie im Jahr 2025 und 30 Prozent im Jahr 2026 hoch — sichtbar als blauer Balken in der Abbildung oben. Das ist der leise Putsch: Nicht, dass KI schlechte Architektur schreibt, sondern dass Architekturentscheidungen ihren Review-Prozess verloren, bevor jemand bemerkte, dass sie einen neuen brauchen.
Von textuellen Anforderungen zu Microservice-Architekturen zeigt, wohin das führt: natürliche Sprache als Anforderung hinein, eine Kandidaten-Zerlegung in Microservices heraus. Die Zerlegung war der Kronjuwel der Architekten — die Aufgabe, für die man Senior-Leute einstellt. Sie wird eine Generierungsaufgabe.
Generieren ohne Verifikation ist Raten, deshalb ist das wichtigere Paper sein Gegenstück: Strukturelle Validierung LLM-generierter Microservice-Zerlegungen. Die Autoren lassen OpenAI o3 auf den klassischen Fallstudien PetClinic und Bookstore laufen, vergleichen Zero-Shot mit Few-Shot-Prompting und bewerten die Ergebnisse auf zwei Achsen: kompiliert es und bestehen die Tests, und ist die Struktur tatsächlich gut — Kopplung, Kohäsion, Stabilität der API-Oberfläche? Die Ergebnisse unterscheiden sich massiv. Gleiches Modell, gleiche Aufgabe, andere Prompt-Disziplin, andere Architektur.
Die Lehre generalisiert über die Zerlegung hinaus. Jedes LLM-generierte Struktur-Artefakt — Modul-Layout, Interface, Schema — ist eine Hypothese, die eine Validierungs-Pipeline braucht. Die Papers, die 2026 zählen, sind nicht die, die Struktur erzeugen. Es sind die, die sie prüfen.
Eine zweite Welle behandelt KI nicht als Code-Generator, sondern als Laufzeit-Komponente — und stellt die alte Frage mit neuem Material: Wie strukturiert man ein System, dessen Teile nichtdeterministische Agenten sind?
Architectural Patterns for Multi-Agent Systems katalogisiert die entstehenden Antworten — Orchestrator-Worker, Blackboard, hierarchische Delegation, marktbasierte Koordination — im Kern das klassische Musterbuch verteilter Systeme, neu illustriert mit Agenten. Is Three the Magic Number? liefert die empirische Korrektur: optimale Agentenzahlen sind klein, und die Erträge sinken schnell. Fünf Agenten sind nicht dreimal besser als einer; sie sind ein System mit fünf Fehlermodi.
Das nützlichste Paper dieses Clusters dürfte Agentic AI Between Capability and Reliability sein. Seine These: Jeder Fähigkeitsgewinn in agentischen Systemen bringt eine Zuverlässigkeitsschuld mit sich — und die architektonische Antwort sind nicht bessere Modelle, sondern begrenzte Autorität: skopierte Berechtigungen, Human-in-the-Loop-Checkpoints, Sandboxes, reversible Aktionen. Multi-Agenten-Systeme sind noch ein junges Thema (34 Papers), aber sie sind die am schnellsten wachsende Zelle im Korpus.
Wenn Microservices (317 Papers) den Korpus dominieren, sind Observability (107) und Incident Response (71) sein Nervensystem — und 2026 werden beide miteinander verdrahtet.
ORCA führt Root-Cause-Analyse und Reparaturvorschläge in einer Schleife zusammen. GALA lässt LLM-Agenten strukturelle Änderungen am Code vorschlagen, verifiziert vor dem Merge. Beyond Fault Localization argumentiert, die Grenze habe sich bereits verschoben: Die Fehlerlokalisierung war Schritt eins, und die interessante Frage ist, was auf die Diagnose folgt. OpsMem ergänzt die fehlende Zutat — operative Erinnerung, damit sich die Incidents einer Organisation im Vorwissen eines Agenten ansammeln, statt in Post-Mortems zu verdampfen. Und föderierte Observability behandelt die organisatorische Variante: Telemetrie-Muster für Systeme, deren Komponenten ganz verschiedenen Teams gehören.
Der konzeptuelle Rahmen ist alt — der MAPE-K-Regelkreis der autonomen Informatik: Monitor, Analyze, Plan, Execute über geteiltem Wissen. Geändert hat sich, dass die Slots Analyze und Plan, die ein Jahrzehnt regelbasierter Selbstheilungssysteme besiegt hatten, nun von einem LLM gefüllt werden können. Der Haken ist derselbe, den die Muster-Papers aufwerfen: Ein Reparatur-Agent ist ein Agent. Er braucht Guardrails — sonst wird Ihr selbstheilendes System zu Ihrer kreativsten Incident-Quelle.
Drei Konzepte wandern aus dem KI-Engineering in den allgemeinen Architektur-Wortschatz.
Skills als deploybare Einheiten. Microskill Architecture und Skillware behandeln Agenten-Skills wie Deployment-Artefakte — versioniert, testbar, verantwortet. Die Deployment-Einheit eines KI-Systems ist nicht mehr nur ein Container; es ist auch der Skill, der dem Agenten sagt, was er kann.
Kontext als architektonische Oberfläche. Prompts, Retrieval-Konfigurationen, Tool-Manifeste, Speicher: Das bestimmt Systemverhalten inzwischen ebenso wie Code — und ändert sich in einem anderen Takt. Architekturdiagramme ohne die Kontext-Pipeline sind unvollständig.
Nichtdeterminismus als modellierte Eigenschaft. Graphical-Probabilistic Modeling of Generative Flows ist das zukunftsweisendste der drei: Es modelliert generative Komponenten probabilistisch, sodass Unsicherheit eine erstklassige Architektur-Eigenschaft wird — statt eines nachgelagerten Testthemas.
Der Korpus behält seine Skeptiker, und sie sind lesenswert.
Ein empirischer Vergleich von Monolithen und Microservices misst, was die Migrationen behaupten: In vielen Workloads gewinnt der Monolith bei Latenz und Kosten, und die Microservice-Prämie kauft unabhängige Deploybarkeit, nicht Geschwindigkeit. Ein systematisches Review zur Energieeffizienz in Microservice-Architekturen ergänzt die Umweltrechnung. Und DeepRepoQA dokumentiert eine unbequeme Rekursion: Die KI-Agenten, die unsere Architektur umformen, tun sich weiterhin schwer damit, große Repositories zu navigieren — die Struktur der Codebasis ist Teil der User Experience des Agenten.
Die alten Debatten verschwinden im Zeitalter der KI nicht. Sie bekommen neue Messwerte.
Nichts davon eliminiert den Architekten. Es schreibt die Rolle neu — hin zu Verifikation und Grenzen:
Die Einzeiler-Zusammenfassung von 576 Papers: Im Zeitalter der KI ist die knappe Ressource nicht mehr die Fähigkeit, einen Entwurf zu erzeugen. Es ist die Fähigkeit zu wissen, ob der Entwurf — von Mensch oder Maschine — hält.
Die Statistiken oben stammen aus meinem eigenen Forschungskorpus: 20.301 Papers zur Softwareentwicklung (576 zur Softwarearchitektur), gesammelt über arXiv und OpenAlex und kontinuierlich neu klassifiziert. Die Methodik liegt in software-development-research.