Ingo Eichhorst — „Das Eichhorst Prinzip“

Eichorst Principle. Ich glaube, du hast es nicht so genannt, sondern es war Ralf D Müller, glaube ich, der es so genannt hat. Es ist mir ein bisschen peinlich oder ein bisschen unangenehm, muss ich sagen. [musik] Herzlich willkommen zu einer neuen Folge unserer neuen Staffel von Namenze Beyond Pippecoding, der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.

Ich bin Sebastian Heidemier zu Erpen, CTO bei North und ich bin Andre Neubauer, CDPO bei Trusted Shops. Schön, dass ihr wieder da seid. Heute geht's ums Rauschen. Ähm und auch ein bisschen darüber hinaus.

Wir haben mal wieder eine bisschen technischere Folge und zwar werfen wir ein Blick darauf, wie LMs funktionieren und wie man bessere Ergebnisse erzielt. Genau. Unser Gast von vor ein paar Folgen Ralf D Müller hat uns auf das Eichhorst Principle aufmerksam gemacht und den Erfinder von diesem Prinzip haben wir uns für die heutige Episode auch gleich eingeladen. War wieder eine wahnsinnig spannende Folge.

Ähm freut dich drauf und jetzt viel Spaß beim Hören. Herzlich willkommen, Ingo. Ähm wir freuen uns, dass du da bist. Äh, wir haben ja neulich mit Ralf gesprochen und der hat das Ing Eichhorst Principle hat das glaube ich genannt angesprochen und uns gleich empfohlen, ladet doch mal den Ingo ein und das haben wir uns gedacht, machen wir doch einfach mal und jetzt bist du da.

Wir freuen uns. Stell dich gern unseren Gästen einmal unseren Hörern einmal kurz vor. Mega. Äh ja, Ralf ist äh ist äh Klasse.

[gelächter] Ralf macht's großen Spaß, die Welt der KI zu erkunden, aber natürlich auch mit allen meinen anderen Projekten äh, die ich so am laufen habe. Und meine Historie ist, ich habe schon als ja als Tini quasi angefangen, wahrscheinlich schon bevor ich Tini war, ähm mit meinem ersten C64. Mein Vater hat mich da so ein bisschen rangeführt, hat gesagt, das ist eine coole Idee, macht das und ja und darauf dann kleine Programme geschrieben, irgendwie so in die IT-Welt reingekommen, dann ein bisschen abgedriftet. Im Uni war habe ich BWL studiert und bin dann erst später dann in einem anderen Studiengang dann wieder an die Informatik rangeführt worden.

Das heiß, ich habe auch am Anfang als Projektmanager gearbeitet und bin dann später wieder an die in die Basis zurückgegangen. eigentliches entwickeln, programmieren, da PRP gemacht, JavaScript auch C ähm Kunterbund, alles mögliche ähm auch Defops mal eine ganze Weile. Und 2019 habe ich bei uns in der Firma die damals die ähm CTO Rolle übernommen. Wir haben so Online Streaming Angebote gehabt damals.

Hauptsächlich sind wir so ein bisschen äh weggegangen von von klassischem Livestreaming und klassischem Video on Demand hin zu mehr Advertisement und dynamische Werbeinsertierung und genau da habe ich die CTO Rolle übernommen, kleines Team aufgebaut ähm von einem Entwickler auf zehn Entwickler und ja genau das Unternehmen wurde dann irgendwann verkauft und ähm das war irgendwie meine Chance, meine Gelegenheit äh mal was anderes auszuprobieren. Dann habe ich in der Beratung gearbeitet und ähm ersten Jahr Banken äh Bereich und Stiftung. Das war super spannend und da ist dann das war so 2022 und ich hatte davor schon mal Beta Tester bei GTA Copilot und habe die Image Modelle ausprobiert und dachte okay krass da entsteht wirklich was. Ja, man sieht hinter mir sieht man noch die Bilder die so mit einer ganz frühen Midrainy Version entstanden sind.

Ähm es ist ja alles noch nicht lange her, ne? Aber es kommt halt schon echt vor wie eine Ewigkeit und ja und da war ich extrem begeistert. M und das hat mich gecatcht und deshalb gab es dann noch eine Möglichkeit und habe ich kurz für KPMG gearbeitet, weil diese Firma dann wieder aufgekauft wurde und dann gab es die Möglichkeit in Deutschland ein KI Team generative KI äh Projekte aufzubauen auch für eine Beratungsfirma. Ähm und ja, das habe ich dann genommen.

Das war meine Chance und genau das habe ich ein Jahr lang gemacht. Äh, dann irgendwann ist den aufgefallen, kein Geld aus eine japanische Firma und die haben irgendwann kein ist ih aufgefallen, dass das Geld ausgegangen ist, weil den Banken ist das aufgefallen und dann musste sie ein paar Büros schließen. Das waren natürlich die, die noch keine schwarzen Zahlen schrieben und da wir erst irgendwie ein Jahr am Berkeln waren, ihr wisst ja, solche Dinge dauern ein bisschen. Mhm.

äh waren wir da halt eben von mit betroffen und dann war dann die Überlegung, okay, entweder ins Ausland gehen äh dort ähm dann in der Beratungsfirma hinterher oder halt eben hier in Deutschland äh was suchen und genau und damals, das war so 20, da war die Frage so, in welche Richtung soll es gehen? habe ich mich auch bei Alf beworfen. Also, ich wollte schon gerne in dem KI Bereich bleiben und bei Jonas war halt das Spannende, ähm da gab's halt sowohl den ganzen KI Bereich als Austrobefeld, ne, das ist gerade entstanden und größer und größer geworden, aber halt eben auch das Programmieren, Entwickeln mit Agenten und mit KI Systemen, gut, Agenten waren damals, also es gab schon Agenten, ich hatte 2024 Frühling einen Vortrag über KI Agenten, der eigentlich relativ nah an dem ist, was wir heute als KI Agent verstehen. Ja, weil damals hat halt noch niemand drüber geredet und ähm ja und und dann war die Überlegung, okay, wenn ein Safe Play ist Infrastruktur auf jeden Fall, weil wenn jeder programmieren kann, dann was brauchen die, ne?

Die merken dann irgendwann auf Local Host ist halt schwierig von außen zuzugreifen und dann brauchen sie Server und äh also probieren wir das doch mal. Und jetzt bin ich hier wirklich äh bei Jonas Happy und ähm das ist äh das ist wirklich cool. Kann da natürlich nicht wirklich tief über was sprechen heute. Ich bin aber nebenbei noch äh so beratener CTO bei einem Startup in in den Staaten.

Das macht auch großen Spaß und berate und mache so nebei so kleinen Schulungen noch für Partnerunternehmen, für einfach Leute, die ich irgendwie kenne über die Zeit und daraus kann ich berichten und dann habe ich noch ein kleines Open Source Projekt, was gerade in der in der Entstehungsphase ist und da kann ich auch gerne berichten, weil da mache ich was, das habe ich jetzt Highspeed Open Source getauft und da kann ich gerne ein bisschen was von erzählen. Ja. Ja, cool. Bevor wir bevor wir da reinspringen, ich muss trotzdem die Chance nutzen.

Was macht ein Engineering Trainer Dayday? Wie muss ich mir das vorstellen? [räuspern] Ja, ich glaube, das ist schon eine sehr ähm also eine wenig verbreitete Rolle. Absolut.

Deswegen frage ich, also äh vielleicht lernen wir was. Ja. Ja. Bei mir war das, also ich wusste das vor quasi zwei Jahren hatte ich davon auch keine Ahnung, dass es das überhaupt gibt.

Ich habe damals dachte ich so, um sich neues Wissen anzueignen, guckt man halt YouTube Videos. Äh, das ist halt schwierig bei größeren Firmen, wo halt viel auch noh in den einzelnen Bereichen sitzt und man quasi Silobildung vermeiden möchte und nicht jeder ist halt Rechtsexperte auch äh oder weiß genau Bescheid, über welche Tools sollen jetzt für welchen Zweck eingesetzt werden. Und ich verstehe meine Rolle so ein bisschen als Brückenbauer. Das heißt, ich sorge dafür, dass dass Teams, die vielleicht schon was entworfen, vielleicht schon äh was gebaut haben, ähm dass diese Lösungen halt eben auch durch andere Teams genutzt werden können.

Und ähm genau, also ich bin auch selber in Entwicklungsprojekten mit beteiligt, äh einfach damit ich nicht einstaube zu dolle [gelächter] und äh auch, dass ich immer was habe, was ich mitnehmen kann und gucken kann halt eben wie auch die Sachen umgesetzt werden in meinen Trainings. Und dieses Jahr habe ich viele Workshops gemacht zum Thema agentische agentisches Programmieren, Pieren mit KI Agenten. Ähm jetzt auch mehr und mehr Harness Engineering. Ähm und ja und das geht von den Basics ähm bis bis wie gesagt zu dem, was gerade so Dark Factory, was gerade so äh gerade am Rand irgendwie erkennbar ist und anfängt möglich zu sein und dann mit anderen zusammen Konzeptar arbeiten, aber halt eben auch durch Workshops führen, ähm ja, Konzepte trainieren und äh diese Brücken bauen halt und und Herons biete ich auch noch an.

Das ist immer gerne genommen und finde ich auch cool, weil dann habe ich nicht ganz so viel zu tun. Äh in den Workshoptagen stehe ich dann da und quatsche viel und begleite dann bei den bei den einzelnen Sessions. Äh Hackertons sind immer ein bisschen bisschen entspannter. Äh verstehe ich spannend.

Äh gibt's ein Trainer oder wie viel Trainer gibt's? Ähm ja, also [räuspern] genau, also ich bin quasi der Engineering Trainer. Ich bin auch, also Jonas ist sehr groß, könnt ihr euch vorstellen, wir wir also wir haben ja extrem viele Brands, die dazu gehören aus unterschiedlichen Ländern und [räuspern] ich bin jetzt im Cloudbereich verortet, aber ja, versuche auch da natürlich immer mal ein bisschen links und rechts zu schauen, aber das ist so so mein Hometurf. Okay, genau.

Cool, spannend. Danke dir. Total. Äh, ich hätte jetzt irgendwie fünf Volge Fragen, die würden aber, glaube ich, unseren äh unseren Rahmen hier ein bisschen springen.

Deswegen äh da kommen wir bestimmt später äh noch auf das eine oder andere zurück. Ähm lass uns wie üblich einsteigen mit der ersten Rubrik, dem Text. Du hast ja auch gesagt, du bist auch in Engineering Projekte involviert, ne? Hast Open Source Projekte.

Das heißt, du dein Text ist tatsächlich auch oder Toolstack ist tatsächlich auch ein äh Coding oder Engineering relatierter Toolstack. Genau. Äh was nutzt du, wie arbeitest du, welche Skills, was auch immer. Ja.

Ja. Ja. Also, ich hatte ja schon kurz angesprach, also jetzt privat, was jetzt das verrückteste ist, würde ich sagen, was ich gerade mache, ist so ein Projekt ein Open Source Projekt, das heißt Earlicht und ähm da hat man quasi in seiner Menülist Leiste auf macOS erstmal irgendwann dann auch noch auf mehr Betriebssystemen, man dann quasi so eine Anzeige, also einfach ein Licht, ein Lämpchen für jeden Agenten, den man hochfährt. Wenn man einen Agenten hat, dann hat man halt ein Licht.

