Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Folge 298 - Spec-Driven-Development mit Simon Martinelli Hallo, ich bin Eberhard Wolff.

Ja, hallo und herzlich willkommen zu einer neuen Folge von Software-Architektur im Stream.

Die erste Folge in diesem Jahr.

Heute zu Gast Simon Martinelli.

Simon ist Java-Champion, er ist Vaadin, ist es Champion, genau Champion und bei Oracle heißt es Ace Pro.

Simon, möchtest du kurz was über dich erzählen, was du so machst, was dein Steckenpferd ist?

Ja, hallo zusammen.

Ich bin seit 30 Jahren in der Software-Entwicklung tätig.

Mittlerweile bin primär im Java-Umfeld dabei und mache ganz viele Sachen.

Ich bin auch Dozent an zwei Fachhochschulen in der Schweiz und kümmere mich aber in der letzten Zeit vor allem um Software-Modernisierung.

Die letzten sieben Jahre habe ich vor allem Legacy-Systeme modernisiert und aktuell mache ich ganz viel im Bereich, wie können wir Software modernisieren und das KI unterstützt, damit wir da schneller werden.

Und deshalb ist auch KI wichtig geworden.

Genau, ich finde es total cool, dass du so in der Community unterwegs bist und dein Wissen teilst und du teilst ja auch dein Wissen, wie du mit der KI umgehst.

Dafür sind wir ja jetzt hier gerade da.

Du hast mir ja im Vorfeld erzählt, dass du seit über einem Jahr quasi nach diesem Prozess arbeitest, recht erfolgreich.

Das funktioniert, die KI zu integrieren als Sparings-Partner und ja, es ist quasi schon fast unglaublich.

Viele Leute haben Probleme, die KI tatsächlich in produktiven Projekten einzusetzen und du sagst, wieso, geht doch.

Willst du da mal ein bisschen Details erzählen?

Also ich kann mal erklären, wie es bei mir begonnen hat.

Ich bin im Turnverein in der Schweiz und noch in anderen Verbänden, Vereinen, Gruppierungen dabei.

Und diese Gruppen sind eine Quelle von Anforderungen für Software im Prinzip.

Und wir organisieren ein Strandfest in der Schweiz vom Turnverein und ich habe eine Bekannte, die organisiert mit einem Verein ein Musikfestival, ein Open Air Festival im Sommer.

Und plötzlich hatte ich da eine Anforderung von beiden, dass es eigentlich cool wäre, wenn man Helfer verwalten könnte.

Und es gibt Software, die Helfer verwalten können, aber halt nicht unbedingt so, wie wir das jetzt machen oder so, wie wir das gerne hätten.

Und der Freund vom Turnverein hat dann gesagt, hey, du bist doch Softwareentwickler und KI ist da, mach.

Und dann habe ich gesagt, okay, mache ich mal.

Und dann habe ich so mit Windsurf begonnen.

Ungefähr im September 24 war das, als ich damit begonnen habe.

Und ich habe relativ rasch gemerkt, dieses sogenannte Vibe-Coding, obwohl es diesen Begriff damals noch gar nicht gab.

Das führt zu nichts, weil nicht, weil es nicht funktioniert hat, sondern weil ich nicht mehr wusste, wo ich war.

Ganz kurz, Windsurf ist die KI-IDE, die auf Visual Studio Code basiert, ne?

Genau, genau.

Und dann habe ich da relativ rasch was gehabt, auch mit Java.

Kein Problem, ich verwende Vaadin, wie du bereits gesagt hast, das verwende ich schon sehr lange.

Und das Coole an Vaadin ist halt, es ist ein Fullstack-Framework und Fullstack ist für KI sehr gut geeignet, weil es nur ein Ökosystem gibt.

Du hast nur Regeln für eine Sprache.

Du hast Leitplanken für diese Sprache.

Das ist eigentlich relativ gut geeignet.

Aber ich wusste nicht mehr, was habe ich implementiert, wo stehe ich gerade und hatte auch keinen Plan, was ich genau tue.

Und deshalb habe ich mir überlegt, ja, wie könnte ich das besser machen?

Und ich habe tatsächlich nach ungefähr drei Monaten alles weggeworfen, was ich bisher gemacht habe, bin einen Schritt zurückgegangen und habe begonnen, mich darauf zu besinnen, was hat für mich gut funktioniert in der Vergangenheit.

Und das waren Use-Cases, also Use-Case-Beschreibungen, weil die haben Vor-Bedingungen, Nach-Bedingungen, haben einen Ablauf, haben alternative Abläufe, haben Business-Regeln und das ist im Prinzip eine Task-Liste für KI, damit sie Software entwickeln kann.

Und ich habe dann tatsächlich begonnen, mithilfe von KI natürlich die Anforderungen an diese Software, um diese freiwilligen zu verwalten, zu erzeugen.

Das Interessante war natürlich, der ganze Requirements-Prozess war da mit dabei.

Also ich habe die Requirements-Katalog gemacht und dann Domänen-Modelle abgeleitet und Use-Cases abgeleitet und alles KI unterstützt.

Und ich habe ungefähr 70 Use-Cases in diesem System und bin vor zwei Wochen live gegangen in einer Beta-Phase.

Und das hat gut funktioniert, weil ich habe eigentlich nicht selber programmiert, sondern ich habe dann so ab Februar, als Cloud-Code rausgekommen ist, habe ich mit Cloud-Code begonnen zu arbeiten.

Und ich bin nach wie vor damit unterwegs, weil ich das nach wie vor das beste Werkzeug finde und ich habe eine Applikation, die läuft.

Und in der Zwischenzeit habe ich dann begonnen, in einem ERP-Modernisierungsprojekt mitzuarbeiten, respektive ich war schon vorher dabei.

Aber wir haben relativ rasch gemerkt, okay, dieser Prozess, der funktioniert auch für Modernisierung in Bezug, dass wir halt Anforderungen, Use-Cases, Modelle reverse-ingenieren lassen.

Und dann haben wir die Basis, damit wir das generieren können.

Und aktuell bin ich im Projekt mit einem Kollegen zusammen und wir sind im ersten Self-Contained System, das wir bauen.

Das modernisieren wir genau nach diesem Prozess.

Okay, jetzt habe ich zwei Begriffe, die ich gerade noch klären möchte.

Vaadin habe ich bislang als Frontend-Framework wahrgenommen.

Du sagst jetzt Pull-Stack, kannst du es kurz beschreiben, wo da der Vorteil liegt?

Genau, also mein Stack sieht so aus, ich verwende Vaadin zum Frontend-Entwickeln.

Ich verwende Spring Boot und Spring Security und Datenbankzugriffe mache ich mit Juke.

Das ist kein OR-Mapper, sondern eigentlich eine Fluent API, um SQL zu schreiben, weil ich keine Entitäten brauche in diesem System.

Der Punkt ist, die meisten Applikationen, die ich baue, sind sehr stark datenzentriert mit relativ wenig Business-Logik im Verhältnis zu Datenbankzugriffs-Code.

Vaadin als solches integriert sich in Spring Boot.

Das heisst, ich schreibe meinen UI-Code vollständig in Java und Vaadin hat dann Java-Klassen für alle Komponenten, die Vaadin anbietet.

Vaadin hat ein eigenes Komponentenset, ein eigenes Design-System und das sind alles Standard-Web-Components, die kann man auch ausserhalb von Vaadin verwenden.

Die Vaadin-Architektur sieht dann so aus, dass im Prinzip zur Laufzeit der UI-Code auf der Service-Seite erzeugt wird, also der Komponenten-Baum, nicht der UI-Code.

Dieser Komponenten-Baum wird dann über das Vaadin-Flow-Framework mit dem Browser synchronisiert.

Zur Laufzeit ist eine Vaadin-Applikation eine Single-Page-Applikation wie Angular oder React, mit dem Unterschied, dass ich nicht den JavaScript-Code schreibe, sondern den Java-Code.

Ich hatte es mal ausprobiert, dass ich mit Grails, also auf dem CRUD-Framework, mit der KI arbeiten wollte und ich bin total gescheitert, weil ja, er hat mir zwar Source-Code erzeugt, aber bei Grails ist halt die Besonderheit, ich habe ein CLI-Tool, was mir alles scaffoldet und generiert.

