Latest / Beyond Vibe Coding / #059 AI Transformation bei sipgate - mit Lukas Hejniak
Transcript
- Sebastian: Einmal noch husten, räuspern, meh, meh, meh, genau, und Schluck Wasser trinken oder Tee. So und los geht's. Lukas Hejniak: Ahem. Sebastian: Herzlich willkommen, Lukas. 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 bzw. 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. Lukas Hejniak: Hallo zusammen. Erst mal schöne Grüße an Jörg natürlich und vielen Dank für die Einladung. Mein Name ist Lukas Henjak. Ich bin bei der Zipgate GmbH in Düsseldorf tätig. Ich bin aber auch noch Lehrende an den unterschiedlichen Hochschulen, vor allem auch im Düsseldorfer Umkreis und Leiter im Prüfungsausschuss bei der EHK Düsseldorf. Dazu erzähle ich gleich noch ein bisschen was. Vielleicht erst mal zu den spannenden Dingen, die ich so bei Zipgate mache. 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 Day-Trading erlernt und angewendet, so zwischen 2006 und 2009, damals nannten wir das noch nicht so intensiv, Scrum, 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 eskalieren wollen, Energie, Scrum und so weiter. Und bin dann zu ZipGit gewechselt, ⁓ das alles zu fördern, mitzumachen und so weiter. war dann Teil des ersten Scrum Teams als Software-Entwickler. Ja, das hat sich so ein paar Jahre hingezogen. Ich habe an mehreren Projekten mitgearbeitet in der Welt außerhalb von ZipGit. Während das alles so Start-ups 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 SIPG, den Fachkräftemangel, dazu, dass ich im Jahr 2017 war, das 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 SüdGeld etablieren kann. Und das habe ich dann konzeptioniert etabliert und habe das fachlich verantwortet bis, ja eigentlich bis heute noch. sind noch zwei Auszubildende da, zwei Studierende da, aber es waren mal so Hochzeiten, glaube ich, so was wie knapp ⁓ 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 der Shooting, denn 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 klassischen Hierarchien. Deswegen sage ich immer, habe das Programm begleitet. Und irgendwann sind dann die ganzen Studenten fertig geworden. Wir haben sie behalten, mussten einige schmerzlich gehen lassen. Masterarbeiten waren zu Ende korrigiert, in denen ich 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 Prozent mein Arbeitstag bei sich führt. Ich bin eigentlich Tech-PO für gewisse regulatorische Themen, weil ich immer irgendwie in diese Themen reingeraten bin, wahrscheinlich so falschen Zeichen nicht reingesagt und diese super 900 Seiten spezifikationslastigen Themen. Da waren immer irgendwie meins, vor allem Rufnummern und so Telefoniegesellschaften mit BNZA-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 ⁓ das Schwulen der Leute. Wahrscheinlich wird das auf dem klassischen Markt so ein AI Adoption Lead sei, Engineering Manager, aber sowas haben wir bei SIPG nicht. Deswegen sag ich einfach mal, ich bin so der, der das alles voran treibt, 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, hab ich mit der großen, ähm, ja, Bubble, sagen wir, an Devs begonnen. und Agents Software Engineering mit InnoQ zu Ende gedacht und dann bei uns eingeführt und wir haben jetzt, ich glaube an der 8. und 9. Kohorte arbeiten wir jetzt mit jeweils 12 Leuten. Sebastian: Super spannend. Vielleicht bevor wir reingehen und ich sehe auch andere Fragen, zwei Worte zu Zipgate. 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. Lukas Hejniak: Also die erste Frage kann ich sehr einfach beantworten. Im Kern bauen wir Telefonanlagen in 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 Telekommunikationen seit Jahrzehnten ja gleich. Irgendwo nimmst du ein Hörer in die Hand, willst eine Rufnummer durchs Anrufen, dann klingelt es irgendwo. Das sind aber potenzielle Millionen Zeilen Quelltexts, die da durchlaufen werden. Richtig viel Hardware. Und das bauen wir quasi per Per Klick kannst du dir dann eine 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 viel Devs oder Techs haben wir denn? Denn da hinten, da drin steckt ja was ist denn ein Tech oder ein Dev für uns? Und wenn man das so ganz Arbeitsmarkt spezifisch betrachtet, haben wir Telekommunikationsingenieure, Wir haben DevOps, wir haben so eine Art DevSecOps, 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, dann können diese technischen Kundenbetreuerinnen, können das dann durchaus analysieren. Selbst das könnte man ja zutechst 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. Sebastian: 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 Agents engineering in welcher Form auch immer. Andre, ich glaube du hattest noch eine Frage. HMZE Podcast - Beyond Vibe Coding: Ja, wo würdest du sagen steht in Quasi sieb gip bei der ai oder sind wir vielleicht sogar ein bisschen spezifischer in der agentik adaption also wie Quasi wo seid ihr und natürlich in einem umkehrschluss woran macht schon das fest dass ihr da so weit seit Lukas Hejniak: Tja, das kann man tatsächlich sogar empirisch belegen. Wenn ich jetzt also quasi eine Masterarbeit mit dem Studierenden aufsetzen würde, würde ich sagen, hier, jetzt 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 so was wie vielleicht 35 bis 40 Prozent meines Erachtens nach, ja, weil wir schon sehr, sehr viel machen. Das Wahlkern 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, dort stellt man sich derzeit noch andere Fragen. Gefühlt beschäftigt man sich noch sehr, sehr stark mit der, mit den Sachen, die wir so als digitale Transformation bezachten. 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 weitergehen. Und vielleicht ist der nächste Schritt dann AI. Aber so weit sind viele noch nicht. Deshalb ich sagen würde, wenn ich das jetzt mit meinem Wissen, meinem Netzwerk vergleiche, sind wir bestimmt so drei bis fünf Jahre voran den Unternehmen. Man muss aber natürlich sagen, ein kleines Start-up 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äche 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 dann Stückchen voraus. Sebastian: Dann erzähl mal so ein bisschen, wo du sagen würdest, wo ihr gerade steht. Lukas Hejniak: Ja, habe einem der Gründer und Eigentümer Tim Mois, habe ich letztes Jahr, ich glaube November, was einen 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 diesen 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. Da geht es ja auch ⁓ das Enablen, welche Tools kann ich wie nutzen, wo darf ich was nicht reintun, wegen Datenschutz, Urheberrechte, Unternehmensdaten und so. Und ich glaube, wir haben relativ schnell die Fragen beantwortet, wo sich viele relativ langsamer auf Angeln festhalten oder aufhalten, nämlich was darf ich wann in welche KI-Tools reintun. Da waren wir relativ... Das war so binnen 1,5 Monate erledigt, weil wir selbst Anwälte beschäftigen. Und dann hat es Fahrt aufgenommen mit den Schulungen. wir hatten quasi bis Februar dieses Jahres, hatten wir 6 Kohorten durch mit fast nur Techs. ja, 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. Es nehmen aber auch schon weitere Gruppen an diesem Agents 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 bisschen weniger technisch werden, einfach breit zu fächern und das adressiert und gerecht eine breite Gruppe streuen zu können. Und da stehen wir jetzt. machen jetzt also quasi schon die letzte Iteration des Agents 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 an sich, ich das irgendwo dann mit auf dem Flurfunk, Kaffee oder beim Pairing oder irgendwie sowas, singe ich 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, letzten fünf Termine für ja, potenziell fünf Termine für Techs. 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 Prozent der Firma potenziell geschult haben. Geht natürlich nicht immer wegen Kinder krank oder wegen irgendwas anderem, aber mein persönliches Ziel wäre, bis Q3 haben wir tatsächlich alles voll geschult. Und wenn ich sage, wir haben Non-Tech geschult, dann meine ich damit, dass die quasi Prompt Engineering Techniken gelernt haben, die wissen, was in Formal Architektur ist, die wissen... wie so Tokenberechnung funktioniert, dass da nicht große Intelligenz bei ist, sondern eine Berechnung von Wahrscheinlichkeiten. Die wissen, was ein Zero-Shot, ein Few-Shot und ein Chain-of-Fault-Pompting ist. Sowas werden die alles wissen. Die Möglichkeit gibt es dazu geben in x weiteren Fortbildungen. Und da stehen wir jetzt. In den Worten des Eigentümers oder des Geschäftsführers würde es heißen, wir sind 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. HMZE Podcast - Beyond Vibe Coding: Eindruckend so ein bisschen ich habe die sorge dass wir quasi zu zeitig jetzt quasi das hauptthema abbiegen vielleicht machen wir parken wir das hier kurz Und nehmen gleich noch mal den ball auf also reden ein bisschen darüber nach dem training welche botanik sie seht wie sich der Lifeziken ist auf der wettbewerb mit lifeziken halt angepasst hat aber Wie nutzen du heute also quasi day in day out ei für für deine für deine themen bevor wir da so ein bisschen tiefer in die andere Richtung einsteigen. Lukas Hejniak: Ich bin noch nebenbei in einem Studium aktiv, dass sich da Data Science Machine Learning schimpft. Das heißt, ich mache sehr, viel so mit Machine Learning Algorithmen, wo man die anwenden kann, ⁓ mal ein konkretes Beispiel zu geben, weil bei uns geht es ja ⁓ Audio. Womit ich mich so beschäftige ist, ein LLM, ein Gen-AI-Apparat, der jetzt quasi eine Audio-Type bekommt, daraus Text macht, der kann jetzt E-Mail-Adressen. nicht gut identifizieren, weil dieses Add ist schwierig, wenn jemand Sechse spricht oder in anderen Dialekts, ist das nicht immer eindeutig, die Modelle können das nicht gut übertragen und ich mach dann so eine Art, ich komm dann mit meinem Machine Learning dahin, baue irgendwelche Experimental Use Cases, lass mir Testdaten generieren oder nehme eigene, wenn ich welche finde und hab und ja optimiere das LLM mit gewissen Metriken und versuche das dann ohne LLMs zu lösen oder Open-Way-LLMs quasi. zu trainieren, dass sie bessere Ergebnisse liefern. Das ist ein Use Case, ich mache. Aber ich programmiere ganz normal auch mit Cloud Code oder anderen Werkzeugen. Ja, 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, ⁓ an User Stories zu arbeiten im Sprint. Aber ich versuche dann quasi manchmal ein paar Tickets zu machen oder mal ein bisschen Forecast zu machen, die User Stories mit die Codebase anzuschauen, lasse mir dann über Skills oder irgendwelche Agents UML-Diagentaml zeugen, 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 einem Agentic Workflow abbilden könnte, das evaluieren könnte. ⁓ da auch KPIs dazu schreiben wegen Model Drifts und so weiter, ist das womit ich mich so beschäftige. ist also ein bunter Strauß letztendlich. Sebastian: Was ist denn da, du sprachst ja gerade von verschiedenen Tools, was ist denn da so der Haupttoolstack, den du so benutzt? Lukas Hejniak: Ja, also ich habe mal sehr, sehr viel in OpenAI Chat-GPT gemacht und da auch viel Custom Games gemacht über Assistenten 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 Closed Code und nutze aber noch für gewisse Szenarien immer noch Google Gemini, Das sind so meine Tools. Fürs Coden klar, CodeCode, da gibt es derzeit nur wenig besseres außer ich fahre lokal das Modell hoch ⁓ es zu optimieren für einen gewissen Use Case. Ansonsten benutze ich meistens CodeCode fürs reine Programmieren. Sebastian: und Gemini dann quasi einfach als LLM, also in Chatform sozusagen. Lukas Hejniak: Ja exakt, in Chatformen aber auch API und Talkants, 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 Limit Elements, ein bisschen schneller oder wenn es ⁓ 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. Sebastian: Alles klar, das wäre meine nächste Frage gewesen, also wann du welches Tool benutzt, quasi also dann im Allgemeinen für Coding Cloud Code und für Text und Research eher Gemini. Verstehe ich jetzt. Lukas Hejniak: Ja, einen Punkt muss ich da noch ergänzen. Code hat eine andere Limite, 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 Web 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 pdf rein tun 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 Wissenssynthese angeht und ich kann ja inzwischen in Gemini kann ich sogar Notebook LM hier anbinden als Wacke und dann spare ich mir sogar noch ein lokales Wacke hochzufahren und dann Which we will optimieren und so weiter, das brauch ich dann alles nicht mehr machen, das machen dann die Tools von der Stange. Sebastian: ⁓ interessant. Was wäre denn da so ein Beispiel für, wie 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? Lukas Hejniak: Ja, ich habe einen kleinen Workshop gehalten, wo es darum ging, dass wir die Kundenkommunikation irgendwie besser zusammen tragen mussten, Zusammenfassungen erstellen wollten und so ein bisschen auch ein Gesprächsleitfaden erstellen wollten. Heißt, wir haben Audionachrichten, die uns jemand auf Voice Mail 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 LLM hochgeladen, haben zum Beispiel gesagt in einem Prompt, ich generiere mir jetzt meine Zusammenfassung, generiere mir dort in Notebook LLM mal einen Podcast, weil ich gerade im Auto unterwegs bin und das nur hören kann, weil ich meine Location wechseln muss oder so und dann generiere ich mir bitte auch ein Gesprächsleitfaden, das zieht das Ding relativ gut hin und das halluciniert 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 haben wir dann noch ein bisschen was in Richtung Vergleichsanalysen mit der Konkurrenz gemacht. Das heißt, wenn wir wissen, dass der Kunde bisher woanders einen Verzag hatte oder irgendwo besonders die Inzessen liegen, dann kann man mit Gemini, wenn man dort quasi Deep Research macht mit dem Notebook LM als WAC, also 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 zu gewissen, mit gewissen Limitierungen kann ich 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 brauche ich dann, das mache ich dann in Gemini auf Basis des Wags, was ich vorher bei Notebook LLM erstellt habe. Sebastian: Okay, alles klar. heißt, du lädst da einen Haufen Dokumente rein nach Notebook LM und gehst dann aber gar nicht über Notebook LM, sondern über Gemini, sozusagen nativ, so wie du es sonst auch machst. Interessant. Okay, das habe ich tatsächlich noch gar nicht gemacht. habe Notebook LM bisher immer extra genutzt, auch eher so experimentell. Noch gar nicht so richtig die Standard-Use-Cases gefunden, aber spannend. Lukas Hejniak: Exakt. Und inzwischen kann man das auch über Google API steuern und das in Jupyter Skripte verpacken oder auch in Python Skript verpacken oder in der Programmiestrache eurer 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 für Nontix sehr, sehr gut benutzen in den Workshops. Sebastian: Ja, das glaube ich. Ja, ich meine, am Ende so wird es dann auch, wie du schon sagst, usable. Ich habe meinen eigenen, also 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, das Transkript runterzieht und dann nach einer bestimmten Formatierung sehr schön zusammenfasst und dann Referenzen rauszieht und... 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 usable. HMZE Podcast - Beyond Vibe Coding: Wie gehst du mit dieser Veränderungsgeschwindigkeit ⁓ Lukas, weil das die Beispiele gerade nennt sind, der schon würde ich sagen sophisticated, also schon das Zeug der von viel ausprobieren. Aber das ist ja quasi man könnte eigentlich den ganzen Tag ausprobieren und jederweise hat auch noch die Nacht quasi. Was ist denn so dein natürlicher Filter? Also das mache ich, das mache ich nicht oder so, ⁓ sich da nicht auch in so einem Revit hohe zu verlieren. Lukas Hejniak: Also ich muss gestehen, inzwischen plane ich einige Tests 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 Schlafen gehen ansteuere und morgens sich die Metiken habe. Das muss ich ganz ehrlich sagen. Ansonsten wäre das gar nicht möglich, so ganz hartes Machine Learning zu evaluieren und proben. Ich versuche, dass alles andere immer relativ nah an meinen praktischen Tätigkeiten zu sehen. Deswegen fällt es mir nicht schwer, quasi dieses Ändertumstempo mitzugehen, weil immer wenn ich was quasi per Hand gemacht habe, vor allem wenn es mich genervt hat, frage ich mich, kann das ein 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, schreibe dann meine Prompts noch nicht einmal selbst, sondern nutze das halt irgendwie anderweitig, lasse ich das herstellen. dann weiß ich, das ist ein Roll-Prompt, das ist ein Systemprompt, 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 so. das ist für mich inzwischen ganz normal, so zu arbeiten. ich komme natürlich in meinem Job auch in Berührung mit viel, viel Ablehnung und Vorsicht. Und ich kann euch sagen, dass so 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 enablen kann, etwas zu erreichen. Bei mir ist es ganz klar ein Zeit... HMZE Podcast - Beyond Vibe Coding: Hm. Lukas Hejniak: Vorsprung, wenn ich ein Projekt habe, wo ich eine Deadline erreichen will, was schneller haben will, weil ich potenziell auch zu den ungeduldigeren Typen gehöre, dann hilft mir KI das erstmal Prototypen auf die Straße zu bringen und dann kann ich ja weiter darauf hiniterlichen. Ich habe da also nicht so einen Expertentumanspruch. Aber wenn jetzt jemand 20 Jahre lang oder 15 oder 10 irgendwie maximal Wissen in Java aufgebaut hat und der super Spring Boot Experte ist, von mir ist auch weiß ich nicht, Astros 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, da auf die Leute zukommt und das muss man begleiten. Das muss man ganz klar begleiten. Was ich so mit bekomme ist, dass dieses Ändertungstempo, was man verlangt, nicht nur bei SIPGIT, sondern allgemein, so das, was mir in meinem Netzwerk begegnet, Das ist immens hoch, das ist noch viel höher als wir angefangen haben darüber zu sprechen, ey wir müssen jetzt agile Arbeitweise einführen. Jetzt ist irgendwie erproben maximal, bis zum geht nicht mehr und das fällt den Leuten schwer. Und ich glaube diese Anforderungen an die Leute, 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 anderen machen das schon, das ist das es schwer macht. hättest KI durch einen anderen Begriff ersetzen können. hättest da auch weisig nicht irgendwas anderes hinschreiben können. Aber sobald du eine radikale Änderung anstößt, kriegst du Widerstand. Und das betrifft jetzt natürlich KI sehr stark. Und 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 man über Schmerzen bei Veränderung spricht. HMZE Podcast - Beyond Vibe Coding: wollen wir ein bisschen stärker noch mal auf sieb geht gehen Sebastian: See you HMZE Podcast - Beyond Vibe Coding: Ich meine, wir machen das ja auch ein bisschen als Selbsthilfegruppe hier, Lukas. Insofern, äh, quasi wir sind da, sowohl Sebastian als ich, sind ja quasi auch in unseren Jobs quasi mit dem Thema da tagtäglich konfrontiert. Ich hab jetzt so eine ganze Liste an Fragen. Ich fang mal an. Wie mäßt ihr für euch so die Transformation? Eine Sache natürlich, 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 life cycle halt irgendwie verändert also quasi dieser dieser inner loop quasi wird weitestgehend automatisiert quasi arbeit findet er also bei dem themen requirements engineering und so statt quasi wie wie wie mästen das für euch wo ihr da als firma steht Lukas Hejniak: Ja, 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 Studien, die empfehlen dir das. Dann hat es einfach 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, so was wie Tokenverbrauch. sowas wie wie viele tools nutzen wer wie ist die aktivität da drin das alles kannst du messen ja es gibt natürlich auch noch fragwürdige kpi ist wie falls es überhaupt noch kpi ist wie ich kann mir sogar den inhalt der der prompt angucken die die user angeben das machen wir jetzt nicht aber theoretisch gibt es ja eine ganz bunte breite palette wenn du mich fragst wie messe ich denn jetzt im vorschritt ganz klar ist denn jetzt die Anzahl der Leute, an dem Workshop teilgenommen haben. Vor allem, was mir aber viel wichtiger ist, und das ist so ein bisschen der Berufsbüroge in mir, ich versuche die Workshops zu evaluieren. Das heißt, ich bitte Leute, die daran teilgenommen haben, erstmal via internem Kommunikationstools 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 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ößeres Lots aufhängen mit Gruppen diskutieren. so gehe ich vor und stelle fest, aha, 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 in Hand der, sagen wir mal, der Team, die die Leute im Slack bewegt und die sie kommunizieren, kannst du natürlich auch so eine Aufschwung. kommunizieren. haben irgendwann in der dritten Runde, der dritten Kohorte des Agents Software Engineering Workshops, kamen dann Skills raus. Wir haben das dann eingebaut in die Workshops und immer mehr Skills entstehen. Immer mehr Leute diskutieren über Skills, immer mehr Leute bauen Chatbots, also eine Art Slackbot in die Teamchannel rein, die du nach Sachen fragen kannst, wo du vorher immer ein Meeting potenziell gemacht hättest oder gewartet hättest, bis jemand Zeit hat, ⁓ mal eben im Büro mit Leuten zu sprechen. So kannst du auch Fortschritt messen. Es gibt also nicht das eine einzige Konstrukt namens KPI, das du zur Messung hinzunehmen kannst. Du kannst aber durchaus Zahlen erheben, die dir eine gewisse Tendenz andeuten. Sebastian: ist ja am ende worum es geht das outcome also die skills die slackbots also das was was entsteht dadurch dass leute jetzt befähigt sind von daher sind es schon sicherlich die 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äre jeder 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 gibt es Standard-Subscriptions, die benutzt Lukas Hejniak: Also im Slack kam mal eine Nachricht von einem Kollegen, wo drin stand, ey Leute, wir müssen Tokens verbrennen. Wir wollen dieses, dieses, dieses, dieses, Award haben, der dann kommt, wenn wir einen Platinistatus vielleicht haben, ü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. irgendeinen Nonsens, irgendeine Katzenvideogenerierung oder so, da muss man mal früher oder später drüber sprechen, aber ansonsten sind wir alle angehalten uns 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 danach Chat-GPT, dann Go for it! sind wir auch sehr stark angeraten. das in 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 GentiCore Close ausprobieren, wir wollen das Lengen-Chain ausprobieren, wir wollen irgendwelche komplexeren Dinge bauen, weil es einfach an unserer Natur als Software-Entwickler liegt und es gibt diese finanzielle Grenze nicht. Wir alle haben irgendwie große Anthropic-Enterprise, Google-Enterprise-Versäge am Laufen. Und jeder, ich glaube es ist der Codecode Max Plan, jeder Def hat, er will. Aber inzwischen hat es glaube ich auch fast jeder PM. Weil die PMs ja jetzt auch durch diese Agenti-Coding-Schulungen gehen. Go for it! Niemand wird wahrscheinlich, also ich würde mich sehr sehr wundern, wenn jemand irgendwo hingeht und sagt, ey du darfst jetzt Tulex, YZ nicht benutzen, weil es zu teuer. Es könnte sein, dass jemand hingeht und sagt, wir dürfen das Tule 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... HMZE Podcast - Beyond Vibe Coding: Ich versuch nochmal den die die kurve zu meiner frage vorher die jetzt Quasi habt ihr habt ihr aber als firma für euch definiert wo was zu eurer zielzustand sein soll also wo ihr hin wollt also warum ihr das alles macht und Dagegen könnte man ja dann messen also ich aber ich kann noch mal aus einer anderen richtung fragen vielleicht kann es in zwischenzeit kann es so ein bisschen quasi im hinterkopf schon mal quasi Prozessen lassen Man, könnte ja auch so mit schuld die modelle halt irgendwie nehmen bin ich normalerweise ein fan von also quasi so meta ebene dann halt quasi was nicht vier fünf levels und dann halt irgendwie eine passende definition ich habe noch nichts in dem umfeld gefunden also es gibt glaube ganz gute ei mit schuld die model Für. So agentik ei war ich bis jetzt noch nichts gefunden deswegen war ich ein bisschen gespannt oder weil du gerade auch meintest von ihr seid so weit Und ich glaube auch das was du erzählst das 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 wo ich es messen kann also all diese aspekte habt ihr da doch vielleicht irgendwas Lukas Hejniak: Ich persönlich habe nichts außer dem MIT Slogan AI Maturity Model. Ich habe also nichts für das Agentic 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 und das könnt ihr euch so vorstellen wie Telekommunikation wird sich ändern, ganz klar. Wir telefonieren nicht mehr so früher, Admetisstelefone, Leute schreiben, schicken Audios via WhatsApp und gleichzeitig drücken da Start-ups quasi von unten mit neuen Features. Es gibt ja so Fonio, Hallo Petra oder wie sie auch immer heißen, über die sprachen wir ja vor x Jahren noch nicht. Das heißt, Markt wird, der Kuchen vom Markt wird vielleicht ein bisschen kleiner und diese Start-ups, nutzen halt oft Agentec-Mittel, ⁓ natürlich Kosten zu sparen, ⁓ Effizienz. zu erzeugen. Also müssen wir ja irgendwas tun, ⁓ uns in eine Lage zu versetzen, ein bisschen performanter und schneller zu sein. Wie so in Richtung Start-ups. Über all dem, was wir tun, steckt also sicherlich irgendwo der Gedanke, AI kann uns was abnehmen, was uns effizienter macht. Und 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, ist das Ziel, alle dahin, Ziel ist, weiß ich nicht. Wir brauchen unbedingt alle 50 Prozent Abdeckung, Agentikmittel, ⁓ 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 Agenti-Coding denn jetzt für mich? Es gibt also nicht das Ziel, wenn wir Agenti-Coding machen, heißt das, wir müssen 80 % der Tests selber generieren. So, ver-eigenlieren lassen. Sowas 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-Meteroity-Model zu drücken, denn alle sind so 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 beantworten. Sebastian: ist ja am Ende auch das, worum es geht, dass man auf Outcome optimiert und nicht für eine Matrix sozusagen wie ein Proxy darstellt. ⁓ zu gucken, ja, wie viel KI schon benutzt wurde oder Agendic Use Cases, sondern das man auf Outcome optimiert. Und da ist ganz klar natürlich der Innovationsdruck oder die Innovation an sich, Kerntreiber und Motivation. Von daher macht es schon Sinn und ich verstehe auch, was ich bisher von der Siebgate Kultur verstanden habe, so dass es eine Ene Kultur ist, 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 Geldung kommen und sich entfalten können, ⁓ halt Innovation auch in 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 Zipgate offenbar auch relativ weit gebracht hat bisher. ⁓ von daher macht es schon durchaus Sinn, so zu sehen. Ich glaube, ist natürlich, also bei Zipcade, wo ihr sehr viel in diese Kultur investiert habt, auch das wieder über die Schulungen sehr, sehr breit streut, das geht ihr wieder relativ gut an und relativ strukturiert. Ich glaube, bei größeren Unternehmen ist es wahrscheinlich nicht ganz so leicht, eine homogene Kultur zu gewährleisten, dauerhaft. Und da gibt es dann ebenso Maturity-Modelle. Da hat auch wieder die Laura Tacho Pragmatic Engineer Summit, die hat da so Talk gehalten, die hat ein Modell auch präsentiert, was sie nutzt, was so drei Kernaspekte ⁓ sich anguckt, das eine ist Utilisation, also wie viel wird es genutzt, AI Tool Usage, Percentage of PRs, are AI Assisted, Task 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, AI Spend, Time Gain per Developer und sowas. Und sie hat da noch einen ganz lustigen Satz, lustig oder traurig, je nachdem, wie man nimmt, gesagt. Und zwar in vielen auch großen Tech-Organisationen gab es ja immer die Diskussion Developer Experience, ne? Also das 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ähneknöchelnd 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, ⁓ ja, Agents, genau, die bringen uns nach vorne, klar, nehmt was ihr wollt, wir investieren. Das fand ich lustig, aber gleichzeitig irgendwie auch traurige Aussagen. Lukas Hejniak: Vielleicht ein spannender Inside, wozu unser Vorgehen jetzt zuletzt geführt hat, was ich so an die Kaffeemaschine besprochen habe mit anderen. Dadurch, dass wir ja breit gefächert sind und vor allem auch die Probung 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 hier mit einem Agent auf Basis von Baselines, der ja zufälligerweise auch noch in Code gucken kann, sehr guten Epic runterschneiden in Stories und schippbare Incremente 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 so? Und wir haben da einige, die sind da schon sehr, sehr fortschrittlich, würde ich sagen. Auch für SIP-Geld-Verhältnisse sehr, fortschrittlich. Und einige Teams, die sind da noch in der Erprobungsphase oder versuchen gerade erst Fahrt aufzunehmen. Das passiert auch bei uns. HMZE Podcast - Beyond Vibe Coding: Super spannend da wollte ich auch noch so ein bisschen in die richtung mal rein weitergehen was sind die veränderungen die also offenheit non individual level quasi gesehen habt also du hast ja gerade schon gesagt ne teamkomposition prozesse kannst du da irgendwas schon kannst du da teil also teilen was sie schon alles hinter euch habt was sie schon alles erlebt habt Lukas Hejniak: ganz viel Diskussion haben wir hinter uns. Aber das ist a never ending story und das ist auch gut, dass es so ist. Man muss drüber sprechen, weil einige, ⁓ da den Kreis zu schließen, tun sich schwer, drücken da so ein bisschen der Schuh, ganz klar. Die muss man auch unterstützen und einige nehmen voll Fahrt auf. Und dann gibt es noch die ganz verrückten wie mich, die wollen ganz tief gucken, was ist denn jetzt so ein stochastisches, gradierende Absiegsverfahren und lernen das dann auswendig. HMZE Podcast - Beyond Vibe Coding: Okay, das ist gut. Lukas Hejniak: 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. könnt 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 Story zu machen, weil das kann ja jemand auch machen mit einer KI. Wir haben Daten von Kunden, haben Kundenfeedbacks, das kann man ja alles irgendwie analysieren lassen. Das müsste jetzt eigentlich vorher passieren. Während wir vorher also noch so Personen hatten, denizierte Personen, die irgendwie die Strategie gebaut haben, dann diese Strategiemenschen haben dann potentiell auch schon erste Ethnics gebaut. Oder sind in Meetings gegangen mit POs oder PMs oder was auch, wem auch immer. Und haben dann erste User Stories gemacht. Guck, wie sind denn die Leute verfügbar, um dann Termin zu machen, erste Schätzung zu machen. Das geht ja jetzt viel schneller. kann, LLM kann ich oder AI kann ich einem Baseline beibringen. Die kann den Code gucken. Das geht potentiell als eine Person, ja. Und deswegen stellt man sich die Frage. Es ist jetzt ein 3-Person-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, diese Formulierung der Strategie und diese Kundenniet und Anforderungen sehr präzise machen in Requirements. 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 eine LLM auch in Code gucken lässt und man gemeinsam Baselines definiert und dann trennen sich die Wege und jeder geht so, jeder nimmt so seine User-Story, geht dann ins Back-Driven-Development, also Agentic Software Engineering und baut dann die Story für sich selbst und am Ende trifft man sich und guckt, 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. Da so ein Dialtlan in so einem Telefonieserver, das Ding hat das noch kaum gesehen, So ein LLM ist nicht ziniert auf irgendwelche Dialpläne oder Kamalio Code 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, musst du das löschen, lass uns das lieber im Pfeifen machen, weil es viel cooler ist. funktioniert natürlich nicht. Im Umkehrschluss müssten diese Teams dann natürlich vielleicht ein bisschen mehr lernen, wie man da so ein Werk aufbaut, ein bisschen mehr Kontext füllt, das Ding irgendwie optimiert und so. Solche zwei großen Bewegungen haben wir, deshalb ist es auch schwerer, Zahlen dann zu schreiben. HMZE Podcast - Beyond Vibe Coding: Ja, krasses Spannungsfeld auf alle Fälle. Sebastian: Ja, ich wollte gerade auch so was ähnliches sagen wie du mit Rack aufbauen und so. Also eigentlich ist es ja dann wieder Kontext Engineering, denn ich mache gerade in einem Fall, also bei uns, 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 Speck für das Format hat und das LLM damit füttert, geht es auch wieder. Also das ist Genau, da geht es wirklich ums Kontext 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. Dann kann man noch Web Search dazu geben und sagen, hier recherchier doch mal. Oder wenn es ganz schlimm kommt, dann gibt man direkt einen linken Speck oder irgendwas dazu. Und damit kommt man tatsächlich auch relativ weit. gestern hatte ich auch den Fall, haben wir mal für unsere wirklich große Legacy-SARS-Applikation, die definitiv größer ist, als dass alles ins Kontext-Window passen würde. Da haben wir mal so ein komplexes Feature durchgeplant. Da habe ich einfach PM und... Head-of-Software-Engineering mal zusammengenommen und den Plan wurde angeschmissen. Nach 20 Minuten war das Feature komplett durchdefiniert. dann aber auch bis zu einem Punkt, wo man sagen würde, das sind eigentlich keine User-Stories mehr, sondern 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 das Requirements-Engineering sozusagen, die haben wir beantwortet. Dann wir uns das Ergebnis angeguckt, haben dann noch eine Stelle vergessen, wo es noch nicht ganz optimal den Punkt gefunden hat, wo man noch mal was re-usen konnte, also nach unserem zu dritt sozusagen, Gusto und haben das nochmal gesteuert in die Richtung und danach war es eine Spec, wo wir alle drei gesagt haben, genau so würde man es machen. Das war schon echt beeindruckend. Lukas Hejniak: eine spontane Impuls, den ich auch öfter mal bei unseren Kaffeemaschinen lasse. Das ist ein Satz, der brennt sich bei den meisten ein und entweder wollen sie damit immer weiter diskutieren oder jagen mich weg von der Kaffeemaschine und ich sag 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 zu zuordnen sind, auch manchmal so schwierig, ja. Aber alles, was ein 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, potentiell Sachen per Hand. mehrfach machen müssen. Das geht nicht immer, das hat natürlich Limitierungen, aber das ist erstmal mein Ansatz. Und ⁓ auf deine Frage nochmal zurückzukommen, dem Software Development Lifecycle, ich muss das auch schon ein bisschen bei mir Revue passieren lassen. Ich glaube, sind, also 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, wau, das ist jetzt mal offen, ich nicht, das ist so ein Grafikpattern um oder ein Observerpattern oder irgendwie sowas, das muss ich nicht mehr per Hand machen. Und wir werden uns viel stärker um das Requirements, 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 Arbeitweise im Team erst kennenlernen. Nur hatten wir bisher nie so delizierte Tester. Das war immer Aufgabe der Softwareentwicklung der Menschen bei uns, weil you code it, you wanted, you own it und so weiter. Typisch agiler Ansatz. Aber Unternehmen, die Tester haben, was machen die denn jetzt, wenn die so unterwegs sind wie wir? Der Job ist auch quasi potentiell 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 Systemtests habe. die in meinen Kontext passen, kann ich die auch superschneller weg automatisieren. Wenn ich weiß, wie ich den Kontext ein bisschen optimieren kann, kann ich auch größere Systeme weg automatisieren. Dann gucke ich mir den CodeCardboardReport, vertraue darauf, so wie ich es früher auch gemacht habe und setz it. Das ist so das, wo es sich meiner Meinung nach hinbewegen wird und das alles führt letztlich dazu. Ich weiß nicht, ob bei diesem Punkt... ansprechen wollte, der war auch bei dem letzten Kollegen mit dem Moldbot Meetup in München Thema die Werteverschiebung in der Softwareentwicklung. Das wird passieren. HMZE Podcast - Beyond Vibe Coding: Schießt los Schießt mal los werte werte werte in werte entwicklung in der software entwicklung die werte verschiebung in der software entwicklung Ja werte verschiebung so jetzt welche werte welche verschiebung Sebastian: Verschiebung. Lukas Hejniak: Verschiebung. Ja, ist ein riesiges Thema, ne? Wenn man, also eingangs hatte ich ja gesagt, ich habe so bisschen Unternehmensorg-Entwicklung gemacht und so mit dem internen Lehrstuhl und Leute nachschieben und so weiter, ne? High Potentials finden, Fachkräfte mangeln, entgegenwirken und so. Wenn man mal überlegt, dass wir jahrzehntelang Organisation und Organisationsstrukturen, die wir als Teams meistens bezeichnen, ⁓ quasi das teuerste Gut, nämlich software entwickelnde Menschen, die Quelltex erzeugt haben. gebaut haben, ja, oder halt, wenn du nicht bis zum Qualtex gegangen bist, hast du das gleiche auf Designlevel gemacht, ja, 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 Qualtex durch KI erzeugt, potentiell viel geringer ist, denn ich kann ja in großer Menge ausprobieren und neuen Code erzeugen lassen, ob der qualitativ genug ist. möchte ich jetzt noch nicht verantworten, wahrscheinlich wird das nicht sein, aber potentiell habe ich ja erstmal die Möglichkeit, ja, viel schneller das, wir früher eigentlich, wo wir Prozesse hin optimiert haben, dieses shippable Increment, was am Ende von Scrum rausfällt, kann ich viel schneller erzeugen, was eigentlich Schlussfolgern bedeutet, ich muss irgendwie diese Wertverschiebung auffangen und irgendwas anders machen in meiner Unternehmensorgane. HMZE Podcast - Beyond Vibe Coding: Definitiv also das ist ein fundamentaler change sicherlich sicherlich und genauso quasi heften sich dann die themen bild oder bei dran Aber ist genau das gleiche ja ja ja ja ja Lukas Hejniak: Ja. Und das kann man weiter spinnen, ne? Jetzt stellt euch vor, ihr seid eine SaaS-Company und euer größtes Produkt oder euer größter Cashflow war die Erzeugung von Quelltix. Scheiße Zeit. Sebastian: 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 SAS. Also wenn du ein System auf 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 wie auch immer geartetes Tool kauft, sondern auch die Sicherheit, dass die Daten definitiv nicht verschwinden, dass es 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 vibe coden 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 10 oder 50 Integration haben, die man ⁓ nicht braucht, die auch nur intern genutzt werden, wo man also nicht irgendwie spezielle Security oder sogar Reliability oder Scalability Anforderungen hat, weil es nur drei interne Nutzer gibt. Das sind natürlich super Beispiele für Schneller Vibegecoded. HMZE Podcast - Beyond Vibe Coding: 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, ganz nett. Ich glaube nicht. quasi. Not proved ja 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 noch mal so zum abschluss lukas du hast ja vor noch gesagt du bist so ein new work veteran so müssen wir das hier notiert hast du eine idee wie diese agentik software development Wie man es auch immer nennen will, quasi was das mit Arbeitsmethod macht. Lukas Hejniak: Ja, ganz schwierige Nummer. Erstmal tief durchatmen. Denn tatsächlich glaube ich, neben der Veränderung von unserer Domine, Softwareentwicklung, sage ich mal, dass natürlich Ausprägungen haben wird auf das, was die Pädagogen als lebenslanges Lernen bezeichnen. Wenn ihr mal überlegt, was wir alles gelernt haben im Rahmen unseres unseres Arbeitslebens und dazu gehört es definitiv mal Fehler zu machen. Und ich vermute auch die Hürder 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 aufzustellen und das gleiche. So wie wir beim Fahrrad fahren, hinfallen und dann haben wir 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, 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 ⁓ Hilfe bei anderen bitten, die das vielleicht schon mal durchlebt haben. Und dann nehme ich gemeinsam einen Weg finden. Das ist also irgendwie so ein dreistufiges Ding. Erst mal 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, schnell. wenn ich irgendwie mal eine Woche lang irgendwie so ein großes Projekt mal gecoded hab, wie dieses Kafka Ding, dieses verteilte System, dem ich weiterentwickeln wollte. Ich hab da was auf die Straße bekommen. ist auch mit KPIs, nicht KPIs, sondern mit Ansätzen wie Clean Code, Clean Architecture und so weiter. Hab ich die KI gefüttert, hat mir super was gebaut, ja. Aber ich erinnere mich heute nur noch bedingt, was ich eigentlich so gemacht hab, weil es einfach zu viel war, in einem viel zu hohen Tempo. Ich konnte mir das also nicht mehr merken. Wenn früher die Ausnahme dazu natürlich viel tiefer ging, man hat so bisschen auch Deep Work gebraucht und das wird irgendwann fehlen. HMZE Podcast - Beyond Vibe Coding: Die tatsache dass du eben nicht mehr alles wissen musst weil du jemanden co-pilot neben dir hast ja halt gefühlt erst mal alles weiß oder zumindest aus unserer sicht alles weiß ne gut enough ist brauchst du halt brauchst du das halt nicht mehr Lukas Hejniak: Und ich muss ganz ehrlich sagen, das macht mir stellenweise auch Angst. so aus mit der Brille des Hochschullehrenden, das macht auch den jüngeren Generationen in Studium Angst derzeit. Beziehungsweise Angst ist so ein hartes Wort, beschäftigt die schon sehr, hart. HMZE Podcast - Beyond Vibe Coding: 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. Und wie bei jeder größeren Transformation oder Disruption, quasi fallen halt Jobs weg, neue entstehen. Und wir wissen noch nicht, quasi haben wir eine Vermutung, was vielleicht wegfällt, aber wir wissen noch nicht, was entsteht. Und das ist Das ist wahrscheinlich diese Unsicherheit, die da gerade herrscht. Sebastian: Amen. Lukas Hejniak: Was vielleicht auch passieren könnte ist, so Sachen wie Squam, was wir jahrzehntelang erlernt haben, geht jetzt vielleicht tatsächlich wieder in so eine Art Rapid-Portotyping oder Extreme-Programming zurück, weil halt einfach die Entwicklung der Prototypen schneller wird. Und ob man das gut findet oder nicht, ja, ist wahrscheinlich sogar potenziell, wenn man so die Hardfacts 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 hier 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, also die Erzeugung von Code ist nicht mehr so teuer. Vielleicht geht es dahin, ja, 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. Sebastian: Ich würde sagen, wir sollten langsam mal zum Ende der Episode kommen. Wir haben ja ganz am Schluss noch zwei so kleine recurring Segmente. Das erste ist der Reality Check. Da gibt es immer so zwei Fragen. Welches Tool hat dir kürzlich einen What the fuck Moment erzeugt? Was ist für dich aktuell der heißeste Shit sozusagen? Lukas Hejniak: Ich bin stellenweise in der Wissenschaft aktiv und ich muss sagen, es gibt da potentiell Toolings, wie sowas wie Semantik Scholler. Das ist meines Wissens nach so einer 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 hingesetzt und dann wirklich die ganzen Genres durchgesucht. Das Ding macht quasi per Fingerschnipp, findet das, abstracts, es 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 in 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 drei 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, wenn wir vorher nur eins machen konnten. Und das ist mit so Tools wie Semantik Scholler möglich. Und das war so mein Aha-Moment. Den nutze 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 zur 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 Start-up, dass den Quantencomputer für zu Hause anbieten wird. Für viel Geld, aber durchaus im Bereich eines Kleinwagens. Also die ganz nördigen und freaky Leute werden sich den Quantencomputer statt einer Wärmepumpe 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. Will ich jetzt so mathematisch alles alles können wir mit Quantencomputer noch nicht machen, da müssen die Forscher noch ein bisschen aktiv werden, aber stellt euch vor anstelle von irgendwie zehn Stunden Wartezeit bis so ein Machine Learning durchgelaufen ist, kann ich mit QML, 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 AH-Momente mich so ein bisschen enttäuscht hat, war Bildgenerierung mit LLMs. ⁓ Ja, 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 Blended 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. HMZE Podcast - Beyond Vibe Coding: Mhm. Lukas Hejniak: haben für mich in der 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 hab's erwartet, so richtig schlecht kam das bei mir nicht rüber. Ich will einfach Fan, ja? Ich probier gerne aus, ich wandel gerne, ich geh gerne nach vorne. Ich guck aber auch gerne viel viel tiefer in die Mathematik dahinter und die Frameworks. Das bin ich so, deswegen waren das so meine Momente. Sebastian: 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? Lukas Hejniak: Ja, ich glaube es war ganz deutlich das QML, also quantum machine learning kommen wird. Früher oder später, da steht sehr viel Geld hinter, da wird wirklich richtig viel Geld eingebuttert. Ich hoffe, und das würde ich mir so eher als Wunschprediction äußern, ich hoffe Hochschullehrer, auch Schule, demt sich KI ein bisschen an. Es muss nicht in absolutem Fanboy-Tum ausarten. Aber irgendwas muss für die nächsten Generationen passieren und da meine ich nicht ein Wetterseinstudium, 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 sich nicht hinsetzen können und wollen, sehr schwierig haben. Und ich hoffe aus meiner Wunschprediction wird irgendwann mal Zukunft. Sebastian: Vielen Dank dir. Dann haben wir's. Lukas Hejniak: Danke euch! Sebastian: Herzlich willkommen zur neunten Folge unserer neuen Staffel von AMSZ Ehebiont Vibe Coding. Der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten. Ich bin Sebastian Heidemeyer zu erbem CTO bei NorthIO. HMZE Podcast - Beyond Vibe Coding: und ich bin Andre Neubauer CDPO 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 ein oder anderen Begriff sein. Das ist eine Firma, die für ihre progressive Kultur und Innovation bekannt ist. dann macht es natürlich auch total Sinn, dass Zipgate sich relativ früh schon mit dem Thema AI auseinandergesetzt hat. Sebastian: 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!