Wenn man zehn Agenten hat, dann hat man halt so ein Aggregat. Ähm und ähm die also die gruppieren sich dann auch nach Projekten und äh helfen einem einfache Orientierung zu schaffen, welche Agenten gerade arbeiten, weil ich war super angenervt und habe Netflix Filme geschaut und musste dann immer wegwischen auf dem MacBook, um zu gucken, ob die Agenten schon fertig waren und dann hat man mehrere Agenten auf Mar Screens laufen, komplett äh die Übersicht verloren und das hilft mir jetzt sehr. Genau. Und das bau ich halt, dass du auch Pie unterstützt.

Gut finde ich, dass du auch den Pi Agent unterstützt. Ja, das war der einer der ersten. Also, ich glaube mit äh Cloud Code, klar, das muss man halt. Ähm Pie und ähm Codex habe ich angefangen, weil das sind meine Treiber, meine täglichen Treiber.

Ähm und genau und jetzt jetzt meine erste Contribution von extern ist jetzt eingetroffen gerade heute, die muss ich noch reviewen. Also, die habe ich schon einmal gereviewt, aber jetzt ist sie noch mal gefixt, eingereicht worden. Und das ist Open Code, also auch ein ganz klasse äh ganz klasse Agent. Genau.

Und dann sollen kommen da noch Agenten Orchestrierung mit rein, also jetzt Gestown z.B. oder Cloud Squad. Also das wächst und ich glaube auch da wird's eine Menge zu tun geben in nächster Zeit. Genau.

Ähm und das ist ähm vom Texttech her hauptsächlich entwickelt mit Cloud Code, ein bisschen Codex, ein bisschen P für ganz für unterschiedliche Anwendungsä Zwecke. Und äh vom vom also von der Pur Miersprache habe ich ein Back and Golang, das habe ich einfach rausgefunden, das ist irgendwie das gefällt mir am besten Koningagenten, weil das so schön idiomatisch ist, so schön klar, was gut ist und was schlecht ist. Das hilft den Agenten gut sich zu orientieren und ähm im Frontend nehme ich whatever. Also das ist meistens sind es eher Sin Cliance und dann ist es mir eigentlich wurscht äh was es ist, weil das kriegen die Agenten einfach so one shot meistens relativ gut hin, was ich von ihnen haben will.

Alte das Thema rund um Golang, das hatten wir auch schon mal Laubert Stefan tatsächlich mitgebracht. ähm wahrscheinlich sogar mit in der ersten Folge. Äh habt ihr das hast du da irgendwie so empirische Daten? Also, hast du also hast du dir Erfahrung gesammelt, dass wie bist du da drauf gekommen?

Lassen mich es offen fragen, wie bist du darauf gekommen, dass Golang quasi für dich da der beste Pick ist? Ja. Ähm, gute Frage. Also ähm ist es auch eine Sprache, die bei Jonas verbreitet ist, muss ich sagen.

Also von daher so ein bisschen natürlicher Catch auch gewesen, weil ich eh besser in Golang werden wollte. Ähm, aber [räuspern] und es gibt auch Untersuchung zu dem Thema Studie und zu dem Thema, welche welche Programmiersprache ist am besten geeignet und da schneidet in der Regel Go nicht als beste Programmiersprache ab, weil einfach der der Footprint noch nicht groß genug ist, ne? Die meisten Issues auf Stack Overflow ähm sind einfach JavaScript oder Python und deshalb sind diese Sprachen viel besser geeignet, aber die Studien, die gucken sich Onehot Shot Generation an, also quasi ja, also das klassische quasi, ich schreib was in mein Chatboard rein und sag: "Hey, mach mal eine Python App und ich kriege dann eine Python App oder halt eben eine Go App und ich kriege eine Go App rausgegeben und das machen wir ja nicht mehr. Äh, da sind wir ja nicht mehr an dem Stand der des Wissens, sondern wir sind ja schon ein Schritt weiter.

Ähm und dadurch, dass wir jetzt agentisch arbeiten und quasi in dem Loop der Agent seinen Output selber korrigieren kann, ist eine Sprache auf einmal besser geeignet, die halt viele dieser Korrekturmechanismen hat und äh da passt Go halt sehr gut, weil bei Go ist relativ klar, du Go Format und idiomatisches Go und da kannst du deine Checker drüber laufen lassen, die dir ein deterministischen Output geben, ob der ob das gut ist, was der Agent produziert hat oder nicht. Und das halt bei JavaScript komplett anders, weil also ich bin echt, ich liebe JavaScript, aber JavaScript und ich liebe es, weil es eine Wild Wild West Sprache ist. Also, du kannst ja alles machen in JavaScript, ne? Ähm, aber das ist halt doof für die Agenten, weil die natürlich dann auch alles machen, ja, und vielleicht nicht unbedingt den besten Weg wählen, sondern halt irgendeinen und dann hast du auf einmal drei unterschiedliche Ansätze ein und dieselbe Sache zu machen deiner Codebasis und muss das halt eben rückwirkend unterbinden und Go kommt schon mit diesen ganzen Boardmitteln und von daher ja feiere ich das und Rust ist mir zu kompliziert.

Da habe ich es noch nicht geschafft, tiefer reinzuschauen. Sonst wäre es vielleicht das. Äh und so ist es hauptsächlich Go. Ja.

Und ist fairerweise, ne? Ich glaube, da hat Go oder auch Typescript wahrscheinlich haben da so ein Sweet Spot, ne, auf der einen Seite typisiert und deswegen gut auch überprüfbar sozusagen das Ergebnis. Äh Rust ist da ja noch mal ein Schritt weiter. Das heißt, also eigentlich kriegst du noch korrektere Ergebnisse raus, aber es ist bei weitem nicht so weit verbreitet wie Go, ne?

Und ich glaube, da ist Go einfach Go und Typescript sind wahrscheinlich so die perfekten Languages dann. Ja. Ja, aber ich, also ich muss auch sagen, ich mache im Frontend für ehrlich. Ja, das ist ja so eine Menübar App.

Das ist alles Swift UI, also alles, ne? Das ist jetzt nicht viel. Das sind vielleicht 1000 Zeilen. Ja, nicht mal.

Ja, doch. So um die 1000 Zeilen Code Frontend Code. Ähm, also ist ganz wenig, aber muss ich sagen, habe ich null Probleme mit. Das funktioniert wunderbar.

Äh, also, also ich würde es jetzt nicht nur auf Typescript äh begrenzen, aber Typescript besser als JavaScript auf jeden Fall durch die Typisung halt. Also, ist schon ein Fehleraspekt irgendwie rausgenommen aus der Gleichung und ja, das hilft halt absolut. Ja, also ich habe selber sogar eine Typescript, sorry, eine Swift App geschrieben. Genau die gleiche Experience sozusagen.

Äh Typescript war einfach nur ein Beispiel, weil es wahrscheinlich noch weiter verbreitet ist, ne? Wobei es glaube ich auch nicht selten ist, ne? Das hat sich das hat sich ja durchgesetzt. Ja, genau.

Imbereich schon lange her. Anyway, wir wollten ja eigentlich über dein Text sprechen. Genau. Also, welche Agents, welche Skills und so nutzt oder Harness.

Also ich muss sagen, ich probiere mal irgendwas verrücktes aus. Ähm, also ich habe Zeitlang mal das, also jetzt weiß nicht, vor zwei Monaten oder so Gadget dann eine ganze Weile ausprobiert mit einem Projekt und muss dann sagen, ja, das denn das der Name ist genau das Gegenteil äh von dem, was passiert, ne? Also irgendwie wird man damit nie fertig. Äh, es dauert immer alles ewig lange und ähm und ich bin jetzt haupt, also ich versuche immer dann nach einer Weile, wenn ich irgendwie neues Framework oder neue neuen Ansatz ausprobiere, wieder zurückzugehen [schnauben] ähm zu Vanilla und zu gucken einfach, okay, wie wie anders ist einfach die Vanilla Lösung.

Im Moment bin ich relativ happy mit den Boardmitteln von Cloud Code, muss ich sagen, im täglichen Arbeiten. Und wenn man jetzt wirklich ein riesen riesen Batzen hat, ja, dann würde ich sagen, dann macht Spectrum Development irgendwas Sinn. Aber das habe ich selten, weil ich dann doch meistens die Aufgaben in so kleiner handhabare Aufgabenpakete runterbreche, dass ich die noch gut überschauen kann und dass der Agent die eigentlich gut gut abarbeiten kann, weil ich habe auch ein Problem bei diesen riesengroßen Spectrum Development Frameworks. Du du erzeugst ja extrem viel Spack und ich habe keinen Bock FBC zu lesen.

Also von daher habe ich dann lieber irgendwie ein paar kleine Issues, dann lieber ein paar mehr von den Issues, aber ich kann die halt pö umsetzen, also eher so iterativ. Genau. Ich weiß, vielleicht schneiden wir das auch einfach raus. Du kannst auch nein sagen, Ingo.

Ähm ähm wie macht ihr das bei äh bei Iones? Ähm versucht ihr da eher einen Stil hinzubekommen oder in Anführungsstrichen zwingt die Leute in einen Workflow? Also angenommen, du würdest jetzt in in ein Training gehen. Ähm und dort würde würden Leute sagen, wir machen das hier in dem Team machen wir das halt immer Spectrippen.

Es quasi würdet ihr versuchen, da eine Linie zu führen oder? Also, da kann ich jetzt natürlich da kann ich jetzt natürlich nicht super ins Detail reingehen. Ähm, ich versuche meine Trainings immer so aufzubauen, dass die schon eher anhand der äh der der Grundlagen, also der Prinzipien heragieren. Und äh mein Ansatz ist eigentlich zu sagen, okay, wie komplex ist das Problem und wir lernen quasi in den Trainings äh wie komplexes, also wie man die einschätzt, wie komplex ein Problem ist.

Und da gibt's ja auch Tools für, die die einem helfen, erstmal das zu verstehen, was ist komplex aus der Sicht eines Agenten. Ähm Task Master, glaube ich, heißt es. Ähm das macht so eine Komplexitätsanalyse mit einem LM, aber das kann man sicher auch schnell als Skill selber schreiben und ähm dann dann kriegt man halt eben so ein Output und kriegt so ein Gefühl dafür, wie viel wie wie krass doch ein einzelner Tast ist. Und anhand der Komplexität äh die erörtert wird, ähm sagen wir dann, wir treffen eine Entscheidung.

Also einfach nur Cloud Code reinschreiben, fertig oder Pi oder was auch immer für ein Agent genutzt wird. oder wir äh holen ein bisschen weiter auf, wir machen erstmal ein Research Run und machen dann Plan, reviewen den Plan, verbessern den vielleicht noch mal und lassen es dann laufen. So ne und das krasseste ist halt Spectral and Development und der also es ich kenne Leute, die Spectrum and Development wirklich die ganze Zeit nutzen und nichts anderes mehr nehmen und damit super gut fahren und ich werde da nicht reingrätschen und werde sagen, nee, nee, so machen wir das aber nicht, weil ne, also das soweit soweit geht das nicht. Also, es gibt da sicherlich äh Vorgaben, aber äh und Ideen, wie man das was ein guter Ansatz ist.

