# Transitioning to Agentic Software Engineering and AI-Native Operations

**Podcast:** HMZE
**Published:** 2026-04-23

## Transcript

Einmal noch husten, räuspern, mir, mir, mir, mir, genau.
Nur einen Schluck Wasser trinken oder Tee.
So, und los geht's.
Herzlich willkommen zur neunten Folge unserer neuen Staffel von AMZ E-Biond Vibe Coding.
Der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin Sebastian Heidemeyer zu Erben, CTO bei North.io.
Und ich bin André Neubauer, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
Unser heutiger Gast ist unter anderem AI Adoption Lead bei ZipGate.
Und ZipGate wird dem einen oder anderen Begriff sein.
Das ist eine Firma, die für ihre progressive Kultur und Innovation bekannt ist.
Und dann macht es natürlich auch total Sinn, dass ZipGate sich relativ früh schon mit dem Thema AI auseinandergesetzt hat.
Ein wilder Ritt mit viel Begeisterung, teilweise etwas nerdig.
Und vor allem mit viel Fokus auch darauf, wie die Mitarbeiter AI-enabled werden bei ZipGate.
Viel Spaß beim Hören.
Herzlich willkommen, Lukas.
Wir freuen uns sehr, dass du da bist.
Ein guter Bekannter dieses Podcasts, Jörg Müller von InnoQ, hat uns ja miteinander in Kontakt gebracht und gesagt, Lukas ist jemand, mit dem ihr unbedingt sprechen müsst.
Deswegen, ja.
Ich glaube, die Spannung ist am Siedepunkt, beziehungsweise ich habe jetzt sozusagen den Bar geraced und freue mich auf eine interessante Episode mit dir.
Und wie immer bitten wir auch dich, dich für unsere Gäste mal kurz vorzustellen.
Hallo zusammen.
Erstmal schöne Grüße an Jörg natürlich und vielen Dank für die Einladung.
Mein Name ist Lukas Heniak.
Ich bin bei der SIPGATE GmbH in Düsseldorf tätig.
Ich bin aber auch noch Lehrender an unterschiedlichen Hochschulen, vor allem auch im Düsseldorfer Umkreis und leite einen Prüfungsausschuss bei der IHK Düsseldorf.
Dazu erzähle ich gleich noch ein bisschen was.
Vielleicht erstmal zu den spannenden Dingen, die ich so bei SIPGATE mache.
Ich komme eigentlich aus der Informatik und habe quasi die Vorreiter des New Work Ansatzes, den wir heute meistens in so agilen Ausprägungen kennen.
habe ich in einer Bank für Daytrading erlernt und angewendet, so zwischen 2006 und 2009.
Damals nannten wir das noch nicht so intensiv Scrum, sondern mehr so Extreme Programming, Rapid Prototyping und so.
Und irgendwann habe ich dann, in 2009 muss es gewesen sein, eine Stellenausstellung von ZipGit gesehen, dass die hier skalieren wollen, Energie, Scrum und so weiter.
Und bin dann zu ZipGate gewechselt, um das alles zu fördern, mitzumachen und so weiter.
Und war dann Teil des ersten Scrum-Teams als Softwareentwickler.
Hat sich so ein paar Jahre hingezogen.
Ich habe an mehreren Projekten mitgearbeitet.
In der Welt außerhalb von ZipGate wären das alles so Startups gewesen, wo wir teilweise krasse Ideen ausprobiert haben mit verrückten Ansätzen wie so Lean Startup oder so.
Und das führte mich dann irgendwann bei ZipGate wegen dem Fachkräftemangel dazu.
dass ich im Jahr 2017, war es meine ich, Q2, Q3, in erste Meetings gegangen bin, wo wir eine Art innerbetrieblichen Lehrstuhl, ihr müsst euch das so vorstellen, wie so ein Lehrstuhl an der Hochschule mit Auszubildenden, Praktikanten und alles quasi, was man als Lernenden zusammenfassen kann, wie man das bei Sitge etablieren kann.
Und das habe ich dann konzeptioniert etabliert und habe das fachlich verantwortet, Eigentlich bis heute noch.
Es sind noch zwei Auszubildende da, zwei Studierende da, aber es waren mal zu Hochzeiten, glaube ich, so was wie knapp um die 50 Talents, wie wir sie nannten, also Lernende, die ich dann mit insgesamt drei Vollzeitkräften und noch weiteren Werkstudierenden, die uns unterstützt hatten bei Recruiting.
Wir haben die volle Brandbreite gemacht, habe ich das dann quasi angeschoben.
In der normalen Welt würde man sagen geleitet, aber wir denken nicht so in so klassischen Edelfinen.
Deswegen sage ich immer, ich habe das Programm begleitet.
Und irgendwann sind dann die ganzen Studenten fertig geworden.
Wir haben sie behalten, mussten einige schmerzlich gehen lassen.
Die Masterarbeiten waren zu Ende kollegiert, indem ich es zweitgutachter war.
Und dann habe ich mich seit 2000 ungefähr 20...
für dieses ganze neue AI-Zeug interessiert, was heute quasi so zu 70 Cent mein Arbeitstag bei 75.
Ich bin eigentlich Tech-PO für gewisse regulatorische Themen, weil ich immer irgendwie in diese Themen reingeraten bin, wahrscheinlich zur falschen Zeit nicht reingesagt und diese super 900 Seiten spezifikationslastigen Themen, da waren immer irgendwie meins, vor allem Rufnummern und so, Telefoniegesellschaften mit BNZ-A-Regulatorik bauen und so.
Das mache ich noch zu einem kleinen Teil mit einem Team namens Dada.
Ansonsten bin ich mehr oder weniger verantwortlich für so die AI-Adaption bei ZipGate und da insbesondere so um das Fuhlen der Leute.
Wahrscheinlich wird das auf dem klassischen Markt so ein AI-Adoption-Lead sein, Engineering-Manager, aber sowas haben wir bei ZipGate nicht.
Deswegen sage ich einfach mal, ich bin so der, der das alles vorantreibt, anschubst.
Und da kommt die Connection zu Jörg her, denn wir haben mit InnoQ bis zu 150 Techs vorzuschulen.
Wir sind so ungefähr bei der Hälfte.
Und ja, da ich Informatiker bin, habe ich mit der großen Bubble, sagen wir, an Devs begonnen und Agentic Software Engineering mit InnoQ zu Ende gedacht und dann bei uns eingeführt.
Und wir haben jetzt, ich glaube, an der achten und neunten Kohorte arbeiten wir jetzt mit jeweils zwölf Leuten.
Super spannend.
Vielleicht bevor wir reingehen und ich sehe auch, André hat Fragen, nochmal zwei Worte zu ZipGate.
Also für diejenigen, die ZipGate nicht kennen, dass du vielleicht einmal kurz sagst, was ihr so macht.
Und dann auch würde mich interessieren, wie viele Entwickler, weil das klingt ja wirklich viel, also die geschult wurden schon bei euch.
Also die erste Frage kann ich sehr einfach beantworten.
Im Kern bauen wir Telefonanlagen für die Cloud.
Wir sind also so eine Art SaaS-Anbieter oder PaaS-Anbieter, je nachdem, was du für ein Produkt bei uns kaufst.
Im Kern funktionieren Telekommunikation seit Jahrzehnten ja gleich irgendwo.
Nimmst du ein Hörer in die Hand, willst eine Lufnummer, drückst anrufen, dann klingelt es irgendwo.
Das sind aber potenziell Millionen Zeilenquelltext, die durchlaufen werden, richtig viel Hardware.
Und das bauen wir quasi.
Per Klick kannst du dir deine Telefonanlage mit unter anderem AI-Features kaufen.
Ja, und dann geht's los.
Und die zweite Frage lässt sich nicht so einfach beantworten.
Die Frage nach, wie viele Devs oder Techs haben wir denn?
Denn da drin steckt ja, was ist denn ein Tech oder ein Dev für uns?
Und wenn man das so ganz Arbeitsmarkt...
specifisch bezachtet, haben wir Telekommunikationsingenieure, wir haben DevOps, wir haben so eine Art DevSec-Op, dann haben wir die gewöhnlichen Informatiker, sage ich, und dann kannst du noch die Informatikerin schneiden in Fullstack, Frontend, Mobile und so weiter halt.
Deswegen ist es schwierig, dort eine Grenze zu ziehen.
Ich würde sagen, wir haben ungefähr 150 Texts.
Das betrifft alles, was irgendwas Technisches mit der Plattform macht.
Und das kann durchaus sein, dass in den 150 auch schon Leute bei uns aus dem Support sind, die wirklich sehr, sehr tief auch Telefonprotokolle analysieren können, weil wenn ein Kunde zum Beispiel irgendwo anruft und nicht durchkommt oder es Fehler mit seiner Rufnummer gibt, was durchaus mal passiert, der sich nicht im Netz einbuchen kann, können diese technischen Kundenbetreuerinnen.
können das dann durchaus analysieren.
Selbst das könnte man ja zu Tech zählen.
Aber mit 150 sind wir nicht falsch.
Wenn wir das so nur auf reine Informatikerin runterbrechen, würde ich sagen, so was wie 80 bis 90 vielleicht.
Aber vielen Dank.
Das ist auf jeden Fall signifikant und auch sehr cool, würde ich sagen, wie du das betrachtest, weil am Ende für Aldi hilft ja Agentic Engineering in welcher Form auch immer.
Sehr spannend.
André, ich glaube, du hattest noch eine Frage.
Ja, wo würdest du uns sagen, steht denn quasi Zipgate bei der AI oder vielleicht sogar ein bisschen spezifischer in der Argentic Adoption?
Also wie quasi, wo seid ihr?
Und natürlich im Umkehrschluss, woran machst du denn das fest, dass ihr da so weit seid?
Ja, das kann man tatsächlich sogar impedisch belegen.
Wenn ich jetzt also quasi eine Masterarbeit mit dem Studierenden aufsetzen würde, würde ich sagen, hier, jetzt nehmen wir mal das MIT-Slogan, AI Maturity Model, ja, und dann gucken wir mal, wo stehen wir denn, welche Richtung müssten wir dann noch machen.
Und ich glaube, wir stehen so bei, ja, wenn das Ziel quasi voll AI-Native ist, sind wir bei sowas wie vielleicht 35 bis 40 Prozent, meines Erachtens nach, ja, weil wir schon sehr, sehr viel machen.
Das Weile kann ich gleich ausschmücken.
Noch eine Sache, die mir so aufgefallen ist in Gesprächen, in Fachbereichssitzungen mit Lehrenden, mit anderen Wissenschaftlern von Hochschulen und auch vor allem an der IHK.
So stellt man sich derzeit noch andere Fragen.
Gefühlt beschäftigt man sich noch sehr, sehr stark mit den Sachen, die wir so als digitale Transformation betrachten.
Man könnte auch sagen agile Transformation.
Und man ist sehr, sehr an diesen Zellen gerade festgebissen.
Deswegen gibt es bei vielen anderen Unternehmen auch noch wenig Luft, nach vorne zu blicken, weil man muss ja erstmal die Sachen machen, in die man jahrelang reingebuttert hat und jetzt will man die erstmal auf die Straße bringen, erproben und dann vielleicht noch einen Schritt weiter gehen.
Und vielleicht ist der nächste Schritt dann AI, aber soweit sind viele noch nicht, weshalb ich sagen würde, Wenn ich das jetzt mit meinem Wissen, meinem Netzwerk vergleiche, sind wir bestimmt so drei bis fünf Jahre vor Ansehen Unternehmen.
Man muss aber natürlich sagen, ein kleines Startup von 10 bis 15 Leuten ist natürlich in gewisser Weise schneller, als wir mit unseren knapp 200, irgendwas 50, 60, 70 Personen.
Das ist definitiv schneller in der Adaption von Sachen.
Ich vergleiche mich bei diesen Aussagen natürlich immer mit anderen, ähnlich großen Unternehmen.
Und da gibt es ein paar in Düsseldorf und Düsseldorfer Umgebung.
Und da ist man meines Erachtens nach noch nicht so weit.
Das merke ich auch, wenn ich zum Beispiel zu Konferenzen eingeladen werde, zu irgendwelchen Barcamps, Workshops, wo ich mal was erzählen soll.
Und dann kommt man meistens in Gespräche und anhand dieser Gespräch und der Fragestellung merke ich schon, aha, die machen sich die...
Gedanken, die wir uns eigentlich schon vor einem Jahr gemacht haben.
Was eigentlich bedeutet, wir sind ein Stückchen voraus.
Dann erzähl mal so ein bisschen, wo du sagen würdest, wo ihr gerade steht.
Ja, ich habe einem der Gründer und Eigentümer, Tim Moyes, habe ich letztes Jahr, ich glaube November, was im Plan vorgelegt.
Und wenn ihr mal so im Change Management seid, dann gibt es so Tipping Points und so.
Und ich hatte den Tipping Point berechnet für, ich glaube, Mitte Februar diesen Jahres.
Da, wo es quasi nicht mehr aufzuhalten war.
Lustigerweise war es dann Mitte Februar dieses Jahres so ungefähr.
Man kann es nicht so genau sagen, dass wir quasi so viel an Schulungen angeboten haben und auch Leute befähigt haben.
Ja, da geht es ja auch um das Enabling.
Welche Tools kann ich wie nutzen?
Wo darf ich was nicht rein tun?
Wegen Datenschutz, Urheberrechte, Unternehmensdaten und so.
Und ich glaube, wir...
haben relativ schnell die Fragen beantwortet, wo sich viele relativ lange drauf angeln, festhalten oder aufhalten, nämlich was darf ich wann in welche KI-Tools rein tun.
Ja, da waren wir relativ typisch, fand ich, drin.
Das war so binnen eines, anderthalb Monate erledigt, weil wir selbst Anwälte beschäftigen.
Und dann hat es Fahrt aufgenommen mit den Schulungen.
Und wir hatten quasi bis Februar diesen Jahres, hatten wir sechs Kohorten durch.
mit fast nur Techs und inzwischen sind so 70% ungefähr Techs durch diesen Agentic Software Engineering Workshop mit InnoQ zusammengegangen und jetzt machen wir noch weitere Landgruppen.
Ich als Tech-PO, von meiner Rolle gibt es noch ein paar mehr, die nehmen jetzt einen Teil.
Ich nehme aber auch schon erste weitere Gruppen an diesem Agentic Software Engineering Workshop teil, weil ich immer evaluiert habe.
Ich bin immer in das Gespräch gegangen und habe das dann wieder quasi in OQ gefeedbackt.
Wir müssen das ein bisschen breiter aufstellen.
Wir müssen hier ein bisschen weniger technisch werden, um einfach breit zu fächern und das Adressaten gerecht an eine breite Gruppe streuen zu können.
Und da stehen wir jetzt.
Wir machen jetzt also quasi schon die letzte Iteration des Agentic Software Engineering Workshops.
Das heißt, wir gehen von drei Tagen auf zwei Tage, weil natürlich, wenn irgendwie schon die Hälfte der Dev-Bubble oder der Tech-Bubble bei uns die Schulung gemacht hat und wir intern noch so ein paar Barcamps haben, man intern noch ein bisschen Zeit hat, entwickelt sich das Thema ja auch.
Anzukriegen das irgendwo dann mit auf dem Flurfunk beim Kaffee oder beim Pairing oder irgendwie sowas, ziehen die das ja mit.
Und deswegen sind drei Tage inzwischen zu viel und wir glauben, wir können auf zwei Tage runtergehen.
Und das wird dann die letzte Iteration sein, die letzten fünf Termine für, ja, potenziell fünf Termine für Text.
Und wir arbeiten jetzt schon quasi an der nächsten Gruppe, nämlich POs, Produktmanager, Product Leads, plus noch den Rest der Firma, also alles, was quasi Buchhaltung ist, Justitia, Sales.
Das zufälligerweise, heute habe ich das Angebot dazu bekommen, bestätigt.
Das rollen wir jetzt groß aus, sodass wir hoffentlich bis Q3 tatsächlich 100% der Firma potenziell geschult haben.
Geht natürlich nicht immer wegen Kinderkrank oder wegen irgendwas anderen, aber Ziel wäre, mein persönliches Ziel wäre, bis Q3 haben wir tatsächlich alles voll gefühlt.
Und wenn ich sage, wir haben ein Non-Tech geschult, dann meine ich damit, dass die quasi Prompt-Engineering-Techniken gelernt haben, die wissen, was jetzt in Forma-Architektur ist, die wissen, wieso Token-Rechnung funktioniert, dass da nicht große Intelligenz bei ist, sondern eine Berechnung von Wahrscheinlichkeiten.
Ja, die wissen, was ein Zero-Shot, ein Few-Shot und ein Chain-of-Fort-Prompting ist.
Sowas werden die alles wissen.
Die Möglichkeit wird es dazu geben, in x-weiteren Fortbildungen.
Und da stehen wir jetzt, ja.
In den Worten des Eigentümers oder des Geschäftsführers würde es heißen, wir sind sehr, sehr gut in Richtung AI First unterwegs, vielleicht sogar irgendwann mal AI Native.
Das werden wir aber noch klären müssen und selbst herausfinden.
Beeindruckend.
So ein bisschen, ich habe jetzt die Sorge, dass wir quasi zu zeitig jetzt quasi in das Hauptthema abbiegen.
Vielleicht parken wir das hier kurz und nehmen gleich nochmal den Ball auf.
Also reden ein bisschen darüber.
Nach dem Training, welche Bottinex ihr seht, wie sich euer Lifecycle, Software-Livecycle halt angepasst hat.
Aber wie nutzt du heute, also quasi Day-in, Day-out, AI für deine Themen, bevor wir da so ein bisschen tiefer in die andere Richtung einsteigen?
Ich bin noch nebenbei in einem Studium aktiv, dass sich da Data Science Machine Learning schimpft.
Das heißt, ich mache sehr, sehr viel so mit Machine Learning Algorithmen, wo man die anwenden kann, um ein konkretes Beispiel zu geben, weil bei uns geht es ja um Audio.
Womit ich mich so beschäftige, ist, dass ein LLM, ein Gen AI Apparat, der jetzt quasi eine Audio-Teile bekommt, daraus Text macht, der kann jetzt E-Mail-Adressen.
nicht gut identifizieren, weil dieses Ad ist schwierig, wenn jemand sexisch spricht oder einen anderen Dialekt, ist das nicht immer eindeutig, die Modelle können das nicht gut übertragen und ich mache dann so eine Art, ich komme dann mit meinem Machine Learning dahin, baue irgendwelche experimentellen Use Cases, lasse mir Testdaten generieren oder nehme eigene, wenn ich welche finde und habe und ja, optimiere das LLM mit gewissen Metriken und versuche das dann ohne LLMs zu lösen oder Open-Wade-LLMs quasi.
so zu trainieren, dass sie bessere Ergebnisse liefern.
Das ist ein Use Case, den ich mache, aber ich programiere ganz normal auch mit CodeCode oder anderen Werkzeugen und versuche da bestmöglich meine Effizienz zu steigern.
Denn als Tech-PO und als Mensch, der sich da diesen Hut angezogen hat für das Vorantreiben der gesamten Schulung der Belegschaft, komme ich nicht mehr so oft ins Pair, um an User Stories zu arbeiten im Sprint, aber ich versuche dann quasi manchmal ein paar Tickets zu machen oder mal ein bisschen Forecasts zu machen, die User Stories mit die Codebase anzuschauen, lasse mir dann über Skills oder irgendwelche Agents OML-Diagramme erzeugen, mache ein bisschen Agentic Workflows und versuche zu evaluieren, wie man zum Beispiel so...
nervige Tickets, die man immer wiederkehrend bekommt, wie man das in der Mergenti-Corpflow abbilden könnte, das evaluieren könnte, um da auch KPIs dann zu schreiben wegen Model Drifts und so weiter.
Das ist das, womit ich mich so beschäftige.
Das ist also Butterstrauß letztendlich.
Was ist denn da, du sprachst ja gerade irgendwie von verschiedenen Tools, was ist denn da so der Haupt-Tool-Stack, den du so benutzt?
Ich habe mal sehr, sehr viel in OpenAI ChatGPT gemacht und da auch viel Custom Games gemacht, über Assistant dann make.com angebunden, N8n.
Davon bin ich inzwischen weg, weil ich war nicht so ganz zufrieden damit.
Ich bin jetzt hauptsächlich bei Anthropic mit Cloud und Close Code und nutze aber noch für gewisse Szenarien immer noch Google Gemini.
Was sind so meine Tools?
Fürs Coden, klar, Code-Code, da gibt es derzeit nur wenig besseres, außer ich fand lokal das Modell auch, um es zu optimieren für einen gewissen Use-Case.
Ansonsten benutze ich meistens Code-Code fürs reine Programmieren.
Und Gemini dann quasi einfach als LLM, also Chat in Chatform sozusagen?
Exakt, in Chatform, aber auch API und Tokens.
Wenn ich mal einen Agentic Workflow für gewisse Szenarien testen will, dann nehme ich auch mal Gemini, dann Gemini Pro 3.1 oder sowas oder kleine Modelle, wenn es ein bisschen schneller oder wenn es um andere Szenarien geht.
Aber ansonsten benutze ich Gemini vor allem für Text und für Research, denn gefühlt ist der Outcome beim Research bei Gemini besser.
Alles klar, das wäre meine nächste Frage gewesen.
welches Tool benutzt, aber quasi also dann im Allgemeinen für Coding Cloud Code und für Text and Research eher Gemini.
Verstehe ich jetzt.
Ja, einen Punkt muss ich da noch ergänzen.
Cloud Code hat eine andere Linie, nicht Cloud Code, Cloud Project, also das Äquivalent zu Google Gems, hat Eine andere Limitierung, was die Dateien anbetrifft, die du dort in den Speicher tun kannst, wenn du dir das Werk baust, was Gemini dir anbietet.
Das ist bei Cloud Code ein bisschen besser.
Da sind die Limitierungen größer.
Das heißt, ich kann dort zum Beispiel 500 PDFs reintun.
Bei Gemini geht das nicht.
Und wenn ich dann auch noch sehr, sehr diverse Daten habe, wie Audiodateien, Talks von Videos bei YouTube, nutze ich auch inzwischen Notebook.lm, weil es tatsächlich mit eines der besten Tools ist, was so die Wissensynthese angeht.
Und ich kann ja inzwischen in Gemini sogar Notebook.lm ja anbinden als Rack.
Und dann spare ich mir sogar noch ein lokales Rack hochzufahren.
Und Retrieval-Optimierung und so weiter, das glaube ich dann alles nicht.
Wir machen das, machen dann die Tod.
Interessant.
Was wäre denn da so ein Beispiel für, also wie da der Workflow ist?
Also was sozusagen ist das Ziel, was ist der Input und wie nutzt du das dann?
Hast du da mal ein Beispiel?
Ja, ich habe einen kleinen Workshop gehalten, wo es darum ging, dass wir die Kundenkommunikation irgendwie besser...
zusammentragen mussten, Zusammenfassungen erstellen wollten und so ein bisschen auch einen Gesprächsleitfaden erstellen wollten.
Heißt, wir haben Audionachrichten, die uns jemand auf Voicemail aufgesprochen hatte, plus Tickets, die wir irgendwo hergenommen haben und auch noch Präsentationen des Kunden, die frei bei YouTube zugänglich waren.
Die haben wir dann mal bei Notebook.lm hochgeladen, haben zum Beispiel gesagt in dem Prompt, generieren wir jetzt mal eine Zusammenfassung, generieren wir dort im Notebook LM, meinen Podcast, weil ich gerade im Auto unterwegs bin und das nur hören kann, weil ich meine Location wechseln muss oder so.
Und dann nehmen wir bitte auch einen Gesprächsleitfaden.
Das kriegt das Ding relativ gut hin und es halluziniert nicht, weil es einfach so programmiert ist, dass es nur die eigenen Quellen nimmt.
Und dann haben wir, wenn es ein bisschen komplexer wurde, habe ich dann zum Beispiel in Gemini mit 3.1 Pro noch ein bisschen was in Richtung Vergleichsanalysen mit der Konkurrenz gemacht.
Das heißt, wenn wir wissen, dass der Kunde bisher woanders einen Vertrag hatte oder irgendwo besonders die Interessen liegen, dann kann man mit Gemini...
Wenn man dort quasi Deep Research macht mit dem Notebook LM als Wissensquelle, kann man dort relativ viel rausholen und sich vor allem viel Arbeit ersparen.
Ich muss dann nicht mehr irgendwie ganz viel Material gucken, sondern ich kann mit gewissen Limitierungen mich darauf verlassen, dass die Ergebnisse richtig sind.
Und ich kann dann sowas fragen wie, gib mir die fünf USPs im Vergleich zu der Konkurrenz.
Das mache ich dann in Gemini auf Basis des Racks, was ich vorher bei Notebook-LM erstellt habe.
Ah, okay, alles klar.
Das heißt, du lädst da einen Haufen Dokumente rein nach Notebook-LM und interagierst dann aber gar nicht über Notebook-LM, sondern über Gemini, sozusagen nativ, so wie du es sonst auch machst.
Okay, das habe ich tatsächlich noch gar nicht gemacht.
Ich habe Notebook-LM bisher immer extra genutzt, aber auch eher so.
Experimentell noch gar nicht so richtig die Standard-Use-Cases gefunden, aber spannend.
Inzwischen kann man das auch über Google API steuern und das in Jupyter-Skripte verpacken oder auch in Python-Skript verpacken oder in der Programmistik heute Wahl.
Das kann schon sehr viel und es ist natürlich für User, die jetzt nicht programmieren wollen, weil man da Google Drive-Ordner anbinden kann.
Das fühlt sich ja an wie so ein Windows Explorer oder so, kann man das für Non-Tix sehr, sehr gut benutzen in den Workshop-Szenarien.
Ja, das glaube ich.
Ja, ich meine, am Ende, so wird es dann auch, wie du schon sagst, usable.
Ich mache ähnliche Sachen mit OpenClaw, wo ich manchmal, wenn ich einen YouTube-Talk habe, der sehr reich ist an Informationen, dann habe ich mir einen Skill gebaut, der das Transkript runterzieht und dann nach einer bestimmten Formatierung sehr schön zusammenfasst und dann Referenzen rauszieht und dann Suggestions ableitet und offene Fragen und so.
Und das dann auch in den Google Drive Ordner hochlegt, damit ich es dann entspannt sozusagen zur Verfügung habe.
Damit wird es natürlich dann besonders jung.
Wie gehst du mit dieser Veränderungsgeschwindigkeit um, Lukas?
Weil die Beispiele, die du ja gerade nennst, sind ja schon, würde ich sagen, sophisticated.
Also schon das Zeug der von viel ausprobieren.
Aber das ist ja, also quasi man könnte ja eigentlich den ganzen Tag ausprobieren und idealerweise halt auch noch die Nacht.
Was ist denn so dein natürlicher Filter?
Also das mache ich, das mache ich nicht, um sich da nicht auch in so einem Rabbit Hole zu verlieren?
Also ich muss gestehen, inzwischen plane ich einige Tasks so, dass ich weiß, da läuft ein Apparat über Nacht, der braucht acht Stunden, bis das Reinforcement Learning durch ist.
Dann plane ich den Tag so, dass ich das abends vorm Schlafengehen ansteuere und morgens die Metriken habe.
Das muss ich ganz ehrlich sagen.
Ansonsten wäre das gar nicht möglich, so ganz hartes Machine Learning zu evaluieren und zu proben.
Ich versuche, das alles andere immer relativ nah an meinen praktischen Tätigkeiten zu sehen.
Deswegen fällt es mir nicht schwer, dort quasi dieses Änderungstempo mitzugehen, weil immer, wenn ich was quasi per Hand gemacht habe, vor allem, wenn es mich genervt hat, frage ich mich, kann das KI auch?
Und dann gucke ich.
Wie gehe ich da vor?
Und inzwischen, glaube ich, bin ich relativ gut und sicher in Context Engineering und Prompt Engineering.
Das heißt, ich schreibe dann meine Prompts noch nicht mal mir selbst, sondern nutze das halt irgendwie anderweitig, lasse ich das herstellen.
Dann weiß ich, das ist ein Roll Prompt, das ist ein System Prompt.
Dann habe ich ein paar Examples, die gebe ich da rein.
Dann gibt es eine gewisse Struktur.
Und wenn ich weiß, dass ich das mehrfach täglich machen muss, dann mache ich mir quasi meine Automatisierung.
Das ist für mich inzwischen ganz normal, so zu arbeiten.
Und ich komme natürlich in meinem Job auch in Berührung mit viel, viel Ablehnung und Vorsicht.
Und ich kann euch sagen, dass meiner Beobachtung nach vor allem Leute, die ich als Experte bezeichnen würde, sich schwer tun.
Das hat meines Erachtens nach was damit zu tun, inwieweit KI allgemein Leute ernebeln kann, etwas zu erreichen.
Bei mir ist es ganz klar ein Zeitvorsprung, wenn ich ein Projekt habe, wo ich irgendwie eine Deadline erreichen will, was schneller haben will, weil ich potenziell auch eher zu den ungeduldigeren Typen gehöre, dann hilft mir KI, das erstmal einen Prototypen auf die Straße zu bringen und dann kann ich ja weiter darauf interieren.
Ich habe da also nicht so einen Expertentumanspruch.
Aber wenn jetzt jemand 20 Jahre lang oder 15 oder 10 irgendwie Maximalwissen in Java aufgebaut hat und der super Spring Boot Experte ist, von mir aus auch, weiß ich nicht, Asterisk und Telekommunikationsexperte ist, ich glaube, da fällt es am meisten oder da bemerke ich, dass es am öftesten schwerfällt.
Und das ist natürlich ein riesiger Change, der da auf die Leute zukommt.
Und das muss man begleiten.
Das muss man ganz klar begleiten.
Was ich so mitbekomme ist, dass dieses Änderungstempo, was man verlangt, nicht nur bei SIPGIT, sondern allgemein, also das, was mir in meinem Netzwerk begegnet, das ist immens hoch.
Das ist immens hoch, das ist noch viel höher, als wir angefangen haben darüber zu sprechen, wir müssen jetzt agile Arbeitsweise einführen.
Jetzt ist irgendwie Proben maximal.
Bis zum geht nicht mehr.
Und das fällt den Leuten schwer.
Und ich glaube, diese Anforderung an die Leute, ihr müsst euch schnell wandeln können, völlig egal, ob es KI ist, sondern dieses maximale Drücken mit ihr müsst euch schnell ändern, weil der Druck von KI ist da.
Alle andere machen das schon.
Das ist das, was es schwer macht.
Du hättest KI durch einen anderen Begriff ersetzen können.
Du hättest da auch, weiß ich nicht, irgendwas anderes hinschreiben können.
Aber sobald du eine radikale Änderung anstellst, siehst du Widerstand.
trifft jetzt natürlich KI sehr stark, aber es gibt dafür Lösungen und eigentlich müssten wir auf diese Lösungen genauer gucken, Leuten mehr Zeit lassen, vielleicht irgendwelche Coaches nehmen und Leuten, die an die Hand geben, zeigen, was es noch für Wege gibt.
Irgendwie sowas würde ich gerne haben, wenn wir über Schmerzen bei Veränderung sprechen.
Wollen wir ein bisschen stärker nochmal auf SIPGATE gehen?
Sehr gerne, ja.
Wir machen das ja auch ein bisschen als Selbsthilfegruppe hier, Lukas.
Insofern, sowohl Sebastian als ich sind ja quasi auch in unseren Jobs quasi mit dem Thema da tagtäglich konfrontiert.
Ich habe jetzt so eine ganze Liste an Fragen.
Ich fange mal an.
Wie mäßchen für euch so die Transformationen?
Die Antwort kann ich mir geben.
Wie viele Mitarbeiter habt ihr da irgendwie trainiert?
Aber das, was wir ja zum Beispiel schon sehen, ist, dass sich der Software Development Lifecycle halt irgendwie verändert.
Also quasi dieser Innerloop wird weitestgehend automatisiert.
Arbeit findet eher bei den Themen Requirements Engineering und so statt.
Wie messt denn das für euch, wo ihr da als Firma steht?
Gute Frage, ob wir das überhaupt sinnvoll messen.
Ich blende mal das sinnvoll aus, weil wir haben noch nicht so den großen Weg gefunden, sage ich mal.
Der ist schwer zu finden.
Es gibt Spodien, die empfehlen dir das.
Dann hat Stanford 100.000 Leute gefragt, dann haben die diese KPIs empfohlen und so weiter.
Das kannst du nicht pauschalisieren, meines Erachtens nach.
Es gibt natürlich die Klassiker, sowas wie Tokenverbrauch.
Sowas wie, wie viele Tools nutzt denn wer, wie ist die Aktivität da drin, das alles kannst du messen.
Es gibt natürlich auch noch fragwürdigere KPIs, falls es überhaupt noch KPIs ist, wie ich kann mir sogar den Inhalt der Prompts angucken, die die User da angeben, das machen wir jetzt nicht, aber theoretisch gibt es da ja eine ganz bunte, breite Palette.
Wenn du mich fragst, wie messe ich denn jetzt den Fortschritt, ganz klar, wie...
ist denn jetzt die Anzahl der Leute, die an dem Workshop teilgenommen haben.
Vor allem, was mir aber viel wichtiger ist, und das ist so ein bisschen der Berufspädagoge in mir, ich versuche, die Workshops zu evaluieren.
Das heißt, ich bitte Leute, die daran teilgenommen haben, erst mal via internem Kommunikationstool Slack, mir gerne Feedback zukommen zu lassen.
Ansonsten gehe ich in persönliche Gespräche.
Und frage, wie waren denn die Workshops?
Was kannst du mitnehmen?
Das kann man mal bei einer Tasse Kaffee machen oder beim Mittagessen.
Oder auch mal bei so einem Barcamp, das wir alle zwei Wochen haben.
Wir nennen es Open Friday.
Dann kann man auch mal größere Resorts aufhängen, mit Gruppen diskutieren.
So gehe ich vor.
Und stelle fest, da gibt es eine Bewegung nach vorne.
Du kannst aber natürlich auch, wenn du so ein bisschen mehr im qualitativen Bereich bist, wie diese Gespräche, kannst du natürlich auch anhand der Themen, die die Leute im Slack bewegt und die sie kommunizieren, kannst du natürlich auch so eine Aufbruch kommunizieren.
Wir haben irgendwann in der dritten Runde, der dritten Kohorte des Agentix Software Engineering Workshops kamen dann Skills raus.
Wir haben das dann eingebaut in die Webshops und immer mehr Skills entstehen.
Immer mehr Leute diskutieren über Skills.
Immer mehr Leute bauen Chatbots, so eine Art Slackbot in die Team-Channel rein, die du nach Sachen schlagen kannst, wo du vorher immer ein Meeting potenziell gemacht hast oder gewartet hast, bis jemand Zeit hat, um mal eben im Büro mit Leuten zu sprechen.
So kannst du auch Fortschritt messen.
Es gibt also nicht das eine einzige...
sagen wir mal, Konstrukt namens KPI, das du zur Messung hinzunehmen kannst.
Du kannst aber durchaus Zahlen erheben, die dir eine gewisse Tendenz andeuten.
Das ist ja am Ende das, worum es geht, das Outcome, also die Skills, die Slackbots, also das, was entsteht dadurch, dass Leute jetzt befähigt sind.
Von daher sind das schon sicherlich die wichtigsten Messungen.
Was ich mich vorher noch gefragt habe, Du hast ja gesagt, man kann auch gucken, welche Tools.
Das klingt so, als wärt ihr da relativ frei.
Also jeder nutzt wahrscheinlich das, worauf er oder sie Lust hat.
Und wie macht ihr das mit dem Budget?
Also wie steuert ihr das?
Wie viel Budget hat jeder?
Gibt es Standardsubscriptions, die benutzt werden?
Also im Slack kam mal eine Nachricht von einem Kollegen, wo drin stand, ey Leute, wir müssen Tokens verbinden.
Wir wollen dieses...
diesen Award haben, der dann kommt, wenn wir Platin-Status erreicht haben, weil wir über 10 Milliarden Tokens verbrennt haben, ist ein Synonym für, es gibt gefühlt derzeit keine Limitierung.
Klar müssen wir mal darüber sprechen, wenn jemand irgendwie versucht, weiß ich nicht, 5 Millionen Tokens pro Tag zu verbrennen für irgendeinen Nonsens, irgendeine, weiß ich nicht, Katzen-Videogenerierung oder so, da muss man mal früher oder später drüber sprechen, aber ansonsten sind wir alle angehalten und so weit auszutoben, wie wir wollen und es ist explizit auch erwünscht, dass wir alles, was wir an Lizenzen haben und wenn du Cloud Code plus Gemini brauchst und dann nach ChatGPT, dann go for it.
sind wir auch sehr, sehr stark angeraten, das im privaten Kontext zu benutzen, wenn wir den Bedarf sehen und wollen.
Das ist kein Zwang oder irgendwie sowas, aber die Neugier zeigt halt an.
Wir wollen halt Gentic Core Close ausprobieren.
Wir wollen das Langchain ausprobieren.
Wir wollen irgendwelche komplexeren Dinge bauen, weil es einfach in unserer Natur als Softwareentwickler liegt.
Und es gibt diese finanzielle Grenze nicht.
Wir alle haben irgendwie große Antropic Enterprise, Google Enterprise.
wird sehr gerne am Laufen und jeder, ich glaube, das ist der Cloud Code Max Plan, den jeder Dev hat, den er will, aber inzwischen hat es, glaube ich, auch fast jeder PM, weil die PMs ja jetzt auch durch diese Agency Coding-Schubung gehen und go for it.
Niemand wird wahrscheinlich, also ich würde mich sehr, sehr wundern, wenn jemand irgendwo hingeht und sagt, ey, du darfst jetzt Tool X, Y, Z nicht benutzen, weil es zu teuer ist.
Es könnte sein, dass jemand hingeht und sagt, wir dürfen das Tool nicht benutzen, weil wir Datenschutz noch nicht geklärt haben.
Kann passieren.
Aber nicht wegen Kosten, weil wir in so einer massiven Explorationsphase sind und alle sollen irgendwelche Erkenntnisse sammeln.
Ich versuche nochmal die Kurve zu meiner Frage vorher.
Jetzt habt ihr aber als Firma für euch definiert, was euer Zielzustand sein soll, also wo ihr hin wollt, also warum ihr das alles macht.
Dagegen könnte man ja dann messen.
Also ich kann nochmal aus einer anderen Richtung fragen.
Vielleicht kannst du in der Zwischenzeit so ein bisschen quasi im Hinterkopf schon mal quasi prozessen lassen.
Man könnte ja auch so Maturity-Modelle halt irgendwie nehmen.
Bin ich normalerweise ein Fan von.
Also quasi so Meta-Ebene, dann halt quasi vier, fünf Levels und dann halt irgendwie eine passende Definition.
Ich habe noch nichts in dem Umfeld gefunden.
Ich glaube, ganz gute AI-Maturity-Model.
Für so Argentic AI habe ich bis jetzt noch nichts gefunden.
Deswegen war ich ein bisschen gespannt, weil du auch meintest, ihr seid so weit.
Und ich glaube auch, das, was du erzählst, das hört sich sehr, sehr weit an.
Aber habt ihr für euch da so eine Idee, was dann auch als nächstes kommt?
Also das wäre, wenn ich weiß, wo ich hin will, dann weiß ich auch, wo ich heute bin, wie ich es messen kann.
Also all diese Aspekte, habt ihr da doch vielleicht irgendwas?
Ich habe nichts außer dem MIT-Slogan AI Maturity Model.
Ich habe also nichts für das Identik-Dasein.
Ich habe aber auch nichts, wenn ich die Frage beantworten müsste, was ist denn das große und ganze Ziel?
Wir denken da so ein bisschen anders.
Das könnt ihr euch so vorstellen wie...
Die Telekommunikation wird sich ändern, ganz klar.
Wir telefonieren nicht mehr so früher, keiner hat mehr Tischtelefone, Leute schicken Audios via WhatsApp und gleichzeitig drücken da Startups quasi von unten mit neuen Features.
Es gibt ja so Phonio, Hallo Petra oder wie sie auch immer heißen, über die sprachen wir ja vor x Jahren noch nicht.
Das heißt, der Kuchen vom Markt wird vielleicht ein bisschen kleiner und diese Startups, die nutzen halt oft.
Agentic-Mittel, um natürlich Kosten zu sparen, um Effizienzsteigerungen zu erzeugen.
Also müssen wir ja irgendwas tun, um uns in der Lage zu versetzen, so ein bisschen performanter und schneller zu sein, wie so in Richtung Startups.
Über all dem, was wir tun, steckt also sicherlich irgendwo der Gedanke, AI kann uns was abnehmen, was uns effizienter macht.
Dadurch, dass wir effizienter werden, können wir vielleicht alle Sachen machen, so wie ihr vorhin gesagt habt, die in die Schublade gewandert sind, die wir früher nicht machen konnten, aber jetzt möglich sind, weil es einfach schneller möglich ist.
Ich gehe stark davon aus, dass das die Wette ist, auf die wir setzen.
Aber so konkret hat sich niemals jemand hingestellt und gesagt, das ist das Ziel, alle dahin, ja, Ziel ist, weiß ich nicht, wir brauchen unbedingt alle 50% Abdeckung, Agentic Mittel, um...
die Kosten wieder reinzuholen, sowas gibt es nicht.
Sondern wir wissen, das ist eine Zukunftstechnologie.
Wir haben das akzeptiert, dass es so ist.
Wir müssen das irgendwie bei uns anwenden.
Aber dadurch, dass wir halt sehr agil organisiert sind, gehört es auch dazu, dass jeder so ein bisschen ausdefinieren muss für sich.
Was bedeutet denn Argenti-Coding denn jetzt für mich?
Es gibt also nicht das Ziel, wenn wir Argenti-Coding machen, heißt das, wir müssen 80% der Tests selber generieren.
So was gibt es nicht, sondern es gibt gewisse Freiheiten und das alles muss jeder für sich selbst, der bei ZipGate beschäftigt ist, herausfinden, meines Erachtens nach.
Was es auch so furchtbar schwierig macht, das in so ein AI-Maturity-Model zu drücken, denn alle sind so ein bisschen wild in eine gewisse Richtung am Schwimmen, aber es gibt so nur bedingt so eine konkrete Richtung.
Es ist mehr so der Schwarm, der insgesamt in Richtung AI drückt.
Ich hoffe, ich habe das so versucht, bestmöglich zu beeinflussen.
Ich glaube, das ist ja am Ende auch das, worum es geht, dass man auf Outcome optimiert und nicht für eine Metrik sozusagen, die ein Proxy darstellt, um zu gucken, wie viel KI schon benutzt wird oder Agentic Use Cases, sondern dass man auf Outcome optimiert.
Und da ist ganz klar natürlich der Innovationsdruck.
die Innovation an sich, Kerntreiber und Motivation.
Von daher macht es schon Sinn und ich verstehe auch, was ich bisher von der SIPGATE-Kultur verstanden habe, so dass es eine Kultur ist, die sehr auf, du sprachst vorhin von New Work und Agilität ausgelegt ist, also sprich darauf, dass auch die Innovationskraft und die diversen Perspektiven der einzelnen Individuen in der Organisation voll zur Geltung kommen und sich entfalten können, um halt Innovation auch in der Unternehmung zu erzeugen.
Also das höre ich da raus, dass es dahinter steht.
Und ich glaube, das ist natürlich grundsätzlich ein sehr vielversprechender Ansatz, der ja SIPGATE offenbar auch relativ weit gebracht hat bisher.
Von daher macht es schon durchaus...
Sinn, das so zu sehen.
Ich glaube, das ist natürlich, also bei SIPCATE, wo ihr sehr viel in diese Kultur investiert habt, auch sehr, das wieder über die Schulungen sehr, sehr breit streut.
Das geht ihr insofern wieder relativ gut an und relativ strukturiert.
Ich glaube, bei größeren Unternehmen ist es wahrscheinlich nicht ganz so leicht, so eine homogene Kultur zu gewährleisten, dauerhaft.
Und da gibt es dann eben so Maturity-Modelle.
Da hat auch wieder die Laura Tacho beim Pragmatic Engineer Summit, die hat das im Talk gehalten, die hat ein Modell auch präsentiert, was sie nutzt, was so drei Kernaspekte sich anguckt.
Das eine ist Utilization, also wie viel wird es genutzt?
AI-Tool-Usage, percentage of PRs that are AI-assisted, tasks assigned to agents, etc.
Dann Impact, also Time-Savings, Developer-Satisfaction.
Dann die X-Core-Metrics und ja, Hours of Work Completed by Agents, also Human Equivalent Hours of Work und dann nochmal Costs, also AI Spend, Time Gain per Developer und sowas.
Und sie hat da noch einen ganz lustigen Satz, ja, lustig oder traurig, je nachdem wie man nennt, gesagt und zwar in vielen auch ...
großen Tech-Organisationen gab es ja immer die Diskussion Developer Experience.
Also das ein Stück weit wurde verstanden, gerade in der Hochzeit, und wir als Developer sehr gesucht waren, ja, die Experience muss für die auch stimmen.
Und da hat man dann immer mal wieder zähneknirschend irgendwie investiert.
Wenn man jetzt aber eigentlich das Gleiche möchte, weil Agent Experience ist eigentlich das Gleiche wie Developer Experience, dann braucht man einfach nur Agent Experience zu sagen und schon sind alle Entscheider so, oh, Ja, Agents, genau.
Die bringen uns nach vorne.
Klar, nehmt, was ihr wollt, wir investieren.
Das fand ich eine lustige, aber gleichzeitig irgendwie auch traurige Aussage.
Vielleicht ein spannender Insight, wozu unser Vorgehen jetzt zuletzt geführt hat, was ich so an der Kaffeemaschine besprochen habe mit anderen.
Dadurch, dass wir ja breit gefächert sind und vor allem auch die Erprobung sehr, sehr explorativ und auch breit fördern.
Es unterhalten sich natürlich Leute, wie kann ich meine Effizienz als Programmierender stärken, aber es unterhalten sich Leute auch darüber, wie sieht denn eine Teamzusammensetzung in Zukunft aus?
Denn potenziell kann ich ja mit einem Agent auf Basis von Baselines, der ja zufälligerweise auch nur in Code gucken kann, sehr guten Epic runterschneiden in Stories und shipbare Inkremente und so weiter.
Dieses Requirements Engineering, was ihr gerade gesagt habt.
Welche Rolle hat denn noch so ein PO in dem Team?
Auch das sind so Prozesse, die gefühlt jetzt immer mehr Fahrt aufnehmen, denn wir werden irgendwann darüber sprechen müssen.
Das wird sich natürlich auch verändern und das hat so ein bisschen Unternehmensentwicklungs-Org-Charakter.
Wie sieht so die Zukunft eines Teams aus?
Wer sitzt da drin?
Wie viele Leute sind das denn?
Und wir haben da einige, die sind da schon sehr, sehr fortschrittlich, würde ich sagen, auch für SIP-Gate-Verhältnisse sehr, sehr fortschrittlich und einige Teams, die sind da noch...
in der Erprobungsphase oder versuchen gerade erst Fahrt aufzunehmen.
Das passiert auch bei uns.
Superspannend.
Da wollte ich auch noch so ein bisschen in die Richtung mal rein weitergehen.
Was sind denn die Veränderungen, die ihr also auf einem non-individual Level quasi gesehen habt?
Also du hast ja gerade schon gesagt, Teamkomposition, Prozesse.
Kannst du da irgendwas schon teilen, was ihr schon alles hinter euch habt, was ihr schon alles erlebt habt?
Das ist eine never ending story und das ist auch gut, dass es so ist.
Man muss darüber sprechen, weil einige, um da den Kreis zu schließen, tun sich schwer.
Einigen drückt da so ein bisschen der Schuh, ganz klar.
Die muss man auch unterstützen und einige nehmen Vollfahrt auf.
Und dann gibt es noch die ganz Verrückten wie mich, die wollen ganz tief gucken, was ist denn jetzt so ein stohastisches, die in Abschiedsbefahren und lernen das dann auswendig.
So, und die muss man ja irgendwie zusammenbringen und es gibt die Leute, die sagen, hör mal.
Wir können nicht mehr so wie früher arbeiten.
Eigentlich brauchen wir vom PO oder nennen diese Person, die diese Kundenanforderungen irgendwo in eine Story gegossen hat, wir können sie nennen, wie ihr wollt.
Aber das muss eigentlich jetzt viel präziser sein.
Wir können dort keine Research Stories mehr irgendwie machen.
Nicht können, sondern es lohnt sich nicht mehr, die Research Stories zu machen, weil das kann ja jemand auch machen mit einer KI.
Wir haben Daten von Kunden, wir haben Kundenfeedbacks.
Das kann man ja alles irgendwie analysieren lassen.
Das müsste jetzt eigentlich vorher passieren.
Während wir vorher also noch so...
sagen wir mal, Personen hatten, delizierte Personen, die irgendwie die Strategie gebaut haben.
Dann diese Strategiemenschen haben dann potenziell auch schon erste Epics gebaut oder sind in Meetings gegangen mit POs oder PMs oder was auch, wem auch immer und haben dann erste User Stories gemacht, geguckt, wie sind denn die Leute verfügbar, um dann Termin zu machen, erste Schätzungen zu machen.
Das geht ja jetzt viel schneller.
Ja, LLM kann ich oder...
AI kann ich einen Baseline beibringen, sie kann den Code gucken, potenziell als eine Person, ja, und deswegen stellt man sich die Frage, ist das jetzt ein Drei-Personen-Team mit irgendwie ein Tech macht noch gleichzeitig den PO mit, weil wir die Strategie so gut schon formuliert haben, aber eigentlich muss es irgendwo diese Person geben, die diese Formulierung der Strategie und diese Kunden mit den Anforderungen sehr, sehr präzise machen und in Requirements gießt, ne.
Und ich würde sagen, wir haben Nicht viele Teams, die schon da ihren Weg gefunden haben.
Wir haben vielleicht so ein, zwei Teams, die erproben gerade so erste gute Modi, die haben sich so etabliert, wo der PO dann tatsächlich LLM auch in Code gucken lässt und man gemeinsam Baselines definiert und dann trennen sich die Wege und jeder geht so, jeder defnimmt so seine User-Story, geht dann ins Backdriven Development, also Agentic Software Engineering und baut dann die Story für sich selbst und am Ende trifft man sich und guckt, hey, hat das denn jetzt funktioniert oder nicht?
Das alles wäre vorher viel zeitaufwendiger gewesen, vor allem wegen Meetings mit allen Finden und so weiter.
Da stehen wir gerade so und andere Teams überlegen noch, wie kann es denn überhaupt funktionieren, dass wir AI in unsere Domäne lassen.
Das hat aber dann vor allem damit zu tun, dass diese Teams viel mit Legacy-Software arbeiten, wo man einfach nur bedingt Fehler machen kann, sonst sind zwei Millionen Datensitze kaputt in der Datenbank.
Und die sind dann nur bedingt wiederherzustellen.
Oder es sind tatsächlich Probleme, mit denen man sich im Team beschäftigt, wo die AI tatsächlich kaum Wissen hat.
Und das ist vor allem bei telekommunikationsnahen Techniken so.
Also ein Dialplan in so einem Telefonie-Server, das Ding hat das noch kaum gesehen.
So ein NLM ist nicht zäniert auf irgendwelche Dialpläne oder Kamaliocode oder irgendwelche spezialisierten Programmiersprachen, die man nur im Telekommunikationssektor hat.
Das machen die erstens falsch und meistens dann tatsächlich verstehen sie gar nicht, was du von ihnen willst und sagen dann, ja, du musst das löschen, lass uns das lieber ein paar helfen machen, weil es viel cooler ist.
Funktioniert natürlich nicht.
Im Umkehrschluss müssen diese Teams dann natürlich vielleicht ein bisschen mehr lernen, wie man da so ein Rack aufbaut, ein bisschen mehr Kontext füllt, das Ding irgendwie optimiert und so.
Solche zwei großen Bewegungen haben wir, weshalb es auch schwer ist, an Zahlen zu bleiben.
Ja, krasses Spannungsfeld auf alle Fälle.
Ja, ich wollte gerade auch so etwas Ähnliches sagen wie du mit Rack aufbauen und so.
Also eigentlich ist es ja dann wieder Context Engineering.
Denn ich mache gerade in dem Fall, also bei uns, wir sind ja auf Geodaten spezialisiert, das ist auch eine sehr spezielle Nische und da gibt es teilweise auch proprietäre Formate.
Aber in dem Moment, wo man die Spec für das Format hat und das LLM damit füttert, geht es auch wieder.
Also das ist, genau, da geht es wirklich ums Context Engineering und selbst in so einer speziellen Domäne und ich möchte zugestehen, dass Telefonie nochmal eine speziellere Domäne durchaus sein kann, aber selbst in so einer speziellen Domäne wie unsere Ocean Data Domäne, da kommt man mit dem, was die LLMs per se können, schon relativ weit.
Websearch dazugeben und sagen, hier, recherchiere doch mal.
Oder wenn es ganz schlimm kommt, dann gibt man direkt einen Link, einen Speck oder irgendwas dazu.
Und damit kommt man tatsächlich auch relativ weit.
Gerade gestern hatte ich auch den Fall, haben wir mal für unsere wirklich große Legacy-SaaS-Applikation, die definitiv größer ist, als das alles in ins Kontext-Window passen würde.
Dann war so ein komplexes Feature durchgeplant.
Da habe ich einfach PM und Head of Software Engineering mal zusammengenommen und den Plan-Mode angeschmissen.
Nach 20 Minuten war das Feature komplett durchdefiniert.
Aber auch bis zu einem Punkt, wo man sagen würde, es sind eigentlich keine User-Stories mehr, sondern es sind tatsächlich Implementation-Tasks gewesen, weil die User-Stories, die sind gar nicht mehr nötig gewesen.
Wir haben halt die 22 Fragen, die das LLM eruiert hat während des Requirements Engineering sozusagen, die haben wir beantwortet.
Dann haben wir uns das Ergebnis angeguckt, haben dann noch eine Stelle vergessen, wo es noch nicht ganz optimal den Punkt gefunden hat, wo man nochmal was re-usen konnte, also nach unserem zu dritt sozusagen, unserem Gusto und haben das nochmal gesteuert in die Richtung und danach war es ein Spec, wo wir alle drei gesagt haben, genau so würde man es machen.
Das war schon echt beeindruckend.
Ja, ein spontaner Impuls, den ich auch öfter mal bei uns an der Kaffeemaschine lasse.
Das ist ein Satz, der brennt sich bei den meisten ein und entweder wollen sie dann mit mir weiter diskutieren oder jagen mich weg von der Kaffeemaschine.
Und ich sage dann immer, wenn ihr eine Spezifikation habt, kann ich das automatisieren.
Und ich halte das tatsächlich auch mit allen Sachen, die ich so mache.
Wenn ich eine Spezifikation, ein PDF habe, wo vielleicht Daten in Textform vorliegen.
Bilder sind schwierig, das werdet ihr kennen.
Tabellarische Daten, die schwierig zuzuordnet sind, sind auch manchmal so schwierig.
Aber alles, was den Text hat, gut beschrieben ist, Stichwort Dokumentation, dann kann ich das meistens mit LLMs irgendwie performanter machen, als ich es selber hätte.
Oder ich kann tatsächlich Prozesse auf Basis dieser Spezifikation automatisieren, wo ich vorher hätte potenziell Sachen per Hand mehrfach machen müssen.
Das geht nicht immer, das hat natürlich Limitierungen, aber das ist erstmal mein Ansatz.
Und um auf deine Frage nochmal zurückzukommen, dem Software Development Lifecycle, muss das auch so ein bisschen bei mir Revue passieren lassen.
Ich glaube, wir sind in Zukunft, vielleicht jetzt schon, das kann ich nur schwer insgesamt beantworten, aber das, was ich so feststelle, ist, wir werden viel weniger Zeit in die Testphase investieren.
Auch in die Construct-Phase, da werden wir potenziell weniger Zeit investieren, weil du dem Ding einfach sagen kannst, baue das jetzt mal auf, weiß ich nicht, Stranger-Fick-Pattern um oder Observer-Pattern oder irgendwie sowas.
Das muss ich nicht mit bei Hand machen.
Und wir werden uns viel stärker um das Requirement Engineering oder das Planning und das Design kümmern.
Und da sind die Personen, die ich erwähnt habe, wichtig.
Die müssen wir erst kennenlernen.
Wir müssen diese Zusammensetzung und die Arbeitsweise im Team erst kennenlernen.
Nur hatten wir bisher Nie so delizierte Tester.
Das war immer Aufgabe des Softwareentwickels der Menschen bei uns.
Weil you code it, you want it, you own it und so weiter.
Typisch agile Ansatz.
Aber Unternehmen, die Tester haben, was machen die denn jetzt, wenn die so unterwegs sind wie wir?
Deren Job ist doch quasi potenziell weg oder sie müssen sich halt ändern.
Das Problem haben wir, wie gesagt, nicht.
Aber trotzdem merkst du da so eine gewisse Verschiebung.
Denn Unit-Tests habe ich schnell generiert.
Wenn ich irgendwie große System-Tests habe.
die in meinen Kontext passen, kann ich die auch super schnell wegautomatisieren.
Wenn ich weiß, wie ich den Kontext ein bisschen optimieren kann, kann ich auch größere Systeme das wegautomatisieren, ja.
Dann gucke ich mir den Code-Car-Volt-Report, vertraue darauf, so wie ich es früher auch gemacht habe und setze es, ja.
Das ist so das, wo es sich meiner Meinung nach hinbewegen wird und das alles führt letztlich dazu, ich weiß nicht, ob ihr diesen Punkt ansprechen wollt, der war auch bei dem letzten Kollegen mit dem Moldbot-Meetup in München ein Thema, die Werteverschiebung in der Softwareentwicklung.
Das wird passieren.
Schieß mal los.
Werteentwicklung in der Softwareentwicklung.
Nee, Werteverschiebung in der Softwareentwicklung.
Ja, Werteverschiebung.
So, jetzt.
Welche Werte, welche Verschiebung?
Ja, ist ein riesiges Thema.
Eingangs hatte ich ja gesagt, ich habe so ein bisschen Unternehmensorg-Entwicklung gemacht und so mit dem internen Lehrstuhl und Leute nachschieben und so weiter.
High Potentials finden, Fachkräftemangel entgegenwirken und so.
Wenn man mal überlegt, dass wir jahrzehntelang Organisationen und Organisationsstrukturen, die wir als Teams meistens bezeichnen, um quasi das teuerste Gut, nämlich Software entwickelnde Menschen, die Quelltex erzeugt haben.
gebaut haben.
Oder halt, wenn du nicht bis zum Quelltex gegangen bist, hast du das gleich auf Design-Level gemacht.
Oder vielleicht sind auch beide gleichwertig in so SaaS-Companies wie bei uns.
Kann ja sein, das ändert sich natürlich rapide, weil natürlich die Halbwertszeit von Quelltex durch KI erzeugt, potenziell viel geringer ist, denn ich kann ja in großer Menge ausprobieren und einen neuen Code erzeugen lassen, ob der qualitativ genug ist.
Möchte ich jetzt noch nicht verantworten, wahrscheinlich wird das nicht sein, aber potenziell habe ich ja erstmal die Möglichkeit, viel schneller das, was wir früher eigentlich, wo wir Prozesse hin optimiert haben, dieses Shippable-Inkrement, was am Ende von Scrum rausfällt, kann ich viel schneller erzeugen.
Was eigentlich schlussfolgernd bedeutet, ich muss irgendwie diese Wertverschiebung auffangen und irgendwas anders machen in meiner Unternehmensorgung.
Definitiv.
Also das ist ein fundamentaler Change, sicherlich.
Sicherlich.
Und genauso quasi heften sich dann die Themen Build or Buy dran.
Or Make or Buy.
Aber es ist genau das Gleiche.
Und das kann man weiterspinnen.
Jetzt stellt euch vor, ihr seid eine SaaS-Company und euer größtes Produkt oder euer größter Cashflow war die Erzeugung von Quelltext.
Geiste Zeit?
Ja, ja, absolut.
Also habe ich auch vorhin tatsächlich mit jemandem die Diskussion gehabt.
Ich glaube, Das hängt stark davon ab, welche Art von SaaS.
Also wenn du ein System of Record bist, dann bist du tendenziell wahrscheinlich eher auf der sicheren Seite, je nachdem, wie wertvoll die Daten sind, die bei dir drin sind.
Und dann hast du wahrscheinlich viele AI-Use-Cases, die du darauf bauen kannst, weil man ja da nicht nur sozusagen...
hier auch immer geartetes Tool kauft, sondern auch die Sicherheit, dass die Daten definitiv nicht verschwinden, dass das Tool reliable ist, dass es immer da ist, dass es secure ist.
Das sind alles Sachen, die man für so sehr wichtige Daten möglicherweise auch nicht nebenbei mal so weibcoden möchte.
Für interne Tools, für Sachen, die man sonst gekauft hätte für, keine Ahnung, 10.000 Dollar im Jahr, die halt zehn oder 50 Integrationen haben, die man eh nicht braucht, die auch eh nur intern genutzt werden, wo man also nicht irgendwie eine spezielle Security oder sogar Reliability oder Scalability Anforderungen hat, weil es nur drei interne Nutzer gibt.
Das sind natürlich super Beispiele für schnell mal Vibe gecodet.
Kennt ihr wahrscheinlich, aber trotzdem vielleicht auch nicht alle Hörer, relativ hyped.
Dev by Claude.
So eine Webseite, wo man halt einfach mal das Business eingeben kann und dann mal schaut, was quasi das LLM quasi denkt, wie lang dieses Geschäftsmodell des Unternehmens quasi noch verteidigbar ist.
Ganz nett.
Ich glaube nicht quasi not proved, aber quasi hilft so ein bisschen die Richtung zu denken, die du gerade genannt hattest oder die ihr gerade genannt hattet.
Definitiv.
Definitiv.
Vielleicht so eine Frage nochmal so zum Abschluss.
Lukas, du hast ja vorhin auch gesagt, du bist so ein New Work Veteran.
Zumindest habe ich mir das hier notiert.
Hast du eine Idee, wie diese Agentic Software Development, wie man es auch immer nennen will, quasi was das mit Arbeitsmethod macht?
Ja, ganz schwierige Nummer.
Erstmal tief durchatmen.
Denn tatsächlich glaube ich, dass neben der Veränderung von unserer Domäne der Softwareentwicklung, sage ich mal, dass natürlich Ausprägungen haben wird auf das, was die Pädagogen als lebenslanges Lernen bezeichnen.
alles gelernt haben im Rahmen unseres Arbeitslebens.
Und dazu gehört es definitiv mal, Fehler zu machen.
Und ich vermute, auch die Hörer haben schon mal sowas wie Fail Early, Fail Often gehört.
Das macht natürlich was mit uns.
Lernen durch Einsicht, lernen durch Fehler und dann lernst du ja irgendwie, wie es weitergeht und aufzustehen und das Gleiche.
So wie wir mit dem Fahrrad fahren, hinfallen und dann haben wir ein paar blutige Knie, aber irgendwann passiert das halt nicht mehr.
Und das ist zu einer gewissen Zeit in unserem Leben so das Tollste, was uns passieren konnte, dieses Learning.
Das fehlt meines Erachtens nach.
Das fehlt in dem gesamten Spektrum der...
Berufskompetenzen, so wie die Pädagogen das nennen, weil was ja quasi KI uns abnimmt, ist so ein bisschen, wir probieren mal einen halben Tag was, stellen fest, es funktioniert nicht.
Und dann müssen wir uns hinsetzen, bis der Kopf raucht oder um Hilfe bei anderen bitten, die das vielleicht schon mal durchlebt haben und dann nämlich gemeinsam einen Weg finden.
Das ist also irgendwie so ein dreistiefiges Ding, erstmal nach Hilfe fragen, dann mit anderen Menschen Synergien erzeugen und eine Problemlösung herbeiführen und dann natürlich auch noch meine eigene Problemlösekompetenz.
Und ich glaube, das wird ganz krass in Arbeitsmethoden fehlen, wenn man sehr, sehr lange, ohne das eigene Tun und Handeln zu hinterfragen, auf Lösungen von KI setzt.
Das merke ich bei mir zum Beispiel auch sehr, sehr schnell, wenn ich irgendwie mal eine Woche lang irgendwie so ein größeres Projekt mal gecodet habe.
wie dieses Kafka-Ding, dieses verteilte Systeme-Ding, was ich weiterentwickeln wollte.
Ich habe sowas auf die Straße bekommen.
Das ist auch mit KPIs, und nicht KPIs, sondern mit Ansätzen wie Clean Code, Clean Architecture und so weiter, habe ich die KI gefüttert, hat mir super was gebaut.
Aber ich erinnere mich heute nur noch bedingt, was ich eigentlich so gemacht habe, weil es einfach zu viel war, in einem viel zu hohen Tempo.
Ich konnte mir das also nicht mehr merken.
Während früher die Ausnahmesituation natürlich viel, viel tiefer ging, man hat so ein bisschen auch Deep Work gebraucht.
Und das wird irgendwann fehlen.
Ja, die Tatsache, dass du eben nicht mehr alles wissen musst, weil du jemanden, also ein Co-Pilot neben dir hast, der halt gefühlt erstmal alles weiß oder zumindest aus unserer Sicht alles weiß, ne, good enough ist, brauchst du halt, brauchst du das halt nicht mehr, ja.
Und ich muss ganz ehrlich sagen, das macht mir stellenweise auch Angst und so aus, mit der Brille der, der, das...
Das Hochschullehrende, das macht auch den jüngeren Generationen in Studium Angst der Zeit, beziehungsweise Angst ist so ein hartes Wort, es beschäftigt die schon sehr, sehr.
Ja, insbesondere, weil quasi die Antwort darauf noch nicht da ist.
Also was quasi, wenn wir wahrscheinlich in zehn Jahren zurückspulen, dann gibt es darauf eine Antwort.
wie bei jeder größeren Transformation oder Disruption, quasi fallen halt Jobs weg, neue entstehen und wir wissen noch nicht, quasi wir haben eine Vermutung, was vielleicht wegfällt, aber wir wissen noch nicht, was entsteht.
Und das ist wahrscheinlich diese Unsicherheit, die da gerade herrscht.
Amen.
Ja, was vielleicht auch passieren könnte ist, so Sachen wie Scrum, was wir ja zehntelang erlernt haben.
geht jetzt vielleicht tatsächlich wieder in so eine Art Web mit Prototyping oder Extreme Programming zurück, weil halt einfach die Entwicklung der Prototypen schneller wird.
Und ob man das gut findet oder nicht, es ist wahrscheinlich sogar potenziell, wenn man so die Hard Facts von XP nimmt, also Extreme Programming, ist es vielleicht sogar der klügere Ansatz.
zu sagen, du brauchst dieses große Framework nicht zur Prozesskontrolle und so weiter.
Weil wir bauen ja sowieso Prototypen, die haben eine Lebenszeit von einer Woche und wenn wir sie an Kunden vertestet haben oder mit Kunden zusammen erprobt haben, dann schmeißen wir es weg, wenn es nicht mehr benötigt wird oder iterieren da drauf, weil Code ist ja jetzt nicht mehr so teuer.
Die Erzeugung von Code ist nicht mehr so teuer.
Vielleicht geht es dahin, vielleicht entwickeln wir uns.
Eigentlich zurück, weil Extreme Programming waren so Vorreiter, aber vielleicht ist es auch die Möglichkeit, jetzt quasi Extreme Programming für uns neu zu erfinden und neu zu denken.
Gut, ich würde sagen, wir sollten langsam mal zum Ende der Episode kommen und wir haben ja ganz am Schluss noch zwei so kleine Recurring-Segmente.
Das erste ist der Reality-Check und da gibt es immer so zwei Fragen.
Welches Tool hat dir kürzlich einen What-the-Fuck-Moment erzeugt und was ist für dich aktuell so der heißeste Shit sozusagen?
Okay.
Ich bin stellenweise in der Wissenschaft aktiv und ich muss sagen, es gibt da potenziell Toolings.
wie sowas wie Semantic Scholler.
Das ist meines Wissens nach so eine Ausgründung von ein paar Studierenden des MIT und die haben eine AI-Suche gebaut für Literaturrecherche.
Wenn man vorher noch so große Systematic Literature Reviews gemacht hat oder in kleinen Formen so Rapid Reviews, da hat man sich hingersetzt und dann wirklich die ganzen Journals durchgesucht.
Das Ding macht quasi per Fingerschnipp.
findet das Abstracts, das baut mit Zusammenfassungen.
Die haben auch ein eigenes KI-Modell für Research, wenn man das lokal betreiben will.
Das war so mein Aha-Moment, weil dort finde ich tatsächlich alles.
Ich finde dort einfach alles.
Und ich kann das alles sogar noch, wenn ich da irgendwie ein Research betrieben habe, kann ich das dort...
nochmal ein zusätzliches LLM packen und mir dann die Analysen machen lassen, wo ich vorher an einem Whiteboard mit x Wissenschaftlern hätte stehen müssen und diskutieren müssen, welche Methodik machen wir denn jetzt.
Jetzt machen drei Leute sehr unterschiedliche Methodiken, treffen sich auch nach einer Stunde und haben dann erste Ergebnisse und die wissenschaftliche Quelle quasi synthetisiert und müssen dann darüber diskutieren, ob das Ob die Qualität genug ist oder die LLM da so ein bisschen dazu erfunden hat, aber wir haben halt drei Experimente gefahren, während wir vorher nur eins machen konnten.
Und das ist mit so Tools wie Semantik Scholler möglich und das war so mein Aha-Moment.
Benutze ich sehr, sehr gerne auch heute noch.
Ein zweiter Aha-Moment war, ich war letztes Jahr im Januar beim Fraunhofer-Fokus in Berlin auf einer Fortbildung zu Quantum Machine Learning, also Machine Learning auf Quantencomputern.
Und was da noch möglich ist, da werden wir die Ohren anlegen.
Und da gab es quasi erste Tendenzen zu einem Startup, das den Quantencomputer für zu Hause anbieten wird, für viel Geld, aber durchaus im Bereich eines Kleinwagens.
Also die ganz nerdigen und freakigen Leute werden sich dann Quantencomputer statt einer Werbepumpe in den Vorgarten stellen.
So ungefähr muss man sich das vorstellen.
Da ist nochmal was völlig anderes möglich.
Und zwar im Bereich der Datenanalyse vor allem.
Wird jetzt so mathematisch, alles, alles können wir mit Quantenkubülter noch nicht machen.
Da müssen die Forscher noch ein bisschen aktiv werden.
Aber stellt euch vor, anstelle von irgendwie 10 Stunden Wartezeit, bis so eine Maschine durchgelaufen ist, kann ich mit QML, das ist meistens von IBM, so eine Machine Learning Sprache, kann ich damit in einer Stunde Ergebnisse erzielen und Forecasts in Machine Learning Modelle bauen.
Die waren vorher gar nicht denkbar, weil einfach die Technik nicht in der Lage war, schneller zu arbeiten.
Das waren so meine zwei Aha-Momente.
Was mich so ein bisschen enttäuscht hat, war Bildgenerierung mit LLMs.
Das ist nicht so mein Schwerpunkt.
Ich würde aber wahrscheinlich gerne meine Vorlesungen...
so per KI erstellen lassen und dann so ein bisschen mehr ins Planet Learning gehen, diese Videoerstellung hat bei mir überhaupt nicht funktioniert, war furchtbar teuer.
Das war auch nicht gefühlt irgendwie so ich.
Das hat nicht gut funktioniert für mich.
Und einige Sachen bei OpenAI im Bereich Deep Research.
haben für mich in letzter Zeit auch schlechter funktioniert.
Das war jetzt aber nicht so ein ganz schlimmer Moment für mich, sondern ich wusste einfach, dass gewisse Fachbereiche schwierig sind, mit LLMs abzudecken.
Und dementsprechend war das für mich okay.
Ich habe es erwartet.
So richtig schlecht kam das bei mir nicht drüber.
Ich bin einfach Fan.
Ich probiere gerne aus.
Ich wandle gerne.
Ich gehe gerne nach vorne.
Ich gucke aber auch gerne viel, viel tiefer in die Mathematik dahinter und die Frameworks.
Das bin ich so.
waren das schon meine Momente.
Alles klar.
Danke dir.
Hast du noch eine Prediction, die du unseren Hörern gerne mitnehmen möchtest?
Oder hast du im Prinzip schon alle Predictions vorhin genannt?
Waren ja einige.
Ich glaube, es war ganz deutlich, dass QML, also Quantum Machine Learning, kommen wird.
Früher oder später, da steckt sehr viel Geld hinter, da wird wirklich richtig viel Geld reingebuttert.
Ich hoffe, und das würde ich mir so eher als Wunsch-Prediction äußern, ich hoffe, Hochschullehrer, auch Schule, nimmt sich KI ein bisschen an.
Es muss nicht in absolutem Fanboytum ausatmen, aber irgendwas muss für die nächsten Generationen passieren und da meine ich nicht ein Data Science Studium, sondern da meine ich einfach ganz grundlegende Skills, die an Hochschulen vermittelt werden müssen.
Vor allem auch Soft Skills, wie bringe ich mir Sachen überhaupt bei, wie werde ich wandelbar und so.
Das würde ich mir wünschen und ich hoffe, dass es quasi etwas, was sich erfüllen wird.
Denn sonst tatsächlich werden es irgendwann die nachrückenden Studierenden und Schülerinnen, die sich nicht hinsetzen können und wollen, sehr schädig haben.
Und ich hoffe, aus meiner Wunsch-Prediction wird irgendwann mal zu kommen.
Vielen Dank dir.
Dann haben wir es.
Danke euch.
Der HMZE-Podcast ist ein gemeinsames Projekt von Sebastian Heidemeyer zu erben und André Neubauer.
Infos zum Gast und Themen aus dem Podcast findest du in den Shownotes.
Diskutieren kannst du mit uns bei LinkedIn und für alles andere, zum Beispiel wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an podcast.hmze.tech schicken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.