Latest / Beyond Vibe Coding / #061 Das Eichhorst Prinzip - mit Ingo Eichhort (IONOS)
Transcript
- Sebastian: Herzlich willkommen Ingo. Wir freuen uns, dass du da bist. Wir haben ja neulich mit Ralf gesprochen und der hat das Ingo 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, äh unseren Hörern einmal kurz vor. Ingo: Ralf ist klasse. Mit Ralf macht es großen Spaß, die Welt der KI zu erkunden, aber natürlich auch ⁓ mit meinen anderen Projekten, die ich so am Laufen habe. Und meine Historie ist, ich habe schon ⁓ als quasi angefangen, wahrscheinlich schon bevor ich Teenie war. ⁓ mit meinem ersten C64. Mein Vater hat mich da so bisschen rangeführt, hat gesagt, das ist eine coole Idee, mach das. Und darauf dann kleine Programme geschrieben, irgendwie so in die IT-Welt reingekommen, dann ein bisschen abgedriftet. Im Uni hab ich BWL studiert und bin dann erst später dann in einem anderen Studiengang dann wieder an die Informatik rangeführt worden. Das heißt, ich hab auch am Anfang als Projektmanager gearbeitet und bin dann später wieder an die Basis zurückgegangen. eigentliches entwickeln, programmieren. Da PHP gemacht, JavaScript, auch C, Kunterbunt, alles Mögliche. Auch DevOps meine ganze Weile. Und 2019 habe ich bei uns in der Firma, die damals die CTO-Rolle übernommen. Wir haben so Online-Streaming-Angebote gehabt. Damals hauptsächlich sind wir so ein bisschen weggegangen von von klassischem Livestreaming und klassischem Video on Demand hin zu mehr Advertisement und dynamische Werbeinsatierung. Und genau da habe ich die CTO-Rolle übernommen, ein kleines Team aufgebaut von einem Entwickler auf zehn Entwickler. Und ja, genau, das Unternehmen wurde irgendwann verkauft und das war irgendwie meine Chance, meine Gelegenheit mal was anderes auszuprobieren. Dann habe ich in der Beratung gearbeitet und ersten Jahr Bankenbereich und Stiftung. Das war super spannend. das war so 2022. Und ich hatte davor schon mal Beta-Tester bei GitHub Copilot und habe die Image-Modelle ausprobiert und dachte, okay krass, da entsteht wirklich was. Man sieht hinter mir, sieht man noch die Bilder, so mit einer ganz frühen Mid-Journey-Version entstanden sind. Es ist ja alles noch nicht lange her, aber es kommt einem halt schon echt vor wie eine Ewigkeit. Und ja, da war ich extrem begeistert. Das hat mich gecatcht und deshalb gab es dann noch eine Möglichkeit. Dann habe ich kurz für KPMG gearbeitet, diese Firma da wieder aufgekauft wurde. Und dann gab es die Möglichkeit, Deutschland ein KI-Team, generative KI-Projekte aufzubauen, auch für eine Beratungsfirma. Und ja, das habe ich dann genommen. Das war meine Chance. genau, das habe ich ein Jahr lang gemacht. Dann irgendwann ist ihnen aufgefallen, kein Geld aus einer japanischen Firma. André Neubauer: Hm. Ingo: Und irgendwann ist ihnen aufgefallen, dass das Geld ausgegangen ist oder in den Banken ist das aufgefallen. Und dann mussten sie ein paar Büros schließen. Das waren natürlich die, die noch keine schwarzen Zahlen schrieben. Und da wir ja erst irgendwie Jahr werkeln waren. wisst ja, solche Dinge dauern ein bisschen. Waren wir da halt eben von mit betroffen. Und dann war dann die Überlegung, okay, entweder ins Ausland gehen dort, dann in der Beratungsfirma hinterher oder halt eben hier in Deutschland was suchen. Und genau. Und damals, das war so... André Neubauer: Mhm. Ingo: 2024, da war die Frage, in welche Richtung soll es gehen? habe mich auch bei Aleph Alpha beworfen. Also ich wollte schon gerne in dem KI-Bereich bleiben. Und bei Jonas war halt das Spannende, da gab es halt sowohl den ganzen KI-Bereich als Austrobefeld, 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-Agenten verstehen. Damals hat halt noch niemand drüber geredet. dann war die Überlegung, wenn ein Safe Play ist, Infrastruktur auf jeden Fall, weil wenn jeder programmieren kann, dann was brauchen die? Die merken dann irgendwann auf Local Host, ist halt schwierig von außen zuzugreifen. Und dann brauchen sie Server. Also probieren wir das doch mal. Und jetzt bin ich hier wirklich... bei Jonas Happy und das ist wirklich cool. Ich kann da natürlich nicht wirklich tief drüber sprechen heute. Ich bin aber nebenbei noch so Beratender CTO bei einem Startup in Staaten. Das macht auch großen Spaß und berate und mache so nebenbei noch kleine Schulungen 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 Entstehungsphase ist. Und da kann ich auch gerne berichten, weil da mache ich was. Das habe ich jetzt High Speed Open Source getauft und da kann ich gerne ein bisschen was von erzählen. André Neubauer: Bevor wir da reinspringen, ich muss trotzdem die Chance nutzen. Was macht ein Engineering-Trainer day to day? Wie muss ich mir das vorstellen? Ingo: Ich glaube, ist schon eine also eine wenig verbreitete Rolle. Ja, ja, mir war das, also ich wusste das vor quasi zwei Jahren, hatte ich davon auch keine Ahnung, dass es das überhaupt gibt. Ich damals, dachte ich so, ⁓ sich neues Wissen anzueignen, guckt man halt YouTube-Videos. Das ist halt schwierig bei größeren Firmen, wo halt André Neubauer: Absolut, deswegen frage ich. Vielleicht lernen wir was. Ingo: viel auch Know-how in den einzelnen Bereichen sitzt und man quasi Silobildung vermeiden möchte. Und nicht jeder ist halt Rechtsexperte 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 Teams, vielleicht schon was entworfen, vielleicht schon was gebaut haben, dass diese Lösungen auch durch andere Teams genutzt werden können. Ich bin auch selber in Entwicklungsprojekten mit beteiligt, einfach damit ich nicht einstaube, zu doller. Und auch, dass ich immer was habe, was ich mitnehmen kann und gucken kann, wie auch die Sachen umgesetzt werden in meinen Trainings. Dieses Jahr habe ich viele Workshops gemacht zum Thema agentisches Poemieren, Poemieren mit KI-Agenten, jetzt auch mehr und mehr Harnes Engineering. Und das geht von den Basics bis zu dem, was gerade so Dark Factory, was gerade am Rand irgendwie erkennbar ist und anfängt möglich zu sein und dann mit anderen zusammen Konzepte erarbeiten, aber halt eben auch durch Workshops führen, Konzepte trainieren und diese Brücken bauen halt. Und Hackathons biete ich auch noch an, das ist immer gerne genommen. Finde ich auch cool, weil dann habe ich nicht ganz so viel zu tun. In den Workshop-Tagen stehe ich dann da und quatsche viel und begleite dann bei den einzelnen Sessions. Hackathons sind immer ein bisschen entspannter. ⁓ André Neubauer: Das daf- Verstehe ich spannend. Gibt es einen Trainer oder wie viele Trainer gibt es? Ingo: Ja, ich bin quasi der Engineering-Trainer. bin auch, also Jonas ist ja groß, könnt ihr euch vorstellen. Wir haben ja extrem viele Brands, die dazugehören aus unterschiedlichen Ländern. ich bin jetzt im Cloud-Bereich verortet, versuche auch da natürlich immer mal bisschen links und rechts zu schauen. Aber das ist so mein Home turf. André Neubauer: Hm. Ok. Cool. Spannend. Dank dir. Sebastian: Ich hätte jetzt irgendwie fünf Folge fragen, die würden aber glaube ich unseren Rahmen hier ein bisschen springen. Deswegen, da kommen wir bestimmt später noch auf das eine oder andere zurück. Lass uns wie üblich einsteigen mit der ersten Rubrik, dem Text Deck. Du hast ja auch gesagt, du bist auch in Engineering-Projekte involviert, hast Open Source-Projekte. Das heißt, dein Text-Deck ist tatsächlich auch oder Tools-Deck ist tatsächlich auch ein Coding oder Engineering relatierter Toolstack. Genau. Was nutzt du? Wie arbeitest du? Welche Skills? Was auch immer. Ingo: Ja, Also ich hatte ja schon kurz angesprochen, jetzt privat, was jetzt das verrücktest ist, würde ich sagen, was ich gerade mache, ist so Projekt, OMSource Projekt, das heißt Öhrlicht. Und da hat man quasi in seiner Menülisteleiste auf macOS erst mal, irgendwann dann auch noch auf mehr Betriebssystemen, hat 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 ... André Neubauer: Hmhm. Ingo: und Aggregat. Und die gruppieren sich dann auch nach Projekten und helfen einem einfach 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, ⁓ zu gucken, ob die Agenten schon fertig waren. Und dann hat man mehrere Agenten auf mehreren Screens laufen, komplett die Übersicht verloren. Und das hilft mir jetzt sehr. Genau. Und das baue ich halt. Bitte. Sebastian: finde ich, dass du auch Pi unterstützt. Gut finde ich, dass du auch den Pi Agent unterstützt. Ingo: Ja, das war einer der ersten. Also ich glaube mit Cloud Code, klar, das muss man halt. Pi und Codex habe ich angefangen, weil das sind meine Treiber, meine täglichen Treiber. genau, und 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 nochmal gefixt, eingereicht worden. Und das ist Open Code, also auch ein ganz klasse André Neubauer: Hm. Ingo: ganz klasse Agent. Genau, und dann kommen da noch Agenten-Orchestrierungen mit rein, also jetzt Guest Town zum Beispiel oder Claude Squad, also das wächst und ich glaube auch, da wird es eine Menge zu tun geben in nächster Zeit. Genau, und das ist vom Text-Tech her hauptsächlich entwickelt mit Claude Code, ein bisschen Codex, ein bisschen Pi für ganz, für unterschiedliche Anwendungszwecke und vom Also von der Poemiersprache habe ich einen Backhand-Golang. Das habe ich einfach herausgefunden, das gefällt mir am besten mit Coding-Agenten, weil das so schön idiomatisch ist, so schön klar, gut ist und was schlecht ist. Das hilft den Agenten gut, sich zu orientieren. Und im Frontend nehme ich whatever. Meistens sind das eher Synth-Clients und dann ist es mir eigentlich wurscht, was es ist, weil das kriegen die Agenten einfach so one-shot meistens relativ gut hin, was ich von ihnen haben will. André Neubauer: Wurde das Thema rund ⁓ Golang? Das hatten wir auch schon mal, glaube ich, Stefan tatsächlich mitgebracht. Wahrscheinlich sogar mit in der ersten Folge. Hast du da irgendwie so empirische Daten? Also hast du dir Erfahrungen gesammelt, wie bist du da drauf gekommen? Lass mich das offen fragen. Wie bist du darauf gekommen, dass Golang quasi für dich da der beste Pick ist? Ingo: Ja, gute Frage. Es ist auch eine Sprache, die bei Jonas verbreitet ist, muss ich sagen. Also von daher so ein bisschen natürlicher Catch auch gewesen, weil ich ⁓ besser in Golang werden wollte. Aber es gibt auch Untersuchungen zu dem Thema Studie und zu dem Thema, welche Pugamiersprache ist am besten geeignet. Und da schneidet in der Regel Go nicht als beste Pugamiersprache ab, weil einfach der... der Footprint noch nicht groß genug ist. Die meisten Issues auf Stack Overflow sind einfach JavaScript oder Python und deshalb sind diese Sprachen viel besser geeignet. Aber die Studien gucken sich One-Shop-Generation an. quasi das klassische, ich schreib was in meinen Chatbot rein und sag, mach mir eine Python-App und ich krieg dann eine Python-App oder eine Go-App und ich krieg eine Go-App rausgegeben. Das machen wir ja nicht mehr. Da sind wir ja nicht mehr in dem Stand der das Wissens, sondern wir sind ja schon einen Schritt weiter. 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 da passt Go halt sehr gut, weil bei Go ist es relativ klar. Das Go-Format und idiomatisches Go. Und da kannst du deine Checker drüber laufen lassen, die dir einen deterministischen Output geben. Ob der... ob das gut ist, was der Agent produziert hat oder nicht. Und das ist bei JavaScript komplett anders. 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. Aber das ist halt doof für die Agenten, weil die natürlich dann auch alles machen. Und vielleicht nicht unbedingt den besten Weg wählen, sondern halt irgendeinen. Und dann hast du auf einmal drei unterschiedliche Ansätze, eine und dieselbe Sache zu machen in deiner Code-Basis. André Neubauer: Hm. Ja. Ingo: und muss das halt eben rückwirkend unterbinden. Und Go kommt schon mit diesen ganzen Bordmitteln. Und von daher feiere ich das. Und Rust ist mir zu kompliziert. Da habe ich es noch nicht geschafft, tiefer reinzuschauen. Sonst wäre es vielleicht das. Und so ist es hauptsächlich Go. Sebastian: Und es fairerweise, ich glaube, da hat Go oder auch TypeScript wahrscheinlich haben da so einen Sweet Spot auf der einen Seite typisiert und deswegen gut auch überprüfbar sozusagen das Ergebnis. 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. Und ich glaube, ist Go einfach. Go und TypeScript sind wahrscheinlich so die perfekten Languages dann. Ingo: Ja, ja. Aber ich muss auch sagen, ich mache im Frontend für Ehrlich, das ist ja so eine Menübar-App. Das ist alles SwiftUI, also alles. Das ist jetzt nicht viel, das sind vielleicht 1000 Zeilen, ja nicht mal. Ja doch, um die 1000 Zeilen Quote, Frontend Quote. Also das ist ganz wenig, aber muss ich sagen, ich null Probleme mit, das funktioniert wunderbar. André Neubauer: Hm. Ingo: Also, ich würde das jetzt nicht nur auf TypeScript begrenzen, aber TypeScript besser als JavaScript auf jeden Fall durch die Typisierung halt. Also, schon ein Fehleraspekt irgendwie rausgenommen aus der Gleichung und ja, das hilft halt. Sebastian: Ja, ich habe selber sogar eine TypeScript, sorry, eine Swift App geschrieben. Genau die gleiche Experience sozusagen. TypeScript war einfach nur ein Beispiel, weil es wahrscheinlich noch weiterverwendet ist, wobei Swift glaube ich auch nicht selten ist. Ingo: Ja. Das hat sich ja durchgesetzt im IOS-Bereich schon lange. Sebastian: Anyway, wir wollten ja eigentlich über deinen Text Stack sprechen. Genau, also welche Agents, welche Skills und so nutzt du oder harnesses auch. Ingo: Genau. Ja, ich muss sagen, ich probiere immer irgendwas Verrücktes aus. Also ich habe eine Zeit lang mal das, also vor zwei Monaten oder so, Gadget Done eine ganze Weile ausprobiert mit einem Projekt und muss dann sagen, der Name ist genau das Gegenteil von dem, was passiert. Also irgendwie wird man damit nie fertig. Es dauert immer alles ewig lange. ich bin jetzt hauptsächlich, also ich versuche immer, Dann nach einer Weile, wenn ich irgendwie ein neues Framework oder einen neuen Ansatz ausprobiere, wieder zurückzugehen zu Vanilla und zu gucken, wie anders ist einfach die Vanilla-Lösung. Im Moment bin ich relativ happy mit den Bordmitteln von Claude Coat, muss ich sagen, im täglichen Arbeiten. Und wenn man jetzt wirklich einen riesen Batzen hat, 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 handhabbare Aufgabenpakete runterbreche, dass ich die noch gut überschauen kann und dass die Agenti eigentlich gut abarbeiten kann. Weil ich habe auch ein Problem bei diesen riesengroßen Spectrum Development Frameworks. Du erzeugst ja extrem viel Speck und ich habe keinen Bock so viel Speck 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 peu à peu umsetzen, also eher so iterativ. Genau. André Neubauer: Hm. Ich weiß, vielleicht schneiden wir das nachher auch einfach raus. Du kannst auch nein sagen, Ingo. Wie macht ihr denn das bei IONIS? Versucht ihr da eher einen Stil hinzubekommen oder in Anführungsstrichen zwingt ihr die Leute in ein Workflow? Also, im Angenommen, würdest jetzt in ein Training gehen und dort würden Leute sagen, wir machen das hier in dem Team, machen wir das halt immer Spectripen. Quasi würdet ihr versuchen, da eine Linie zu führen oder gibt ihr die Freiheit? Ja, genau. Ingo: Also da kann ich jetzt natürlich nicht super ins Detail reingehen. Ich versuche meine Trainings immer so aufzubauen, dass die schon eher anhand der Grundlagen, also der Prinzipien her agieren. Und mein Ansatz ist eigentlich zu sagen, wie komplex ist das Problem? Und wir lernen quasi in den Trainings, wie komplex Problem ist. André Neubauer: Hm? Ingo: Und da gibt es ja auch Tools für, die einem helfen, mal das zu verstehen, was ist komplex aus der Sicht eines Agenten. Taskmaster, glaube ich, heißt das. Das macht so eine Komplexitätsanalyse mit einem LLM. Aber das kann man sich ja auch schnell als Skill selber schreiben. Und dann kriegt man halt eben so ein Output und kriegt so Gefühl dafür, wie viel, wie krass doch ein einzelner Task ist. Und anhand der Komplexität, die erörtert wird, sagen wir dann, treffen eine Entscheidung. Also einfach nur Claude Code reinschreiben, fertig, oder Pi, oder was auch immer für einen Agent genutzt wird. Oder wir holen ein bisschen weiter auf, machen erstmal einen Research Run und machen dann einen Plan, reviewen den Plan, verbessern den vielleicht nochmal und lassen es dann laufen. Das Krasseste ist halt Spectrum Development. Ich kenne Leute, die Spectrum 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, so weit geht das nicht. Also es gibt da sicherlich Vorgaben und Ideen, man das, was ein guter Ansatz ist. Und es gibt sicherlich auch Non-negotiables, die man einfach vorgeben, also einfach aus einem rechtlichen Rahmen, die vorgegeben sind, aber Was die Teams einzeln machen, extrem abhängig von ihrem Tag Stack und von den Sachen, die sie einsetzen. Sebastian: Das macht auch total Sinn. Also bei so einem großen Laden wie Yonos gibt es zentrale Core Services, einfach ganz anderen Rahmenbedingungen unterliegen als irgendwelche Sachen, im Marketing Stack sind oder so. Ingo: Ja. Genau. André Neubauer: Ja, und trotzdem denke ich, gibt es wahrscheinlich so einen Bodensatz an Sachen, halt jetzt gar nicht zu sehr abweichen, abspeifen heute. Aber gibt es halt irgendwie so ein Basisset an Non Negotiables, also nicht funktionale Anforderungen, meistens irgendwie Security Compliance Schlag mich tot, die halt dann doch wieder für alle relevant sind. Und also wie wie kriegst du da einen Griff dran, ohne dass es halt quasi ein ganz enges Korsett wird? Deswegen. mich unheimlich interessiert hat, fragen, wie man das angeht, weil jede mittelgroße Firma wird dieses Problem haben oder hat dieses Problem. Ingo: Ja, Also ich bin ja nicht der Entscheider am Ende. bin ja der, der die Nachricht überbringt an die anderen. Ich kann das ja nur weitergeben, mittragen und vielleicht, wenn ich sehe, dass Teams das auf die eine oder andere Art umsetzen, dann nehme ich das natürlich mit in die Trainings und zeige so Wege auf. es gibt auch Themen, wo ich das aufzeigen kann, wo ich die André Neubauer: Sehr schöne. Ingo: Grundlage habe, die Basis quasi, wie wir die angehen. Zum Beispiel Datenschutz, Datenklassifizierung ist ja ein Thema bei KI. Was darf man wo verwenden, mit welchen Tools? Wo haben wir welche Auftragsdatenverarbeitungs-, wie heißt das Auftragsdatenvereinbarung mit dem Kunden geschlossen und was ist sozusagen der Rahmen, in dem man die Daten dann verwenden kann? Das sind dann Non-Negotiables. Das kann man dann klassifizieren, einschätzen als Team. André Neubauer: Hm. Ingo: und kann dann sagen, ich fall in die oder in die Kategorie. Wir haben auch Open Source Tools, die sind natürlich dann public. Da ist es dann egal eigentlich. Also jetzt auch nicht komplett, aber zu großen Teilen egal, wo die den Code reinstecken. Und dann gibt es halt andere, die High Secret, Top Secret sind. Da sieht die Welt halt komplett anders aus. Sebastian: Das finde ich schon mal super, also sehr allgemein formuliert, aber ein super Finding oder Ansatz, wie man es in der Organisation angehen kann, dass man Teams einfach klassifiziert nach genau den Rahmenbedingungen, die du da angegeben hast. Also wo wird mit Kundendaten direkt agiert, beziehungsweise wo würden Kundendaten möglicherweise einmal an den amerikanischen Server geschickt werden, wo ist es völlig unkritisch und je nachdem kann man dann auch andere Rahmenbedingungen setzen. Macht total Sinn. Ingo: Genau und in den Trainings bringe ich dann eher so was rüber, wie man so eine Klassifizierung macht. Das heißt also, da arbeite ich gerade dran tatsächlich, weil ich die Rückfrage halt so oft gekriegt habe. Das ist eigentlich nicht mein Metier, weil ich halt schon eher Engineering-Praktiken irgendwie runder rüberbringen will. Aber die Frage kam halt sehr oft und deshalb baue ich das jetzt ins Training mit ein. So quasi, einfach so spielerisch zu lernen, okay, wie klassifiziere ich eigentlich meine Daten. Sebastian: macht Sinn. dann ⁓ das abzuschließen. Also ich höre raus, du arbeitest sehr viel Vanilla und ich höre raus, so Claude ist auch wahrscheinlich so dein Go-To Agent und ja, alles klar. Ingo: Ja, hängt auch damit zusammen, dass ich, hatte ja die amerikanische Firma da angesprochen, die ich noch berate, da nutze ich halt, also die stellen mir einen 200 Dollar Anthropic Plan zur Verfügung und das ist nämlich näher, ne, also ich würde, wenn ich einen 200 Euro Open AI Plan hätte, dann würde ich halt Codex nutzen, also ich bin da, ich bin da leidenschaftlos, muss ich sagen. André Neubauer: Hm. Ja. Ingo: Ich es, mit allem rund zu spielen und auch mal die Tools gegeneinander antreten zu lassen. Zum Beispiel, wenn Codex, Claude-Code, also Claude-basierten Code analysiert, ist Codex immer sehr kritisch. Gemini auf der anderen Seite sagt immer so, hey, das ist viel besser, als du dich selbst bewertest. Stell dein Licht mal nicht unter den Scheffel, du bist so toll. Du kannst so toll einen Code schreiben. Und Codex ist eher so, na ja, also komm, da könntest es noch ein bisschen besser machen. Das war ja nicht so dolle. Das ist ganz witzig. Sebastian: interessant ich hatte ich hatte so ein umgekehrt halte genau so ein ähnliches erlebnis da war es nicht codec sondern geht ab co pilot und da glaube ich das standard modell was klob koth kritisiert hat und klob koth hat dann auch beschämt anerkannt ja das sind alles valide punkte so anyway ja Lass uns mal, wir sind schon ein bisschen fortgeschritten jetzt in der Zeit, lass uns mal zum Hauptteil der heutigen Episode kommen, nämlich zum Principle ⁓ Principle und sicherlich davon abgeleitet dann noch zu einigen damit korrelierten Themen oder Themen, die damit zu tun haben. genau. ⁓ Ich glaube, du hast es nicht so genannt, sondern es war Ralf D. Müller, der es so genannt hat. Ich glaube, du hast es nicht so genannt, sondern es war Ralf D. Müller, der es so genannt hat. Ingo: Ja, es ist mir ein bisschen peinlich oder ein bisschen unangenehm, muss ich Ja, es ist mir ein bisschen peinlich oder ein bisschen unangenehm, muss ich sagen. Genau, Ralf und Eichhorst-Prinzip. Das ist schon so ein bisschen, ich sage eigentlich ein Witz, aber das ist ⁓ schon so ein bisschen ein Experiment eigentlich. Also die Idee ist, ⁓ formulieren das, wir bringen das mal raus oder er bringt das raus. Mir ist das wie gesagt ein bisschen unangenehm und wir gucken mal, wann das in den LLMs vertreten ist und ob man so quasi so ein Konzept, was einfach noch nicht gab, und das gab es halt nicht. Es gibt andere mit dem gleichen Nachnamen wie ich, aber es gab halt keinen, irgendwann mal gesagt hat, ich mache jetzt mal ein Prinzip draus. Und wie lange dauert das, das in die LLMs rein sackert. Also von daher, gebt das ruhig gerne weiter, auch wenn es ein bisschen unangenehm ist. ⁓ Ja und die Idee ist entstanden im Anfang März war ich auf der Java-Land und habe einen Vortrag gehalten zu einem Thema, eigentlich so mein Herzensthema ist, Architektur 3.0, haben wir es mittlerweile genannt. Also quasi die Idee, dass mehr und mehr Architektur in den Vordergrund gestellt wird, weil wenn Agenten die Code-Arbeit also das eigentliche Schreiben des Codes übernehmen, dann quasi geht meine Rolle als Entwickler einen Schritt weiter raus, also eher auf die Architekturarbeit und aber auch die Architekten, die heute versuchen Menschen zu steuern und Menschen irgendwie Vorgaben zu machen, eine Richtung zu lenken. Das werden dann zukünftig dann eben mehr mehr KI-Agenten sein. Und mein Ansatz, das so bisschen rüberzubringen, wie man das machen kann, dass man halt ⁓ Input in das LLM, also einen Prompt reingibt und am Ende was Funktionierendes bei rausbekommt, ⁓ 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 eine Nachricht überträgst, also jemand spricht in ein Mikrofon rein, so wie wir das jetzt machen, dann ist dann eine gewisse Wahrscheinlichkeit, dass das verrauscht wird und auf dem Weg nicht funktioniert. Damals war das halt eben analoge Telefone. Mosegeräte. Man wusste halt eben nicht mit 100 Prozent hier Sicherheit, ist das wirklich was hinten rauskommt, ist das wirklich korrekt. Jetzt kann man halt eben diese Signalspitze erhöhen und was Shannon halt gemacht hat, der hat so einen Korrekturmechanismus eingebaut. Also ich nehme mal gerne als Beispiel so ein QR-Code. Ein QR-Code hat nämlich auch so einen Fehlerkorrekturmechanismus und wenn man dann beim Einkaufen mit dem Wurschtfinger drüber geht und dem bisschen verwischt, den QR-Code ist das überhaupt kein Problem. Der kann bis 30 Prozent verlieren, einfach komplett weg und ich kann das am Ende wieder rekonstruieren über halt eben den Fehlerkorrektur-Algorithmus. Und so ein bisschen so sehe ich das bei LLMs halt auch. Also ich gebe halt was rein, das hat Unschärfe, weil ich nicht klar genug in meiner Formulierung bin, weil einfach meine Konzepte, meine gedanklichen Konzepte anders sind als die von dem LLM vielleicht, weil ich domainenspezifische Sachen reingebe, die das LLM gar nicht kennen kann. Das heißt, ich bringe so bisschen Rauschen schon von draußen rein. Dann habe ich das Sampling im LLM, noch 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. genau, die Frage ist jetzt, wie mache ich das? Und da kann ich genau an diesen Punkten ansetzen und da hat Shannon halt eben schön einen Transmitter und den Kanal und den Receiver. Und das kann man wunderschön, dieses Prinzip, das kann man wunderschön auf Das LLM übersetzen als Transmitter ist quasi dann halt eben wir oder die Spezifikation. Dann haben wir den Kanal, das Sampling aus dem LLM. Man kriegt ja nicht immer den gleichen Output, sondern das ist ja durch die Temperature ist das Sampling ein bisschen angepasst. Aber auch so ist es unscharf, weil man ja nie genau das trifft, was du treffen willst. Ich mache mit meinen Trainies, aber auch mit meinen Studenten. bin also noch Dozent nebenbei an der Uni und mit denen mache ich immer so ein Sampling-Experiment. Wir geben eins plus eins ein und dann das ist gleich in so ein kleineres LLM und da kommt dann meistens raus sowas wie zwei, aber nur mit 66 Prozent Wahrscheinlichkeit. Und dann versuchen wir das weiter zu verrauschen, sodass halt eben irgendwann nicht mehr zwei rauskommen. Die Frage, wie können wir das verrauschen? Wenn man jetzt zum Beispiel 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. Team Synergies als Anker rein, kommt auf einmal eins plus eins ist drei raus. Aber wir jetzt auf einmal einen Anker gegeben haben, eine Klarheit gegeben haben, mitgegeben haben, am Anfang schon für das LLM. Das Sampling ist immer noch rund, klar, aber auf einmal ist das nicht mehr 66 Prozent, sondern das ist halt irgendwie 90 Prozent. Das heißt also, 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 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 einen Fehlerkorrektur-Mechanismus, der wieder einen heilen QR-Code draufmacht oder der sich beschwert und sagt, mach nochmal ein Foto oder find halt einen... Heilen-QR-Code. Das sind so die beiden Möglichkeiten. Und eigentlich ist das relativ genau das, was wir beim Programmieren mit KI auch haben. Der Output ist entweder, sagen wir jetzt mal in der ersten Stufe, irgendwie, wir lassen vielleicht einen Type-Check drüber laufen und der Type-Check ist okay oder ein Linter drüber laufen und der Linter sagt, das ist alles super. Dann ist es okay. Das ist dann so wie der QR-Code, der in Ordnung ist, der genug Informationen enthält. Oder es geht wieder zurück an den Absender. Und ich ist halt nicht type safe. ist halt oder also die Typisierung ist nicht korrekt oder keine Ahnung, ob die Variablen sind falsch benannt oder du hast hier Tabs anstatt Spaces verwendet, whatever. Und dann geht es halt eben wieder zurück. André Neubauer: Hm. Ingo: Und das ist sozusagen so grob das sorry, das ist grob so das das Prinzip. André Neubauer: Was ich mich gefragt... Ja. Was ich mich gefragt habe, was für mich total einleuchtend ist, dass man etwas verrauschen kann, dass etwas rauschen kann und dass man quasi ja im Endeffekt ein LLM schlechter in der Antwort machen, also quasi schlechter in Antwort werden lassen kann. Die Frage, die ich mich gestellt habe, ist, geht das auch einen umgekehrten Weg? Also kann ich auch etwas, also kann ich halt Rauschen rausnehmen? Das ist jetzt gerade, glaube ich, der Part, den du als Receiver bezeichnet hast, wo eine gewisse Fehlerkorrektur drin ist. Ingo: Ja, also der Receiver ist, genau, also der Receiver ist wirklich zum Korrigieren da. 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 zum Beispiel. Also wir haben ja jetzt nur über so diesen, den inneren Loop, also einfach passt die Formatierung, kann das kompilieren, das ist quasi so das erste. Und dann gibt es ja noch größere Loops, laufen die Tests, laufen End-to-End-Tests. noch größer, kann man eine Welt-Simulation quasi dagegen laufen lassen. Also man kann das ja, man kann das ja weiter spinnen. Und das ist sozusagen der Receiver-Teil, aber das jetzt ist einfach spezifischer zu machen und einen genaueren Output zu bekommen. Das ist halt eben auch von den Studenten, was ich trainiere. Also wir geben halt ganz, ganz, wir fangen ganz, ganz ambivalent an mit unserem Prompting. Zum Beispiel wir wir sagen, Hey, generier uns mal einen Web-Server. Wenn du das halt fünf Mal laufen lässt, dann kriegst du quasi fünf unterschiedliche Web-Server. Also jetzt einfach nur das LLM zum LLM sagen, gib mir den Web-Server und man nimmt den Web-Server, rauskommt und macht das. Wie können wir jetzt besser werden da drin, was wir wollen? Also wenn wir überlegen, wollen wir lieber einen Wetter-Web-Server haben oder einer, der uns, keine Ahnung, die eBay Angebote rausgibt? Und jetzt fangen wir an in unserem Gehörn, ja, das ist jetzt extrem einfach, aber jetzt fangen wir an, in unserem Gehörn Klarheit zu schaffen. Wir fangen an, das zu sortieren. Und das geht halt runter, bis auf, wollen wir Camel Case oder wollen wir Snake Case haben. Das nimmt uns oft schon die Bohemian Sprache ab oder das Umfeld, die einfach sagen, okay, unsere coding guidelines geben das vor. Aber irgendwann muss man diese Entscheidung treffen, diese Klarheit schaffen. 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. Bei JavaScript muss ich es erst schaffen. Muss ich es erst erreichen später. Ja, und zurück auf den Webserver. Die Aufgabe ist es quasi, frage quasi, das LLM in den Webserver zu erreichen. Dann haben wir uns irgendwann darauf geeinigt, dass es ein Wetter-Webserver ist. Und dann laufen die Studenten alleine und haben quasi eine halbe Stunde Zeit, Eingaben in das LLM zu machen, also zweimal die gleiche Eingabe zu machen, und es muss exakt das gleiche Ergebnis bei rauskommen. 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, wenn wir dann nur noch zweimal daneben liegen, dann hast du ja die Spitzifikation quasi auf die Spitze getrieben. Das ist ja das Maximum, was du erreichen kannst. Das heißt, du hast die Klarheit im Signal, was du reingibst, sozusagen der Inputkanal von dir als Mensch, 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 so, ja, jetzt irgendwie, keine Ahnung, also dass man irgendwie eine DIN A4-Seite schreibt, ⁓ so einen Webserver rauszubekommen. viel ist es gar nicht. Das sind meistens so vier, fünf Zeilen. André Neubauer: Hm. Ingo: dann ist man schon relativ klar. Und in der Realität sagst du halt eben auch ganz oft so, ist mir egal. Also das ist ja auch eine Entscheidung, am Ende zu sagen, nimm halt den Web-Server, du oder den die Wetter-API, die du für am besten hältst, ist mir jetzt an der Stelle einfach egal als Entwickler. Oder ich sag halt, nee, ⁓ Gottes Willen, das kann mir doch nicht egal sein, das ist ja wichtig, vielleicht gibt es welche, die haben Kosten dran, dann habe ich ein Rate-Limiting, Für ein Prototyp egal, für Wer dann produktiv wird, wird auf einmal wichtig. hoffe, dass das ein bisschen Sinn. ⁓ André Neubauer: Ja, ich versuch das noch. Ich versuch grad das so in real world Szenarien. Also du hast es ja schon mit dem Webserver beschrieben. Also quasi quasi praktisch, also einfache Reuse Cases. Versuch das gerade dahingehend nochmal für mich so zu übersetzen. Aber Sebastian, du hattest. Sebastian: Am Ende, also Schlussfolgerung ist ja die Spezifikation bringt ja die Klarheit hier an der Stelle. Also sprich, du mehr, sorry, nicht unendlich mehr, gibt unendlich mehr Genauigkeit oder Präzision. Aber diese vier bis fünf Zeilen, die geben ja hier offenbar die Klarheit. Was auch immer diese, kannst du ein bisschen beschreiben, was da genau diese vier bis fünf Zeilen oder was die ungefähr enthalten? Ingo: Ja, was meistens eins der ersten Sachen ist, wie gesagt, es gibt unterschiedliche SDKs, die du nutzen kannst und da gibt es halt 10 oder so, die ganz gut im Latentsraum vertreten sind und die dann halt eben immer wieder auftauchen. Und dann gibt es aber auch so was wie Kommentare. Will ich überhaupt Kommentare haben? Wenn ja, wie sollen die aussehen? Die sind natürlich kunterbunt gemixt. ist es Proamiersprache. Das ist ja schon das erste. Wahrscheinlich kriegst du Python raus. Also Wahrscheinlichkeit, Python zu bekommen für eine Wetter-Abi, das kann ich jetzt. Da habe ich eine relativ gute Sampling-Größe mittlerweile. Also die ist hoch. Aber vielleicht wird es hier nicht Python. Also es trotzdem nicht gesagt oder mit Sicherheit, dass du Python rausbekommst. Dann die Benamung der Variablen. Das ist halt auch kunterbunt. Dann wie Baust, also gibt es eine Main-Funktion quasi, die irgendwie eine Unterfunktion aufruft, so dass das alles in einer großen Funktion. Und wir sind natürlich jetzt sehr, sehr kleinteilig. Wahrscheinlich für die meisten werden genau so eine Entscheidung, die trifft man halt einmal, schreibt sie sich in seine Coding-Guidelines rein und überprüft dann halt eben den Code darauf, dass das eingehalten wird. dann ist es okay und oft spielt es auch eben auch gar keine Rolle. Es ist wirklich mehr zu zeigen, dass man das Denkmodell halt ein anderes ist als klassische rollenbasierte Skripte zu schreiben, also rollenbasiert zu arbeiten oder regelbasiert zu arbeiten und einfach sagen, wenn das, dann das. Das ist ja im Endeffekt, was wir im Poemieren oder zumindest einen großen Teil des Poemierens ausmachen. weg davon und ein bisschen mehr Freiheit zu geben, aber halt eben nicht zu viel Freiheit zu geben. Und das ist quasi die Aufgabe, ⁓ so dieses Fingerspitzengefühl dafür zu bekommen, wann ist das genug, wann ist vielleicht auch zu viel. André Neubauer: Hm. Hm. Hm. Ingo: Ja, und das macht immer riesig Spaß. Auf jeden Fall. ist eine ganz klasse Aufgabe. Und man kann das total auf die Spitze treiben. weiß, vor anderthalb Jahren oder so gab es eine Bewegung, hießen Prompt, Speck Prompt, nee, Prompt, ich weiß nicht. Also irgendwas auch mit Speck und mit Prompt. Und die waren, das waren halt, das war eine strukturierte Sprache. Es war so eine domain-spezifische Language. Domainspecific 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 Programmiersprache umwandeln. Und dadurch, dass es so spezifisch ist und so klar ist, kannst du das halt eben auch durch ein 8b-Modell locker generieren lassen. Auch eine Sprache, die nicht gut vertreten ist. Und du wirst was Vernünftiges rauskriegen. Nachmittlerweile bei Ionis hosten wir ja die eigenen Modelle und dadurch kann ich quasi immer beliebig 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 ist halt auch so was, halt eben das Rauschen erhöht. Es ist halt eben je, genau, je schwächer das Modell ist, desto schwieriger wird es im Fall auf Basis meiner Informationen, meinem Intent, den ich reingebe. zu generalisieren und zu sagen, okay, ja, das ist das größere Konzept, in dem das drinne besteht. Wenn ich eine ganz, ganz klare Zäudokurtspezifikation habe und die reingebe, ist es halt eben auch für ein kleines Modell sehr, klar, okay, das ist sozusagen die Spitze, erreicht werden soll. Und ein größeres Modell kann sich dann halt eben auch in generellere Aussagen halt eben einfacher reinhängen. Das ist auch meiner Meinung neben dem agentischen Loop halt eben der Hauptgründe, warum jetzt so vor ein paar Monaten nochmal agentisches Programmieren so durch die Decke gegangen ist, weil man auf einmal mit einer natürlichsprachlichen Aussage einfach fast immer zu einem vernünftigen Output gekommen ist. Und das war halt komplett anders als vor, keine Ahnung, einem Jahr. Da war es halt wirklich mehr, man musste auch manchmal ein bisschen Glück haben mit KI. Und das ist jetzt komplett weg. Also die Generalisierungsfähigkeit der LEMS ist Ist echt beeindruckend mittlerweile. Obwohl ich sagen muss, Stefan und ich, wir hatten telefoniert und 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? kann das gar nicht nachvollziehen. Stefan meinte, ich kann das auch nicht verstehen. Das ist gar nicht so viel anders von dem, was bis jetzt da war. Weil man hat immer diese inkrementellen Fortschritte, aber für jemanden Außenstehenden, der halt nicht ständig damit arbeitet. war das auf einmal ein ganz schöner Sprung. das müssen wir jetzt einfach so anerkennen, das ist jetzt einfach da. Sebastian: verstehe das so ein bisschen das das iterative wenn man sich stark damit befasst beschäftigt dann fühlt sich das eher iterative an Ingo: Aber dann merkst du halt, also diese Rauschreduzierung quasi, in den Modellen dann drin ist, dadurch, dass dein Gedankenansatz quasi besser in Code übersetzt werden kann. 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ßt Scheiße, mit halt eben noch nicht so tollen Modellen. Ja, aber das ist cool, also beeindruckend was. Sebastian: Hm. Ingo: was geht. Sebastian: Das hört man ja auch immer wieder, dadurch der Vorsprung noch relativ gering ist. Weil alles was man sich in einem alten Modell an Hilfsmitteln drum herum aufbaut, damit das Ergebnis besser wird. in nächsten oder übernächsten Modellvariante schon nicht mehr nötig sein wird und dann kannst du es einfach one-shotten sozusagen. Genau, also die Entwicklung ist einfach weiterhin wahnsinnig beeindruckend. Genau, vielleicht nochmal zum Eichhorst-Prinzip zurückzukommen. Je öfter wir es hier im Transkript erwähnen, vielleicht kommt es dann noch schneller in irgendeinen LLM-Retreiben. Das Beispiel, was du gebracht hast hier zum Web-Server, das ist ja schon sehr eng. Das ist ein sehr, sehr enger Loop bzw. auch mit dem Pseudo-Code ein sehr, sehr enger Loop. Lässt sich das gut abstrahieren oder bedeutet das im Prinzip, das ist eigentlich quasi der theoretische Hintergrund hinter Spectreven oder Beamert oder wie sie alle heißen. Ingo: Also ich glaube, ist einfach für mich selbst, es ist einfach nur ein Gedankenmodell, was mir gut hilft, meine Stellschrauben gut zu vororten in dem gesamten Prozess. 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, gleich wenn ich ein kleineres Modell habe. Also es hilft mir einfach gut, schnell darüber nachzudenken. André Neubauer: Hm. Ingo: Warum folgt B aus A? Dafür ist es einfach ein gutes Werkzeug, glaube ich. Und das fand halt Reif auch. Deshalb hat er ja das mit übernommen. ... Ja, ich weiß gar nicht, was soll ich noch dazu sagen. Dafür ist es gedacht. Ich denke, das funktioniert genauso für alles andere auch. Der agentische Loop ist damit eingebaut. glaube auch nicht, ganz ehrlich, das erklärt ja quasi ... ein LLM von 2017 genauso wie ein LLM von heute und die Funktionsweise von heute. ich fällt mich schwierig jetzt irgendwie da 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 andere Aspekte anwenden kann. André Neubauer: Es wird, glaube ich, auch allgemein, es hat eine gewisse Allgemeingültigkeit. Es wird auch mit besseren LLMs, also quasi die, Rauschen, zwangsläufig reduzieren. Ich glaube, das ist natürlich auch bloß bis zu gewissen Grenze halt irgendwie möglich. Also gerade was so Kontextinformationen angeht, das kannst du ja nicht raten. ein gewisses Potenzial zu malozinieren wird es halt immer geben. Aber das, was du beschreibst, wird nie Schaden, würde ich sagen. tendenziell, könnte man es auch als Best Practice bezeichnen. Ingo: Genau. Und was Shannon halt auch sagt, ist, du hast halt einen gewissen Informationsgehalt in Informationen. Also er hat eben Informationen neu gedacht. Anders als quasi davor darüber nachgedacht wurde. Wo Informationen eher so als physisch versucht wurden, als quasi als Wellenlängen zu denken. Und er hat halt eben Informationen eher verstanden als Entropie, also als Unterschied zu dem, da ist. Das heißt, du, sei Beispiel mal, wenn du eine Münze wirfst, dann hast du eine 50-50 Entropie. Oder eine 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 keine Nullinformationen, weil du wirst dir immer Kopf haben. Und das finde ich auch eine starke Referenz. Wenn wir einfach nur was wissen wollen, dann ist vielleicht ein LLM gut, um uns zu sagen, wo ist das? Weil wir aus diesem Gesamtwissen heraus samplen, wir wissen nicht, wo was ist. Das ist die Information, die uns fehlt und wir wollen diese Information haben. Wir samplen die aus dem LLM, wenn sie dort vorhanden ist. Oder das LLM durchsucht das Internet für uns. Das ist eine andere Art, das zu finden. Wenn wir das aber quasi abgespeichert haben. wie... Bei mir ist noch Prometheus... André Neubauer: Hm. Ingo: aus der zehnten Klasse ist da noch komplett reingebrannt. Wenn ich jetzt das Gedicht kriegen würde und lesen würde, hätte das null Informationsgehalt für mich. Weil das ist ja schon da drinnen. Jetzt will ich das nochmal lesen. Das war sozusagen sein Ansatz, Informationen zu betrachten. Und wenn wir das so sehen, dann ist natürlich nur das für uns wichtig, was im LLM kreativ in Anführungsstrichen, aber neu gesampelt wird aus unserer Perspektive. Und das finde ich so ein spannender auch. Ansatz und der zeigt halt eben auch, dass LLM ist halt kein Buch und sollten wir auch dafür nicht nehmen, sondern es ist eine neue Kombination, die halt genau dann sinnvoll ist, wenn sie nicht zu krass entrupisch ist, also Kauderwelsch. Wenn man die Temperatur auf zwei stellt bei LLMs, dann kriegt man komplett einen Kauderwelsch raus und dann wird beliebig gesampled aus allen Tokens, die verfügbar sind. Also das ist dann gibberish. hat zwar viele Informationen jetzt nach Schenden's Theorie, aber es bringt uns natürlich nichts, es ist nicht hilfreich. Und bei einer Justierung von so einem LLM, von einem KI-System geht es halt immer darum, irgendwie so einen Sweet Spot zu finden. Genug Entropie, dass es sinnvoll und hilfreich ist, ansonsten kann ich halt auch ein Gesetzestext nehmen und der ist halt so gegeben, dann brauch ich kein LLM oder kein KI-Modell. Und das muss aber trotzdem halt eben nicht zu krass. entropisch sein, weil dann kann ich nicht mehr anwenden. Dann hat es keinen Sinn mehr in der realen Welt. Sebastian: Ja, absolut. Genau. Das finde ich ist auch nochmal als Erklärungsansatz oder als Kontext für das Modell auch ganz hilfreich, das genauso zu betrachten, dass die Information oder die relevante Information ja genau darin besteht, dass es eben nicht hundertprozentig deterministisch ist, dass da eben was Neues entsteht, was noch nicht da ist. Ingo: Und das, 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, Architekturerrosion durch KI-Agenten. Das ist nachweisbar statistisch, ich auch hier. Ihr es ja vorhin kurz angesprochen, ich hatte so einen kleinen Artikel geschrieben zu quasi Meta-Analyse, habe ich es genannt, zu allen möglichen Produktivitätsanalysen. Wie viel produktiver macht mich eigentlich KI? Den gibt es bei Medium. Wir sind eigentlich noch gar nicht so weit, aber wir hängen natürlich wissenschaftlich auch immer bisschen hinterher, weil es eine Weile dauert, bis die Studien ausgewertet sind. Und da haben eben auch in den Studien viele berichtet, dass die Architekturqualität, die Qualität der Software einfach deutlich schlechter geworden ist. André Neubauer: Mh. Ingo: Das lässt sich halt statistisch auch nachweisen, aber ich glaube, wir haben das noch nicht verstanden, dass das einfach so eine äußere Schicht drum herum ist, die man einfach noch wieder, so dieser Review-Schicht, entspricht die neue Architektur, entspricht die quasi dem, was wir für sinnvoll halten, als eine gute Architektur, dass die Module halt eben schön tief sind, dünnes Interface haben, aber tief sind in ihrer Implementierung und einfach austauschbar werden dadurch. So was zum Beispiel. Das beachtet ja ein LLM nicht out of the box, aber das ist sozusagen eins unserer Review-Zyklen, die dann halt als Feedback mit reingehen und dem LLM dann sagen, okay, hier gucken wir nochmal nachbessern, das wollen wir doch lieber ein bisschen anders haben. Und da haben wir jetzt klassisch hier von Corolla Lilienthal zum Beispiel Langley wie Software-Architekturen, den, jetzt muss ich kurz nachgucken, Modularity Maturity Index oder Neil Ford schreibt gerade auch an einem Buch, Architecture as Code, wo genau so eine Sache festgehalten sind, die einfach dafür sorgen, dass der Code stabil bleibt. Das war bei Menschen halt schon so. Aber Menschen produzieren halt eben begrenzt Code. Die besten Entwickler erzeugen auf wie minus zehn Lines of Cones am Tag. Aber ich denke, so viel mehr als 200 Zeilen ist wahrscheinlich nicht drin. Und bei LLMs ist das natürlich ein Witz und dadurch geht das natürlich mit der Erosion, mit den Tech-Dabs viel, viel schneller. Und deshalb müssen wir dagegen arbeiten. Das ist dann der nächste Loop. Und dann können wir da noch wieder ein Loop drüber schlüpeln 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 Slash-Inspect-Kommando. Da kann man sich so einen Reporter stellen über das, wie man sich so mit dem ... 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 Öllicht auch viel gemacht. Habe mir angeguckt, okay, die Transkripte der Agenten. Und dann sieht man ja, wo ist der Agent gegen eine Mauer gelaufen und musste irgendwie eine andere Entscheidung treffen. Bei PIE sieht man das sehr schön. Da wird nämlich dann der Hintergrund rot. Das finde ich so, also in der Standardkonfiguration. Das finde ich super, weil Das zeigt dir halt eben, ist irgendwie, hat das LLM gerade eine Fehlannahme getroffen, ⁓ das Ziel zu erreichen. Warum hat es die Fehlannahme getroffen? also bei mir war das eigentlich irgendwie meistens relativ schnell fixbar. Aber ich hab halt von Leuten gehört, da hat ein LLM zehn Minuten was Falsches gemacht. hat einfach in die falsche Richtung gelaufen, weil irgendwo in der Doku noch eine alte Information drin war. Und so eine Sache sollte man natürlich dann aufschw- 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 bisschen in die Richtung Dark Factories oder Self-Improving Factories. Da wir noch super am Anfang, aber extrem spannendes Feld. Sebastian: Genau, habe deinen Artikel auch vorhin noch gelesen, ja schon kurz drüber gesprochen im Vorgespräch und fand den total spannend und höre jetzt bei dir raus, dass du das durchaus, ja, sagen wir mal, wahrscheinlich ein bisschen positiver betrachtest als, ich habe Folge Armin Roenacher auch, der gerade mit seiner Firma Arandeale, der Pi sogar gekauft hat, aber auch an einem Produkt arbeitet, wo sie sagen, die haben sich jetzt mit den Coding Agents in so eine Sackgasse. gekodet und der also der ist wirklich erfahren also der ist glaube ich vorher ein guter macht das mit den Agents seit er sagt immer seit April 20 25 glaube ich das heißt also ist auch schon lange dabei gewesen und das für ihn dann so auch explodiert als dann Cloud Code raus kam und es immer besser wurde aber auch der sagt also da fehlt noch was und und Also Beispiel von ihm ist immer, was ich persönlich auch in meiner Arbeit sehe oder in meinen Projekten, 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 zum Beispiel ein User Kontext nicht vorhanden ist, dass man da nicht einen Fehler wirft, sondern dass man dann sagt irgendwie Er nennt mich halt als Fallback ein Default User. Was dir in so einem Kontext, in dem 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 ID's hatte und dann gab es aber ein Fallback, wo wenn die ID nicht gefunden wurde, dann der über Namen versucht aufzulösen und wenn der Name nicht gefunden, dann auch so ein Default Fallback, was aber oft gar nicht das Richtige war. Lange Rede, kurzer Sinn. Also, wie du schon gesagt hast, in der Community oder in der Szene hört man gerade so 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 Analyse der Studien sozusagen durchaus ein bisschen positiver. Hör ich das richtig raus? Ingo: Ja, das ist total lustig, es gar nicht... Eigentlich kommt die Studie... Also kommt eigentlich Programmieren mit KI gar nicht so gut weg bis jetzt. Und ich habe aber halt eben so einen Cut-Off bei den Studien. Und der Cut-Off ist so bisschen... Also Anfang des Jahres. Ab da kam ich einfach... Bin ich im Blindflug. Und ich will sagen, das ist natürlich das, wo es gerade irgendwie so kämperisch explodiert ist mal wieder. Bis dahin ist es eigentlich gar nicht so... Es ist gar nicht so verrückt. eine Studie, die 300, irgendwas 350 Unternehmen oder Teams aus mehreren Unternehmen von der Stanford University untersucht hat. Die sind jetzt so bei im Schnitt in den Teams bei so plus 15, 10, 15 Prozent Produktivitätsgewinne. Das ist jetzt aber Daten, die schon irgendwie neun Monate alt sind. Und die besten Teams schaffen es dann vielleicht so eher so 30, 25, 30 und natürlich abhängig. hast du Greenfield, Brownfield-Projekte, wie komplex ist die Code-Basis. 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, mal zu sehen, was da in wissenschaftlichen Untersuchungen betrieben wurde im Hintergrund, was dabei rauskam, was man da sehen kann. Und es ist ja doch immer noch mal ein ganz interessantes in Zahlen zu sehen, als nur ein Bauchgefühl zu haben. Sebastian: Absolut, genau, die EVALS sind ja doch sehr individuell, kleine Samplingen, die man sonst so hat. Was da ja auch rauskam, das tatsächlich, was du eben schon angesprochen hast, ja Produktivitätsgewinn, gleichzeitig aber durchaus eine Verschlechterung der Qualität bei der Codequalität sozusagen. Ingo: Aber ich sehe das nicht wirklich. Das bringt mich immer so bisschen in schwierige Situationen. Ich bin schon eher so ein positiver Mensch. Ich versuche die Dinge eher optimistisch zu sehen und das auch so mit meinen Mitmenschen so zu teilen. Auf der anderen Seite haben wir natürlich hier einen extrem technologischen Umbruch. Und der wird halt nicht nur zu Gewinnern führen. Es wird auch Verlierer geben. Ich weiß, letztens bei einer Pendeldiskussion mit Corola Linienthal und sie meinte in ihrem Team, ist es so, sie hat halt Entwickler, die jetzt happy sind, weil sie jetzt auf einmal dieses frickelige Code-Krams, 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 bisschen wie so ein Archäologe irgendwie, so ganz cool. Ich mochte das. Aber es ist natürlich doch schon ein relativ langweiliger Prozess. Man hat natürlich irgendwie so ein 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, 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, mir am entwickeln Spaß gemacht hat. Und die haben natürlich jetzt, wie soll ich sagen, eine Arschkarte. Für die ist es natürlich jetzt auf einmal nicht mehr so schöne Welt wie vorher. Von daher versuche ich es eher so ein bisschen, schon für mich persönlich positiv zu betrachten. in dem Setting möchte ich schon offen sein, schon sagen, es da nur Gewinner gibt, nicht nur Leute, die da plus rausziehen. André Neubauer: Ich würde noch hinzufügen, wir sind halt immer noch super early on. 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 der Episode, besser zu verstehen, wie diese Systeme arbeiten, wie diese Systeme arbeiten, einen Griff dran zu bekommen und diese best practices abzuleiten, die wir halt, weiß ich nicht, 20 Jahren mit Onkel Bob und Clean Code uns halt irgendwie reingezogen haben, ⁓ halt einfach einen Griff an Software, an Design, an Architektur zu bekommen. Und genau das passiert jetzt halt einfach auf einer höheren Ebene. Bloß mit dem Unterschied, dass wir deutlich weiter am Anfang stehen. Ingo: Ja, total. Und auch, ich finde auch Test-driven-Development und Clean-Architecture, also Clean Code spielt ja in Programmieren mit KI rein. Das passt ja wie die Fost aufs Auge. Aber ob Clean-Architecture für uns in zwei, drei Jahren noch der richtige Ansatz ist, also hexagonale Architektur, Portz & Adapters, ... Wir werden sehen. Ich kann mir schon vorstellen, dass da irgendwie ganz verrückte andere Architekturen entstehen. Vielleicht auch dynamisch entstehen einfach darauf, weil wir sagen, das ist jetzt gerade. Das hat sich sozusagen, wenn man sich jetzt Gradient Descent, quasi die, so funktioniert ja das Training von KI Modellen, dass man versucht halt eben so ein ein lokales Minimum, im Optimalfall ein globales Minimum zu finden und sich immer weiter diesen Nullwert anzunähern. So wenig wie möglich Reibungspunkte zu haben in dem Output. das kann ich mir gut vorstellen, dass das für Architekturen auch funktioniert. Letztes Jahr habe ich das mal so bisschen angeteasert und habe mal einen Artikel geschrieben für Informatik aktuell, verstärkende Softwarearchitektur. Und geguckt, okay, wie könnten wir eigentlich dieses Gedankenmodell übernehmen auf Softwarearchitektur und es einfach mit objektivierbaren Parametern. In dem Fall war das halt für einen Partner das Thema Latenz. Also mit welcher Architektur kriegen wir die beste Latenz hin? Und dann habe ich das einfach durchlaufen lassen durch die Schleife. Heute würde man das Auto Research von Andrej Kapasi nennen. Damals habe ich das quasi im Kleinen für mich selber gebaut, ⁓ 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, naja nimmste Monolith oder nimmste Modulith oder nimmst du hexagonal, sondern dass man einfach auf einer höheren Abstraktionsebene auf einmal argumentiert und sagt, ja ich hab jetzt, was weiß ich, wie man es nennt, ich hab jetzt einen Domänen oder vielleicht einen webbasierten Ansatz gefahren und ich hab vielleicht eher so einen oder einen zentralen einen verteilten Ansatz gefahren oder sowas, also dass man gar nicht mehr so weit runtergeht und die Architektur sich quasi selber findet. André Neubauer: Endeffekt existiert das ja auch nur, wenn man irgendwie eine Notwendigkeit hat, diese halt weiter zu verändern oder zu warten und zu verstehen. Das ist ja der einzige Grund, warum diese Konzepte halt überhaupt entstanden sind. Bringt mich wieder zu, glaube ich, auch unserer ersten Folge, dass quasi das halt komplett verschwinden wird. Und ich glaube, müssen wir auch wieder da verstehen. Es geht so ein bisschen in das, was wir am Anfang halt irgendwie diskutiert haben über was über welche Art von Software reden wir hier? Ist das halt irgendwie Greenfield? Die Architektur, die kann heute schon anders aussehen. Ist das halt irgendwie Brownfield? quasi, dass die Architektur quasi zwangsläufig ist das halt in einem anderen State und kann sich gar nicht so schnell dahin entwickeln. Aber ich, ja, ja, ich glaube, es läuft halt alles da auch hinaus. Es ist halt wie immer, depends. Ingo: Ja, und ich bin auch davon überzeugt, dass es viele, viele neue Felder geben wird. Auch wenn jetzt das klassische Programmieren wahrscheinlich so bisschen zu einem Artefakt wird. Ich hatte das letztens in einem Jobinterview. hatten ein Jobinterview mit einem Kandidaten und die Aufgabe war halt in der Prolumiersprache der Wahl, ein genästetes Array zu, ich weiß gar nicht mehr, flach zu machen und zu sortieren oder so. Also so eine klassische Aufgabe, man die man halt in einem Interview stellt. ich fand das so spannend, also war quasi nur Co. in dem Interview. Ich war nicht der Hauptinterviewer und ich fand das so spannend und dachte dann so, okay, ich muss das jetzt machen. Und dann hat der 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 Ansätze gegeneinander verglichen. Einfach nur so ein Stringaustausch. Also man kann das ja unterschiedlich lösen. musste es ja nicht parsen 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. Ich habe das komplett vergessen, ich habe das komplett verdrängt. André Neubauer: Ich finde es spannend, dass ihr das in einem Interview fragt. genau, das führt wahrscheinlich jetzt gerade mit Blick auf die Uhr ein bisschen zu weit. Ich habe mir eine Frage so ein bisschen zum Abschluss, bevor wir quasi dann noch zum heißen Scheiß kommen, aufgeschrieben. Was quasi jetzt Hat das jemand die Episode bis hierher gehört? Was ist 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? Ingo: Also was ich halt sehe ist Personenstaaten an unterschiedlichen Orten. Ich hab das nie so krass gesehen wie jetzt. Also in der Schule muss man ja irgendwie die letzte Klasse abschließen. Man muss eine Satze Pythagoras kennen, bevor man halt mit Algebra anfängt. 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, wie funktioniert das eigentlich, wann kriege ich einen guten Output, wann nicht, und es vielleicht auch so bisschen an die Grenzen getrieben hat, 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äre mein erster Ratschlag, erstmal alle irgendwie versuchen, auf einen der Welt zu bringen und alle eine Brücke zu bauen, ⁓ da hoch zu gehen. Zumindest versuche ich das. Und das ist schwierig, weil wir halt Menschen sind. Und zweitens ist, wir sind gerade in einer Phase, wie ihr auch gesagt habt, wir sind sehr früh. Das heißt, gibt für vieles kein Patrintrezept. Und wenn mich Menschen mit lasigen Augen angucken und sagen, Ingo, 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 wahrscheinlich nicht die richtige Lösung. 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 letztes Jahr einen Vortrag bei den IT-Tagen zum Thema Benchmarking. So einfach zu gucken, den einen Ansatz gegen den anderen Ansatz zu vergleichen. LLMs sind halt probabilistisch. Das heißt, vielleicht macht man das fünfmal, damit man mehr Gewissheit hat, ob ein Ansatz funktioniert oder nicht, wie oft er nicht funktioniert. wie oft er funktioniert. Und damit, glaube ich, kommt man eine ganze schon sehr, weit. Also einfach messen, was funktioniert, was funktioniert nicht, und darüber über dieses Messen ein Verständnis aufbauen. Genau, das wäre so mein Take. Sebastian: dir ja andrej hat es gerade schon angeteasert wir haben am schluss noch so ein kleines recurring segment und da geht es immer ⁓ den heißen scheiß sozusagen also was ist für dich gerade so der absolute hype kram Ingo: Ich habe eben schon angesprochen, Thema Dark Factories und Harness Engineering. Das ist schon das, was mich gerade sehr begeistert. Da steckt eine Menge drin, zumal es halt eben doch so bisschen weiter denken ist von dem Shannon Principle, was ich mir quasi ausgeborgt habe. Also das ist quasi von der Theorie her und vom kognitiven Ansatz für mich total spannend. aber eben auch von den Möglichkeiten, die daraus entstehen. Und das, was ich bei Öhrlicht gerade mache, also du kannst da, wir hatten es ja vorhin kurz angesprochen, es gibt fünf Agenten, glaube ich, die ich jetzt unterstütze. Und da gibt es 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, die sich über Nacht automatisch integrieren. Und das ist quasi jetzt mein Ansatz. Also quasi ich möchte den Harnes, das Drumherum so stabil machen, dass so klar ist, wann das richtig ist und wann es falsch ist, dass einfach so ein neuer Agent über einen einfachen Skill und halt eben diese diese Guardrails 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 der ist nicht mal ein richtiger Agent, aber mein erstes System war Ada und es ist komplett gescheiße. Es haben drei von fünf Use Cases funktioniert am Ende. Also ich bin da auch noch am Anfang. Aber ich sehe da halt super viel Potenzial. Sebastian: Ich wollte gerade schon sagen, wenn du das geschafft hast, das konsistent für alle möglichen Agenten zu machen, dann kommst du nochmal hier in den Podcast und erzählst uns, wie du das gemacht hast. Weil tatsächlich Dark Factories 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 ⁓ ist. Aber ich bin da insofern, ich habe da noch so einen logischen Ingo: Gena, Gena. Sebastian: Also sagen wir mal logischen Knackpunkt darin gehend, dass wir ja also gelernt haben, Wasserfall ist halt nicht gut, weil du ja erst während des Projektes herausfindest, was du was du so war, wie das die Lösung aussehen muss, die du brauchst. Und am Ende ist es ja eigentlich dann nur runtergebrochen. Wie groß ist der Loop, auf dem du unterwegs bist? Und dann bedeutet Dark Factory wenn man es zusammendampft, eigentlich, dass man einmal am Tag wahrscheinlich nochmal 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 Integration machst, wie StrongDM oder wie die hießen, die hatten halt, relativ klar genau diese Entropie rausnehmen und diesen Loop insofern automatisieren und dem Agenten oder des Harnes so aufbauen, dass der Agent eben überprüfen konnte. ob der Output korrekt ist oder nicht. Auch wenn du es nicht hast, wo du halt ein Interface für Humans baust oder so, da musst du dich dann schon selber noch damit beschäftigen, ⁓ dann den nächsten Schritt zu definieren wahrscheinlich. Sorry, jetzt bin ich doch wieder tiefer reingegangen ins Thema, als ich eigentlich wollte. Ingo: Genau, sorry. Aber noch ganz kurz meine Hypothese, 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 den geht es nicht. Wenn du erst noch herausfinden musst, was du eigentlich willst, dann geht es nicht anders. Dann musst du halt im Loop mit drin herumschwimmen. Wenn du aber weißt, was das Ziel ist, und halt wie bei den Agenten, die anzubinden, das weiß ich. Ich weiß, welche State-Übergänge es gibt in meiner Lösung. da gibt es halt Fälle. Und jetzt versuche ich, die Umgebung zu simulieren. quasi, schaffe mir ... Andre Capasi hat mal gesagt, LLMs sind People Spirits. sind kleine Geisterchen von Menschen, die quasi noch so über sind. Das sind keine richtigen Menschen. Man könnte sagen, so eine Art wie die Seele 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 samplen. Da gibt es Studien zu, die es geschafft haben, die Personalität eines Menschen zu 85 Prozent über das LLM abzubilden. Also gab es so einen Persönlichkeitstest. Und dann hat man das LLM gefragt und das hat 85 Prozent 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 Wochen später nochmal in das gleiche Labor gebeten und dann haben sie die gleichen Fragen gekriegt und... Guess what? war dann auch so 85 Prozent Übereinstimmung mit den Antworten vor. Also LLM sind quasi genauso ich, wie ich in zwei Wochen ich bin. Und jetzt muss man das richtig samplen aus dem LLM. 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 einen State Transfer bei mir in meiner ÖLICHT-Anwendung, wo dann halt eben gesagt wird, okay, jetzt wartet der halt eben auf dich, Agent, jetzt musst du was antworten. Und dann kann der Agent, es baut, der guckt dann halt eben ins Protokoll, okay, ist das sinnvoll überhaupt gerade? Also ergibt es Sinn? Und der LLM-Kunde, der sich das quasi anguckt, der muss dann auch sagen, okay, ergibt das Sinn? Für mich passt das gerade. Und so habe ich halt mehrere Quellen und versuche so bisschen, Lösung zu triangulieren aus den unterschiedlichen Sampling-Quellen vom LLM. Und ja. Das ist eine schwierige Aufgabe, weil Null vertreten in den Gewichten vom LLM. In einem halben Jahr ist es auf einmal einfach, aber jetzt ist es halt noch schwer. Und das finde ich interessant gerade. ⁓ Sebastian: absolut ja und genau zum heißen scheiß fragen auch immer nach was momenten hast du auch hin und wieder was momenten noch oder sagst du eigentlich durch deine eichhaus principle bist du so im moon dagegen dass du alles gut umschiffen kannst Ingo: Ja, also ich muss sagen, für mich selber, mir fällt es immer ein bisschen schwierig. Also ich habe bestimmt ganz viele What the fuck Momente und ich, aber für mich ist das so normal, das ist halt so, wie wenn du mit Menschen redest, dann weiß ich auch nicht. Ich würde es ja auch nicht jedes Mal flaggen, wenn dich irgendwer nicht richtig verstanden hat, wenn du mit ihm redest. Und ich hatte aber was, das hatte ich mir gerade aufgeschrieben, gucken, was das war. Ich hatte nämlich am Wochenende mit meinem Startup aus den USA telefoniert und die hatten nämlich ein Problem. Ach genau, 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 fertiggestellt sein. Und da ging es ⁓ Multitenancy in dem System und Multitenancy, ich weiß nicht, wenn ihr das mal gemacht habt, irgendwie in die Richtung, das ist schon ein bisschen Aufwand, ne? Da musst du schon ein bisschen an der Datenbank rumkratzen, das muss dann den Authentifizierung, Autorisierungsflow ein bisschen ändern. So hast du schon ein bisschen was mit zu tun und da hat das KI-Modell gesagt, naja, also ganz ehrlich, wenn du das morgen haben musst, André Neubauer: Hm. Ingo: dann bau doch da eine Umgebungsfeierablerei rein. Und dann hat er dann die E-Mail-Adressen mit dem dazu gemapten Tenant als Umgebungsfeierablerei geschrieben. Das war so der Ansatz. Und dann hab ich mir das angeguckt und hab gedacht, ⁓ Gottes Willen, warum? Und dann hab ich dann das nachverfolgt und dann hab ich gesehen, eigentlich ein Trigger dafür, ⁓ diese Entscheidung zu treffen, war halt, dass das LLM gesagt hat, ja, es muss ja schnell gehen. Und aber schnell ist halt anders jetzt auf einmal. Jetzt gibt's keinen langsam mehr. Also es gibt nur noch schnell. Also warum sollte ich noch irgendwas, ne, hacky bauen? André Neubauer: Ja, weil das LLM hat halt gelernt, schnell gleich schlecht. Es gibt ja dieses, quasi dieses berühmte Bild, das gibt halt irgendwie schnell, günstig und gut. Und du kannst zwei, zwei kannst du halt irgendwie auswählen. Das ist halt an der Stelle quasi schnell und günstig, wird halt nicht gut. Warum auch immer günstig. Vielleicht war, klar, sie ist der Start-up bei dir auf keinem, auf keiner Max-Subscription von Claude. Spaß beiseite. Ingo: Doch, sind die auch. Nein, nein, das sind so Kleinigkeiten, wo man sich denkt, krass, wie sich so eine Kleinigkeit auswirkt am Ende. ja. Ja, Die sind ganz toll und die machen ganz, ganz klasse Arbeit. Sonst wäre ich da nicht mitinvaviert. Der will das gar nicht. Die machen auch ... Sonst war alles ganz toll, wirklich nur in dem Moment ein Beispiel, was mir aufgefallen ist, wo ich gedacht habe, André Neubauer: Absolut, absolut. Ich hab auch nur Spaß gemacht, aber es ist... am Ende... Zero und ich wollte es auch nicht. Ingo: Ach guck, ist ja nett. André Neubauer: Fairerweise wäre aber da spannend, zu verstehen, warum solche Sachen das triggern. Das wäre zumindest meine Folge fragbar. Eine richtig logische, eine gute Erklärung hätte ich dafür nicht. Ingo: Ja, das LLM hat halt eben eine Vorstellung von Zeit, die basiert nur auf von vor zwei Jahren oder vor einem Jahr. Und also auf den Trainingsdaten halt. Und den Trainingsdaten ist halt, ja, dauern die Dinge halt länger. Und wenn es schnell gehen muss, dann ist halt laut Trainingsdaten, machst halt Hackey. 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 challangen können, dieses... dieses Dreigestören von ob es jetzt gut oder schnell oder günstig ist. Also ich glaube, das gibt es immer noch, aber es verschiebt sich jetzt gerade in eine Richtung, wo wir als Ingenieure gut erstmal an der Qualitätsschraube lange drehen können und es sich doch noch nicht wirklich langsam anfühlt. In zwei, drei Jahren fühlt es sich dann langsam an, wenn man an der Qualitätsschraube viel dreht. Sebastian: Ja, Dank. war eine sehr interessante Folge. André Neubauer: Danke schön. Sebastian: willkommen zu einer neuen Folge unserer Staffel von Abendzeit E. Beyond Vibe Coding. Der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten. Ich bin Sebastian Heidemeyer zu erbem CTO bei NorthIO. André Neubauer: und ich bin André Neubauer CDPO bei Trusted Shops. Schön, dass ihr wieder da seid. Heute geht es ums Rauschen und auch ein bisschen darüber hinaus. Wir haben mal wieder eine bisschen technischere Folge und zwar werfen wir einen Blick darauf, wie LLMs funktionieren und wie man bessere Ergebnisse erzielt. Sebastian: 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. Freut euch drauf und jetzt viel Spaß beim Hören.