Und es gibt sicherlich auch Nonnegotiables, ähm, die man einfach vorgeben, also einfach aus dem rechtlichen Rahmen, ja, ähm die vorgegeben sind, aber ja, was was die Teams einzeln äh machen, ist extrem auch abhängig von ihrem Text und von den von den Sachen, die sie einsetzen. Das macht auch total Sinn, ne? Also bei so einem großen Laden wie es gibt halt äh sagen wir mal zentrale Coreservices, die einfach ganz anderen Rahmenbedingungen unterliegen als äh ja irgendwelche Sachen, die Marketingstack sind oder so, ne? Ja, genau.

Und trotzdem denke ich, gibt's wahrscheinlich so einen Bodensatz an Sachen, die halt jetzt gar nicht zu sehr abweichen, abschweifen heute, aber gibt's halt irgendwie so ein so ein Basisset an nonnegotiables, also nicht funktionale Anforderung. Ja, meistens irgendwie Security Compliance schlag mich tot, die halt dann doch wieder für alle relevant sind, ne? Und also wie wie kriegst du da einen Griff dran ähm ohne dass es halt quasi ein ganz enges Corsette wird? Deswegen hat mich unheimlich äh interessiert halt irgendwie zu fragen, wie wie man das halt irgendwie angeht, weil jede mittelgroße Firma wird dieses Problem halt haben oder hat dieses Problem.

Ja. Ja. Also gesagt, ich bin ja da auch nicht das, ich bin ja nicht der Entscheider am Ende, ich bin ja der quasi der, der die Nachricht überbringt, ja, an die anderen. Ich kann das ja nur, ich kann das ja nur weitergeben, mittragen und vielleicht, wenn ich sehe, dass Teams es auf die eine oder andere Art umsetzen, dann nehme ich das natürlich mit in die Trainings und äh ja und und zeige so Wege auf, aber es gibt auch Themen, die ähm ja, die einfach also wo ich das aufzeigen kann, wo ich die Grundlage habe, die Basis quasi, wie wir wie wir die angehen.

Z Daten Datenschutz, ja, Datenklassifizierung ist ja ein Thema bei KI. Was was darf man wo verwenden? Mit welchen Tools? Wo haben wir welche Auftragsdatenverarbeitungs?

Nee, wie heißt das? Auftragsdaten Vereinbarung mit dem mit dem Kunden geschlossen und was ist sozusagen der Rahmen, in dem man die Daten dann verwenden kann? Ähm, das sind dann nonnegotiables, ne? Das kann man dann klassifizieren, einschätzen als Team und kann dann sagen, okay, ich fall in die oder in die Kategorie.

Wir haben auch Open Source Tools, die sind natürlich dann public. Ja, den den da ist dann egal eigentlich. Also jetzt auch nicht komplett, aber zu großen Teilen egal äh wo die den Code reinstecken und dann gibt's halt andere die High Secret Top Secret sind. Da sieht die Welt halt komplett anders aus.

Das finde ich ein schon mal ein super, also sehr allgemein formuliert, aber ein super ähm Finding oder Ansatz, wie man das in der Organisation angehen kann, dass man Teams einfach klassifiziert nach genau den Rahmenbedingungen, die du da angegeben hast, ne? Also, wo wird mit Kundendaten direkt agiert bzw. wo würden Kundendaten möglicherweise einmal an den amerikanischen Server geschickt werden, ne? Wo wo ist es völlig unkritisch und je nachdem kann man dann auch andere Rahmenbedingung setzen.

Macht total Sinn. Ja, genau. Und in den Trainings bringe ich dann eher sowas rüber wie man so eine Klassifizierung macht. Ähm, das heißt, also da arbeite ich gerade dran tatsächlich, weil ich die Rückfrage halt so oft gekriegt habe.

Ist eigentlich nicht mein Mettier, weil ich halt schon eher Engineering Praktiken irgendwie Runde rüber bringen will, aber die Frage kam halt sehr oft und deshalb baue ich das jetzt ins Training mit ein. So quasi ja einfach so spielerisch zu lernen, okay, wie klassifiziere ich eigentlich meine Daten? Macht Sinn. Genau.

Dann um das abzuschließen, also ich höre raus, du arbeitest sehr viel Vanilla und ich höre raus so Claud ist auch wahrscheinlich so dein Goto Agent, ne? Und ähm Ja, genau. Alles klar. Hängt auch damit zusammen, dass ich äh hatte ja die amerikanische Firma da angesprochen, die ich noch berate.

Äh da nutze ich halt, also die stellen mir 200$ an Tropic Plan zur Verfügung und das ist nämlich na ja, ne? Also ich würde, wenn ich ein 200 € Opte, dann würde ich halt Codex nutzen. Also ich bin da, ich bin da leidenschaftlos, muss ich sagen. Ich mag es mal mit allem rundzelen und auch mal die Tools gegeneinander antreten zu lassen.

Äh z.B. wenn Codex Cloud Code, also Cloud basierten Code analysiert, ist Codex immer sehr kritisch. Gemini auf der anderen Seite sagt mal so, hey, das ist viel besser, als du dich selbst bewertest. Stell dein Licht mal ich schäfe, du bist so toll.

Du kannst so toll Code schreiben und Codex ist es eher so. Na ja, also komm, da könntest du es noch ein bisschen besser machen. Das war ja nicht so dolle. Das ist ganz witzig.

Ja, interessant. Ja, ich hatte ich hatte so ein äh umgekehrt äh nee, halt genau so ein ähnliches Erlebnis, da war es nicht Codex, sondern Gitub Copilot und da glaube ich das Standardmodell, [schnauben] was Cloud Code kritisiert hat und Cloud Code hat dann auch beschämt anerkannt, ja, das sind alles valide Punkte. Das war auch [gelächter] lustig. Na ja, anyway.

Äh ja, dann lass uns mal, wir sind schon ein bisschen fortgeschritten jetzt in der Zeit, lass uns mal zum Hauptteil der heutigen Episode kommen, nämlich äh zum Eichhorst Principle und sicherlich davon abgeleitet dann noch zu einigen ähäh damit äh korrelierten Themen oder dem, die damit zu tun haben. Genau. Äh ich glaube, du hast es nicht so genannt, sondern es war Ralf Düler, glaube ich, der es so genannt hat. Es ist mir ein bisschen peinlich oder ein bisschen unangenehm, muss ich sagen.

Ähm, genau. Ralf und das Eichhorst Prinzip, das ist ein das ist schon so ein bisschen, wie ich soll sagen, nicht ein Witz, ne? Aber aber es ist schon schon so ein bisschen ähm äh ein Experiment eigentlich. Also, die Idee ist ähm wir formulieren das, wir bringen das mal raus oder er bringt das raus.

Mir ist es wie gesagt ein bisschen unangenehm und äh wir gucken mal, wann das im äh in den LMs vertreten ist und ob man so quasi so ein Konzept, was es einfach noch nicht gab und es gab's halt nicht. Es gibt andere mit dem gleichen Nachnamen wie ich, aber es gab halt keinen, der irgendwann mal gesagt hat, so ich mache jetzt mal ein Prinzip draus und ähm wie lange dauert das, bis das in die LMs reinsack hat? Also von daher gibt das ruhig gerne weiter, auch wenn es mir ein bisschen unangenehm ist. Ähm ja und die Idee ist entstanden im äh wann war das?

Anfang März war ich auf der Javaland und hab ein Vortrag gehalten äh zu einem Thema, was eigentlich so mein Herzensthema ist. Architektur 3.0 haben wir es mittlerweile genannt. Ähm, also quasi die Idee, dass mehr und mehr äh Architektur in den Vordergrund gestellt wird, weil wenn Agenten die äh die Codearbeit, also das eigentlich Schreiben des Codes übernehmen, dann äh quasi geht meine Rolle als Entwickler ja einen Schritt weiter raus, also eher auf die Architekturarbeit und aber auch die Architekten, die halt e heute versuchen Menschen zu steuern und Menschen irgendwie Vorgaben zu machen, eine Richtung zu lenken. Ähm, das werden dann zukünftig dann halt eben mehr und mehr KI Agenten sein.

Ja, und mein Ansatz, um das so ein bisschen rüberzubringen, wie man das machen kann, dass man halt ähm ein Input in das LM, also ein Prompt reingibt und am Ende was Funktionierendes bei rausbekommt. Ähm, war halt angelehnt an das Shannon, an das zweite Prinzip von Claude Shannon, der halt sagt, okay, du hast eine gewisse Kanalkapazität. Das ist also quasi, wenn du äh eine Nachricht überträgst, also jemand spricht in Mikrofon rein, so wie wir das jetzt machen, dann ist da eine gewisse Wahrscheinlichkeit, dass äh ja, das verrauscht wird und auf dem Weg nicht funktioniert. Damals war das halt eben der analoge Telefone, Morsegeräte, man musste halt eben nicht mit hundertprozentiger Sicherheit, ist das wirklich, was hinten rauskommt, ist das wirklich korrekt.

Und jetzt kann man halt eben diese Signalspitze erhöhen und was Shanon halt gemacht hat, der hat so ein Korrekturmechanismus eingebaut. Also ich nehme mal gerne als Beispiel so ein QR-Code. Ein QR-Code hat nämlich auch so ein Fehlerkorrekturmechanismus und wenn man dann beim Einkaufen mit dem Wasstfinger drüber geht und dem ein bisschen verwischt den QR-Code, ist das überhaupt kein Problem. der kann bis 30% verlieren, einfach komplett weg und ich kann das am Ende wieder rekonstruieren über halt eben den Fehlerkorrektur Algorithmus und so ein [räuspern] bisschen so sehe ich das bei LMs halt auch.

Also ich gebe halt was rein, das hat Unschärfe, weil ich nicht klar genug in meiner Formulierung bin, weil ähm einfach meine Konzepte, meine gedanklichen Konzepte anders sind als die von dem LM vielleicht, weil ich Domänenspezifische Sachen reingebe, die das LM gar nicht kennen kann. Das heißt, ich bringe so ein bisschen Rauschen schon von draußen rein. Dann habe ich das Sampling im LM, was noch ein bisschen Rauschen reinbringt und am Ende will ich ja trotzdem das, was bei rauskommt, was so ist wie das, was ich mir irgendwie am Anfang vorgestellt habe. Und ähm genau und die die Frage ist jetzt, wie wie mache ich das?

Und da kann ich genau an diesen Punkten ansetzen und da hat Shanon halt eben schön äh äh ein Transmitter und die die den Kanal und den Receiver. Und das kann man wunderschön, dieses Prinzip, das kann man wunderschön auf das LM übersetzen. Als Transmitter ist quasi dann halt eben wir oder die Spezifikation, dann haben wir den Kanal, das das Sampling aus dem LM, ne? Man kriegt ja nicht immer den gleichen Output, sondern das ist ja durch die ähm äh durch die Temperature ist es ja äh das Sampling ein bisschen angepasst, aber auch so ist es unscharf, weil man ja nie genau das trifft, was du treffen willst.

