Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
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örner komplett.
Ich arbeite bei der Firma embarc.
Wir machen 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 genau, 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 dem 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 Architektur-Dokumentation 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 A42 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, wenn man genau bei Diagramms das Code nennt, dass manche Leute, dass sie sowas nehmen wie PlantML 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 so das, was am häufigsten genannt wird als Problem bei Architekturdokumentation.
Und jetzt haben wir ja mit GenAI plötzlich die Möglichkeiten, Texte sehr gut zu generieren, zusammenzufassen, aktuell zu halten.
Und das wäre jetzt genau der Match, nach dem 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 Architekturdokumentation 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 Zuschauer anziehen.
Also von daher…
Das berührt die Menschen tatsächlich.
So könnte man es formulieren, genau.
Jetzt gibt es verschiedene Möglichkeiten und Ansätze, um GenAI und Architekturdokumentation zu kombinieren.
Welche denn zum Beispiel?
Oder welches ist der Erste, der dir einfällt?
Ja, wenn man so ein bisschen drüber nachdenkt, fallen einem so verschiedene Ansatzpunkte ein.
Manche Leute, manche Dinge sind vielleicht auch total, das ist ja banal und da kann man das ein bisschen genauer bearbeiten.
Da wird es interessant.
Also das Erste, was mir zu 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 ein Claude 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 einen Teil gezeigt, was darauf getunet war, Qualitätsziele gemeinsam mit dem Ansprechpartner, P&U 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 erst mal definiert wird, was ist überhaupt ein Qualitätsziel?
Aus welchem Vorrat darfst du dich überhaupt bedienen?
Da sind dann halt Qualitätsmerkmale hinterlegt.
Das ist halt wirklich auch sichergestellt, die senden die da raus.
Da ist das Ergebnis klar definiert gewesen in der Lösung, dass eine Checkliste hinterlegt wird, bitte halte die da dran.
Und das sind schon recht überzeugende Ergebnisse, die da rauskommen, wenn man das ausprobiert.
Kann ich das denn selber ausprobieren und das selber nutzen?
Ja, das geht.
Wir haben jetzt in dem konkreten Fall dieses Beispiel mit den Qualitätszielen einfach als Prompt mal als Markdown-Datei auf Deutsch und Englisch einfach bei GitHub, also verlinken in 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 mit NoLama oder sowas, indem man es da drin laufen lässt.
Das geht tatsächlich ganz gut.
Du hattest das live gezeigt mit einem Flipper, glaube ich, also dem Flipper-Automaten.
Und da halt über Software geredet.
Genau.
Warum soll ich das tun?
Oder was sind die Vorteile von dem Vorgehen?
Ja, also 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, ist auch häufig irgendwie schwierig zu erarbeiten, Qualitätsziele.
Das heißt, das 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 eigentlich 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 das haben wir auch gute schon für gebaut, dass dann das Diagramm auch gleich mitgeneriert wird.
Dass ich also nicht nur Beschreibung der Akteure habe, sondern für jeden Akteur auch noch, also wo ich dann noch dabei habe, neben dem Diagramm noch die Beschreibung.
Und das ist so, also ich sehe es halt vor allem so als Startpunkt.
Also 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 das ist im Dialog so, dass man also schrittweise irgendwie durchläuft und nicht jetzt irgendwie das voll automatisiert ist.
Genau, 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 davorstehen.
Das empfehle ich normalerweise nicht über Qualitätszielen, aber da habe ich es einmal gemacht, weil es dann sehr einfach ist zu sagen, tauscht doch bitte mal drei und vier.
Und fünf ist Quatsch, kannst du rausnehmen.
Also kannst du halt sehr effizient dann halt eben auch über die Lösung reden.
Und ja, das ist so eine Sache, die man machen kann, einen Ansatz.
Was sind Vorteile davon oder wo siehst du da die Chancen?
Ja, wie gesagt, wirklich erster Wurf.
Ein bisschen Sicherheit kriegen, dass das an Sachen gedacht wird.
Denke aber auch, dass Grenzen drin sind.
Also gerade bei dem Qualitätsziele-Beispiel 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 Beispiele und Qualitätsziele sind 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.
Also 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 Flipperparad hat?
Also um eine etwas vielleicht klässlerische Frage zu stellen.
Also damit sagst du ja, dass eigentlich die Qualitätsziele in der Gruppe erarbeitet werden sollen.
Dafür gibt es ja gute Gründe, weil ich da 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 ein Antipattern ein?
Vielleicht, genau.
Also vielleicht ist dieses Qualitätsziele-Beispiel beeindruckend, weil die Ergebnisse so beeindruckend sind, aber nicht unbedingt das, was man zeigen sollte, macht das.
Also vielleicht sind da, wäre dann so etwas wie ein ADR vielleicht cleverer, wo man sagt, ADR wäre jetzt zum Beispiel ein Beispiel aus der Lösungsecke.
Also Qualitätsziele sind ja Anforderungen, ADR wäre dann auch so eine Lösungsecke, wo man auch wirklich sieht, ja der Vorteil ist, ich werde geführt.
Ich werde halt irgendwie aufgefordert, bestimmte Dinge noch mal zu hinterfragen, bestimmte Dinge halt noch mal nachzulegen vielleicht.
Vielleicht wäre das das bessere Beispiel.
Also Architecture Decision Records, wo es halt darum geht, dass eben eine Architekturentscheidung halt begründet wird und dargelegt 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 LMS-Druck 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 dann 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 tatsächlich.
Okay, gut, super.
Dann haben wir 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 Architektur-Dokumentationen, 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 eine 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.
Also das hörte sich für mich so ein bisschen an wie, hey, also LLM oder nicht, so ein dramatischer Unterschied ist das nicht.
Ich hätte jetzt was anderes erwartet.
Ja, es gibt doch eine Kurve, die dann zum Beispiel die Wiki noch macht, wo dann diese konservative oder klassische Ansätze, also Doxygen beispielsweise oder sowas, die da halt eben Sachen daraus ableiten aus dem Quelltext.
Noch eine Kurve, die dann Doxygen nicht mehr machen kann, also gerade das Deep Wiki, 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 oder gleich mehr, 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 Fragen sie haben und die Lösung reagiert dann da drauf.
Das finde ich spannend, also wenn man sich ein bisschen die Grenzen angucken möchte, das Deep Wiki 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, kann man sich die Dokumentation angucken, kann mit der Dokumentation quasi reden, das geht dann tatsächlich auch.
Aber für viele ist das natürlich irgendwie ein No-Go, die sagen, ja, unseren Code können wir so einer Software-as-a-Service-Lösung natürlich nicht geben.
Also wir können ja nicht einfach unsere 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 das richtig verstanden habe.
Genau, ja, es ist halt, dieses Deep Wiki ist, glaube ich, von 2024 ist das rausgekommen.
Von Devin ist das ein Teilprodukt und da hatte jetzt ja die Software-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 ich das vielleicht nennen, oder Klone, die auch unterschiedliche Ansätze haben, teilweise sind die sehr nah an dem klassischen Deep Wiki dran, also an dem Deep Wiki 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 kommandozeilenorientiert, also wo ich quasi die Dokumentation per Kommandozeile dann anstoße und ich dort dann entsprechend das Repo angebe, LLM angebe und dann macht 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.
Und wenn ich es richtig sehe, ist das ein Beispiel für letzteres, also Kommandozeile, Deep Wiki RS, was RASLich Name ist und das andere Beispiel für das Web-Orientierte ist Deep Wiki Open.
Genauso heißt es, genau, Deep Wiki Open.
Ich muss trotzdem nochmal 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 Legacy-Klops, der ist ja wahnsinnig schwer zu durchdringen.
Ich habe also ein System, was jetzt glaubt oder von dem ich, 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 Deep Wiki 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 mein Lieblingsbeispiel wäre so etwas 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önnen die, glaube ich, nicht wirklich helfen.
Also weil die Information ist einfach nicht da.
Vielleicht ist es ja in der Dokumentation, also kann man die Dokumentation noch dazu holen?
Es gibt Produkte, die das machen, also das DeepWiki IRS macht das zum Beispiel explizit.
Da kann man einen Ordner angeben, wo da noch Requirements-Dokumente beispielsweise liegen.
Ja, dann wäre sowas denkbar, ja.
Also 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 halt 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 entwickeln 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, das 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.
Das Original-Deep-Wiki adressiert das sogar.
Das ist eine gewisse Struktur, erhaltene 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 am 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 so etwas gesagt im Sinne von, das sei so ähnlich wie Sona, was 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 mir auch interessante 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, das ist ja jetzt eben überhaupt nicht AI, sondern es gibt schon seit 20 Jahren, dass du halt einfach Lösungen nimmst, die den Source-Code aufschließen können, die da Strukturen erkennen können, die da Visualisierungen daraus ableiten können.
Und die kannst du natürlich wunderbar nehmen, wenn du das System erst mal überhaupt noch nicht kennst, um damit quasi ein abstrakteres Bild zu bauen, wie so einen 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 nennen?
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 wüstigerweise auch Produkte nehmen oder Lösungen nehmen, die eigentlich für Quelltext-Dokumentation rausgenerieren, in eine andere Form ist.
Also Doxygen wäre vielleicht das berühmteste, was 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.
Und 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 also, 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 in diesem Bereich?
Im Vortrag habe ich ja im Prinzip drei Sachen gezeigt.
Zwei jetzt mal so ein bisschen angeteasert.
Das dritte ist jetzt vielleicht auch wieder etwas, was naheliegender ist, tatsächlich auch früh zu benutzen.
Das 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.
Also im Extremfall sind das vielleicht so Ja-Nein-Dinge, wo ich wirklich so eine Checkliste.
Also ich möchte gerne, dass eine Arch-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 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 Arch-42 genommen, im Wesentlichen aus dem Template.
Da stehen ja genau solche Sachen drin, also Hinweise.
Also diese 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 speziell sagen.
Und das kann man dann entsprechend anwenden, also kann man aufverlinken, kann man dann anwenden auf seine Arch-42 Dokumentation.
Er hatte das als Showcase, hatte er das DocChess von mir genommen.
Also 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 Empfehlungen, könnte man sagen.
Guck doch mal darauf.
Und da war es tatsächlich so, dass die Ergebnisse, also als ich diese Berichte anguckte, also 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 es sehe, korrigieren, wo ich so drauf hinweise.
Kannst du ein Beispiel geben?
Ja, ich glaube, das Krasseste war, also es gibt in Arch-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.
Und da dachte ich, ja, das finde ich irgendwie unglücklich.
Also wenn ich ein Review auf eine Dokumentation machen würde, das würde ich ziemlich fett beanstalten.
Das hat er auch rot gemacht.
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 DocChess ist eine Schach-Engine und das kann halt eben mit anderen Schachprogrammen interagieren.
Und da gibt es auch so etwas wie ein Remis-Angebot.
Also im Spiel mache ich keinen Zug, sondern ich sage, ich schlage vor, wir machen einen Remis.
Schachspiel auch üblich.
Das tauchte auch in einer Kontextabgrenzung auf.
Aber 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.
Also das war wirklich beeindruckt von den Dingen, die er gefunden hat.
Das ist ein Tippfehler oder so.
Sondern wirklich, das waren inhaltliche Dinge.
Und also DOCTRESS ist ja eins von den, ich glaube sogar offiziellen AXE-45-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, noch mal besonders beeindruckend, dass da so was rausgekommen ist an der Stelle.
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 halt halber weggelassen.
Das wird einfach in Unit-Tests und in der Main-Methode einfach quasi zusammengesteckt, fest zusammenveradratet.
Und das steht da einfach salopp drin im Text.
Also wurde von abgesehen.
Einfach so auch 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 er hatte so drei, vier Sachen, wo ich dachte, hat er einen Punkt.
Also das steht einfach so salopp im Text drin.
Könnte man darüber nachdenken.
Der sagt ja, ich schreibe ein ADR.
Also es 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.
Es gibt natürlich schon Grenzen.
Also gerade wenn es darum geht, irgendwelche Arbeitsergebnisse zu erstellen und man sagen würde, na, das ist…
Also 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.
Sollte dann sagen, aber wie ist denn sichergestellt, wenn du das nochmal startest oder ein anderes LLM benutzt, dass das gleiche Reviewergebnis rauskommt?
Gar nicht.
Das ist nicht gegeben.
Das kann ich dir direkt zeigen.
Wir starten zweimal, da kommen andere Reviewergebnisse raus.
Das ist ja schlecht.
Ja, ich weiß nicht.
Also weil man könnte ja auch zwei Menschen dran setzen, die dieses Review durchführen.
Die werden auch zu im Detail unterschiedlichen Reviewergebnissen 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 einzelnen Ergebnissen finde ich auch sehr spannend.
Also das sind glaube ich meine Sweet Spots gerade.
Also sollte man benutzen.
Es 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 halt 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 ihr irgendwie sagt.
Eben gerade nicht Vollautomatisierung, gerade nicht sozusagen dem sklavisch Vertrauen, sondern eben dieses kritische Review.
Und eben insbesondere dieser Hinweis, dass insbesondere bei den Qualitätsszenarien es eben 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 das, glaube ich, sich alleine von Rechner setzen, sehr kontraproduktiv.
Das war so das, was ich mitgenommen habe.
Ja, ich hatte auch einmal eine Gruppe, die hatte vorgeschlagen, lasst uns doch gemeinsam vor ein LLM sitzen und diskutieren, was das Markt macht.
Ich würde euch jetzt nicht verbieten, aber ich finde es komisch.
Ihr nehmt euch ja gemeinsam die Zeit.
Also vielleicht wäre dann eher der Ansatz, ihr erarbeitet was gemeinsam und dann lasst es reviewen.
Also dass man sagt, okay, dann verbieten würde ich es Ihnen nicht, wenn Sie Spaß haben.
Aber ich fände jetzt den Ansatz, das dann gemeinsam zu erarbeiten und dann halt eben für ein Review so ein Teil vorzulegen, finde ich naheliegend.
Kann man aber ausprobieren, nicht?
Das wäre so Ensemble oder Mob LLM-Nutzung.
Genau, super.
Noch irgendwas, was ich vergessen habe?
Irgendwelche weitere Themen?
Nö, ich wüsste jetzt so nichts.
Also was halt generell eine Erkenntnis war bei den Sachen, 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ätsdialog gebaut hatten.
Das hatten wir am Anfang, das war ziemlich getuned, 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 nur für ein System?
Und das war, glaube ich, ein kleines Gwen-Modell.
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.
Wo kommt die her?
Da müsste man schon ein bisschen tunen.
Da merkt man schon, die 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 rechnen.
Das ist halt shit in, shit out.
Das ist tatsächlich dann auch so.
Oder sehr vage Antworten.
Da 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 hier bei einem anderen Gedenkmal nochmal.
Schön, dass ich hier sein durfte.
Vielen Dank.
Danke.
Hier ein Hinweis in eigener Sache.
Software-Architektur 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. software-architektur.tv