LLM erstellt Architektur?

LLMs sind insbesondere dafür geeignet, Texte zu generieren. Ein wesentlicher Teil der Architekturarbeit scheint das Erstellen von Texten zu sein: Architekturdokumentationen oder -konzepte gehören dazu. Und auch Diagramme können aus textuellen Repräsentationen generiert werden. Das scheint also ein Bereich zu sein, den LLMs autonom abdecken können. Und tatsächlich kann man ein LLM dazu veranlassen, eine Architektur in diesem Sinne zu erzeugen.

Kann das, was dabei entsteht, aber eine sinnvolle Architektur sein? Um dieser Frage nachzugehen, ist ein Fall interessant [2], bei dem ein LLM ein vorhandenes System analysieren sollte. Ergebnis: Das LLM hat einige Aspekte korrekt wiedergegeben, aber die Information, dass das System Apache ActiveMQ und Apache Artemis nutzt, war schlicht falsch. ActiveMQ und Artemis sind zwei Messagingsysteme. Solche Technologien sind eigentlich nur sinnvoll, wenn das System asynchron kommunizieren soll. Damit liegt die Analyse auf technologischer Ebene daneben, und sie erzeugt auch einen falschen Eindruck von der Architektur, denn so würde man wahrscheinlich von einer asynchronen Architektur ausgehen. Zudem ist Artemis eine Art Nachfolger von ActiveMQ. Das macht die Analyse nahezu grotesk, weil sie behauptet, dass zwei sehr ähnliche Technologien genutzt werden, eine davon eine modernere Variante der anderen. So etwas wäre nur dann zu erklären, wenn von der einen zur anderen Technologie migriert wird.

Würde ein Mensch bei einem Architekturreview eine so fehlerhafte Analyse erstellen, würde man vermutlich dem Rest der Analyse ebenfalls keinen Glauben schenken und die Person nie wieder mit einer solchen Aufgabe beauftragen. Beim LLM waren die Reaktion deutlich anders, es überwog eher ein Erstaunen. Warum sind die Konsequenzen hier anders? Es liegt nahe, grundsätzlich infrage zu stellen, ob LLMs für solche Architekturaufgaben überhaupt geeignet sind.

Halluzinationen

In dem konkreten Beispiel hat das LLM also im Text eine Information – nämlich die Nutzung von Artemis und ActiveMQ – ausgegeben, obwohl diese Information in der Wissensbasis nicht vorhanden war. Der Fachbegriff für solche Fehler sind „Halluzinationen“. Es gibt sie auch in anderen Variationen. So gibt es ein Beispiel, bei dem ein LLM Code erzeugen sollte und im Rahmen eines Tests die Produktionsdatenbank gelöscht hat, obwohl das explizit verboten war. Hier hat das LLM also eine explizite und wichtige Anweisung missachtet.

Solche Halluzinationen bedeuten, dass LLMs Fake-Informationen produzieren und bei Aktionen, die sie auslösen, unzuverlässig sind. Wenn man Architekturarbeit vollständig an LLMs delegieren will, ohne sie anschließend manuell zu überprüfen, müssten solche Halluzinationen praktisch ausgeschlossen sein.

Zuverlässige LLMs?

Damit kommt den Halluzinationen eine entscheidende Bedeutung zu, wenn es um die Bewertung der Nutzbarkeit von LLMs für die Softwarearchitektur geht. Halluzinationen sind ein Phänomen, das beim Entwurf von LLMs bewusst in Kauf genommen wird. LLMs sollen in erster Linie gute Dialoge mit Menschen führen können. Dafür sind ansprechende und überzeugende Texte wichtig, die Korrektheit ist sekundär. Das ist bei der Kommunikation zwischen Menschen nicht sehr viel anders: Wenn man in einem Gespräch jede Aussage validieren würde, käme der Dialog zum Erliegen. Bei einem wissenschaftlichen Paper ist die Korrektheit hingegen sehr wichtig; dafür dauert das Erstellen auch viel länger als eine Antwort in einem Dialog, weil jede Aussage geprüft wird und durch einen Prozess wie eine Peer Review auch noch andere Menschen die Aussagen validieren.