Das scheint jetzt bei Vaadin nicht zu sein, sondern bei Vaadin schreibe ich das Frontend in Java und das Besondere ist, dass die Übersetzung über das Framework nach JavaScript stattfindet und deswegen kann die KI dann wahrscheinlich mit dem, ja, Source-Code-basiert ganz gut arbeiten.

Genau, der Punkt wegen Full-Stack vielleicht noch.

Es ist egal, ob wir Full-Stack Java machen oder Full-Stack JavaScript oder Full-Stack Python oder Full-Stack was auch immer.

Wichtig ist Full-Stack, weil grundsätzlich wir wollen keine Trennung zwischen UI und Backend haben.

Also wir wollen schon eine Trennung rein technisch, aber rein projektmäßig, weil wenn wir uns überlegen, wir möchten gerne eine Software bauen, sei es jetzt, keine Ahnung, irgendeine Verwaltungssoftware für irgendwas, zum Beispiel unsere Büchersammlung oder so, dann sind die Use Cases ja nicht getrennt nach Frontend und Backend, sondern aus Benutzersicht haben wir diese Trennung nicht.

Die Trennung zwischen Frontend und Backend ist ein Reverse Conveys Manöver.

Also das heißt, wir führen Kommunikation ein, wo es keine braucht.

Also der User sieht keine Kommunikation, der weiss, okay, ich habe hier ein UI, da kann ich meine Daten eingeben oder anschauen und dann verrichte ich das und dann wird das hoffentlich abgelegt in der Datenbank, qualitiert, die Business Logik wird ausgeführt, die es da braucht, um meine Prozesse zu steuern.

Aber aus Sicht Anforderungen gibt es diese Trennung nicht.

Und deshalb macht es eigentlich keinen Sinn, die Applikation in zwei Teile zu schneiden und dann das Backend separat zu erzeugen und das Frontend separat zu erzeugen, weil der Use Case beschreibt ja den ganzen Ablauf aus Sicht vom Benutzer.

Also möchten wir das zusammen.

Jetzt könnten wir natürlich auch hingehen und ein Projekt machen mit Angular und Spring Boot, aber dann haben wir zwei Technologie Stacks und die KI und alle Guidelines, die wir haben für die KI, die müssten wir auch für beide Technologien haben.

Und wenn wir Java pur oder JavaScript pur sind, egal welche Seite man wählt, dann haben wir einen Vorteil.

Ich hatte gerade eben gesagt, zwei Begriffe, die ich klären will.

Die Self-Contained Systems, das ist eine Architektur, so wie ich sie verstanden habe, dass ich eben die Applikationen aus nicht Microservices, sondern Säulen aufbaue, die voneinander unabhängig sind.

Und also keine Ahnung, ich habe hier meine Buchverwaltung und ich habe hier meine Nutzerverwaltung und das sind beides Säulen, die halt über Schnittstellen miteinander reden.

Das ist doch auch wieder ein architektonischer Trick, dass du leichter mit der KI arbeiten kannst, weil der Kontext nicht so groß ist, sondern du hast den Kontext auf einer Säule.

Richtig?

Ja, ich hätte es nicht besser erklären können.

Ich denke für KI ist Self-Contained Systems der beste Architekturstil, weil Microservices trennt man Frontend und Backend häufig.

Man hat zwar Microfrontends, aber die sind dann nicht eins zu eins, sondern vielleicht ein zu ein irgendwie miteinander verknüpft.

Und wenn du einen Monolithen machst, auch wenn der modular ist, der wird relativ gross.

Auch wenn die Applikation klein ist, wird der gross.

Und das heisst, der Kontext, der nötig ist oder der die KI dann sieht, der ist zu gross.

Und wenn du es kleiner schneiden kannst, ist der Lösungsraum kleiner und deshalb das Resultat besser.

Das finde ich jetzt aus Architektursicht insofern spannend, weil eigentlich nehme ich ja Qualitätskriterien, treffe damit meine Architekturentscheidung.

Und jetzt hast du quasi das Qualitätskriterium der Entwicklung, der Entwicklungsgeschwindigkeit, sage ich mal, genommen und hast gesagt, komm, dann können wir, wenn wir die KI zur Entwicklung einsetzen wollen, dann nehmen wir eben die Architektur mit Vardien und Self-Contained Systems, weil das der KI entgegenkommt.

Und es passt auf die Art der Anwendungen, die du baust.

Und insofern passt es auch zum Rest der Applikation, richtig?

Genau.

Also beispielsweise, dass die Software, die ich aktuell für einen Kunden modernisiere, das ist ein ERP-System.

Da haben wir fast 1000 Entitäten, also 1000 Datenbanktabellen und das System ist ein grosser Monolith aktuell.

Der ist relativ gut strukturiert, muss man sagen.

Wir lösen den nicht ab, weil der ganz schlecht wäre.

Wir lösen den ab, weil die Technologie, das ist der Eclipse RCP, das dort noch verwendet wird.

Das ist einfach ziemlich end of life, weil wir nicht auf die neuesten Versionen gehen können und so.

Und wir möchten gerne Web-Applikationen haben, dass die Benutzer das von überall verwenden können.

Aber das teilen wir auf, weil einfach das ist einfach jetzt schon zu groß.

Und der Vorteil von Self-Contained Systems, insbesondere wenn du Systeme baust, die viele Stakeholder haben und mehrere Nutzergruppen umfassen, hast du natürlich den Vorteil, dass du die so schneiden kannst, dass eben pro Stakeholdergruppe, sage ich mal, eine Applikation entsteht.

Ein Self-Contained System oder mehrere, die dann auch individuell betrieben werden können.

Und das geht nicht um Skalierung.

Es geht darum, dass wenn jetzt zum Beispiel eine Abteilung gerne Änderungen hätte, dann können wir nur diesen Teil der Applikation deployen und beeinflussen den Rest vom System nicht.

Und eigentlich Self-Contained Systems habe ich schon lange auf dem Schirm.

Also ich bei Modernisierungsprojekten bin ich in der Regel auf diesem Technologie, nicht Technologie, sondern Architekturstil, weil ich den eben praktisch finde, auch für die Modernisierung, so nach dem Strangler Fig Pattern passt das eigentlich auch gut dazu.

Dann hast du deployments, die du nach und nach deployen kannst oder modernisieren kannst.

Und jetzt mit KI ist es Zufall, dass das gerade so gut dazu passt.

Aber das hat wirklich mit der Größe der Komponente oder der Teilapplikation zu tun, die du mit KI entwickeln willst.

Okay, im Chat haben wir jetzt schon die ersten Fragen und eigentlich wollen wir ja gar nicht so in die Wadien Welt abdriften.

Aber hier ist schon die Frage, ob Wadien Open Source ist und wie das mit der Business Logik aussieht, wo die dann liegt.

Ja, also Wadien ist Open Source, das ist Apache 2.

Aber Wadien ist auch eine Firma und die muss irgendwie Geld verdienen, um ihr Framework zu bauen.

Und deshalb gibt es von der Firma erstmal Support.

Also ihr könnt einen Support Vertrag haben, dann habt ihr 15 Jahre Support für Updates vom Framework.

Und auf der anderen Seite gibt es kommerzielle Komponenten, die man vielleicht benutzen könnte.

Also es kommt darauf an.

Bei mir ist es so, meine Kunden, die alle grundsätzlich Wadien verwenden, da würde ich jetzt mal behaupten, wahrscheinlich zwei Drittel, die verwenden die Open Source Version.

Die sind damit zufrieden, das reicht.

Und ein Drittel verwendet die kommerzielle Version, aber nicht unbedingt aufgrund von den Komponenten oder sonstigen Features, die da mitkommen, sondern eher, weil sie halt einen Vertrag wollen mit einer Firma, die Security-Updates und regelmässige Updates bietet, damit sie ein wenig Sicherheit haben.

Es geht eher um das.

Und die Business Logik, die lebt genau gleich wie, also der Unterschied ist einfach, wenn ihr eine Applikation baut mit einer REST-API.

Die REST-API wird einfach durch das Wadien Frontend ersetzt und das heisst, die Business Logik, die lebt in Entitäten, also im Domain Modell mit Services.

Ob ihr da eine Clean Architecture Struktur habt oder eine Layered Architektur, das spielt im Wesentlichen überhaupt keine Rolle.