Ähm, ich mache mit meinen äh äh mit meinen äh ja, mit den Trainys, aber auch mit meinen Studenten. Ich bin also noch Dozent nebenbei an der Uni und ähm und mit denen mache ich immer so ein so ein so ein Sampling Experiment, so wir geben 1 + 1 ein und dann das ist gleich in so ein kleineres LM und da kommt dann meistens raus sowas wie äh zwei, aber nur mit 66% Wahrscheinlichkeit. Und dann versuchen wir das weiter zu verrauschen, so dass halt eben irgendwann nicht mehr zwei rauskommen. Ist die Frage, wie können wir das verrauschen, ne?

Wenn man jetzt z.B. Team Synergies so als Anker mit reingibt, Ralf spricht ja viel über diese semantischen Anker. Das machen wir quasi dann da an der Stelle auch. Ja, geben s Team Synergies als Anker rein, kommt auf einmal 1 + 1 ist 3 raus.

Aber jetzt auf einmal ein Anker gegeben haben, ja, eine Klarheit gegeben haben, mitgegeben haben am Anfang schon für das LM. Das Sampling ist immer noch unklar, aber auf einmal ist das nicht mehr 66%, sondern das ist halt irgendwie 90%. Das heißt also die wir haben die Spitze sozusagen in der Wahrscheinlichkeit spitzer gemacht und das Sampling quasi genau da, wo wir es haben wollen, ist jetzt wahrscheinlicher, dass es dort auftritt und genau das ist sozusagen das Rauschen im Kanal und dann haben wir das den Receiver Part, also da, wo das Signal dann wieder ankommt und das ist dann quasi der Agent, also beim QR-Code wäre es quasi der kaputte QR-Code kommt an und jetzt habe ich ein Fehler Korrekturmechanismus, der wieder ein heilen QR-Code drauf macht oder der sich beschwert und sagt, mach noch mal ein Foto oder finden heilen QR-Code, ne? Das sind so die beiden Möglichkeiten und eigentlich ist das relativ genau das, was wir beim Programmieren mit KI auch haben, ne?

Der Output ist entweder es, sagen wir jetzt mal in der ersten Stufe ist irgendwie wir lassen vielleicht ein Typck drüber laufen und der Typhack ist okay oder ein Linter drüber laufen und der Linter sagt, das ist alles super, dann dann ist es okay, ne? Das ist dann so wie der der ähm der QR-Code, der in Ordnung ist, der genug Informationen enthält oder es geht wieder zurück an den Absender und sagt, ja, ist halt nicht nicht Typesfe, ne? oder ist halt oder äh also die die Typisierung ist nicht korrekt oder äh keine Ahnung, die Variablen sind äh falsch benaht oder du hast hier Tabs anstatt Spaces verwendet, whatever und dann geht's halt eben wieder zurück und das ist sozusagen so grob das Sorry äh das ist grob so das das Prinzip. Ja, was ich mich gefragt habe, ähm od was für mich total einleuchtend ist, dass man etwas verrauschen kann, also das etwas rauschen kann, ähm und dass man quasi äh ja im Endeffekt ein LM schlechter eine Antwort machen, äh also quasi schlechter Antwort werden lassen kann.

Die Frage, die ich mich gestellt habe, ist geht das auch umgekehrten Dreh Weg? Also kann ich auch etwas, also kann ich halt Rauschen rausnehmen, ne? Das jetzt gerade glaube der Part, den du als Receiver bezeichnet hast. Ähm ja, wo du der Recei Korrektur drin hast.

Genau. Also der Receiver ist wirklich zum Korrigieren da. Also klar, du musst halt eine Möglichkeit haben zu erkennen, ist das was ankommt, ist das überhaupt plausibel? Ist das korrekt?

Das kannst du halt gut machen, z.B. Also, wir haben ja jetzt nur über äh so diesen den inneren Loop, also einfach passt die Formatierung kann das kompilieren. Das ist quasi so das erste. Dann gibt's ja noch ein größeren größere Loops.

Also so laufen die Tests, laufen End Tests noch größer, ne? kann man eine Weltsimulation quasi dagegen laufen lassen. Ähm, also man kann das ja, man kann das ja weiterspinnen. Ähm, und das ist sozusagen der Receiverteil, aber das jetzt ist einfach spezifischer zu machen und ein genaueren Output zu bekommen.

Das ist halt eben auch von den Studenten, was ich trainiere. Also, wir geben halt äh ganz ganz wir fangen ganz ganz ambivalent an mit unserem Prompting. Z.B. Wir haben ähm wir sagen: "Hey, generier uns mal einen Webserver." So, wenn du das halt fünf mal laufen lässt, dann kriegst du quasi fünf unterschiedliche Webserver.

Also jetzt einfach nur das LM zum LM sagen, ne, gibt mir Webserver und man nimmt den Webserver, der rauskommt und macht das. Wie können wir jetzt besser werden da drinne, was wir wollen? Also uns vi überlegen, wollen wir lieber ein Wetter Webserver haben oder einer, der uns keine Ahnung die eBay ähm die eBay Angebote rausgibt. Ähm und jetzt fangen wir an in unserem Gehirn.

Ja, das ist jetzt extrem einfach, aber jetzt fangen wir an unserem Gehören Klarheit zu schaffen. Wir fangen fangen an das zu sortieren und das geht halt runter bis auf, ne, wollen wir Camel Case oder äh oder wollen wir Snake Case haben? Das nimmt uns oft schon die P. mirprache ab, weil oder das die äh das äh das Umfeld, ne?

Ähm die einfach sagen, okay, also unsere Coding Guidelines geben das vor, aber irgendwann muss man diese Entscheidung treffen, diese Klarheitschaften und das ist halt eben auch der große Vorteil von Go gegenüber JavaScript, weil Go kommt mit dieser Klarheit an vielen Stellen schon und bei JavaScript muss ich es erst schaffen, muss ich sie erst erreichen später. Ja. Und ähm und zurück auf den Webserver. Ähm, die Aufgabe ist es quasi, ich ähm frag quasi das LM Webserver zu erreichen, dann haben wir uns irgendwann darauf geeinigt, dass es ein Weber Wetter WebSver ist und dann laufen die Studenten alleine und haben quasi eine halbe Stunde Zeit, zwei äh Eingaben in das LM äh zu machen, also zweimal die gleiche Eingabe zu machen und es muss exakt das gleiche Ergebnis bei rauskommen, ne?

Das ist natürlich nur so 30 Zeilen Code, aber es muss genauso aussehen und dann haben wir ja quasi, das wird vielleicht bei 50 mal werden wir dann nur noch zweimal daneben liegen, aber dann dann hast du ja die Spezifikation quasi auf die Spitze getrieben. Das ist ja das Maximum, was du erreichen kannst. Das heißt, du hast die die Klarheit im Signal, was du reingibst, sousagen der Inputkanal von dir als Mensch, ähm den hast du quasi so präzise gemacht, wie es dir irgendwie möglich ist. Und das erreicht man meistens schon relativ schnell.

Also da braucht man gar nicht äh braucht man gar nicht so äh ja jetzt irgendwie keine Ahnung, also, dass man irgendwie eine Dina vier Seite schreibt, um so ein Webserver rauszubekommen. So viel ist es gar nicht. Das sind meistens so vier, fünf Zeilen. Ähm und dann ist man schon relativ klar.

Und in der Realität sagst du halt eben auch ganz oft so, ist mir egal, ne? Also, das ist ja auch eine Entscheidung am Ende zu sagen, ja, nimm halt den den Webserver, den du oder den den die Wetterappi, die du für am besten hältst. Es ist mir jetzt an der Stelle einfach egal als Entwickler. Oder ich sag halt, nee, um Gottes Willen, das kann mir doch nicht egal sein.

Das ist ja wichtig, weil vielleicht gibt's welche deren Kosten dran, dann habe ich ein Rate Limiting, irgendwas für ein Prototypen egal, für ne wä dann produktiv ähm wird's auf einmal wichtig. Hoffe, das ergibt ein bisschen Sinn. Ja, ich versuche das noch, ich versuche gerade das so in Real World Szenarien, also hast das ja schon mit dem Webserver beschrieben, ähm also quasi quasi prakt, also einfachere Use Casases ähm äh versucht es gerade dahingehend noch mal für mich so zu übersetzen. Ähm, aber Sebastian, du hattest am Ende also Schlussfolgerung ist ja spez die Spezifikation bringt ja die Klarheit hier an der Stelle, ne?

Also, sprich, wenn du äh mehr, sorry, Kontext, also, sagen wir mal nicht unendlich mehr gibt unendlich mehr äh äh Genauigkeit oder Präzision, ne? Aber diese vier bis fünf Zeilen, die geben ja hier offenbar die Klarheit, ne? was auch immer diese kannst du kannst du ein bisschen beschreiben, was da genau der die diese vier bis 15 oder was die ungefähr enthalten? Also, was meistens eins der ersten Sachen ist, wie gesagt, es gibt unterschiedliche ähm SDCs, die du nutzen kannst und da gibt's halt zehn oder so, die ganz gut im ähm Latenzraum vertreten sind und die dann halt eben immer wieder auftauchen.

Und dann gibt's aber auch sowas wie Kommentare. Ähm, will ich überhaupt Kommentare haben? Wenn ja, wie sollen die aussehen? Die sind natürlich kunterbund gemixt.

Ähm ist es Proersprache ist ja schon das erste. Wahrscheinlich kriegst du Python raus, also Wahrscheinlichkeit Python zu bekommen für einen für eine Wetterabi. Das kann ich jetzt da habe ich eine relativ gute Samplinggröße mittlerweile, [gelächter] also die ist hoch, aber vielleicht wird's hier nicht peiten. Ähm also ist trotzdem nicht äh gesagt äh oder oder mit Sicherheit, dass du Python rausbekommst.

Ähm dann die Benahmung der Variablen, das ist halt auch kunterbund. Dann äh wie baust du es? Also gibt's eine gibt's eine Mainfunktion quasi, die irgendwie eine Unterfunktion aufruft oder ist alles in einer großen Funktion? Äh und wir sind natürlich jetzt sehr sehr kleinteilig.

Ja, wahrscheinlich für den für die meisten werden genau so eine Entscheidung, die trifft man halt einmal, [schnauben] ähm schreibt sie sich in seine Coding Guidelines rein und überprüft dann halt eben den Code darauf, dass das dass das eingehalten wird und äh dann dann ist es okay und oft spielt es eigentlich gar keine Rolle. Es ist wirklich mehr zu zeigen, dass man das Denkmodell halt ein anderes ist als klassische ähm rollenbasierte ähm Skripte zu schreiben, also Rollenbasiert zu arbeiten und einfach oder regelbasiert zu arbeiten und einfach sagen, okay, wenn das dann das es ist ja im Endeffekt was wir was wir programmieren oder was müssen große Teil des Programmierens ausmachen. ähm weg davon und ein bisschen mehr Freiheit zu geben, aber halt eben nicht zu viel Freiheit zu geben. Und das ist und das das quasi die Aufgabe, um so dieses Fingerspitzengefühl dafür zu bekommen, wann es ist genug, wann ist vielleicht auch zu viel.

Mhm. Ja. Mhm. Mhm.