Letztendlich sind LLMs reine Textgeneratoren. Sie haben kein Konzept einer Wahrheit oder von Fakten, sondern generieren nur Text. Aufgrund der Trainingsdaten haben die Texte eine gewisse Wahrscheinlichkeit, korrekt zu sein, wenn in den Trainingsdaten nur korrekte Texte enthalten sind. Aber logische Denkprozesse gibt es bei LLMs nicht.

DIE KUNST DER SOTWARE-ARCHITEKTUR

Architecture & Design-Track entdecken

Mehr erfahren

Man kann die Ergebnisse von LLMs nicht als Lügen klassifizieren. Lügen würden bedeuten, dass das LLM ein Konzept von Wahrheit hat und bewusst Texte erstellt, die dieser Wahrheit widersprechen. LLMs haben aber ein solches Konzept von Wahrheit nicht. Noch dazu sollte eine Lüge einer Absicht folgen. Wenn man beispielsweise behauptet, man hätte viel mehr Geld als man tatsächlich hat, stellt man eine Behauptung auf, die der Wahrheit widerspricht. Typischerweise verfolgt man damit ein Ziel, beispielsweise einen Menschen zu beeindrucken. Wegen dieser beiden Umstände ist es eine Lüge.

Anders ist es bei Bullshit: Da trifft man Aussagen ohne Rücksicht auf den Wahrheitsgehalt. Wer bei einer Prüfung beispielsweise den Stoff nicht beherrscht, kann irgendwelche Aussagen treffen. Ob sie wahr sind oder nicht, muss einem egal sein, weil man den Stoff nicht beherrscht. Entscheidend ist, die Prüfung zu bestehen, und wenn man ausreichend kompetent wirkt und keinen zu offensichtlichen Unsinn erzählt, kann das vielleicht gut gehen.
LLMs produzieren in diesem Sinne Bullshit, weil sie manchmal Fake-Informationen (Halluzinationen) produzieren, aber weder ein Konzept von Wahrheit haben noch eine Intention und daher nicht lügen [5]. Die Wahrheit ist ihnen noch nicht einmal egal, weil sie kein Bewusstsein haben, dass solche Entscheidungen treffen könnte, und keine Wissensbasis mit einer Wahrheit.

Damit ist sehr gut zu erklären, wie die ActiveMQ/Artemis-Fehlinformation zustande gekommen ist: Es ist schlicht ein generierter Text, der plausibel klingt, aber ohne Rücksicht auf Wahrheit erzeugt wurde.

Kritisch hinterfragen

Also muss man die Ergebnisse eines LLMs kritisch hinterfragen. Dann trifft man aber selbst die Architekturentscheidungen und nicht das LLM. Das ist auch sinnvoll, denn am Ende wird man wohl kaum die Verantwortung für ein Architekturproblem auf ein LLM abschieben können. Und selbst wenn das geht: Es ist auf jeden Fall besser, die Probleme frühzeitig zu erkennen und zu lösen.

Leider hat unsere Branche aber beim kritischen Hinterfragen und dem Treffen eigener Entscheidungen oft Schwächen. Deshalb ist es nicht ungewöhnlich, dass eine Architektur so entworfen wird, „weil man das eben heute so macht“ oder „weil das eine bekannte Person auf einer Konferenz so erläutert hat“. Natürlich ist es denkbar, dass sich in Zukunft die Begründung „weil das LLM es so entschieden hat“ dazu gesellt. Es ist sogar praktisch, weil man so Verantwortung abschieben kann. Dennoch sollten Softwarearchitekt:innen anders arbeiten und selbst Verantwortung übernehmen.

Text ist nicht Architektur