Wesentlich ist, dass das getrennt ist, dass ihr habt, ihr trennt den UI-Code selbstverständlich vom Business Code und das ist kein Unterschied.

Also REST-API oder Wadien Frontend, das ist im Wesentlichen dasselbe.

Okay, hier haben wir noch eine Frage.

Was ist mit GraalVM?

Die GraalVM habe ich eigentlich schon lange nicht mehr gehört und ich sehe es eigentlich nur als Runtime Environment oder ja, also ist davon unabhängig, oder?

Ja, ja, also man kann sehr gut GraalVM, also grundsätzlich alle Technologien, die ich verwende seit Spring Boot, also vor allem Spring Boot hat dazu zu tun, nicht unbedingt Wadien.

Aber ich kann grundsätzlich die Applikation auch als Native Image bilden.

Das brauche ich aber nicht, weil meine Self-Contained Systems sind ja nicht Serverless.

Also das heißt, die sind nicht, die werden nicht gestartet, sondern die laufen und allem für sich profitieren wir dann bei der Applikation vom JIT-Compiler zur Laufzeit, der natürlich optimiert.

Und das verlieren wir, wenn wir GraalVM machen und deshalb ist eigentlich GraalVM braucht weniger Speicher und ist schneller gestartet, die Applikation.

Schneller gestartet ist bei Geschäftsanwendungen in der Regel kein Thema und Speicherverbrauch kommt darauf an.

Also Speicherverbrauch ist natürlich eine Kostenfrage.

Das ist klar, ob man 10 Mega oder 120 Mega hat und dann wie viele Self-Contained System am Schluss, dass man hat.

Aber wir sind nicht so feingranular wie die Microservices, die vielleicht zu feingranular geschnitten werden und dann plötzlich 100 Microservices entstehen, die alle zusammen viel Speicher brauchen.

So ist es nicht.

Deshalb sehe ich keinen Vorteil mit GraalVM für meine Applikation.

Da hast du jetzt eigentlich schon eine weitere Frage angeschnitten, dass die Microservices ja eigentlich auch abgeschlossen sind und die KI ganz gut damit arbeiten kann.

Aber du hast ja jetzt quasi schon gesagt, es hängt auch ein bisschen von der Größe ab.

Und ich glaube, bei Self-Contained Systems ist die Größe, die ergibt sich natürlicher und bei den Microservices, weil es Micro heißt, versucht jeder so klein wie möglich zu schneiden.

Und was ich auch so gemerkt habe, ist, dass die KI das Umfeld, den Kontext kennen muss von der Säule oder von dem Microservice und es dann quasi davon abhängt, wie gut ich das dokumentiere.

Merkst du das auch so, dass die Dokumentation dann eben eine große Rolle spielt?

Ja, genau.

Also grundsätzlich, mein Prozess sieht ja so aus, als vielleicht nur so als Randbemerkung.

AIUP heißt ja so, weil es mal den Rational Unified Process gibt.

Das erwähne ich nicht so gerne, weil ich habe mich dort inspirieren lassen, aber viele haben nicht so gute Erinnerungen vielleicht an den Rational Unified Process Ende 90er, Anfang 2000er Jahre.

Das liegt aber primär daran, dass dort halt eine Riesenflut an Artefakten und Prozessen da ist und niemand den Prozess customised hat damals.

Aber bei mir beginnt der Prozess eigentlich mit der Projektvision.

Also wir haben grundsätzlich Informationen, was das System machen soll.

Dann gibt es einen Anforderungskatalog, das ist meistens sind da zum Beispiel User Stories drin, die entstehen dann auch unterschiedlich.

Also da sagt der Prozess nichts dazu.

Da könnte man Domain Storytelling oder Event Storming oder irgendeinen anderen TDD Ansatz oder aus dem TDD Umfeld einen Ansatz wählen oder auch ganz klassisch Leute befragen.

Was hat die Requirements Engineers zu tun?

Bei mir beginnt es eigentlich mit der Architektur Dokumentation, wo eben auch abgeleitet werden kann aus den Anforderungen, da kann KI auch helfen.

Das ist aber nicht wirklich Bestandteil.

Bei mir im Prozess steht einfach drin, dass es irgendein Software Architektur Dokument gibt, ob das ARC42 ist oder irgendein anderes Dokumentationsformat, ist nicht so relevant.

Aber diese Informationen, die dort stehen, die geben den Rahmen vor.

Also das heisst, die KI Agenten haben in der Regel ein Guidelines File, bei Glot heisst das Glot-MD, manchmal heisst es Agents-MD, manchmal heisst es Guidelines-MD, sind Markdown-Files.

Und die Dokumentation bei uns, also bei mir im Projekt und bei den Kunden, die liegt vollständig in Markdown, also wir haben alles in Text.

Also wir haben Markdown oder ASCII-Doc, je nachdem, wir haben Plan2ML und Mermaid-Diagramme auch als Text.

Also wir machen keine Bilder, sondern wir machen Text.

Und das ist wichtig, damit die KI das auch versteht.

Genau, das kommt ja der KI auch wieder entgegen.

Mittlerweile kann die KI ja ganz gut Diagramme visuell verstehen, aber das verbraucht mehr Token, als wenn es jetzt die textuelle Beschreibung ist.

Genau, und durch die DSL von Mermaid zum Beispiel, die kann KI sehr gut und KI kann die auch verstehen und wir können sie auch verstehen.

Und IntelliJ oder GitHub oder andere, GitLab oder so, die rendern ja das direkt im Browser und dann sieht der Benutzer zum Beispiel, kann sich dann die Diagramme angucken und muss nicht Mermaid verstehen.

Also von daher haben wir eigentlich beides aus den besten Welten und das Layouting passiert automatisch.

Das heisst, wir verlieren keine Zeit, um Kästchen rumzuschieben und schön zu machen und so.

Das ist halt, wie es ist.

Das ist meistens ein Vorteil.

Jetzt haben wir das Ganze mit Spec-Driven Development überschrieben und du hast jetzt schon Requirements und Use Cases und Storys angesprochen und Architektur.

Ich würde das ganz gern nochmal alles irgendwie zusammenbringen, wie das zusammenspielt, weil wir hatten Peter Ruschka zum Beispiel auch in einer Folge und das war sehr spannend, was Requirements überhaupt sind und der Unterschied zur Spezifikation und eben auch, wie man das Ganze festhält und das finde ich ja jetzt zum Beispiel spannend, dass du eben zum Beispiel sagst, dass User Storys nicht so geeignet sind, dass die Use Cases besser geeignet sind und die Use Cases, ich hatte sie eigentlich schon zur Seite gelegt, weil UML, wer macht schon noch UML und Use Cases, eh nicht, sondern eben Boxes and Lines, ja, und jetzt gräbst du sie wieder aus und sagst, hey, das ist aber für die KI echt prima.

Kannst du die Begriffe mal so in Relation setzen?

Also grundsätzlich habe ich es vorhin erwähnt, wir verwenden auch User Storys, aber in Form von Backlog sozusagen, also das sind die groben Anforderungen und die sagen eher aus, was das System machen soll, also Requirements sind was und System Use Cases sind wie, also wie genau wird das implementiert, wie ist der Ablauf, wie funktioniert das genau und warum, dass ich User Storys nicht so gerne mag, ich mochte die noch nie, muss ich ehrlich gestehen, also das Erste, was mir fehlt, ist ein Überblick und das Use Case Diagramm, das eignet sich sehr gut, um mit dem Kunden zu sprechen, was haben wir für Use Cases im System zum Beispiel, der erkennt die und da gibt es ja zwei Ebenen, es gibt Business Use Cases und System Use Cases und Business Use Cases wären wieder mehr was und die System Use Cases wären wiederum eher wie und zu den Use Cases dazu gehören ja Abläufe, also das heisst wir können auch Aktivitätsdiagramme oder Zustandsdiagramme mit oder Aktivitätsdiagramme, je nachdem was wir halt machen wollen, damit dazu packen, wir können auch UI, Figma Designs zum Beispiel gehören eigentlich auch zum System Use Case, weil die gehören ja zu dieser Einheit und das Problem mit den User Storys ist ein wenig, dass die User Story, die ist ja in der Regel, wer was machen will und was das Resultat sein soll, das ist super, das ist okay, finde ich gut, aber die ganzen Abläufe, Business Regeln und so weiter, die sind in den Akzeptanzkriterien versteckt und häufig in loser Schüttung, also das heisst, aufgrund dessen kann ich mir noch gar nichts vorstellen, was da passiert und auch der Benutzer kann sich da nichts vorstellen, was da passiert, sondern ich kann mit dem Benutzer eigentlich über Anforderungen sprechen, wenn ich sehe, wie ist der Ablauf, was macht der genau, wie geht das weiter und bei uns ist es so, wir haben Business Prozesse, daraus gibt es Anforderungen, die entstehen parallel und daraus gibt es dann pro Business Ablauf zum Beispiel oder Prozess gibt es dann Use Cases, die die Schritte im Business Prozess spezifizieren.

