# AI Coding Requires Deterministic Architecture Constraints

**Podcast:** Software Architektur im Stream
**Published:** 2026-10-28

## Transcript

Hallo, mein Name ist Alaa Reuchenbach.
Organisiert ihr User Groups, Konferenzen oder andere Tech-Veranstaltungen?
Dann trage sie gerne auf treff.tech ein.
Eine nicht kommentielle Plattform für Tech-Veranstaltungen im deutschsprachigen Raum.
Kostenlos, ohne Werbung und ohne Tracking.
Schaut einfach vorbei unter treff.tech oder scannt einfach den QR-Code.
Den Link findet ihr außerdem in der Videobeschreibung.
Und übrigens, ihr findet alle Termine von Software Architektur im Stream natürlich auch auf Treff und Tech.
Bei Fragen meldet euch gerne bei mir.
Hallo und herzlich willkommen zu einer weiteren Ausgabe von Software Architektur im Stream.
Heute etwas später dran, weil wir haben einen Gast, der nicht in unserer Zeitzone ist und wir werden uns trotzdem auf Deutsch unterhalten.
Heute mit Alexander von Zizowice und wir werden uns über Architektur und Ja, KI unterhalten.
Wie KI mit Architektur?
Braucht KI noch Architektur oder kann das weg oder ist es umso wichtiger jetzt?
Alexander, möchtest du dich kurz vorstellen?
Ja, okay.
Ja, meinen Namen hast du ja schon vorgestellt.
Ich lebe hier jetzt gerade an der Ostküste der Vereinigten Staaten in Massachusetts.
Aber bin die meiste Zeit meines Lebens in Deutschland verbracht und da unter anderem auch verschiedene Unternehmen gegründet.
Das letzte Unternehmen, was ich gegründet habe, hat die Hello Tomorrow GmbH in 2005.
Die gibt es immer noch.
Da bin ich immer noch tätig in dem Bereich.
Und Hello Tomorrow ist vor allem bekannt für unsere Sona-Graf-Produkt-Familie.
Startliche Analyse mit Schwerpunkt auf Architektur und Metriken.
Und das war schon immer so mein Thema so ein bisschen.
Ich habe Informatik studiert an der TU in München.
Ich bin vor langer, langer Zeit fertig geworden.
Das war 1990, ich kann es kaum glauben, wie lange schon her ist alles.
Aber es hat sich eine Menge getan seitdem, aber manche Themen tauchen auch immer wieder auf und bleiben konstant.
Und ein Thema, das mich immer beschäftigt hat, war die Struktur von Software.
Weil in meiner ersten Firma, das war eine Software-Dienstleistungsfirma, haben wir festgestellt, dass wenn...
Wenn wir zu schnell losgelegt haben und uns zu wenig Gedanken über Architektur gemacht haben, dass die Projekte dann schnell in eine ungute Richtung gegangen sind und alles länger gedauert hat und schwieriger geworden ist, als ursprünglich erhofft oder geplant.
Das hat am Ende dann echtes Geld gekostet, vor allem bei Festpreisprojekten.
Das heißt, das Architekturthema ist eigentlich relativ früh auf dem Radar aufgetaucht und wir haben uns dann damals schon Gedanken gemacht, wie können wir denn sicherstellen, dass wir gewisse architectural boundaries im Code forcieren können.
haben kleine Tools geschrieben zu der Zeit, die ein bisschen dabei helfen und zumindest minimal Absicherung machen.
Und es hat uns damals sehr geholfen.
Und dann gab es Ende 90er Jahre, Anfang 2000, gab es ein Projekt mit BMW, die damals voll auf Java umgestiegen sind und relativ schnell in der Lage waren, Big Boards of Mart in Java zu programmieren, die alle möglichen Probleme hatten.
Die haben uns dann gebeten, für die auch so ein Architekturschritte-Tool zu bauen.
Da haben wir damals das Dependometer gebaut.
Das war ein relativ einfaches Java-Programm, was eine Architektur- und Metrik-Schwellwert-Spezifikation in XML übernommen hat und dann aus dem XML-File geschrieben worden, beschrieben hat, welche Klassen wohin gehören und wie die Beziehungen zwischen verschiedenen Containern waren und hat es dann im Continuous Integration Bild sozusagen automatisch gecheckt, ob die Architektur eingehalten worden ist oder nicht.
Und das war letzten Endes eine Erfolgsstory, also für BMW zumindest damals.
Das ist sehr gut angekommen.
Und irgendwann 2005, die erste Firma hatte ich dann verkauft, dann kam 2005 irgendwie um die Ecke und dann kam die Idee, hey, warum machen wir da nicht eine Firma draus, die sich genau um dieses Thema kümmert, um Architektur und Struktur.
Und ich stehe nach wie vor dazu, dass eigentlich Architektur und Struktur das wichtigste Asset für die Langlebigkeit.
und Wahrbarkeit von der Software ist.
Weil Entwickler verbringen die meiste Zeit mit Code lesen und relativ wenig Zeit mit Code schreiben.
Und je besser der Code strukturiert ist, desto einfacher ist er zu verstehen, desto einfacher ist er zu verändern und zu erweitern und zu warten.
Und das bleibt bis heute wahr.
Jetzt hast du gerade schon oft von Architektur gesprochen.
Was ist deine Definition von Architektur?
Wenn ich von Architektur spreche, dann meine ich die innere Struktur von einem Software-System.
Also welche Komponenten hat das System und wie dürfen die Komponenten miteinander kommunizieren, also in welche Richtung.
Das ist im Prinzip, ich unterteile das System in verschiedene Boxen und dann definiere ich für die Boxen vielleicht noch Interfaces.
Sagen also, du darfst, wenn du mit dieser Box redest, nur einen Teil der Klassen, die da drin sind, irgendwie benutzen von außen.
Und dann möchte ich natürlich sicherstellen, dass diese Struktur am Ende zyklenfrei ist.
Boxen können natürlich auch geschachtelt sein, eigentlich wie ein UML-Component-Diagramm.
Wenn du eine Software in einem UML-Component-Diagramm beschreibst, dann hast du auch diese geschachtelten Komponenten, Symbole mit Interfaces und Konnektoren, die sich miteinander verbinden.
Und das ist eigentlich meine, also wenn ich jetzt im Kontext von diesem Vortrag von Architektur rede, ist das, was ich meine.
Die Struktur, die die Software am Ende hat, aus der man sozusagen dann verstehen kann, was die Software tut und wie die Aufgaben der Software aufgeteilt sind.
Okay.
Und wenn du jetzt von der inneren Struktur sprichst, dann gehe ich mal davon aus, dass du eher mit größeren bis riesigen Softwaresystemen zu tun hast und nicht so klassischen drei Schichten und ist alles übersichtlich und das nicht irgendwie groß analysieren, oder?
Ja und nein.
Also natürlich für größere Systeme wird es lebenswichtig, so eine Architektur zu haben, weil ich meine, es gibt ja viele praktische Beispiele draußen, zum Beispiel in der Open Source-Welt haben wir viele Systeme analysiert.
In Hibernate und Hibernate zum Beispiel haben einen Klassenzyklus, da sind 1500 Klassen in einem großen Zyklus, da gibt es keine Architektur.
Da gibt es nur eine große Box und 500.000 Zeilen Code und alles ist in derselben Box drin.
Da gibt es keine innere Struktur.
Dasselbe war für Apache Cassandra zum Beispiel auch.
Und da kann man natürlich jetzt gleich mit dem Argument kommen.
Ja, Habernet und Cassandra sind doch erfolgreiche Projekte.
Die werden überall eingesetzt, sind überall in Produktion.
Und das stimmt auch, sind erfolgreiche Projekte, haben auch eine enorm gute Testsuite.
Die brauchen sie auch, weil bei der internen chaotischen Struktur muss man sich jedenfalls irgendwie gut abtesten.
Das Argument, trotzdem eine Architektur zu versuchen oder zu haben, oder warum es besser ist, eine zu haben, ist, dass Wer kann sich denn da einarbeiten in so eine Code-Basis?
Die Leute, die es ursprünglich mal geschrieben haben, die verstehen vielleicht noch einigermaßen, was sie da gemacht haben.
Aber wenn jemand von außen dazukommt und sozusagen bei null anfängt und in der Code-Basis irgendwie herausfinden muss, wo tue ich denn dieses Feature hier einbauen, der tut sich enorm schwer, braucht viel, viel Zeit.
Also es geht immer wieder um das Argument Lesbarkeit von Code.
Wenn wir uns absolut sicher sind, dass wir unsere Software nicht mehr ändern müssen, wenn wir uns sicher sind, dass wir für immer leben und es für immer warten können und nie jemand Neues an der Software arbeiten muss, dann ist es wahrscheinlich weniger wichtig.
Und wir alle wissen, dass es natürlich eine unrealistische Erwartung ist.
Naja, viele Leute haben ja jetzt die Erwartung, dass zumindest wir Menschen nicht mehr in den Code reingucken müssen, weil das nur noch die Maschine macht.
Und dann kann ich mich ja schon zurücklehnen und...
Sagen wir, macht ja die Maschine und ist mir doch egal, wie die innere Struktur aussieht.
Aber du hast jetzt schon öfters davon gesprochen, dass Zyklen schlecht sind für die Architektur.
Genau, also Zyklen sind so, ich sage immer, eine gute Struktur von der Software hat zwei Säulen, auf der sie stehen muss.
Die eine ist eine möglichst zyklenfreie Abhängigkeitsstruktur und die zweite ist eben ein Architekturmodell.
hier mal ein Component-Diagramm drüberlegen kann, dann eine saubere Struktur in der Software am Ende.
Was viele Vorteile mit sich bringt.
Modularisierbarkeit, du kannst deine Komponenten rauslösen, ersetzen und so weiter.
All diese Sachen werden viel flexibler, wenn du eine gute Softwarestruktur hast.
Aber Zyklen, kleine Zyklen sind erstmal auch kein großes Problem.
In Klasse A benutzt Klasse B und Klasse B benutzt Klasse A zum Beispiel im Visitor-Pattern, das ist ein häufiges Ding, das vorkommt, ist kein Issue, über den ich mir jetzt Sorgen machen würde.
Ich mache mir dann Sorgen, wenn wir plötzlich 20, 30, 50, 100 Klassen aus verschiedensten Schichten zusammen in einem großen Zyklus haben.
Dann haben wir das, was wir den Big Ball of Mark bezeichnen und dann ist die Architektur dahin erodiert sozusagen.
Existiert dann nicht mehr so richtig und dann wird es für alle schwieriger, auch für die KI an dem Code zu arbeiten.
Aber wo ist jetzt das konkrete Problem an dem Zyklus?
Also wie kann ich mir das vorstellen?
Ich habe Klasse A, die referenziert Klasse B und Klasse B referenziert Klasse C und Klasse C wieder A.
Ich habe das auch noch ein kleiner Zyklus mit drei Elementen.
Da machen wir uns keine zu großen Sorgen dabei, weil das sind drei Elemente.
Wenn die idealerweise auch noch im selben Directory oder Package oder Namespace liegen, kein großes Ding.
Das Problem entsteht, wenn diese Zyklen dann wachsen.
Wenn wir plötzlich Zyklen mit 20, 50, 100, 1000 Elementen haben.
Dann hast du keine Modularisierbarkeit mehr.
Und wenn du eine Klasse von denen dann wiederverwenden willst, eine einzige Klasse, dann ziehst du an dieser Klasse und plötzlich hängen 999 andere Klassen dran, die du auch mitnehmen musst, wenn du irgendwas wiederverwenden willst an der Klasse.
Und dann wird es zäh.
Du kannst nicht mehr modularisieren, du kannst keine Features mehr rauslösen, du kannst keine...
Einfach Schnittstellen ändern und solche Sachen wird in so einem großen Big Ball of Mark, wie es so schön heißt, viel, viel schwieriger.
Okay, also die Zyklen machen die Modularisierung kaputt und dadurch muss ich dann unter Umständen auch ran, wenn ich an einer Stelle was ändere, an so vielen anderen Stellen irgendwie was nachziehen, solche Geschichten, weil ich dann auch mit der fehlenden Modularisierbarkeit eben auch die fehlende Abstraktion habe, richtig?
Genau.
Die Abstraktionen werden verwaschen sozusagen, die werden irgendwie verwässert in dem ganzen Ding und man kann einfach nicht mehr klar sehen, wo was hingehört in der Software, weil alles irgendwie mit allem verbunden ist und dann wird es eigentlich von da ab meistens nur noch schlimmer.
Also ich habe ja mal ein richtiges Research-Projekt gemacht und Apache Cassandra über die verschiedenen Versionen verfolgt, von 1.0 bis 4 oder 5 im Moment.
In einem Satz zusammengefasst, and then it got worse.
Also es wurde mit jeder Iteration, es ist am Ende immer weniger Architektur übrig geblieben.
Es war am Anfang schon nicht besonders gut strukturiert von der Gesamtstruktur, aber sobald du mal diese Kerne hast, also diese Zyklenkerne, die eben dann auch über Schichten hinweggehen und über Architekturkomponenten hinweggehen, wird es in der Regel eher schlechter als besser.
Und wie gesagt, das Hauptargument ist wieder die Lesbarkeit und das Verstehen.
Wenn du so einen Zyklus hast, dann musst du, wenn du jetzt eine kleine Komponente hast, die independent ist in zehn Klassen, umfasst sie es relativ leicht zu verstehen.
In dem Fall ist eine Komponente, besteht aber aus tausend Klassen, die alle irgendwie miteinander verbunden sind.
Und da dauert es doch erheblich länger, durchzublicken, wo was ist, wenn überhaupt, wenn es überhaupt möglich ist, ein solides Verständnis zu entwickeln.
Aber jetzt hast du von Apache Cassandra und von Hibernate gesprochen.
Und mit Hibernate hatte ich ein bisschen was zu tun.
Und irgendwie, ich habe bei diesen Open-Source-Projekten oftmals das Gefühl, sie kommen mir riesig vor.
Ich sehe keine Architektur.
Ich vermute eine Architektur, baue mir irgendwo meine Abstraktion im Kopf zusammen.
Und hätte jetzt eigentlich gedacht, dass Hibernate eigentlich ganz gut modular aufgebaut sein muss.
Ja, okay, du grinst schon.
Das ist nicht.
Es ist spannend.
Definitiv nicht modular, ja.
Weil da hätte ich jetzt gedacht, so was wie verschiedene Datenbankadapter, das muss ja irgendwie modular sein, dass man damit arbeiten kann.
Okay, aber wie komme ich dann zu dieser Architektur, dass ich überhaupt, ich meine, Abhängigkeiten zwischen drei Klassen, das traue ich mir noch zu.
Sieben plus minus zwei Elemente kriege ich irgendwo im Kopf hin.
Wenn es größer wird, wenn es komplexer wird, dann habe ich da echt ein Problem.
Und ich kenne viele solche Projekte, wo man sagt, nee, wir können das nicht so einfach stückweise erneuern, weil, ja, Big Ball of Mud hängt alles irgendwie zusammen.
Hilft da dein Ansatz, um das zu visualisieren, um diese Zyklen zu finden und sie dann auch zu beseitigen?
Definitiv.
Visualisierung ist ein ganz entscheidendes Werkzeug dabei, weil wenn ich in der Lage bin, eine Grafvisualisierung von so einer Struktur zu machen und ich Glück habe, das ist natürlich auch eine Glücksfrage im Moment, wie manche Grafen eignen sich gut zum Aufsplitten.
Da kann man schon mit einem Blick sehen, hier und hier muss ich schneiden.
dann zerfällt diese Struktur und es wird übersichtlicher, das Ganze.
Aber wenn ich dann eine Struktur habe wie bei Hibernate oder Cassandra, da wird es dann erheblich schwieriger, weil wir dann wirklich von Tausenden von Elementen reden.
Da ist die Kopplung so enorm stark zwischen den ganzen Teilen, dass es nicht einfach ist, ohne Graph-Algorithmen überhaupt irgendeine Chance zu bekommen, was zu sehen an der Stelle.
Das heißt, im Idealfall habe ich zwar einen riesigen Graphen, aber merke, ja, da sind zwei Brücken und die muss ich irgendwie auflösen und dann kann ich ein Modul rausziehen.
Wenn ich Pech gehabt habe, dann habe ich den Big Ball of Mud und alles spricht mit allem und ich kann es, und die Kunst ist dann die richtigen Blöcke.
Hilft da eigentlich Domain-Driven Design, dass ich so ein...
Wahrscheinlich nicht, ne?
Domain-Driven Design.
Ja, absolut, absolut.
Also Domain-Driven Design schneidet dein System ja in verschiedene Silos sozusagen, die nebeneinander liegen, ja, und die intern auch wieder eine Layering-Struktur haben.
Hilft absolut, ja, weil wenn du ein Domain-Driven Design wirklich umgesetzt hast, dann hast du keinen Big Ball of Mud.
Genau, wenn ich von Anfang an es gemacht habe, wenn ich dann aber den Big Ball of Mud habe, dann kenne ich zwar den richtigen Zuschnitt, aber dahin zu kommen, ist ja schwierig.
Genau, und da kommt jetzt eigentlich das ideale Thema, wo die KI mit reinkommt.
Ich habe ja immer gescherzt, lange Zeit, ich meine, wir alle wissen, Tool verkaufen ist ja kein einfaches Geschäft.
Hello Tomor hat zwar überlebt, aber so reich geworden sind wir damit auch nicht, weil einfach, es heißt nicht umsonst, das Developer-Ghetto, in dem wir uns befinden, das ist schwierig, Tools zu verkaufen und damit wirklich gut Geld zu verdienen.
Ich habe immer gedacht, das schönste Feature, was uns reich machen würde, wäre der Magic Fix-It-Button.
Du hast irgendeinen Button in so einer Graph, da steht Fix-It drauf und der nimmt dann den ganzen Big Ball of Mud auseinander und transformiert die Software in eine schöne Struktur, die dann am Ende von jedem verstanden und genutzt werden kann.
Und alle Tests sind auch wie vor grün.
Dieser Fix-It-Button, der wäre echt Geld wert.
Das Schöne ist, und das ist eigentlich die ideale Überleitung zu einem KI-Thema jetzt, Mit KI kommen wir jetzt in die Nähe, von sowas träumen zu dürfen.
Da will ich jetzt aber erstmal kurz, wir hatten auch schon im Vorfeld kurz drüber gesprochen, auf das Thema kommen, KI, brauche ich überhaupt noch Architektur?
Das hat, glaube ich, jetzt mittlerweile jeder schon mal ausprobiert, dass man einfach mit Cloud Code oder einer anderen Umgebung sagt, ich stelle mir dies und jenes vor und jetzt mach mal bitte und dann kriege ich was.
Das heißt, Architektur ist mir ja dann eigentlich egal.
Die KI wird sich schon drum kümmern, die KI wird immer besser und die wird es hoffentlich auch supermodular aufbauen.
Wie siehst du das?
Gut, also ich meine letzten Endes, die Endfrage ist eine Glaubensfrage.
Ist die KI am Ende wirklich so gut, dass sie das alles hinbekommen kann und wir uns gar nicht mehr, nie mehr mit Code auseinandersetzen müssen und Claude regelt das alles für uns?
Ich meine, im Moment kann man tatsächlich sehen, dass der Fortschritt ziemlich stark in die Richtung geht, aber es sind immer noch offene Grenzen.
Es gibt eine Studie, eine Stanford-Studie dazu, die ist jetzt allerdings auch schon wieder über ein Jahr alt, was in unseren Zeiten wahrscheinlich Lichtjahre sind in Entfernung.
Aber in dieser Studie hat man 120.000 Entwickler beobachtet und versucht zu messen, wie viel Produktivitätsgewinne sie durch KI nur zum Erreichen.
Und bei allen 120.000 Entwicklern im Durchschnitt kam lediglich ein Produktivitätsgewinn von 10 Prozent bei raus.
Das ist deutlich geringer, als was wir persönlich teilweise erfahren, wenn wir mit KI arbeiten.
Und dann ist die Frage, warum ist das so?
Und dann hat man Korrelationen gemacht und festgestellt, dass manche Teams sind 200, 300 Prozent schneller und andere Teams werden langsamer durch KI-Nutzung und haben einfach mehr Probleme und weniger und tauchen immer mehr Wachs in der Software auf.
KI-Slot wird erzeugt und plötzlich fallen Produktionssysteme aus.
die eigentlich jahrelang stabil gelaufen sind.
Ich meine, wir haben alle diese Story schon gelesen.
Es passiert im Prinzip jede Woche jetzt irgendwas in der Richtung, dass plötzlich Ergebnisse doch nicht ganz so toll gewesen sind, wie erwartet.
Und letzten Endes, die interessanteste Korrelation in dieser Studie war, dass man festgestellt hat, die Teams, die schon auf einer sauberen Code-Basis gearbeitet haben, also die Struktur vermessen von dem Code, gibt es Metriken, mit denen man eben die...
sagen kann, wie gut ist die Struktur von der Software oder wie schlecht ist sie, hat solche Metriken über die Software laufen lassen und festgestellt, dass die größten Produktivitätsgewinne korreliert haben mit der besten Softwarestruktur.
Das heißt, je besser die Struktur ist, desto besser funktioniert KI.
Und was im Prinzip bei rauskam, ist, dass KI das verstärkt, was die KI vorfindet.
Claude und Co.
sind inzwischen richtig gut darin, sozusagen auch deinen Stil nachzuahmen und deine Konventionen einzuhalten und so weiter und so fort.
Und wenn deine Konvention Big Ball of Mud ist, dann arbeitet Claude am Big Ball of Mud.
Und was wir bei Taste festgestellt haben, dass wenn du so eine Struktur hast und dann Änderungen machen willst, braucht Claude erheblich mehr Tokens.
Also das hatte ich auch so schon gemerkt, dass die KI sich tatsächlich im Code Beispiele sucht und dass das viel besser geworden ist.
Ich hatte mal einen ASCII-Doc-Linter geschrieben, komplett mit der KI Dark Factory und als jemand mal einen Blick in den Code geworfen hat, hat er mich dann gefragt, sag mal, warum hast denn du jede Regel mit einem anderen Test-Framework abgecheckt?
Und dann kam es mir so, ich habe...
jede Regel in einer neuen Session angefangen und die KI hat keine Entscheidung irgendwo vorgefunden.
Ich glaube, sie hat auch nicht richtig gesucht, was eben schon verwendet wird und das war dann, ja, jedes Mal ein anderes Test-Framework.
Aber das wird ja wirklich besser.
Wir haben hier eine Frage aus dem Publikum.
Hast du gute Beispiele für strukturierte Software?
Ja, also mein Lieblingsbeispiel ist das Spring Framework.
Extrem gut strukturiert und die haben auch von Anfang an strikte Architekturregeln umgesetzt.
Die haben Tools benutzt wie damals J.D.Pend oder die haben auch mal so eine Graf eingesetzt für eine Zeitung, ihre Strukturen zu analysieren mit Spring und Jürgen Höller, einer der Gründer von dem Spring Framework, war immer sehr, sehr streng beim Review von Dependencies.
Das hat sich am Ende ausgezahlt.
Also die innere Struktur von Spring, wenn du dich mal anschaut, ist fast komplett zyklenfrei.
Es gibt ganz wenige Zyklen da drin.
Und damit kommen besser.
Und dann gibt es so Projekte in der Mitte.
Zum Beispiel Gradle ist auch so ein Open-Source-Projekt, das Build-Tool für Java.
Gradle ist auch...
überwiegend relativ gut strukturiert.
Es gibt ein großes Modul, da haben Sie schon die Tendenz zum Big Ball of Mud.
Das ist ein Dependency Management Modul.
Das ist auch das größte Modul in Gradle, auch das wichtigste.
Und da sieht man die Probleme gerade wachsen.
Da sieht man gerade, dass sich die Struktur auch von Version zu Version eher verschlechtert als verbessert.
Bei Gradle würde ich ja sagen, durch das Plug-in-System muss das Ganze irgendwo modular sein.
Bei Spring bin ich ja...
Als ich noch damit gearbeitet habe und nicht die KI habe arbeiten lassen, da habe ich immer so ein bisschen die Architektur vermisst, dass ich mal irgendeinen Blick drauf habe.
In den Source-Code wollte ich nie reingucken und ansonsten hat man ja die User-Dokumentation.
Von daher, ja.
Aber worauf das Ganze ja hinausläuft, ist, wir machen jetzt alle Greenfield.
bauen uns unsere Software, sind begeistert, was die KI macht.
Wir können aber, glaube ich, alle noch nicht sagen, ob die KI jetzt über die nächsten Jahrzehnte diese Software auch weiterentwickeln und warten kann.
Und da geht ja eigentlich dein Ansatz rein, dass man hergeht und dafür sorgt, dass die innere Struktur passt.
Und was du ja so sagst, dass die KI sich auch über Modularität freut.
ist ja glaube ich auch dieses, ich meine, wir Menschen brauchen die Modularität, dass wir den Überblick behalten, weil wir eben 7 plus minus 2 im Kopf handeln können.
Die KI mit ihrem begrenzten Kontext, die muss ja auch irgendwo schauen, dass sie ihren Weg findet und dass sie irgendwo den Überblick hat.
Wollen wir mal einen Blick auf so eine Visualisierung werfen?
Ja, wir können, das wäre ganz spannend.
So ein Graph hier offen.
Und hier haben wir gerade das Gretelprojekt.
Das Gretelprojekt, da sieht man hier so einen Überblick über die wichtigsten Metriken.
Man sieht also Entanglement, das ist also wie viele Zyklen sind da, schaut es eigentlich gar nicht so schlecht aus.
Also der Balken ist relativ wenig rot.
Insgesamt 15 Prozent der Codebasis sind Zyklen drin und die meisten Zyklen sind kleine Zyklen mit zwei bis fünf Elementen, ist dieser gelbe Balken hier.
Das ist jetzt alles ein bisschen klein.
Ich glaube, du kannst jetzt nicht auf die Schnelle reinzoomen, oder?
Ich könnte die Screen Resolution ändern, dann wird es ein bisschen größer.
Das mache ich mal.
Also das heißt, das Tooling analysiert hier die Modularität, die Zyklen und kann das dann somit gleich visualisieren.
Genau, das ist jetzt eine Visualisierung, genau wie wir es hinbekommen.
Und den Gerät gibt es jetzt zum Beispiel, wenn wir hier mal reinkommen, sieht man das jetzt besser bei der Beier?
Ich habe die Auflösung jetzt ein bisschen umgestellt.
Komponentenzyklen in dem Fall sind Zyklen zwischen Server-Files.
Und es gibt hier, wie ich schon erwähnt habe, vorhin den größten Zyklus mit 92 Elementen im Dependency-Management-Modell.
Okay, das heißt, ich beschreibe das jetzt mal gerade so ein bisschen für die Hörer.
Ich sehe jetzt hier, die verschiedenen anscheinend Zyklengruppen, keine Elemente, sondern Zyklengruppen und die sind nach ihrer Größe sortiert.
Und dann kann man da gleich einen Drilldown machen und sich das angucken.
Genau, jetzt gehe ich in Show & Cycle View, jetzt wird es mir visualisiert.
Ich komme jetzt diesen Graphen hier.
Da ist natürlich jetzt klar, wegen der Screenauflösung sieht man jetzt nicht besonders viel, aber es fällt auf, wir haben insgesamt diese 92 Java-Files, die diesen großen Zyklus bilden und die Farben sind die Packages in dem Fall.
Und das sieht jetzt wirklich aus wie ein Big Ball of Mud, weil ich sehe ganz viele Texte, die eingefärbt sind, die Komponentennamen und da ganz viele Verbindungen durcheinander drinnen.
Genau, aber man sieht so ein bisschen, dass eigentlich so eine Trennlinie so in der Mitte hier durchgeht, so ein bisschen oben links und unten rechts, ganz grob.
Was bedrücken die beiden Farben?
Ich sehe oben links ist vieles rot, unten rechts ist vieles blau und tatsächlich scheint da die Trennlinie dazwischen zu laufen.
Genau, die Farben stehen in dem Fall für den Direct Structural Parent.
In unserem Fall, nachdem wir kein Architekturmodell haben, sind es die Packages.
Also alle, die im selben Package liegen, haben dieselbe Farbe.
Und das wird jetzt hier über die Palette auch dargestellt.
Hier können wir sehen, wir haben insgesamt in diesem Zyklus 16 verschiedene Packages, die hier beteiligt sind.
Aber das zeigt ja jetzt, eigentlich haben wir hier schon zwei Packages.
Wir sehen auch visuell da etwas.
Aber jetzt sehen wir es.
Okay.
Genau.
Also man kann sehen, dass eben...
Irgendwann ist hier diese Trennung, die eigentlich da sein sollte zwischen den Farben, die ist irgendwie verloren gegangen.
Und jetzt wird es ein bisschen gemischt, so das Blaue wird mit Gelb hier unten vermischt, ein bisschen Lachsfarben und so weiter.
Es ist alles ein bisschen durcheinander, aber man sieht schon, es gibt ein sogenanntes Spring Embedded Layout, der sucht auch so Dinge, die in einem Graphen näher zusammen liegen, auch nebeneinander abzubilden.
Also man kann schon noch sehen, dass es hier eine Struktur gibt irgendwo, aber die ist halt so ein bisschen verwaschen inzwischen durch diese große Züge.
Ist das was, was du als technische Schuld bezeichnen würdest, dass man mit Modulen angefangen hat und dann vielleicht mal, ach komm, so geht es schneller und dann machen wir da die direkte Verbindung, das müssen wir irgendwann fixen?
Also ich bin inzwischen mit einem neuen Term gekommen und mein neuer Term heißt Technical Friction, Reibung.
Weil technische Schulden impliziert ja, dass jemand ein Darlehen aufgenommen hat, also eine bewusste Entscheidung getroffen hat, dass wir die Struktur jetzt so entarten lassen.
Aber ich glaube, eine bewusste Entscheidung ist nie getroffen worden.
Das ist das Problem, wie ich es erfasse, weil eigentlich, wie du sagst, die Definition ist, ja, ich nehme hier Schulden auf, um zum Beispiel schneller zu sein, um schneller das Release rauszubringen, nehme ich hier mal den Shortcut, aber muss eben den Fix irgendwann bringen.
Und wie du sagst, meistens macht man das nicht bewusst.
Genau.
Das geschieht komplett unbewusst.
Die Leute, die Gredel bauen, die wachen ja nicht morgens auf und sagen, wie kann ich jetzt heute die Struktur kaputt machen.
Das wird keiner tun.
Die wissen genau, was sie da tun.
Die haben eine komplexe Software, die relativ gut funktioniert.
Aber sie haben halt keine Tools, die in die Architektur sozusagen prüfen und versuchen, so gewisse Boundaries einzuhalten.
Und wenn du das eben nicht machst, wenn du keine automatische Überprüfung hast, für einen Menschen ist es unmöglich zu sehen, wenn er diese Strukturen implizit aufbaut, wenn er jetzt aus Versehen mal eine Abhängigkeit zu einem anderen Package einbaut, kann er nicht sehen, dass dadurch jetzt ein Zyklus mit fünf anderen Packages entsteht.
Das merkt er nicht beim Programmieren.
Und der Compiler, dummerweise, zählt es ihm auch nicht.
Das heißt, das wächst dann halt so im Laufe der Zeit.
Aber das Interessante jetzt hier, wo man hier mal gucken kann, ist, Stellen wir uns vor, wir würden diesen Graph partitionieren, weil wir müssen diesen Graph vereinfachen, um irgendwas tun zu können.
Und wenn ich das jetzt partitionieren würde, dann kann ich nach Farbe gehen und dann sage ich hier, wie sieht denn der Graph aus, wenn ich alle die in dieselbe Farbe in einen Knoten zusammenfasse?
Dann bekomme ich jetzt zack, zack, einen deutlich einfachen Graphen.
Weil ich nicht mehr die Komponenten sehe, sondern die Packages.
Genau, alle die in dem selben Package sind, sind hier zusammengefasst in einen Knoten.
Und jetzt sind die Farben die Parent Packages von diesen Packages.
Wir sehen hier zum Beispiel das Graph Package, das blaue hier.
Insgesamt drei Dinge und es gibt ein Unterpackage, Selektors, Builder und Konflikts.
Und jetzt sehe ich nicht mehr so eindeutig den Schnitt, sondern jetzt sehe ich wirklich, alles spielt mit allem zusammen.
Genau, aber wir können es ja weiter vereinfachen.
Jetzt können wir das Spiel ja nochmal machen.
Fassen wir nochmal alle Knoten zusammen, die dieselbe Farbe haben.
Immer noch nicht viel besser.
Immer noch nicht viel besser.
Und jetzt plötzlich wird es schon ein bisschen übersichtlicher.
Noch weiter gehen, dann bleiben am Ende nur noch drei Knoten übrig.
Okay, zum Schluss, wenn ich nur noch einen Knoten habe, dann ist es sehr übersichtlich mit der Verbindung.
Aber was ich jetzt zeigen will, ist eigentlich, gehen wir nochmal auf den vorigen zurück.
Hier wird es einfacher zu überlegen, wo kann ich aufbrechen.
Ich kann jetzt hier sagen, zeig mir das mal in einer anderen Darstellung.
Also ich bin gerade etwas erstaunt.
Ja, okay, jetzt wird ein Schuh draus.
Weil ich hätte jetzt gerade eben noch gesagt, ja, du mit deiner Erfahrung, du weißt vielleicht, wie man es da aufbrechen kann.
Ich hätte da jetzt gerade nicht viel gesehen.
Aber jetzt haben wir eine Darstellung, wo ich Verschachtelungen sehe.
Ich sehe aber vor allem Rechtskreise.
Ich sehe...
Das sind diese Bögen, das ist der sogenannte Exploration View, den wir hier sehen.
Und der Exploration View ordnet die Elemente untereinander an.
Und die Bögen gehen gegen den Uhrzeigersinn.
Also auf der linken Seite gehen die Bögen von oben nach unten und auf der rechten Seite von unten nach oben.
Der Clou daran ist, dass wir jetzt hier diese Knoten so sortieren, dass wir die minimale Anzahl von Bögen auf der rechten Seite haben.
Das wir benutzen den Graph-Algorithmus, um sozusagen hier ein Break-Up-Set zu finden.
Aber das heißt, durch diese vertikale Anordnung und dass ich wirklich Bögen mache und nicht Linien, ist, wenn jetzt ein Bogen größer ist, ist der Radius größer und ich habe dadurch auch keine Überschneidung von den Bögen, dass sie übereinander liegen, sondern ich sehe tatsächlich sehr schön die Anzahl der Bögen überall.
Genau.
Und ich kann jetzt auf so einen Bogen draufklicken und dann sehe ich, das sind 167 Abhängigkeiten.
Die werden jetzt mir hier unten angezeigt, einzeln.
Wenn ich hier auf so eine Zeile, das ist eine von den 167 Abhängigkeiten, wenn ich da drauf doppelt klick, bin ich im Source-Mod, kann mir die Stelle angucken.
Okay, das heißt, ein Bogen liegen doch mehrere Abhängigkeiten übereinander, aber es ist jeweils von dem einen Modul ins andere jeweils.
eine Abhängigkeit und die müsste ich dann alle auflösen.
Genau.
Und was du hier auch sehen kannst, dass die Bögen verschiedene Dicke haben.
Also manche sind dicker und manche sind dünner.
Das ist eine logarithmische Skala, die sagt, wie viele Abhängigkeiten sind dahinter.
Hier zum Beispiel dieser Bogen umfasst nur 12 Abhängigkeiten und der hier unten 10.
Und das Coole ist, ich kann es mit einem Blick sehen, ich kann diese Struktur dramatisch vereinfachen, indem ich diese beiden Bögen hier entferne.
Die beiden, die auf der rechten Seite hochgehen.
Dann bleibt am Ende nur noch bleiben diese drei im Zyklus übrig, weil die sich auch intensiv gegenseitig benutzen, aber der Rest wird zyklenfrei.
Okay, weil alle Abhängigkeiten quasi in eine Richtung gehen, dadurch kann es keinen Zyklus geben.
Und das ist der Trick, dass ich eben...
Genau, der Zyklus entsteht nur durch diese beiden Kanten hier.
Wenn die weg wären, und das Coole ist, ich kann das jetzt simulieren, das ist genau das, was wir für die KI auch gebaut haben.
Dass die KI eben solche Untersuchungen intern im Speicher macht, das sieht natürlich dann keiner.
Aber auf die Art und Weise kann man natürlich der KI enorm helfen, wenn man solche Strukturen hat.
Wie bricht denn das jetzt auf an der Stelle?
Also ich fand es vorhin schon mal interessant, dass du ja gesagt hast, die KI, wenn die Struktur besser ist, die guckt sich das Ganze an.
Und sieht, aha, okay, ich darf jetzt nicht von da nach da irgendwie eine Abhängigkeit einbauen.
Beziehungsweise umgekehrt, wenn sie sowas vorfindet, dann sagt sie sich, naja, hier haben wir schon zehn Abhängigkeiten, dann kommen noch die elfte und die zwölfte hinzu.
Das ist wahrscheinlich die Gefahr, dass die KI so einen schlechten Code, eine schlechte innere Architektur über die Abhängigkeiten dann mit ihrer Arbeit verstärkt.
Wie gesagt, ich glaube, das wichtigste Pattern zum Verstehen von KI und von der Qualität von KI ist, KI verstärkt, was sie vorfindet.
Baut auf dem auf, was schon da ist und benutzt dieselben Patterns, die sie schon im Code findet.
Und wenn das Pattern Big Ball of Mud ist, dann produziert die KI mehr Big Ball of Mud.
Beziehungsweise wenn sie irgendwo merkt, da ist schon mal unsauber gearbeitet, dann arbeite ich halt unsauber weiter.
Das funktioniert ja.
Okay, verstanden.
Das Coole ist jetzt hier noch, um das mal zu Ende zu bringen, wir können jetzt das simulieren, diesen Change.
Wir können jetzt hier draufklicken, auf die Kante sagen, was passiert, wenn die Kante nicht mehr da ist.
Ich mache ein sogenanntes Virtual Refactoring.
Kann ich jemandem zuweisen, auf die Aufgabenbeschreibung dazu geben, da wird eine Task draus.
Und dann sieht man schon, der hier unten wird einfacher.
Und jetzt tun wir den auch noch weghauen hier.
Jetzt bin ich gerade etwas erstaunt.
Du haust sie einfach weg.
Ich sehe einen Fortschrittsbalken, er refactort irgendwas.
Du sagst jetzt virtuell, also nicht echt.
Ich meine, so eine Abhängigkeit ist ja nicht einfach rauszunehmen.
Richtig, genau.
Aber da ist die KI zum Beispiel relativ gut drin, zum Beispiel eine Abhängigkeit zu entfernen, zum Beispiel durch Einführung von einem Interface oder durch Verschieben von Code.
Es gibt ja verschiedene Techniken, wie man solche Abhängigkeiten entfernen kann.
Die wichtigste Technik ist immer...
das Arbeiten mit Interfaces, aber es gibt auch andere Techniken durch Umstrukturieren von Code, durch Abändern von Klassen sozusagen, solche Abhängigkeiten dann loszuwerden.
Aber natürlich ist es eine schwierige Aufgabe, dass man in der Regel einen Menschen braucht, aber jetzt in der Zwischen, das, was ich gesehen habe, wenn es um Entfernen von Kanten geht, ist die KI sehr, sehr gut.
Das haben wir simuliert an Open-Source-Projekten, was passiert und dann haben wir tatsächlich mal versucht, mit dem MCP-Server zusammen mal so einen Big Ball of Mud aufzulösen und das ist enorm gut gelaufen.
Jetzt, du hast gerade die Theorie gut erklärt, sie ist einleuchtend und was machen wir beim Agentic Coding, wir sagen ja nicht mehr Wipe Coding, wir sagen einfach der KI, du kannst du mal nach Zyklen gucken und kannst du die auflösen, das wäre jetzt so das Triviale.
Funktioniert das gut?
Tja, da kommt genau so ein MCP Server ins Spiel.
Also es funktioniert, wenn wir jetzt von Java reden, ich meine, für jede Sprache ist es ein bisschen anders, weil jede Sprache ihre eigenen Patterns hat und eigene Strukturmuster und so weiter.
Und wenn wir jetzt mal von Java ausgehen und da eine Package Struktur haben, wenn ich der KI einen Prompt gebe, dass sie Zyklen auflösen soll, dann kann sie das sehr gut auf der Package Ebene.
Dafür braucht die kein Tool, weil was er macht, der analysiert die Imports sozusagen, braucht sich sein eigenes Bild auf und fängt an loszulegen.
Aber was man nicht vergessen darf dabei, dass die KI kein internes Modell der Software hat.
Die hat kein Dependency-Modell der Software.
Das heißt, sie muss alles, also wenn Dependencies analysiert werden mit KI, dann benutzt sie meistens ein Tool wie CREP dafür.
greppt nach einem Namen, um herauszufinden, wo kommt der überall vor in der Code-Basis, egal ob der im Kommentar steht oder zufällig eine Overloaded Function ist oder was auch immer.
Das ist ja das richtige Tool.
Der Name sagt es ja schon.
Dependency Analysis in grepp vor.
Nein.
Das ist also nur ein Hilfsmittel, was die KI...
Genau.
Und was wir dann festgestellt haben, bei dem Experiment, ohne den MCP-Server, komplett blind war es.
Java-File-Zyklen angeht.
Das kann sie nicht handeln.
Hier haben wir ein gutes Feedback, wie ich finde, das Language-Server-Protokoll.
Das könnte schon helfen, um im Source-Code zu navigieren, ne?
Ja und nein.
Also das war auch interessant, weil wir haben ja, als wir den MCP-Server gebaut haben, haben wir gesagt, wir müssen eigentlich im Memory eine Abhängigkeitsstruktur des Codes haben.
um wirklich gute Aussagen, um solche Algorithmen laufen lassen und so weiter und so fort, weil die KI hat es nicht.
Das heißt, wir benutzen dann das, was wir mit Grosz und Agraf gelernt haben, um sozusagen so einen Parser drin zu haben, der in ein paar Sekunden so ein System komplett parsed analysiert und Dependency-Modell aufbaut.
Wenn du jetzt mit einem Language-Server-Protokoll arbeitest, die Language-Server sind gut, was die Struktur angeht, aber nicht gut, was Abhängigkeiten angeht.
Die machen diesen Schritt der Abhängigkeitsauflösung, der findet in dem LSP-Protokoll nicht statt.
Ein LSP ist super, um zum Beispiel einen syntaxsensitiven Editor zu schreiben, der Highlighting macht und so weiter und so fort und so ein bisschen die Struktur erkennt, also den Baum, den Syntaxbaum sozusagen analysiert.
Aber was beim LSP fehlt, ist die semantische Phase, die dann die Dependencies auflöst, die dann sagt, aha, hier habe ich einen Function Call, der von der Klasse A in die Klasse B geht.
Ich dachte, dass zumindest so Features drin sind wie...
Zeig mir mal alle Aufrufe von dieser Funktion oder sowas.
Aber das ist dann nicht ganz so strukturiert, wie man es eigentlich bräuchte.
Genau.
Also als wir den MCP-Server gebaut haben, war natürlich mein erstes Ding, hey, können wir dafür nicht LSP benutzen?
Also Claude hat mir dafür dann gleich 20 Gründe genannt, warum das eben nicht geht.
Weil eben genau diese Dependency-Auflösung rudimentär ist, sondern eben nur on-demand gemacht wird und es gibt keine komplette Auflösung.
Wenn du jetzt fragst, wer benutzt denn das alles, dann läuft irgendwie eine Syntax-Baumsuche los über alle möglichen Stellen.
Das heißt, das Modell ist nicht fest vorhanden.
Es wird on-demand sozusagen erzeugt, was zu spät ist.
Wenn du eine Zyklin-Analyse willst, musst du alle Abhängigkeiten kennen.
Das heißt, die Motivation für den MCP-Server war, Ja, die KI zu unterstützen, so eine Architekturanalyse zu machen, weil es ist für uns Menschen schwer, sich durch die ganzen Klassen durchzuwühlen, für die KI ohne deterministisches Tooling genauso.
Und der MCP-Server liefert genau dieses deterministische Tooling.
Genau, der ist die Quelle der Wahrheit.
Das heißt, einer der großen Vorteile für Cloud ist, wenn du einen MCP-Server benutzt, der muss nie mehr Grab benutzen.
Der Dependency-Auflösungs-Tool im MCP-Server kann direkt fragen, wer benutzt denn das hier und kriegt präzise Antworten und nicht irgendwelche Gräbergebnisse.
Hier nochmal kurz, damit wir das mit den Zyklen hier oben nochmal abschließen können, bevor wir jetzt weiterspringen in die Details mit Claude und so weiter.
Wir haben ja hier diese beiden Kanten jetzt entfernt.
Wenn ich jetzt zurück in meine Graphen hier gehe, sieht man, dass der plötzlich zyklenfrei ist.
Dieser Graph hat jetzt plötzlich noch eine Zyklengruppe hier unten.
Das heißt, die ganzen Graphen.
Jetzt sind wir also aus der spezialisierten Ansicht raus, sind wieder in der Ansicht, wo wir die Komponenten sind.
Sind wir jetzt hier schon auf Klassenebene?
Genau, das ist der ursprüngliche Graph, den wir mal gesehen haben.
Der sieht jetzt ganz anders aus.
Diese Klassen hier in der Mitte sind alle zyklenfrei.
Dann gibt es hier unten noch zwei größere Cluster, nämlich den blauen Cluster hier oben und den gelben hier unten.
Also man sieht jetzt auf jeden Fall besser die Trennung zwischen den Clustern, zwischen den Packages, weil die Classen sind ja nach Packages eingefärbt.
Aber es ist jetzt noch nicht so, dass ich jetzt als Laie sagen würde, wow, da ist jetzt zwischen den Packages quasi nur noch eine Verbindung.
Das sind die auf der linken Seite, die von oben nach unten gehen.
Es sind ja immer noch viele Abhängigkeiten, aber nur noch in eine Richtung.
Genau, also die in der Mitte sind jetzt alle okay, weil das ist eine klar hierarchische Struktur.
Das ist also levelized dieser Graph.
Das heißt, die mit den meisten Ausgehenden sind oben und die mit den Eingehenden sind unten.
Es gibt also einen Cluster oben, einen Cluster unten.
In der Mitte sind es ungefähr 40, 50 Klassen, die zügelfrei sind.
Und das war also nur eine kleine Session.
Wir haben nur zwei Kanten geschnitten.
Das darf man ja nicht vergessen.
Das war jetzt der Beginn von der Session.
Und das kann ich jetzt an Claude geben.
Tu mir mal die Kanten raushauen.
Und 20 Minuten später hat Claude die Kanten weggehauen.
Und dann kann man zum nächsten Schritt übergehen.
Das Ziel ist ja nicht, mit einem einzigen Schritt sozusagen alle Zyklen komplett aufzulösen.
Das ist unrealistisch.
Weil das wird ein viel zu großes Change-Set am Ende.
Das Ziel ist, durch inkrementelle Verbesserungen langsam an diesen Big Ball of Mud reinzuhämmern und Stückchen rauszuhauen, bis das Ganze in eine gute modulare Struktur übergeführt werden kann.
Wir können das Spiel hier mit den beiden Remining Clusters, das ist wahrscheinlich dieselbe Session, dass man hier anfängt, das gruselig auskriegen wir als Kommentar.
Das sieht immer noch gruselig aus.
Genau, den Halloween-Kommentar.
Passend zu Halloween, ja.
Aber come on, also hier sieht es schon mal deutlich besser aus, ja, auf der Package-Ebene, wenn man das mal anschaut hier.
Aber klar, das war jetzt ein erster Schritt.
Aber mit zwei weiteren Sessions für jeden von diesen Clustern kann man sich vorstellen, dass wir das weiter so weit verbessern, bis wir am Ende eine Struktur haben.
Also der Grund, warum wir diese Zyklen ja alle weghauen wollen, ist auch, dass ich am Ende darüber dann mein UML-Component-Diagramm drüberlegen kann, ohne dass ich eine zyklische Komponentenstruktur bekomme.
Aber sag mal, das wäre doch jetzt ein Weg.
Ich habe einen Big Ball of Mud, ich kann keine Komponenten rausziehen.
Das heißt, mir fällt es auch schwer, das Ganze zu erneuern, weil ich eben nicht die Modularität habe.
Jetzt habe ich Zyklen entdeckt, habe gesehen, welche Kanten ich entfernen muss.
Gebe das an Claude, dass der das Heavy Lifting macht.
Genau.
Danach habe ich, ja.
kann ich Module schneiden und könnte dann die Software dementsprechend modernisieren, oder?
Genau so ist es ja.
Und jetzt das nächste Thema, wir haben ja gesagt, über zwei Säulen gesprochen.
Die eine Säule war das Architekturmodell und die zweite Säule war die möglichst zyklenfreie Struktur.
Wenn es mir gelingt, die Struktur über weite Strecken zyklenfrei zu halten oder zyklen zu minimieren, dass ich nur kleine Zyklen drin habe, dann kann ich immer später ein Architekturmodell drüberlegen.
Wenn ich umgekehrt aber dann diese großen Zyklen bekomme, in diesem Dependency-Manage-Modul gibt es keine Unterstruktur mehr.
Das ist alles ein großer Big Ball of Mad.
Das heißt, da kann ich dann nichts mehr unterteilen, weil die unterteilt Struktur wäre genauso zyklisch und damit eben keine Struktur, wie die Basis-Struktur, von der wir ausgegangen sind.
Und jetzt kommt halt der nächste Schritt.
Idealerweise willst du eigentlich dahin kommen, dass die KI schon bevor sie eine neue Abhängigkeit im Code anlegt, jemand fragen kann, ist das eine gute Abhängigkeit, kann ich den Code einbauen?
Bevor überhaupt der Code generiert wird.
Und wenn du so ein Tool dann hast und die KI fragen kannst, hier seht ihr gerade, wie sagst du Claude, womit er entfernte Kanten richtig ersetzt?
Das wäre jetzt auch so demnächst meine Frage gewesen.
Also ich komme aus der ARC-42-Welt, ich habe Qualitätskriterien, ich habe Architekturentscheidungen und ich denke mir, kriegen wir das bei Software tatsächlich hin, dass wir Kanten ersetzen?
Du sprachst vorhin von Interfaces und solchen Geschichten, sodass wir die Funktionalität und die Qualitäten nicht verändern?
Ja, absolut möglich.
Also das war genau der Test, wir haben da mit einem Open-Source-Projekt, das heißt JPOS.
Da haben wir mal so ein Experiment gemacht.
Das hat auch so ein Big Ball of Mud Cluster drin gehabt mit Packages und Komponenten involviert.
Und da haben wir dann mal eine Session gemacht mit Cloud.
Wie können wir das jetzt verbessern?
Und das Gute an dem Ding ist, dass dieses Open-Source-Projekt hat eine Test-Suite gehabt mit 4000 plus Tests.
die aber relativ schnell durchgelaufen ist.
Dadurch hat man dann schnell einen Turnaround gehabt und konnte immer noch nachweisen, dass die Funktionalität noch so ist, wie sie ist.
Und Claude ist erstaunlich gut darin, diese Kanten zu entfernen.
Der benutzt alle Patterns, die er so kennt, um Kanten eben zu ersetzen oder loszuwerden oder eben die Richtung umzudrehen.
Das ist das Dependency-Inversion-Pattern, gerade Interfaces, erlaubt dir, die Richtung von der Dependency umzudrehen und damit eben Zyklenstrukturen aufzubrechen.
Und das macht er gut.
Also das habe ich gesehen, da habe ich live gesehen, dass er nach und nach eine Kante nach der anderen entfernt hat und dann immer wieder die Tests hat laufen lassen, ob die alle noch gehen und dann den MCP-Server gefragt hat, stimmt meine Struktur noch?
Und dann eben nach und nach die Struktur verbessert.
Aber wie gesagt, die zweite Säule ist jetzt eigentlich die entscheidende, nämlich die Architektur-Modellierungssäule.
Wie modellierst du die Architektur?
Als ich das Thema Resarched habe für den DAX-Vortrag, habe ich im März angefangen, mit April sowas mit dem Vortrag dann gemacht.
Dann kam Claude, ja, wir brauchen irgendwelche architectural boundaries, um eben das auch überprüfen zu können.
Und dazu versorgen wir Tools wie ArcUnit benutzen.
Was ja schon mal ein Schritt in die richtige Richtung ist.
Der Nachteil ist, dass ArcUnit ein bisschen spät im Spiel kommt, weil der Agent erzeugt den Code.
Dann muss er die Test-Suite laufen lassen und dann sagt ihm ArcUnit, hey, das war jetzt nicht okay, mach bitte was anderes.
Dann geht er wieder zurück, muss die Änderung wieder zurückdrehen, anders probieren, geht er wieder an ArcUnit.
ArcUnit sagt ihm wieder, es ist immer noch falsch, hier und da stimmt noch irgendwas nicht.
Das ist also eine Iteration, die länger dauert unter Umständen.
Das zweite Problem ist, dass es in ArcUnit und ähnlichen Tools kein Architektur-Modell gedanken ist.
In ArcUnit baust du nicht ein UML-Component-Diagramm auf.
Im Prinzip definierst du eine Menge von Regeln, die alles definieren, was verboten ist.
Es gibt da zwar elementare Ansätze, zum Beispiel eine Layered Architecture aufzubauen, solche Dinge sind auch in ArcUnit drin, also das ist ein Schritt in die richtige Richtung, aber sehr rudimentär.
Also das heißt, du musst im Vorhinein schon alles vorhersehen, was verboten ist und dann für jede der möglichen verbotenen Aktionen einen ArcUnit-Test schreiben.
Und dann weißt du auch noch nicht, ob alles abgedeckt ist.
Deswegen ist so ein Architekturmodell immer besser, wenn du sagen kannst, ich kann feststellen, ich kann actually messen, dass ich meine ganze Software mit abgedeckt habe, dass jede Klasse zu irgendeiner Komponente gehört, UML-Komponente.
Und dann kann ich am Ende, wenn ich so ein Modell habe, kann ich dann über die statische Analyse beweisen, dass es keine Architekturverletzungen gibt.
Oder wenn es welche gibt, kann ich beweisen, wo sie sind.
Und jetzt kann natürlich ein MCP-Server, der so ein Modell hat, kann es zwei Fragen an das Modell stellen.
Zum Ersten ist diese Kante, die du hier einführen wirst, konform mit meiner Architektur.
Und die zweite Frage, die er stellen kann, wenn du diese Kante hier einbaust, tut die einen Zyklus entstehen lassen oder einen bestehenden Zyklus vergrößern.
Zwei Fragen, die der MCP-Server in Bruchteilen von Sekunden beantworten kann, aufgrund von dem Modell.
Das heißt, Claude kriegt, bevor überhaupt die erste Zeile Code geschrieben hat, schon mit, ob das eine erlaubte Abhängigkeit ist oder nicht.
Das heißt, Und wenn die Abhängigkeit nicht erlaubt ist, dann kann der MCP-Server sogar Vorschläge machen, was stattdessen möglich ist.
Aber sag mal, ich habe ja früher auch viel Java gemacht und da hat man ja auch so die Sichtbarkeit von Klassen, von Properties, Public, Private, sonst was, die Modifier.
Und sorgen die nicht eigentlich schon dafür, dass nur die richtigen Verbindungen aufgebaut werden können?
Sollte das nicht eigentlich das Sprachelement sein, was sich darum kümmert?
Ja, dann erklärbar, wie der Big Ball of Mud in Hibernate oder Cassandra entstanden ist.
Ja.
Also, wie reicht das nicht aus?
Weil diese Public- und Private-Geschichten gehen ja nur auf Package-Ebene.
Bezieht sich ja nur auf den Package-Scope.
Das ist viel zu gering, um jetzt sozusagen eine größere Architektur zu mobilisieren.
Dann könnte man jetzt argumentieren, naja, wir können ja stattdessen Java-Module benutzen.
Das ist ja ein cooles Feature, wo sie sehr lange gebraucht haben, das umzusetzen.
Aber selbst Module können auch nicht geschachtelt sein.
Immerhin haben sie dann ein Interface, das ich sagen kann, ich mache nicht alles sichtbar, was in dem Modul drin ist, sondern nur gewisse Sachen.
Das ist schon ein Schritt in die richtige Richtung.
Aber du hast immer noch eine eindimensionale, nicht schachtelbare Struktur.
Und selbst beim einfachsten Domain-driven-Modell hast du eigentlich schon eine geschachtelte Struktur.
Du hast die Domains als Hauptblöcke.
Und innerhalb von den Domains hast du wieder Schichten.
Das heißt, du hast hier automatisch schon eine geschachtelte Struktur.
Nichts von denen kannst du mit Java-Sprachmitteln abbilden.
Und die meisten Programmiersprachen sind leider, was diese Architekturecke angeht, einfach unterbelichtet.
Das ist eigentlich schade, wenn ich eine Programmiersprache entwickeln würde jetzt, wenn ich die Chance hätte zu sagen, ich entwickel die Sprache für das nächste Jahr 1000, dann würde die definitiv Architektur-Constraints mit drin haben, schon in der Sprache selbst.
Also das heißt, dein Ansatz ist erstmal eine Architektur entwerfen, damit das LM weiß, was erlaubt ist, aber dann auch die Architektur überprüfen, um zu sehen, ob es sich an die Regeln gehalten hat.
Stimmt das so?
Genau.
Ich kann jetzt mal ein Beispiel zeigen, wie so eine Architektur aussieht.
Ich habe diese Folgen hier noch irgendwo, wenn ich Glück habe.
Dann suche ich jetzt mal eine mit einem Architekturbeispiel raus.
Das ist im Prinzip ein ganz einfaches Beispiel von dieser Architektur-Diagramm, was wir hier sehen.
Es gibt ein Artefakt.
Artefakt ist sozusagen unsere Komponente oder die Box im Architektur-Diagramm.
Und das Include-Statement sagt mir, was ist da drin.
Zum Beispiel alle, wo Web im Package-Namen vorkommt.
Das ist unser Artefakt Web.
Dann gibt es ein Service-Artefakt und ein Domain-Artefakt.
Das ist also die einfachstmögliche Architektur, die wir hier sehen.
Und die Abhängigkeitsstruktur wird durch dieses Keyword relaxed hier ersetzt.
Das heißt, relaxed layering bedeutet, dieses Webding darf auch alle Geschwisterkomponenten zugreifen, die unten drunter definiert sind.
Also Web darf auf Service und Domain zugreifen und Service darf auf Domain zugreifen.
Das heißt, jetzt für unsere Hörer, es ist eine textuelle, eine Domain-specific-Language, in der ich definiere, welche Komponenten auf welche zugreifen dürfen.
Genau.
Das kann dann noch verfeinert werden.
Also hier gibt es jetzt zum Beispiel ein Artefakt Tree, das aber ein Interface hat.
Das heißt, in dem Tree-Artefakt ist alles drin, wo Tree irgendwo im Package-Namen vorkommt.
Und dann gibt es ein sogenanntes Default-Interface, also das ist die Default-Schnittstelle.
Wenn jemand sich mit Tree connectet und kein Interface angibt, bekommt er dieses Interface hier und er sagt, da ist alles drin aus Tree, außer...
dem Fokushändler, TreeHändler, CollapseInfo und diverse andere Sachen, die dann eben ausgeblendet werden.
Das heißt, wir definieren über das Interface, was ist nach außen sichtbar und das ist in der Regel dann eine Teilmenge von dem, was in der Komponente drin ist.
Das ist halt im Prinzip so in zwei Sätzen die Architekturbeschreibungssprache.
Und das Coole ist, wenn du diese Sprache hast, die habe ich dann Claude mal gezeigt.
Und Claude war begeistert, wenn man sowas sagen kann über einen KI-Agenten.
Manchmal schleimt er auch ein bisschen und will nett sein, aber Claude hat die Sprache eigentlich relativ auf Anhieb verstanden.
Ich müsste ihm noch zwei, drei Konzepte erklären.
Allein mit dieser Sprachdefinition schon ohne MCP-Server kann Claude schon was anfangen.
Er kann das lesen, verstehen und versucht sich schon in die Regel zu halten.
Das Problem ist, dass natürlich dann sind subtile Dinge drin, wie dieses Pattern-Matching funktioniert und so weiter, da ist Clutter nicht perfekt, macht gerne noch Fehler.
Deswegen kann man das natürlich in den MCP-Server reinpacken, der versteht die Sprache perfekt, weiß genau, was wo zugeordnet ist und kann dann alle wirklichen Fragen zum Thema beantworten.
Das heißt, wir hatten das ja auch schon früher, zum Beispiel Plant-OML, die ersten Plant-OML-Diagramme, hat die KI nicht so ganz die Syntax verstanden, waren immer irgendwelche Fehler drin und Man hat versucht, sie irgendwie zu korrigieren.
Mittlerweile sind die LLMs da ziemlich gut.
Plant-Union ist jetzt auch Open-Source und recht bekannt.
Und hier sagst du, dass die KI die Sprache eigentlich ganz gut versteht, aber der MCP-Server eben darauf ausgelegt ist, die KI auch zu guiden und dann diese Sprache zu schreiben und zum Beispiel...
verhindert, dass Keywords reinkommen, die falsch sind oder so, weil Claude sagt, ich habe mir gedacht, das könnte so gehen.
Ist das so?
Ja, das ist ein bisschen genau in die Richtung.
Das hast du schon relativ nah angedeutet.
Das Coole ist, dass der MCP-Server dem Claude eben auch beibringt, wie die Sprache funktioniert.
Also er hat eine Erklärungsfeature und das heißt Claude kann dann selber die Architektur mit der Sprache definieren.
Das haben wir auch mal ausprobiert in einem Projekt, wo wir dann so ein Testprojekt aufgesetzt haben, um zu sehen, wie das funktioniert.
Und ich habe ihm eigentlich als Prompt gegeben, create a layered architecture divided by domains.
Das war der Prompt.
Okay.
Und hat er gemacht, hat dann komplette Architektur-Spezifikation rausgehauen.
und sich dann beim späteren Codieren an seine eigene Architekturspezifierung gehalten.
Die habe ich natürlich überprüft und war im Großen und Ganzen okay.
Und dann gab es aber andere Beispiele wieder, wo man auch sehen kann, wie wichtig ist es für den MCP-Server gebaut worden.
Der heißt Zügel, by the way.
Das ist also der Produktname dafür.
Zügel haben wir entwickelt, weil wir sagen, der Zügel für das Pferd, für das Wildpferd, das in die falsche Richtung rennen will.
Der MCP-Server kann ja immer in drei Sprachen.
Der kann Python, Java und C-Sharp.
Eine der wichtigsten Architekturregeln ist, dass diese Sprachmodule komplett irgendwie getrennt sind voneinander und irgendwie auch austauschbar sein müssen, weil jede Sprache anders irgendwie die Analyse durchführt.
Und als da der Klotterngerarbeitete hat an einem Ding und ohne die klare Architekturregeln hat er das schnell irgendwie bounderisch verwischt zwischen den verschiedenen Elementen.
die dann nicht mehr so klar auseinanderzuhalten waren, nicht mehr so klar modularisiert waren.
Da musste ich dann die Architektur nachschärfen.
Also da habe ich dann von Hand nachgeschärft, um sicherzustellen, dass das nicht mehr passieren kann und dann hat es auch funktioniert.
Okay.
Das heißt also, der korrekte Ansatz wäre, dass Claude erstmal eine Architektur in Form von einer Komponentenverschachtelung entwirft, das über den MCP-Server in diese DSL gießt, damit klar definiert ist, wie die Architektur sein soll und dass man dann eben später die Regeln überprüft, dass eben wirklich keine Zyklen drin sind.
Beziehungsweise wenn man eben Legacy Software hat und schon den Big Ball of Mud, dass man dann eben gleich reingehen kann, die Zyklen analysieren kann und erstmal auflösen kann.
Wobei wir hier, Christopher haben wir noch nicht ganz abgeholt, der immer noch sich fragt, wie ist das mit der Kantenersetzung?
Aber wenn ich das richtig verstanden habe, dann ist das ja quasi eine Sprachdefinition, diese Kanten, diese Abhängigkeiten, die da entstehen und nicht unbedingt Features, Qualitäten, ja Qualitäten, Modularität, ja, aber Aber ich kriege die Ersetzung, ich glaube, man muss mal erlebt haben, dass man sieht, dass die Ersetzung funktioniert, ohne dass man die Funktionalität bricht.
Genau, genau.
Wir haben jetzt noch ein paar Fragen aus dem Grund.
Ich wollte eine Sache noch erwähnen bei dem Ganzen.
Ich meine, wo es dann wirklich enormen Unterschied macht, mit so einem MCP-Server zu arbeiten, ist, wenn ich dann mehrere Agenten habe, also mehrere Entwickler, die alle mit Cloud arbeiten, auf demselben System.
Da wird dann sowas lebenswichtig, weil du hast Cloud oft, also Cloud ist lokal eigentlich ganz gut, aber wenn jetzt zehn Clouds auf demselben System arbeiten, die wir mit dem eigenen Entwickler, dann kann es sein, dass plötzlich Chaos entsteht.
Da werden diese Regeln dann wichtig, wenn die alle mit denselben Architekturregeln arbeiten.
kann man dieses Problem sehr stark mitigieren damit.
Das erinnert mich jetzt an mein Beispiel vorhin mit dem Linter, wo jeder Lauf ein eigenes Testframework verwendet hat.
Das wäre jetzt hier so, wenn mehrere Agenten arbeiten und merken, oh, sie müssen hier vielleicht ein neues Modul einführen, dann macht das einer, setzt das in die Regeln rein und die anderen sehen schon, guck mal, ist da, halten wir uns dran.
Beziehungsweise Naming ist das Gleiche und wahrscheinlich auch noch andere Aspekte.
Genau.
Also man kann damit einfach einen übergreifenden Rahmen vorgeben, der auch von parallel laufenden Agenten genutzt werden kann, was dann wirklich zu großem Mehrwert führt am Ende.
Wir haben hier noch eine Menge Fragen im Chat drin, vielleicht nachdem die Zeit jetzt ein bisschen zu Ende geht.
Sollen wir nochmal drauf gucken.
Also Reichdefinition in ClotMD zum Beispiel ist eine gute Frage.
Damit fangen alle an.
Und Clot selber sagt, was in ClotMD steht, ist für ihn eine Suggestion, die er benutzen kann oder nicht.
Und die Frage ist, wie ausführlich ist man, wie genau man es beschreiben kann.
Der Vorteil von der formalen Beschreibungssprache, von der formalen DSL, dass es halt präzise ist, dass sie genau vermessen werden kann.
und auch genau Stellen im Code finden, wo Verletzungen stattfinden.
Aber Cloud MD ist mit Sicherheit ein Anfang.
Man könnte zum Beispiel die Architektur DSL referenzieren von Cloud DSL und Cloud kann dann schon ganz gute Ergebnisse mit erreichen.
Ich habe sogar gesehen in einem anderen Beispiel, wo wir versucht haben, mal dasselbe Projekt aufzusetzen, einmal mit Cloud allein und einmal mit Cloud und MCP-Server, dass wenn Cloud allein war, also in dem Prompt-Start natürlich drin, dass wir Architekturregeln haben wollen.
hat er sich selber ein kleines Architektur-Framework gebaut und dann über Greppen von Import-Stables und so weiter Architektur-Regeln definiert.
Also es ist alleine draufgekommen, was gut war, es war nicht perfekt die Lösung, aber besser als nichts.
Mit dem MCP-Server, was wir aber festgestellt haben, dass es dann schneller geworden ist.
Von jeder Iteration, von jedem Step wurde dann der Schritt, der den MCP-Server, es hat weniger Tokens gebraucht, ist schneller fertig geworden als der andere.
Aber auch der MCP-Server ist ja eine Empfehlung, die quasi in der Cloud MD drin steht.
Du hast hier einen MCP-Server, nutzt den.
Ist vielleicht auch in der Function Definition.
Aber er muss sie ja nicht benutzen, die MCP-Server.
Kann ich das Tooling auch quasi in die Build-Pipeline, den Outerloop reinsetzen, sodass Ja, er muss ja die Build-Pipeline grün bekommen und wenn es eine Architekturverletzung gibt, dann checkt er das automatisch und sagt, nee, ist nicht?
Genau, also das ist genau, das ist natürlich dann, was immer noch als Sicherheit mit drin ist.
Es müssen natürlich, die Regeln sollten auch in der CI-Pipeline drin sein.
Das heißt, beim Jenkins oder was immer ich da benutze, müssen wir natürlich auch geprüft haben, ob die Architektur da ist.
Da kommt dann die Zusammenarbeit zwischen so einer Graph und Zügel ins Spiel.
Und so ein Graph hat natürlich dann den Synagraph Bild, der dieselbe Sprache versteht und der sozusagen dann im Bild checken kann, ob das alles korrekt ist oder nicht.
Wir haben hier noch eine Frage, was mit dynamischen Systemen ist.
Aber du hast ja jetzt schon gesagt C Sharp, Java und war nicht auch Python dabei?
Python ist auch dabei, ja.
Und Python ist ja eigentlich hochgradig dynamisch.
Genau.
Also in Python hat man natürlich ein nicht 100% vollständiges Abhängigkeitsmodul.
Das darf man nicht vergessen, ja.
Ich kann Abhängigkeiten sehen, manchmal kann ich Abhängigkeiten, weil die dynamisch sind und erst zur Laufzeit überhaupt berechenbar sind, sehe ich die nicht.
Und ich kann natürlich jetzt erstmal nur mit dem arbeiten, was der MCP-Server sehen kann, nämlich die echten Abhängigkeiten.
Also dynamische Abhängigkeiten werden so nicht gesehen.
Und dasselbe gilt auch, was der Herr Nguyen hier gefragt hat.
Dynamische Systeme, in denen man zum Beispiel in Java Reflection verwendet wird, das wird nicht berücksichtigt.
Also wenn jemand irgendwelche Shenanigans über Reflection macht, das sehen wir in dem MCP-Server nicht.
Aber ich glaube, das ist dann auch eine erste Architekturentscheidung, was für eine Sprache ich nehme.
Ich meine, wenn ich zum Beispiel eine typisierte Compiler-Sprache nehme, dann weiß ich, wenn das Ganze kompiliert, dann ist es syntaxerrorfrei und die Typen sind korrekt.
Wenn ich eine interpretierte Sprache nehme, dann kann ich nicht den Compiler anschmeißen, sondern dann...
muss ich halt testen, ob der Code interpretiert werden kann, indem ich jedes Pfeil mal irgendwie lade.
Ist eine erste Architekturentscheidung und ich gehe jetzt davon aus, dass dein Framework eben auf statischen Systemen, also Java und Dynamik.
Was man zur Compile-Zeit finden kann, basiert das Ganze.
Also dynamische Abhängigkeit hätten wir nicht.
Aber es ist auch wieder einfach relativ einfach.
Ich kann zum Beispiel mit Reflection.
in einen Artefakt reinstecken und dann beschränken, wer das benutzen kann.
Wer zum Beispiel ein erster Schritt.
Also, dass nicht jeder mit Reflection irgendwelche Schnellgents macht.
Das wäre schon mal gut.
Es gibt auch eine Frage, die jetzt auch wichtig ist, und zwar Wolfgang Frech hat gefragt, wir bauen jetzt alle Greenfield und schauen dann.
Und hat er auch erwähnt, ich habe in den letzten 30 Jahren nie im engeren Sinne Greenfield-Projekte gehabt, wenn er ihnen nützlich sein soll, dann für Weiterentwicklung und Modernisierung.
Das war eigentlich die ganze erste Hälfte von dem Talk, wo wir darüber gesprochen haben, wie können wir existierende Systeme modernisieren und verbessern, auch mit der Hilfe von KI.
Und da ist ja KI genau die große Stärke, dass ich damit in die Nähe von dem magischen Fix-it-Button bekomme.
So eine Kombo aus einem MCP-Server mit Dependency-Modell und KI ist enorm stark, um solche Strukturen zu modernisieren, zu verbessern und in die richtige Richtung zu bringen.
Sorry.
Ja, ich glaube, das ist tatsächlich auch die große Herausforderung.
Wir sehen momentan sehr viele KI-Demos, wo Leute auch Software nachbauen oder so.
Aber alles Greenfield, wo die KI ihre Entscheidungen treffen kann.
Und wenn wir auf Legacy treffen, ja, dann fängt es erst mal an.
Haben wir Testabdeckung?
Haben wir Dokumentation?
Haben wir eine Architektur?
Und dann ist natürlich ein Tool, mit dem ich die Architektur erst mal mir angucken kann, Gold wert.
Absolut, ja.
Also das ist, ja, Game Changer, würde ich sagen, ja.
Ja, sehr cool.
Wir sind schon über die Zeit, aber ich fand es jetzt echt extrem wertvoll, was du jetzt hier so uns näher gebracht hast, den Ansatz, wie ich mit der KI die innere Architektur irgendwo sauber hinbekommen kann und den Big Ball of Mud, aufräumen kann, aber auch beim nächsten Mal, wenn ich Greenfield mache, irgendwie die Architektur besser vorgeben kann.
Fand ich super spannend.
Herzlichen Dank für diesen Einblick.
Gerne, gern geschehen.
Hat auch mir Spaß gemacht.
Hier ist nochmal der Wolfgang Frech.
Ist denn ein LM das richtige Werkzeug, um im Code zu arbeiten und zum Beispiel Abhängigkeiten umzudrehen?
Absolut, ja.
Also das macht definitiv Cloud schneller, als ich das machen könnte.
Habe ich auch schon ausprobiert.
Also sobald ich mir dieses Feature mit der Graph-Partitionierung, was wir in so einer Graph gesehen haben, das war das erste größere Feature, wo ich Cloud allein in so einer Graph habe arbeiten lassen und das Feature war in zwei Stunden fertig.
Also da war ich schon sehr beeindruckt.
Aber das Spannende an dieser Frage ist, also nur der erste Teil hätte ich gesagt, naja, Genauso ist die Frage, ob ein Mensch das richtige Werkzeug ist, um im Code mit Abhängigkeiten zu arbeiten.
Aber dann dieser zweite Teil mit der guten IDE.
Und ich glaube, da kommt ja eben auch dein MCP-Gedanke rein, dass ich damit...
Ja, die KI könnte jetzt zyklische Abhängigkeiten finden, aber mit dem richtigen deterministischen Tool über MCP angebunden geht das besser.
Genau.
Und wenn ich jetzt eben diese Refactoring-Module aus der IDE, keine Ahnung, Methode rausziehen oder sowas, auch noch als MCP hätte, ich glaube, da hat Wolfgang schon...
Oh, jetzt ist er plötzlich weg.
Haha, das ist jetzt schade.
Jetzt machst du mal kurz weg.
Ich dachte, okay, perfektes Timing.
StreamYard hat gesagt, ups, irgendwas ist schiefgelaufen.
Ja, ich habe es gemerkt.
Ich war weg.
Ja, also ich glaube, das Thema bleibt spannend.
Und ich glaube, da können wir noch lange drüber reden.
Aber jetzt sollten wir mal dann unsere Zuschauer auch ins Wochenende verabschieden.
Alexander, herzlichen Dank für deine Einblicke.
Für allen, denen es Spaß gemacht hat, das nächste Mal, nächsten Freitag, haben wir eine größere Gesprächsrunde über Self-Contained Systems.
Das wird, glaube ich, auch nochmal spannend, weil auch da nochmal das Zusammenspiel von KI und wie schneide ich Module und kann ich hier Self-Contained Systems auch abbilden?
Die Abhängigkeiten ist wahrscheinlich über die verschiedenen Ebenen etwas schwieriger.
Genau, also das Tool, also der MCP-Server schaut nur innerhalb eines Systems rein, also innerhalb einer Code-Basis, ja.
Auf Projekte beschränkt und kann also jetzt nicht zum Beispiel, also er kann zwar zwischen Projekten hin und her springen, das kann er schon, also einfach Switch Project machen, aber er kann jetzt keine Abhängigkeiten zwischen Projekten, die jetzt über andere Kanäle, zum Beispiel Messaging oder sowas kommen, das wird im Moment nicht analysiert, das wäre vielleicht die nächste Stufe, dann mal eine Ebene weiter hoch zu gehen.
Aber wenn ich jetzt zum Beispiel das Frontend über Vardin Ab Frühstücke, was ja eben in Java das Frontend definiert, dann müsste ja das Tooling wieder greifen können.
Genau.
Genau so ist es, ja.
Okay, dann herzlichen Dank.
Auch vielen Dank für die Einladung.
Es hat viel Spaß gemacht.
Ich glaube, das ist ein Thema, aber kann man sehen, dass mir das sehr am Herzen liegt.
Und ich glaube, dass ich das...
fundamentale Problem, wie bauen wir sauber strukturierte Software?
Das fundamentale Problem hat sich seit 30 Jahren nicht geändert.
Das ist immer auch dasselbe.
Ja, definitiv.
Das wird auch bleiben.
Ich würde sagen, mit KI wird es sogar noch wichtiger jetzt.
Je besser die Struktur, desto besser die Ergebnisse.
Gut.
Also dann, tschüss, schönes Wochenende und auf bald.