# AI-Driven Software Engineering: Strategy, Stacks, and Harness Frameworks

**Podcast:** HMZE
**Published:** 2026-05-07

## Transcript

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.
Herzlich willkommen zu einer neuen Folge unserer neuen Staffel von AMZE Beyond Vibe Coding.
Der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin Sebastian Heidemeier zu Erben, CTO bei North.io.
Und ich bin André Neubauer, CDPO bei Trusted Shops.
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.
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.
Freu dich drauf und jetzt viel Spaß beim Hören.
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, unseren Hörern einmal kurz vor.
Mega.
Ja, Ralf ist klasse.
Mit Ralf macht es großen Spaß, die Welt der KI zu erkunden, aber natürlich auch mit all meinen anderen Projekten, die ich so am Laufen habe.
Und meine Historie ist, ich habe schon als Teenie quasi angefangen, wahrscheinlich schon bevor ich Teenie war, mit meinem ersten C64.
Mein Vater hat mich da so ein bisschen rangeführt, hat gesagt, das ist eine coole Idee, mach das.
Und ja, und darauf dann.
Kleine Programme geschrieben, irgendwie so in die IT-Welt reingekommen, dann ein bisschen abgedriftet.
Im Uni habe ich BWL studiert und bin dann erst später dann in einem anderen Studiengang dann wieder an die Informatik herangeführt worden.
Das heißt, ich habe auch am Anfang als Projektmanager gearbeitet und bin dann später wieder in die Basis zurückgegangen.
Eigentlich ist entwickeln, programmieren, da PHP gemacht, JavaScript, auch C, Kunterbund, alles Mögliche.
Auch DevOps mal eine ganze Weile.
Und 2019 habe ich bei uns in der Firma damals die CTO-Rolle übernommen.
Wir haben so Online-Streaming-Angebote gehabt.
Damals hauptsächlich sind wir so ein bisschen weggegangen von klassischem Livestreaming und klassischem Video-on-Demand hin zu mehr Advertisement.
und dynamische Werbeinsertierung.
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 im ersten Jahr Bankenbereich und Stiftung.
Das war super spannend und 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.
Hinter mir sieht man noch die Bilder, die so mit einer ganz frühen Mid-Journey-Version entstanden sind.
Es ist ja alles noch nicht lange her, aber es kommt halt schon echt vor wie eine Ewigkeit.
Und ja, da war ich extrem begeistert und das hat mich gecatcht.
gab es dann noch eine Möglichkeit, da 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-Projekte aufzubauen, auch für eine Beratungsfirma.
Und ja, das habe ich dann genommen.
Das war meine Chance.
Und genau, das habe ich ein Jahr lang gemacht.
Dann irgendwann ist denen aufgefallen, das ist kein Geld, das ist eine japanische Firma.
Und die haben irgendwann...
ist ihnen aufgefallen, dass das Geld ausgegangen ist oder in 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 ja erst irgendwie im Jahr am Berkeln waren, ihr 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 damals, das war so 20, da war die Frage, Welche Richtung soll es gehen?
Da habe ich 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.
im Frühling einen Vortrag über KI-Agenten, der eigentlich relativ nah an dem ist, was wir heute als KI-Agenten verstehen, weil damals hat halt noch niemand drüber geredet.
Und dann war die Überlegung, okay, ein Safeplay ist Infrastruktur auf jeden Fall, weil wenn jeder programmieren kann, dann was brauchen die?
Die merken dann irgendwann auf Localhost, es 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 über was sprechen heute.
Ich bin aber nebenbei noch so beratender CTO bei einem Startup in den Staaten.
Das macht auch großen Spaß und berate und mache so nebenbei so kleine 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 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.
Ja, cool.
Bevor wir da reinspringen, ich muss trotzdem die Chance nutzen.
Was macht ein Engineering Trainer Day to Day?
Wie muss ich mir das vorstellen?
Ja, ich glaube, das ist schon eine wenig verbreitete Rolle.
Absolut, deswegen frage ich.
Vielleicht lernen wir was.
Ja, ja, mir war das, also ich wusste das vor quasi zwei Jahren, hatte ich davon auch keine Ahnung, dass es das überhaupt gibt.
Damals dachte ich so, um sich neues Wissen anzueignen, guckt man halt YouTube-Videos.
Das ist halt schwierig bei größeren Firmen, wo halt...
viel auch Know-how in den einzelnen Bereichen sitzt und man quasi Silo-Bildung 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, die vielleicht schon was entworfen, vielleicht schon was gebaut haben, dass diese Lösungen halt eben auch durch andere Teams genutzt werden können.
Und genau, also 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.
Und dieses Jahr habe ich viele Workshops gemacht zum Thema agentisches Programmieren, Programmieren mit KI-Agenten, jetzt auch mehr und mehr Harness Engineering.
Ja, und das geht von den Basics bis, wie gesagt, zu dem, was gerade so Dark Factory, was gerade so 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.
Verstehe ich.
Spannend.
Gibt es einen Trainer oder wie viele Trainer gibt es?
Ja, also ich bin quasi der Engineering-Trainer.
Ich bin auch, also Jonas ist ja groß, könnt ihr euch vorstellen, Also wir haben ja extrem viele Brands, die dazugehören aus unterschiedlichen Ländern.
Und ich bin jetzt im Cloud-Bereich verortet, aber versuche auch da natürlich immer mal ein bisschen links und rechts zu schauen.
Aber das ist so mein Home-Turf.
Okay.
Genau.
Cool.
Spannend.
Dank dir.
Total.
Ich hätte jetzt irgendwie fünf Folgefragen, die würden aber, glaube ich, unseren Rahmen hier ein bisschen sprengen.
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 Tech-Stack.
Du hast ja auch gesagt, du bist auch in Engineering-Projekte involviert, hast Open-Source-Projekte.
Das heißt, dein Tech-Stack ist tatsächlich auch oder Tool-Stack ist tatsächlich auch ein Coding- oder Engineering-relatierter Tool-Stack.
Genau.
Was nutzt du?
Wie arbeitest du?
Welche Skills?
Was auch immer.
Ja, ja.
Also ich hatte ja schon kurz angesprochen, 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 Oerlicht.
Und 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.
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 wegfischen auf dem MacBook, um 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.
Und finde ich, dass du auch Pi unterstützt.
Gut finde ich, dass du auch den Pi-Agent unterstützt.
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.
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 OpenCode, also auch ein ganz klasse Agent.
Genau, und dann kommen da noch Agentenorchestrierungen mit rein, also jetzt Guest Town zum Beispiel oder Cloud 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 TechStack her hauptsächlich entwickelt mit Cloud Code, ein bisschen Codex, ein bisschen Pi.
für unterschiedliche Anwendungszwecke.
Und von der Poemiersprache habe ich ein Backend-Golang.
Das habe ich einfach herausgefunden, das gefällt mir am besten, Coding-Agenten, 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 im Frontend nehme ich whatever.
meistens sind das eher Synth-Lines 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.
Das Thema rund um Golang, das hatten wir auch schon mal, glaube ich, hat Stefan tatsächlich mitgebracht, wahrscheinlich sogar mit in der ersten Folge.
Hast du da irgendwie so empirische Daten?
Also hast du dir Erfahrung gesammelt, dass...
Wie bist du darauf gekommen?
Lass mich es offen fragen.
Wie bist du darauf gekommen, dass Golang quasi für dich da der beste Pick ist?
Ja, gute Frage.
Also 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 eh besser in Golang werden wollte.
Und es gibt auch Untersuchungen zu dem Thema, Studien zu dem Thema, welche Programmiersprache ist am besten geeignet.
Und da schneidet in der Regel Go nicht als beste Programmiersprache ab, weil einfach 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, die gucken sich OneShop.
Short Generation an.
Also quasi das Klassische quasi, ich schreibe was in mein Chatbot rein und sage, 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.
Da sind wir ja nicht mehr in dem Stand des Wissens, sondern wir sind ja schon einen Schritt weiter.
Und dadurch, dass wir jetzt agentisch arbeiten und quasi in dem Loop der Agent sein 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 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 das gut ist, was der Agent produziert hat oder nicht.
Und das ist halt bei JavaScript komplett anders.
Ich liebe 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.
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 Codebasis und musst das halt eben rückwirkend unterbinden.
Und Go kommt schon mit diesen ganzen Boardmitteln.
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.
Und es ist 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 nochmal einen 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, 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 Örlicht, ja, das ist ja so eine Menübar-App.
Das ist alles SwiftUI.
Also alles, ne?
Das ist jetzt nicht viel.
Das sind vielleicht tausend Zeilen, ja, nicht mal.
Ja doch, so um die tausend Zeilen Code, Frontend Code.
Also das ist ganz wenig, aber muss ich sagen, habe ich null Probleme mit.
Das funktioniert wunderbar.
Also ich würde das jetzt nicht nur auf TypeScript begrenzen, aber TypeScript besser als JavaScript auf jeden Fall durch die Typisierung halt.
Also es ist schon ein Fehleraspekt irgendwie rausgenommen aus der Gleichung.
Und ja, das hilft halt.
Absolut.
Ja, also ich habe selber sogar eine Swift-App geschrieben, genau die gleiche.
Experience sozusagen.
TypeScript war einfach nur ein Beispiel, weil es wahrscheinlich noch weiterverbreitet ist.
Wobei Swift, glaube ich, auch nicht selten ist.
Das hat sich ja durchgesetzt.
Im US-Bereich schon lange.
Anyway, wir wollten ja eigentlich über deinen Tech-Stack sprechen.
Welche Agents, welche Skills und so nutzt du?
Oder Harnesses auch?
Ich muss sagen, ich probiere immer irgendwas Verrücktes aus.
Also ich habe eine Zeit lang mal, also ich weiß nicht, vor zwei Monaten oder so, Gadget dann eine ganze Weile ausprobiert mit einem Projekt und muss dann sagen, ja, der Name ist genau das Gegenteil von dem, was passiert.
Also irgendwie wird man damit nie fertig.
Es dauert immer alles ewig lange.
Und 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 einfach, okay, wie anders ist einfach die Vanilla-Lösung.
Im Moment bin ich relativ happy mit den Bordmitteln von Cloud Code, muss ich sagen, im täglichen Arbeiten.
Und wenn man jetzt wirklich einen 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, handhabbare Aufgabenpakete runterbreche.
dass ich die noch gut überschauen kann und dass die Agent die 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.
Ich weiß, vielleicht schneiden wir das nachher auch einfach raus.
Du kannst auch Nein sagen, Ingo.
Wie macht ihr das bei Ionis?
Versucht ihr da eher einen Stil hinzubekommen oder in Anführungsstrichen zwingt ihr die Leute in einen Workflow?
Also angenommen, du 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 Spectrippen.
Quasi würdet ihr versuchen, da eine Linie zu führen oder gibt ihr die Freiheit?
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 das Problem ist, wie man einschätzt, wie komplex ein Problem ist.
Und da gibt es ja auch Tools für, die einem helfen, erstmal das zu verstehen, was ist komplex aus der Sicht deines Agenten.
Taskmaster, glaube ich, heißt das.
Das macht so eine Komplexitätsanalyse mit einem LLM, aber das kann man sicher auch schnell als Skill selber schreiben.
Und dann kriegt man halt eben so ein Output und kriegt so ein Gefühl dafür, wie krass doch ein einzelner Task ist.
Und anhand der Komplexität, die erörtert wird, 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 holen ein bisschen weiter auf.
Wir machen erstmal ein Research Run und machen dann einen Plan, reviewen den Plan, verbessern den vielleicht nochmal und lassen es dann laufen.
Und das krasseste ist halt Spectral Development.
Ich kenne Leute, die Spectral Development wirklich die ganze Zeit nutzen und nichts anderes mehr nehmen und damit super gut fahren.
Und ich werde da nicht...
reingrätschen und wird sagen, nee, so machen wir das aber nicht, weil so weit geht das nicht.
Also es gibt da sicherlich Vorgaben und Ideen, wie 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, ist extrem auch abhängig von ihrem Tech-Stack und von den Sachen, die sie einsetzen.
Das macht auch total Sinn.
Also bei so einem großen Laden wie Jonas gibt es halt zentrale Core-Services, die einfach ganz anderen Rahmenbedingungen unterliegen als irgendwelche Sachen, die Marketing-Stacks sind oder so.
Ja, genau.
Und trotzdem denke ich, gibt es wahrscheinlich so einen Bodensatz an Sachen, die halt jetzt gar nicht zu sehr abweichen, abschweifen wir heute, aber gibt es halt irgendwie so ein Basisset an, non-negotiables, also nicht funktionale Anforderungen, ja meistens irgendwie Security, Compliance, schlag mich tot, die halt dann doch wieder für alle relevant sind.
Und also wie kriegst du da einen Griff dran, ohne dass es halt quasi ein ganz enges Korsett wird.
Deswegen hat mich unheimlich interessiert, halt irgendwie zu fragen, wie man das halt irgendwie angeht, weil jede mittelgroße Firma wird dieses Problem halt haben oder hat dieses Problem.
Also gesagt, ich bin ja da auch nicht das, Ich bin ja nicht der Entscheider am Ende, ich bin ja quasi der, der die Nachricht überbringt an die anderen.
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 zeige so Wege auf.
Aber es gibt auch Themen, wo ich das aufzeigen kann, wo ich die 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 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 und kann dann sagen, okay, ich falle in die oder in die Kategorie.
Wir haben ja auch Open-Source-Tools.
Die sind natürlich dann public.
Das ist 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.
Das finde ich schon mal ein super, also sehr allgemein formuliert, aber ein super 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, also wo wird mit Kundendaten direkt agiert, beziehungsweise wo würden Kundendaten möglicherweise einmal an den amerikanischen Server geschickt werden, wo ist das völlig unkritisch und je nachdem kann man dann auch andere Rahmenbedingungen setzen.
Macht total Sinn.
Genau und in den Trainings bringe ich dann eher sowas 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 rüberbringen will.
Aber die Frage kam halt sehr oft und deshalb baue ich das jetzt ins Training mit ein.
Also quasi 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 Claude ist auch wahrscheinlich so dein Go-To-Agent.
Und ja, genau.
Alles klar.
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 200 Dollar einen Tropic-Plan zur Verfügung.
Und das ist nämlich, naja, also ich würde, wenn ich einen 200 Euro OpenAI-Plan hätte, dann würde ich halt Codex nutzen.
Also ich bin da Ich bin da leidenschaftlos, muss ich sagen.
Ich mag es mal mit allem rumzuspielen und auch mal die Tools gegeneinander antreten zu lassen.
Zum Beispiel wenn Codex Cloud Code, also Cloud-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 tollen Code schreiben und Codex ist eher so, naja, also komm, da könntest du es noch ein bisschen besser machen.
Das war eigentlich so dolle.
Das ist ganz witzig, ja.
Interessant.
Ich hatte so ein umgekehrt, ach nee, halt genau, so ein ähnliches Erlebnis.
Da war es nicht Codex, sondern GitHub Copilot und da glaube ich das Standardmodell, was Cloud Code kritisiert hat.
Und Cloud Code hat dann auch beschämt.
Anerkannt, ja, das sind alles valide Punkte.
Anyway, 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 zum Eichhorst 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, glaube ich, der es so genannt hat.
Es ist mir ein bisschen peinlich oder ein bisschen unangenehm, muss ich sagen.
Genau, Ralf und das Eichhorst-Prinzip.
Das ist schon so ein bisschen, ich sage nicht ein Witz, aber es ist schon so ein bisschen ein Experiment eigentlich.
Also die Idee ist...
Wir 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 es einfach noch nicht gab.
Und das gab es halt nicht.
Es gibt andere mit dem gleichen Nachnamen wie ich, aber es gab halt keinen, der irgendwann mal gesagt hat, ich mache jetzt mal ein Prinzip draus.
Wie lange dauert das, bis das in die LLMs reinzackert?
Also von daher, gebt das ruhig gerne weiter, auch wenn es mir ein bisschen unangenehm ist.
Ja, und die Idee ist entstanden im, wann war das?
Anfang März war ich auf der Java Land und habe einen Vortrag gehalten zu einem Thema, was eigentlich so mein Herzensthema ist.
Architektur 3.0 haben wir es mittlerweile genannt.
Also quasi die Idee, dass mehr und mehr Architektur in den Fordergrund gestellt wird, weil wenn Agenten die Code-Arbeit, also das eigentliche Schreiben des Codes übernehmen, dann quasi geht meine Rolle als Entwickler ja einen Schritt weiter raus, also eher auf die Architekturarbeit und aber auch die Architekten, die halt eben heute versuchen, Menschen zu steuern und Menschen irgendwie Vorgaben zu machen, eine Richtung zu lenken.
Das werden dann zukünftig dann halt eben mehr und mehr KI-Agenten sein.
Und mein Ansatz, um das so ein bisschen rüber zu bringen, wie man das machen kann, dass man halt einen Input in das LLM, also einen Prompt reingibt und am Ende was Funktionierendes dabei 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 da eine gewisse Wahrscheinlichkeit, dass das verauscht wird und auf dem Weg nicht funktioniert.
Damals war das halt eben analoge Telefone, Morsegeräte.
Man wusste halt eben nicht mit 100%iger Sicherheit, ist das wirklich, was hinten rauskommt, ist das wirklich korrekt.
Und 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 einen QR-Code.
Ein QR-Code hat nämlich auch so einen Fehlerkorrekturmechanismus.
Und wenn man dann beim Einkaufen mit dem Wurstfinger drüber geht und den ein 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 Fehlerkorrekturalgorithmus.
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 domänenspezifische Sachen reingebe, die das LLM gar nicht kennen kann.
Das heißt, ich bringe so ein bisschen Rauschen schon von draußen rein, dann habe ich das Sampling im LLM, 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 am Anfang vorgestellt habe.
Und 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, 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...
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 den Trainees, aber auch mit meinen Studenten, ich bin also noch Dozent nebenbei an der Uni und mit denen mache ich immer so ein Sampling-Experiment.
Wir geben 1 plus 1 ein und dann das ist gleich.
kleineres LLM und da kommt dann meistens raus sowas wie zwei, aber nur mit 66% Wahrscheinlichkeit.
Und dann versuchen wir das weiter zu verrauschen, sodass es halt eben irgendwann nicht mehr...
2 rauskommen.
Das ist 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 reinkommt, auf einmal 1 plus 1 ist 3 raus.
Aber jetzt auf einmal einen Anker gegeben haben, eine Klarheit gegeben haben, gegeben haben, am Anfang schon für das LLM.
Das Sampling ist immer noch unklar, 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 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 Fehlerkorrekturmechanismus, der wieder einen heilen QR-Code drauf macht.
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, 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 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 type safe.
Oder die Typisierung ist nicht korrekt.
Oder, keine Ahnung, die Variablen sind falsch benannt.
Oder du hast hier Tabs anstatt Spaces verwendet.
Whatever.
Und dann geht es halt eben wieder zurück.
Und das ist sozusagen grob das Prinzip.
Was ich mich gefragt habe, was für mich total einleuchtend ist, dass man etwas verrauschen kann, also dass etwas rauschen kann und dass man quasi im Endeffekt ein LLM schlechter in der Antwort machen, also quasi schlechter in der Antwort werden lassen kann.
Die Frage, die ich mich gestellt habe, ist, Geht das auch im 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.
Ja, 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 zum Beispiel.
Also wir haben ja jetzt nur über...
den inneren Loop.
Also einfach passt die Formatierung, kann das kompilieren.
Das ist quasi das Erste.
Und dann gibt es ja noch größere Loops.
Also laufen die Tests, laufen End-to-End-Tests.
Noch größer kann man eine Weltsimulation quasi dagegen laufen lassen.
Also man kann das ja weiterspinnen.
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 haben, wir sagen, hey, generiere uns mal einen Web-Server.
Wenn du das halt fünfmal 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, der rauskommt und macht das.
Wie können wir jetzt besser werden da drin, was wir wollen?
Also wenn wir uns ü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 Gehirn.
Das ist jetzt extrem einfach.
Aber jetzt fangen wir an, in unserem Gehirn Klarheit zu schaffen.
Wir fangen an, das zu sortieren.
Und das geht halt runter bis auf, wollen wir Camel Cays oder wollen wir Snake Cays haben.
Das nimmt uns oft schon die Buomiersprache 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.
Und 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, fragt quasi das LLM einen Webserver zu erreichen, dann haben wir uns irgendwann darauf geeinigt, dass es ein Wetterwebserver ist und dann laufen die Studenten alleine und haben quasi eine halbe Stunde Zeit, zwei 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 genau so aussehen.
Und dann haben wir ja quasi, das wird vielleicht bei 50 Mal, wenn wir dann nur noch zweimal daneben liegen, aber 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 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.
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, um so einen Web-Server rauszubekommen.
So viel ist es gar nicht.
Das sind meistens so vier, fünf Zeilen und 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, ja, nimm halt den Web-Server, den du oder die Wetter-API, die du für am besten hältst.
Das ist mir jetzt an der Stelle einfach egal als Entwickler.
Oder ich sage halt, nee, um Gottes Willen, das kann mir doch nicht egal sein, das ist ja wichtig, weil vielleicht gibt es welche, der haben Kosten dran, dann habe ich ein Rate-Limiting, irgendwas.
Für einen Prototypen egal, wer dann produktiv, wird es auf einmal wichtig.
Ich hoffe, das ergibt ein bisschen Sinn.
Ja, ich versuche das noch, ich versuche gerade, dass du in Real-World-Szenarien, also du hast das ja schon mit dem Webserver beschrieben, Also quasi praktisch, also einfachere Use Cases.
Versucht das gerade dahingehend nochmal für mich so zu übersetzen.
Aber Sebastian, du hattest.
Am Ende, also Schlussfolgerung ist ja, die Spezifikation bringt ja die Klarheit hier an der Stelle.
Also sprich, wenn du mehr, sorry, also sagen wir mal, nicht unendlich mehr, gibt unendlich mehr.
Genauigkeit oder Präzision, aber diese vier bis fünf Zeilen, die geben ja hier offenbar die Klarheit.
Kannst du ein bisschen beschreiben, was da genau diese vier bis fünf Zeilen oder was die ungefähr enthalten?
Also was meistens eins der ersten Sachen ist, wie gesagt, es gibt unterschiedliche SDKs, die du nutzen kannst.
Und da gibt es halt zehn oder so, die ganz gut im...
im Latenzraum vertreten sind und die dann halt eben immer wieder auftauchen.
Und dann gibt es aber auch sowas wie Kommentare.
Will ich überhaupt Kommentare haben?
Wenn ja, wie sollen die aussehen?
Die sind natürlich kunterbunt gemixt.
Ist das eine Programmiersprache?
Das ist ja schon das Erste.
Wahrscheinlich kriegst du Python raus.
Also die Wahrscheinlichkeit, Python zu bekommen für eine Wetter-API, da habe ich eine relativ gute Sampling-Größe mittlerweile.
Also die ist hoch.
Aber vielleicht willst du ja nicht Python.
Also es ist trotzdem nicht gesagt oder mit Sicherheit, dass du Python rausbekommst.
Dann die Benahmung der Variablen.
Das ist halt auch kunterbunt.
Dann, wie baust du das?
Also gibt es eine Main-Funktion quasi, die irgendwie eine Unterfunktion aufruft?
Oder ist das alles in einer großen Funktion?
Und wir sind natürlich jetzt sehr, sehr kleinteilig.
Wahrscheinlich für den...
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.
Und dann ist es okay und oft spielt es auch gar keine Rolle.
Es ist wirklich mehr zu zeigen, dass das Denkmodell halt ein anderes ist als klassische rollenbasierte Skripte zu schreiben, also rollenbasiert zu arbeiten oder regelbasiert zu arbeiten und einfach sagen, okay, wenn das, dann das.
Das ist ja im Endeffekt, was wir poemieren oder zumindest ein großer 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, um so dieses Fingerspitzengefühl dafür zu bekommen, wann ist es genug, wann ist es vielleicht auch zu viel.
Und das macht immer riesig Spaß, auf jeden Fall.
Das ist eine ganz klasse Aufgabe.
Und man kann das total auf die Spitze treiben.
Ich weiß, vor anderthalb Jahren oder so gab es eine Bewegung, die hießen Prompt, Spec Prompt, nee, Prompt, ich weiß nicht.
Also irgendwas auch mit Spec und mit Prompt.
Und die waren, das waren halt...
Das war eine strukturierte Sprache.
Es war so eine domain-spezifische language, 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 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.
Bei IONOS 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 sowas, was halt eben das Rauschen erhöht.
Genau, je schwächer das Modell ist, desto schwieriger wird es ihm fallen, auf Basis meiner Information, meinen Intent, den ich reingebe, zu generalisieren und zu sagen, okay, das ist das größere Konzept, in dem das drin besteht.
Wenn ich eine ganz, ganz klare Pseudocode-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 ein größeres Modell kann sich dann halt eben auch in generellere Aussagen einfacher reinhängen.
Das ist auch meiner Meinung nach neben dem agentischen Loop 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 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 echt beeindruckend mittlerweile.
Obwohl ich sagen muss, Stefan und ich, wer hat telefoniert?
Ich so, was haben die alle mit Opus 4.5?
Das war das, was Dezember rausgekommen ist.
Warum finden das alle so toll?
Warum feiern das alle?
Ich 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.
Ja, weil man hat immer diesen inkrementellen 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.
Ich verstehe, das ist so ein bisschen das Iterative.
Wenn man sich stark damit beschäftigt, dann fühlt sich das eher iterativer an.
Ja, aber dann merkst du halt diese Rauschreduzierung quasi, die 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 geht.
Ja, das hört man ja auch immer wieder, dass dadurch der Vorsprung noch relativ gering ist, weil alles, was man sich in einem alten Modell an Hilfsmitteln drumherum aufbaut, damit das Ergebnis...
besser wird, in der 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 Eichhaus-Prinzip zurückzukommen.
Je öfter wir es hier im Transkript erwähnen, vielleicht kommt es dann noch schneller in irgendeinen LL-Inwort rein.
Das Beispiel, was du gebracht hast hier zum Web-Server, das ist ja schon sehr eng.
Das ist ein sehr, sehr enger Loop, beziehungsweise auch mit dem Pseudocode 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?
Ich glaube, es ist einfach, also für mich selbst ist es 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.
Gleiches, wenn ich ein kleineres Modell habe.
Also es hilft mir einfach gut, schnell darüber nachzudenken.
Warum folgt B aus A?
Dafür ist es einfach ein gutes Werkzeug, glaube ich.
Und das fand halt Ralf auch.
Deshalb hat er das mit übernommen.
Und ja, ich weiß gar nicht, was soll ich noch dazu sagen?
Also dafür ist es gedacht.
Ich denke, das funktioniert genauso für alles andere auch.
Der agentische Loop ist damit eingebaut.
Ich glaube auch nicht, dass, ganz ehrlich, das erklärt ja quasi.
ein LLM von 2017 genauso wie ein LLM von heute und die Funktionsweise von heute.
Also es fällt mich schwierig, jetzt irgendwie da was zu erkennen, wo ich jetzt sagen würde, okay, 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.
Ich glaube auch, das hat eine gewisse Allgemeingültigkeit.
Es wird auch mit besseren LLMs, also quasi die das Rauschen, zwangsläufig reduzieren.
Ich glaube, das ist natürlich auch bloß bis zu einer gewissen Grenze halt irgendwie möglich.
Also gerade was so Kontextinformationen angeht, das kannst du ja nicht raten.
Also ein gewisses Potenzial zum Halluzinieren wird es halt immer geben.
Aber es wird quasi das, was du beschreibst, wird halt eben nie schaden, würde ich sagen.
Also es ist tendenziell von einer, also es ist halt tendenziell wird es, könnte man es auch als Best Practice bezeichnen.
Genau.
Und was Shannon halt auch sagt, ist, du hast halt einen gewissen Informationsgehalt in Informationen.
Also er hat halt eben Informationen neu gedacht, anders als quasi.
davor darüber nachgedacht wurde, wo Informationen eher so als physisch versucht wurden, quasi als Wellenlängen zu denken.
Und er hat halt eben Informationen eher verstanden als Entropie, also als Unterschied zu dem, was da ist.
Das heißt, sein Beispiel war immer, 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 null Informationen, weil du wirst ja 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 zampeln, okay, wir wissen nicht, wo was ist.
Das ist Information, die uns fehlt und wir wollen diese Information haben.
Wir zampeln die aus dem LLM, wenn sie dort vorhanden ist.
Oder das LLM durchsucht das Internet für uns.
Das ist halt eine andere Art, das zu finden.
Wenn wir das aber quasi abgespeichert haben.
Also wie, bei mir ist noch Prometheus aus der 10.
Klasse, ist da noch komplett eingebrannt.
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.
Und 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, kreativ in Anführungsstrichen, aber neu gesampelt wird aus unserer Perspektive.
Und das finde ich ist so ein spannender Ansatz und der zeigt halt eben auch, dass LLM ist halt kein Buch.
Sollten wir auch dafür nicht nehmen, sondern es ist eine neue Kombination, die halt genau dann sinnvoll ist, wenn sie nicht zu krass entropisch ist.
Also Kauderwelsch, wenn man die Temperatur auf zwei stellt bei LLMs, dann kriegt man komplett einen Kauderwelsch raus und dann wird beliebig gesampelt aus allen Tokens, die verfügbar sind.
Also das ist dann gibberish.
Hat zwar viele Informationen jetzt nach Shannon'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 eben immer darum, irgendwie so einen Sweetspot zu finden.
Genug Entropie, dass es sinnvoll und hilfreich ist.
Sonst kann ich halt auch einen Gesetzestext nehmen und der ist halt so gegeben.
Dann brauche ich kein LLM oder kein KI-Modell.
Und es muss aber trotzdem halt eben nicht zu krass.
entropisch sein, weil dann ist es nicht mehr, dann kann ich es nicht mehr anwenden.
Dann hat es keinen Sinn mehr in der realen Welt.
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, sondern dass da eben was Neues entsteht.
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.
Das ist nachweisbar, statistisch habe ich auch hier.
Ihr hattet das ja vorhin kurz angesprochen.
Ich hatte so einen kleinen Artikel geschrieben.
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.
Und 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.
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.
Und 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 drumherum ist, die man einfach noch wieder, so dieser Review-Schicht, 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 ihre Implementierung und einfach austauschbar werden dadurch.
Sowas 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 nach Bersand, das wollen wir doch lieber ein bisschen anders haben.
Und da haben wir jetzt klassisch hier von Corolla Lilienthal zum Beispiel langlebige Software-Architekturen, 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.
Und zwar bei Menschen halt schon so, aber Menschen produzieren halt eben begrenzt Code.
Die besten Entwickler erzeugen irgendwie minus 10 Lines of Codes am Tag.
Aber ich denke, so viel mehr als 200 Zeilen ist wahrscheinlich nicht drin.
Und bei LLMs, ja, das ist natürlich ein Witz.
Und dadurch geht das natürlich mit der Erosion, mit den Tech-Tabs 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 einen Loop drüber stülpen und können sagen, okay, wir gehen jetzt mal raus aus dem Loop und gucken, okay, was funktioniert denn gut, was funktioniert nicht gut.
Im Cloud-Code gibt es so ein Slash-Inspect-Kommando.
Da kann man sich so einen Report erstellen über das, was man so, ja, wie man sich so mit dem...
LLM unterhalten hat, mit dem Agenten unterhalten hat, was war gut, was war nicht so gut, was sollte beim Menschen verbessert werden, aber man kann sich natürlich auch die Protokolle angucken, das habe ich halt eben für Oerlicht 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 Pi sieht man das sehr schön, da wird nämlich dann der Hintergrund rot, also in der Standardkonfiguration, das finde ich super, weil Das zeigt dir halt eben, okay, da ist irgendwie, hat das LLM gerade eine Fehlanlahme getroffen, um das Ziel zu erreichen.
Warum hat es die Fehlanlahme getroffen?
Also bei mir war das eigentlich irgendwie meistens relativ schnell fixbar.
Aber ich habe halt von Leuten gehört, da hat ein LLM zehn Minuten was Falsches gemacht.
Es hat von 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 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 Richtung Dark Factories oder Self-Improving Factories.
Da sind wir noch super am Anfang, aber extrem spannendes Feld.
Genau, ich habe deinen Artikel auch vorhin noch gelesen, haben wir ja schon kurz drüber gesprochen im Vorgespräch und fand ihn total spannend.
Und ich höre jetzt bei dir raus, dass du...
das durchaus, ja, sagen wir mal, wahrscheinlich ein bisschen positiver betrachtest als, ich habe folge Armin Ronacher auch, der gerade mit seiner Firma Aaron Deal 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 gecodet.
Der ist wirklich erfahren, der war vorher ein guter Coder, macht das mit den Agents seit April 2025, glaube ich.
Das heißt, er ist auch schon lange dabei gewesen und das für ihn dann so auch explodiert, als dann Cloud Code rauskam und es immer besser wurde.
Aber auch der sagt, da fehlt noch was.
Ein Beispiel von ihm ist immer, was ich persönlich auch in meiner meine Arbeit sehe oder in meinen 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 zum Beispiel ein User-Kontext nicht vorhanden ist, dass man da nicht einen Fehler wirft, sondern dass man dann sagt, ich nehme mich halt als Fallback-Default-User, was dir in so einem Kontext, in dem du aber dem Nutzer irgendwelche Informationen anzeigen möchtest, ja überhaupt gar nicht hilft.
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 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 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 Analyse der Studien sozusagen durchaus ein bisschen positiver.
Höre ich das richtig raus?
Naja, das ist total lustig, weil 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 ein bisschen Anfang des Jahres.
Ab da bin ich einfach im Blindflug.
Und ich würde sagen, das ist natürlich das, wo es gerade irgendwie so cambrisch explodiert ist mal wieder.
Und bis dahin ist es eigentlich 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 im Schnitt in den Teams bei so plus 15, 10, 15 Prozent Produktivitätsgewinne.
Das sind jetzt aber Daten, die schon neun Monate alt sind.
Und die besten Teams schaffen es dann vielleicht so eher so 30, 25, 30.
Und es ist 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, das 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 irgendwie noch mal ein ganz Interessantes in Zahlen zu sehen, als nur ein Bauchgefühl zu haben.
Absolut, genau.
Die E-Vals, die sind ja doch sehr, sagen wir mal, individuell kleine Sampling und so, die man sonst so hat.
Genau, und was da ja auch rauskam, ist das tatsächlich, was du ja eben schon angesprochen hast, ja, Produktivitätsgewinn, gleichzeitig aber durchaus eine Verschlechterung der Qualität, also der Code-Qualität sozusagen.
Aber ich sehe das nicht wirklich, also das ist jetzt, und das bringt mich immer so ein bisschen in eine schwierige Situation.
Ich möchte schon, also 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 war letztens bei einer Pendel-Diskussion mit Corolla Lilienthal 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 ein bisschen wie so ein Archäologe irgendwie, so ganz cool.
Ich mochte das.
Aber es ist natürlich doch schon ein relativ langwieriger Prozess und 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, die 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, wie soll ich sagen, Arschkarte.
Für die ist es natürlich jetzt auf einmal eine 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.
Aber jetzt so in dem Setting, ich möchte da schon offen sein.
Schon sagen, dass es da nicht nur Gewinner gibt, nicht nur Leute, die da Plus rausziehen.
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, 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, um 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.
Ja, total, total.
Und auch, ich finde halt auch Test-Ridden Development Und Clean Architecture, also Clean Code spielt ja total in Programmieren mit KI rein.
Das ist ja, das passt ja, wie die Forst aufs Auge.
Aber ob jetzt Clean Architecture für uns in zwei, drei Jahren noch der richtige Ansatz ist, also hexagonale Architektur, Ports und Adapters, wir werden sehen.
Also ich kann mir schon vorstellen, dass da irgendwie ganz, ganz verrückte andere...
Architekturen entstehen, vielleicht auch dynamisch entstehen, einfach darauf, weil wir sagen, okay, das ist jetzt gerade, das hat sich sozusagen, wenn man sich jetzt Gradient Descent, also quasi die, so funktionieren ja das Training von KI-Modellen, dass man versucht halt eben so ein lokales Minimum, im Optimalfall ein globales Minimum zu finden und sich immer weiter diesem Nullwert anzunähern.
so wenig wie möglich Reibungspunkte zu haben in dem Output.
Und das kann ich mir gut vorstellen, dass das für Architekturen auch funktioniert.
Letztes Jahr habe ich das mal so ein bisschen angeteasert und habe einen Artikel geschrieben für Informatik aktuell, Verstärkung der 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 André Capasi nennen.
Damals habe ich das quasi im Kleinen 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, naja, nimmst du Monolith 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, ich habe jetzt einen Domänen oder vielleicht einen Web-basierten Ansatz gefahren.
Peer-Ansatz oder einen zentralen oder einen verteilten Ansatz gefahren oder sowas.
Also dass man gar nicht mehr so weit runter geht und die Architektur sich quasi selber findet.
Im Endeffekt existiert das ja auch nur, weil 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.
Ich glaube, geht so ein bisschen in das, was wir am Anfang halt irgendwie diskutiert haben, ü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?
Also 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 darauf hinaus.
Es ist halt wie immer.
It depends.
Ja, und also ich bin auch davon überzeugt, dass es viele, viele neue Felder geben wird.
Ja, auch wenn jetzt das klassische Programmieren wahrscheinlich so ein bisschen zu einem Artefakt wird.
Und ich hatte das letztens in einem Jobinterview, wir hatten ein Jobinterview mit einem Kandidaten und die Aufgabe war halt, in der Programmiersprache der Wahl ein genestetes Array zu...
ich weiß gar nicht mehr, flach zu machen und zu sortieren oder so.
Also so eine klassische Aufgabe, die man halt in einem Interview stellt.
Und ich fand das so spannend.
Also ich 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.
Aber ich gucken wollte, ob ich das noch hinkriege und habe dann so mehrere Ansätze gegeneinander verglichen.
Einfach nur so ein String-Austausch.
Also man kann das ja unterschiedlich lösen.
Man muss das ja nicht parsen und dann als Array mit Flatmap oder so, sondern es gibt ja da viele Ansätze.
Und 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.
Ich finde es spannend, dass ihr das in einem Interview fragt.
Aber 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.
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?
Personen starten an unterschiedlichen Orten.
Ich habe das nie so krass gesehen wie jetzt.
Also in der Schule muss man ja irgendwie die letzte Klasse abschließen.
Jetzt muss man den Satz des 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 ein 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 Level zu bringen und alle eine Brücke zu bauen, um da hoch zu gehen.
Zumindest versuche ich das.
Und das ist schwierig, weil wir halt Menschen sind.
Und zweites ist, wir sind gerade in einer Phase, wo Wie ihr auch gesagt habt, 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, 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, okay, 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 der nicht funktioniert, wie oft der funktioniert.
Und damit, glaube ich, kommt meine ganze schon sehr, 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.
Danke dir.
Ja, André hat es gerade schon angeteasert.
Wir haben am Schluss immer noch so ein kleines Recurring-Segment und da geht es immer um den heißen Scheiß sozusagen.
Also was ist für dich gerade so der absolute Hype-Kram?
eben ja schon angesprochen, das Thema Dark Factories und Harness Engineering, das ist schon das, was mich gerade sehr begeistert.
Da steckt eine Menge drin, zumal es halt eben auch so ein bisschen Weiterdenken 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 halt eben auch von den Möglichkeiten, die daraus entstehen.
Und das, was ich bei Oerlicht 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, dass die sich über Nacht automatisch integrieren.
Und das ist quasi jetzt mein Ansatz.
Also ich möchte den Harness, das Drumherum so stabil machen, dass so klar ist, wann das richtig ist und wann es falsch ist, dass einfach so ein neuer ein neuer Agent über einen einfachen Skill und halt eben diese Guard Rates 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, das ist nicht mal ein richtiger Agent, aber mein erstes System war ADA und das ist komplett gescheiße.
Es haben drei von fünf Use Cases funktioniert am Ende.
Also ich bin da noch auch.
am Anfang.
Aber ich sehe da halt super viel Potenzial.
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 es 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 um ist.
Aber ich bin da insofern, ich habe da noch so ein logischen Knackpunkt darangehend, dass wir ja gelernt haben, Wasserfall ist halt nicht gut, weil du ja erst während des Projektes herausfindest, wie die Lösung aussehen muss, die du brauchst.
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, sich wirklich dann aber auch damit ein bisschen beschäftigen muss, je nachdem, was das für ein Problem ist, was gelöst wird.
Wenn du da irgendwelche Integrationen machst, wie StrongDM oder wie die hießen, die hatten halt Konten relativ klar.
genau diese Entropie rausnehmen und diesen Loop insofern automatisieren und dem Agenten oder des Harnes so aufbauen, dass der Agent ü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, um dann den nächsten Schritt zu definieren wahrscheinlich.
Sorry, jetzt bin ich doch wieder tiefer reingegangen ins Thema, als ich eigentlich wollte.
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 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 rumschwimmen.
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 und da gibt es halt Fälle.
Und jetzt versuche ich, die Umgebung zu simulieren.
Also quasi, ich schaffe mir, André Capasi hat mal gesagt, LLMs sind People Spirits.
Also so 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.
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.
Es gab so Persönlichkeitstests 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?
Ja, war dann auch so 85 Prozent Übereinstimmung mit den Antworten vor.
Also LLMs 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 ein State-Transfer bei mir in meiner Öhrlicht-Anwendung, wo dann halt eben 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 Agent, der es baut, der guckt dann halt ins Protokoll, okay, ist das sinnvoll überhaupt gerade?
Also ergibt es Sinn?
Und der Kunde, der LLM-Kunde, der sich das quasi anguckt, der muss dann auch sagen, okay.
Gibt es Sinn für mich?
Passt das gerade?
Und so habe ich halt eben mehrere Quellen und versuche so ein bisschen, diese Lösung zu triangulieren aus den unterschiedlichen Sampling-Quellen vom LLM.
Und ja, das ist schwierig, weil das ist eine schwierige Aufgabe, weil halt eben 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.
Absolut, ja.
Und genau, zum heißen Scheiß fragen wir auch immer nach What-the-Fuck-Momenten.
Hast du auch hin und wieder What-the-Fuck-Momente noch?
Oder sagst du, eigentlich durch dein Eichhaus-Prinzipal bist du so immun dagegen, dass du alles gut umschiffen kannst?
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, aber für mich ist das so normal, weil es ist halt so, wenn du mit Menschen redest, dann...
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 mal gerade aufgeschrieben, mal 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, 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 fertiggestellt sein.
Und da ging es um 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.
Da musst du schon ein bisschen an der Datenbank rumkratzen.
Das musst du den 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, dann baue doch da eine Umgebungsvariable rein.
Und dann hat er dann die E-Mail-Adressen mit dem dazu gemappten Tenant als Umgebungsvariable reingeschrieben.
Das war so der Ansatz.
Und dann habe ich mir das angeguckt und habe gedacht, um Gottes Willen, warum?
Und dann habe ich das nachverfolgt und dann habe ich gesehen, ja, der eigentliche Trigger dafür, um diese Entscheidung zu treffen, war halt, dass das LLM gesagt hat, ja, es muss ja schnell gehen.
Aber schnell ist halt anders jetzt auf einmal.
Jetzt gibt es kein langsam mehr.
Also es gibt nur noch schnell.
Also warum sollte ich noch irgendwas...
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 das Startup bei dir auf keiner Max-Subscription von Claude.
Doch, doch, da sind die auch.
Nein, nein, das ist auch einfach nur, das sind so Kleinigkeiten, wo man sich denkt, so krass, wie sich so eine Kleinigkeit halt eben auswirkt am Ende.
Ich habe auch nur Spaß gemacht, aber es ist...
Die sind ganz toll und die machen ganz, ganz klasse Arbeit.
Sonst wäre ich da nicht mit involviert.
Der will das gar nicht...
Die machen auch sonst mal alles ganz toll, war wirklich nur in dem Moment irgendwie so ein Beispiel, was mir aufgefallen ist, wo ich gedacht habe, ach guck, das ist ja nett.
Fairerweise wäre aber da spannend, halt irgendwie zu verstehen, warum solche Sachen quasi das triggern.
Das wäre zumindest meine Folgefrage, weil richtig logisch, eine gute Erklärung hätte ich dafür nicht.
Ja, also das LLM hat halt eben eine Vorstellung von Zeit, die basiert nur auf...
von vor zwei Jahren oder vor einem Jahr.
Also auf den Trainingsdaten halt.
In den Trainingsdaten dauern die Dinge halt länger.
Und wenn es schnell gehen muss, dann ist es halt laut Trainingsdaten, mach es halt hacky.
Und ich glaube halt, jetzt sind wir das erste Mal in der Geschichte, in der Programmierung an einem Punkt, wo wir einfach das vielleicht ein bisschen challengen können.
Das ist 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.
Gut, danke.
Vielen Dank.
Ja, war eine sehr interessante Folge.
Der HMZE Podcast ist ein gemeinsames Projekt von Sebastian Heidemeier zu erben und André Neubauer.
Infos zum Gast und Themen aus dem Podcast findest du in den Shownotes.
Diskutieren kannst du mit uns bei LinkedIn und für alles andere, zum Beispiel wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an podcast.hmze.tech schicken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.