# AI-Driven Architecture Analysis for Enterprise Software Systems

**Podcast:** Software Architektur im Stream
**Published:** 2026-04-07

## Transcript

Hallo, ich bin Eberhard Wolff.
Freitags mache ich oder Lisa Moritz einen Livestream zum Thema Softwarearchitektur, oft zusammen mit Gästen.
Dieser Podcast ist das Audio des Streams.
Weitere Folgen, Sketchnotes und vieles mehr findet ihr unter software-architektur.tv.
So, dann herzlich willkommen zu einer weiteren Episode von Softwarearchitektur im Stream.
Dieses Mal zum Thema Analyse großer Software-Systeme mit LLMs mit Michael Stahl.
Michael, erstmal vielen Dank, dass du dir die Zeit genommen hast und dass du da bist.
Michael, möchtest du kurz zwei Worte über dich sagen?
Zwei Worte ist zu wenig, aber ich mache es trotzdem.
Ich bin seit 1991 bei Siemens, forsche da an Themen wie Softwarearchitekturen, verteilte Embedded-Systeme und jetzt eben seit einigen Jahren eben auch Richtung AI oder künstlicher Intelligenz, KI.
Ja gut, ich habe noch eine Professur in Köln.
Da geht es eher um Architekturen und Architektenausbildung.
Ja, und mehr gibt es eigentlich nicht zu sagen über mich.
Außer vielleicht, dass wir die Pattern-Oriented Software-Architecture-Buchserie geschrieben haben, deren erster Band vor genau 30 Jahren veröffentlicht worden ist.
Das fühlt sich an wie gestern.
Und genau, mir fiel auch gerade auf, dass ich deinen Professor-Doktor-Titel unterschlagen habe.
Es geht ja heute um dieses Siemens Architecture Review.
Review-Agent heißt das Ding, glaube ich, Sarah.
Und bevor wir, also auf der Agenda steht halt irgendwie die Frage, was ist das eigentlich, wie funktioniert das?
Und das Ganze basiert halt auf dem Vortrag bei der OP, den du ja darüber gehalten hast.
Beziehungsweise das war der Anlass, also darauf basiert es halt gar nicht so sehr, sondern das war der Anlass, weswegen ich dachte, es wäre spannend, darüber zu reden.
Und da ist für mich insbesondere interessant, was sind eure, sozusagen eure Praxisherfahrung, gerade in dem AI-Bereich gibt es ja eine Menge an Hypes.
Und nachdem ihr nicht selber ein Produkthersteller seid, sondern es sozusagen selber euch überlegt und umgesetzt habt, fand ich es halt ganz spannend, mal mit jemandem zu reden, der da jetzt nicht versucht, irgendwas zu verkaufen.
Führt dann zu der ersten Frage, warum habt ihr das gebaut?
Also eigentlich ist das ja ein Werkzeug zur Architekturanalyse, so habe ich das verstanden.
Das ist halt ein etablierter Markt, da gibt es irgendwie verschiedene Werkzeuge.
Jetzt könnte man ja sagen...
Ich erwarte, dass ich sowas halt einfach irgendwo kaufen kann oder ich kaufe es vielleicht auch irgendwo und stattdessen habt ihr ja angefangen, es halt irgendwie selber zu bauen.
Warum?
Der Grund bei uns ist, wir machen ja relativ häufig Software-Architektur-Reviews für unsere Business Units, also zum Beispiel Fahrkartensysteme oder Ladestationen für elektrische Autos und solche Geschichten.
Und da sind wir oft gefragt, in relativ kurzer Zeit, ein Eindruck, von den Software-Architekturen, die die halt haben, zu bekommen.
Und das Problem ist halt, wenn du dich als, sag ich mal, Zwei- oder Drei-Mann-Team da hinstellst und versuchst, den Code innerhalb von kurzer Zeit zu verstehen, dass du da klar an die Grenzen kommst.
Weil da waren meinetwegen 60 Leute für mehrere Jahre dran gesessen und das ist halt chancenlos, da zu versuchen, durch jede Codezeile zu gehen.
Und das ist halt immer...
Das hat uns schwergefallen oder wir haben es dann doch hingekriegt, weil wir ja auch Interviews geführt haben mit den Leuten.
Aber es war die Idee, wieso bauen wir nicht ein Werkzeug auf Basis von KI, das quasi uns zumindest ein wenig Aufgaben abnimmt.
Also das quasi selber sucht, versteht, was die Architektur denn macht und wo vielleicht noch irgendwelche Defizite drin sind, die man verbessern könnte.
Und das ist ja nicht nur die Architektur.
Das ist ja nicht nur die Architektur selber, sondern auch, wie ist die Organisation, was sind die Geschäftsziele, kann diese Architektur überhaupt die Geschäftsziele sozusagen unterstützen und derlei Fragen tauchen ja auch auf.
Weil du gesagt hast, es gibt auch Grenzen.
Vielleicht nur ein Punkt schon mal vorab.
Eine Grenze ist, dass viel Wissen ja natürlich nicht in dem Code steckt oder in irgendwelchen Dokumenten, sondern in den Köpfen der Entwickler oder Architekten.
Und da ist natürlich...
Da ist natürlich für ein KI-basiertes Review-System eine Grenze erreicht, weil da muss ich quasi Human Insel Loop einbauen.
Ich muss also Menschen dazunehmen, die mir dann erzählen oder in dem Fall dem System erzählen, warum jetzt welche Architekturentscheidung getroffen wurde zum Beispiel.
Oder wie dieses, sag ich mal, schlampiges Design zustande kam und dann bekommst du dann Antworten und kannst sie entsprechend eingeben.
Und uns entsprechend dann verarbeiten.
Das war so unser Grund.
Und ich meine, vielleicht, Entschuldigung, dass ich die unterbreche, noch ein zweiter Punkt.
Wir hatten einen Kunden oder wir haben einen Kunden, das ist die Siemens Mobility.
Und zwar ist das die Bahninfrastruktur.
Und die haben auch Systeme, die teilweise mehrere Jahrzehnte alt sind.
Und wo die Architekten, Entwickler teilweise nicht mehr in-house sind.
Und wo die auch Interesse haben, so ein System zu machen.
Und so ein System zu verwenden, um eben ihre eigenen Architekturen wieder zu verstehen und zu untersuchen.
Also was bedeutet, ihr habt halt einen hohen Bedarf, eben selber Reviews zu machen.
Das heißt, ein Werkzeug im Allgemeinen ist erstmal sinnvoll.
Das ist, glaube ich, also das ist für mich sofort nachvollziehbar.
Jetzt wäre ja für mich die Frage, warum LLMs?
Da habe ich jetzt irgendwie so das Gefühl mitgenommen, naja, also ich kann damit eben zumindest so Architekturdokumentationen und sowas.
Ja, der erschließt.
Und deswegen ist es halt eine LLM.
Ist das so die Richtung oder gibt es da irgendwie was?
Ist die Richtung, weil das Problem ist.
Also natürlich, du hast jetzt Standard, Review oder Architektur-Assessment-Werkzeuge.
SonarCube und Understand und wie die auch immer heißen mögen.
Die gehen aber an ihre Grenze, weil sie ja nur Syntax verstehen im Endeffekt.
Und LLMs ist halt die Hoffnung, die verstehen ja auch Semantik, können sich auch ein Bild machen.
Worum es da in dieser Applikation?
Auch von der semantischen Seite aus.
Und deswegen reichen bloße Architektur-Assessment-Tools nicht aus.
Aber wir können auch in unserem Werkzeug solche Tools integrieren, um deren Ergebnisse halt auch zu bekommen.
Führt ja dazu, dass du im Prinzip sagst, wenn ich so etwas machen will wie eine Architektur-Review, ist eben ein LLM-Ansatz sinnvoll.
Das ist ja jetzt nicht eine Aussage, die halt spezifisch ist nur für Siemens, sondern die geht ja, würde ich behaupten, für Software-Architektur im Allgemeinen.
Führt für mich zu der Frage, gibt es da nicht einen Tool-Hersteller, der sowas anbietet?
Habt ihr euch das angeschaut?
Also wir haben es angeschaut und nichts gefunden.
Es gibt natürlich die normalen, sag ich mal, Cloud-Code und Copilot und Cursor und Windsurf und wie die alle heißen.
Das Problem von diesen Werkzeugen ist, die sind zwar recht gut zur Software-Entwicklung, aber sie verstehen nur einen relativ kleinen...
lokalen Kontext.
Und wenn du jetzt zum Beispiel ein größeres Git-Repository hast, wo teilweise Millionen Zeilen Code drinstecken, daran scheitern diese Tools.
Aber so ein richtiges Architektur-Analyse-Tool habe ich zumindest auf Basis von KI nicht gefunden.
Also wäre mir auch neu, dass da eines existiert.
Ich kann mir aber vorstellen, dass wahrscheinlich welche an sowas bauen.
Wäre also nicht überraschend.
Genau.
Und das ist ja auch das, was, glaube ich, dein Talk-Titel bei der OOP auch gesagt hat und was auch der Titel dieses Streams halt sagt, dass es eben um große Software-Systeme geht.
Und vielleicht sozusagen zum Hintergrund, ich habe halt, also wie soll ich sagen, du kümmerst dich um das Thema KI ja schon an verschiedenen Stellen und auch schon deutlich länger.
Das heißt, das ist jetzt irgendwie nicht so eine Aussage von, also du hattest das bei deiner Vorstellung nicht so explizit gesagt, aber ich kriege halt von dir immer wieder so auf Social Media, und auf LinkedIn und so Hinweise, dass du halt da ganz viele Sachen machst.
Das ist also dann eben nicht nur, du hast nicht nur einen Assault- und Software-Architektur-Hintergrund, sondern eben auch, glaube ich, einen Hintergrund in dem AI-Bereich, sodass das, glaube ich, gut belastbare Aussagen erstmal sind in dem Jahr.
Gut, wollen wir kurz darüber, oder wollen wir darüber sprechen, wie dieses System aufgebaut ist?
Da gibt es ja einige Sachen, die über so Retrieval-Augmente, über RAC angewendet werden.
Schlossensinn, was ist RAC, was habt ihr da angeschlossen und wie funktioniert der Teil?
Also wir haben im Prinzip zwei Komponenten.
Das eine ist eben RAC, das steht ja für Retrieval Augmented Generation.
Das ist im Prinzip ein LLM-Modell, kann ja nur Wissen in sich tragen, das quasi bis zu einem Trainingszeitpunkt eben vorhanden war.
Weiß aber jetzt weder, wie es bei einem Siemens-Projekt lokal ausschaut, noch kennt es neuere.
Und das RAC ist im Prinzip, ich nehme irgendwelche Dokumente, die werden dann in sogenannte Chunks zerlegt.
Die Chunks werden in sogenannte Embeddings umgewandelt, das sind also Vektoren im höherdimensionalen Vektorraum und werden in eine Vektordatenbank eingespeist.
Und wenn ich dann eine Frage habe, dann kann ich eben erst in dieser Vektordatenbank nachschauen, mit Similarities.
Also welche Inhalte in dieser Datenbank passen am besten zu der Benutzeranfrage.
Und diese Ergebnisse schicke ich zusammen mit einem Kontextinformationen zum LLM.
Und die kann also quasi diese Ergebnisse nutzen, um die Anfrage zu beantworten.
Also sie kann dann quasi auf echten faktischen Daten entsprechend arbeiten.
Und das zweite, was wir machen, ist Knowledge Grafen.
Knowledge Grafen sind im Prinzip so Graf-Datenbanken, beziehungsweise unterstützen Graf-Datenbanken.
Und da geht es darum, welche Abhängigkeiten bestehen zwischen Komponenten.
Also das kann jetzt quasi eine enthält, ruft auf, ist abgeleitet oder vererbt von Klasse X und solche Geschichten sein.
Sodass man auch die, sag ich mal, semantische Struktur ein bisschen besser erkennt.
Und was wir jetzt festgestellt haben in Versuchen ist, dass man, wenn man nur REC nimmt, wesentlich schlechter dasteht, als wenn man primär erstmal Knowledge Grafen verwendet und dann zusätzlich Retrieval Augmented Generation Embeddings.
Weil scheinbar eben diese ganze, sag ich mal, Entity Relationships, die da drin sind, aus dieser Knowledge Datenbank besser hervorgehen.
Also da bekommt die KI eine bessere Übersicht.
Was sind jetzt Module?
Klasse?
Klasse und so weiter.
Wie hängen die voneinander ab und dergleichen?
Welche Art von Daten füttert ihr darüber in dieses System rein?
Oder welche Art von Informationen?
Wir füttern zum einen natürlich das System rein, also den Code inklusive Konfigurationsdateien, Readmes und was immer.
Und vielleicht, wenn man Glück hat, sind auch noch ADRs drin.
Also so Architecture Decision Records.
Bildfiles und dergleichen.
Das ist quasi.
Alles, was so auf der Software-Ebene stattfindet.
Wir füttern allerdings auch ein Meeting Notes oder Folien, Präsentationen, die von dem, sag ich mal, Architektur-Treiber oder dem Business Unit halt erstellt worden sind.
Auch irgendwelche Minutes, Protokolle, die da eben sagen, irgendwelche Entscheidungen zum Beispiel enthalten.
Und alles zusammen führt eben dazu, dass man die Architektur nicht nur hinsichtlich des Codes, sondern auch hinsichtlich, zum Beispiel erfüllt diese Architektur die Ziele, die wir uns gegeben haben.
Welche Entscheidungen wurden wann getroffen und warum?
Also da bekomme ich wesentlich mehr Informationen in das System rein, als ich normal hätte, wenn ich nur ein Repository verwenden würde.
Und ich glaube, an der Stelle ist ja nochmal klar, dass es eben etwas ist, wo LLMs eben mit dem textbasierten Ansatz vielleicht tatsächlich hilfreich sind.
Ich meine, eine Grenze gibt es.
Da haben wir ja vorher drüber gesprochen.
LLMs wissen natürlich nicht, was in den Köpfen von Projektbeteiligten steckt.
Sprich, also jedes dieses System, das quasi auf Basis von AI so ein System analysiert, muss irgendwie einen Jugend in den Loop-Ansatz fahren.
Sodass quasi, wenn jetzt irgendwelche Fragen seitens des LLMs dann entstehen, Menschen beantworten können, warum wurde diese Architekturentscheidung getroffen, wieso habt ihr die, oder wieso wurden zum Beispiel andere Optionen abgelehnt, die vielleicht jetzt am Anfang besser erscheinen würden.
Also da kriegt man halt dann mehr Informationen raus, wie Zeitdruck, Technical Debt und dergleichen.
Okay, interessant.
Also meine Erfahrung mit LLMs und wenn ich es richtig verstehe, auch sozusagen die Art und Weise, wie halt LLMs aufgebaut werden, ist ja so, dass die halt mit Nachdruck sagen, so und so ist übrigens die Welt.
Und wir kennen ja...
Weil das Thema mit den Halluzinationen, wo man dann irgendwie das System mit Nachdruck sagt, hey, die Welt ist übrigens folgendermaßen.
Und dann stellt man halt irgendwie gemeinsam fest, nee, das stimmt halt irgendwie nicht, sondern das ist halt irgendwie einfach erfunden.
Das, was du jetzt gerade sagst, ist, es gibt eben sozusagen Lücken in den Informationen, das ist nachvollziehbar, und dass dann das LLM Fragen stellt, das ist, wie soll ich sagen, mich überrascht das ein bisschen, weil das ist für mich nahezu ein Widerstand, wie LLMs typischerweise funktionieren.
Kannst du den Widerspruch auflösen?
Also wie schon gesagt, bei uns war speziell die Tatsache, dass nicht alle Informationen in den Köpfen sind, warum zum Beispiel eine Architekturentscheidung A gefallen ist, das kann zum Beispiel jetzt der Mensch, der daran beteiligt war, beantworten.
Und das steht meistens oder oft nicht drin in der Code-Basis, weil die Leute...
Also ich kann ja keine EDAs pflegen, was ich immer kritisiere, also weil es eigentlich sinnvoll ist.
Und deswegen ist das notwendig.
Und dieses Human-in-the-Loop passt ja auch beim Training von LLMs, weil da werden auch die Nutzer gefragt, ist das eine Antwort, mit der du zufrieden wärst?
Kennst du vielleicht selber von JetGPT?
Auf einmal erzeugt es dir zwei Lösungen und fragt, welche findest du besser?
Das ist ja auch Human-in-the-Loop mit Reinforcement-Learning halt das Modell, verbessern.
Aber wie habe ich mir das jetzt vorzustellen?
Das heißt also, ich fange jetzt irgendwie an und sage dem LLM, ich möchte halt etwas...
Also wie ist dein...
Also ist es so, dass das System dann proaktiv tatsächlich nachfragt und in welchen Situationen passiert das?
Ja, es wird auch angewiesen mit Prompt, dass es proaktiv nachfragt, wenn es auf irgendwelche Lücken stößt, wo es mehr Informationen braucht.
Und zum Beispiel eine typische Anfrage, also zum Beispiel gerade bei den Zügen, der Zug fährt auf unsere Infrastruktur und hat gebremst.
Warum?
Das ist so eine typische Anfrage, die unsere Mobility-Leute zum Beispiel haben bezüglich der Architektur.
Also warum ist genau das passiert?
Und da wird es dann eben noch komplexer, weil man dann auch dynamische Informationen einlesen muss.
Das haben wir noch nicht drin, aber daran arbeiten unsere Mobility-Kollegen momentan.
Auch nur, dass man sich mal vorstellt, wie das läuft, weil selbst die Architekten...
Oder die Entwickler das nicht beantworten können.
Und eine LLM kann sich jetzt anschauen, was waren die Zustände, was war die Basis von dem Ganzen und kann es auch rückwärts verfolgen.
Kann ich als Mensch schon.
Eine LLM ist halt wesentlich schneller, sowas zu analysieren.
Musst du aber, wie du vorher richtig gesagt hast, dann auch verifizieren, dass da nicht irgendeine Halluzination eine Rolle spielt.
Sondern es muss immer, wir fordern von dem LLM oder von dem Agenten immer, er muss uns Faktische...
...Referenzen geben, die uns genau sozusagen helfen, diese Beweiskette nachzuvollziehen.
Gut, das heißt also, ich frage jetzt das System, warum ist der Zug in dieser spezifischen Situation, warum hat er gehalten?
Genau.
Und dann stellt das System mir potenziell Rückfragen.
Also kannst du eine konkrete Rückfrage nennen?
Zum Beispiel eine Rückfrage wäre zum Beispiel, in welcher Situation...
in welcher Situation ein Zug überhaupt bremst.
Es ist nicht immer, es steckt zwar eine Implementierung drin, aber das ist nicht immer ganz klar, weil teilweise das eben auch schlecht dokumentiert ist, leider.
Und wir deswegen aus diesen Informationen vielleicht dann diese Antwort nicht kriegen, die wir uns erwarten.
Und sie wird auch vielleicht fragen, was waren die Situationen, in der der Zug gebremst hat?
Also was ging da speziell vor?
Wer hat gebremst?
Hat der Zug automatisch gebremst?
War es der Lokführer und dergleichen?
Was dann bedeutet, dass die Benutzung eher so ein Dialogding ist?
Also das hört sich ja an, wie dass man eben in einen Dialog eintritt und da Fragen und Rückfragen und Feststellungen hat, irgendwie trifft und dann irgendwie darüber weiterkommt.
Zum Beispiel, ich ist aber normal bei LLMs, wenn du zum Beispiel sagst, erzeuge mir einen LLM-Chatbot.
Dann wird es die Fragen, kriegst du auch Fragen zurück.
Ja, was willst du konkret?
Also das ist mir zu vage.
Okay.
Dinge, die zu vage sind, da soll das LLM auch aktiv Rückfragen stellen.
Weil man, bevor es dann irgendwelche Findings hat, weil es versucht ja immer irgendwas zu produzieren, egal ob es jetzt stimmt oder nicht.
Und das hilft dabei, das auch zu verifizieren.
Okay, super.
Dann habe ich verstanden, also das ist glaube ich irgendwie dieses Thema rund um Rack und sozusagen Informationen, die das System reinbekommen.
Genau.
Dann ist es so, dass das ein Multiagentensystem ist.
Wenn ich es richtig verstehe, was bedeutet das und was sind da die Agenten, die da arbeiten?
Da sind zum Beispiel Agenten drin, die sind auf Architektur spezialisiert.
Andere Agenten sind zum Beispiel mehr darauf spezialisiert, gewisse Programmiersprachen zu kennen und die entsprechend zu verarbeiten.
Weil wir haben es ja meistens auch mit Polyglotten-Systemen zu tun.
Da ist ja nicht nur Python drin oder C++, sondern etliche andere Sprachen, TypeScript, JavaScript und dergleichen.
Und deswegen braucht man spezialisierte Agenten, die sich eben konkret um diese Thematik kümmern.
Wir haben auch einen Kritik-Agenten.
Also für jeden Agenten kannst du, wenn du willst, einen Kritik-Agenten nehmen, der immer versucht zu beweisen, dass der eigentliche Agent sich geirrt hat und dass da irgendwas nicht in Ordnung ist, sodass quasi das System darüber reflektieren muss und es dann entsprechend hoffentlich terminierend zu einer guten Lösung führt.
Mhm.
Okay.
Also ich weiß nicht, ich hätte mir jetzt aus den OP-Folien, die du mir ja freundlicherweise gegeben hast, aufgeschrieben, sowas wie einen Main-User-Input-Agent habt ihr?
Ja.
Also du brauchst ja einen Agenten, der sozusagen die Interaktionen zwischen den Menschen, die da dran arbeiten, und dem System verantworten.
Und der ist quasi da, kriegt Aufgaben, weiß dann, an welcher Agenten er mit welchen Aufgaben geht.
Mhm.
Kann vielleicht auch Aufgaben in Subteile zerlegen.
Und jeden Agenten, der eben auf diesen Teil spezialisiert ist, damit beauftragend ist, zu untersuchen.
Mhm.
Genau.
Dann haben wir sowas wie, genau, Planning.
Wobei, das hast du, glaube ich, gerade schon erläutert.
Genau.
Wir haben auch einen Agenten, der quasi, sobald sich irgendwas an der Code-Basis ändert, ist ja nicht so, dass das GitHub-Repository zum Beispiel oder das Git-Repository zum Beispiel, oder das Git-Repository unverändert bleibt, sondern es könnte sich was ändern.
Und um eben überhaupt einen initialen Zustand in das System zu bringen, das wir gebaut haben, das kann auch mal einen Tag dauern.
Oder sogar mehrere Tage oder mehrere Stunden.
Und wenn ich das jetzt jedes Mal von null aus wiederholen würde, wenn da jetzt ein neuer Code hinzukommt, dann hätte ich ein Problem.
Also deswegen gibt es einen Agenten, der merkt, da hat es eine Änderung gegeben, baut sich dann quasi eine Impact-Analyse und stellt fest, welche Teile konkret davon betroffen waren und was er eben neu einlesen muss als Delta.
Genau.
Dann hast du schon genannt, die sprachspezifischen Agenten über die verschiedenen Programmiersprachen.
Mhm.
Bei Architektur hatte ich mir aufgeschrieben, Patterns, Modulabhängigkeiten, ADR Compliance, also Compliance zu diesen Architektural Decision Records und Solid-Prinzipien.
Weiß ich nicht, ob ihr da noch… Mhm.
…die noch tiefer eingeben wollen.
Ja, aber im Prinzip, die Agenten selber haben ja versucht, möglichst sauber architektonisch aufzusetzen.
Und deswegen haben wir denen auch diese Prinzipien sozusagen mitgegeben.
Also Single Responsibility Principle, also ein Agent macht eine Sache, die er gut kann und versucht nicht, quasi auf fünf Sachen gleichzeitig zu arbeiten.
Mhm.
Genau.
Und dann Get-Analyse hattest du ja auch schon genannt.
Ich glaube, wir haben es dann auch im Wesentlichen sozusagen.
Darf ich fragen, ich weiß nicht, ob du darüber sprechen darfst, wie viel Aufwand da reingeflossen ist, das Ding zu bauen?
Also erstmal nicht so viel, weil wir haben jetzt Stand OP, da hat man Prototypen.
Und da haben mitgearbeitet die Kollegen von Mobility, wir und ein, sag ich mal, Masterstudent, der sich da mitgearbeitet hat.
Ja.
Ja.
Und der war ein Masterstudent, dessen sozusagen Master Thesis auch war, sowas zu bauen.
Das war halt unser Glück, dann sind wir gut zusammengekommen.
Und also den ersten Stand gibt's, der kann aber wesentlich, ist Multiagenten, nur nicht Multiagenten fähig, kann also große Git-Repositories einlesen und kann auch zum Beispiel, wenn man dann Fragen stellt, zum Beispiel wo ist meinetwegen dieses, diese Format, diese Format, diese Funktionalität konkret implementiert, kann er das auch rausfinden.
Und wie vorher schon erwähnt, wir hatten ja gedacht, wir nehmen jetzt Rack her.
Und was sich herausgestellt hat, wir nehmen lieber Knowledge Graphen, weil damit kann die KI wesentlich besser arbeiten.
Und LLMs oder Rack ist dann quasi ein Zusatz an der Information.
Aber sie braucht auch die Struktur des Systems, was ja eben im Knowledge Graphen hinterlegt ist.
Okay, super.
Was mache ich jetzt typischerweise damit?
Also in welchen Situationen nutze ich dieses System oder in welchen Situationen habt ihr es genutzt?
Also zum einen, wie schon gesagt, Architektur Refuse.
Also gerade, wenn man eben relativ wenig Zeit hat.
Es gibt zum Beispiel Due Diligence, wir wollen eine Firma kaufen und wollen aber erstmal sehen, was deren Systeme taugen.
Also Software Architekturen zum Beispiel.
Und das ist so ein relativ cooles System.
Das ist so ein relativ kurzer Zeit zu machen, also zum Beispiel eine Woche.
Und das heißt, in dieser Woche kannst du nicht Millionen Zeilen Code entsprechend durchackern, sondern du kannst da zumindest eine initiale Perspektive auf das System quasi mit diesem Multiagenten-System erarbeiten.
Also beziehungsweise ist es ja noch kein Multiagenten-System, sondern auch in diesem einfachen System, das wir bisher haben.
Diesen Prototypen kann man das relativ einfach dann bewerkstelligen.
Habt ihr es in dem Kontext schon genutzt, wenn ich fragen darf?
Ja, haben wir schon.
Also wie schon gesagt, konkret für Architektur Refuse.
Von denen haben wir relativ viele.
Also im Jahr schätze ich mal 20, 30 Architektur Refuse.
In der Abteilung sind 200 Leute und nur ein Teil davon beschäftigt sich mit Architektur Refuse.
Und für die ist es halt nützlich.
Bloß ich warne halt nicht.
Bloß ich warne halt immer.
Trotz aller Maßnahmen schaut immer nach, ob die Aussagen der KI auch richtig sind.
Genau.
Also die Abteilung, von der du sprichst, ist ich weiß nicht Corporate Technology oder so heißt es.
Es ist Software and System Processes.
Also ich bin konkret in der SSP.
Wir machen Automation Team.
Also für Mobility, für die Industrie Automatisierung oder für Energie Automatisierung und Gebäude Automatisierung.
Und in diesem Bereich sind wir halt bevorzugt tätig.
Machen aber auch was für Healthy News oder Siemens Energy.
Also das kommt auch vor.
Und auch zum Beispiel letzten Fall, wo wir das benutzt haben, da ging es um eine Ladesäulen Infrastruktur und die dazugehörige Software.
Und die hatten eine neue Firma aufgekauft.
Eine kleinere Company mit wenigen Entwicklern.
Und unsere Aufgabe war da einfach mal durchzublicken.
Wie weit passt das mit dem Siemens System zusammen?
Also wie leicht kann ich das integrieren?
Und da hat uns das halt schon geholfen zu sehen, wo gibt es vielleicht Probleme in der Integration?
Wo läuft es vielleicht ganz easy?
Und ich bekomme halt dann Aussagen, die ich teilweise zum Beispiel selber übersehen hätte.
Muss ich ehrlich zugeben.
Also ich habe relativ, ich mache das ja relativ häufig, aber auch mir passiert, dass ich mal irgendwelche Dinge übersehe, die nicht so offensichtlich sind, weil ich eben nicht den kompletten Überblick über ein System haben kann.
Gut, das heißt also, ich gehe jetzt irgendwie hin und sage jetzt zu diesen Menschen, die diese Software gebaut haben, so nehme ich jetzt jedenfalls erstmal an, ich brauche halt von euch Zugriff auf ADRs, Git-Repositories und was auch immer da rumfliegt.
Genau.
Und dann installiere ich das erstmal, also gebe ich erstmal dem, diesem Sarah-System da sozusagen Zugriff.
Genau.
Genau.
Oder mache eine lokale Kopie und lasse es dann lokal laufen.
Also das passiert auf jeden Fall.
Und ja, also das Ganze nennt sich auch Siemens Architektur Review Assistant.
Assistant heißt eben, er assistiert mir.
Also ich nehme ihn jetzt nicht als hauptverantwortlich, sondern ich bin da noch vorsichtig, weil wir müssen erstmal noch mehr Erfahrungen sammeln, wo es dann vielleicht Halluzinationen gibt, die vielleicht sozusagen wir übersehen haben oder wo das System reingefallen ist.
Genau.
Das wäre jetzt irgendwie meine nächste Frage.
Ich wollte jetzt irgendwie bewusst naiv die Frage stellen und dann sage ich dem System nicht, wo sind Probleme mit der Integration mit der Siemens-Infrastruktur und das ist offensichtlich nicht die Art und Weise, wie ich mit dem System umgehe.
Aber was mache ich jetzt mit dem System?
Also das hat ja gesagt, dass das System dir tatsächlich geholfen hat und halt bestimmte Sachen herausgefunden hat oder dich darauf hingewiesen hat, die du sonst nicht gesehen hättest.
Wie stelle ich mir das jetzt vor?
Also wie gehe ich jetzt da hin?
Also wie gehe ich jetzt da ran, diese Software von diesem Unternehmen beispielsweise irgendwie anzugucken?
Also ich erkläre dem LLM oder dem System, wie unsere Siemens-Systeme aussehen, also speziell was die Integrationsschnittstellen betrifft, also alles, was von außen kommt oder nach außen geliefert wird und lasse das System auch dieses, sage ich mal, von der kleineren Firma, die Infrastruktur untersuchen und frage konkret, sag mal, ob es irgendwelche Probleme geben würde.
Wenn zum Beispiel hier diese Teil-Funktionalität in das Siemens-System integriert würde.
Also gibt es da Schwierigkeiten oder lässt sich das Ganze recht einfach bewerkstelligen?
Und wie immer gibt es natürlich Schwierigkeiten, weil natürlich die beiden oder die mehreren Systeme sind ja unabhängig voneinander entstanden.
Also wird das meistens nicht so einfach sein.
Also ich bekomme dann zumindest einen Eindruck, heißt aber nicht, dass ich nicht die Leute von der Firma unterinterviewe und mir auch dann sozusagen einen Einblick gewähren lasse und auch denen mal sage, bitte macht mir so End-to-End-Use-Cases und zeigt mir die im System.
Das ist aber jetzt ja tatsächlich eine sehr high-level Frage.
Also damit sagst du ja im Prinzip, wo überall können jetzt in diesem spezifischen Fall Integrationsprobleme auftauchen und das ist ja schon, ja wie gesagt, eben sehr, sehr high-level.
Das heißt, ich erwarte jetzt, dass da eigentlich etwas rauskommt, was so ähnlich ist wie das Architektur-Review-Dokument, was du sonst irgendwie sozusagen manuell erzeugen würdest.
Also ich erwarte hier ein Problem, ich erwarte hier ein Problem aus folgenden Gründen, was weiß ich, Skalierbarkeit.
Ich meine, das ist nicht so einfach.
Wir übergeben natürlich auch die Schnittstellen.
Also wir übergeben die Schnittstellen des Siemens-Systems und versuchen dann rauszufinden, wie das funktioniert.
Erstmal als Mensch, aber auch mithilfe der KI, wo da eventuell Probleme wirklich entstehen können.
Es ist dann natürlich sehr konkret, was wir dann fragen.
Also ich frage da nicht allgemein, gibt es da Integrationsprobleme, sondern auch gezielt nach gewissen Punkten, Daten zum Beispiel, Integration und dergleichen.
Aber das wäre jetzt für mich genau die Frage.
Also auf welcher Ebene benutzt du das LLM?
Sagst du dem jetzt irgendwie, wo erwartest du Integrationsprobleme?
Also irgendwie high-level?
Ja.
Oder ist es so, dass du halt sagst, okay, ich sehe hier jetzt, dass in dieser Schnittstelle, die wirkt halt, weiß ich nicht, das ist eine Messaging-Schnittstelle.
Wir benutzen ja, wir bauen uns an dauernd Rest.
Da ist halt offensichtlich ein Problem.
Wie siehst du das?
Also welche Ebene ist das halt?
Also gut, ich kann am Anfang, stelle ich halt erstmal eine allgemeine Frage.
Dann bekomme ich Ergebnisse raus und dann kann ich sehr konkret fragen, auf gewisse Aspekte eben konkret.
Das System ansprechen, dass mir das einfach erklärt, welche Komponenten innerhalb des Systems sind jetzt von diesem Thema zum Beispiel betroffen und müssten bei einer Integration entsprechend berücksichtigt werden.
Also das geht quasi von eher allgemein, wenn du das System ja selber noch nicht kennst, zu immer mehr speziell auf gewisse Themen und Aspekte.
Okay, das heißt also beide Ebenen.
Konversation, genau.
Also ich finde Konversation, genau.
Du hattest es vorhin schon angesprochen, es gibt halt Halluzinationen in diesem System.
Wie sehr ist das dabei störend?
Also es wäre ja jetzt theoretisch denkbar, dass halt irgendwie zurückkommt, nicht?
Diese Integration ist halt problemlos möglich oder es gibt halt irgendwie super krasse Probleme aus irgendwelchen Gründen und dann baut man halt irgendwie nach und stellt, also nicht guckt sich halt die reale Realität an und stellt fest, das ist totaler Quatsch.
Bei mir passiert das halt öfter mit LLMs.
Wie ist da deine Erfahrung?
Also wir versuchen es ein bisschen auszugleichen durch diesen Kritikagenten, der dann das Ergebnis des anderen Agenten eben versucht auf Fehler entsprechend zu lokalisieren und zum zweiten eben durch Rec und GraphRec.
Also wir versuchen wirklich faktisch, dass das System immer begründet aufgrund von Code innerhalb des Repositories, warum es meint, dass hier an der Stelle das problemlos wäre.
Also wie würden die Integration zum Beispiel aussehen?
Zeig mir das mal und wo siehst du da eine problemlose Integration und warum?
Okay.
Und wie ist dein Gefühl?
Also sind diese Halluzinationen ein Problem im realen Leben oder ist das halt eher so, dass du sagst, naja ab und zu passiert da mal was, aber eigentlich ist das kein ernsthaftes Thema?
So wie es jetzt halt bei euch funktioniert.
Das ist ein Problem.
Wir haben ja auch bei Siemens die Voraussetzung oder die Vorgabe, dass man auf keinen Fall irgendwelche KI generierten Systeme nutzt, ohne dass sie vorher überprüft werden und auch deren Ergebnisse überprüft werden.
Also darum sehe ich das eher als Assistenten.
Du kannst natürlich nicht alle Halluzinationen abschalten, weil irgendwo geht da halt was sozusagen verloren.
Und dann wird eine Halluzination entstanden.
Und dann wird entsprechend aufgebaut.
Da kann man nur versuchen, das immer auch manuell noch zu verifizieren.
Wie weit stimmt das?
Sagen wir mal zu 90, 95 Prozent ist das ja alles richtig.
Also die Halluzinationen in den LLMs gehen so von 5 bis 20 Prozent, je nach Modell.
Also wenn du ein Frontiermodell hast, dann kommst du eben auf 5 Prozent.
Aber diese 5 Prozent kannst du eben durch diese Maßnahmen in der Architektur, wie eben Rack und dergleichen.
Abfedern.
Weil dann muss das System dir immer beweisen, warum es auf diesen Schluss kommt.
Mit harten Fakten.
Das heißt aber trotzdem, sagen wir mal in 2, 3 Prozent wirst du immer noch Halluzinationen bekommen.
Und da hilft wirklich nur die manuelle Inspektion.
Ist das wirklich so?
Schaue ich mir mal an.
Wird wahrscheinlich ja auch jemand den Automotor untersucht und dann seine Software verwendet.
Auch mal nachgucken.
Was ist da wirklich am echten Motor?
Ist das wirklich, wo ist das Problem eigentlich?
Okay.
Also es ist kein naiver Ansatz.
Wie ist denn, also ich will bei dem Punkt sozusagen nochmal bleiben mit dieser, sagen wir mal, subjektiven Nützlichkeit.
Würdest du dir die Welt vor diesem System zurückwünschen?
Oder ist das etwas, was jetzt ein integraler Bestandteil ist?
Wie sehr oder wie sehr beeinflusst das deine Arbeit bei so einem Review?
Genau, das wäre eigentlich die Frage.
Ist das jetzt dein zentrales Tool, mit dem du halt das Review machst?
Oder ist das halt ein Tool von vielen, das dir halt irgendwie an einigen Stellen punktuell hilft, aber es ist eben nicht das zentrale Tool?
Also wir bauen eben, wie schon gesagt, eine Integration mit anderen Architektur-Tools schon mit ein.
Würde ich mir die Welt von früher zurückwünschen?
Ja und nein.
Also im Prinzip.
Da sind wir auch früher mit Architektur-Reviews zurechtgekommen.
Das hat halt dann immer alles länger gedauert.
Also du gewinnst halt an Produktivität.
Und viele Kunden haben einen relativ kleinen oder geringen Zeitrahmen.
Das heißt, für diese Fälle nützt es ja wirklich.
Wenn ich aber jetzt einen 6-Wochen-Auftrag habe, ein Review zu machen, dann benutze ich zwar die KE, um zu helfen, aber da habe ich wesentlich mehr Zeit, um mit Leuten zu sprechen oder mit Kunden.
Und da habe ich dann auch noch ein paar Fragen, die mir dann wieder auf die Seite kommen.
Und da habe ich auch schon ein paar Fragen, die ich mir auch noch mal ein paar Fragen stellen möchte.
Also ich habe eine Frage.
Ich habe eine Frage zu den Systemen, die die bauen, um zu sehen, was sind jetzt so typische Problemstellungen?
Und tauchen die dann auch auf, wenn ich dann die KE danach frage?
Also sind das Systeme, die die KE erkennen würde oder nicht?
Und damit kannst du ja auch das System laufend verbessern.
Du kannst zum Beispiel jetzt LLMs speziell feintunen für gewisse Themen, meinetwegen für eine Fachdomäne.
Und die dann auch sagt, wie die Domäne aufgebaut ist, ob sie DDD-Prinzipien folgt und und und.
Das ist halt alles sehr hilfreich an der Stelle.
Aber die meisten haben eben keine DDD-Ergebnisdokumentation in ihrem GitHub-Repository.
Aber man erkennt es halt aufgrund der Patterns, die verwendet werden, dass da DDD verwendet worden ist zum Beispiel.
Gut.
Also wenn ich das richtig verstehe, sagst du, insbesondere wenn es darum geht, schnell ein Ergebnis zu haben, dann ist das halt ein Werkzeug, was tatsächlich sehr hilfreich ist.
Genau.
Oder wenn ich halt wirklich tiefer bohren will.
Weil wenn du jetzt ein Review hast mit Menschen, dann kannst du nicht so tief bohren, wie du gerne möchtest.
Und es kann auch sein, dass dir Leute vom Auftraggeber gezielt Informationen vorenthalten.
Und dadurch kann ich zumindest auf diese Punkte stoßen und dann eben nachfragen.
Das konnte ich vorher eben nicht.
Da musste ich mich auf die Leute verlassen.
Genau.
Das ist, glaube ich, noch ein wichtiger Aspekt, den ich, glaube ich, auch nochmal kurz hervorheben wollen würde.
Ein Review bei einer Firma, die man halt potenziell kaufen will, ist halt ein anderes Setting als das, was ich halt häufig habe, wo man irgendwie sagt, hey, hilf uns doch bitte.
Weil nicht in der Umgebung, wo man halt eine Firma kaufen möchte, will die natürlich besonders gut dastehen.
Und das Optimum ist keine Probleme.
Während wenn man jemanden um Hilfe bittet, dann ist das Optimum halt irgendwie Hilfe, was ja impliziert, dass es halt Herausforderungen gibt.
Und das sind andere Sachen.
Und bei den Herausforderungen, wenn es um eine Hilfestellung geht, wird man auch unterstützt und, glaube ich, auf die auch hingewiesen.
Also das sind ein paar unterschiedliche Sachen.
Genau, das ist richtig.
Und da ist, glaube ich, noch ein Punkt.
Wir haben zum Beispiel auch ein Review mit einem Ticket.
Das war so ein Ticketsystem, wo du halt quasi für Nahverkehr Tickets kaufen kannst.
Und die hatten halt Probleme mit der Effizienz und wollten auch wissen, ob ihre Architektur gut genug ist oder Fehler enthält.
Da war das natürlich auch sehr nützlich, da mal kurz sozusagen so ein Architektur-Review zu machen und dann ein bisschen Eindrücke zu bekommen.
Also das Tool selber gibt dir aber auch zurück so eine Art Wortanalyse.
Das heißt, du versuchst wirklich herauszufinden, was sind Stärken, Schwächen, Gelegenheiten und Risiken des Systems.
Das versuchst du auch.
Das versucht auch, das zu bewerten, wie kritisch das ist.
Das heißt also, hier hast du auch noch mehr Informationen als nur in dem Interface A ist die Methode X nicht funktionstüchtig oder hat Fehler, sondern bekommst noch mehr Informationen, wie kritisch das eigentlich ist.
Wo siehst du die Hauptnachteile dieses Tools?
Also die Hauptnachteile, wie wir schon gesagt haben, sind erstens mal die LLMs, die ja auch alluzinieren können.
Ich muss auch die Agenten, die ich habe, die müssen natürlich auch die Programmiersprachen verstehen, die in diesem Repository drin sind.
Das heißt, du musst die speziell trainieren.
Reines Training von Agenten, die nur über den Code schauen, funktioniert aber nicht.
Was wir machen, ist, dass wir eben zumindest den abstrakten Syntaxbaum mit Semantik angefüllt quasi zur Verfügung stellen.
Also wir lesen jetzt nicht naiv.
Eine LLM liest nicht naiv sozusagen den Code, sondern es bekommt eben einen Parser an die Seite gestellt, der auch wirklich die Struktur des Programms und so weiter vorgibt.
Also wo man auch dann mehr sieht als nur LLM.
Hier hast du mal 2000 Zeilen Code und sag mal mal was über welche Herausforderungen es noch gibt in diesem System.
Jetzt ist ja tatsächlich, also wir hatten es vorhin kurz gesagt, es geht halt um die Analyse großer Software.
Das ist ja auch offensichtlich die Herausforderung.
Kannst du nochmal und wir wissen ja alle, dass LLMs dieses begrenzte Kontextfenster haben, also nur eine bestimmte Menge an Informationen aufnehmen können.
Kannst du nochmal konkret sagen, was dazu führt, dass diese Systeme tatsächlich mit großen Software Systemen umgehen können und auch die analysieren können?
Es gibt mehrere Ansätze, die wir dazu haben.
Erstens haben wir spezialisierte Agenten.
Die haben jeweils ihr eigenes Context Memory.
Also wenn ich einen einzigen Agenten hätte, der alles macht, dann würde er natürlich überschwemmt werden.
Wir machen auch sozusagen Context Window, Sliding Context Windows zum Beispiel, wo man einfach sagen ab einem gewissen Punkt vergisst das, was du vorher da gewusst hast.
Wir machen Summarization.
Das heißt also, wenn ich jetzt ein größeres System habe, dann muss ich nicht jetzt alle Details erstmal haben, sondern ich kann zum Beispiel angeben.
So paar Sätze.
Was macht jetzt diese Komponente?
Das ist so eine Summary.
Und wenn ich dann tiefer reingehen will, dann kann das System tiefer reingehen.
Es muss es aber nicht unbedingt gleich am Anfang machen.
Das heißt also, ich versuche eben die Zahl der Informationstichte geringer zu halten, um eben nicht an diese Grenzen zu stoßen.
Weil trotz 100.000 oder Millionen Context Memory ist ja auch erfahrungsgemäß so, die kannst du nicht verwenden.
Das heißt, selbst wenn ein Modell 100.000 Tokens Context Memory hat und du gehst an die Grenze, dann wird es relativ viele Halluzinationen zeigen.
Also du musst, rechne mal mit der Hälfte zum Beispiel oder einen Teil davon.
Also deswegen hast du das Problem, gerade bei großen Code-Repositories natürlich schon.
Und das nächste, was du machen kannst, ist Multi-Prompting.
Das ist ein Agent, macht nicht einen riesen Prompt, um alles abzufragen, sondern er macht, zerlegt es in mehrere kleinere Prompts.
Und jeder Prompt oder jede Session hat ja wiederum ihr eigenes Context Memory zur Verfügung.
Das heißt also, du hast dann diese Möglichkeit und du kannst auch mehrere LLMs benutzen.
Also spezialisierte LLMs, je nachdem wo du bist.
Meinetwegen ein Gwen-Coder mit relativ wenig Billionen Parametern für Code-Analyse und ein meinetwegen Claude Opus oder Sonet 4.6 für, was weiß ich, komplexere Zusammenhänge.
Es gibt eine Frage von dem Raj Kumar, heißt das glaube ich, wenn ich es richtig sage, auf YouTube, die ist englisch.
Ich werde sie gleich nochmal übersetzen.
Und zwar ist die Frage auf Englisch, does the review happen against the architecture diagrams etc.
or against the code base?
Also die Frage ist, ist das Review anhand von Architektur-Diagrammen oder basiert das auf dem Code selber?
Mhm.
Ich glaube, du hast es schon gesagt, aber wir können es ja glaube ich nochmal kurz diskutieren.
Also wir nutzen ja nicht nur LLMs, sondern auch VLMs, die Diagramme und dergleichen eben wissen und die auch Feintuning erfahren, damit sie halt meinetwegen mit UML-Diagrammen besser umgehen können.
Also das schaut sich das System auch an.
Haben wir aber jetzt noch nicht so wirklich genutzt.
Also bisher hat man eben mehr mit den Code-Basen zu tun.
Klar, mit Architekturspezifika.
Aber wir haben die Möglichkeit von VLMs vorgesehen, aber nun nicht wirklich integriert.
Das heißt, das funktioniert im Augenblick nicht.
Aber das ist natürlich der Wunsch, dass in Zukunft halt VLMs sich auch die Diagramme anzeigen lassen können und dann vielleicht noch mehr Informationen kriegen, ob die Architektur wirklich implementiert ist in dem System oder ob das eine Fantasie-Architektur ist, die aber nie jemand mehr wirklich implementiert hat.
Genau.
Was also eigentlich bedeutet, ist es sogar eher die Code-Basis, du hast ja gerade eben gesagt, dass die irgendwie reduziert wird und es da Abstract-Syntax-Trees gibt, die daraus generiert werden und die Lücke ist eher auf der Ebene der Diagramme.
Es ist momentan eine Einschränkung, weil du kannst natürlich nicht alles bauen.
Du startest ja auch klein, also inkrementell, schaust dir erstmal an, ob deine Arbeitshypothesen wirklich stimmen und baust das System dann Schritt für Schritt dann aus.
Und wie schon gesagt, wir haben noch keine VLMs drin, die Diagramme analysieren können.
Aber die Idee wäre halt, die entsprechenden LLMs zu nehmen oder VLMs und sie halt auch noch fein zu tunen mit den Diagrammtypen, die normalerweise so auftauchen.
Genau.
Noch sozusagen eine Frage aus so ein bisschen so einer persönlichen Perspektive und das ist auch etwas, was ich dir, worüber wir ja auch per E-Mail vorher schon mal kommuniziert hatten.
Also ich hatte mir ja die Folien angesehen von der OP, die du mir ja wie gesagt netterweise zur Verfügung gestellt hast.
Und für mich ist jetzt die Frage, und das steht ja hier auch drauf, im Mittelpunkt die Frage nach der Praxisrelevanz sozusagen.
Das hast du, glaube ich, sehr schön beantwortet.
Und vielen Dank erstmal dafür.
Was mir bei den Folien aufgefallen ist, ist, du hattest halt im Hintergrund einmal so einen Informationshappen, wo halt drin stand, ich habe hier oder hier ist halt eine SQL-Injection.
Und in meiner Erinnerung war das halt so, dass das glaube ich tatsächlich Java-Code war, wo eben ein String zusammengebaut wird.
Genau.
Für eine SQL-Anfrage.
Und dann eben eine Variable einfach konkateniert wird in den String hinein, was eben bedeutet, dass da halt irgendwas reinkommen kann.
Und dann haben wir genau dieses SQL-Injection-Problem.
Das heißt, ich mache eben nicht Anführungsstriche oben, sieben Kolonnen ist es, glaube ich, oder Bindestrich, Bindestrich, um halt irgendwie das Kommando zu wenden.
Und dann sage ich halt, hier ist das nächste Kommando, das nächste Kommando, das hat irgendwie eine Datenbanktabelle oder gibt mir halt eine Information aus oder so.
Das sind ja diese klassischen SQL-Injection-Sachen, wo ich halt durch einen String dann eben SQL-Statement ändere.
Und die Frage, die sich da bei mir halt irgendwie ergeben hat, ist, diese Erkenntnis, ich habe an dieser Stelle eine SQL-Injection in Java, ich unterstelle, dass ich die halt irgendwie durch SonarCube einfach rausfinden würde.
Und ich habe da an der Stelle sozusagen nicht den Sinn verstanden von einem, von dem Ansatz, den ihr da habt.
Also sprich, das kann ich halt auch ohne LLM rausfinden.
Kannst du das auflösen, diesen Widerspruch?
Ja, genau.
Diesen mindestens scheinbaren Widerspruch.
Für solche Sachen, wie schon gesagt, wir können auch normale Architektur-Tools verwenden wie SonarCube und deren Ergebnisse integrieren.
Also zum Beispiel, wo sind Abhängigkeitszyklen oder wo ist zum Beispiel so eine In-Fan-Out-Problematik drin oder Coupling und Cohesion-Schichte.
Das heißt also, da können wir auch diese Architektur-Tools integrieren und deren Ergebnisse nutzen.
Das heißt, die LLMs sind jetzt nicht für alles verantwortlich, sondern wo du bereits praxisnahe Tools hast, die man auch gut verwenden kann, dann kannst du die auch sozusagen in diese Landschaft integrieren.
Und das ist der Vorteil halt, dass wir halt nicht nur, also ich will nicht, dass die LLM, schaut mal über das System drüber und dann bekomme ich dann einen SWOT-Report und ich bin glücklich und gebe das weiter, sondern, wie gesagt, ist für mich ein Assistent.
Also ich nehme das erstmal als Hypothesen hin, was er mir liebt.
Schau da aber nochmal kritisch drüber.
Ich glaube, im Augenblick würde ich mich nicht auf ein System alleine verlassen in der Art, weil du eben mangels Erfahrung, da müssen wir erst nur länger damit arbeiten, weißt du halt nicht, wo dann vielleicht Falschaussagen entstehen und so weiter.
Also da wäre ich vorsichtig und darum eben immer schau auch nochmal selber drüber.
Kannst du das nachvollziehen im Code?
Ist da was dran?
Oder ist das vielleicht völlig daneben, was zum Beispiel jetzt das System liefert?
Und vielleicht noch zu der Frage Sequel Injection.
Also wir haben auch optional Agenten, die für gewisse Quality Attributes verantwortlich sind.
Zum Beispiel ein Performance Agent, der sich das anschaut oder ein Security Agent.
Und wir haben auch in diese ganze Software natürlich auch Maßnahmen eingebaut, weil du kannst ja auch dieses SARA-System, könntest ja auch mit Prompt Injection und so weiter angreifen.
Also das ist natürlich dann auch im System selber drin.
Und das System selber untersucht auch noch andere Systeme auf solche Geschichten, sei es mit eben Hilfe von SonarCube oder Understand oder was auch immer da existiert.
Also wir versuchen alle Informationen, die man bisher schon kriegen konnte von anderen Werkzeugen, dann Linta und dergleichen eben auch mit so einzubauen, um eben die Halluzination zu reduzieren.
Weil wenn man in SonarCube sagt, da ist ein Dependency Cycle drin, dann macht es das ja nicht sozusagen zum Spaß, um mich zu ärgern.
Und es ist in Wirklichkeit nichts vorhanden, sondern da kann ich mich drauf verlassen, das stimmt.
Und das ist eine weitere Ebene, um eben auf faktenbasierte Analysen durchzuführen.
Hört sich für mich so ein bisschen an, als wäre das eher ein Input, den man halt dem LLM geben würde.
Also dieses konkrete Vernehmen in den SQL Injections, was halt vielleicht dann von SonarCube tatsächlich kommt.
Genau, genau.
Genau.
Und vielleicht noch der andere Punkt.
Weil ich glaube, das haben wir jetzt, also an dem Punkt sind wir glaube ich ein paar Mal vorbeigekommen.
Und ich wollte das halt auch nochmal unterstreichen.
Ich finde es halt sehr schön, dass du halt sagst, das ist halt ein Assistent.
Und mir fehlt halt bei diesen LLM-Sachen andersrum.
Ich glaube, die Nutzung von LLMs kann gutes Exercise sein in kritischen Nachfragen.
Genau.
Und das ist etwas, wo man sich halt bewusst sein muss, dass LLMs eigentlich dazu gebaut sind, um irgendwie zu beeindrucken.
Und halt eben zu sagen, so ist übrigens die Wahrheit.
Und so ist es halt.
Und wir kennen das alle, wie schnell man das System dazu bekommt, irgendwie dann zu sagen, nee, es ist halt irgendwie nicht.
Weil das ist halt auch in die Textgenerator eingebaut, dass es einen halt irgendwie nicht pleasen soll.
Ich weiß gar nicht, wie man das auf Deutsch sagt.
Also wohlgefällig sein soll.
Und das führt irgendwie dazu, dass halt dieses kritische Hinterfragen eigentlich eine Kernskill ist.
Und ich habe dieses Exercise gehört, was, glaube ich, eine Lehrerin tatsächlich an der Schule gemacht hat oder so.
Wo irgendwie die Aufgabe war, ich löse diese Aufgabe mit einem LLM und finde mindestens fünf Sachen, die halt einfach falsch sind.
Genau.
Und das ist tatsächlich eine Aufgabe, die ich halt sehr spannend fand und, glaube ich, an der Stelle hilfreich ist, um das in die kritische Distanz hinzubekommen.
Was ich vielleicht noch sagen soll.
Also meiner Meinung nach, oder meiner Erfahrung nach, sind LLMs zwar gut im Code analysieren, weil du findest natürlich massenhaft Code in GitHub und sonstigen Repositories, aber noch relativ mittelmäßig in Architekturbewertungen.
Das heißt, auch da musst du aufpassen.
Dafür brauchst du eben so Tools wie SonaCube und dergleichen, um das quasi auch auszugleichen.
Und du musst auch den LLMs gewisse Differenzen haben.
Du musst LLMs gewisse Trainingsdaten an die Hand legen, um das so ein bisschen zu leiten.
Also wenn ein LLM eine Architektur baut, dann sind es meistens immer dieselben Patterns wie Observer oder Strategy und Factory.
Die Architektur-Patterns kennst du mal fast gar nicht, außer vielleicht Leers.
Also du landest dann im Endeffekt, wenn du nicht aufpasst, immer bei einer Leers-Architektur, wo ganz bestimmte Patterns dann auftauchen.
Und das muss ja nicht immer die richtige Geschichte sein.
Da könnte man ja auch mal über hexagonale Architecture nachdenken zum Beispiel.
Oder ich habe ja auch einen Architektur-Ansatz jetzt entwickelt mit Capability-Centric-Architecture.
Das ist auch quasi ein Architekturstil.
Und sowas kennt natürlich eine LLM von Haus aus nicht.
Das muss ich ihm speziell beibringen.
Und wie schon gesagt, wenn ich einen LLM naiv auf dem System loslasse, ohne was zu tun, dann wird es mir nicht unbedingt die Qualitätslücken in der Architektur aufzeigen.
Also dafür musst du extra Aufwand betreiben, damit es funktioniert.
Und keineswegs, also wenn ich es einfach in eine LLM-Reihe schmeiße, dann werde ich auch nicht unbedingt das bekommen, was ich mir erhoffe.
Ich habe noch so ein Thema, also sozusagen einen Look zu dieser SQL-Injection.
Und das kommt tatsächlich auch von einer von deinen Folien von der OOP.
Da geht es halt um eine Spot-Analyse.
Da ist ein Beispiel.
Und da steht halt als Beispiel, Finding ist eine Microservice-Architektur.
Microservice-Architektur ist eingeführt worden.
Und da steht dann irgendwie als Stärken, Skalierbarkeit, Teamautonomie und Tech-Diversität.
Nachteile sind erhöhte Komplexität, verteiltes Tracing und Konsistenzprobleme.
Was dann irgendwie zu Opportunities und Threats führt.
Opportunities sind Cloud-Native, A-B-Testing, unabhängiges Deployment.
Threats, so steht hier, Monitoring-Gaps, Netzwerk-Latenz, Debugging schwierig.
Und also ich habe ja nun buchstäblich Bücher über das Thema geschrieben.
Und wenig überraschend finde ich das halt irgendwie unterkomplex.
Also man kann darüber sehr viel sagen.
Ich glaube, das ist halt auch irgendwie profan, darüber weiter zu diskutieren.
Und was dann da weiter stand, war als Empfehlung Service-Mesh einzuführen.
Service-Mesh ist, wer es nicht kennt, ist halt so ein Infrastruktur-Ding, womit ich gerade so im verteilten System ein paar Sachen einfach auf die Reihe bekomme, indem ich mich in den Netzwerk Kommunikation einschalte.
Also ich kann die ja zum Beispiel verschlüsseln.
Ich kann die ja zum Beispiel verschlüsseln.
Ich kannulus das Thema wichtig bei uns zumindest, weil wir halt relativ viel mit Kubernetes machen.
Und Kubernetes und Docker sind ja so Plattformen, um Microservices zu integrieren.
Und da gibt es ja auch ein Service-Mesh.
Das nennt sich Istio.
Und sowas verwenden wir halt dann.
Auch konkret zum Beispiel, um in einem Kubernetes-System nicht ein Standardprotokoll, also TCP-IP zu verwenden, sondern wenn man eine zusätzliche schnelle Netzwerkkarte mit einem anderen Protokoll hat, TSN oder untergleichen, dann kann man auch diese Systeme so bauen, dass sie halt immer, wenn es geht, über das schnelle Netzwerk kommunizieren und nicht über das normale Internet- oder Ethernet-Netzwerk.
Ja, also meine Fragen sind eigentlich, oder wie gesagt, ich war halt durch die Präsentation durchgegangen eben in Bezug auf diese Praxisgeschichte und deswegen ist es jetzt irgendwie so, dass ich mir sozusagen nicht so gut daraus hole.
Das war halt der zweite und auch tatsächlich der letzte Punkt, der mir halt aufgefallen ist.
Ich habe dazu, also die eine Bemerkung und da würde ich gerne wissen, wie deine Antwort dazu sozusagen ist, ist eben genau diese Aussage.
Das erscheint mir unterkomplex, denn ich würde halt behaupten, Microservices haben verschiedene Vorteile.
Ich kann zum Beispiel, was jetzt hier nicht drinsteht, ist, ich kann die Sachen unabhängig voneinander deployen, was halt zum Beispiel in Bezug auf Testing einen Vorteil hat.
Ich muss eben nur ein Teil isoliert testen.
Ja, genau, und das hat irgendwie Vorteile, weil wir wissen halt, durch schnelleres Deployment haben wir Produktivitätsvorteile, schnelleres Feedback, nicht nur von Kunden, sondern auch technisches Feedback.
Das heißt also, es könnte jetzt sein, dass ich eine Situation habe, wo ich irgendwie sage, ich möchte halt öfter deployen, weil das irgendwie gut ist und deswegen mache ich jetzt irgendwie Microservices.
Wenn das hier so ein Fall wäre, dann würde das in der SWOT-Analyse noch nicht mal auftauchen und deswegen wirkt das auf mich unterkomplex.
Wie ist dein Gefühl dazu?
Also ist das jetzt irgendwie dem speziellen Beispiel geschuldet oder ist es eben tatsächlich so, da würde ich halt...
Ich würde sagen, da hast du vollkommen recht.
Das sind halt so Ergebnisse, die man am Anfang rausbekommt, wo man sagt, okay, wie du richtig sagst, das ist unterkomplex, müsste man eigentlich viel mehr nachhaken, auch Datenpersistenz untergleichen in puncto von Microservices oder eben Bau- oder Evolvierbarkeit nach Cloud-Ansätzen untergleichen.
Und es können im Projekt Gründe bestehen, ganz andere Gründe als die genannten, um eben eine Microservice-Architektur einzuführen.
Und wenn du an solche Punkte kommst, dann ist es eben wiederum so, dass dieser Architekturagent neu trainiert werden muss oder zusätzlich trainiert werden muss oder feingetunt werden muss.
Du wirst aber wahrscheinlich am Anfang, wenn du so ein System gebaut hast, immer wieder solche Ergebnisse kriegen.
Du meintest vorher, die sind relativ schwach in Architektur.
Und das ist ja wieder so ein konkreter Fall, wo man das sieht.
Und deswegen heißt es da aufpassen und danach schärfen.
Und ich vermute halt, so was wird dann auch mal öfters vorkommen, gerade am Anfang.
Und da musst du ja entsprechend das System darauf einstellen.
Und da gibt es sicher noch hunderttausend andere Probleme, die man da hat.
Okay.
Was also bedeutet, dass wir jetzt wieder bei diesem Thema sind mit kritischen Nachfragen, Dialog, solcher Geschichten.
Und das wäre jetzt irgendwie, also wenn ich jetzt das Review machen würde mit diesem Werkzeug und ich hätte das Ergebnis, dann wäre es irgendwie fein, dass ich sagen würde, hm, komisches Ergebnis, gucke ich mir nochmal genauer an.
Ich würde bei allen LLM-Anfragen auf die Ergebnisse gucken und einfach mal davon ausgehen, dass da Fehler drin sind.
Und eben dann nachprüfen und auch mir von einem LLM praktisch zeigen lassen, wie es drauf kommt.
Also konkret am Code oder an dem Architektur, wie es zu diesem Ergebnis kommt.
Und das kann ich dann nachvollziehen, warum eben das berichtet wird.
Wobei man allerdings sagen muss, Cloud und Graphic hat man ja mal untersucht.
Also das Graphic-Team, das sagt dann dir irgendwelche Schlussfolgerungen, aber in Wirklichkeit ist ganz anders vorgegangen.
Also auch das Problem hast du.
Weil das sind eben Textgeneratoren und eben nicht Systeme, die halt sozusagen wirklich denken.
In dem Kontext, wenn ich sozusagen auf dem Punkt nochmal kurz stehen bleiben darf.
Also die Empfehlung ist ja jetzt, diese Service Mesh einzuführen.
Und ich muss gestehen, ich fand das in gewisser Weise, sagen wir mal, bemerkenswert.
Weil ich würde halt argumentieren, ein Service Mesh ist eben ein durchaus komplexes Ding.
Und das steht halt als eine Schwäche von dem jetzigen Ansatz, dass der Ansatz eine erhöhte Komplexität hat.
Der Microservices-Ansatz.
Was halt für mich zu so einer Situation führt, wo ich irgendwie das Gefühl habe, die Komplexität wird bekämpft durch noch mehr Komplexität.
Weil mir ein Fragezeichen entstand.
Aber das wäre dann auch wieder etwas, wo das sozusagen meine faire Meinung wäre.
Was da untersucht worden ist, ist wirklich so ein Kubernetes-System.
Und da war das tatsächlich der Fall.
Dass man mit Mesh halt entsprechend weiterkommt oder besser vorankommt, als mit, sage ich mal, einfach Microservices zu verwenden mit Standardprotokollen.
Also in dem Fall hat es sogar gestimmt.
Aber das kann ja auch passieren beim System, wo es eben nicht stimmt.
Also da musst du immer aufpassen, ob das System die richtigen Schlussfolgerungen gemacht hat und eben auch für den konkreten Projektkontext das stimmt.
Und vielleicht irgendwelche Fakten eben überhaupt nicht berücksichtigt worden sind.
Dann gibt es eine Frage von teppich626 auf YouTube.
Und zwar fragt er oder sie, Michael hatte vorhin gesagt, dass er auch Modelle Models wechselt.
Je nach Frage.
Ich habe gerade angefangen Anything-LLM zu nutzen, um eine Stelle für meine RAG-Vektor-Datenbank zu haben.
Auf die ich dann mit unterschiedlichen Modellen zugreifen kann.
Welchen Interface nutzt ihr da konkret?
Habt ihr unterschiedliche ausprobiert?
Also wir haben selber ein Interface implementiert.
Das nennt sich LLM Client.
Der LLM Client definiert quasi als abstrakte Basisklasse, wie der konkrete Zugriff auf Modelle ausschaut.
Also du kriegst dann quasi ein Objekt von dem Typ und kannst mit diesem Objekt auf dein Modell zugreifen.
Und wenn jetzt zum Beispiel das System entscheidet, dafür brauche ich aber einen Python-Agenten, der darauf entsprechend programmiert ist und eine spezielle LLM, dann kann ich die dynamisch sozusagen zur Laufzeit dann auch ändern.
Also da kann ich mir dann quasi mit per dependency injection eine andere LLM Client-Schnittstelle geben lassen, die sich eben auf ein ganz anderes Modell bezieht.
Und wir haben also quasi mit anderen Worten eine Abstraktionsschicht, die von den konkreten Modellen abstrahiert und die ich dann entsprechend, aus dem Grund auch, austauschen kann.
Gut.
Und dann gibt es noch eine Frage von dem Kevin Rie bei Twitch.
Oder eine Bemerkung ist es vielleicht eher.
Er schreibt, also ich hatte es schon echt oft, dass Claude bei Analysenkomplexer Systeme falsche Ergebnisse geliefert hat.
Das ist halt bei unbekannten Codebasen ein Problem.
Da kann man sich aus meiner Sicht nur bedingt drauf verlassen.
Also wie gesagt, das ist depends.
Wenn du wirklich jetzt hergehst und sagst, Claude schaut sich nicht den Code an, sondern verwendet einen PASA, verwendet dann eben Ergebnisse von anderen Architektur-Introspektionswerkzeugen und sozusagen hat einen spezialisierten Agenten, der da drauf schaut, der vielleicht auch noch feintuned ist, dann kann man das Problem zumindest abmildern.
Aber wie schon gesagt, man kann sich auf LLMs wirklich nur bedingt verlassen.
Man kann Sicherheitsstufen einbauen, die das quasi, möglichst reduzieren, was an Halluzinationen zustande kommt.
Aber man muss eben als Mensch auch nochmal nachgucken.
Also dir bleibt nichts übrig, als dann wirklich, das ist ein Assistent, der gibt mir irgendwelche Informationen.
Kann auch sein, dass die ab und zu falsch sind.
Also menschliche Informationen können ja auch falsch sein.
Also deswegen kann man es ja nochmal nachprüfen.
Und so einfach ein Ergebnis von einem Claude zu nehmen oder vom GPT-5, das wird nicht funktionieren, weil das quasi nicht spezialisiert ist.
Das ist ein allgemeines LLM, das quasi alles macht, aber speziell gut coden kann, aber auch wieder bei Architekturanalysen eben Schwächen hat, wie eben alle LLMs, weil die nie auf richtig vielen Architekturen trainiert worden sind, mangels eben vorhandenen Trainingsdaten.
Letzte Frage, kann man auf euch oder dich zukommen, wenn da noch weiteres Interesse besteht oder weitere Themen sind?
Ja, selbstverständlich.
Einfach auf mich zukommen, also vielleicht lieber über meine Privat-Mail, michael.stahl.gmail.com.
Also ich bin jederzeit ansprechbar oder über LinkedIn.
Sich mit mir vernetzen ist auch kein Thema und dann kann man sich direkt austauschen.
Gut.
Achso, der Marian Zeiss867 hat noch bei YouTube geschrieben, deswegen heißt es ja Context is King.
Das ist fast eine gute Endbemerkung.
Das ist ein gutes Schlusswort, ja.
Genau.
Dann würde ich sagen, vielen Dank nochmal für die Zeit und die Einblicke.
Das ist ja durchaus nicht selbstverständlich und insbesondere eben wertvoll, weil im Gegensatz zu Tourherstellern seid ihr eben keiner, sondern Tournutzer.
Deswegen vielen Dank und ich wünsche dir und auch allen anderen ein schönes Osterfest.
Bis dahin.
Vielen Dank dir auch.
Merci.
Bis dann.
Achso.
Weil ich es gerade noch sehe.
Der Marwan hat geschrieben, das ist ja, glaube ich, auch ein Kollege von dir.
Finde ich an euch beide folgende Frage.
Gibt es einen Rat, wie ich bei meinen aktuellen Architekturanalysen vorgehen soll?
Mir ist klar, dass ich prinzipiell AI verwenden kann, aber ich kann kein Analyse-System bauen.
Gibt es einen niedrigschwelligeren Einstieg?
Gibt es Tools oder Vorgehensweisen, die du empfiehlst?
Da kann ich mit ihm persönlich reden.
Klar gibt es...
Es gibt viele Tools, aber eben nicht viele.
Und wie schon gesagt, die meisten Tools haben eben gerade mit Architekturfragen Probleme.
Er kann aber durchaus...
Ich werde ihm antworten, er kann ja auf die Mobility-Kollegen auch zugehen, weil wir haben das gemeinsam gebaut.
Das heißt, ich kann zum Beispiel nicht entscheiden, auch innerhalb von Siemens, welcher Code rausgehen darf und welcher nicht.
Aber ich werde ihm mal den Tipp geben, dass er einfach mal den Adam Schmidt, das ist der Mobility-Verantwortliche, einfach mal anfragt, ob er auf deren oder auf unserer Gemeinschaft, auf unserem Code-Agenten-Ansatz zugreifen kann.
Was wäre der Tipp für Nicht-Siemens-Mitarbeiter, außer ein Siemens-Mitarbeiter zu werden?
Ja, das wäre dann schon Last Resort sozusagen.
Da kann ich da eigentlich keinen richtigen Tipp geben.
Also ich würde halt schauen, entweder du musst es selber bauen, aber das kannst du natürlich als kleine Firma vergessen.
Also bei Siemens ist das natürlich möglich, weil wir mehrere Stakeholder haben und auch finanziell das Problem nicht haben.
Bei einer kleineren Firma würde ich mich wirklich schwer tun.
Also du kannst mit meinen Patterns, die ich ja teilweise auch verwendet habe, die aber nicht die gesamte Tiefe zeigen natürlich, kannst du schon sozusagen starten.
Du kannst ein kleineres System bauen, aber da wirst du wahrscheinlich auch nicht die Detailinformationen rausbekommen, die du normal rauskriegen würdest.
In unserem Ansatz ist halt schon einige Zeit reingeflossen.
Aber ich veröffentliche auch immer so die Architekturen und dergleichen in der Kategorie, das heißt ich gebe den Leuten durchaus die Chance, dass sie sich dann quasi dort auch bedienen können und auch mal selber so einen Ansatz wählen können.
Aber ich kann jetzt nicht jedem sagen, ich frage mal den Adam Schmidt, ob er den Code da auch rausgibt.
Das wird nicht funktionieren.
Und ich weiß eben nicht, ob es noch weitere Werkzeuge gibt, die auf das aufbauen.
Also ich würde mal davon ausgehen, ich weiß nicht, ob das dann Claude ist oder Entrupter, oder OpenAI sind, die das sowas machen werden.
Aber ich gehe mal davon aus, dass es vielleicht kleinere Firmen gibt, die auf LLM-Basis sowas auch bauen.
Genau.
Und dann aber tatsächlich als Schlusswort von Afrination ist das, glaube ich, bei YouTube.
Vielen lieben Dank für den super informativen Talk.
Das ist, glaube ich, der letzte Schlusswort.
Bis dahin und schöne Ostern und schönes Wochenende.