Das heisst, wenn wir es mal konkreter machen, eine User Story wäre ja eigentlich so etwas wie, als User möchte ich mich an der Anwendung anmelden können, sodass ich sie benutzen kann.

Okay, sagt noch nicht viel aus.

Use Case ist für viele, glaube ich, einfach so ein Oval, wo dann drin stehen würde, User Anmeldung, Login, aber jetzt sagst du ja, da ist noch ein Prozess dahinter.

Genau, wie User gibt jetzt nicht Username, Passwort ein, sondern nur seine E-Mail Adresse und er kriegt einen Link zugeschickt, auf den klickt er dann, aber es gibt auch Ausnahme Pfade und solche Geschichten und das macht das Ganze dann so powerful, vor allem in der Kombination mit Diagrams as Code, weil du das dann als Aktivitäten Diagramm hinterlegst und die KI sieht das Aktivitäten Diagramm als Text oder Sequence Diagram und versteht den Text sofort.

Ist das richtig zusammengefasst?

Genau, der Punkt ist, die Use Cases, die sind ja generell von der Struktur her, hast du irgendeinen Header, da steht so drin, wie das Ding heisst, wer die Akteure sind und dann hast du Vorbedingungen, also was muss erfüllt sein, dass diese Use Case gestartet werden kann, also in deinem Fall, wenn der User sich anmelden will, muss die Applikation geöffnet sein, damit er das tun kann und dann haben wir einen Ablauf.

Der User gibt das ein, in deinem Beispiel gibt er zum Beispiel die E-Mail Adresse ein, klickt an einen Link und dann geht es weiter und dann gibt es alternative Abläufe oder Fehlerabläufe und die werden spezifiziert, also zum Beispiel der User wird nicht gefunden, könnte ein Fehler sein, dann wird eine Fehlermeldung angezeigt und dann gibt es Nachbedingungen, das Ergebnis, was soll im guten Fall geschehen, der User soll eingeloggt sein zum Beispiel und diese Beschreibung, unterstützt durch Diagramme, unterstützt durch vielleicht UI Mockups, die helfen sehr gut, der KI das zu tun und zwar nicht nur, um den Code zu generieren, sondern auch, um die Tests zu generieren, weil wenn ich natürlich eine Applikation baue mit einem UI, ist ja der Test mit UI, also ich will ja nicht einen Unitest machen und dann das UI nicht testen, sondern ich möchte eigentlich, dieser Ablauf, der im Use Case Beschreibung drin steht, der wird in einen Test gegossen, die Frage ist nur, auf welcher Ebene wir testen, im Endeffekt ein Akzeptanztest wäre ein End-to-End-Test mit UI Automatisierung, der genau die Schritte macht, die dort im Use Case beschrieben sind und das erlaubt es dann auch, eine Traceability zu haben, das heißt, ich kann dann KI-unterstützt sagen, okay, welche Use Cases sind vollständig implementiert, welche Use Cases sind vollständig getestet und das kann ich dann tun aufgrund dieser Ablaufbeschreibung im Wesentlichen und bei User Stories gibt es keine Ablaufbeschreibung, das ist das Problem.

Also das heißt, wenn ich das nochmal so zusammenfassen darf, die User Stories kann man für einen Backlog benutzen, wenn man dann an das Backlog-Item kommt, dann schreibt man mal die Spezifikationen in Form eines Use Cases mit Ablauf und weiteren Details, was dann implementiert werden kann und zu hoffentlich funktionsfähigen Code führt, das ist verkürzt, das sogenannte.

Und es gibt einen kleinen Nebeneffekt, weil das Problem, das ich heute habe, wenn ich Software modernisiere, ist, dass genau das fehlt.

Und meine Hoffnung ist, dass durch das, dass wir diese Use Cases haben und die so detailliert sind, dass eben Code generiert werden kann, kann ich die behalten und in zehn Jahren, wenn ich sage, okay, Vaadin und Java war jetzt nicht so eine tolle Idee, wir machen doch lieber JavaScript, dann lasse ich mir die Applikation neu generieren.

In zehn Jahren sind wir wahrscheinlich schneller als heute, hoffentlich, aber ich habe alle Informationen dort und ich habe nicht die Informationen im Code, sondern ich habe die Informationen in einer Form, die ich dann in zehn Jahren zum Beispiel dem Benutzer geben kann und sagen, hey, stimmt das noch?

Lies das mal durch.

Ist das noch so, wie du heute arbeiten möchtest oder gibt es Änderungen bei dem Code?

Den kann ich nicht selbst lesen.

Ich habe in meinem Talk diese Vision, momentan iterieren wir auf dem Code und schmeißen immer das Executable weg und du sagst jetzt in zehn Jahren, mein Traum ist, wir iterieren auf der Spezifikation, lassen den Code generieren, schmeißen den aber immer wieder mal weg.

Was du ja jetzt so andeutest, ist, dass das tatsächlich, naja, ab und zu passieren könnte.

Also, dass wenn eine Architekturentscheidung verändert werden muss und Architekturentscheidungen sind ja die, die bislang schwierig zu ändern sind, aber in dem Fall, wenn ich zum Beispiel eine andere Programmiersprache nehme, eine andere Datenbank, irgendwas Großes, eine Architektur ändere, dann hätte ich so eine detaillierte Spec, die es mir ermöglicht, der KI zu sagen, du, iterier mal über die Use Cases.

Vielleicht ist das auch die richtige Reihenfolge, weil so haben wir es zuerst implementiert und die Hoffnung ist, dass da was Gutes rauskommt.

Genau, weil der Punkt ist, es ist die Use Cases, es gibt eine Frage da im Chat von Mark M3623 gesehen, in zehn Jahren sind die Use Cases vielleicht nicht mehr gleich und das Problem bei Software-Modernisierung, man kann Software-Modernisierung nicht, also man kann die automatisieren, das haben wir vorhin gesprochen, ich könnte eine Cobol-Applikation nehmen und daraus eine Java-Applikation generieren.

Der Punkt ist, das will niemand, das generiert ja kein Business-Value und das Problem, das wir heute haben, ist, der Fachbereich kann zum Teil keine Entscheidungen treffen, weil er nicht sieht, wie heute was implementiert ist.

Das ist nur im Code drin, also er muss immer den Entwickler haben und der Entwickler weiß das vielleicht auch nicht, also heute mit KI, Reverse Engineering und Diagramme generieren von Abläufen, das ist super, das ist wirklich super gut.

Früher musste man relativ teure Werkzeuge verwenden.

Ich habe da Werkzeuge immer noch in meinem Werkzeugkasten, die das können, aber die kosten einige Tausend Euro zum Teil, um Reverse Engineering zu betreiben, aber der Benutzer möchte ja gerne oder der Fachbereich möchte gerne eine Entscheidung treffen, der möchte wissen, wie sieht das aus ablauftechnisch, was machen wir heute, wie können wir das anpassen und das fehlt, dass wir haben heute eine extreme Blackbox zwischen ursprünglichen Anforderungen und Code, der implementiert ist und für den Fachbereich ist das praktisch unmöglich herauszufinden, was heute geändert werden müsste, das geht nicht und deshalb finde ich, die Wahrheit liegt im Code, stimmt, weil das ist das, was ausgeführt wird, aber das ist kein guter Zustand.

Jetzt hatten wir vorab schon in der Ankündigung eine Frage so nach dem Motto Spec-Driven Development.

Arbeitet ihr bislang ohne Specs?

Das fand ich eine spannende Frage, weil ich habe auch das Gefühl, es kommt ein bisschen auf die Branche drauf an.

Wie ist da deine Erfahrung?