Ja. Und das macht immer das macht immer riesig Spaß. Auf jeden Fall seine ganz ganz klasse Aufgabe und man kann das total auf die Spitze treiben. Ich weiß vor anderthalb Jahren oder so gab's eine Bewegung, die hießen Prompt Speck Prompt, nee, Prompt, ich weiß nicht, also irgendwas auch mit Speck und mit Prompt.

Ähm und die waren ähm das waren halt äh das war eine strukturierte Sprache. Es war so eine Domain spezifische Language äh Domain specific language, aber für Programmieren. Das heißt also, ich habe den Namen der Funktion aufgeschrieben, dann halt grob, welche Parameter ich haben will und dann so Pseudocode mäßig den Ablauf formuliert und somit hatte ich dann Pseudocode und konnte den in jede beliebige Poumiersprache umwandeln. Und dadurch, dass es so spezifisch ist und so klar ist, kannst du es halt eben auch durch ein 8bodell locker generieren lassen, auch eine Sprache, die nicht gut vertreten ist und du wirst was vernünftiges rauskriegen.

Das damit ich bei hosten wir ja die eigenen Modelle und dadurch kann ich quasi immer beliebig durch äh durch alle Modellkategorien durchswitchen und gucken dann, okay, was ist das kleinste mögliche Modell, mit dem man noch vernünftigen Output bekommt. Also das [räuspern] ist halt auch sowas, was halt eben das Rauschen erhöht, ne? Es ist halt eben je genau je je schwächer das Modell ist, desto schwieriger wird's im Fallen auf Basis meiner Information, mein Intent, den ich reingebe, zu generalisieren und zu sagen, okay, ah ja, das ist das größere Konzept, in dem das drinne besteht. Wenn ich eine ganz ganz klare Pudocode Spezifikation habe und die reingebe, ist es halt eben auch für ein kleines Modell sehr sehr klar, okay, das ist sozusagen die Spitze, was erreicht werden soll und ähm ja, ein größeres Modell kann sich dann halt eben auch in in generellere Aussagen halt eben einfacher reinhängen.

Das ist auch meiner Meinung neben dem agentischen Loop halt in eines der Hauptgründe, warum jetzt so vor ein paar Monaten noch mal agentisches Programmieren so durch die Decke gegangen ist, weil man auf einmal mit einer ähm ja, mit einer natürlich sprachlichen Ausgabe Aussage einfach fast immer zu einem vernünftigen Output gekommen ist und das war halt komplett anders als vor keine Ahnung vor einem Jahr. Da war es halt wirklich mehr Ja, man muss auch manchmal ein bisschen Glück haben mit KI. Und das ist das ist jetzt komplett weg. Also die Generalisierungsfähigkeit der LEMS ist äh äh ist echt echt beeindruckend mittlerweile.

Obwohl ich sagen muss ähm Stefan und ich, wir hatten telefoniert und ich ich so was haben die alle mit Opos 4.5, das war das, was Dezember rausgekommen ist. Warum finden das alle so toll und warum feiern das alle? Ich kann das gar nicht nachvollziehen. Stefan meinte, ich kann das auch nicht verstehen.

Es ist gar nicht so viel anders von dem, was bis jetzt da war. Ja, weil man hat immer diese inkrellen Fortschritt, aber für jemanden außenstehenden, der halt nicht ständig damit arbeitet, war das auf einmal ein ganz schöner Sprung. Und ja, das müssen wir jetzt einfach so anerkennen. Das ist jetzt einfach da.

Ähm, verstehe. Das ist so ein bisschen das Ierative, wenn man sich stark damit befest beschäftigt, dann äh fühlt sich das eher iterativer an. Ja. Ja.

Ja. Aber dann merkst du halt also diese diese Rauschreduzierung quasi, die in den Modellen dann drinne ist, dadurch dass da dem dein Gedankenatz quasi besser in Code übersetzt werden kann. Ähm genau, der kommt dir halt iterativ nicht so krass vor, als wenn du es halt auf einmal probierst, davor war es scheiße und jetzt ist es toll. Und wir haben uns halt mit Scheiße schon ganz gut arrangiert.

Das heiß scheiße, ne? mit halt eben noch nicht so tollen Modellen. Ähm ja, aber aber das ist cool, also beeindruckend, was äh was geht. Ja, das hört man ja auch immer wieder, dass äh die äh da oder dadurch die der Vorsprung noch relativ gering ist, ne?

Weil alles, was man sich in einem alten Modell an Hilfsmitteln drumherum aufbaut, damit das Ergebnis besser wird, im der nächsten oder übernächsten Modellvariante schon nicht mehr nötig sein wird und dann kannst du es einfach onhotten sozusagen. Ähm, genau. Also, die Entwicklung ist einfach weiterhin wahnsinnig beeindruckend, ne? Ähm, genau.

Vielleicht noch mal zu zum Eich Principle zurückzukommen. Je öfter wir es hier im Transkript erwähnen, vielleicht äh kommt's dann noch schneller in irgendeinen LNW rein. Ähm, was das Beispiel, was du gebracht hast hier zum zum Webserver, das ist ja schon sehr eng, ne? Es ist halt sehr sehr enger Loop, ne, bzw.

auch mit dem Pseudocode sehr sehr enger Loop. Äh, lässt sich das oder also lässt sich das gut abstrahieren? äh oder bedeutet das im Prinzip äh das ist eigentlich die ähm quasi der theoretische Hintergrund hinter Speckdraven oder Beamert oder wie sie alle heißen? Also ich ich glaube, es ist einfach also für mich selbst es ist einfach nur ein Gedankenmodell, was mir gut hilft meine äh Stellschrauben gut zu vorordnen in dem gesamten Prozess.

Ja, und wenn meine Spezifikation halt eben schlecht ist und die auf ein super agentisches System trifft, dann wird trotzdem Quatsch rauskommen, weil ich das Sampling an der falschen Stelle mache. Gleiches wenn ich halt ein kleineres Modell habe. Also, es hilft mir einfach gut darüber schnell darüber nachzudenken, ähm warum passiert B, warum folgt B aus A? Ähm dafür ist es einfach ein gutes ein gutes Werkzeug, glaube ich.

Und genau und das fand halt Ralf auch. Ähm, deshalb hat er ja das das mit übernommen und ja, ich weiß gar nicht, was was soll ich noch dazu sagen? Also, dafür ist es gedacht. Ich denke, das funktioniert genauso für alles andere auch.

Also es ist der agentische Loop ist damit eingebaut. Ich glaube auch nicht, dass ganz ehrlich, also das erklärt ja quasi ähm ein LM von 2017 genauso wie ein LM von von heute und die Funktionsweise von heute. Also ich fällt mich schwierig jetzt irgendwie da was was zu erkennen, wo ich jetzt sagen würde, okay ja, wenn jetzt aber die Weltmodelle kommen, dann ist es auf einmal ganz anders und ich glaube, das ist schon so ein Konstrukt, was man halt eben auch auf viele und andere Aspekte anwenden kann. Ja, es wird glaube auch das wird allgemein, es hat eine gewisse Allgemeingültigkeit.

Es wird auch mit besseren LMs ähm also quasi die das Rauschen zwangsläufig reduzieren. Ähm wenn man ich glaube, das ist natürlich auch bloß bis zu ein gewissen Grenze halt irgendwie möglich, ne? Ähm, also gerade was so Kontextinformation angeht, das kannst du ja nicht raten. Also das ein gewisses ein gewisses äh Potenzial zum Halluzinieren wird's halt immer geben.

Ähm aber es wird äh quasi das, was du beschreibst, wird halt eben nie schaden, würde ich sagen. Also es äh es ist tendenziell von der, also es ist halt tendenziell wird es könnte man es auch als best practice bezeichnen. Genau. Und und was Shanon halt auch sagt, ist ähm du hast halt einen gewissen Informationsgehalt in Information, also er hat halt eben Informationen neu gedacht, anders als quasi davor darüber nachgedacht wurde, wo Informationen eher so als ja physisch äh versucht wurden, so als als quasi als als Wellenlängen äh zu denken.

Und er hat halt eben die Information eher verstanden als Entropie, also als Unterschied zu dem, was da ist. Das heiß, wenn du sein Beispiel war immer, wenn du eine Münche Münzefst, ja, dann hast du eine 5050 Entropie, ja, oder ist relativ hohe Entropie, weil du es gar nicht weißt. Und wenn du jetzt aber eine Münze hast, die halt eben auf beiden Seiten Kopf hat, dann hast du kein null Information, weil ne, du wirst dir immer Kopf haben. Ähm und äh das finde ich das finde ich auch eine starke Referenz, ne?

Also, wenn wir einfach nur was wissen wollen, dann ist vielleicht ein LM gut, um uns zu sagen, wo ist ist wo ist das? Ja, weil wir aus halt eben diesem Gesamtwissen heraus zäeln, okay, wir wissen nicht, wo was ist, ne? Information, die uns fehlt und wir wollen diese Information haben. Das wir sampeln die aus dem LM, wenn sie dort vorhanden ist, ja, oder das LLM durchsucht das Internet für uns.

Das halt eben eine andere Art das zu finden. Wenn wir das aber quasi abgespeichert haben, ja, also wie hier bei mir ist noch Prometus aus der zehnten Klasse ist da noch komplett reingebrannt, ne? Das wenn ich jetzt das Gedicht kriegen würde und lesen würde, hätte das null Informationsgehalt für mich, ne? Weil das ist ja schon da drinne.

Jetzt will ich das noch mal lesen. Das ist keine Ja, und das war sozusagen sein Ansatz ähm Informationen zu betrachten. Und wenn wir das so sehen, dann ist natürlich nur das für uns wichtig, was im LM kreativ kreativ in Anführungstrichen, aber neu gesampelt wird aus unserer Perspektive. Und das finde ich ist so ein spannender ähm auch Ansatz und der zeigt halt eben auch, dass ja LM ist halt kein Buch, ne?

Sollten wir auch dafür nicht nehmen, sondern es ist eine neue Kombination. ähm die halt genau dann sinnvoll ist, wenn sie nicht zu krass entropisch ist. Also Kauderwältch, ja, wenn man die Temperatur auf zwei stellt bei LMS, dann kriegt man kompletten Kaudderwelch raus und dann wird beliebig gesampelt aus allen Tokens, die verfügbar sind. Also das ist dann gibberisch.

Hat zwar viele Informationen jetzt nach Shens Theorie, aber es bringt uns natürlich nichts. Es ist nicht nicht hilfreich. Und bei einer Justierung von so einem LM, von dem KI System, geht's halt eben immer darum, irgendwie so ein Sweetspot zu finden. Ja, genug Entropie, dass es sinnvoll und hilfreich ist, weil sonst kann ich halt auch ein Gesetzestext nehmen und der ist halt der ist halt so gegeben, ne?

Dann brauche ich kein LM oder kein kein KI Modell und das muss aber trotzdem halt eben ähm nicht nicht zu krass entrupisch sein, weil dann ist es nicht mehr, dann kann ich es nicht mehr anwenden. Ja, dann hat's keins kein keinen Sinn mehr in der realen Welt. Ja. Absolut.

