# Leveraging GenAI for Software Architecture Documentation

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

## Transcript

Wir sitzen gerade auf dem ISAQB Software Architektur Forum.
Der ISAQB war so nett und hat uns Möglichkeiten gegeben, hier mit einigen Menschen aus der Konferenz zu sprechen.
Stefan, möchtest du kurz etwas über dich sagen?
Ja, ich bin Stefan, also Stefan Zörnerin komplett.
Ich arbeite bei der Firma Embark.
Wir machen so Sachen rund um Software Architektur, sagen wir mal ganz gerne, also wir entwerfen Lösungen.
bewerten Lösungen auch recht viel, halten Dinge fest.
Und das mache ich recht viel bei Kunden.
Und gerade dieses Festhalten ist schon so ein Dauerthema bei mir, dass ich mich so rund ums Dokumentieren von Architektur kümmere.
Also es kommt in Review-Situationen vor, aber es kommt auch in konkreten Projekten dann auch vor.
Genau, und du hast einen Vortrag gehalten über das Thema Dockers Code trifft Gen.ai.
Warum vermutest du da oder siehst du da Synergieeffekte?
Ja, genau, ich hatte...
in den Vortrag dazu und wie ich da irgendwie schon drüber nachgedacht hatte, ich glaube, da muss man gar nicht so weit denken, ist, man beobachtet halt zwei Dinge, würde ich sagen.
Also zum einen, Architekturdokumentation ist sehr textlastig.
Also man hat halt sowas wie ADRs, also Architekturentscheidungen, man hat Konzepte, man hat Qualitätsziele, die konkretisiert man in Qualitätsszenarien.
Also muss man einfach nur mal ARC 42 aufmachen, das ist ganz viel Text.
Und Tabellen vielleicht listen, aber es ist Text.
Und dann habe ich auf der anderen Seite ja noch Diagramme.
Aber selbst die Diagramme, Kann ich ja auch beschreiben in Texten, aber immer genau bei Diagrams das.
Code nennen das manche Leute, das ist sowas wie Plant-UML oder Mermaid und das ist plötzlich auch Text.
Das ist so die eine Beobachtung.
Und die andere treibt mich jetzt auch schon länger um, weil ich das Thema auch schon recht lange bearbeite.
Das Thema ist nicht sehr beliebt.
Das heißt also, viele Leute haben da so Berührungsängste oder mindestens mal keine Lust oder sehen, na, das ist schwierig, weil wenn wir da Dinge anfertigen, wie halten wir die eigentlich aktuell?
Das ist, glaube ich, das, was am häufigsten genannt wird als Problem bei Architekturdokumentation.
Und jetzt haben wir ja mit Gen.ai plötzlich die Möglichkeit, Texte sehr gut zu generieren, zusammenzufassen, aktuell zu halten.
Und das wäre jetzt genau der Match, nachdem du fragst, ich habe was, das ist textbasiert, ich habe was, was nicht gerne gemacht wird und dann habe ich plötzlich einen Mechanismus, der das...
automatisieren kann und dann, das sieht aus wie ein Match.
Genau.
Ich fand es halt interessant, dass du noch in dem Vortrag gesagt hast, dass also bei den Trainings dann tatsächlich Menschen das Thema Architektur, Dokumentation schreiben, dann total toll finden.
Und lustigerweise ist es halt so, dass auch etwas, was ich im Stream gelernt habe, die Episoden zur Architekturdokumentation, hätte ich vorher auch nicht gedacht, sind halt tatsächlich welche, die halt mehr ZuschauerInnen anziehen.
Das berührt die Menschen tatsächlich.
So könnte man es formulieren, genau.
Jetzt gibt es verschiedene Möglichkeiten und Ansätze, um Gen-AI und Architektur-Dokumentation zu kombinieren.
Welche denn zum Beispiel?
Oder welches der erste, der dir einfällt?
Wenn man so ein bisschen drüber nachdenkt, fallen einem so verschiedene Ansatzpunkte ein.
Manche Dinge sind vielleicht auch total banal und dann kann man das ein bisschen genauer bearbeiten.
Da wird es interessant.
Das Erste, was mir so einfallen würde, ist einfach im Dialog.
mit einer KI halt einfach Dinge erarbeiten und dann habe ich halt die Ergebnisse und die Dokumentation fällt dann quasi bei ab, weil sie halt einfach mitprotokolliert wird.
Das kann man jetzt irgendwie wenig geleitet machen natürlich, einfach in Cloud oder Mistral oder was auch immer.
Aber da kann man natürlich auch Sachen für anfertigen, also Dinge, die sehr pointiert bestimmte Arbeitsergebnisse produzieren und sicherstellen, dass diese Arbeitsergebnisse eine gewisse Qualität haben.
Da hatte ich im Vortrag beispielsweise Teil gezeigt, was darauf getunt war, Qualitätsziele gemeinsam mit dem Ansprechpartner, PO vielleicht, also jemand, der halt eben diese Qualitätsziele gerne erarbeiten möchte, zusammen halt erarbeitet und durch einen sehr klaren Prozess geführt wird.
Also wo halt wirklich klar auch ist, erstmal definiert wird, was ist überhaupt ein Qualitätsziel, aus welchem Vorrat darfst du dich überhaupt bedienen.
Da sind dann halt Qualitätsmerkmale hinterlegt, das hat wirklich auch sichergestellt, das nimmt die da raus.
Das Ergebnis ist klar definiert gewesen in der Lösung, dass eine Checkliste hinterlegt war, bitte haltet die da dran.
Und das sind schon recht überzeugende Ergebnisse, die da rauskommen, also wenn man das ausprobiert.
Kann ich das denn selber ausprobieren und selber nutzen?
Ja, das geht.
Also wir haben jetzt in dem konkreten Fall, haben wir jetzt dieses Beispiel mit den Qualitätszielen einfach als Prompt mal als Markdown-Datei auf Deutsch und Englisch einfach bei GitHub, also können wir auch verlinken, GitHub hingestellt.
Und im einfachsten Fall wirft man das einfach in irgendeinen Chat rein.
Und dann legt das Ding dann halt eben los.
Kann natürlich auch ein lokales LLM nehmen, das ist mit einem Lama oder so was, wenn es da drin laufen lässt.
Das geht tatsächlich ganz gut.
Du hattest das live gezeigt mit einem Flipper, glaube ich, also dem Flipperautomaten und da halt über Software geredet.
Warum soll ich das tun?
Oder was sind die Vorteile von dem Vorgehen?
Zum einen, das ist jetzt mit den Qualitätszielen natürlich ein konkretes Beispiel.
Man könnte sich das für andere Sachen auch vorstellen.
Aber bei den Qualitätszielen fand ich halt ganz interessant.
Das steht halt häufig am Anfang, also so gesehen gerade so ein Vortrag, Beispiel irgendwie ganz cool, da kann sich jeder vorstellen.
Es ist auch häufig schwierig zu erarbeiten, Qualitätsziele.
Das heißt, es hilft mir vielleicht auch tatsächlich.
Also so gesehen tatsächlich ein interessantes Beispiel.
Bei anderen Sachen geht das auch.
Aber ich glaube, der Vorteil bei dem Ansatz ist halt vor allen Dingen Anforderungsecke.
Also Rahmenbedingungen vielleicht oder Mission Statement.
Was will man jetzt nicht machen, dass man da irgendwie unterstützt wird.
Da gibt es auch gute Checklisten tatsächlich, die man da in solche Sachen reinlegen kann.
Kontextabgrenzung finde ich als Beispiel auch sehr schön.
Also da haben wir auch gute schon für gebaut.
Dass dann das Diagramm auch gleich mitgeneriert wird.
Dass ich also nicht nur die Beschreibung der Akteure habe, sondern für jeden Akteur auch noch, wo ich dann noch dabei habe, neben dem Diagramm noch die Beschreibung.
Und ich sehe es halt vor allem so als Startpunkt.
Ich habe erstmal nichts und dann fange ich an, mit so einer Lösung zu arbeiten.
Das gibt mir Orientierung, das gibt mir Sicherheit.
Also gerade, wenn ich nicht so erfahren bin, ich denke an Dinge.
Das ist schon naheliegend, das zu verwenden tatsächlich.
Und es ist im Dialog so, dass man also schrittweise irgendwie durchläuft und nicht, dass das voll automatisiert ist.
Ja, es ist nicht Knopfdruck.
Es ist nicht so, das sind deine Qualitätsziele, sondern die Lösung ist auch tatsächlich drauf getunt, was hältst du davon.
Da ist sichergestellt, dass Zahlen davor stehen.
Das empfehle ich normalerweise nicht über Qualitätsziele, aber da habe ich es dann mal gemacht, weil es dann sehr einfach ist zu sagen, Tauschtab bitte mal drei und vier.
Und fünf ist Quatsch.
Kannst du rausnehmen, also kannst halt sehr effizient dann halt eben auch über die Lösung reden.
Und ja, das ist...
So eine Sache, die man machen kann, ein Ansatz.
Was sind Vorteile davon oder wo siehst du da die Chancen?
Ja, wie gesagt, wirklich erster Wurf.
Ein bisschen Sicherheit kriegen, dass an Sachen gedacht wird.
Denke aber auch, dass Grenzen drin sind.
Also gerade bei dem Qualitätszielebeispiel habe ich auch schon gedacht, naja, man kann das machen.
Aber was empfehlen wir normalerweise Teams, wenn die über Qualitätsziele reden?
Also normalerweise erarbeiten sie das gemeinsam mit maßgeblichen Stakeholdern.
Da sitzt jetzt plötzlich nicht mehr alleine jemand da von der KI und arbeitet.
Und das ist auch was, wo ich das Gefühl habe, na gut, wenn sich jemand alleine hinsetzen würde, wäre das Ergebnis mit der...
LLM-Lösung vermutlich besser, als wenn er ganz alleine ist und vielleicht auch wenig Erfahrung hat.
Aber das wirklich sichere Beispiel und Qualitätsziel ist ein richtig wichtiger Input eigentlich für die Softwarearchitektur, würde eher anders entstehen.
Das würde eher über Kollaboration entstehen.
Das sehe ich als wackelig an.
Wir haben auch die Erfahrung gemacht mit solchen Sachen.
Die tun so, als kennen sie sich aus.
Und die strahlen halt auch eine gewisse Sicherheit aus, verblüffen einem auch mit Detailwissen, mit Fachwissen.
Also gerade bei den Flippern war ich total verblüfft.
Mir war nicht klar, dass so ein kleines Modell so viel über Flipper weiß.
Aber ich werde ja beispielsweise auch gefragt, was sind so die größten Risiken?
Und er macht dann Vorschläge.
Sind das wirklich die größten Risiken?
Oder sind das halt die, die ihm gerade einfallen, weil er vielleicht ein bisschen Vokabular für Flipper parat hat?
Also um eine etwas vielleicht ketzerische Frage zu stellen, also damit sagst du ja, dass eigentlich die Qualitätsziele in der Gruppe erarbeitet werden sollen und dafür gibt es ja gute Gründe, weil ich da halt die verschiedenen Stakeholder habe, die da verschiedene Ideen haben, was irgendwie sein kann und die verschiedenen Perspektiven, sodass eben eigentlich eine Person alleine, unterstelle ich jetzt mal, nicht die Qualitätsziele festhalten kann.
Jetzt sagst du aber, als erster Schritt ist das sinnvoll, übt man damit nicht...
als ersten Schritt einen Anti-Pattern ein?
Vielleicht, genau.
Vielleicht ist dieses Qualitätsziele-Beispiel beeindruckend, weil die Ergebnisse so beeindruckend sind, aber nicht unbedingt das, was man zeigen sollte, macht das.
Vielleicht wäre so etwas wie ein ADR vielleicht cleverer, wo man sagt, ADR wäre zum Beispiel ein Beispiel aus der Lösungsecke.
Qualitätsziele sind ja Anforderungen.
ADR wird dann auch so eine Lösungsecke.
Wo man auch wirklich sieht, der Vorteil ist, ich werde geführt.
Ich werde halt irgendwie aufgefordert, bestimmte Dinge nochmal zu hinterfragen, bestimmte Dinge halt nochmal nachzulegen vielleicht.
Vielleicht wäre das das bessere Beispiel.
Also Architektur Decision Records, darum geht es eben, eine Architekturentscheidung halt begründet wird und dargedeckt wird.
Genau, Alternativen gegeneinander abgewogen werden, Kriterien auch definiert werden, nach denen man entscheidet.
wo ich jetzt auch, ich denke gerade darüber nach, wo ich auch tatsächlich das Gefühl habe, dass das häufig etwas ist, wo man sagt, mach du mal und dann reden wir drüber.
Was ja vielleicht, oder ich weiß nicht, wie du das siehst, ist das der Ansatz, den man sonst ohne LLM-Stort wählt?
Ja, es ist halt häufig so, dass das jetzt nicht so ein Gruppending ist.
Also es ist halt häufig so, dass Architekturbewertung gerne in Gruppen gemacht wird tatsächlich, auch aus einem guten Grund.
Aber so Entwurfsachen, das funktioniert in Gruppen nicht so gut.
Das ist sehr ineffizient.
Es ist viel cleverer zu sagen, vielleicht zwei Leute beschäftigen sich mit dem.
Thema mit der Entscheidung und dann erarbeiten die zum Beispiel so einen Vorschlag in Form eines ADRs und da spricht dann halt das Team drüber.
Und das wäre dann halt genau so ein Ding.
Ja, die könnten das ja vielleicht auch gemeinsam mit so einer Lösung machen und dann haben sie das auch gleich aufgeschrieben und strukturiert genauso wie es soll und Kriterien werden eingehalten.
Das ist tatsächlich ein gutes Beispiel.
Okay, gut.
Super.
Dann haben wir ja, weitere Möglichkeiten noch?
Ich glaube, das, was den meisten Leuten als erstes einfällt, ist gar nicht das, weil das ist zwar irgendwie naheliegend, sowas zu machen, aber die meisten Leute würden als erstes, glaube ich, sagen, wir haben schon eine Umsetzung, wir haben schon ein Software-System, wir haben aber keine Architekturdokumentation und wir hätten gerne eine.
Kann uns die KI in Anführungszeichen nicht dabei helfen, dass sowas generiert wird?
Und natürlich geht das, aber da erinnere ich auch immer ganz gerne dran, ja, da bräuchte ich jetzt aber auch nicht unbedingt eine KI für.
Also, dass man aus einer...
Umsetzung halt eben bestimmte Inhalte abstrahiert, Diagramme visualisiert oder so.
Das geht auch mit konventionellen Mitteln, also mit klassischen Mitteln.
KI-Lösungen können noch dadurch glänzen, dass sie das halt noch gut schmücken können mit textuellen Beschreibungen, die ich aus dem Quelltext so vielleicht nicht einfach automatisiert rausgekitzelt kriege.
Also das ist spannend.
Ich hatte da im Vortrag, hatte ich die Wiki gezeigt.
Das ist tatsächlich ein proprietäres Ding, also Software-as-a-Service-Lösung.
wo die Idee ist, ich gebe dem Teil ein Repo, also GitHub-Repo beispielsweise, das fräst sich dann einmal durch und leitet dann daraus ein Wiki ab tatsächlich.
Also interessant, dass du sagst, dass man das halt ohne LLM auch erstellen kann.
Also offensichtlich ist das denkbar.
Ich hätte jetzt vermutet, dass der Aufwand dafür, gerade bei Legacy-Software, wahnsinnig groß ist, sodass da gerade ein Vorteil ist.
Das hört sich für mich so ein bisschen an wie, hey, also LLM oder nicht.
So einen dramatischen Unterschied ist das nicht.
Ich hätte jetzt was anderes erwartet.
Ja, es gibt noch eine Kurve, die dann zum Beispiel dieses Deep Wiki noch macht, wo dann diese konservative oder klassische Ansätze, also Doxygen beispielsweise, die da halt eben Sachen daraus ableiten aus dem Quelltext.
Noch eine Kurve, die dann Doxygen nicht mehr machen kann.
Also gerade das DeepViki, das bietet halt eben nicht nur diese Wiki-Seiten, in denen ich navigieren kann, die super strukturiert sind, wo auch Diagramme drin sind, sogar Überblicksbilder, Abläufe und dergleichen mehr.
Also das bietet auch noch einen Chat.
Also ich kann dann quasi mit der Dokumentation ins Gespräch kommen und Fragen stellen zur Umsetzung.
Und war auch dort relativ beeindruckt von der Qualität tatsächlich von dem Produkt.
Und ich hatte so einen Aha-Moment, weil wir haben relativ viel Aufwand immer.
die Dokumentation aufzubereiten für unterschiedliche Zielgruppen.
Und das ist ja plötzlich andersrum gedacht.
Also ich mache mir nicht vorher Gedanken, was für Fragen würden denn diese unterschiedlichen Zielgruppen haben, die wir hier beantworten müssen, sondern ich stelle etwas hin und die Leute steuern dann, das ist eine ganz andere Form von Dokumentation eigentlich, die Leute steuern dann praktisch ihr Informationsbedürfnis darüber, welche, bekunden ihr Informationsbedürfnis darüber, welche Fragen sie haben und die Lösung reagiert dann darauf.
Das finde ich spannend.
Wenn man sich ein bisschen die Grenzen angucken möchte, das Deep Bickey kann man sich angucken.
Ich glaube, wir verlinken das auch.
Und das ist frei für öffentliche, also Public Repos.
Und es sind auch relativ viele Softwareprodukte, so wie Spring oder Visual Studio Code, sind dort auch schon indiziert.
Man kann mir also die Dokumentation angucken, kann mit der Dokumentation quasi reden.
Also das geht dann tatsächlich auch.
Aber für viele ist das natürlich irgendwie ein No-Go.
Und wir sagen, ja, unseren Code können wir so einer Software-as-a-Service-Lösung natürlich nicht geben.
Repos da durchfräsen lassen und wer weiß, mit was für einem LLM die dann am Ende noch reden, um da die Dokumentation zu erstellen.
Das ist sehr intransparent.
Das ist natürlich für diese Lösung eine Schwierigkeit.
Und da gibt es aber andere Lösungen, wenn ich es so richtig verstanden habe.
Genau, ja, es ist halt, dieses Deep Vicky ist, glaube ich, von 2024 ist das rausgekommen.
Von Devin ist das ein Teilprodukt.
Und da hatte jetzt ja die Ob-Source-Community ein bisschen Zeit.
Und da haben sich natürlich schon Leute die Frage gestellt, naja, also...
wie würde man denn sowas bauen?
Also wenn wir selber so ein Ding bauen, wie müsste das aussehen?
Und da gibt es tatsächlich eine ganze Reihe von Nachbauten, wie man das vielleicht nennen, oder Klone, die auch unterschiedliche Ansätze haben.
Teilweise sind die sehr nah an dem klassischen DeepWiki dran.
Also klassisch, ich bin ein bisschen bescheuert.
Also sind an dem DeepWiki dran, dass ich auch eine Web-Oberfläche habe beispielsweise und mit dem Ding dann tatsächlich auch interagieren kann.
Es gibt andere, die sind Kommandozeilen orientiert, also wo ich quasi die Dokumentation per Kommandozeile dann...
anstoße und ich dort entsprechend dann halt das Repo angebe, LLM angebe und dann mache das.
Was ich interessanter finde, weil das natürlich für Automatisierung interessant ist, weil ich das dann halt in meine Prozesse leichter integrieren kann, in meine Bildprozesse.
Wenn ich es richtig sehe, ist das ein Beispiel für letzteres, also Kommandozeile, DeepWiki RS, was genau eben ist und das andere Beispiel für das Weborientierte ist DeepWiki Open.
Genau so heißt es, genau, DeepWiki Open.
Ich muss trotzdem noch mal fragen, weil, also sozusagen noch auf die Spitze getrieben, hast du eine Idee, wie viel einfacher die Analyse von Legacy-Software dadurch wird?
Also weil, wie gesagt, ich hänge noch an diesem Ding mit, okay, ich habe also diesen Lexic-Clops, der ist ja wahnsinnig schwer zu durchdringen.
Ich habe also ein System, was jetzt glaubt oder was das Versprechen hat, mir auf einer höheren Abstraktionsebene das zu erläutern.
Funktioniert das wirklich?
Ich bin unsicher.
Also ich habe Kunden, die experimentieren damit, dass die halt einfach Dokumentation für Legacy-Systeme erzeugen.
Was halt ganz spannend ist, dass die halt keine Grenzen haben, also die meisten, also die PICC Open beispielsweise, hat keine Grenzen, was die Programmiersprachen angeht, was häufig kommerzielle Produkte haben, weil sie ja den Quelltext tatsächlich parsen müssen.
Das heißt also, die kommen da halt eben ohne klar.
Man kriegt auch relativ sicher bestimmte Dinge raus, wenn man das macht.
Aber man kann auch sofort erkennen, da sind Grenzen.
Also wie sie halt im Quelltext immer sind.
Also ein Lieblingsbeispiel wäre sowas wie, ich kann sagen, da ist eine bestimmte Technologie drin.
Aber ich könnte jetzt nicht sagen, weder mit dem LLM noch mit einem anderen Automatismus, das war eine Vorgabe, die mussten das machen.
Das ist halt eine ganz klare Grenze.
Also Anforderungen, architekturrelevante Anforderungen beispielsweise rekonstruieren.
Da könnte ich glaube ich nicht wirklich helfen.
Also meine Information ist einfach nicht da.
Vielleicht ist es ja in der Dokumentation.
Kann man die Dokumentation noch dazu holen?
Es gibt Produkte, die das machen.
Die BWC-IRS macht das zum Beispiel explizit.
Da kann man Ordner angeben, wo noch Requirements-Dokumente liegen.
Dann wäre sowas denkbar.
Wie ist dein Gefühl?
Gut, schlecht, Vor- und Nachteile?
Ich glaube, das ist weniger naheliegend zu benutzen als diese Geschichte mit dem Dialog.
Weil es schon auch aufwendig ist, das aufzusetzen.
Kunden, die das machen, aber ich glaube, die gucken sich das an, weil es spannend ist.
Aber es sind auf jeden Fall Fragen drin.
Also eine Frage, die recht schnell diskutiert wird, ist, ich mache das jetzt einmal.
Dann habe ich einmal dieses Wiki und vielleicht liegt es auch noch andere Informationen ab.
Aber das habe ich jetzt einmal gemacht.
Jetzt entwickelt sich die Software aber weiter.
Was passiert jetzt eigentlich mit der Dokumentation?
Also müsste ich die nicht eigentlich aktualisieren?
Wenn ich die aktualisieren muss, mache ich die dann komplett neu?
Also ich vergesse alles.
Das ist wahnsinnig aufwendig, wenn man das macht.
Weil es doch relativ lange dauert, zu dokumentieren.
Und man verliert ja auch so ein bisschen, die Leute könnten ja vielleicht auch in die Dokumentation reingucken und am nächsten Tag sieht es ganz anders aus.
Das ist natürlich auch ein Risiko, dass ich halt keine Stabilität habe.
Also das Original-Deep-Wiki adressiert das sogar.
Das ist eine gewisse strukturerhaltende Dinge, die ich da machen kann, damit mir das nicht völlig entgleitet, Links noch aktuell bleiben beispielsweise.
Aber das ist halt schon so eine Hürde.
Also wie gehe ich damit um?
Ich habe Kunden schon gehabt, die haben gesagt, wir machen das als Startpunkt.
Und dann arbeiten wir mit den Ergebnissen weiter.
Aber es ist dann quasi einmal.
Also ich habe dann das weiße Blatt Papier, danach habe ich das Grund befüllt und danach arbeite ich weiter.
Genau, ich habe mir noch aufgeschrieben.
Das fand ich halt auch ganz lustig.
Du hattest halt im Talk sowas gesagt im Sinne von, das sei so ähnlich wie Sonar, was halt irgendwie da ist, aber es wird halt ignoriert, was irgendwie zu der Frage führt.
Also okay, ich habe jetzt eine Dokumentation, nützt mir halt nichts, wenn halt jemand reinguckt.
Das bringt so einen interessanten Gedanken.
Und eine Sache hätte ich fast vergessen.
Du hattest gesagt, es gibt andere Werkzeuge, die sowas ähnliches können.
Ich vermute, du meinst so Systeme, die ja Diagramme oder sowas generieren.
Ja, also statische Code-Analyse.
Also es gibt halt, also das wäre jetzt halt eben überhaupt nicht AI, sondern gibt es schon seit 20 Jahren.
dass du halt einfach Lösungen nimmst, die den Source-Gut aufschließen können, die da Strukturen erkennen können, die da Visualisierung daraus ableiten können.
Und die kannst du natürlich wunderbar nehmen, wenn du das System erstmal überhaupt noch nicht kennst, um damit quasi ein abstrakteres Bild zu bauen, wie so ein Bauplan oder sowas.
Und wo du dann halt eben auch sicher gehen kannst, ja, das ist jetzt irgendwie auch richtig, was hier passiert.
Magst du ein Beispiel?
Also kommerziell ist aus der Ecke beispielsweise Teamscale, das ist auch relativ prominent.
Das kriegt auch tatsächlich relativ schöne Visualisierungen hin.
Man kann lustigerweise auch Produkte nehmen oder Lösungen nehmen, die eigentlich für Quelltextdokumentationen rausgenerieren in eine andere Form ist.
Also Doxygen wäre vielleicht das berühmteste, weil das sehr viele verschiedene Programmiersprachen auch kann.
Das Lustige ist, das kann dann auch sinnvolle Diagramme generieren, auch wenn überhaupt keine Dokumentation da ist.
Also der nimmt dann wirklich nur die Informationen, die im Quelltext halt drin sind, also Bezeichner von Methoden, von Klassen und so weiter.
Es kann dann auch noch ein interessanter Punkt sein, wenn man Zugriff hat auf die Versionsverwaltung, dass man zu einem frühen Zeitpunkt fährt.
Also man sagt, okay, das System ist jetzt 15 Jahre lang entwickelt worden, aber wir gucken uns mal an, wie es vor zwei Jahren aussah.
Und häufig ist das dann halt noch nicht so verrottet.
Das heißt, ich kann klarer die Strukturen erkennen, wenn ich mir einen früheren Zustand angucke als jetzt.
Was gibt es noch für Möglichkeiten, um AIs zu benutzen?
Im Vortrag habe ich ja im Prinzip drei Sachen gezeigt.
Zwei jetzt mal so ein bisschen angeteasert.
Das dritte ist jetzt vielleicht auch wieder was, was naheliegender ist, tatsächlich auch früh zu benutzen.
Was sind so Review-Tätigkeiten?
Also ich habe tatsächlich Architekturdokumentation und ich möchte überprüfen, dass die konsistent ist.
Beispielsweise, dass bestimmte Vorgaben eingehalten sind, dass Strukturen eingehalten werden.
Im Extremfall sind das vielleicht so Ja-Nein-Dinge, wo ich wirklich so eine Checkliste, ne?
Also ich möchte gerne, dass eine AK-42-Dokumentation da ist.
Und ich möchte gerne, dass da Qualitätsziele drin sind.
Und ich möchte gerne, dass das drei bis maximal fünf sind.
Das kann man ja tatsächlich so als, ja, wirklich als Kriterien runterschreiben.
Und das ist auch relativ einfach, Lösungen zu bauen, die das abklopfen, also die dann wirklich so eine Dokumentation zum Beispiel im Markdown halt eben durchackern.
Da hatte ich im Talk eine Lösung gezeigt von Matthias Nießen.
Der hatte sich quasi die Best Practices von ARK 42 genommen, im Wesentlichen aus dem Template.
Da stehen ja genau solche Sachen drin, also Hinweise, also Hinweise für bestimmte Zutaten.
Und der hat dann quasi einzelne Agenten gebaut pro Zutat, wo genau diese Kriterien drin sind.
Und er hat dann noch Agenten gebaut, die Konflikte zwischen verschiedenen Abschnitten aufdecken können.
Was eigentlich die spannenderen sind, muss ich es ehrlich sagen.
Und das kann man dann entsprechend anwenden, also können wir auch verlinken, kann man dann anwenden auf seine ARC-42-Dokumentation.
Er hatte das als Showcase, hatte er das DocChess von mir genommen.
Da sind wir auch ins Gespräch gekommen.
Und hat er halt als Markdown-Dateien gehabt.
Da kommen dann halt eben Hinweise raus.
Also das ist jetzt nicht so richtig falsch.
Das sind wirklich so...
Empfehlung, könnte man sagen, guck doch mal darauf.
Und da war es tatsächlich so, dass die Ergebnisse, also wenn ich diese Berichte anguckte, das DocChess-Beispiel kenne ich ziemlich gut, da war ich doch ein bisschen überrascht.
Also zum einen, was da teilweise für echte Klopper drin waren.
Das würde ich eigentlich jetzt, wo ich sehe, korrigieren, wo ich so drauf hinweise.
Kann es zum Beispiel geben?
Ja, ich glaube, das krasseste war, also es gibt in ARK 42 einen Abschnitt Qualitätsziele.
Und da war halt ein Qualitätsziel drin mit Namen und mit passendem ISO-Begriff.
Und dann gab es später in der Lösungsstrategie, da hieß das Ziel anders und es war ein anderes Qualitätsmerkmal.
Also eine Feinheit.
Aber da dachte ich, ja, das finde ich irgendwie unglücklich.
Also wenn ich ein Review auf der Dokumentation machen würde, das würde ich ziemlich fett behandeln.
Das hat er auch rot gemacht.
Und das war so ein Ding.
Oder vielleicht ein bisschen spitzfindiger schon, aber da war ich auch sehr beeindruckt, dass er das gesehen hat.
Es gibt eine Kontextabgrenzung.
Also TalkChest ist eine Schachengine.
Und das kann halt eben mit...
anderen Schachprogrammen interagieren.
Und da gibt es auch so was wie ein Remis-Angebot.
Also im Spiel mache ich keinen Zug, sondern ich schlage vor, wir machen Remis.
Das ist ein Schachspiel auch üblich.
Das taucht da auch in einer Kontextabgrenzung auf.
Und irgendwo später in der Dokumentation stand drin, die Umsetzung dieses Remis-Angebots ist halt eben der Einfachheit halber weggelassen.
Fand ich jetzt auch okay, ist auch nicht wirklich wichtig jetzt für das Beispiel, aber das ist mindestens mal inkonsistent.
Also du versprichst da vorne irgendetwas, das wird da unten offensichtlich nicht gehalten.
Da wäre doch die Empfehlung mal anzupassen.
Oder waren wirklich beeindruckt von den Dingen, die er gefunden hat.
Das ist nicht so, das ist ein Tippfehler oder so, sondern wirklich, das waren inhaltliche Dinge.
Und also Dog Chess ist ja eins von den, ich glaube, sogar offiziellen AXE 42 Beispielen.
Und eigentlich sind das dann immer Sachen, wo man, also ich zumindest und du sicher auch, versucht genau präzise und besonders sauber zu sein.
Und deswegen ist es halt, glaube ich, nochmal besonders beeindruckend, dass da halt sowas rausgekommen ist an der Stelle.
Ja, und es sind halt Vorschläge.
Vielleicht noch ein drittes Beispiel, wenn ich noch eins erzählen darf.
Das fand ich auch ganz gut.
Er hat Vorschläge gemacht für ADRs.
Also sind einfach sehr salopp tauchen im Text irgendwelche Dinge aus.
So was weiß ich.
Dependency Injection Framework wurde da einfach halber weggelassen.
Das wird einfach in Unit-Tests und in der Main-Methode einfach quasi zusammengesteckt, fest, zusammenverdrahtet.
Und das steht da einfach salopp drin im Text.
Also wurde von abgesehen.
Einfach so schön im Passiv.
Also nicht, ich habe entschieden.
Von wurde abgesehen.
Und das war für ihn so ein Kandidat.
wäre doch vielleicht ein ADR-Wert.
Und der hatte so drei, vier Sachen, wo ich dachte, hat er einen Punkt.
Also da steht einfach so salopp im Text drin, könnte man drüber nachdenken.
Und der sagt ja nicht, schreibt ein ADR.
Also da steht dann wirklich auch, wäre doch vielleicht eine Idee, da ein ADR zu machen.
Also passt es tatsächlich sehr gut zusammen, wie du am Anfang vermutet hast, oder ist das ein anderes Ergebnis?
Nee, also das ist tatsächlich, also jetzt, wenn man auch gerade von diesem konkreten Beispiel weggeht, dass man Kriterien an Dokumentationen anlegt, die man klar formulieren kann.
Und dann halt eben das überprüfen lässt.
Das funktioniert wirklich gut.
Und was ist dein Gesamtfazit?
Also LMs und...
Ah, okay.
Ja, ich finde es tatsächlich naheliegend, Dinge, von denen ich jetzt gerade gesprochen habe, tatsächlich auch zu benutzen.
Ich mache das auch recht viel.
Würde es auch empfehlen tatsächlich.
Gibt natürlich schon Grenzen.
Also gerade wenn es darum geht, irgendwelche Arbeitsergebnisse zu erstellen, wenn man sagen würde, na, das ist...
Das sage ich immer gerne dabei.
Ist ein erster Wurf und passt da auf und Reproduzierbarkeit.
Gerade bei Reviews gibt es durchaus Diskussionen, das finde ich ganz niedlich.
Die Leute dann sagen, wie ist denn sichergestellt, wenn du das nochmal startest oder ein anderes LLM benutzt, dass das gleiche Review-Ergebnis rauskommt?
Gar nicht.
Das ist nicht gegeben.
Das kann ich dir direkt zeigen.
Wir starten zweimal, da kommen andere Review-Ergebnisse raus.
Das ist ja schlecht.
Ja, ich weiß nicht.
Man könnte ja auch zwei Menschen dran setzen, die dieses Review durchführen.
Die werden auch zu im Detail unterschiedlichen Review-Ergebnissen kommen.
Müsste man sich halt angucken, wie stark variieren die denn jetzt tatsächlich.
Manchmal ist es tatsächlich auch nur die Kritikalität.
Also ein Durchlauf sagt dann, das ist schlimm.
Der andere sagt, das ist, keine Ahnung, heikel, aber noch nicht schlimm oder so.
Aber gerade diese Review-Ecke finde ich spannend.
Das ist vielleicht das Spannendste sogar.
Und dieses unterstützende Erarbeiten von Einzelergebnissen finde ich auch sehr spannend.
Also das sind so, glaube ich, meine Sweet Spots gerade.
Also sollte man benutzen.
Spricht auch nichts dagegen tatsächlich, aus meiner Sicht.
Also wenn man es wirklich nimmt als Vorschlag.
Ja, also wenn ich sozusagen sagen darf, was mir aufgefallen ist, ist halt einmal diese Geschichte, das du halt formuliert hast als erster Schritt und so weiter.
Also gerade bei denen, die halt irgendwie generieren, was ja irgendwie sagt, eben gerade nicht Vollautomatisierung, gerade nicht sozusagen dem sklavisch vertrauen, sondern eben dieses kritische Review.
Und eben insbesondere dieser Hinweis, dass es insbesondere bei den Qualitätsszenarien etwas ist, wo man gemeinsam daran arbeiten will und eben diese Arbeit alleine vom Rechner kontraproduktiv ist.
Ich würde ja behaupten, oder mein Gefühl ist halt, dass meistens die Teams und die Zusammenarbeit der Teams, gerade bei der Frage, was halt Anforderungen sind, so das Hauptproblem ist.
Und da ist, glaube ich, sich alleine von Rechner setzen sehr kontraproduktiv.
Das war so das, was ich mitgenommen habe.
Ich hatte auch einmal eine Gruppe, die hatte vorgeschlagen, lasst uns doch gemeinsam vor ein LLM setzen und diskutieren, was das macht.
Ich würde euch jetzt nicht verbieten, aber ich finde es komisch.
Nehmt euch ja gemeinsam die Zeit.
Vielleicht wäre dann eher der Ansatz, ihr erarbeitet was gemeinsam und dann lasst das reviewen.
Also dass man sagt, verbieten würde ich es ihnen nicht, wenn sie Spaß haben.
Aber ich finde jetzt den Ansatz, das dann gemeinsam zu erarbeiten und dann für ein Review so ein Teil vorzulegen, finde ich naheliegend.
Kann man aber ausprobieren, nicht?
Genau, meines machen.
Opsomble oder Mob-LM-Nutzung.
Genau, super.
Noch irgendwas, was ich vergessen habe?
Welche weitere Themen?
Nö, ich wüsste jetzt so nichts.
Also was halt generell eine Erkenntnis war, bei der Sache, die ich gezeigt habe, dass es halt doch relativ viele Faktoren gibt, die Einfluss darauf nehmen, wie die Ergebnisse aussehen.
Und das ist nicht nur die Wahl des LLMs, das ist naheliegend, dass da wirklich teilweise...
echt krasse Unterschiede in der Qualität waren und teilweise auch im Verhalten.
Also ich weiß noch, wie wir diesen Qualitätsziel-Dialog gebaut hatten.
Das hatten wir am Anfang, das war ziemlich getunt, das ist ziemlich gut tatsächlich, mit einzelnen LLMs das Problem, dass das den Prozess nicht eingehalten hat, bis zum selber Antworten ausdenken.
Also ich hatte das einmal so, es fragt ja relativ am Anfang, was hast du denn für ein System?
Und das war, glaube ich, ein kleines Quenmodell war das.
Ja, wir haben jetzt hier diese Fitness-App.
Was ist denn besonders wichtig in deiner Fitness-App?
Was für eine Fitness-App?
Ich habe überhaupt nichts erzählt von einer Fitness-App.
Wo kommt die her?
Da müsste man halt schon ein bisschen tunen dann.
Da merkt man schon, okay, Wahl des LLMs ist irgendwie sehr entscheidend.
Und die Eingaben auch.
Also wenn ich jetzt das Ding ärgern würde, ärgern wollen würde, würde ich halt sehr schlechte Antworten geben.
Dann brauche ich aber auch nicht mit guten Ergebnissen.
Das ist halt Shit in, Shit out.
Das ist tatsächlich dann auch so.
Oder sehr vage Antworten.
Dann kriege ich da nicht viel mit hin.
Super, dann würde ich sagen, vielen Dank.
Gerne.
Und eine angenehme Heimreise, glaube ich.
Und dann sehen wir uns sicher bei einem langen Gedingleiter.
Schön, dass ich hier sein durfte.
Vielen Dank.
Danke.
Hier ein Hinweis in eigener Sache.
Softwarearchitektur im Stream live vor Ort.
Wir sind beim ISAQB Software Architecture Gathering im November in Berlin mit dabei.
Mehr Infos dazu und spezielle Rabattcodes für unsere Community findest du auf unserer Website.