Also meine Erfahrung ist, die meisten Leute oder die meisten Firmen, die ich kenne, die verwenden Confluence und Jira und die machen mal Vorabklärung und schreiben die ins Confluence oder in ein anderes Wiki, das spielt keine Rolle, was für ein Produkt es ist.

Dann sind da Grobanforderungen drin, das ist Zustand zum Zeitpunkt X.

Dann werden aus diesen Anforderungen irgendwie Jira-Tickets gemacht oder andere Tasks in irgendeinem Backlog-System, egal was das ist.

Und dann haben wir häufig ein Scrum-Prozess, was ein Refrainment gibt, da wird man dann Zusatzinformationen anreichern, man wird vielleicht wieder zurückgehen und Fachbereiche fragen, was dazu packen und dann kommt das Ganze ins Planning rein.

Dort werden dann Tasks erzeugt für den Sprint.

Und jetzt muss man sich vorstellen, überall in all diesen Schritten, die ich jetzt gerade gesagt habe, sind Fachinformationen drin, aber nicht in einer strukturierten Form.

Und ganz viele Fachinformationen, die entstehen bei einem Workshop zum Beispiel, die werden einfach nicht dokumentiert, sondern die sind in den Köpfen drin, weil der Entwickler, der das programmieren muss, der sieht, okay, ich weiss, was ich machen muss, ich mache das jetzt mal.

Und zu guter Letzt haben wir folgende Situation.

Wir haben einen Code, der was implementiert.

Wir haben Tests, die irgend aufgrund einer Basis testen und wir haben Dokumentationen, die man eigentlich besser löschen würde komplett, weil falsche Dokumentation ist schlechter als keine Dokumentation, weil sie falsche Annahmen über das System zum Beispiel hervorruft.

Und das ist die Ist-Situation.

Wir haben nicht wirklich eine Spezifikation, sondern wir haben eher einfach diverse Informationen über System irgendwo verstreut in verschiedenen Orten.

Und mit KI gehen wir dazu über, also jetzt konkret im Kundenprojekt.

Alles ist Markdown, habe ich bereits gesagt, das heisst auch die Product Owner, die arbeiten mit IntelliJ bei uns mittlerweile, mit Git.

Also die machen Versionsverwaltung, die führen die Use Cases selber nach.

Und deshalb haben wir eine Single Source of Truth, das ist der System Use Case primär und das Domain Modell natürlich dazu mit Beschreibung der Entitäten zum Beispiel und Funktionen, Business Regeln, Validierungsregeln, was dazu gehört.

Aber das gehört alles zur Applikation und wir brauchen Confluence nur so für andere Sachen und Jira Tickets brauchen wir immer noch, aber das sind mehr Platzhalter, damit die Leute was haben, um sich daran festzuhalten.

Aber da steht nichts drin.

Also ich muss dem zustimmen, weil ich kenne es auch meistens so, dass man über Jira arbeitet und dann so eine Kette an Issues erstellt und würde man daraus ein Speck generieren wollen, muss man erst mal gucken, wo ist alles jetzt die Komponente, in welcher Reihenfolge wie geändert worden, um eine Spezifikation zu erlangen.

Ich kenne aber auch Bereiche, wo es wirklich kritisch ist.

Ich kenne es aus dem Automotive Bereich, in dem ich zum Glück noch nie gearbeitet habe.

Aber da ist eine Traceability und solche Geschichten ganz wichtig.

Und da wird wahrscheinlich komplett anders gearbeitet.

Ja, definitiv.

Also das, was ich jetzt beschrieben habe, das ist das Standardvorgehen.

Also ich vielleicht von der Branche her, weil ich arbeite häufig für Großhandel, Detailhandel.

Ich habe auch für Bahnunternehmungen gearbeitet in der Schweiz für eine ganz lange und dort kommt es auf den Typ drauf an, aber die klassischen Geschäftsanwendungen, die entstehen meistens so.

Natürlich in anderen Branchen ist es anders.

Ich arbeite auch, habe auch Kunden in der Industrie, wo es Abnahmen gibt für die Maschinensteuerung oder so.

Dort muss alles ganz klar spezifiziert werden.

Aber das ist ein bisschen ein anderer Ansatz.

Aber ich spreche jetzt primär so über reguläre, wenn man dem so sagen kann, Geschäftsanwendungen.

Jetzt haben wir hier in dem Chat das Feedback.

Mensch, das ist doch eigentlich alles Wasserfall.

Wir wollen doch agil arbeiten und du sagst jetzt, wir brauchen ab Fronti die Speck und mit dieser Speck lassen wir das implementieren.

Arbeitest du agil oder?

Natürlich, das ist voll agil.

Das ist richtig agil.

Also wir arbeiten jetzt richtig agil.

Wieder mal.

Also vielleicht muss ich meine Agilität definieren.

Was ich nicht agil finde, ist Safe und Scrum, sondern das sind Prozessmodelle, die einen Rahmen geben, wie man arbeitet.

Das hat nichts mit Agilität zu tun im Kern, weil ich kann auch wasserfallmässig Scrum machen.

Mein Prozess ist insofern agil, dass wir also grundsätzlich, bevor man mit irgendwas beginnt, irgendeinem Bereich, z.B. einem Bounded Context, muss man ja schon ungefähr wissen, was man will.

Also das wäre ja die, was wollen wir machen?

Das ist die Anforderungsebene und diesen Prozess gibt es sowieso.

Da gibt es Business Analysten, Requirements, Ingenieurs, die sich überlegen, wie können wir das machen?

Der Produktowner ist dabei, vielleicht sind Entwickler dabei, wenn es technische Fragen gibt oder Architekten, wenn es Architekturthemen gibt.

Vielleicht ist sogar die Plattform dabei.

Das ist Vorarbeit.

Das hast du egal, ob du das agil machst oder nicht.

Dann kommen wir zu den Spezifikationen und die sind insofern agil, dass man nicht alle Use Cases aufs Mal beschreibt, sondern was wir machen, wir extrahieren aus den Requirements die Use Cases und dann haben wir aber nur das Use Case Diagramm.

Dann wissen wir grundsätzlich, was wir machen wollen, also welche Aktionen oder welche Funktionen hat im System und dann überlegen wir, in welcher Reihenfolge müssen die gemacht werden.

Also wir, vor allem der Produktowner natürlich und dann wird Use Case für Use Case spezifiziert und das Spezifizieren des Use Cases ist Bestandteil der Implementation eigentlich.

Beziehungsweise, wenn ich das jetzt auch noch mal so interpretieren darf, ihr macht ja nicht die komplette Applikation vorneweg, dass die komplett spezifiziert ist, sondern ihr macht ja wahrscheinlich erst mal einen Durchstich, dass irgendwie, keine Ahnung, ein Self-Contained, eine Säule erstellt wird, die dann getestet wird und man guckt, wie das funktioniert und ändert es entsprechend ab und geht weiter auf die nächste Säule und somit kommt ja dann das Agile wieder rein, richtig?

Genau, es ist alles iterativ, also grundsätzlich ist der ganze Prozess iterativ inkrementell, wie das der Unified Process im Übrigen auch war.

Das heisst, wir machen dauernd alles, also wir haben dauernd alle Disziplinen.

Der Unterschied ist einfach, dass der Code nicht von Hand geschrieben wird, sondern der wird generiert und die Tests werden generiert, also wird gereviewt, weil wir haben ja ein kleines Problem und das ist, dass KI nicht deterministisch ist.

Das heisst, das ist ganz wichtig, weil, als ich begonnen habe, meinen Prozess vorzustellen, haben gewisse Leute gesagt, ja, das hatten wir doch schon mal, das ist Model-Driven.

Und dann habe ich gesagt, nein, das ist ein grosser Unterschied, weil Model-Driven ging so weit, dass wir eine DSL hatten, zum Beispiel, oder UML, das das System beschrieben hat, und wir konnten das dauernd neu generieren, wir konnten den Output löschen, wie wenn ihr Java programmiert, könnt ihr alle Class-Files löschen, die braucht ihr nicht, die könnt ihr jederzeit wieder generieren.

Aktuell ist KI nicht so weit, dass das jedes Mal neu generiert werden kann.

Das heisst, wenn wir Anpassungen machen am Use-Case, als Beispiel, dann sagen wir, zum Beispiel Cloud Code, bitte appliziere die Änderungen an Code und Test.