Genau. Ja, das finde ich ist auch noch mal als ähm sagen mal Erklärungsansatz oder als Kontext für das Modell auch ganz ganz hilfreich äh das genauso zu betrachten, dass die äh Information oder die relevante Information ja genau darin besteht, dass es eben nicht hundertprozentig deterministisch ist, sondern ähm dass da eben ähm ja was was Neues entsteht, so was was noch nicht da ist. Und das was man jetzt, wenn man diesen Receiver, wir hatten vorhin ja Compiler gesagt oder Linter, wenn man das halt eben weiterdenkt, dann kommt man halt eben auf diesen mittleren Loop, wo man sagt Unit Tests, Integrationstests, dann vielleicht dann jetzt alle berichten von Problemen Architekturerosion durch KI Agenten. Ja, die ist nachweisbar statistisch.

Habe ich auch hier. Ihr hat das ja vorhin kurz angesprochen. Ich hatte so ein so einen kleinen Artikel geschrieben ähm zu quasi Metast oder Metaanalyse habe ich es genannt äh zu allen möglichen äh Produktivitätsanalysen. Ähm wie viel produktiver macht mich eigentlich KI?

Äh den gibt's bei Medium und äh das wir sind eigentlich noch gar nicht so weit, aber wir hängen natürlich wissenschaftlich auch immer ein bisschen hinterher, weil es eine Weile dauert, bis die Studien ausgewertet sind. Ähm und da haben halt eben auch in den Studien viele berichtet, dass die Architekturqualität, die Qualität der Software einfach deutlich schlechter geworden ist. Ähm und das lässt sich halt statistisch äh auch nachweisen, aber ich glaube, wir haben das noch nicht verstanden, dass das einfach so ein äußere Schicht drumherum ist, die man einfach noch wieder, ne, so dieser Review Schicht, also entspricht es die neue Architektur entspricht die quasi dem, was wir äh für sinnvoll halten als eine gute Architektur, dass die Module halt eben schön tief sind, aber also dünnes Interface haben, aber tief sind in ihre Implementierung und einfach austauschbar werden dadurch. Sowas z.B.

Das beachtet ja an LM nicht nicht out of the box, aber das ist sozusagen eins unserer Reviewzy Zyklen, die dann halt als Feedback mit reingehen und dem LM dann sagen, okay, hier gucke noch mal nach beant, das wollen wir doch lieber ein bisschen anders haben. Und da haben wir jetzt klassisch hier äh von Corola Linien z.B. äh langleige Software Architekturen den jetzt muss ich kurz nachgucken. Modularity maturity Index oder Nil F schreibt gerade auch an dem Buch Architecture as Code, wo genau so eine Sachen festgehalten sind, die einfach dafür sorgen, dass der Code stabil bleibt und zwar bei Menschen halt schon so, aber Menschen produzieren halt eben begrenzt Code die besten die besten Entwicklerzeugung für -10 Lines of Cesag, aber ähm ne, also ich ich denke so viel mehr als 200 Zeilen ist wahrscheinlich nicht drin.

Ähm und bei LMS, ja, das ist natürlich ein Witz, ne? Und dadurch geht das natürlich mit der Archit mit der ja, mit der Erosion, mit den Teagtps viel viel schneller und das müssen wir dagegen arbeiten. So, das ist dann der nächste Loop und dann können wir da noch wieder ein Loop drüber stöpen und können sagen: "Okay, wir gehen jetzt mal raus aus dem Loop und gucken, okay, was funktioniert denn gut, was funktioniert nicht gut?" Cloud Code gibt, so ein slashinspect Kommando. Da kann man sich so ein Report stellen über das, was man so ähm ja, wie man sich so mit dem äh LLM unterhalten hat, mit dem Agenten unterhalten hat, was war gut, was war nicht so gut, was sollte bei Menschen verbessert werden.

Aber man kann sich natürlich auch die Protokolle angucken. Das habe ich halt eben für Earlicht auch viel gemacht. haben mir angeguckt, okay, die Transkripte der Agenten und dann sieht man ja, wo ist der Agent ähm gegen eine Mauer gelaufen und muss irgendwie eine andere Entscheidung treffen. Bei P sieht man das sehr schön, da wird nämlich dann der der Hintergrund rot.

Äh, das finde ich so, also in der Standardkonfiguration äh das finde ich super, weil äh das zeigt dir halt eben, okay, da ist irgendwie hat dein das LM gerade eine Fehlnlahme getroffen, ähm um das Ziel zu erreichen, warum hat es die Fehlannahme getroffen? Und ähm also bei mir war das eigentlich irgendwie meistens relativ schnell fixbar, aber ich habe halt von Leuten gehört, da hat ein LM 10 Minuten was falsches gemacht, einfach die falsche Richtung gelaufen, weil irgendwo in der Doku noch eine alte Information drinne war und so eine Sachen sollte man natürlich dann aufspüren. Jetzt spricht nichts dagegen, das halt eben auch irgendwann zu automatisieren, aber da sind wir noch nicht. Das ist dann quasi so der nächste Schritt und da kommen wir dann so ein bisschen in die in die Richtung Dark Factories oder Selfimoving Factories.

Sind wir noch super am Anfang, aber extrem spannendes Feld. Ähm, genau. Ich habe deinen Artikel auch vorhin noch gelesen, haben wir schon kurz drüber gesprochen im Vorgespräch und fand den total spannend. und hör jetzt bei dir raus, dass du äh das durchaus ähm ja, sagen wir wahrscheinlich ein bisschen positiver äh betrachtest als ähm äh ich habe ähm Folge Amin Ronacher auch, der gerade mit seiner Firma Eron Deal ähm der Pie sogar gekauft hat, ne, aber auch an dem Produkt arbeitet, wo sie sagen, die haben sich jetzt mit den Coding Agents in so eine Sackgasse gecodet und der, also der ist wirklich erfahren, also der der ist, ich glaube war vorher ein guter Coder.

macht das äh mit den Agents seit sagt mal seit April äh 2025 glaube ich. Das heißt, also ist da auch schon lange dabei gewesen und es für ihn dann so auch explodiert, als dann Cloud Code rauskam und es immer besser wurde. Ähm, aber auch der sagt, also da fehlt noch was. Und äh, also ein Beispiel von ihm ist immer, was ich persönlich auch in in meiner äh Arbeit sehe oder in meinen meinen äh Projekten, die ich so habe, dass die Agents immer versuchen Probleme zu lösen, aber da ist genau diese Entropie nicht auf die Art, die für uns logisch ist.

Also, wenn z.B. ein User Kontext nicht vorhanden ist, dass man dann nicht ein Fehler wirft, sondern dass man dann sagt irgendwie nehme mich halt als Fallback ein Default User. Was dir in so einem Kontext, indem du aber dem Nutzer irgendwelche Informationen anzeigen möchtest, ja, überhaupt gar nicht hilft. Sowas habe ich auch ganz oft gehabt, dass ich eigentlich ganz klar IDs hatte und dann gab es aber ein Fallback, wo wenn die ID nicht äh gefunden wurde, dann der über Namen versucht aufgelö aufzulösen und wenn der Name nicht gefunden, dann auch so ein so ein Default Fallback, was aber oft gar nicht äh das Richtige war.

Lange Rede, kurzer Sinn. Also in im wie du schon gesagt hast, ne, im im in der äh Community oder in der Szene hört man gerade so ein bisschen so eine Ernüchterung und so ein vielleicht müssen wir doch mal wieder händisch Code schreiben. Bei dir klingt es jetzt aber auch nach der äh Analyse der der Studien sozusagen äh durchaus ein bisschen positiver. Höre ich das richtig raus?

Ja, das ist total lustig, weil gar nicht eigentlich kommen die Studien, also kommt eigentlich Programmieren mit KI äh gar nicht so gut weg. ähm bis jetzt und ich habe aber halt eben so ein Cutoff, ne, bei den Studien und der Cutoff ist so ein bisschen so Anfang des Jahres. Ähm ab da habe ich einfach bin ich im Blindflug und ich würde sagen, das ist natürlich das, wo es gerade irgendwie so kamperisch explodiert ist mal wieder. Ähm und bis dahin ist eigentlich gar nicht so äh es ist gar nicht so verrückt.

Also eine Studie, die äh ich 300 irgendwas 350 Unternehmen oder Teams aus mehreren Unternehmen aus von der Stanford University untersucht hat, die sind jetzt so bei im Schnitt in den Teams bei so plus 15 10 15% Produktivitätsgewinne. ist jetzt aber Daten, die schon irgendwie 9 Monate alt sind und äh die besten Teams schaffen es dann vielleicht zu so eher so 30, 25 30 und ist natürlich abhängig, hast du Greenfield, Brownfield Projekte, ne? Wie komplex ist die Codebasis? Ähm, das sind alles Aspekte, die mit reinzählen.

Das ist natürlich für uns jetzt irgendwie nichts super Neues, aber ich fand es trotzdem interessant, das mal äh ja, mal zu sehen eigentlich, was da in wissenschaftlichen Untersuchungen halt eben betrieben wurde im Hintergrund, was ähm was dabei rauskam, was man da sehen kann und ist ja doch immer irgendwie noch mal ganz interessantes in Zahlen zu sehen, als nur ein Bauchgefühl zu haben. Ja, absolut. Genau, das die Evils, ne, die sind ja doch sehr ähm sagen wir mal individuell kleine Sampling und so, die man sonst so hat. Ja.

Ähm genau. Und was da ja auch rauskam, ist das tatsächlich und was du ja eben schon angesprochen hast, ja, Produktivitätsgewinn, gleichzeitig aber durchaus eine Verschlechterung der Qualität bei der äh also der Codequalität sozusagen. Ja. Ja, aber ich ich sehe das nicht wirklich.

Also das ist jetzt und das ist das bringt mich immer so ein bisschen in schwierige Situation, ne? Ich möchte schon, dass also ich bin schon eher so ein positiver Mensch. Ich versuche die Dinge eher äh optimistisch zu sehen und ähm das auch so mit meinen Mitmenschen so zu teilen. Auf der anderen Seite haben wir natürlich hier einen extremen technologischen Umbruch und der wird halt nicht nur zu Gewinnern führen, wenn es wird's auch Verlierer geben.

Ähm, ich weiß war letztens bei der Pendeldiskussion mit Corolla Lilental und sie meinte in ihrem Team ist es so, sie hat halt Entwickler, die jetzt happy sind, weil sie jetzt auf einmal dieses dieses frickelige Code Krams, ne, dieses Debugging nicht mehr machen müssen. Ich weiß nicht, ich mochte das mit dem Debugger irgendwie so durch den Code zu steppen und das war immer irgendwie so ein bisschen ähm ja, so wie so ein Archäologe irgendwie so ganz cool. Ich ich mochte das, aber ist natürlich doch schon sehr relativ langwieriger Prozess und ja, man hat natürlich irgendwie so Erkenntnisgewinn, also ich kann dem schon was abgewinnen, aber es gibt halt eben Entwickler, die einfach sagen, okay, jetzt mache ich das einfach nicht mehr und jetzt bin ich halt happy, das der Architekturarbeit zu machen und den Code zu reviewen. Und es gibt halt Entwickler, die sagen: "Ja, das war genau das, was ich gut konnte und das, was mir am Entwickeln Spaß gemacht hat." Und die haben natürlich jetzt äh wie soll ich sagen, Arschkarte, ne?