Wichtig dabei: Das LLM generiert genau genommen nur einen Text und keine Architektur. Das wirkt zunächst wie Haarspalterei. Aber tatsächlich kann man eine umfangreiche Architekturdokumentation schreiben, die alle möglichen Dinge erläutert, aber eben nicht die Hauptrisiken und die wichtigsten Entscheidungen definiert. Wenn man eine große Menge Text erzeugt, kann das sogar eher dazu führen, dass wichtige Entscheidungen irgendwo in dieser Textwüste begraben sind. Aber attraktiv ist es dennoch: Schließlich werden ja irgendwo in dieser Textmenge sicher alle Probleme diskutiert und gelöst sein.

Die Realität ist jedoch, dass solche umfangreichen Architekturdokumentationen existieren, die dennoch nichts über die wesentlichen Probleme aussagen, und erst bei einer Review – idealerweise mit einem unverstellten Blick von außen – fällt das auf. Das passt zum Phänomen des „Architekturtheaters“ [9], bei dem ein komplexer, bürokratischer Architekturprozess aufgesetzt wird, der am Ende aber die eigentlichen Herausforderungen und Themen nicht identifiziert. Insofern ist es nachvollziehbar, dass das Generieren von Text, wie es LLMs ermöglichen, wie Architekturarbeit wirkt. Sicher kann mit einem LLM das Generieren einer Architekturdokumentation als Scheinlösung umgesetzt werden – und sie kann sehr umfangreich sein und sehr überzeugend wirken. Eine sinnvolle Architektur stellt der Text dennoch nicht dar.

Worauf kommt es an?

Hilft ein solcher Text dann überhaupt? Wenn man Menschen danach fragt, was der wichtigste Skill in der IT ist, kommt mit einer überwältigenden Mehrheit als Antwort „Kommunikation“ oder etwas anderes im Bereich Social Skills [9]. Ähnliches gilt bei der Frage nach der Hauptherausforderung im Bereich Softwarearchitektur [1]. Auch dort geben Menschen typischerweise Themen wie Kommunikation, Organisation oder das Vermitteln zwischen Business und Technik an.

Aus diesen Gründen ist es so sinnvoll, Softwareentwicklung als soziotechnischen Prozess zu begreifen – also als einen Prozess, der sowohl eine technische Seite als auch eine soziale Seite hat. Dieser Ansatz hat sich gerade in letzter Zeit als vorteilhaft für Architekturarbeit gezeigt und stand auch wiederholt im Zentrum dieser Kolumne. Ansätze wie kollaborative Modellierung beispielsweise mit Event Storming unterstützen die notwendige Kollaboration beim Erstellen der Artefakte, haben also eine soziale Komponente. Nicht nur die Artefakte selbst, sondern auch der soziale Prozess, mit dem diese erstellt werden, wird zunehmend als wichtig erkannt, weil dabei Rollen und Zusammenspiel der Menschen deutlich wird. Und in diesem Bereich existieren oft die größten Herausforderungen.

Es wirkt wenig wahrscheinlich, dass man soziotechnische Probleme wie Softwarearchitektur dadurch lösen kann, dass man mit einem LLM allein vor dem Rechner einen Text erzeugt. In der Praxis besteht eine wichtige Aufgabe von Architekt:innen darin, mit Stakeholdern über Ziele, Ausrichtung und Randbedingungen zu diskutieren und technische Entwürfe mit Techniker:innen zu besprechen. Ein Projekt kann nur erfolgreich sein, wenn alle Stakeholder abgeholt sind und sich abgeholt fühlen. Und schließlich sind die Anforderungen bzw. Qualitäten zentral – egal ob funktional oder nichtfunktional. Wenn man diese Rahmenbedingungen nicht geklärt hat, baut man schlichtweg das Falsche. Die Techniker:innen müssen ebenfalls überzeugt sein, weil sie sonst die Entwürfe unterlaufen, und durch die Diskussion mit ihnen ergeben sich oft noch bessere technische Alternativen.

Wie also LLMs nutzen?