Und das kann KI, weil er ja den Diff anschauen kann.

Also was hat jetzt geändert in diesem Use-Case und aufgrund der Änderungen kann er dann die Abläufe, die Business-Regeln zum Beispiel, wenn es irgendeine Regeln ändert, könnte die Business-Logik ändern oder das UI könnte ändern, es gibt ein neues Feld dazu oder es kommt ein Zweck, es kommt ein neues Datenbank-Feld dazu und dort macht im Prinzip KI nur die Änderungen, also wir generieren nicht neu.

Es kommt ein bisschen darauf an, was genau gemacht wird, wenn man jetzt irgendeine REST-API machen würde und die hätte starke Änderungen, dann löschen wir die und dann generieren wir das neu.

Das kommt ein wenig darauf an, was wir machen, aber wenn wir natürlich relativ viel Code haben, also ein Use-Case, das relativ viele Funktionalitäten umfasst, dann ist das eine applizierende Änderung, eine Anpassung an Code und nicht eine Neugenerierung.

Und dort ist auch die Geschwindigkeit ein Problem, weil wenn die Applikation ein wenig grösser wird oder das Self-Contained System, dann würde das auch zu lange dauern, das zu generieren.

Aber das ist eine Frage der Zeit, also was wichtig ist, keine getriebene Softwareentwicklung ist aktuell so Kindergarten, Erste-Klasse-Niveau, da ist noch viel Luft nach oben, das kann man noch viel besser machen, viel stärker verbessern, optimieren, da sind wir am Ausprobieren und das Ganze sind Experimente, also der Punkt ist ja auch, die Tools entwickeln sich weiter, die Resultate, die ich gekriegt habe vor einem Jahr, unterscheiden sich von dem, was ich heute kriege.

Wenn du sagst, dass die KI ja einen Diff machen kann, dass sie sieht, was sich an dem Use-Case geändert hat, benutzt du Feature-Branches, dass du jedes Feature eben in einem eigenen Branche entwickelst und die KI dann eben leicht den Diff machen kann und eben auch sagen kann, guck mal, das ist jetzt das und du kannst notfalls sagen, das hat gar nicht geklappt?

Ja, es kommt darauf an, wie ich arbeite.

Es kommt darauf an, was ich genau tue, aber ich würde jetzt mal sagen, in der Regel gibt es einen Branch, wenn zum Beispiel der Product-Owner dann künftig die Anpassungen selber machen könnte, also der kann die Änderungen machen, dann würde der Product-Owner bereits den Branch erstellen und sagen, okay, das sind die Änderungen, ich habe den Use-Case angepasst und dann könnte theoretisch KI auf GitHub zum Beispiel laufen oder auf einer anderen Plattform und das dann automatisch generieren und gleich ein Pull-Request erzeugen.

Wenn wir lokal arbeiten, kommt es darauf an, wie wir im Team organisiert sind.

Aktuell sind wir im Team, wo wir eigentlich die, wir machen die Auftragserfassung neu, sozusagen das Kernsystem.

Dort sind wir zu zweit, plus noch ein paar Cloud-Codes dazu und dort machen wir gar keinen Branch, sondern wir machen die Änderungen und wir kriegen die Änderungen, wir applizieren die selber, weil wir im Moment Reverse-Engineering machen und dann lassen wir das laufen.

Im Moment lokal könnten wir aber auch irgendwas sonst machen und dann sind wir Trunk-Based unterwegs, also gibt es keine Branches.

Wir haben hier noch eine sehr spannende Frage.

Benutzt du vorgefertigte Agents, zum Beispiel für Planung, Dev-Testing oder hast du verschiedene Rollen?

Mein Prozess ist für meinen Stack mit Vaadin und Ju, gibt es ein Marketplace mit einem Plugin für Cloud-Code und dort gibt es Commands, Skills und ich habe, ich verwende in der Regel vier MCP-Server, einer ist Playwright, weil den brauche ich, damit ich den Browser fernsteuern kann und Kai sieht, wie die Applikation aussieht.

Dann verwende ich Vaadin, hat einen super MCP-Server, dann habe ich zwei selber gemacht, einen für Ju und einen für Karibu Testing, wo ich im Prinzip mehr oder weniger die Dokumentation vom Testing-Framework und von Ju in eine Vektordatenbank abgelegt habe und dann eine vektorisierte Suche machen kann über MCP in der Dokumentation und das hilft sehr stark.

Das heisst, die Werkzeuge erlauben sehr viel.

Wir sind da noch am Experimentieren, weil das entsteht ein wenig.

Also wenn ich für mich alleine arbeite, ist es anders, als wenn ich im Team arbeite, ein wenig.

Und wir sind im Moment, es gibt von der Requirements-Engineering-Gruppe, die da die Zertifizierung anbietet, gibt es eine Beta-Micro-Credential-Zertifizierung, die heisst AI for Requirements-Engineering und die haben begonnen zu überlegen, wie können Prompts aussehen oder Skills aussehen für das Requirements-Engineering und ich überlege mir laufend oder wir überlegen uns im Team auch, wie können wir Kai besser steuern.

Skills ist ein sehr guter Weg, denke ich, weil Skills mehr oder weniger fast standardisiert sind.

Also das unterstützt mittlerweile fast jedes Tool.

MCPs haben ein wenig einen Nachteil, weil wenn die viele Tools haben, ist relativ viel Kontext schon weg.

Das hat Cloud Code, ist daran, das besser zu machen.

Die laden die MCP-Tools erst, wenn sie es brauchen und nicht von vorne weg.

Neuerdings, da gibt es verschiedene Techniken, da gibt es auch ganz viele Leute, die sich dieses Thema kümmern, wie man das verbessern könnte.

Aber ich denke, Skills helfen sehr, sehr stark.

Ja, ich habe noch immer so ein bisschen, es gibt ja so viele Ansätze und bei Skills und MCP, ja habe ich, also du hast recht, der MCP kann schnell den Kontext voll machen und beim Skill habe ich dann so dieses, ich beschreibe kurz, was der Skill macht und erst, wenn er den braucht, holt er sich die längere Beschreibung.

Das ist ja ähnlich, wie jetzt manche Leute sagen, wir benutzen keine MCPs mehr, sondern wir benutzen CLI-Tools und wenn das LLM das Tool benutzen will, dann ruft es halt mal das CLI-Tool mit “-help!” auf und hat die Beschreibung.

Das spart den Kontext.

Okay, Skills sind spannend.

Was mir noch aufgefallen ist, ich habe jetzt so den Eindruck, dass deine Anwendungen hauptsächlich interne Anwendungen sind und dass dadurch das UI-Design, das hast du bislang nicht erwähnt, geht das so ein bisschen in den Hintergrund?

Nein, überhaupt nicht.

Also das ist wesentlich.

Grundsätzlich das, mit dem ich schon ein Jahr unterwegs bin, das ist eine öffentliche Anwendung.

Die will ich verkaufen, wenn die Beta-Phase durch ist.

Die ist öffentlich und das UI-Design ist natürlich so, dass das KI auch sehr gut kann.

Bei internen Applikationen, jetzt konkret bei der ERP-Modernisierung, wo ich gerade beim Kunden bin, dort haben wir ein Design-System entwickelt.

Das heisst, grundsätzlich ist der Rahmen gegeben.

Welche UI-Elemente haben wir?

Wie sieht das UI aus?

Und dieses Design-System, das ist auch beschrieben und auf das kann KI zurückgreifen.

Dann weiss er, in welchem Kontext er welche UI-Elemente verwenden muss und dadurch gibt es einen extrem starren Rahmen wiederum.

Also die Varianz, wie das UI aussehen kann, ist relativ klein.

Das heisst, bei einfachen Use Cases müssen wir nicht mal ein Design vom UI machen, sondern es reicht im Prinzip, wenn wir mit dem Fachbereich abstimmen, in welcher Reihenfolge die Felder stehen müssen.

Haben wir eine Tabelle, haben wir Cards, haben wir andere Elemente, um die Daten zu visualisieren und das reicht, weil die Elemente sind gegeben.

Wir haben Java-Klassen, eigene für alle UI-Elemente, die wir verwenden dürfen.

