Hallo und willkommen zu Folge 66 von Tilpott. Hallo Dirk. Hallo nach Kastrop-Rauxel. Hallo nach Grüt. Ja, genau. Du hast mich jetzt völlig unvorbereitet getroffen. Ich habe mich gerade noch auf Rekord gedrückt und schon geht es los. Unglaublich. Und du hast mir noch gar nicht die Frage nach dem Wetter gestellt. Nee, bei uns ist Scheißwetter. Puh. Ja, hier ist auch nicht. Tja. Puh. hast du eigentlich gesehen, dass in Chemnitz am kommenden Wochenende um die 0 Grad sein soll? Spinnen die eigentlich? Genau. Wir nehmen gerade am 23. November auf, den Montag. Wir treffen uns in ein paar Tagen live und in Farbe. Also zumindest ich bin in Farbe. Ich bin nur live. Und in Stereo vielleicht noch. So ein großes Doppelkin habe ich dann auch nicht. Genau, weil wenn die Folge raus ist, dann werden wir uns schon gesehen haben bei den Chemnitzer Linux Tagen. Das heißt ein ein ein darüber sprechen wir dann in der Folge für den Mai. Genau, wir können die Rückblick den Rückblick auf die Chemnitzer Linux Tage halt erst einen Monat später bringen. Genau. So, was gibt es denn Neues aus der aus unserer Chat-Community? Also erstmal ist es unfassbar, was da an Chat läuft. Und mittlerweile glaube ich ja, das ist ein Hauseigentümer-Chat geworden, weil sich viele Leute da über Heizungen austauschen, was so die optimalen Einstellungen sind. Aber ich finde das eigentlich ganz toll. Also ich glaube, unser Chat ist zum echten Stammtisch geworden. Und allerdings mit einem kleinen Unterschied, da kommen manchmal auch echt coole Inhalte rüber. Nur nicht von uns. Natürlich nicht von uns. Wir haben schon den Namen gestiftet, das muss reichen für den Chat. Genau, und wir hatten einige sehr interessante Tipps zur Selbstorganisation im Matrix-Chat. Wenn ihr die finden wollt, dann müsst ihr wahrscheinlich so um die tausend Einträge zurückscrollen. Das ist relativ heftig, was da momentan im Raum abgeht. Genau, so viel dazu. Ich glaube, sonst haben wir gar nicht so viel im Vorgeplänkel dieses Mal, oder? Nö, nö. Aber was wir schon ganz lange nicht mehr hatten, ist ein Buchupdate. Nein! Doch! Nein, ich sag kein Oh. Und zwar Buchupdate Nummer 32. Es wird wieder Zeit für ein Buchupdate. Findest du nicht, Dirk? Ja, ich finde nicht. Ich weiß gar nicht, warum. Ja. Wir können ja jetzt gemeinsame Buchupdates machen. Ach, genau. Ja, warum hast du kein Buchupdate? Weil ich da nicht so hinterher bin mit 32 Buchabdeuts bin ich da bekloppt du bist bekloppt genug. Dass du mit mir einen Podcast machst und. Umgekehrt ja genau wenn es irgendwann mal ein Untersuchung meiner geistigen Gesundheit gibt, dann wird das wahrscheinlich negativ zu Buchschlagen, dass wir beide einen Podcast zusammen machen. Genau. Aber zum Thema. Vor zwei Jahren, nämlich Ende März, Mitte März 2024, kam mir mein DevOps-Buch raus. Und jetzt wird es langsam Zeit für die zweite Auflage. Es sind schon ein paar, ich glaube, 2500 Stück, glaube ich, verkauft worden. Sowohl Print als auch gedruckte. Und als auch E-Book mal, das zu sagen Print. Also gedruckte, genau. Dafür zur geistigen. Verwirrung, das wird. Ein lustiger Abend. Und jetzt bin ich halt gerade am überlegen, was kann soll, muss in die zweite Auflage rein, also das ist noch nicht fachlich durch, also das muss noch durch, muss noch genehmigt werden vom Verlag, aber das sieht erstmal gut aus da habe ich halt so ein paar Themen die ich halt überarbeiten will. Einmal bei so Kleinigkeiten, auf die gehe ich jetzt erstmal nicht rein. Was ich aber ganz cool fände ist, und da brauche ich die Hilfe unserer Hörerschaft. Also, wenn es klappt, hoffentlich. Und zwar würde ich gerne in das Buch aus deutschen Firmen, also Firmen aus dem Dachraum, Deutschland, Österreich, Schweiz Raum, da würde ich gerne ein bisschen Präsenzbuche einräumen. Im Sinne von, naja, ich würde halt gerne wissen, so wie wurden einzelne oder ganze DevOps-Prinzipien umgesetzt. Was gibt es da, was machen einige Firmen, was gab es für Probleme, wie kann man da weitermachen und so weiter. Also was hat gut funktioniert, was hat nicht so gut funktioniert und so weiter, weil ich rede halt sehr viel, sehr trocken, also mehr oder weniger trocken darüber. Aber spannender ist es eigentlich halt mal so zu sehen, okay, wie ist das jetzt bei einer großen Firma, wie ist das vielleicht bei einer kleineren Firma oder bei einer mittelständischen Unternehmen. Und bei neuen Firmen und alten Firmen ist ja nochmal was anderes, als wenn du auf einer grünen Wiese anfängst und so weiter. Deswegen wird es eh, wenn das klappt und ich hier rüber und halt durch Kontakte, die ich eh schon habe, Firmen finde, die da was machen wollen, dann wird es eh wahrscheinlich eher so ein kleiner Ausschnitt sein, für was man betrachtet. Das können so Sachen sein wie, okay, wir machen jetzt blameless postmortems oder wie gehen Firmen an, wie das Share-on von Learnings aus bestimmten Sachen dann halt teamübergreifend auch umzusetzen oder wie ist der Weg zum echten kontinuiersten Delivery passiert, sowohl technisch als auch menschlich. und das fände ich halt super spannend, dann halt auch mal so direkt zu sehen aus den deutschen Firmen oder aus dem deutschsprachigen Raum, weil man kennt das halt sehr, sehr viele Story von ja, ja, Amazon macht dies, Netflix macht jenes, Google macht das, zigtausende Deployments pro Minute, pro Stunde und von deutschen Firmen hört man leider nicht so viel. Mich würde auch noch eine andere Sache interessieren, zum Beispiel arbeitet ihr agil oder seid ihr nur agil angemalt? Weil viele der Firmen, die sich Agile nennen, die ich kennengelernt habe, die sind nur Agile angemalt. Die nehmen die Zeremonien mit und sind aber eigentlich Mini-Wasserfall-Firmen. Ja, ich nenne das auch immer Agilen Wasserfall. Agiler Wasserfall, ja. Ich habe jetzt neulich wieder von einer Firma gehört, die auch Agile nach Safe geht und dann aber trotz alledem zu Beginn eines PIs alle Storys für das komplette PI schon haben will. Weil der Auftraggeber das möchte. Das ist natürlich nicht so sehr agil. Aber eine wichtige Information noch, um nicht zu vergessen, wenn ihr dem Suji was verschickt, dann sagt ihm auch, ob er den Firmennamen verwenden darf. Genau, das will ich schon haben. Also wenn, dann wird das wahrscheinlich eh ein Hin und Her sein oder eine Art Calls oder sowas geben, damit das Sinn macht, damit man auch richtig den Fokus drauf setzt, weil alles als Ganzes ist halt schwierig, wie gesagt, aber spannender ist halt eher, wenn man da die ein oder andere Story dann halt hat. Und da hätte ich halt gerne größere Firmen, mittlere als auch kleinere Firmen, um da ein bisschen Abwechslung auch reinzubekommen. Ich weiß halt noch gar nicht, also ich mache das auch abhängig davon, was so Firmen ich bekomme und was für Storys das sind, weil ich will jetzt auch nicht die gleiche Story von fünf verschiedenen Firmen haben, das macht dann auch keinen Sinn. Ich weiß auch nicht, wie viele reichen, weil man will ja auch nicht das ganze Buch damit voll haben. Und die sollten ja auch knapp nicht zu viel Inhalt sein, quasi. Also die einzelne Story, weil sonst sprengt das auch wieder den Rahmen. Mache ich echt davon abhängig, was da rumkommt. Für den Vortrag, den ich ja, wenn diese Episode draußen ist, gehalten haben werde, habe ich ja auch Autoren und Verlage gefragt, einen Fragenkatalog geschickt, was sie mir beantworten wollten. Ich benutze die auch nicht eins zu eins, sondern ich streue dann halt Zitate aus dem, was ich da bekommen habe, ein. Einfach. Und sage dann bestimmte Autoren was Bestimmtes gesagt haben. Oder wie die beiden Verlage, die geantwortet haben, dazu stehen solche Sachen. Ja. Genau. Von daher, ich würde mich freuen, wenn sich jemand bei mir meldet oder bei uns meldet. Und dann müssen wir gucken, wie wir genau weitermachen. Ja, ihr könnt euch auch bei mir melden. Wir machen dann stille Post. Genau. Du machst dich als Durchlaufer Hitzer. Genau. Ich fasse das dann zusammen. Wahrscheinlich falsch. Und geht das dann weiter. Ja, so viel dazu. Ich hatte jetzt nicht geplant, noch etliche Buchupdates zu bringen. Aber hier und da werden wahrscheinlich nochmal welche kommen, wenn ich neue Erkenntnisse habe. Ja, weshalb ich da auch was machen könnte, wäre, weil wir gerade in der achten Auflage vom Adminbuch arbeiten. Die soll im Sommer erscheinen. Ach so, Sommer ist ja schon bald. Ja. Ich müsste auch mal langsam in die Hufe kommen und was tun. Da braucht es noch ein bisschen Gehensspalz von mir. Ich habe einiges an Änderungen, die ich einbauen möchte. Ja, vielleicht brauchst du dafür eine ordentliche Aufgabenverwaltung. Oh, du bist ja Chef der Überleiter. Ich habe ja erzählt, dass ich auf Task Warrior umgestellt habe. Und ich habe mir dann auch, um Mobil-Task Warrior benutzen zu können, habe ich mir dann das Task Warrior Web UI installiert. Und ich habe gemerkt, dass ich das überhaupt nicht benutze. also mit anderen Worten, ich benutze mobil eigentlich gar keine Aufgabenverwaltung also das ist eine interessante Erkenntnis die ich habe und ja, Ich brauche ein Mobil eigentlich nur irgendwas, was mir hilft, den Kopf leer zu machen, dass ich Sachen nicht mit mir rumtrage und dann irgendwann vergesse, sondern dass ich irgendwie aufschreiben kann, was mit dem Rechner zu Hause gesynkt wird, sodass ich die Aufgabe dann im Nachhinein erfassen kann, wenn die eine Aufgabe für meine Aufgabenverwaltung ist. das mache ich momentan mit der Notizanwendung LogSig das funktioniert ganz gut, LogSig wird irgendwie überhaupt nicht mehr weiterentwickelt obwohl sie wie mir zugetragen wird an der Datenbankversion arbeiten also da wird es wahrscheinlich auch nochmal einen Wechsel geben, wenn dann nicht im nächsten halben Jahr was passiert, und aber ich merke, also das war für mich eine interessante Beobachtung, dass ich mobil eigentlich gar keine Aufgabenverwaltung brauche weder für das Erledigen von Aufgaben, noch für das Abarbeiten der Aufgaben, noch für das Erfassen von Aufgaben. Ja, ich gucke da auch selten rein und also am Handy und erfasse auch selten was. Also manchmal habe ich ja einen Link, den ich gerne später mir nochmal angucken möchte. Das mache ich dann meistens mit LinkedIn und da gibt es die Android App Link, die was in LinkedIn schreibt, das reicht mir dann auch völlig auf aus, das reicht mir völlig aus. Und ich muss mich an der Stelle nochmal als Mitglied der Generation X outen und sagen, ich mache eigentlich gar nicht so viel mit dem Handy wie viele andere. Also meine Haupttreiber sind eigentlich Notebook und Desktop-System. Ja. Ich bade auch Loboscrawler am Handy. Das mache ich auch nicht. Fliege vielleicht auch daran, dass ich mittlerweile, eigentlich, also das ist nicht mehr ganz so komfortabel, weil ich eigentlich eine Lesebrille brauchen würde. ich kann schon noch lesen, es ist halt ein bisschen anstrengender, aber, man macht das auch nicht so einen Spaß, ehrlicherweise. Ja. Genau. Also vielleicht als Learning sich zwischendurch mal Gedanken machen, ob das, was man so macht, eigentlich mit dem wieder gespiegelt wird, was man so auf dem Handy installiert hat. Ja, ich packe auch häufig mal irgendwelche Apps wieder raus, die ich gar nicht installiert habe, aber ewig nicht genutzt habe. Android macht auch immer wieder eine Push-Benachrichtigung von wegen so, du hast hier sechs Monate eine App nicht genutzt. Ja, ich schmeiß sie mal runter. Ja, das ist mir mit unserer, wir haben ja so einen Telemedizin-Tarif bei der Krankenkasse, das heißt wir müssen immer erst die Hotline anrufen, bevor wir zum Arzt gehen und die haben auch eine App und die habe ich dann auch länger als sechs Monate nicht genutzt, die muss ich dann wieder neu anmelden, also ansonsten nutze ich das auch, um die Apps vom Handy runterzuschmeißen, ja. Aber zu deinem Thema zurück, also eigentlich kannst du auch, wenn du einen Task anlegen willst, was du später halt weiterverarbeitest, auch dir selbst eine E-Mail schreiben vom Handy aus. Ja, das ist auch eine Möglichkeit. Oder halt irgendein Messenger kannst du ja auch Nachrichten an dich selbst schreiben, kannst du auch theoretisch da rein. Ja, das habe ich sogar bei bei Threema habe ich eine Gruppe aufgemacht mit mir als einzigen Member. Das haben die explizit mal beworben, dass man das so machen kann. Und da tue ich dann auch Sachen rein. Aber das könnte ich auch wirklich häufiger nutzen. Das ist eigentlich eine sehr gute Idee. Du hast mal eine gute Idee gehabt. Unfassbar. Bist du krank? Ich mache das auch nicht mit Tasks, aber manchmal so Sachen, wo ich Text schnipsel oder Bilder übertragen muss. Ich schicke das an Signal an mich selbst meistens und dann kopiere ich das dann irgendwo weiter. Wenn man Mobil was erfasst, muss man ja hinterher sowieso nochmal dran. Also von daher vermisse ich da jetzt auch nichts. Ob ich es jetzt ganz, ganz neu anlege oder ob ich es Copy und Paste verspiele, für mich eigentlich kein Unterschied. Ja, genau, genau. Gut. Gut, gut. So viel dazu. Kommen wir zu meinem Shorty. Der eigentlich mal ein Thema war. Genau, das sollte eigentlich ein Hauptthema sein. Aber Fieber ist auch so, eigentlich gibt es da gar nicht so viel darüber zu erzählen. Aber wir können mal über Container Scanning, ich glaube, das wird jetzt ein Mix zwischen Shorty und Thema. Wie stehst du zu Container Scanning? Oder Container Image Scanning? Ja, sollte man machen. Ja. Und dann? Sollte man darauf reagieren. Genau, das ist ein guter Punkt, weil das ist häufig nicht im Workflow betrachtet. Ja, vor allem sollte man sich bei den Pipelines überlegen, was man da wirklich, ob man die Container-Images durchlässt oder nicht. Das ist, glaube ich, der Hauptpunkt, über den man sich Gedanken machen muss. Genau, also es gibt ja verschiedene Varianten. Also wir gehen gleich, also erstmal jetzt auf den Prozess betrachtet, weil du kannst dann ja ein Container-Image bauen, dann scannen und dann sagen, okay, wenn da kritische Vulnerabilities drin sind, dann wird das nicht gepusht. Wenn da keine drin sind, dann kann es gepusht werden zu der Container-Registry. Alternativ wird es halt zur Container-Registry gepusht, egal wie, und dann kann man es aber nicht pullen, also kann man entweder einfach ignorieren, scannen, aber ignorieren, was sehr, sehr viele machen. Aber dann halt auch eben das Ganze so im Sinne von ignorieren, so von wegen, naja, vielleicht kann man das Pullen deaktivieren, sodass es, wenn Critical Vulnerability hat, das nicht gepullt werden kann und so weiter. Da sind dann ganz viele Themen drin, wie die Usability, weil ich habe schon voll oft gesehen bei verschiedenen Firmen in den letzten Jahren, dann so, ja, wie scannt ihr das eigentlich? Und dann so, ja, das läuft in Harbor rein, in Harbor wird es gescannt. Und dann werden E-Mails verschickt mit den Critical Vulnerabilities, die dann weggefiltert werden von allen Leuten. Und dann kannst du es auch sein lassen. Ja, ich habe in einer anderen Firma erlebt, dass die keine E-Mails generieren, sondern via API direkt ein Ticket im Ticketsystem eröffnen. Und was dann mit Kopie an den CISO geht, also Chief Information Security Officer, tatsächlich. Okay. Und erst wenn der die Freigabe erteilt hat, darf das Image auch weiterverarbeitet werden. Ja, das ist zumindest noch ein Halbweg, also sein Ausnahmegenehmigungsantrag ist das dann ja. Ja, genau. Ja, genau. Ja, ich meine, da gibt es ja verschiedene Sachen. Was mein Problem aber meistens war, ist, dass wenn ich da selbst dran gearbeitet habe, häufig konntest du diese CVEs gar nicht selbst fixen. Jein, oder? Also genau, da kommt es drauf an, in welchen Stand man betrachtet. Was man ja eigentlich grundsätzlich machen sollte, ist Container-Images immer regelmäßig neu bauen. Genau, und man sollte vor allem gucken, wo die Sicherheitslücke drin ist. Ist sie im Base-Image drin oder ist sie in einem Layer da drüber? Genau, Base-Image ist nämlich der wichtige Punkt, weil meistens ist ja irgendein Distro da drunter. In Alpine ist es ja häufig, weil es sehr klein ist, aber auch Ubuntu, Debian und hast du nicht gesehen, gibt es da alles. Wenn da aber in irgendeiner Low-Level-Library oder Abhängigkeit eine Vulnerability drin ist, die auch noch im Hauptsystem nicht gefixt ist, dann hast du halt eine Critical Vulnerability da drin. Dann musst du natürlich gucken, was du damit dann machst und wie du es fixst. Und das finde ich immer super anstrengend, weil du dann halt jedes Mal auf die Suche gehen musst, um zu gucken, habe ich da überhaupt Vulnerabilities drin oder nicht. Genau, und gibt es überhaupt was vom OS-Hersteller, was das fixt? Genau. Was man ja eigentlich möchte. oder? Genau, weil wenn es halt irgendwie einen, ich hatte neulich ein paar Container-Images, wo es Open-SSL-Thematiken war und die waren dann halt, noch nicht gefixt upstream, weil es halt noch in Testing oder sonst was war und dann wartet es doch, dann lernst du das so und wenn du dann halt eine Policy hast, dass du es nicht pullen kannst, dann ist es doof. Wobei man auch unterscheiden muss, wann wird entschieden, ob du es nicht pullen darfst oder nicht. Also das kannst du halber machen, wenn ein Image initial gepusht wurde und dann sind keine Critical Vulabilities drin, dass du das dann weiter nutzen kannst, oder dass wenn du ein neues Image pusht, dass es dann nicht critical sein darf. Ja. Was einen Unterschied ja halt macht, weil sonst kannst du den Betrieb ja nicht sicherstellen, wenn du dann plötzlich nichts mehr deployen kannst. Ja, schlimmer ist es ja noch, wenn in Running Images CVs drin sind. Die, ähm, das scannen nämlich die meisten gar nicht mehr. Genau, das gibt's ja auch nochmal, genau. Container Runtime, äh, Runtime Image Scanning, Container Runtime Image Scanning oder so ähnlich. Das muss ja auch gemacht, müsste theoretisch halt auch gemacht werden, genau. Aber genau, da kommt's aber auch drauf an, wie häufig aktualisiert man jetzt eh die Container-Images durch. Ja, ich meine, man kann das mitigieren dadurch, dass man sagt, ich sage, dass alle Images, die in meiner Runtime laufen, also in meinem Orchestrierer laufen, dass die von einer bestimmten Registry kommen, also in der internen, also wie man es auch immer machen möchte. Ist ja häufig auch Artifactory mit X-Ray zum Beispiel. Und ich scanne alle Images per se von Zeit zu Zeit durch, in der Hoffnung, dass ich damit auch alle Running Images eigentlich erwische in ihrer Ursprungsform. Genau, so ein bisschen wie Käsescheiben. Du hast ja überall irgendwo Löcher drin und wenn du mehrere verschiedene Stufen drüber legst, dann werden halt ein paar Lücken da sein, ein paar Lücken werden geschlossen sein. Genau. Genau, und das ist halt das, wo du halt eigentlich richtig gucken musst, was du genau machst. Weil wir haben ja auch verschiedene Container-Images. Wir haben ja einmal die Container-Images für produktive Production-Runload, Workload quasi. Mein Fokus ist häufig ja eher die CICD-Thematiken, was in der Entwicklungsergebung genutzt wird. Und da brauchst du ja eigentlich auch sichere Container-Images. Und da kann es halt auch nervig sein, wenn du keine Projekte mehr bauen kannst, weil du eine Kritiker-Vonorbilität drin hast. Ja, genau. Ich wollte eigentlich noch darauf zu sprechen kommen, dass man natürlich auch die Pipeline selber prüfen muss. Ja, genau. Und da gibt es ja sehr, sehr viele Sachen, die man halt betrachten kann. Und mir fiel dann neulich halt auch dann auf, dass es diverse Firmen gibt, beziehungsweise diverse, also A gibt es verschiedene Scanner, die ja auch nochmal Verschiedenes finden. Trivi zum Beispiel kenne ich am besten oder am meisten von Aqua Security es gibt auch noch mal Guipe, es gibt auch diverse andere, die auch alle unterschiedliche Sachen scannen, da muss man auch ein bisschen unterscheiden, was scannen wir hier genau, weil einige scannen quasi nur das Basis Image plus die, Plus, plus die Anwendung, die halt drin ist, zum Beispiel wenn du eine Go-Binary dann reinwirfst, andere scannen halt natürlich noch mal was anderes, wie sind da noch Passwörter drin, also so Secret Detection-mäßig, aber halt auch Fehlkonfigurationen, was eigentlich mehr so Infrastructure-Code-Scannung dann noch ist. Es gibt ja eine Unmenge an Tools. Wie hieß noch das eine? Snook? Kann das sein? Ja, Sneak ist ja auch noch mal so ein kommerzielles Tool. Genau, kommerzielle X-Ray, was Sie ja auch erwähnt von Artifactory, J-Flock. Oder die Micro-Segmentation-Lösungen wie Illumio oder New Vector haben ja meist auch noch Image-Scanning eingebaut, wenn man es benutzt. Vielen Dank. Genau, und dann gucken die auch auf verschiedene Sachen drauf, deswegen kann das manchmal so ein bisschen ätzend sein, weil ich weiß, wo, was, wie, kommt auch auf die Konfiguration an. Ja, für sie getestet, ist ätzend, ja. Genau, und was mir dann halt auch irgendwie so auffiel ist, also naja, wo, idealerweise willst du ja auch möglichst kleine Container-Images haben, mit wenig Abhängigkeiten, aus verschiedenen Gründen, nicht nur aus Security-Gründen, sondern eben ja auch aus, aus praktischen Gründen. Ja, S-Bomb, Licensing, kann ja alles Mögliche. Ja, genau, das können ja auch diverse Scanner. Divers können es auch nicht, irgendwie sowas. Und mittlerweile gibt es dann halt, haben sich einige Firmen ja auch das auf die Fahne geschrieben, um das dann als Lösung anzubieten. Und Docker selbst hat was mit Handimages. Ich glaube, Bitnami hat sowas auch. Bitnami war ja von, ein neuer Teil wurde ja von VMware gekauft, die wiederum von Broadcom gekauft wurden. Deswegen fangen die auch alle alles zuzumachen, was vorher offen war. Replicated gibt's noch, Replicated Secure Build und Chaineduard. Chaineduard ist mir vor allem halt häufig schon über den Weg gelaufen. Dem Namen nach zumindest. Genau, da hab ich dann halt auch viel, sowohl Content halt mehr zugesehen, als auch von Firmen halt gehört, dass sie das irgendwie verwenden oder verwenden wollen oder so. Ähm, und dann hatte ich da mal so reingeguckt. Ich hab da noch nicht extremst tief reingeguckt, aber das ist ja irgendwie eine, eigentlich ja eine Distribution, aber irgendwie auch nicht, weil die sagen halt, das sind Distroless Container. Weil halt so gut wie keine Abhängigkeiten da drin sind. Und ich meine, es ist halt kommerzielles Angebot. Es basiert auf Wolfi OS. So heißt das. Das ist halt Distroless. Und Chaineduard OS basiert auf Wolfi OS. Grüße an den Engineering-Kiosk an der Stelle. Stimmt. Ja. Ich frage mich gerade, warum Wolfi? Ich glaube, das hatte ich auch irgendwo gelesen. Also Wolfi is the first community Linux und distribution declaratively built for creating a secure base layer for your containers. Ja, wunderbar. Also Wolfi im Engineering-Kiosk ist einer der Hosts. Ja, genau. Vielen Dank. Genau, also es ist halt komplett Strip-Down-Image quasi auf das Nötigste reduziert, dass halt die Anwendungen laufen können. Die bieten ein paar davon auch kostenlos an. Also ich glaube, die verschiedenen Hersteller bieten Teile von ihren Zero-CVIs kostenlos an, aber halt nicht alle und teilweise dann auch nur mit einem Latest-Tag oder sowas, was halt auch nicht so praktisch ist. Vielleicht für Pipelines noch, aber auch da kommt es ein bisschen drauf an. Ja. Aber ja, und da merkte ich dann halt auch so, okay, das ist schon ein gewisser Pain, der gelöst werden kann. Gib mit Geld. Ja, man muss immer ein bisschen Geld angreifen. Also generell sollten ja Images eh so klein sein, dass sie eigentlich nur die Funktionalität mitbringen, die sie brauchen, um ihre Aufgabe zu erfüllen. Soweit die Theorie. In Praxis sieht es dann doch nochmal anders aus. Da gibt es auch relativ viele Makroservices, die durch die Gegend fahren. Das muss man einfach auch mal berücksichtigen an der Stelle. Bei den CVEs muss man vielleicht auch nochmal sagen, da muss man darauf achten, ob das CVE wirklich durchkommt. Es gibt ein paar CVEs, die sind highly critical, aber nur für Leute, die sich auf dem Container anmelden können. Und das kann man ja vielleicht auch dadurch mitigieren, dass man keinem erlaubt, über irgendeinen Weg sich in einen Container zu connecten, außer den Admins. Genau, das ist dann ja nur der Fall, dass wenn jemand aus der, bei den meisten Containern, also idealerweise hast du gar keine Bash oder sonst was da drin. Das kommt nochmal dazu, genau. Aber bei dem, das ist ja trotzdem noch relevant, falls jemand aus der Anwendung ausbricht und eine lokale Shell öffnen will und da gibt es eine Shell und die dann noch ausgenutzt werden kann, dann ist es natürlich ein Problem. wo wir halt wieder bei den Käsescheiben sind. Je mehr Lücken wir zumachen, desto besser. Aber ja. Ja, aber dann müsste erst mal die Anwendung da drüber eine Security-Lücke haben, die es überhaupt erlaubt, auf eine Stelle zu kommen und sich in die Anzüge machen. Also Käsescheiben, genauso wie du gesagt hast. Genau. Man muss halt irgendwie gucken, dass das alles so ist. Was mir aber halt immer nervig aufstößt, ist, dass halt etliche Projekte, die dann die bauen halt ihre Container-Images nicht regelmäßig neu. Und das ist dann auch irgendwie nervig, weil dann wollte ich bei irgendeinem Projekt, ich weiß gar nicht mehr, was es war, hatte ich halt Critical Vulnerabilities und das stört dann halt an der Policy, die da halt im Place ist und dann will ich halt natürlich gucken, so okay, kann ich das jetzt selbst fixen und kontributen? Wir hatten das Thema ja, einfach selbst kontributen, wenn es geht. Dann baue ich das Image bei mir lokal selbst und merke dann so, die Critical Vulnerability ist gar nicht mehr da. Weil es dann halt zu dem Zeitpunkt, wenn ich es baue, dann halt schon in der Base Image dann gefixt wurde, wenn ich es halt neu baue, aber nicht unbedingt das alte, was halt in dieser Version getaggt ist. Und was dann halt auch wieder ein bisschen anstrengend ist. Kannst du nicht das gleiche Image mit der gleichen Version von deinem Tool, wo du nichts daran geändert hast, neu bauen, einfach nur damit? Die einen wollen es so, die anderen wollen es so. Es gibt ja viele, auch in der Get-Depos-Welt, gibt es noch viele konservative Unternehmen, die dann halt ein Image so lange wie möglich benutzen wollen und die einen Change-Prozess brauchen, wenn das Image gewechselt wird. Also, und die sagen, wir wollen das eigentlich nur gewechselt haben, wenn sich die Applikation ändert. Ja, genau, weil da hast du dann wieder das Problem mit der Versionsbezeichnung, weil wenn du dann halt von dem Tool ABC Version 1, 2, 3 das Container-Image nutzt, und wenn es aber an verschiedenen Tagen gebaut wurde, dann sind das ja verschiedene Images mit dem gleichen Deck. Willst du das? Willst du das nicht? Weil manchmal führt das ja auch dazu, dass es zu verschiedenen Funktionen kommt. Ja ich meine wir kennen das semantic versioning also mit den drei sachen major minor und patch, und da gibt es ja bei manchen versionen noch ein bindestrich und dann noch noch noch noch eine meiner patch version ja das könnte man ja für images verwenden wenn man wollte aber dann wird es auch beliebig kompliziert ja. Genau und dann hast du halt eben das problem. Vielleicht muss man auch irgendwie eine hohe mathematische Funktion schreiben, die dann aus OS-Version und Patch-Level und der Applikationsversion und Patch-Level eine neue Version generiert, vielleicht so als 256 Zeichen langer Hash-Wert, sodass man das nicht wieder nachvollziehen kann. Ja, ich meine, da kommt ein bisschen darauf an, womit du das, was jetzt ein Use-Case genau ist. Also bist du jetzt wirklich in CI-Umgebungen, da ist das vielleicht auch mal ein anderer Fall als in Produktionsumgebungen, wie du es genauer machst, weil eigentlich willst du ja auch existierende Container-Images nutzen, um nicht jedes Mal das Rad neu zu erfinden. Gleichzeitig, wenn die aber nicht regelmäßig neu gebaut werden und dann sind da irgendwelche Vulnerabilities drin, die gegen die Policy verstoßen effektiv, auch wenn sie in der Praxis vielleicht wenig relevant haben, dann ist es dann auch nervig, aber da willst du auch keinen eigenen Fog davon betreiben. Ja, aber vielleicht kann man sich ja darauf einigen, dass man spätestens dann anfängt, neu zu bauen, wenn es eine Vulnerability gibt an der Stelle. Genau. Ja, ich meine, ich denke so an so Sachen wie, keine Ahnung, Node.js-Container, wo du halt nur baust, um dein Projekt halt zu bauen. Da musst du halt dann, das willst du ja nicht selbst bauen, das Image, sondern du willst ja das Vorhandene nutzen, um das Rad nicht neu zu erfinden oder doppelte Infrastrukturen zu haben. Aber wenn das dann abströmlich neu gebaut wird, ich weiß nicht, ob es bei Node.js der Fall ist, aber ich glaube bei Exchange Guard gab es ein Node.js Image, vor FUI auch, dann ist es halt doof, wenn es dann nicht da ist. Ja, klar. Aber es muss natürlich die komplette Pipeline durchlaufen. Wenn ich ein Image brauche, was ein anderes Image baut, dann muss man das Image, was ich als Werkzeug benutze, natürlich auch regelmäßig neu bauen. Spätestens, wenn es ein CVE hat. Ja, und was ich halt auch so gemerkt habe, ist, die meisten Tools, zumindest die ich so kenne, die haben noch nicht, also ich weiß nicht, ob das vielleicht die Chain Guard und Co. das irgendwie richtig anbieten, in kommerziellen Offerings, aber eigentlich willst du ja dann ja auch wissen, bei einem Container-Scann, und da ist eine Vulnerability drin, okay, ich muss jetzt an das Base-Image, was wir selbst bauen, hin und da was fixen. Und dann propagiert das ja teilweise nach oben, weil du dann ja erstmal dein Base-Image hast für das Basis-System. Dann hast du noch deine Laufzaubergebung für, keine Ahnung, Java zum Beispiel und dann deine Anwendung. Dann hast du ja theoretisch drei verschiedene Projekte, wo dreimal jeweils zurückreferenziert wird. Da musst du ja eigentlich nur einmal das Base-Image neu bauen und dann die anderen halt nachführend. Aber diese Visualisierung oder halt irgendwie, ja, schon ein bisschen die Visualisierung, die siehst du halt oder hast du halt nicht. Und dann siehst du halt auch nicht, ob dann jemand nicht doch ein völlig veraltetes nutzt. Ja. So was sehe ich mehr so an GitHub oder GitLab quasi, dass man das da irgendwo sichtbar hätte. Aber gibt es leider nicht. Also nicht, dass ich wüsste zumindest. muss ich selbst was machen, Mensch. Ja. Mach was für dein Geld. Genau. Deswegen waren das eigentlich so viele Learnings so ein bisschen so, dass das eigentlich alles, was Container-Image, sichere Container-Images angeht, eigentlich so ein Pain ist. Zumindest, wenn man kein Geld dafür ausgeben möchte, darf, wie auch immer. Ja, aber es ist Business as usual. Eigentlich ist es das, was wir schon immer gemacht haben. Genau, nur in einer anderen Verpackung. Nur in einer anderen Verpackung, genau. Aber um die Verpackung muss man sich halt kümmern. Und viele denken dann, ah, jetzt mit Container, das ist doch viel einfacher alles. Das ist genau vielleicht der Unterschied, dass man jetzt auch an die Verpackung ran muss. Genau. Toll, Verpackungsmetaphern. Ja, gehen immer. Ja, sonst verwende ich doch immer Autovergleiche. Ich habe mal eine Toffifee-Retro gemacht, da kann ich auch noch mal was zu erzählen. Ja, ich bin aber, glaube ich, auch mit dem Shorty soweit durch. Gut. Jetzt will ich aber wissen, was die Toffee-Fee. In der Retro geht es immer darum zu sagen, was man in den letzten Wochen gemacht hat Da kann man als Beispiel Toffee-Fee nehmen, welche Nüsse hatten wir zu knacken Ja, was war was war süß wie schokolade karamell weiß ich jetzt gerade gar nicht mehr und was machen wir mit dem müll also was sollten wir nicht mehr was sollten wir nicht mehr tun, ja und dann habe ich halt also die idee ist natürlich nicht von mir da gibt es aus dem podcast methoden montag und ich fand die idee ganz gut ich habe das mit zweimal in einem team gemacht, das ist ganz gut angekommen. Hab natürlich dann auch Toffee-Fees auf den Tisch gelegt, das gehört natürlich dazu. Ja, es ist alles nur eine Erfindung der Toffee-Fee-Firma. Nein, aber ich fand die Idee ganz gut. Man versucht ja bei Retro das Bekannte ist wahrscheinlich die Starfish-Retro, man versucht ja immer Sachen zu machen, wo man Analogien findet, die man so benutzen kann. Und bei Toffee-Fee hat es eigentlich jedem direkt eingeleuchtet, was man damit machen kann. Ja, witzig. Ja, sowas konnte ich auch mal oder kann ich auch mal machen. Gut, kommen wir zu unserem Hauptthema. Und zwar müssen wir mal über AI sprechen. Schon wieder. Und nicht nur hier, sondern auch in allen anderen Podcasts. Wollen wir ein AI-Update machen? Jetzt gibt es Cloud 4.9. Ich kann immer noch keine Wäsche machen. Ah, verdammt. dann ist das nichts für mich. Genau. Und zwar rede ich immer wieder, nicht nur mit dir, sondern auch mit anderen Leuten, was macht denn jetzt genau, wenn man mit AI zum Coden verwendet? Du redest mit anderen? Manchmal, ja. Oh nee. Was auch keine EIs sind übrigens. Was, wenn man AI zum Coding verwendet, naja, was für Auswirkungen hat das Ganze denn? Und wir verlinken mal einen Artikel von Tom, Tom Wojcik. Der hat, fand ich, einen relativ guten Artikel geschrieben, den ich jetzt hier auch zusammenfassen werde, um so ein bisschen auch zu differenzieren, was haben wir, was machen wir, wie machen wir das, was Auswirkungen hat das nicht nur auf Code, sondern auch dahin hinaus. und das fand ich dann halt schon super spannend. Aber womit das mal halt anfängt, ist zu sagen, naja, okay, wir haben halt einmal das manuelle Tippen, Und dann haben wir auf der einen, auf links quasi, auf dem Zeitstrahl und ganz rechts haben wir AGI, also diese. Argentic AI, ja. Ja, AGI ist ja das Endstadium, was anvisiert wird, dass es komplett selbstständig ist. Du musst dem nichts mehr sagen, der macht das alles, findet alles raus und bla bla bla. Und da sind wir ja noch lange nicht und ich bezweifle auch, dass wir da so schnell hinkommen. Ich glaube es auch nicht. Und dann hat er nämlich dann nochmal ein bisschen geschrieben, okay, von wo sind wir denn hergekommen? Man kennt ja, wenn man jetzt Form, egal ob man es jetzt AI nennt oder nicht, man hat ja manuelles Tippen, man tippt jeden Scheiß selbst rein. Das wurde ja viel von IDEs ja auch schon angepasst, dass du dann ja irgendwelche Funktions, wie heißt das nochmal? Autovervollständigung. Ja, Autovervollständigung, aber auch, dass du dann halt Funktionsblöcke generieren konntest, zumindest den Namen und irgendwelche Variablen oder Methoden, Klassen, sonst was, wenn du ein UML oder sowas reingeworfen hast. Das ging ja auch schon dahin, so verwegen möglichst viel noch automatisieren, weil es sehr stumpfes Runtergetippe ist. Effektiv ist ja AI-Coding, nenne ich das jetzt erstmal, ja auch eine Art von, naja, wir automatisieren ein bisschen mehr. Weil wir wissen ungefähr, was wir raushaben wollen. Und dahingehend machen wir das. Weil wenn man jetzt so die Copilot zum Beispiel, also Copilot von GitHub, das gibt es ja schon bevor es ChatGPT gab und das war ja am Anfang einfach nur eine intelligente Code-Vervollständigung per Tab drücken effektiv und damals hat es niemanden interessiert, effektiv niemanden interessiert. Das hat sich ja über die Zeit ja auch deutlich geändert. Kaum kein Chat-JPT raus hat es, dass plötzlich jeden interessiert. Und weißt du noch, damals, wo noch die Leute vor allem auch, wo viel Diskussion gab, so, okay, ist denn das, darf ich diesen Code jetzt überhaupt verwenden, so von Copyright-Sicht? Das interessiert heute ja gar keinen mehr. Gar keine Sau mehr, ja, das stimmt. Oder wie wurde das angelernt und sonst was? Es ist heute so, egal. Mit allen Vor- und Nachteilen natürlich. Genau, und das war ja so der erste Schritt in Richtung, wir automatisieren hier was mehr Richtung AI. Und was da jetzt nochmal unterscheidet, ist unter AI-Assisted Human Coding und Human-Assisted AI Coding. Ah, ja. Weil AI-Assisted Human Coding ist Cursor. Also, hatte ich das als Beispiel genommen. Weil die waren ja sehr gut, dass du es in ID hast. Du hast einen Chat-Prompt da drin und du bist immer noch ein Mensch, der es entwickelt, aber du kannst dann halt einzelne Teile von einem AI unterstützend machen lassen. Und das gibt es ja schon so seit 2023, 2024 oder so. und was du jetzt dann halt als Human Assisted AI Coding hast, ist, dass die AI den ganzen Kram macht, aber man als Mensch da Inputs reinliefert und nicht andersrum. Dann nennt es Cloud Code zum Beispiel, was wir in der letzten Folge auch kurz angerissen hatten. was ja auch spannend war, weil so aus der Hinsicht habe ich das noch nie betrachtet. Dass es da ja eigentlich auch schon Unterschiede gibt. Ja, definitiv. Habe ich auch noch nicht so unterschieden, aber es passt ganz gut. Genau, ich meine, der macht ja letztendlich auch nochmal Unterschiede mit verschiedenen Leveln von Human Assisted AI Coding, weil einige sind natürlich besser und schlechter. Und im Moment geht es ja auch dahin, dass du dann halt so, also wenn du als Tropic anguckst, die wollen dann ja auch ein bisschen AI-Coding haben. Dass du viele verschiedene AI-Models oder LLMs hast, die dann halt zusammen was machen. Und was der halt angefangen hat, dann auch zu beschreiben, ist so, naja, was macht das jetzt eigentlich mit dem Kopf? Also, oder generell, was passiert denn da jetzt? Weil wir haben ja auch Agentic-Modus, das heißt, die werken vor sich selbst hin, machen dann Merge-Requests oder Pull-Requests auf und dann revieust du das Ganze. Das ist ja dann doch wieder was anderes. Und die Endstufe ist natürlich die vollständige Automatisierung. Und hier fand ich dann halt spannend, dass er halt einmal gesagt hat, naja, es gibt ja Technical Depth. Also technische Schulden im Code. Und dann hat er es noch Cognitive Debt genannt. Also kognitive Schulden. Also was ist im Kopf da gerade? Was passiert dir gerade? Also wenn du entwickelst. Das wird gefühlt immer mehr eher zu einer Blackbox. Wenn du jetzt sagst, okay, ich generiere sehr, sehr viel Code. Und ich merke das bei mir auch, wenn ich das hier und da mal rumprogrammiere oder mache oder programmieren lasse, dass mein Kopf ganz anders an die Problemlösung rangeht und ich viel weniger und ich mache keine komplexen Sachen ich mache nur Skripte oder sonst was, die ich für mich brauche und ich bin kein guter Programmierer oder kein erfahrener Programmierer, sagen wir so, und das ist für mich dann halt praktisch, weil ich komme zum Ziel für das, was ich halt brauche und dann ist das für mich okay, das ist natürlich ein einfacher Use Case, können wir machen wenn du jetzt aber halt an größere Anwendungen denkst, dann bist du ja, wenn du am entwickeln bist oder am debuggen bist und sowas, da gibt es auch nochmal Unterschiede. Schon im Kopf in der Architektur drin, wie funktioniert das Ganze, wo wird was aufgerollt und gemacht und je mehr du das über einen AI generieren lassen willst, desto weniger blickst du effektiv dadurch. Ja, wobei ich das bei einigen Quellcode, den ich selber geschrieben habe, den ich mir ein halbes Jahr oder ein Jahr später angeguckt habe, auch sagen kann, dass ich nicht mehr durchblicke, was ich damals gedacht habe. Genau, genau. Aber du kannst halt wieder, aber du hast zu dem Zeitpunkt, als du es gemacht hast, kannst du ja trotzdem noch mal verifizieren, passt das? Ja, aber das hilft mir heute nicht mehr. Und da ist es von dem Vibe-Coding eigentlich gar nicht mehr so weit entfernt. Ja und nein. weil einmal, wenn man jetzt relativ langsam Code schreibt quasi, also per Hand, dann, also das Bekannte quasi, dann hast du die Punkte, die du genannt hast, passen da ja auch. Aber wenn du jetzt halt mit Vibe Coding nochmal sehr, sehr viel mehr Code schreibst, dann potenziert sich das Ganze nochmal viel stärker. Ja, na klar. So, und das ist ja dann das Problem. Wenn du jetzt schon nicht durchflickst, dann wird es später nicht besser oder eigentlich schlimmer. Das wollte ich damit sagen, aber dass man sich auch selber in die Falle setzen kann. Die Gedanken, die man sich damals beim Erstellen des Codes gemacht hat, dass man die nicht mehr nachvollziehen kann. Aber trotzdem hast du ja immer noch einen groben Architektur ungefähr, wie das funktioniert von verschiedenen Modulen und irgendwelche Aufrufen. Nicht im Detail, aber je nachdem, wie viel Code du erzeugst, ob du Jahre später wirklich noch weißt, was du in dem einen Skript damals gemacht hast. Ich meine, das ist auf High-Level. Welche Module Wo muss ich hin, wo kann ich anfangen zu suchen und so weiter. Und das ist dann halt eben anders beim Vibe-Coding halt effektiv. Das fand ich auch spannend, der hat dann eigentlich geschrieben, naja, effektiv fühlst du dich produktiv, weil du halt sehr, sehr viel Code generieren lässt, weil du halt vielleicht sehr viel Code reviewen musst. Aber jeder kennt das eigentlich, dass wenn es sehr, sehr viel Code ist, dann ist das TLDR, too long didn't read und looks good to me, LGTM. Ja. Wir wissen ganz genau, dass es eigentlich die große Kunst ist, das Code wegzulassen und nicht Code dazu zu schreiben. Genau, ich finde es auch ganz schlimm, dass voll oft irgendwie jetzt wieder Metriken rausgeholt werden. So von wegen, wir haben, keine Ahnung wie viele, tausende Zeilen mit LLMs geschrieben. und ich denke dann so, es war schon früher eine scheiße Idee, das als Metrik zu verwenden. Ich weiß, was ja grundsätzlich damit gesagt werden will, so von mir gesagt, okay, wir machen jetzt schon viel mit generieren und bla bla, aber ich finde das trotzdem eine kacken Metrik. Absolut. Absolut. Aber ich fand halt diesen Spin halt interessant, dass halt meinte, naja, du fühlst dich halt produktiv, aber effektiv heißt das nicht unbedingt, dass du produktiv bist, weil man dann halt auch weniger überlegt, was hat das langfristig für Einschränkungen für den Code. Weil gefühlt ist dann ja auch schon sehr viel, bei vielen Leuten, naja, Coden mit jedem Review, das muss super sauberer Code sein, es darf alles mögliche mit reused werden, nichts verdoppeln oder sonst was, es wird ja damit halt komplett über den Bord, über das Bord geworfen, nein, über den Haufen geworfen, so. Oder über Bord geworfen, genau. Oder über Bord geworfen. Genau, und der nannte das dann halt zum Beispiel, es gibt dann natürlich einen realen Flow, das nennt ja dann Growth, wenn es halt wächst was auch immer wächst also das Produkt du selbst weil du dann ja auch jedes Mal wieder von neu lernst, und der nennt sich dann auch noch mal es gibt einen Darkflow weil diese Challenge-Skill dass du halt überlegst, wie du ein Problem löst ist halt weg, du überlegst halt nicht also wirklich, wie kannst du es lösen, sondern das LLM löst es für dich, und das ist dann so ein bisschen wie eine Slot-Maschine daher kommt auch ein bisschen der der Begriff, du wirst halt effektiv abhängig und du denkst weniger nach, sondern wirfst halt einfach nach. Also ich hatte ja auch ein Meme gesehen, hast du vielleicht auch schon mal gesehen. So von wegen so, naja, der Unterschied zwischen LLMs und Slot-Machines, so naja, du musst Token einwerfen und vielleicht gewinnst du was, vielleicht auch nicht. Und du hoffst, das nächste Mal wird es besser. Das ist hier teilweise ja auch. Und, aber ja, das ist halt auch irgendwie so spannend, wenn du halt auch überlegst, dann sagst du, ja, eigentlich stimmt das schon. Also jetzt unabhängig von dem Meme. Ganz kritisch finde ich dann aber auch wenn man dann so guckt, es gibt halt ja auch viele die ein oder andere haben ja auch von OpenClaw mitbekommen, wo dann der Entwickler davon gesagt hat, naja ich lasse hier Cloud Code oder Codex oder sowas laufen und den Code gucke ich mir nicht an es wird einfach reingemerged, Wo ich auch so denke, weiß ich nicht. Kommt immer drauf an, wofür du es einsetzt, oder? Wenn es kritischer Code in Produktion ist, sollte man schon noch verstehen, was da passiert. Ja, ich meine, OpenClaw ist ja eh so ein Bot, was du ja auf dein Rechner laufen lässt und deine E-Mails lesen soll und bearbeiten soll und der hat ja gar keine Guardwails und überhaupt drin. Ja, aber gut, da ist es dann auch egal, ob es AI generiert ist oder nicht, weil wenn du jetzt denkst, du brauchst das nicht, dann es ist halt schlecht für die Leute, die es nutzen wollen. Ja. Und das ist dann halt auch irgendwie das Problem. Ja, wenn du dann guckst, wir hatten das, glaube ich, letztes Mal ja auch schon Cloud, also Enthropic entwickelt ja Cloud Code mit Cloud Code und Reviewen effektiv halt auch nur noch, das kannst du halt machen, wenn du es dann auch ordentlich reviewst. Aber das ist dann halt schon für den Kopf halt schon was anderes. Und das fand ich halt auch noch was spannend. Der meinte da halt, oder hat halt in den Blogpost weitergeschrieben, so naja, wenn du keinen Code mehr schreibst, sondern nur noch reviewst, woher kommen dann deine Skills? Weil wodurch hast du gelernt? Nicht nur Coden, sondern auch Systemadministrationen-Themen. Vor allem durch selber machen und Fehler machen. Ja, genau. Und gerade dieses Fehler machen ist halt irgendwie das, was dann halt häufig fehlt. Weil es sieht halt alles immer sofort richtig aus und du könntest das dann halt ohne AI gar nicht mehr reproduzieren, weil du gar nicht weißt, was du alles machen musst. Ja, da sehe ich auch eine ganz große Gefahr. Oder sagen wir mal so, ich sehe ein Risiko. Ja, genau. Kommt auch immer darauf an, wer es nutzt, wenn du das gut nutzt. Aber dann bist du halt nicht mehr ganz so schnell, wie behauptet wird. Ja, ich habe ja neulich jetzt für unseren Podcast mal die ganzen Downloads runtergeladen und einfach mal ausgewertet. Da habe ich mir auch ein Skript schreiben lassen durch Vibe-Coding. Mich interessiert nicht, wie das Skript funktioniert, aber es hat aus Output generiert. Ja, genau. Ich habe es einmal manuell nachvollzogen, das Ergebnis passte und danach war es mir dann auch egal. Genau, für solche Sachen. Das ist ja auch völlig egal. Da macht es auch keinen großen Unterschied. Aber wenn ich das als Feature für Kunden anbieten würde, würde ich das schon gerne verstehen wollen. Ja, vor allem, wenn es irgendwie eine Bank ist oder sowas. Ja, ja. Und, aber ja, ich meine, mein Punkt war jetzt auch mehr so, naja, wie lernst du dazu? Wir hatten das ja jetzt gerade so, naja, man lernt durch Bauen, durch Testen, durch Fehler machen, Fehler korrigieren, durch Debuggen und dann lernst du jedes Mal was dazu. Aber man darf ja auch nicht vergessen, man verlernt ja auch diverse Sachen, wenn du die Sachen häufig nicht machst. Mhm. Aber es ist ja eine ständige Diskussion, welche Skills darf man verlernen, welche darf man nicht verlernen. Also wenn man sich überlegt, dass viele Leute ohne Navi komplett aufgeschmissen sind, orientierungsmäßig. Und die sagen ja, Navi wird immer gehen, Satelliten funktionieren immer und dann gibt es einen Krieg und die Genauigkeit der Satelliten wird von 5 Meter Genauigkeit auf 300 Meter Genauigkeit geändert. Dann war es das mit dem Navigieren mit dem Auto. Genau, und dann fällt dir ein, dass du gar nicht tanken kannst. Dann fällt dir zum einen ein, dass du gar nicht tanken kannst und zum anderen weißt du gar nicht, wie du den Weg alleine zur Tankstelle findest, im schlimmsten Fall. Übertrieben formuliert natürlich. Aber dadurch, dass du überhaupt nicht verstehst, wie die Städte zusammenhängen, wie die Geografie ist, Skills, die wir verlernt haben, wo wir auch sagen, dass es in Ordnung ist, dass wir die verlernt haben, die können aber in Extrinsituationen trotzdem enorm hilfreich sein. Ja, vor allem jetzt in IT, zurück in IT, halt an abgeschotten Umgebungen. Ja. Du hast es ja schon häufig genannt, ich glaube auch hier im Podcast so von wegen, naja, es ist schön, wenn du eine total komplizierte Wim-Konfiguration hast und mit der du gut arbeiten kannst, aber wenn du als Sys-Admin oder hauptsächlich Sys-Admin auf irgendwelche Systeme drauf musst, wo es die dann nicht gibt und du was debuggen musst, dann ist das halt doof, wenn du dann sagst, ich kann jetzt so nicht arbeiten. Ja, deswegen bin ich halt auch immer möglichst nah dran an dem, was ausgeliefert wird, das ist so. Ja, genau, kommt natürlich darauf an, was und wo und wie. Na klar, na klar. Aber ja, das merke ich dann halt auch immer wieder in verschiedenen Umgebungen. Genau. Ja, ich meine, das Thema haben auch schon viele immer wieder angerissen, dass also den Level von den Leuten, also Junior, Intermediate, Senior, Staff, Developer oder Engineers halt generell, wo da die Unterschiede sind und wie man dazulernt. das Dazulernen hatten wir ja gerade noch, aber häufig ist es eher so, dass Junioren was von Senioren lernen, in der Regel. Auch Senioren Sachen von Junioren reviewen, aber es auch hilfreich sein kann, mit Junioren-Code von Senioren, reviewen und verstehen. Idealerweise dann auch verstehen. Das hilft natürlich nicht, wenn du einfach nur auf OK drückst, looks good to me, dann ist es egal, ob es ein LLM ist oder nicht. Aber wenn es halt diese Struktur gar nicht mehr so wirklich gibt, weil effektiv generiert ja ein LLM einfach nur noch Senior-Code effektiv, dann fehlt dann halt auch diese Weiterentwicklung von Junior zu Senior um zu wissen, was können Probleme sein und meistens merkst du es dann auch erst, wenn du Sachen machen lässt die du selbst gut kennst. Aber wenn du jetzt eine eigene Anwendung hast, wo weißt du, okay, ich weiß, was das Ganze tut und macht, dann lässt du einen LLM laufen, der das neu baut, dann werden das diverse Teile sein, die sehr gut sein werden, aber auch diverse Sachen, wo dann so, ja, das wird auf die Schnauze fallen, wenn es 500 Leute oder 200 Leute nutzen gleichzeitig. Ja. Aber Stand jetzt, das kann sich halt auch wieder ändern und besser werden. Es gibt ein relativ interessantes mathematisches Beispiel für Junior und Senior. Hast du früher in der Schule die binomischen Formeln lernen müssen? Ja. Da gab es ja diese dritte binomische Formel, die heißt a minus b mal a plus b ergibt a Quadrat minus b Quadrat. Ja. Habe ich nicht mehr im Kopf gehabt. Sei es drum. Und es gibt ja eine Ableitung davon, du kannst ja sagen, dass du n plus 1 mal n minus 1 ergibt n Quadrat minus 1. Okay. Ist eigentlich auch eine dritte binomische Formel. Ich habe nie verstanden, wofür wir das gelernt haben. Ich habe es relativ schnell auswendig gelernt, aber ich habe es nie so richtig verstanden. Und dann hat in der Einführungsvorlesung Mathematik hat dann mal ein Lehrer gefragt, wie viel ist denn 17 mal 19? Ja. Ja, das ist 18 Quadrat minus 1, weil das nämlich genau die dritte binomische Formel ist. N minus 1 ist 17, N plus 1 ist 19, also N ist in der Mitte, das ist 18. Und wir haben alle früher die Quadratzahlen von 1 bis 25 auswendig lernen müssen. Ja. Und deswegen kann man das relativ schnell ausrechnen. Ja, ja. Wenn man verstanden hat, wofür das eigentlich da ist. Ja, ja. Und die Analogie ist jetzt halt, wenn ein Junior, so wie ich, die binomische Formel lernt und auswendig lernt, aber kein praktisches Anwendungsgebiet dafür hat, dann bleibt das immer eine auswendig gelernte Formel, aber ohne praktischen Nutzen. Ja, ja. Ja, guter Punkt. Ein gutes Beispiel, vor allem auch. Jetzt habe ich dich aus dem Konzept gemacht. Es ist schon irgendwie spannend. Genau, wo war ich gerade noch? Wir waren mal Julia Senior und die LNN schreiben Senior Code. Genau, und was ja dann noch mal hinzukommt, das hatte ich ja gerade auch schon angerissen, sondern wenn du die ganze Zeit Code siehst, der gut aussieht, dann hinterfragst du weniger und effektiv verlierst du dann halt auch Skills, weil du dich nicht mehr hinterfragst und nicht mehr ausprobierst und machst. Und was halt auch nicht so geil ist. Ja. Ich kenne unsere beiden Fähigkeiten, gutes Design zu produzieren, was nah bei null oder drunter liegt. Also wir können beurteilen, was gut ist und was schlecht ist, aber wir sind definitiv ein Junior im selber Design. Design im Sinne von Grafikdesign oder Webdesign. Grafikdesign, Foliendesign, Präsentationsdesign, Webseitendesign, was auch immer so ist. Wir werden auch nicht Senior werden, weil wir es selber nicht probieren. Ja, genau, genau. und genau, das ist dann halt auch irgendwie so spannender, weil was da halt auch nochmal reinkommt ist, naja, wenn die ganzen Leute, und mit Leute meine ich jetzt vor allem halt die AI-Buden, die sagen, ja AI wird doch nur noch Code schreiben. Wenn man mal guckt, wer das sagt, das sind rein zufällig alles Firmen, die Geld damit verdienen, wenn du Tokens bei denen kaufst. Ja, oder CEOs, die das technische Know-how nicht haben und die sagen, da kann ich ja Leute sparen. Genau. Also vor allem halt AI wird nur noch Code schreiben. Das kommt halt vor allem von Google, Entropic, OpenAI und hast du nicht gesehen. Und die machen halt alle damit Geld. Deswegen muss man da eh so ein bisschen aufpassen. Ja, CEOs und sonst was sagen das auch. Bin ich eigentlich auch CEO? Ich bin auch Geschäftsführer. Ich bin auch CEO. Chief Eating Officer. Genau, Chemnitz Eating Organizer, genau. Und ja, ich überlege gerade so und da, wo du ja meintest, jetzt gerade, CEOs, die haben ja auch, also oder Teamleads ja auch, wenn sie kein Code, lange kein Code mehr geschrieben haben, dann fangen sie auch irgendwann wieder an zu coden mit AI. Also, oder vermeintlich zu coden. Die erkennen dann auch vieles nicht mehr. Die sind dann auch irgendwann wieder auf dem Junior-Level. Ich finde, die denken dahinter viel interessanter, zu denken, also AIs lernen, werden ja besser durch Trainingsdaten. Ja. Was passiert denn, wenn keine Trainingsdaten mehr kommen? Ja, dann wird es noch Programmiersprachen geben, die für AIs geschrieben sind. Das heißt, das hieß ja im Gegenzug, dass wir denken, dass alles, was wir momentan an Wissen auf der Welt generiert haben, ausreichend ist. Ja. Wir müssen ja nichts mehr innovieren, wir müssen ja nichts mehr besser machen, weil das ist ja eigentlich alles Wissen schon da, weil ein AI macht ja nun wieder Coin von Wissen. Das kann auch ein paar Querbezüge herstellen, okay, aber letzten Endes ist das ja nur Reproduktion. Ja, ja. Genau, und dann ist halt auch die Frage, wie viel Aufwand steckt man jetzt in Dokumentation rein, damit ein AI das versteht und nicht Menschen das verstehen. Ja. Das gibt es ja schon viel, häufig. Ja, sehr häufig. Mit den Agents MD und hast du nicht gesehen in irgendwelchen Git-Projekten. Ja, aber ich meine auch da, man muss ja schon unterscheiden, okay, was für ein Code machen wir jetzt und für welchen Fall nutzen wir jetzt AI. Wir hatten neulich in einer Chatgruppe, ich glaube, das war auch bei uns im Tillbot in der Chatgruppe gewesen, wo einer meinte so, naja, er war in einer fremden Anwendung und musste dann Code suchen, den er durch ein LLM gejagt hat, effektiv. und dann zu sagen, sagt mir, wo ich dies und jenes finde, damit ich danach suchen kann. Also das Suchen mit einem bestimmten Kontext, das macht das schon deutlich einfacher. Du musst halt nicht mehr bei Hand gehen. Vor allem, wenn das halt das kann deine eigene Anwendung sein, wo du tagtäglich mit arbeitest, das kann aber halt auch irgendwelche anderen fremden Anwendungen sein, um da halt Sachen zu finden. Dafür ist das schon durchaus praktisch und da verlierst du jetzt nicht unbedingt Skills. Nee. Also kannst du es auch ohne machen, weil die Diskussion hatten wir dann nach Ebene. Na ja, dann hast du eine Abhängigkeit an den LM und eigentlich kannst du auch greppen und sonst was, aber es ist halt aufwendiger. Ja, man kann sich auch fragen, ob man komplett auf motorgetriebene Fortbewegung verzichtet und sagt, ich kann ja alles zu Fuß erreichen. Das kann man machen. Ja, genau. Und man kann auch sagen, ich verzichte darauf, weil ich will alles zu Fuß erreichen. Aber ob das wirklich zielführend ist, Das ist die ganz große Frage. Genau, was möchte man erreichen? Und ich meine, das ist auch ein gutes Beispiel, weil viele sehen ja auch, inklusive ich und du, glaube ich, auch AI auch kritisch von wegen, das werden halt irgendwelche Daten genommen und dafür so Copyright oder sonst was, ist ja auch völlig egal. Und welche Folgeabschätzungen werden ja auch häufig nicht gemacht. Und das hast du ja bei Autos ja auch. Ja, ja. Mit Verbrennern oder mit allen möglichen hast du ja irgendwelche Folgeabschätzungen, die du dann halt in Kauf nimmst. Ob es jetzt ein LM ist oder ob es ein Auto ist, anstatt dass du zu Fuß gehst. Beide Sachen sind Werkzeuge, die in bestimmten Kontexten sinnvoll sind und in anderen Kontexten halt nicht. Genau, beziehungsweise Nachteile mit sich bringen. Nicht unbedingt für einen persönlich, aber dann halt für die Gesellschaft. Ja, aber auch für mich persönlich vielleicht. wenn ich jetzt sagen dass ich müsste 1000 km mit dem auto fahren dann werde ich relativ müde wahrscheinlich am ende ankommen ja mal losgelöst davon wie umweltverträglich das ist gut wir fahren jetzt wir fahren jetzt ein elektroauto ist vielleicht noch mal nicht so ganz so umwelt unverträglich aber ich werde in jedem fall kaputt am ende ankommen oder ich nehme neben den öPNV obwohl das ja nicht mehr nv ist kein nahverkehr mehr ist, Ich fahre mit dem öffentlichen Verkehr irgendwo hin und komme relativ relaxed am Ende an und vielleicht noch umweltverträglicher, als wenn ich persönlich gefahren werde. Genau, und warst vielleicht schneller, vielleicht langsamer, aber dafür halt fitter. Genau, also aber... Gleiches Ding halt bei EI und LLMs halt auch. Ja, wenn ich jetzt in acht Stunden noch tausend Kilometer später irgendwo sein muss, dann muss ich mir vielleicht überlegen, ob ich vielleicht doch fliege. Ja. Ja, also dass ich das Werkzeug benutze, was ich eigentlich nicht mag. und wenn ich Zeit habe, kann ich halt andere Methoden benutzen. Und so sieht das hier halt auch, weil ich finde jetzt auch die Vorteile, wo es wenig Nachteile gibt, halt suchen, finden halt vor allem. Mit dem Kontext halt vor allem. Boiler Plating finde ich auch immer praktisch. Wenn es dann halt diverse Sachen, wenn ich Skripte schreibe und der packt mir dann schon mal die ganzen Sachen drin, dass du, die ganze Grundstruktur baut da sich dann halt auf, das ist halt schon praktisch. Finde ich auch. Den Workflow finde ich dann praktisch. Je nachdem, da muss man auch mal ein bisschen unterscheiden zwischen also das Planen davon, das Implementieren, das Testen und das Validieren. Da kannst du in ein paar Sachen natürlich viel tiefer reingucken und dann ja auch so sagen, okay, was könnte ich hier noch verbessern? Was kann ich testen? Weil Testcases kannst du ja auch generieren lassen. Das ist meistens relativ langweilig und wenn du das ordentlich aufgebaut hast, Ob mit oder ohne LLM, kannst du auch, Grundstruktur von Tests aufbauen lassen, wo du vielleicht nur noch Anpassungen machen musst und das dann halt nochmal validieren musst und so weiter. Quasi Fleißarbeit. Ja, genau. Genau, das konntest du ja so auch schon mit diversen IDEs. Haben viele halt nur nicht genutzt oder sonst was. Und vor allem, naja, das, da ich also beim Suchen finden auch gehört für mich so, naja, was kann dieser Abschnitt jetzt? Das gehört mich ein bisschen dazu. Also das Exploren von fremden Code, dass man dann so findet, okay, wie komme ich da jetzt hin? Wie hast du es bearbeitet? Wie ist das aufgebaut? Und so weiter. Das ist dann halt auch praktisch. Ich finde diesen Begriff 30.000 feet für you ganz gut. Also der Blick aus dem Flugzeug. Sag mir doch mal, welche Bereiche des Codes für welche Sachen verantwortlich sind. ja ja überblicksmäßig einfach so und dann entscheide ich mir bei welchem teil des kurs sich die flughöhe veränderung wo ich dann tiefer ein gucke ja aber um überblick zu bekommen wenn kurz gut repositorie hast was mehrere zehntausend seien code hat das durchblickst du nicht in zehn minuten ja dadurch blickst du die struktur auch nicht in fünf minuten oder in zehn minuten ja aber du kannst dir bei der struktur halt helfen lassen genau. Und da ist natürlich auch mal die Frage ist, okay, was schaut man dann nur noch das an, was das LLM ausspuckt? Oder vergisst man dann noch was, weil das LLM gar nicht drüber denkt, also thinking out of the box quasi, ne? Aber ich meine, das hatten wir bei Test Cases ja auch, ne? Sind die Test Cases, die ich habe, ausreichend um jede Zeit des Codes durchlaufen? Ja, und es gibt ja Test-Frameworks, die analysieren tatsächlich, ob die Testfälle wirklich jede Code-Zeile mal durchlaufen haben. Ja, genau, Test-Coverage halt. Ja, genau, aber auf Zeilenebene in dem Moment, genau, und nicht nur auf Feature-Ebene, sondern eben auch auf Zeilenebene. Ja, genau, aber wenn dann halt nur nur wenn der Test halt ist, schiebst du nur ein Beispiel durch, dann hast du zwar 100% Code-Coverage, aber halt nichts gewonnen. Ja, genau, genau. Du musst beides haben. Ja, was er jetzt auch noch schreibt ist, die Vorteile hatten wir jetzt gerade genannt, aber was sind jetzt so die Risiken? Und das hatten wir vorhin ja auch schon, die Code-Basis, die keiner versteht, ist halt so ein Punkt. Es bringt halt nichts, wenn es keiner versteht, inklusive einem selbst. Die kognitiven Fähigkeiten nehmen halt tendenziell eher ab. Burnout hat halt auch da mit reingenommen, weil du die ganze Zeit nur am Deliveren bist und denkst, du kannst hier schnell und Vollgas geben. hatte ich auch schon manchmal das Gefühl, okay, das ist schon irgendwie für den Kopf anders anstrengend. Wenn du die ganze Zeit was machen willst. Bei mir waren es noch mehr so inhaltlich irgendwelche Slides oder sonst was machen, aber auch da musst du natürlich gucken und dann merkst du dann, wenn sich so ein LLM irgendwo hin verrennt, dass du den halt wieder einfangen musst und dann so, okay, jetzt muss ich den wieder zurückholen und so, nein, vergiss das. Und dazu haben wir ja noch einfache Use Cases. Viele sagen, mit denen ich geredet habe, naja, es ist halt ein Junior-Entwickler, ein Azubi, Azubide, wie auch immer, der also ein Guter quasi, aber der kann halt auch nur das, was er eben sagt. Und sonst muss man halt auch gucken, dass das auch ordentlich ist und nicht irgendwo halt in die falsche Ecke verrennt und eine Rabbit Hole landet. So, dass dann halt einige Bugs aussehen, oder Features aussehen wie Features quasi. Ich ähm, Wir haben die, glaube ich, auf die schon mal verwiesen. Eine der Keynotes auf der Frostcon im letzten Jahr, in 2025, war von Daniel Stemberg, der gesagt hat, wie er herausfindet, ob eine AI ein Bugreport eingereicht hat. Und es gab zwei Punkte, die mir jetzt gerade noch in Erinnerung sind. Das eine war, dass es unfassbar ausführlich ist und dass es unfassbar viele Bullet Points gibt. Und Emojis. Und ich vermute sehr, dass es mit Code auf einer anderen Ebene genauso sein könnte, dass es halt vielleicht besonders ausführlich ist oder vielleicht besondere Mechanismen, die darin vorkommen, die eigentlich spezifisch sind für LLM-generierten Code. Ja. Warum sollte es da anders sein? Ja, ich meine, ich finde es halt auch ein bisschen irritierend, ganz bewusst irritierend, dass du mit Claude Code schreiben kannst. Und jetzt hat er ja noch Claude oder Entropik noch Claude Code Review angekündigt, wo ein Review irgendwie 10 bis 20 Dollar kosten kann oder 15 bis 25 US-Dollar. Und dann guckt er sich aus verschiedenen Ebenen an und gibt ein ordentliches, volles Review. halt zurück. Wo ich dann auch so denke, okay, du hast jetzt also Cloud Code, um Code zu schreiben, der da von dem gleichen LLM auch wieder reviewt werden, wenn auch mit anderen Einstellungen. Das fühlt sich nicht richtig an. Oder mit anderen Trainingsdaten trainiert? Keine Ahnung. Ja, das nicht. Das sind ja meistens die gleichen. LLM sind ja im F... Nackte LLM sind ja relativ dumm. Der ganze Kontext drumherum, den du mit übergibst, ist ja das Spannende. So wie wir beide. Wir sind eigentlich auch relativ dumm. Ja, sind wir auch. Und da ist es dann auch irgendwie so die Frage, so okay, Warum kann jetzt ein LLM nicht gleich den perfekten Code generieren, wenn du dann noch verschiedene Tools hast für Code-Review und für Security auch nochmal, Cloud-Code-Security gibt es auch nochmal. Das Geheimnis liegt in den 20 Franken oder 20 Dollar, die du gerade gesagt hast, dass das wesentlich aufwendiger ist. Ja, also es macht schon Sinn, das mit einer anderen anderen Prompling quasi dann halt durchzusuchen und das kann schon Sinn machen, aber es fühlt sich trotzdem falsch an, weil das ja theoretisch ja... Definitiv. Aber vielleicht wäre der Code ja auch gut, wenn man da vorher 20 Dollar reingesteckt hätte. Ja, genau. Keine Ahnung. Ich habe ja auch nicht die Details angeguckt, aber wenn theoretisch verschiedene Testcases fährt und die Anwendung irgendwie auch noch irgendwo hochfährt und dann noch macht und testet, dann kann 20 Dollar auch ganz schön günstig sein. Das ist richtig, ja. Weil wenn du bedenkst, einen Stundensatz von, keine Ahnung, von einem Entwickler von 80 Euro oder sowas, sage ich jetzt einfach mal, und ein Review dauert halt eine Stunde, wenn du es richtig machst, dann ist es halt teurer. Je nach Codemenge. Je nach Codemenge und je nach Tiefe natürlich. Und wie natürlich wie gewiss du das machst. Aber da spricht jetzt gerade der CEO aus dir, genau. Man kann ja damit Geld sparen, genau. Genau. Ja, ich hatte mit einem Kollegen gesprochen, der macht für HackerOne, HackerOne ist ja die Bug-Bounty-Plattform, also der Security-Mensch. Und der hat mir zwei Sachen erzählt, die ich spannend fand. Einmal meinte er so, naja, er ist in seiner Firma, wo er ist. Irgendwas Staff Principle, irgendwas Security Mensch, also ganz oben und einer der wenigen, weil die sind nicht so groß. Also auch internationale Firma, Venture Capital, bla bla, hast du nicht gesehen. Und in der Regel sieht es halt so aus, dass es bei bestimmten Sachen, die die Entwickler entwickeln, auch mithilfe von LLMs, dass dann die, dass dann ein Application Security Review stattfindet. Und jetzt wird da halt auch noch mal, ich weiß nicht mal, ob es Cloud Code Security war oder andere Sachen noch drüber geworfen. Ich glaube, es war Cloud Code Security. Da meint er, es findet A mehr oder mindestens das Gleiche von den Sachen, die er eh findet. Er guckt da jetzt halt auch noch mal mit drauf und guckt, ob das alles soweit richtig ist und ob da noch was vergessen ist. Aber es ist halt schon so gut, dass die sich halt sparen, neue Leute nur für diesen Use Case Application Security mit. mit abzudecken. Weil das jetzt halt ein LLM schon und er sagte, er sieht es dann halt schon, dass das, dass man diese Rolle nicht zusätzlich braucht, beziehungsweise deutlich weniger braucht. Auch als einer, der das eher so ja nicht den Hype hinterher rennt, wie wir halt. Das halt Werkzeug dann halt sieht. Und der meinte halt aus, naja, der macht halt für HackerOne dann halt auch Reviews von irgendwelchen. Firmen, die dann Code da hochladen und er macht dann ein Review davon und wird pro Minute oder sowas bezahlt oder in einem 5-Minuten-Takt bezahlt, was für ihn halt so Nebeneinkommen ist. Er glaubt, das wird weggehen, weil das sind dann halt kleinere Firmen, die Geld haben, aber nicht unbedingt die Leute haben, die das dann halt rausgeben, um so ein Review machen zu lassen und das sind meistens sehr kleinere Sachen, wo du halt in 15 Minuten durch bist und das kannst du dann halt eher auslagern. Und dann sind es halt billiger, es ist halt billiger als 20 Dollar bei Klott reinzuwerfen, als es selbst zu machen. Ja. Dass es nicht immer alles richtig ist, das kommt auch hinzu, aber auch Menschen erfinden nicht alles. Auch Menschen machen auch Fehler, genau. Genau, oder sind faul oder was auch immer. Oder nicht gut. Ja. Und ja, dann ist auch immer die Frage, was heißt das jetzt für den Engineer? Du bist jetzt nur noch der da, der auf OK drückt. Alles klar, ausgenehmigt. Die Skills ändern sich schon. Also ich glaube, das wird sich auch finden. Wir sind ja momentan, wir haben das, glaube ich, schon mal angesprochen, vielleicht auch im anderen Kontext. Gartner definiert ja so ein Hype-Cycle, wir sind momentan auf der Spitze dieses Hype-Cycles, irgendwann kommt das große Tal der Verlassenheit oder wir nennen es glaube ich Tal der Disillusion, Valley of the Illusion oder sowas und danach pendelt sich das auf einen vernünftigen Wert ein. Also ich glaube, wir sind gerade momentan genauso wie früher bei Blockchain, wo es dann irgendwelche Tools gab, die mit drei oder vier oder fünf Blockchains dahergekommen sind. Mittlerweile sieht man kaum noch Anwendungsfälle für Blockchain. Das ist halt ein Hype-Thema gewesen. Genauso ist es mit AI. Es ist im Moment sehr, sehr stark gehypt und es werden sich die Use Cases herauskristallisieren, die auch sehr gut damit umzusetzen sind. Es wird nicht wieder weggehen. Ja, ich meine, es ist ja ein bisschen so, als wenn du bei der Dotcom-Blase gesagt hättest, ah ja, jetzt ist der Hype weg und es wird keiner mehr Computer brauchen. Es gibt kein Social Media mehr, zum Beispiel, ja. Ja. Genau. Ja, soweit dazu. Und ich würde direkt mal auf meinen Medientipp drüber switchen, weil es geht nämlich Hand in Hand mit, eigentlich sind es beides Medientipps als eines Blogposts. Und das andere ist jetzt eine Studie von Entropic selbst. Da musst du natürlich auch wieder aufpassen, so wen glaubt man jetzt? Die fand ich aber auch spannend zu lesen, weil die haben sich das dann auch mal angeguckt, also so als Studie dann halt gemacht. Ich kann jetzt schlecht einschätzen, wie gut das Studiendesign ist, weil dafür bin ich nicht Wissenschaftler genug. Aber da geht es halt darum, okay, was für einen Einfluss hat jetzt ein AI-Assistance auf die Coding-Skills für einen bestimmten Use-Case. Die hatten jetzt nur, in Anführungsstrichen, 52 Junior-Devs. Also das hat auch nur einen bestimmten Fall abgedeckt, nämlich Junior-Devs. 52 ist auch nicht so unfassbar groß. Das waren Leute, die haben Python für mindestens ein Jahr, mindestens einmal die Woche genutzt, dass sie so eine gewisse familiär sind mit Python. Dass sie auch schon Erfahrungen mit AI hatten, aber keine Erfahrungen mit der Trio Python-Library. Keine Ahnung, was das für ein Library ist. Und da haben sie halt eine Kontrollegruppe gehabt mit AI und ohne AI und haben dann halt mal geguckt, wie arbeiten die denn und was kommen da für Ergebnisse raus. Das fand ich spannend, dass wir den Use Case mal eben zu sehen, weil effektiv haben die zwei Sachen angeguckt. Einmal halt, wie schnell sie neue Skills auf, also die Auffassfähigkeit von neuen Skills ist, in dem Fall eine Python-Library, sowohl mit als auch ohne AI-Assistance. Und das andere ist so, naja, verstehen die auch den Code, den du AI gemacht hast oder den sie selbst gemacht haben. Besser? Da gab es dann auch so ein Quiz da drin. Ich habe mir jetzt eher nur die Zusammenfassung von denen angelesen. Ich habe jetzt nicht die komplette Studie durchgelesen, muss ich dazu sagen. Und was spannend war, ist, dass im Durchschnitt war die AI-Kontrollgruppe schneller, aber um zwei Minuten. Und das war statistisch nicht signifikant. Okay. Und wenig überraschend war in dem Quiz, um zu gucken, ob man das richtig verstanden hat, war die Nicht-AI Gruppe besser, mit 67 Prozent versus 50 Prozent bei AI. Da gehen die noch mal ein bisschen auf die Details ein, so okay, was, die besonders schlechten angeguckt und die besonders guten angeguckt. Und was da halt auch mal auffiel, ist so, naja, theoretisch generiert ja eine AI schnell Code, aber dass die Leute, die halt AI genutzt haben und dann zwar auch schneller waren, dass sie halt mehr Zeit mit dem Chatten, mit dem Chatbot, gegangen sind. Während bei den Leuten, die AI-Assistance halt nicht genutzt haben, dass die halt Try- und Error- und Debugging halt gemacht haben. Und gelernt haben durch Versuchen-Fehlschlag. Genau. Und das kostet ja auch Zeit, genauso wie es die richtige Prompt mit mehreren Iterationen dann halt auch hinzukommen. Weil die ganze Diskussion, die du einfach mit dem Chatbot hast, kostet auch Zeit, darf man nicht vergessen. fand ich spannend, weil hab ich auch so nicht drüber nachgedacht, dass das Tippen und Überlegen, was du da genau eintippst, die auch Zeit kostet, genau, und die haben halt auch nochmal Unterschieden zwischen Debugging, Code Reading, Code Writing und das Konzept und, genau, ich guck gerade noch, was ich vergessen hab genau, die AI-Gruppe hat mehr gepromptet, was auch Zeit kostet, non-AI war mehr am Testen und Debuggen, kein signifikanter Unterschied. So, und dann haben sie halt angeguckt, was haben jetzt die Leute gemacht, die schlechte Ergebnisse geliefert hatten. Die haben halt komplett das Schreiben und vervollständigen der Aufgabe halt eine AI übergeben. Und das hat dann halt das Fatsache das Schnellste, aber nicht unbedingt immer ohne Fehler. Überraschend, überraschend. Ja, sehr überraschend. Einige haben natürlich mehr Fragen gestellt, also mehr gepromptet effektiv dann halt auch aber trotzdem waren dann teilweise die Ergebnisse bei dem Quiz dann halt auch sehr schlecht, weil sie die Konzepte nicht verstanden haben. Wir sind ja immer noch bei den schlechten Interaktionen und dann gibt es nochmal Leute, die iterativ das gemacht haben, die waren zwar, die hatten zwar auch ähnliche Ergebnisse, waren aber deutlich langsamer, um diese Aufgaben fertigzustellen. Das ist schon spannend. Ja, und wenn ich so über nachdenke, ist das jetzt nicht so überraschend. Ich meine, das war jetzt aber auch die Nutzerzahl, weil es bei diesen drei Sachen, die ich genannt habe, das waren auch vier Leute jeweils. Das ist jetzt nicht super viel, aber man kennt es effektiv. Ja, und unsere Liebstingsdoktorin der Chemie sagt ja, wir sollten denen eh nicht vertrauen, wenn es keine Langzeitstudie ist. Genau, und wenn es halt eine signifikante Größe ist. Ja. Genau, und dann hatten wir natürlich noch mal geguckt, naja, die, die gut abgeschnitten haben, da gab es halt auch noch mal drei verschiedene Leute, sowohl AI als auch nicht AI, und da gab es, beziehungsweise AI, so nur um die AI, dann haben Leute was generieren lassen, haben aber auch noch mal Zeit reingesteckt, um das richtig zu verstehen, und da kannst du ja auch noch mal Fragen stellen. Das kannst du halt einmal generieren, um dann versuchen zu verstehen, in den Codeleas, die haben ja natürlich auch die Leute beobachtet, Das kannst du auch aber als hybriden Modus machen, dass du Code generierst und dir das erklären lässt. Hilft auch. Und das andere war dann halt auch mehr, den Konzept halt auch eben stärker zu erfragen. Die waren dann auch besser im Verstehen. Was ja auch ein bisschen, und das reicht glaube ich auch an der Zusammenfassung, mehr habe ich nämlich noch nicht aufgeschrieben, ist, dass wie du mit dem LLM arbeitest, an einem Source-Code, macht halt schon einen Unterschied. Ja, ja. Was wir gerade in dem anderen Teil halt auch nicht hatten. Ich finde das ganz interessant, dass sich da so ein kleiner Kreis schließt. Ich habe ja vor ein paar Wochen oder ein paar Folgen das Buch Hidden Potential empfohlen von Adam Grant. Und eins der Findings war ja, dass man am besten lernt, wenn man die Komfortzone verlässt. Und wenn ich das jetzt vergleiche mit der Studie, ist das Prompten dann halt in der Komfortzone bleiben. Man muss sich selber nicht damit auseinandersetzen. und wenn man nicht promptet, dann ist es halt unbequemer, man verlässt die Komfortzone und lernt dann wieder mehr. Also das unterstützt die These quasi. Ja. Ich meine, ich glaube schon, dass sich das noch deutlich weiter verändert wird über die Zeit. Auf jeden Fall. Also das wird ein Einfluss auf die Arbeit sein, wie du mit wie du Software entwickelst effektiv oder Softwareprojekte gestaltest, also die Entwicklung dafür gestaltest, Entwicklung und Betrieb gestaltest, wie genau wird sich zeigen. Aber ich glaube, dass die Leute, die eh schon, also wenn man jetzt mal wirklich drüber nachdenkt und sagt, okay, was für Leute haben eher ein Problem, einen Job zu finden, dann glaube ich, sind das die Leute, die generell nicht so tief nachdenken, nachgedacht haben, egal ob mit oder ohne AI, die werden durch AI erst recht abgehängt. Ja. Ja, gut möglich. Für mich muss ich sagen, es verändert der Weg, wie ich Sprachen lerne. Wenn ich jetzt mal sehe, ich lerne ja gerade Types. Und ich lasse mich da auch massiv durch AI unterstützen bei Types. Ich habe da konkrete Beispiele, die ich gerne umsetzen möchte. Und ich lasse mir dann den Code von der AI generieren, versuche den im Nachhinein zu verstehen. Wenn ich früher geguckt habe, dann habe ich halt das versucht zu machen und habe dann in die Doku geguckt, wie ich das umsetzen kann. Das Gucken in die Doku wird jetzt zum Gucken im LLM. Ja, beziehungsweise das, was du dem Output halt angucken. Ja, genau. Und auch dein Output erklären lassen. Aber das ist das, was du gerade sagtest, dass die Leute besser abgeschlossen haben, die es den Code haben, auch nochmal erklären lassen, dieses Hybrid Coding. Ja, ja. Genau, ich meine, das ist ja auch nochmal ein Nachtrag zu dem, was ich ja letzte Folge auch erzählt hatte, mit Cloud Code und Types, das hast du dann ja auch rausprobiert. ich gucke da gar nicht so sehr auf den Code drauf also nur so viel wie viel ich auch anpassen muss, damit das rauskommt was ich haben will, also das ist wirklich Output generiert, Output orientiert bei mir, aber wenn ich jetzt wieder anfangen würde, da einige Sachen dann rauszuziehen, in das Theme zu packen um das reusable zu machen dann muss ich das schon wieder mehr verstehen auch wenn LLM da hilft hilft. Ja, aber ja, wird doch spannend. Ja, finde ich auch. Gut. Und nun zu etwas völlig unterschiedlichen, zu dem, was wir jetzt gerade gesagt haben. Ich habe ein Kurzvideo zu empfehlen, das hat noch nicht immer vier Minuten, das Kurzvideo ist überschrieben mit What are Simple Rules, also was sind einfache Regeln. Und da geht es halt darum, wenn man sich einfache Regeln auferlegt, dann trifft man auch unter schwierigen Bedingungen gute Entscheidungen. Und das gilt beruflich wie auch privat. Und die Kathleen Eisenhardt bringt halt Beispiele dafür, was einfache Regeln sind. Erste Sache, simple rules are simple. Also einfache Regeln sind einfach. Und es gibt nur ein paar davon, also maximal zwei bis fünf. dann einfache Regeln sind einzigartig und auf die Situation angepasst und einfache Regeln sind Aktivitäten basiert, also basieren auf Aktivitäten Okay. Hast du Beispiele? Ja, ich komme jetzt zu den Beispielen, die auch aus diesem Talk sind natürlich, Es gibt drei Food Rules von Michael Pollan Ich weiß wirklich nicht, wer Michael Pollan ist das habe ich nicht recherchiert, und er hat halt gesagt, isst nur das, was deine Großmutter, kennen würde, also what your grandmother would recognize, es is überwiegend Pflanzen und isst nicht zu viel. Der Fokus ist einfach nur auf gesunde Ernährung. Genau, das ist in dem Moment der Fokus auf gesunde Ernährung und es sind einfach drei Regeln, die garantieren, dass du dich einfach gesund ernährst. Okay. Und was wie Großmutter alles erkennt, das sind halt nicht prozessierte Lebensmittel, also nicht industriell prozessierte Lebensmittel zum Beispiel, sondern einfach das, was man kennt. Und um zu kennzeichnen, dass das auch auf die Situation angepasst werden kann, also was man einem Football-Team zum Beispiel sagt, ist, sieh zu, dass du immer hydriert bist, also dass du immer genug Wasser getrunken hast. Da ja die meisten Football-Teams aus Studenten bestehen, sagt man, ess jeden Tag Frühstück, weil die meisten Studenten pennen viel zu lange und vergessen, dass Frühstück meist. Und ess nur Dinge, die du sammeln, ernten oder töten kannst. Hä? Ja, also du kannst jetzt nichts industriell Gefertigtes sammeln. Ah, ja, okay. Also natürliche Lebensmittel, das zielt auf natürliche Lebensmittel. Ja, ja, ja. Michael Pollan hat ja gesagt, dass du überwiegend Pflanzen essen sollst und er wird eben auch gesagt, dass du auch Fleisch essen kannst zum Beispiel. Ja, genau, das war ja die Anpassung an die Aktivität, dass du mit Waldes Football Team bist, ja. Ja, genau. Und dann hat sie noch ein Beispiel gebracht, was sich ganz interessant fand. es gibt halt diese beiden crowdfunding-plattformen indiegogo und kickstarter ja indiegogo hat eine ganz einfache regel du kannst alles auf indiegogo bringen wenn es die den rechtlichen rahmen nicht kaputt macht also ganz alles auf indiegogo die finanzieren lassen wenn es legal ist ja alles, bei kickstarter musst du sachen einreichen und die kuratieren dass die entscheiden sich ob sie das wirklich kickstarten wollen oder nicht die hat dann im nachhinein verglichen mit android Ökosystem versus IOS Ökosystem. Bei Android ist es halt nicht so stark reglementiert wie bei Apple. Bei Android kannst du halt alles draufbringen. Das wird sich ja jetzt auch bald ändern. Ja, aber tendenziell ja, Android ist deutlich offener als Apple. Ich fand die Idee von Simple Rules einfach super, muss ich sagen, sich vielleicht auch mal zu überlegen, welche einfachen Regeln man sich selber auferlegen kann, um Sachen nicht zu kompliziert zu machen. und fand die Beispiele auch gut. Das Buch gibt es, glaube ich, noch als Kindle-Buch. Das werde ich mir, glaube ich, kaufen und durchlesen. Ja, ich überlege gerade an meine Ultramarathons. Da gibt es ja auch ein paar simple Rules. Nämlich auch während des Ultramarathons selbst regelmäßig trinken, regelmäßig essen, auch wenn du keinen Hunger hast, auch wenn du keinen Durst hast. Viele Kohlenhydrate. Genau. und halt möglichst wenig, Pausen machen. Also, ja, wobei, das kommt ein bisschen drauf an, aber halt möglichst in Bewegung bleiben und nicht zwei Sacken an Verpflegungsstellen. Ja, genau. Und das war das Problem bei meinem ersten Ultramarathon, den ich gemacht habe. Da habe ich mich versackt bei irgendwelchen Verpflegungsständen. Ich habe zu wenig getrunken, ich habe zu wenig gegessen. Vor allem, wenn ich essen war. Aber ich finde das ganz spannend, wenn man sich mal Gedanken darüber macht. Es gibt, glaube ich, sehr viele Bereiche, wo man sich einfache Regeln auferlegen kann. und wenn man sich an die hält, dann geht es einem gut. Auf die eine oder andere Art. Ja, gute Schlafhygiene sind auch drei Regeln. Nicht zu viel Wasser vorher trinken, keine Bildschirme kurz vorher oder eine Stunde vorher. Kein Blaulicht, genau. Blaulicht ist übrigens gar nicht so relevant. Ja, ich hatte irgendwo das gelesen gehört, dass die also A ist die Studienlage total dünn beziehungsweise nicht die Studienlage, sondern wie viele Leute da mitgemacht haben, war sehr gering. Und das Problem war nicht das Blaulicht effektiv, sondern eigentlich nur, dass je mehr Farben und Interaktive, je mehr dann Gehirn aktiv ist. Das hat nichts mit dieser Bildschirmfarbe zu tun. Wieder was gelernt, ja. Aber ich habe dich unterbrochen. Ja. Regeln für Schlafhygiene. Genau, und kein Handy halt in der Nähe haben. Ja. Aber es sind ja auch nur drei Regeln oder sowas. Ja, nicht kurz vorm Schlafen gehen essen und kein Alkohol trinken. Ja, ja. Das wird mir noch einfacher. Ja, genau, das gehörte für mich zu, nicht zu viel trinken vorher. Ja, ja. Weil sonst musst du wieder nachts auf Toilette. Ja, aber Alkohol selber macht ja den Schlaf nicht gesünder. Ja, genau, das sowieso. Das hemmt ja die Tiefe. Ja, genau. Ja, für mich ist Alkohol halt eh nie relevant, von daher denke ich auch nie dran. Für mich schon, aber ich trinke auch nur einen Liter, nein, gar nicht wahr. Nur einen Liter pro kurz am Schlafen gehen. Ich wollte sagen in Maßen, aber das ist, in Bayern ist ja ein Liter Krug. Nein, ich trinke nicht, so viel Alkohol trinke ich nicht, glücklicherweise. vielleicht einmal die Woche oder so, ein bisschen. So oft. Gut. Kommen wir zu den Tooltips. Dieser Kurzvortrag lohnt sich. Vielleicht lohnt sich auch das Buch, das werde ich noch rausfinden. Ja, wahrscheinlich war das Anhören von dem Abschnitt länger als das Video selbst. Ich vermute auch was. Ja, genau. Tooltips. Schon wieder was mit LLMs? Nein, nicht schon wieder. Und zwar, das hatte jemand in der Tilpott Matrix Gruppe gepostet. nämlich LLM-Fit und das ist ein Tool, womit du was auf deinen Rechner ausführen kannst, um nachzuschauen, welche LLMs passen auf deine Hardware quasi von der Größe her. Es gibt etliche LLMs, die du da halt reinladen kannst, theoretisch, aber du weißt halt nicht immer, es ist zu groß, zu klein, was auch immer. und wenn es halt zu groß ist, dann kannst du entweder gar nicht starten oder es ist halt so langsam, dass du jeden Buchstaben einzeln aufploppen siehst. Und dann kannst du da halt ein bisschen gucken und da machen wir einige, sind auch extra einzelne Use Cases, für was du dann filtern kannst, um dann eben zu gucken, was möchtest du dafür haben. Weil für einige Sachen oder für viele Sachen brauchst du auch keine große, kein großes LLM. Also Texte zusammenfassen oder sowas, jedoch Kleineres, auch wenn die Qualität dann auch nur leidet. Genau, kann man sich angucken, wenn man es braucht, ansonsten halt nicht. Sehr cool. Ich habe auch noch einen Tooltipp, das ist Typesetter. Typesetter gibt es als Flatback beispielsweise. Das Typeset ist ein Editor für Types und es hat eine Echtzeitanzeige dessen, was man da gerade tut und es ist wirklich Echtzeit in dem Moment, wo man auf der linken Seite im Editor was tippt, erscheint es auf der rechten Seite im Text, im Types generierten Text. Naja, also wie so ein PDF, wie quasi dann rechts. Ja, bloß Echtzeit. Also mein normaler Workflow sieht ja so aus, dass ich ein Typeswatch auf eine Datei mache, dann wird halt überprüft, ob die Datei ändert. In einem anderen Fenster habe ich halt mit Okular das PDF offen und dann habe ich einen Editor offen und immer wenn ich beim Editor auf Speichern drücke, dann macht das Typeswatch, kompiliert das dann und der Okular zeigt mir dann das, das fertige PDF an. Das ist so die eine, so mache ich Präsentationen in der Regel. Ja, ich auch. Im Typesetter ist es so, dass man einfach die Types-Datei aufmacht und dann live sieht, was damit passiert. Ja, ja. Ohne, dass man es speichern muss. Also einfach während des Tippens. Ja. Das, benutze ich im Moment wieder weniger, aber ich habe es eine Zeit lang benutzt, als ich die Types-Syntax noch nicht so hundertprozentig drauf hatte. Da habe ich halt Syntaxfehler sofort während des Tippens gesehen. Ja, ja. Ja, und du siehst das dann ja auch direkt in den Text, ja dann auch, wenn irgendwas aus zu groß, zu klein, was auch immer ist. Ja, genau. Oder wenn es, also kursiv ist zum Beispiel mit Unterstrich vorne, Unterstrich hinten, was ich nicht wusste und ich habe es jetzt mit dem Stern vorne und dem Stern hinten gemacht. Aber es war es dann fest. Ja, ich auch. Jedes Mal, diese Fehler. Ja, und sowas sieht man dann halt direkt, da muss man nicht erst kompilieren und dann es hinterher wieder editieren, sondern das sieht man sofort. Ja, ja. Gut. Gut, gut. Dann... War es das für diese Folge? Sehr LLM-AI-lästig. Ja. Ja, bleibt eigentlich nur zu sagen, kommt in die Matrix-Gruppe. Da ist viel los. Und frohe Ostern. Wenn ihr kurz nach Veröffentlichung euch das anhört. Genau, wann ist denn Ostern, genau. Ah ja, es ist ja dann ein paar Tage danach. Ja, genau. Zweiter, dritter oder so. Gut. In dem Sinne, bis zum nächsten Mal. Morgen, Nacht, Mittag, wie auch immer. Schöne Tageszeit. Schöne allgemeine Standard-Frost-Girl. Bis dann. Tschüss.