Aber man kann natürlich ein LLM Architekturentwürfe generieren lassen – wenn man es ethisch verantworten kann. LLMs sind schließlich sehr energieintensiv und Menschen müssen sie unter fragwürdigen Arbeitsbedingungen trainieren. Und die Entwürfe müssen kritisch hinterfragt und abgestimmt werden. Ob dadurch die Architekturarbeit einfacher wird, ist fraglich: Denn am Ende muss man einen Architekturentwurf kritisch prüfen und abstimmen, der ohne ein Konzept von Wahrheit entstanden ist und dazu noch überzeugend präsentiert wird.

Natürlich ist es denkbar, mit einem LLM statt einer ganzen Architekturdokumentation Texte zu bestimmten technischen Fragestellungen oder zu einzelnen architekturellen Entscheidungen zu generieren – so wie man sonst auch im Web nach solchen Informationen sucht. Man bekommt dann auf der einen Seite maßgeschneiderte Aussagen, die aber auf der anderen Seite Fake-Informationen bzw. Halluzinationen sein können. Oft ist dieser Ansatz aber tatsächlich der schnellere und einfachere Weg zum Ergebnis.

Am Ende liegen aber Verantwortung und Entscheidungsgewalt bei beiden Vorgehensweisen bei der Architekt:in. Das kritische Hinterfragen und Einarbeiten der Ergebnisse des LLMs ist ihre Aufgabe. Sie ist dann auch verantwortlich und nicht das LLM – so wie eben der Autor einer Webseite oder eines Buchs auch nicht dafür verantwortlich sein kann, was mit seinen generellen Aussagen in einem spezifischen Projekt geschieht.

Damit sind LLMs ein weiteres Werkzeug im Architekturwerkzeugkoffer. Der ist mit einer Vielzahl anderer Werkzeuge gefüllt – dazu zählen kollaborative Modellierung, Domain-driven Design und Architekturdokumentationsansätze wie arc42. Es erscheint unwahrscheinlich, dass LLMs die Produktivität von Architekt:innen massiv erhöhen oder sie überflüssig machen, wie das andere Werkzeuge auch nicht geschafft haben. Aber es gibt wahrscheinlich Einsatzmöglichkeiten wie für alle anderen Werkzeuge auch.

Fazit

Es ist zunächst wichtig zu verstehen, dass die Ergebnisse von LLMs prinzipienbedingt unzuverlässig sind, weil sie Halluzinationen bzw. Fake-Informationen erzeugen können. Daher muss man die Ergebnisse von LLMs immer kritisch hinterfragen – auch und gerade, weil sie so überzeugend sind. Und LLMs lösen nicht das zentrale Problem der Softwareentwicklung, das vor allem im Bereich Kommunikation und sozialen Faktoren liegt. Dass das die wesentlichen Probleme sind, ist der breiten Mehrheit klar [1],[10]. Warum dann LLMs massive Vorteile bringen sollen, bleibt offen – aber sie sind sicher ein interessantes Werkzeug, das man prinzipiell auch in der Softwarearchitektur einsetzen kann, wenn man es ethisch vertreten kann.

Links & Literatur

[1] Softwarearchitektur im Stream: „Was ist die Hauptherausforderung der Software-Architektur?“: https://software-architektur.tv/2025/06/27/folge269.html

[2] Mahler, Dirk: https://www.linkedin.com/posts/dirk-mahler-837a4b5_ai-neo4j-claude-activity-7321596753223340033-xz4r

[3] https://x.com/jasonlk/status/1946065483653910889

[4] https://arxiv.org/html/2202.03629v7

[5] Softwarearchitektur im Stream: „KI = Bullshit“: https://software-architektur.tv/2025/04/11/episode260.html

[6] https://winfuture.de/news,150778.html

[7] https://www.nature.com/articles/s41562-025-02194-6

[8] Softwarearchitektur im Stream: „Besteht ChatGPT die iSAQB-Advanced-Level-Prüfung? 2/2 mit Ralf D. Müller“: https://software-architektur.tv/2024/01/19/folge197.html

[9] https://mastodon.social/@kevlin/112003129757159797

[10] Softwarearchitektur im Stream: „Was ist der wichtigste Skill in der IT?“: https://software-architektur.tv/2024/08/16/episode228.html