Und das ist auch der Vorteil im Übrigen von Vaadin, respektive nicht von Vaadin, sondern von Web-Components, weil wenn ich jetzt die Applikation so Tailwind-mässig mit ganz vielen Divs in HTML machen würde, dann habe ich ein Problem, weil dann habe ich keine Komponente.

Aber jetzt nehmen wir mal Vaadin, er hat eine Grid-Komponente und diese Komponente kann alles, sie kann Lazy-Loading, sie kann sortieren, sie kann filtern, sie kann man verwenden, um einen Grid-Inline-Editor zu bauen, man kann Spalten ausblenden, Spalten sortieren und so weiter und so fort.

Und diese Komponente ist so reich an Funktionalität, dass ich dort gar nicht selber implementieren muss.

Das heißt, wir versuchen auch im Projekt jetzt so höherwertige Komponenten zu schaffen, ganz viele, die passen zu unserer Domäne und KI dann instruieren, schau, das sind Komponenten, die kannst du wählen, du musst nichts selber erfinden.

Und das ist UI-Komponenten- mässig ein Riesenvorteil.

Wie kriegt die KI dann die Beschreibung der Komponenten?

Ist das eine textuelle Beschreibung oder ist es eine…

Im Moment schon, ja.

Im Moment leben die Komponenten in Confluence, also die Beschreibung, die Dokumentation liegt in Confluence.

Ich muss mir das noch genau überlegen, aber grundsätzlich eine textuelle Beschreibung reicht.

Ich könnte auch ein MC-Preserver machen mit Tools, wo KI fragen könnte, welche Komponente verwende ich, um sowas zu visualisieren und dann würde die Komponente zurückgeben.

Das wäre auch noch cool, aber da haben wir einfach im Moment keine Zeit und das ist nicht so viel besser, als es jetzt ist, würde ich mal sagen.

Okay, jetzt haben wir die ganze Zeit über deinen Ansatz gesprochen und es gibt ja noch viele andere Ansätze, was gerade so modern ist.

Höre ich Gastown oder was wir schon länger haben ist Cloudflow.

Hier haben wir noch die Frage nach BMAT oder BMAD.

Sagt dir das was, dieser Ansatz?

Ja, die kenne ich.

Es gibt ja verschiedene Speck-Driven-Frameworks.

BMAD ist einer davon.

Also das ist eine Idee, wie man Spezifikation macht.

Ist ähnlich wie mein Prozess, nur eben anders.

Dann gibt’s Speckkit von GitHub oder Kiro von Amazon.

Ich werde am 22., glaube ich, ist das ja in fast einer Woche am Donnerstag, bin ich zusammen mit Ricardo von Amazon und er wird einen Workshop machen über Amazon Kiro, wie man es verwenden kann mit Python und ich werde dort ein wenig mit dabei sein.

Der Punkt ist, diese Tools sind mir zu entwicklerlastig, weil in meinem Prozess drin, der ist gesamtheitlich gedacht.

Also Wachbereitsleute vertreten durch den PO, Architekten, Tester, die gehören alle dazu.

Und die Spezifikation, also ich habe auch einen Blogpost darüber geschrieben und dort sage ich eigentlich, das was heute von Tools wie Speckkit oder Kiro gemacht wird, ist für mich nicht unbedingt Speck-Driven, sondern den würde ich schon fast eher Task-Driven sagen.

Weil bei mir ist es so, ich mache Newsguides und der ist detailliert genug, damit mit dem Rahmen des Frameworks, mit dem Rahmen der Architektur, mit dem Rahmen der Domäne zum Beispiel, kann ich dann Applikationen erzeugen.

Speckkit oder Kiro gehen einen anderen Weg.

Die machen zuerst einen Plan und aus diesem Plan werden dann Tasks abgeleitet und KI implementiert dann diese Tasks.

Also wir sind eine Ebene weit drunten.

Also das wäre, wenn ich nach dem System-Newsguides noch hingehen würde und KI sagen würde, wie er jetzt diese Newsguides zu implementieren hat.

Und das braucht mein Prozess nicht.

Aber das liegt daran, dass die Art und oder die Art der Applikation, die ich damit erzeugen kann, eben diese sogenannten Geschäftsanwendungen sind.

Und die sind schon von der Anatomie her klar, wie man die baut.

Eigentlich sind die immer ähnlich und das ist ein grosser Vorteil.

Und ich mag die anderen Tools nicht.

Die geben mir auch einen zu starken Rahmen.

Ich arbeite auch nicht in der Idee, also in der Idee mache ich Reviews, in der Idee schreibe ich die Spezifikationen oder validiere die Spezifikation besser gesagt, weil die schreibt ja meistens jemand vom Fachbereich und dann schaue ich mir das dort an.

Aber meine Agenten, die laufen in der Kommandozeile.

Also ich will keine Integration mit KI, die laufen auch auf GitHub in vielen Projekten, weil ich die autonom laufen lassen will.

Also ich will denen nicht zugucken, was die so machen.

Und deshalb brauche ich da keine ID-Integration und die Tools, die heute gebaut werden, die sind viel zu stark entwicklerlastig und zielen nicht auf den gesamten Software- Entwicklungsprozess.

Das finde ich falsch aktuell.

Okay, ich habe jetzt auch das Gefühl, dass dein Ansatz relativ technologieunabhängig ist.

Ich brauche eine Architektur, die für die KI sehr geeignet ist, dass der Kontext nicht zu groß wird, dass sie gut damit arbeiten kann.

Aber ich brauche jetzt nicht irgendwelche spezialisierten Prompts oder in dem Dreh, sondern ich kann der KI einfach sagen, da ist der Use Case und mach mal was draus.

Genau.

Und ich mache Schulungen zu meinem Prozess, meistens mit Java, weil ich halt Java Entwickler bin und das am besten kenne.

Aber ich habe auch einen Kunden, der hat mir gesagt, Java kennen wir nicht, wir kennen JavaScript, das könntest du anbieten.

Und dann bin ich halt hingegangen und es gibt so ein Fullstack, keine Ahnung, man kann es nicht mit Spring Boot vergleichen, aber das ist so eine Idee, dass ich eine CLI habe und ein Projekt machen kann und das verwendet React, Next.js für Backend, dann verwendet es Prisma für den Datenbank Zugriff.

Das stellt auch Docker-Container für die Datenbank zur Verfügung, ähnlich wie das Spring auch machen kann.

Und da habe ich eine CLI und da kann ich ein Projekt erzeugen und das gibt mir einen vollständigen Rahmen.

Das braucht auch tRPC, das ist ein TypeScript Remote Protocol und nicht Restschnittstellen.

Und das heisst T3, also T3 Stack heisst das Ding, wenn ihr das anschauen wollt und das passt für mich auch sehr gut.

Also das heisst, ich kann ein wenig JavaScript, mindestens kann ich den Code verstehen und ich weiss auch wie React ungefähr funktioniert und mit dem habe ich auch gute Ergebnisse gemacht.

Das habe ich produktiv nie richtig verwendet, aber in Kursen verwende ich das auch und das geht gut.

Wie gesagt, bei uns in der Schweiz ist der Stack meistens Angular mit Spring Boot, das ist so bei grösseren Firmen oder im Bundesumfeld der Default Stack und das würde auch funktionieren.

Grundsätzlich, das ist auch nicht so, aber dann würde ich wirklich versuchen, den Rahmen vor allem im Frontend sehr stark abzustecken, weil dort ist die Variante sonst zu groß und auch nicht übersichtlich, zu guter Letzt.

Dein Ansatz ist gut verständlich, wenn man Greenfield arbeitet, wenn ich von vorne anfange, wenn ich jetzt aber schon eine Anwendung habe, die eben nicht Greenfield ist, sondern auch eben vielleicht nicht Vaadin und nicht Self-Contained Systems.

Hast du da noch irgendwelche Tipps oder ist das so, dass du mittlerweile sagst, es ist schwierig mit KI anzugehen, deswegen ist das nicht dein Turf?

Nein, ich mache sehr viele Reviews für Kunden und ich verwende dort immer KI zur Bewertung der Architektur, Bewertung des Codes, Bewertung der ganzen Geschichte und was man natürlich machen kann ist, und das ist natürlich aufwendig, man kann natürlich das Reverse-Engineeren, also man könnte einen Bereich nehmen, einen Use Case zum Beispiel nehmen und den Reverse-Engineeren, um zu schauen, was da rauskommt, ob das überhaupt noch stimmt.

