Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und unterhalte mich heute mit Matthias Zacks. Er ist Testautomatisierer und zeigt uns, wie er in seinem Kontext KI, insbesondere die generative KI, einsetzt. Viel Spaß bei der Folge. Hallo Matthias, schön, dass du da bist. Hallo Ritschi, es ist schön da zu sein. Ja, wir haben es ja ein paar mal verschoben jetzt. Es hat ein
bisschen gedauert, bis wir hier zusammengekommen sind, aber jetzt haben wir es geschafft. Gute Dinge brauchen ein bisschen Zeit. So ist es, darum wird die Folge jetzt umso schöner. Du wurdest mir ja empfohlen vom Rudi Kreutz, der ja auch schon hier im Podcast war, hat gesagt, du musst mit dir mal mit Matthias unterhalten. Und dann bei der letzten OOP standest du auf einmal auch vor mir in voller Pracht. Und ja, da haben wir uns auch kurz unterhalten und dann auch im
Vorgespräch gesagt, komm, das wird eine klasse Folge, das machen wir jetzt. So, jetzt haben wir... Dein Stand war so präsent auf der OOP, da konnte ich nicht vorbeigehen. Das ist richtig, das ist auch wichtig. Da sollen ja ein paar Leute vorbeikommen. So ist es. Ja, und genau, jetzt haben wir eine ordentliche Erwartungshaltung auch geschürt, die musst du jetzt natürlich erfüllen. Und ja, du hast ja ein bisschen Erfahrung, die ihr mit GNI im Testing
Umfeld auch gesammelt, beziehungsweise auch generell. Und das ist natürlich ein Thema, was auch die Community interessiert. Das kriege ich immer beim Feedback mit. Und deswegen würde ich da auch einmal gleich so knallhart rein starten. Was sind denn da so deine Erfahrungs-Background? Was hast du denn damit schon gemacht? Eine gute Frage. Ich meine, natürlich ausprobiert, ausprobiert, ausprobiert. Mit dem ist es ja jetzt
ein Tool, das ja die komplette Bandbreite trifft. Hat es ja kaum Limitierungen gesetzt. Das heißt, wir verwenden es, also mittlerweile verwenden wir es ja auch wirklich, nicht nur ausprobiert, in der Firma. Von Testcase-Design bis hin zu, dass man sie mit recht netten Feature-Files, also so BDD-Files, recht gut, so was, auch generieren lassen kann. Aber ich muss schon
sagen, es ist fantastisch und cool, aber hat auch durchaus Limitierungen. Ich persönlich verwende es schon gern, auch so für, also ich persönlich komme ja voll aus der Testautomationsschiene, bin ja ursprünglich auch Entwickler, also bin immer noch Entwickler. Wie kann das nicht mehr sein, was ich mal war? Und dadurch habe ich die größte Nähe mit Source Code und verwende es da halt auch recht fleißig. Und es ist auch sehr interessant, wie die einzelnen Language Models
da auch unterschiedlich arbeiten. Und es ist schon eine große Bereicherung. Vor allem im Testumfeld, was ich durchaus mitbekomme, auch aus der Community etc., ist halt die Coding-Skills halt nicht so, wie man es gerne hätte, weil auch viele traditionelle Tester, oder wenn man halt nicht so weit in der Testautomation drinnen ist, dann erbt man es ein bisschen und möchte es natürlich durchaus verwenden. Und da ja Testautomation Software Development ist, ist es für
einen halt recht schwierig. Und hier hilft das Tool recht stark, in der Unterstützung, in diesem sogenannten Glue Code und so weiter, oder Boilerplate Code, also dass man das Ganze mal so zum Leben erweckt. Da ist es schon recht mächtig. Gib uns mal ein Beispiel, was kann ich denn da so machen? Ja, so als konkretes Beispiel, also kein Greenfield Projekt, sondern ein beständiges Projekt und hat schon, keine Ahnung, 500 Testcases, davon natürlich nur, weiß nicht, 1% automatisiert
oder so. Und jetzt hat man natürlich neue KPIs und man möchte natürlich besser werden und man muss es ändern. Das heißt, man hätte gerne einen höheren Automationsgrad. Und jetzt beginnt man halt eben als, vielleicht vorhin, ein 3-Zellertester, wo man durchaus manuell getestet hat, oder explodativ, zu scripten. Und dann entscheidet man sich halt wegen Sprache, vielleicht kann man so ein bisschen Java oder Python oder was auch immer, nur zu starten, seine eigene Idee aufzusetzen und
das einmal lokal lauffähig zu bringen. Und heutzutage leben wir einfach in einem Landscape, wo die technische Komplexität sehr hoch ist. Also von, es ist ja CD, dass das Ganze dann natürlich auch in einer Pipeline läuft, mit Git-Version kontrolliert, dass man zusammenarbeitet mit Pull-Requests und so weiter. Und wenn man jetzt in die ganze Area einsteigen muss, ist der Overhead ziemlich groß. Und hier
hilft es, Support zu bekommen. Man kann auch diese Test-Cases, wenn sie jetzt gut spezifiziert sind, mal in JGPT reinschmeißen oder eines der Language Models und sich mal Feedback holen, ist der schon automatisierungsfähig, fehlt noch was, fehlen Testdaten, fehlen Environments, etc. und dann auch den ersten Code generieren lassen. Und dadurch hat man schon mal diese
Hemmschwelle weg. Man kann, es hat dann eigentlich diesen, ich nenne es gerne diesen 24/7 Peering Partner, den man nicht anrufen muss und gar nichts, sondern man schmeißt was rein und bekommt Feedback und das ist schon super. Das heißt, du nutzt den auch zur Prüfung, ob ein Testfall jetzt überhaupt einmal so, ob da noch was fehlt, ne? Machst du da quasi so eine Art Konsistenzprüfung, wo du sagst, okay, sind da genug Testdaten drin oder wie kann ich mir das vorstellen?
Konkret, also richtig. Und auch, ob die Testdaten gut sind. Oft ist das eben nicht so, oft werden auch weitgehend nur so die Sonne scheint, Vögel singen, Test-Cases, definiert also die Good-Cases, aber es wird halt wenig Rücksicht genommen auf die Edge-Cases bzw. Negative-Test-Cases und so weiter. Und da hilft es dann schon. Also wenn man jetzt ein Feature als Ganzes hernimmt, dann ist es ja, da ist ja mehr Akzeptanzkriterien als nur alles ist okay.
Und da machen schon coole Erfahrungen. Natürlich mit Vorsicht zu genießen. Wenn ich jetzt eine User-Story copy-paste, nach JGPT und nach Feedback frage, wird auch ein sehr generisches Feedback kommen. Wenn ich aber konkret dann auch frage, hey, was hältst du von den Testdaten? Können wir da was ändern? Haben wir schon alle Edge-Cases abgedeckt? Oder welche Risiken siehst du jetzt, also du im Sinne von den Language Model hier noch? Und es kommt natürlich, also wenn ich nach
Risiken frage, kommen Risiken. Das heißt jetzt aber nicht, dass es Risiken sind. Also da kommt dann schon noch unser Verständnis, unser Know-how, unsere Sphären, Erfahrungen, dass wir das dann halt validieren. Ja, ja. Jetzt haben ja einige ja Thema auch mit JGPT quasi, ich werfe jetzt gerade Testdaten, Anforderungen, User-Stories, quasi einer KI, die irgendwo in fernen Ländern agiert, einfach so rein in diesen ganzen Datenpool. Wie gehst denn du damit um? Oder hast du da einen
Tipp auch, was man alternativ nutzen kann? Also bei den Open Source Projekten, wo wir alle fleißig mitarbeiten, könnte besser sein. Aber leider ist es ja nicht so, sondern in unseren Firmen und vor allem, ich persönlich arbeite bei der Raiffeisenbank International, das heißt Finanzsektor, irgendwelche User-Daten so spaßig in einer Open AI zu pasten, ist nicht. Und was
kann ich empfehlen? Also wir bei uns in der Firma haben das internalisiert, das heißt, in der Service, es geht schon, also das Language Model ist schon eingekauft, aber sämtliche Prompts verlassen nicht die Firma. Dadurch können wir auch, also ich glaube Strictly Confidential nicht,
aber zumindest ansatzweise diese Daten verwenden. Und das hilft enorm. Also Tipps vor allem an alle Firmen, mittlerweile braucht man ja nicht mehr darüber reden, ob Gen AI wieder wegkommt, sondern ich glaube, das hat sich etabliert, das bleibt zumindest mal die nächsten fünf Jahre oder so. Wobei das schon mutig ist, drei Jahre, weil wer weiß, was dann alles kommt. Und jetzt
gilt es, dass man das den Mitarbeitern zur Verfügung stellt. Also da gibt es ja ganz, in Frage zu stellen, KPIs im Sinne von Performance, Increase und so, da bin ich ein bisschen vorsichtig damit, dass man sagt, jetzt werden alle besser und schneller. Das schon, aber ja, under quotes.
Ja. Aber das nicht zu verwenden, glaube ich, damit wird man einfach langsamer als die Konkurrenz, dass die Firmen müssen das jetzt, also alles die Language Model im Development Bereich halt eher dann sowas wie Copilot, da gibt es ja die verschiedensten Anbieter, gibt es auch welche, die man intern hosten kann. Das heißt, dann ist die Confidelity sowieso keine Frage mehr, ist ja der Kostenfaktor dann. Nur, ja, man muss jetzt schauen. Return of Investment,
meiner Meinung nach, kommt schon. Ja. Jetzt hast du gesagt gerade, vorher auch, du lässt dir dann daraus den Code auch generieren, zum Teil den Testcode. Wie bist du denn da, oder wie ist deine Einschätzung dazu der Qualität, die da rauskommt? Kannst du das so nutzen oder kommt da manchmal auch echt oder großteils Krütze raus, die du einfach noch nacharbeiten musst oder noch nachbessern musst? Wie sind da so deine Erfahrungen?
Also ich bin immer super happy, wenn das Ding so generiert, hoffentlich schnell und dann bildet es. Oder ich bekomme keine Compiler heraus, da bin ich schon, hey, war gut und prompt. Das heißt, die Realität ist halt oft, es bedarf schon Refactorings. Aber jetzt kommt das große Aber. Ich habe ja sehr früh mit dem Ganzen schon begonnen und die ersten Modelle waren da echt
schlecht. Vor allem auch die Copilots, die waren so richtig schlecht. Also wirklich, ja. Ich wage sogar zu behaupten, dass ich langsamer war mit den alten Copilots als ohne, weil ich permanent diese Code Suggestion oder Code Completion weg escapen habe müssen, beziehungsweise refactoren. Aber mittlerweile ist der Trend schon extrem. Also wenn man sich das so anschaut, es wird viel besser. Es kommt immer wieder vor, dass Dinge vorgeschlagen werden, die auch ich nicht kannte,
ich auch. Dadurch ist es auch ein Learning Tool. Das Tolle ist, man bekommt den Code und immer auch die Erklärung dazu. Oft ist es nicht notwendig, meiner Meinung nach. Also jetzt für jemanden, der schon tief in der Materie drinnen ist. Aber wenn Dinge jetzt auch kommen, die ich nicht kenne, dann lese ich es auch durch. Also denke ich mir, ah ok, sehr spannend, neue Library oder was auch immer. Und das ist natürlich gut machbar. Das habe ich mir mal einen Spaß gemacht,
war ja letztes Jahr, aber glaube ich das mit GPT4 Release, ja, letztes Jahr war das. Und da hat Greg Brookman auf dem Developer Livestream ja diese Skizze gezeigt, wo er dann danach das in HTML verwandelt hat, angeblich mit JavaScript und Backend. Und ich habe dann das auch gemacht, also auch so eine nette Skizze zeichnet, Foto und habe mir das generieren lassen. Es war witzig, weil es hat einerseits wirklich die Applikation erkannt, also sagen wir mal so zu 80 Prozent. Und
ich habe mir dann auch den HTML Code generiert, CSS und JavaScript. Das war dann auch responsive und hat funktioniert. Hat mir auch den Spaß gemacht, das war so eine Talk Rating Page. Und hat mir dann auch ein Service generieren lassen, ein Backend Service, auch das hat funktioniert. Und also das war schon ziemlich cool, also wenn man das jetzt betrachtet, so in das ganze Prototyping,
dass man jetzt eigentlich auf ein Stück Papier wieder was zeichnen kann. Das war jetzt ein bisschen so, da waren so einige Schritte dazwischen, wo man halt dann schon den Entwickler braucht. Aber wenn ich da jetzt noch so ein, zwei Jahre nach vor spule, weiß nicht, wenn das jemand entwickelt, kann ich mir schon recht cool vorstellen, dass danach lauffähige Software ist. Also als Prototyp, aber dennoch schon mehr als jetzt das klassische Prototyping,
was es heutzutage schon gibt. Ist schon interessant und funktioniert mit ein bisschen massieren. Ich glaube, es gibt ja ein bisschen die Gefahr, wenn ich mir jetzt Code generieren lasse und wenn der kompiliert, heißt ja noch lange nicht, dass der funktioniert. Also das kann schon funktionieren, aber dass er richtig ist. Also dass das macht, was ich eigentlich vorhatte. Das heißt, ich muss schon noch ein bisschen Qualitätssicherung immer betreiben und das ist vielleicht für
jemanden, der auch nicht gut programmieren kann, auch nochmal ein bisschen herausfordernder. Ich denke, klasse, das läuft jetzt, ich kann kompilieren, aber es heißt ja noch nicht, dass es das macht, was ich mir eigentlich vorgestellt habe. Das stimmt, da sprichst du eh einen ganz wichtigen Punkt an. Ich glaube, die meisten von uns, oder was man sich so austauscht von den Entwicklern, haben gemeint, ja, jetzt kann ich endlich meine
Unitests generieren lassen. Ja, man kann vieles generieren lassen. Meiner Meinung nach ist, aber bitte, ja, ich will keinen Shitstorm auslösen, aber das ist das Schlimmste, was man machen kann. Also vor allem, wenn man das in einer Art und Weise macht, dass man seine Funktionen reinpastet und sagt, hey, bitte generiere mir 100% Line Coverage, Code Coverage. Das Ding macht das. Also vielleicht reizt es dir 100, aber mit ein paar Prompts kommt
es dorthin. Das Problem ist, wenn du einen Bug in deiner Software hast, dann ist er, der covert das. Also der validiert jetzt nicht, ob dein Code richtig ist. Das heißt, der bessere Ansatz wäre, dass man, wenn dann die User Story in das Language Model reinpastet und sagt, hey, generieren wir Tests davon. Ja, aber dann wäre der Fehler halt eben in der User Story auch wieder nicht so cool. Meine Idee wäre ja, dass man eher die Tests selber schreibt und sich den Business
Code generieren lässt. Und ich würde sogar noch einen Schritt weiter gehen, aber jetzt ist es dann natürlich, jetzt philosophieren wir ein wenig, dass die TDD, also Test Driven Development, ist ja für Unit Tests basierend heutzutage. Und in meiner Idee wäre das so, wenn ich so nach vordenke, dass ich meine jetzt eine Mobile App habe oder wie auch immer, oder eine Webseite, dass ich meine Tests dann in Playwright schreibe und behind the scenes wird die Applikation gebaut
und dass ich meine Applikation nur über die Tests ändern kann. Jetzt natürlich theoretisch vorstellbar und das würde das ganze Testen auf ein komplett neues Level heben, weil es würde heißen, dass wir viel mehr testen werden in Zukunft als heute und dahinter die Applikation
zu einem hohen Prozentsatz wird generiert. Kann man nicht vorstellen, dass es anders geht, weil vor allem so Look and Feel und Responsiveness und wie sich so Applikationen verhalten, tut einem das noch schwer vorzustellen, aber unmöglich ist es nicht. Ja, das ist ein cooler Ansatz im Prinzip, weil es ja der Test als Beispiel für die Implementierung oder als Beweis, dass irgendwas funktionieren soll oder auch als Exempel einfach, wenn ich denke an
Specification by Example oder so, ist das natürlich ja eigentlich eine gute Basis auch dafür. Ob das jetzt vollständig funktioniert, man möchte ja vielleicht auch irgendwie eine ordentliche Architektur haben oder dahinter oder das muss ich auch irgendwo einfügen, da muss man vielleicht ein paar Parameter auch noch haben und wieder nochmal. Aber die Idee, das gerade in Teilbereichen,
das kann ich mir auch sehr gut vorstellen. Jetzt hast du ja, bist ja Testautomatisierer und hilft dir denn die KI auch mittlerweile, vielleicht jetzt nicht nur die generative, sondern auch andere Systeme mittlerweile auch, sag mal, dann noch bei der Testfallrealisierung und Durchführung, gibt es da irgendwie Dinge, wo dir das Leben erleichtert?
Also ich bin ja, als Engineering Coach supporte ich ja mehrere Teams, also jetzt in der Testautomation und vor allem ich habe halt sehr oft diesen Ramp-up-Support, also dass die mal ins Laufen kommen, dass man vernünftige Architektur auch in der Testautomation umsetzt, also jetzt im Sinne von Page-Objects und so weiter. Das ist was man alles kennt und ich finde schon, dass es da
massiv hilft und wir verwenden es auch. Also ich verwende jetzt weniger JGPD, um das jetzt als Beispiel zu nennen, weil das, oder Gemini, ist auch egal, sondern mehr die Code-Completion-Tools, weil die mittlerweile gut sind. Also privat verwende ich zum Beispiel Codeum, weil die gratis sind und das finde ich recht nett, weil ich doch auch einige Open-Source-Dinge mache und da hilft das schon. Mittlerweile kennt ihr den Kontext. Also wenn du jetzt eine Repository hast, dann
kennt die AI deine Page-Objects, deine Keywords, deine Helperklassen. Das heißt, es kommen nicht irgendwelche Code-Suggestions von GitHub kommen, was ja ursprünglich meine Daten waren, was das Ganze gefüttert wurde, sondern es kommen von meinen. Das heißt, ich muss die Funktion nicht
umschreiben, sondern es nimmt meine Dinge und dann wird man schon schnell. Das ist halt irgendwie next level of Code-Completion, wie man es von der IDE kennt, von IntelliJ und Co. Jetzt kommt das jetzt eben zusätzlich noch von einer AI, weil die einfach wissen, oder weil die einfach weiß aus dem Kontext und man muss jetzt nicht permanent Kommentare schreiben. Bitte, das ist auch so etwas, was ich immer mehr mitbekomme, dass jetzt die Repositories mit Kommentaren übergehen. Finde
die sehr eigenartig. Ich weiß, darüber wurde mal geredet, vor allem mit dem älteren Copiloten, war das notwendig, dass man dann lange Kommentare schreibt und danach ist der Code gekommen. Ja, man sollte nur das kommen, also die "good coding practices", was vor ein paar Jahren noch gegolten haben, gelten meiner Meinung nach auch heute noch. Das heißt, Code sollte so geschrieben sein, dass man wenige Kommentare braucht und nur die Teile kommentiert, die wirklich notwendig sind, ansonsten
wird es einfach unlesbar. Also man muss ein bisschen aufpassen. Es wird wahrscheinlich auch fehlen, also wenn jetzt die KI anfängt, dann auch noch die Dokumentation zu schreiben und diese ganzen Dinge. Da muss ich jetzt sofort drauf springen, tut mir leid, dass ich wieder unterbringe. Also auch wir in der Firma arbeiten ja gerade daran, dass wir unser Wiki, GitHub, Rhythmify etc. in den Kontext des Language Models reinbringen, dass wir dann query, also dass wir
darüber suchen können. Weil es gibt ja die Beschreibungen eines Enterprise-Unternehmens gehen ja in das Unähnliche, weil jeder schreibt seine eigenen Dinge und dann möchte man halt jetzt irgendwie ähnlich einmal eine Plattform haben, dass man die Daten herausbekommt und vielleicht noch nur die Daten, die nicht outdated sind mittlerweile. Und jetzt gibt es natürlich die ganzen Lustigen, die sagen "Hey, mega, wir müssen Dokumentation schreiben, wir müssen unsere
Applikation beschreiben, wir brauchen eine Teststrategie". Das schreibt ich in meine letzten 10 User Stories rein und sag "Schreib mal bitte Teststrategie". Und ich brauche 10 Seiten, da passt noch mal 15. Schreibt bitte 15 Seiten, den Rest halluzinier dazu, ist mir doch egal, ich lese sowieso nicht und das liest sowieso keiner. Nur es kommt dann halt an den Punkt, wo wir das schaffen, das ist teilweise geht ja auch schon, dass wir dann AI verwenden, also ein Interface verwenden,
wo dann die AI unsere eigenen Daten durchscreent. Das heißt, wir bekommen dann Output zurück von generierter Dokumentation, die was keiner liest, aber jetzt ist dann wieder suchbar. Also da bin ich sehr, sehr skeptisch, wirklich. Und ich rede immer darüber, dass das einer der Anti-Patterns oder Bad Practices ist.
Ich finde das gut, wenn man Rhythmifiers generiert, auch so mit Requirements, weil die AI weiß ja über Skit Repositore, was drinnen sein soll, dadurch kann es auch gut Rhythmifiers erstellen. Die was man dann Reflect hat, finde ich cool, verwende ich auch selbst, ist toll, aber ansonsten sehe ich es noch eher skeptisch. Und ich bin ja jemand, als Entwickler lese ich ja wirklich wenig Dokumentation und ich liebe es,
wenn das dann nur ganz wenig ist. Am besten Bilder, Architekturen als Bilder beschrieben und irgendwie highlighted, eingreisend, das ist wichtig oder das wird getestet, das wird nicht getestet, das ist extern und nicht zehn Seiten oder fünf Seiten oder nicht einmal fünf Zeilen, weil ich lese es nicht. Es ist ein bisschen so ein Inzuchtsystem, wenn du die Dokumentation generierst und dann auch möglichst viel und das auch nicht qualitätsgesichert und dann quasi daraus wieder Abfragen machst,
das wird dann irgendwie so eine Suppe an Trash. Ja schon, oder? Ich meine, ich verstehe die Motivation der Leute, dass sie das machen wollen, aber ich sehe halt die Problematik, warum wir etwas dokumentieren,
wenn es nicht gelesen wird. Ich weiß schon, viele unserer Industrie sind reguliert, wir ja auch, wir sind ja auch reguliert als Bank, nur wir haben auch unsere neuen Templates, das sind sehr überschaubar, da sind nur die wichtigsten Informationen drinnen und nein, wir haben kein Testhandbuch mit 200 Seiten oder sowas, weil wir einfach wissen, das bringt halt nichts. Und der Regulator schreibt dir nicht vor, dass du 200 Seiten haben musst, sondern der schreibt vor,
dass du das dokumentieren musst, wie du testest. Jetzt hast du ja das eine oder andere Erich in Erfahrung in dem ganzen Testautomatisierungsumfeld und nutzt ja KI da auch schon relativ häufig. Was ist denn, wenn du so auf deine Projekte schaust oder auf generell auf Testautomatisierung, was ist denn deiner Meinung nach ein Problem, das wir jetzt mit KI künftig noch lösen werden können, was jetzt aber noch da ist, wenn du da so ein bisschen in die Zukunft schaust,
was fällt dir denn da auf? Ja, also ich glaube, hoffe, bete, wir, also vor allem jetzt generell, wir bauen ja Applikationen, die was langlebig sein sollen. Leider Gottes sehen wir immer wieder, dass Applikationen dann nicht mehr weiterentwickelt werden können. Wir wissen nicht mehr, wie es gebaut wird, wir können nicht upgraden. Die technische Schuld ist viel zu groß. Und jetzt haben wir natürlich Tools, die uns die letzten Jahre immer wieder geholfen haben, vor allem Tools,
die was das, also mit statischen Code-Analysen, die was es uns gezeigt haben. Und dann hat man natürlich gesagt, ja, wir brauchen jetzt einen Factory Sprint und so weiter und wir arbeiten jetzt aktiv daran. Das an sich ist jetzt schon mal nicht so gut, aber besser als nicht. Wie auch immer, die technische Schuld wächst. Und jetzt haben wir natürlich eine, mit GenAI, werden wir,
oder haben wir jetzt etwas, was besser wird. Ich hoffe wirklich, dass es jetzt nicht in die Richtung geht, dass wir jetzt mit unseren Scrum-Teams, mit acht Leuten, plus, minus zwei oder so, dass wir jetzt sagen, ja, jetzt machen wir sechs Leute, plus, minus zwei, weil jetzt seid ihr eher schneller.
Mit GenAI. Und dafür bekommt ihr ja alle GenAI-Tools, was es gibt. Das wäre, hoffe ich nicht, dass es in die Richtung geht, sondern dass wir jetzt eher letztendlich unsere Arbeit als Software-Engineers
besser machen können. Dass wir jetzt auch das Tool so weit integrieren in unseren Software-Development Lifecycle, dass wir die technische Schuld niedrig lassen, dass wir keinen Kloncode produzieren, dass wir keine Klassen mit 2000 Lines of Code produzieren, dass wir die Dinge dokumentieren, die was wichtig sind, dass wir Architekturentscheidungen hinterfragen, dass wir auf moderne und auch basierende Applikationen bitte moderne Architektur wählen, also sei es Microservices
oder sei es modular basierte Monolithen, was auch valide sind, dass man das besser hinterfragen kann. Viele der Dinge sind bis jetzt nicht so gut gelaufen. Dadurch gibt es ja dieses Legacy. Ich glaube, jede Firma hat Legacy. Oder definiere Legacy. Wann ist etwas wirklich jetzt Legacy? Meistens ist es ja dann Legacy, wenn die Entwickler, die etwas programmiert haben, die Firma verlassen haben, weil dann kann es keiner mehr und auf einmal ist es Legacy. Keine Ahnung.
Also wenn ich so in die Zukunft schaue, habe ich einen starken Glauben daran, dass wir technische Schuld besser in den Griff bekommen, indem wir unsere Arbeit besser machen können. Sei es höhere Automationgrad, sei es unseren Peering Partner, dass wir Code-Entscheidungen hinterfragen können oder einfach schon durch Code-Completion besser da sind, dass wir uns keine Gedanken mehr über
RegEx machen müssen. Das ist übrigens mein Highlight für dieses ganze KI-Zeug, dass ich die endlich verstehe und dass ich sie mir generieren lassen kann und eins reingebe und sage, was heißt das? Ja, das ist ja Wahnsinn. Sehr schön. Im Enterprise-Umfeld bei uns, an RegEx, ich habe gar nicht gewusst, was man jetzt machen kann. Das ist ja richtig irre. Und ich bin echt froh, dass jetzt etwas da ist, was man das in menschlicher Sprache machen kann. Ja, super. Das ist schön,
dass es dir da auch so geht. Ja, Matthias, vielen Dank für diese Einsichten, deine Erfahrungen und deine Meinungen auch dazu. Es war viel Spannendes dabei, was ich auch teile und wo ich mich schon freue, was die Zukunft noch bringt. Und wer weiß, unsere nächste Folge, die wir irgendwann mal machen, wie dann der Stand der Technik ist. Ich sage auf jeden Fall, Dankeschön, dass du hier warst und schicke noch liebe Grüße nach Wien und bis bald. Das ist sehr nett, Ritsche. Es hat mich sehr,
sehr gefreut und komme natürlich gerne wieder. Auf jeden Fall. Mach's gut. Ciao. Ciao, ciao. Ciao. [Musik]