Für die ist es natürlich jetzt auf einmal eine nicht mehr so schöne Welt wie vorher. Das also von daher versuche ich es eher so ein bisschen, also schon für mich persönlich positiv zu betrachten, aber ne, also jetzt so in dem Setting, ich möchte das schon offen sein, ja, schon sagen, dass es da nicht nur nicht nur Gewinner gibt, nicht nur Leute, die die da Plus rausziehen. Ich würde noch hinzufügen, wir sind halt immer noch super early on, ne? Ich glaube jetzt die Flinte ins Korn zu werfen und zu sagen, okay, hat nicht funktioniert, lass uns wieder doch mehr Software schreiben.

ist halt, ich glaube, wir versuchen gerade und darum ging es ja heute eigentlich die ganze Zeit in in dem in der Episode besser zu verstehen, wie diese Systeme zu arbeiten, wie diese Systeme arbeiten, einen Griff dran zu bekommen und diese Best Practices abzuleiten, die wir halt weiß ich nicht vor 20 Jahren mit Uncle Bob und Clean Code uns halt irgendwie reingezogen haben, ja, um halt einfach ein Griff an an Software, an Design, an Architekt Tur zu bekommen und genau das passiert jetzt halt einfach auf einer auf einer höheren Ebene bloß hier mit dem Unterschied, dass wir deutlich weiter am Anfang stehen. Ja. Ja. Nee, total.

Und auch ich [räuspern] finde halt auch Testdent Development ähm und Clean Architecture ähm also Clean Code spielt ja total in ähm Programmieren mit KI rein, ne? Das ist ja das passt ja. äh wie die Faust aufs Auge, aber ob jetzt Clean Architecture für uns in 2 d Jahren noch der richtige Ansatz ist, also hexagonale Architektur, Port Filters äh Port Adapters, ähm wir werden sehen, also ich kann mir schon vorstellen, dass da irgendwie ganz ganz verrückte andere ähm Architekturen entstehen, ja, vielleicht auch dynamisch entstehen einfach darauf, weil wir sagen, okay, das ist jetzt gerade, ne, das hat sich sozusagen, wenn wenn man sich jetzt Gradient descent, also quasi die äh wie wir So funktionieren ja das Training von KI Modellen, dass man versucht halt eben so ein so ein lokales Minimum im Optimalfall ein globales Minimum zu finden und sich immer weiter dieser dieser Null diesem Nullwert anzunäheren, ja, so wenig wie möglich Reibungspunkte zu haben in dem Output. Und ähm und das kann ich mir gut vorstellen, dass das für Architekturen auch funktioniert.

Ich hatte letztes Jahr habe ich das mal so ein bisschen angeteasert und hab ein Artikel geschrieben für Informatik aktuell. äh verstärkende Software Architektur und geguckt, okay, wie könnten wir eigentlich dieses Gedankenmodell übernehmen auf Software Architektur und einfach, ne, mit objektivierbaren Parametern. In dem Fall war das halt für ein für ein für ein Partner ähm das Thema äh Latenz, also mit welcher Architektur kriegen wir die beste Latenz hin? Und dann habe ich das einfach durchlaufen lassen durch die Schleife.

Heute wird man das äh Auto Research von Andre Kapassi nennen. Damals habe ich das quasi im Kleiden für mich selber gebaut, um Architekturen durchzuprüfen. Und so kann ich mir auch vorstellen, dass es irgendwann vielleicht gar keine richtige Bezeichnung auf dieser Abstraktionsebene, wo wir jetzt sind mit Architekturen, wo wir jetzt heute sagen, na ja, nimmst du Monolit oder nimmst du Modulit oder nimmst du hexagonal, sondern dass man einfach auf einer höheren Abstraktionsebene auf einmal argumentiert und sagt, ja, ich habe jetzt, was weiß ich, wie man es nennt, ne? Weil ich habe jetzt einen Domain oder vielleicht einen ähm einen einen äh einen einen webbasierten Ansatz gefahren.

Ich habe vielleicht eher so einen Pieransatz oder einen zentralen oder in ein verteiltenansatz gefahren oder sowas, also, dass man gar nicht mehr so weit runtergeht und die Architektur sich quasi selber findet. Endeffekt existiert das ja auch nur, wenn man irgendwie äh einen einen Notwendigkeit hat, diese halt weiter zu verändern, ne, oder zu warten und zu verstehen, ne? Und das ist ja der einzige Grund, warum diese Konzepte halt überhaupt entstanden sind. Bringt mich wieder zu, glaube auch unserer ersten Folge, dass äh quasi das halt komplett verschwinden wird, ne?

Und dann glaube müssen wir auch wieder da verstehen. Es glaube geht so ein bisschen in das, was wir am Anfang halt irgendwie ähm äh diskutiert haben, über was über welche Art von Software reden wir hier? ist das halt irgendwie Greenfield, die Architektur, ne, die kann heute schon anders aussehen. Ähm ist das halt irgendwie Brownfield, also quasi das die Architektur quasi zwangsläufig ist das halt in einem anderen State und kann sich gar nicht so schnell dahin entwickeln.

Ähm aber ich äh ja ich ich glaube, es läuft halt alles darauf hinaus. Es ist halt wie immer, ne? Äh it depends. Ja.

Ja. Und also ich bin auch davon überzeugt, dass es viele, viele neue Felder geben wird. Ähm ja, auch wenn jetzt das klassisch Programmieren wahrscheinlich äh so ein bisschen zu einem Artefakt wird. Und ich hatte das letztens in einem in einem Jobinview, wir hatten ein Jobinterview mit einem Kandidaten und die Aufgabe war halt in der Premiärsprache der Wahl ähm einen ein Genestetes Array zu äh ich weiß gar nicht mehr flach zu machen und zu sortieren oder so.

Also so eine so eine klassische Aufgabe, die man halt ähm die man halt in ein Interview stellt und ich fand das so Spaß, also ich war quasi nur Co in dem Interview. Ähm ich war nicht der der Hauptinterviewer und ich fand das so spannend und dachte dann so, okay, jetzt ich muss das jetzt machen. Und dann hat er das programmiert und ich habe das gleichzeitig auch programmiert, einfach nur, weil ich gucken wollte, ob ich das noch hinkriege und habe dann so mehrere äh mehrere Ansätze gegeneinander verglichen, ne? Einfach nur so ein String Austausch.

Ähm, also man kann das ja unterschiedlich lösen, ne? Muss es ja nicht pasen und dann als Array mit Flatmap oder so, sondern es gibt ja da viele Ansätze und das fand ich, das war so eine Art zu denken, wo ich gedacht habe, wow, krass, so war programmieren damals, ne? Ich habe das komplett vergessen, ich komplett verdrängt. Ähm, ich finde es spannend, dass ihr das in einem äh in dem Interview fragt.

Ähm, aber ähm genau, das führt wahrscheinlich jetzt gerade mit Blick auf die Uhr ein bisschen zu weit. Ich habe mir eine Frage äh so ein bisschen zum Abschluss, bevor wir quasi dann noch zum heißen Scheiß kommen, ähm äh aufgeschrieben ähm was äh quasi jetzt hat das jemand die Episode bis hierher gehört? Äh was ist äh quasi diese eine Sache, die diese Person morgen in ihrem Team ändern sollte? Also, wo fängt man an?

Hast du irgendwie so ein praktisches Beispiel vielleicht auch aus deiner Trainertätigkeit? Also, was geben wir den Leuten hier jetzt mit? Ja, also was ich halt sehe ist Personen starten an unterschiedlichen Orten. Ich habe das nie so krass gesehen wie jetzt.

Also in der Schule, ne, muss man ja irgendwie das das die letzte Klasse abschließen. Ja, muss den Satz des Pythagoras kennen, bevor man halt mit mit Algebra anfängt und und das ist bei Programmieren mit KI auch. Und jemand, der das noch nie erfahren hat, noch nie damit mal rumgespielt hat und mal gesehen hat, okay, wie funktioniert das eigentlich, wann kriege ich einen guten Output, wann nicht und es vielleicht auch so ein bisschen an die Grenzen getrieben hat. ähm der wird einfach da gar kein Verständnis für aufbauen können und wird es gar nicht verstehen, warum das alle so toll finden.

Und von daher glaube ich, wä mein erster Ratschlag, erstmal alle irgendwie versuchen auf ein Level zu bringen und alle eine Brücke zu bauen, um da auch hochzugehen. Ähm, zumindestens versuche ich das und äh das ist schwierig ähm weil wir halt Menschen sind. Und äh zweites ist, wir sind gerade in einer Phase, wo wie ihr auch gesagt habt, ja, wir sind sehr früh, das heißt, es gibt für vieles kein Patrentrezept. Und wenn mich Menschen mit glasigen Augen angucken und sagen, Ingo, das ist aber ich wie soll ich das machen?

Und ich sage, ich weiß es auch nicht. Ich kann dir zeigen, wie es andere machen, wie ich es machen würde, aber das ist nicht wahrscheinlich nicht die richtige Lösung. Ja, die richtige Lösung wird wahrscheinlich irgendwo anders liegen und wir wissen noch nicht, was die Faktoren sind, die das am Ende ausmachen. Deshalb experimentieren, experimentieren, experimentieren finde ich super wichtig.

Mit Ralf hatte ich äh letztes Jahr ein äh Vortrag bei den IT-Tagen zum Thema Benchmarking, ähm so einfach zu gucken, okay, den einen Ansatz gegen den anderen Ansatz zu vergleichen. LMS sind halt probabilistisch, das heißt vielleicht macht man das fünf mal, damit man mehr Gewissheit hat. ob ein Ansatz funktioniert oder nicht, wie oft der nicht funktioniert, wie oft der funktioniert und ähm und damit glaube ich kommt man eine ganze schon schon schon sehr sehr weit. Also einfach messen, was funktioniert, was funktioniert nicht und darüber über dieses messenden Verständnis aufbauen.

Ähm genau, das wäre so mein mein mein Take. Danke dir. Ja, Andre hat's gerade schon angeteasert. Wir haben am Schluss immer noch so ein kleines Recurring Segment und da geht's immer um den heißen Scheiß sozusagen.

Also was ist für dich gerade so der absolute Hype Kram? Ich habe eben ja schon angesprochen, das Thema Dark Factories und Harness Engineering. Äh, das ist schon das, was mich gerade sehr begeistert. Ähm, da steckt eine Menge drinne, zumal es halt eben auch so ein bisschen weiter Denken ist von dem Shanciple, was ich mir quasi ausgeborgt habe.

Ähm, also das ist quasi äh von der Theorie her und von der von vom kognitiven Ansatz für mich total spannend, aber halt eben auch äh von den von den Möglichkeiten, die dadurch daraus entstehen. Und das, was ich bei Eliicht gerade mache, also du kannst da, wir hatten es ja vorhin kurz angesprochen, es gibt fünf fünf Agenten, glaube ich, die ich jetzt unterstütze. Und da gibt's natürlich noch irgendwie, ich habe mal so eine Analyse gemacht, es gibt 50 Agenten oder so mittlerweile, die man quasi unterstützen könnte und die alle da quasi konzeptionell in das Tool reinpassen würden. Und die will ich natürlich jetzt nicht alle integrieren, nicht mal mit KI will ich die integrieren, sondern ich will, dass die sich über Nacht automatisch integrieren.