Und dann könnte man ab da weiterfahren.

Das wäre natürlich eine Möglichkeit grundsätzlich, weil grundsätzlich muss man den Kontext irgendwie herstellen.

Man muss zum Beispiel der KI auch Informationen über die Domäne geben, also was für Aggregate oder Entitäten haben wir im System zum Beispiel.

Das ist wichtig, damit entsprechend gearbeitet werden kann.

Und KI könnte man natürlich auch verwenden, um die Diagramme zu generieren.

Ich habe es vorher gesagt, ich habe Tools, die sehr teuer sind, um eben solche Reverse-Engineering-Sachen zu machen.

KI macht das gratis.

Die Frage ist halt, stimmt das, was es dann rauskommt oder ist es nicht richtig, weil es ja KI ist und eben nicht ein Werkzeug, das nach einem Algorithmus vorgeht und das analysiert.

Das kommt ein wenig darauf an, aber die Resultate sind eigentlich sehr gut.

Also Code-Verständnis ist viel einfacher als früher, eben insbesondere bei Modernisierungsprojekten hilft es sehr stark herauszufinden, was macht das heute.

Und dann sieht man eben auch, dass die Wahrheit im Code nicht eine gute Idee ist, weil grundsätzlich ist es so, dass bei Legacy-Systemen, die über eine Zeit lang laufen, gibt es immer wieder Wechsel im Team.

Manche verstehen es nicht ganz und dann entsteht dem sage ich Balkon-Architektur, weil der Entwickler, der getraut sich nicht, den gesamten Ablauf zu ändern, sondern er baut dann so Balkone an der Logik an und das sieht man dann sehr gut, wenn man sagt Okay, schau mal diese Business-Methode, mach mir ein Sequenz-Diagramm, was da genau aufgerufen wird.

Und da sieht man dann dreimal denselben If drin mit derselben Abfrage, weil eben sich niemand getraut hat, den Ablauf komplett umzubauen.

Jetzt hast du mehrfach gesagt, dass die KI ja nicht deterministisch ist.

Ja, ich sage immer, die KI erzeugt mir in fünf Minuten Code, für den ich fünf Stunden zum Review brauche und während ich das Review mache, läuft die KI weiter und erzeugt neuen Code.

Wie kriegst du das unter Kontrolle?

Der Punkt ist wiederum der Stack.

Ich kenne meinen Stack natürlich in- und auswendig, wie das zu funktionieren hat.

Ich bin Experte in allen Werkzeugen oder allen Libraries, die ich verwende und das heißt, wenn der Code generiert wird, kann ich praktisch nur draufschauen und sehe sofort, ob es passt oder nicht.

Wenn ich natürlich Business-Logik habe oder Logik habe, vielleicht noch zum Thema, wenn die Zeit noch bleibt, Test-Driven-Development, ja oder nein, ist eine gute Frage in diesem Zusammenhang.

Wenn ich UI mache, mache ich nicht Test-Driven-Development, weil es funktioniert nicht, weil das UI entsteht und bis ich weiss, welche Selektoren ich habe, wie das UI aussieht, wie ich das UI testen kann, dann geht es eine Weile.

Das kann man schlecht Test-Getrieben machen.

Vaadin nur noch hat einen riesen Vorteil.

Ich kann Integrations-Tests auf UI-Ebene machen, indem ich nur den Java-Code teste und das, was im Browser abläuft, macht Vaadin selber, das ist nicht mein Thema.

Deshalb kann ich dort komplett von UI bis zur Datenbank alles testen.

Dem sagt man Browser-Less-Testing und das ist wie Mock-MVC, wenn ich Rechnungsstellen baue, zum Beispiel müsste ich auch kein Spring-Boot, kein Tomcat starten, zum Beispiel für die Tests und das beschleunigt.

Meine Applikation hat ungefähr 1400 solcher UI-Tests und die laufen in knapp einer Minute durch.

Wenn wir natürlich End-to-End-Tests machen, das geht viel länger, weil ein End-to-End-Test läuft dann 2-3 Sekunden und wenn ich so viele hätte, dann würde das ewig dauern, bis das durch ist.

Wenn ich aber Business-Logik habe, also richtige Logik, irgendeine Berechnung oder sowas, dann würde ich einen Test-Getriebenen-Ansatz machen, also diesen Teil vielleicht aus dem Use-Case extrahieren und dann tatsächlich das Interface definieren und dann sagen, okay, schreibt mir die Tests, die passend zum Use-Case sind, also Unit-Tests und dann implementiere ich mir, basierend auf diesen Tests, den Code.

Dann habe ich einen Test-Getriebenen-Ansatz.

Aber bei datenlastigen Applikationen stimmt die Test-Pyramide sowieso nicht, da hat man eher diesen Test-Pokal, davon kennt sie DOTS, wo man eben viele Integrations-Tests hat und relativ wenige Unit-Tests.

Wir werden auf jeden Fall deinen Blog und deine Website zu dem Prozess noch mal verlinken in den Show Notes, weil ich glaube, da kann man jetzt mit diesem Einstieg von heute noch ziemlich viel weiter reingehen, tiefer gehen.

Wir haben eine letzte Frage, wie man bei Claude in einem bestehenden Projekt das MD-File generieren kann.

Ich glaube, das ist einfach Slash-Init, oder?

Slash-Init und Claude erzeugt das für sich.

Slash-Init erzeugt das Claude-MD und man kann Slash-Init auch immer wieder aufrufen, wenn man zum Beispiel neue Leibnisse hinzufügt oder eine wegnimmt, dann kann man das hinzufügen.

Und dieses Claude-MD, wenn man ähnlich gelagerte Projekte hat, dann würde ich das auch teilen.

Also wenn wir mehrere Self-Contained System haben mit dem selben Technologie-Stack, dann bräuchten wir auch dasselbe.

Genau, da steht ja hauptsächlich sowas drin, wie ist die Folder-Struktur, aber eben auch was der Technologie-Stack und wie rufe ich Test-Tool auf und solche Geschichten.

Daher ist das bei gleicher Architektur leicht zu teilen.

Genau.

Sehr gut, Simon, herzlichen Dank.

Es war spannend, es hat mir tiefe Einblicke gegeben und ich weiß auf jeden Fall, wie ich jetzt meine Software-Entwicklung verändern werde.

Ich glaube, viele der Zuschauer denken ähnlich.

Herzlichen Dank.

Vielen Dank und als Schlusswort von mir.

Lasst euch nicht frustrieren.

KI-Agenten sind ein neues Werkzeug, das müsst ihr zuerst lernen.

Ich spreche ja ab und zu mit Leuten, die sagen mir, ich habe es ausprobiert, es hat nicht funktioniert und ich frage dann ja, wie lange hast du es probiert?

Und dann ist die Antwort häufig, ja, gestern Nachmittag.

Dann sage ich, ja, vielleicht ein wenig kurz.

Und überlegt euch, was macht ihr falsch, lest andere Blogs, schaut euch Videos an, wie andere damit umgehen.

Da lernt man viel.

Ich musste auch zuerst lernen, wie man damit umgeht.

Was muss ich machen, wenn das Resultat nicht so ist, wie ich das erwartet hätte?

Wie kann ich das verbessern?

Und der Agent ist eher ein Team-Mitglied als ein Werkzeug.

Er ist ein Werkzeug, er ist nicht das ist kein Team-Mitglied, der lernt nichts, der vergisst alles.

Aber von der Art und Weise von der Zusammenarbeit ist es ähnlich, weil ich gebe einen Auftrag und bekomme ein Resultat und dann muss ich entscheiden, ist das Resultat das, was ich wollte oder nicht?

Und dann geht es von vorne los.

Und das wäre ja auch dasselbe, wenn ihr mit einem anderen Team zusammenarbeiten würdet, mit Juniorentwicklern oder so, dann habt ihr denselben Effekt.

Und das ist wichtig.

Also ihr könnt nicht erwarten, dass der erste Wurf gleich super Resultat sein könnte.

Es könnte auch sein, dass einmal ein Resultat super ist, einmal nicht mehr.

Bitte nicht sich frustrieren lassen, sondern bleibt dran, probiert es aus und dann macht es irgendwann auch Spaß.

Lifelong Learning.

Dank für dieses Schlusswort und bis zum nächsten Mal.