Und das ist quasi jetzt mein Ansatz, also quasi ich möchte den Hannes das drumherum so stabil machen, dass so klar ist, wann das richtig ist und wann es falsch ist, dass einfach so ein neuer ähm ein neuer Agent über einen einfach einen Skill und halt eben diese diese Guardrates drumherum, die sagen, okay, ist gut oder ist nicht gut, dieses Feedback geben, das einfach so klar ist, dass die durchlaufen und alle super funktionieren. Und mein erster Agent war Ada. Ich weiß nicht oder das ist nicht mein richtiger Agent, aber mein erstes System war Ada und es ist komplett geschei. Also es haben drei von fünf US Casases funktioniert am Ende.

Also ich bin da noch am Anfang, aber ich sehe da halt eben super viel Potenzial. Ja, ich äh wollte gerade schon sagen, wenn du das geschafft hast, das äh konsistent für alle möglichen Agenten zu machen, dann kommst du noch mal hier in den Podcast und erzählst uns, wie du es gemacht hast. gerne, weil tatsächlich Dark Factories ähm ist ein Thema, wollten wir ja auch mal besprechen, müssen wir mal für eine andere Folge uns aufheben, weil die Zeit jetzt leider schon um ist, aber ähm ich bin da insofern, ich habe da noch so ein so ein äh logischen ähm also sagen wir mal äh logischen äh Knackpunkt daran gehend, dass wir ja, ne, also gelernt haben, Wasserfall ist halt nicht gut, weil du ja erst während des Projektes herausfindest, was du ähm was du äh also wie wie das die Lösung aussehen muss, die du brauchst, ne? Und das am Ende ist es ja eigentlich dann nur runtergebrochen, wie groß ist der Loop, auf dem du unterwegs bist, ne?

Und dann bedeutet Dark Factory äh wenn man es zusammendampft eigentlich, dass man einmal am Tag wahrscheinlich noch mal irgendwie reinguckt, okay, was ist jetzt das Ergebnis? Ich wirklich dann aber auch damit ein bisschen beschäftigen muss, je nachdem was es für ein Problem ist, was gelöst wird. wenn du irgendwelche Integrationen machst, wie äh Strong DM oder wie die hießen, die die hatten halt konnten relativ klar genau diese Entropie rausnehmen und diesen diesen äh Loop insofern automatisieren und dem Agenten oder des Hahnes so aufbauen, dass der Agent eben überprüfen konnte äh ob der Output korrekt ist oder nicht. Aber wenn du es nicht hast, wo du halt ein Interface für Humans baust oder so, ähm da musst du dich dann schon selber noch damit beschäftigen, um dann den nächsten Schritt zu definieren wahrscheinlich, ne?

Sorry, jetzt bin ich doch wieder tiefer reingegangen ins Thema, als ich eigentlich Sor, aber noch ganz kurz meine Hypothese, um es zum Laufen zu kriegen und die versuche ich gerade zu beweisen oder zu widerlegen, ist halt, wenn das Ziel klar ist, also das klar ohne dem geht's nicht, weil wenn du erst noch herausfinden musst, was du eigentlich willst, dann ist wird geht's nicht anders. Dann musst du halt im Loop mit drin rumschwimmen. Ähm, wenn du aber weißt, was das Ziel ist und halt wie bei den Agenten die anzubinden, das weiß ich ja, ich weiß welche Stateübergänge es gibt in meiner Lösung und ja, da gibt's halt Fälle so und jetzt versuche ich die Umgebung zu simulieren. Also quasi ich schaffe mir Andre Passi hat mal gesagt, LMS sind people spirits.

So kleine kleine Geisterchen von Menschen, die quasi noch so über sind. Das sind keine richtigen Menschen, wenn man jetzt ja weiß ja nicht, man könnte sagen so ein bisschen die so so eine Art wie die Seele, ne, des Menschen. Also das schwimmt so ein bisschen mit. Es ist nicht richtig ein Mensch, aber es ist irgendwie auch nicht richtig kein Mensch.

Und das kann man zählen. Da gibt's Studien zu, die die es geschafft haben, die Personalität eines Menschen zu 85% im über das LM abzubilden. Also g so Persönlichkeitstests und dann hat man das LM gefragt und das hat 85% das gleiche gesagt, wie halt eben der Mensch, der diesen Persönlichkeitstest ausgeführt hat danach. Und die gleichen Menschen, die haben sie dann zwei zwei Wochen später noch mal das gleiche Labor gebeten und dann haben sie die gleichen Fragen gekriegt und guess what?

Ja, war dann auch so 85% Übereinstimmung mit den Antworten vor. Also LMS sind quasi genauso ich wie ich in zwei Wochen ich bin. Mhm. Und jetzt muss man das richtig sampeln aus dem LM.

Also quasi diese People Spirits, die muss man jetzt laufen lassen und die bedienen quasi dann den KI Agenten auf unterschiedliche Arten und dann erwarte ich dann so ein State Transfer bei mir in meiner Earlichtanwendung, wo dann halt eben ja gesagt wird, okay, jetzt wartet der halt eben auf dich, der Agent, jetzt musst du was antworten und dann kann ich halt eben kann dann der der Agent, der es baut, der guckt dann halt e Protokoll, okay, ist es sinnvoll überhaupt gerade? Also macht, ergibt es Sinn und der Kunde, der LM Kunde, der sich das quasi anguckt, der muss dann auch sagen, okay, er gibt es Sinn, für mich passt das gerade? Und zwar habe ich halt eben mehrere Quellen und versucht so ein bisschen diese diese Lösung zu triangulieren aus den aus den unterschiedlichen Sampling Quellen vom LM. Und ja, das ist ähm das ist schwierig, weil das ist eine schwierige Aufgabe, weil halt eben nullvertreten im in den Gewichten vom LM, ne?

In ein halben Jahr ist es auf einmal einfach, aber jetzt ist es halt noch schwer. Und das finde ich interessant gerade. Absolut. Ja.

Und äh genau zum meisten Scheiß fragen wir auch immer nach What the Momenten. Hast du auch hin und wieder What the Momente noch? Oder sagst du o eigentlich durch dein Eichhaus Principle bist du so immun dagegen, dass du alles gut umschiffen kannst? Ja, also ich muss sagen, für mich selber mir fällt's immer ein bisschen schwierig so.

Also ich habe bestimmt ganz viele what the Momente und ich aber für mich ist das so normal, ne? Weil es ist halt so, wie du Menschen redest, dann [japst] weiß ich auch nicht, ich würde es ja auch nicht jedes Mal fleggen, wenn dich irgendwer nicht richtig verstanden hat. wenn du mit ihm redest. Ähm und ich hatte aber was das hatte ich mir mal gerade aufgeschrieben, mal gucken, was es war.

Ähm ich hatte nämlich am Wochenende mit meinem Startup aus den USA telefoniert und die hatten nämlich ein Problem. M ach genau, da war folgendes passiert. Die haben in den Prompt mit reingegeben oder der Entwickler hat in den Prompt mit reingegeben. Hey ja, es muss aber schnell fertig gestellt sein und da ging es um Multitendency in dem System und Multitendency, ich weiß nicht, wenn ihr das mal gemacht habt irgendwie in die Richtung, das ist schon ein bisschen Aufwand, ne?

Da muss schon ein bisschen eine Datenbank rumkratzen. Das muss den Authentifizierung äh Autorisierungsflow ein bisschen ändern. So hast schon ein bisschen was mit zu tun. Und hat das das KI Modell gesagt, na ja, also ganz ehrlich, äh wenn du das morgen haben musst, dann bau doch da eine Umgebungsvariable rein, ne?

Und dann hatte dann die E-Mailadressen mit dem dazu gemappten Tenant als Umgebungsvariabel reingeschrieben. Das ist so der Ansatz und dann habe ich mir das angeguckt und hab gedacht, um Gottes Willen, warum? Und dann habe ich dann das nachverfolgt und dann habe ich gesehen, ja, eigentliche Trigger dafür, um diese Entscheidung zu treffen, war halt, dass das LM gesagt hat, ja, es [schnauben] muss ja schnell gehen. Ähm und aber schnell ist halt anders jetzt auf einmal, ne?

Jetzt gibt's kein langsam mehr, also ne, also es geht nur noch schnell. Also, warum sollte ich noch irgendwas hat halt gelernt, schnell gleich schlecht. Es gibt ja dieses äh quasi dieses berühmte Bild, das gibt halt irgendwie schnell, günstig oder und gut, ne? Und du kannst zwei äh zwei kannst du halt irgendwie auswählen.

Ja, ist halt äh an der Stelle äh quasi schnell und gününstig, wird halt nicht gut, warum auch immer günstig. Vielleicht war klar sie ist der Startup bei dir auf keinem äh auf keiner Max Subscription von Clod sind die auch Sind die auch. Nein, nein, das ist auch einfach nur, das sind so Kleinigkeiten, ne, wo man sich denkt so krass, wie sich so Kleinigkeit halt eben auswirkt am Ende. Ähm und ich habe auch nur Spaß gemacht, aber es es ist am Ende die sind ganz toll und die machen ganz ganz klasse Arbeit, also sonst wä ich da nicht mit involviert.

Also, der will das gar nicht, die machen auch sonst alles ganz toll. War wirklich nur in dem Moment irgendwie so ein Beispiel, was mir aufgefallen ist, wo ich gedacht habe so, ach guck, [gelächter] das ist ja nett. Fairerweise wäre aber da spannend halt irgendwie zu verstehen, warum solche Sachen äh quasi das triggern, ne? Ähm, das wäre also wäre zumindestens meine Folgefrage, weil eine richtig logisch eine gute Erklärung hätte ich dafür nicht.

Ja. Ja. Also das genau, also das das LM hat halt eben eine Vorstellung von Zeit, die basiert noch auf von vor zwei Jahren oder vorm Jahr und also auf den Trainingsdaten halt, ne? den Trainingsdaten ist halt ja halt dauern die Dinge halt länger und wenn es schnell gehen muss, dann ist halt laut Trainingsdaten machst halt hacky und ich glaube halt jetzt sind wir das erste Mal in der Geschichte in der Programmierung an dem Punkt, wo wir einfach das vielleicht ein bisschen äh challengen können, dieses äh dieses dieses Dreigestören von ob es jetzt gut oder schnell oder günstig ist, weil also ich glaube, das gibt's immer noch, aber aber Was verschiebt sich jetzt gerade in eine Richtung, wo wir äh als Ingenieure gut erstmal an der Qualitätsschraube lange drehen können und ja, 100 pro und es doch noch nicht wirklich langsam sich wirklich langsam anfühlt, ne?

In z d Jahren ist es dann vielleicht fühlt sich dann langsam an, wenn man an der Qualitätsschraube viel dreht. Gut. Ja, vielen Dank. Ja, war eine sehr interessante Folge.

Der HMZE Podcast ist ein gemeinsames Projekt von Sebastian Heidemier zu Erpen und Andre Neubauer. Infos zum Gast und Themen aus dem Podcast findest du in den Showotes. Diskutieren kannst du mit uns bei LinkedIn und für alles andere, z.B. wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an podcast@hamzde.

Vielen Dank für deine Zeit. Wenn es dir gefallen hat, abonniere im Podcast. Bis zur nächsten Folge.