Ralf D. Müller — „Semantic Anchors“

Ich habe ihn gestoppt, habe gesagt, du, du musst jetzt irgendwie anders vorgehen, dass du das Verhältnis zwischen grünen und roten Tests verbesserst. Er gesagt, ja, danke für den Hinweis, hat zwei rote Tests gelöscht und hat gemeint, jetzt ist das Verhältnis besser. Herzlich willkommen zu einer weiteren Episode unserer neuen Staffel von HMZE Beyond Vibe Coding, der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten. Ich bin Sebastian Heidemaier zu Erpen, CTO bei North IO.

Und ich bin Andre Neubauer, CTP O bei Trusted Shops. Schön, dass ihr wieder da seid. Heute ist Ralf Müller bei uns, also nicht der Schauspieler, der heißt nämlich Ralf Möller, wie ich quasi gerade wieder gelernt habe, sondern es geht um, genau zu sein, um Ralf D. Müller, der in der Architekturszene nicht ganz unbekannt ist.

Hat der ein oder andere sicherlich schon mal auf einer Konferenz oder in einem Podcast gesehen. Und es geht um Zaubersprüche. Ja, Zaubersprüche trifft es eigentlich schon ziemlich gut. Tatsächlich nennt er es Semantic Anchors und das sind bestimmte Begriffe oder Wortgruppen, die Wissensgebiete in LLMs aktivieren und damit mit wenigen Worten es ermöglichen, sehr präzise Ergebnisse basierend auf umfangreichen Methoden zu erzielen.

Super spannendes Thema und welche Semantic Anchors er schon gefunden hat und wie das genau funktioniert, erzählt er uns in dieser wirklich hervorragenden Episode. Deswegen viel Spaß beim Hören. Herzlich willkommen zu einer neuen Episode von HMZE Beyond Vibe Coding. Heute haben wir einen Gast, den wir auch so indirekt aus dem Netzwerk kennen, wie die meisten unserer Gäste empfohlen tatsächlich von Stefan Schmidt zu einem ganz besonderen Thema.

Herzlich willkommen Ralf. D Müller, genau, lässt sich besser wiederfinden als nur Ralf Müller. Genau, wir bitten unsere Gäste am Anfang sich einmal kurz für unsere Zuhörer vorzustellen. Mach das doch gerne mal, erzähl mal, wer du bist, was du so gemacht hast.

Ja. Herzlich willkommen. Danke. Also erstmal danke für die Einladung.

Ralf D Müller, ich bin irgendwie seit zehn Jahren auf Konferenzbühnen, weil es einfach weil es einfach Spaß macht und beschäftige mich seit ja, auch ungefähr zehn Jahren mit Architekturdokumentation. Arc 42, da bin ich der dritte Mann hinter Gernot Starke und Peter Ruschka, derjenige, der sich so ein bisschen um die Technik kümmert. Und Ende 2023 bin ich zu dem Thema Generative gekommen. Oh Wunder, da ist das Thema zum Fliegen gekommen und da habe ich mir eben auch gedacht, ich gucke mir das an und bin da ziemlich hängen geblieben.

Ich habe damals angefangen, mein eigenes Chat-System aufzubauen, um die API kennenzulernen. Hat total viel Spaß gemacht. Und so langsam kriege ich wieder den Bogen zur Softwarearchitektur und eben auch da die Dokumentation, weil gerade die Dokumentation für die LLMs ja super wichtig ist, weil das ist das, was sie ja sehen. Im Kontext, ne?

Und deswegen wird die Architekturdokumentation und die Dokumentation allgemein jetzt super wichtig. Und da passt auf einmal alle Puzzleteile wieder total zusammen. Danke dir. Vielleicht erstmal eine provokante Frage zu Beginn, bevor wir dann zu unserem üblichen ersten Einstand kommen.

Architekturdokumentation, ändert sich das gerade? Also ist es jetzt eher eine Sammlung von MD Files, die miteinander verlinkt sind? Es ändert sich, aber in eine andere Richtung, als die meisten glauben. Ähm, ich sehe Architektur-Dokumentation tatsächlich wenig in den Prozessen, so in dem Spec Driven Development, ist aber total wichtig.

Ähm, habe ich gerade vorhin wieder einen Post abgelassen, weil äh ohne die Architektur, ähm, weiß das LLM gar nicht so recht, na ja, es wird was machen, ja, aber es wählt dann selbst die Architektur. Und das sollte man nicht aus der Hand geben. Und deswegen, ähm, wenn man es verstanden hat, dann merkt man, dass die Architektur wichtiger ist als vorher, weil ähm, früher im Team hat man sich so, ich sage immer am Lagerfeuer ausgetauscht, wie machen wir das, gehen wir links oder rechts? Ähm, das passt mit der, ähm, mit der KI nicht mehr so, weil die ist am Lagerfeuer nicht mit dabei, sondern die braucht das im Kontext.

Und dafür, ja, MD Files machen Sinn. Ich benutze ganz gern AsciiDoc, einfach aus dem Grund, AsciiDoc ist ein technisches Dokumentationsformat. Ähm, eigentlich genauso leicht wie Markdown, aber es gibt z.B. ähm, die das den Diagramm, ähm, ja, das Diagramm-Makro.

Und wenn ich AsciiDoc verwende, dann kennt das die KI und kann gleich Diagramme schreiben. Und Arc42 ist halt das Template. Ich glaube, wir haben es mittlerweile in 12 Sprachen ist es verfügbar, wird weltweit verwendet. Und auch das ist wieder so ein Punkt, weil es seit 20 Jahren existiert, seit 20 Jahren Open Source ist, ist es in den Trainingsdaten der LLMs drin.

Und wenn ich einem LLM sage, Arc42, dann weiß es ganz genau, 12 Kapitel, die und die Struktur. Das ist natürlich ein unheimlicher Vorteil, ne, wenn das äh nichts äh ja, vielleicht ist es sogar was proprietäres, aber was bekanntes ist. Schon mal das erste Nugget für mich mitgenommen, mir das AsciiDoc anzuschauen. Genau.

AsciiDoc ist nicht ganz so weit verbreitet wie Markdown, wird aber eigentlich genauso gut von den Tools unterstützt und hat den großen Vorteil, Markdown gibt's, ich würde sagen, in der Wikipedia sind so ungefähr 60 Dialekte aufgeführt. Bei AsciiDoc gibt's nur einen und das heißt, das Tooling, das passt immer, weil es immer der gleiche Source ist. Ist halt präzise damit, ne? Okay.

Perfekt. Ich glaube, wir haben, ich hätte schon ein, zwei Brücken zu unserem Hauptthema machen können, aber wir sagen ja am Anfang immer, quasi, wie arbeitest denn du? Also, was ist dein aktueller Tech Stack oder Tool Stack? Experimentierst du viel?

Und so weiter und so fort. Also, vielleicht kannst du da uns mal so einen Einblick geben, was so deine, deine, deine tägliche AI-Kost ist. Also, experimentieren auf jeden Fall. Und ich bin als Technology Evangelist unterwegs.

Das heißt, ich, ich erkläre Leuten die Technologie. Ich, äh, ich versuche, dass der Funken meiner Begeisterung überspringt und das klappt eigentlich, glaube ich, meistens recht gut. Und für diese Rolle muss ich halt viel ausprobieren. Und muss ich verstehen, wie das funktioniert und warum das funktioniert.

Das Warum ist ist heutzutage super wichtig, weil die KI, wenn sie z.B. dokumentiert, dass was da passiert und wie der Code ausgeführt wird, ist nicht das Problem. Warum ich jetzt hier einen Merge Sort und keinen Quick Sort verwendet habe oder sowas, warum ich die und die Datenbank verwendet habe, das Warum ist heutzutage echt ein größeres Problem. Und wenn wir vom Tech Stack reden, ist es total faszinierend, dass der eigentlich jetzt egal geworden ist.

Hauptsache, die KI kann gut damit umgehen. Und äh gerade heute habe ich mich wieder mit der KI drüber unterhalten, wie man den den Loop hinbekommt äh im Agenten im Coding Agenten, dass der Agent sich gut korrigieren kann. Und da haben unterschiedliche Sprachen unterschiedliche Stärken. Und dann sage ich doch, muss ich nicht unbedingt meine Sprache, die ich gewöhnt bin, also ich bin eigentlich mit dem Java Stack aufgewachsen.

Ähm muss ich nicht den benutzen, sondern dann benutze ich einen anderen Stack, den die KI für dieses Problem vorschlägt. Und das eben auch, wenn die KI das Problem kennt, dann kann sie eben auch sagen, ja, du ähm für das Problem haben wir hier mit Python die besseren Libraries als mit Go. Go wäre zwar typisierter und äh für einiges praktischer, aber in dem Fall nehmen wir besser Python. Und dann sage ich der KI, okay, du weißt, ich kenne Java.

Wenn ich blöde Fragen habe, dann erklärst du es mir bitte ebenso, dass ich als Java Entwickler das verstehe. Und damit ist der Technologie Stack für mich relativ in den Hintergrund geraten. Ist verrückt. Ja, mach mal, Sebastian.

Ja, genau in mit mit Text Stack äh also die die Frage ähm hat auch eher den Hintergedanken, welche äh welcher KI Text Stack sozusagen, ne? Also es ist eher Cloud Code, ist es äh Codex, äh ist es Integrati KI oder nutzt du Cursor? Und wie ja, also welche wichtigsten Tools äh nutzt du so? Hast du irgendwie bestimmte Skills oder Plugins, die dich extrem weitergebracht haben?

Der Text Stack. Okay. Der benutze äh Cloud Code ähm schon ziemlich lange. Ich benutze auch Kiro ähm und jeweils eben mit den Cloud Modellen, wobei man mittlerweile auch bisschen hört, dass äh Claude so ein bisschen naja verheizt jetzt mehr Tokens und wird teilweise schwieriger.

Ich bin mit Claude noch ziemlich zufrieden und ich benutze ja, wenn ich Tools benutze, dann eben auf der CLI. Also ich setze meinen Cursor nicht mehr in irgendein Editorfenster, deswegen selbst sowas wie Visual Studio Code für ein Preview oder so. Nee, da sage ich der KI öffne mir das Preview bitte im Browser und dann macht sie das und dann sehe ich das. Und deswegen bin ich von den Editoren IDEs komplett weg.

Die KI macht das Debugging für mich und ähm ja, damit ist quasi eigentlich nur noch Modell und Harness und was so Skills und Agenten angeht, ich versuche mit dem Modell den Agentic Flow durchzugehen und das Agentic Ich musste da erstmal lernen als Non-Native Speaker. Agentic hört sich für einen Deutschen jetzt immer so an wie Agenten ähm und im Englischen heißt es eben auch eigenständig. Wenn einem das bewusst geworden ist, ähm ja ähm mein Claude Code arbeitet eigenständig und wenn Claude Code meint, es müsste noch irgendwie was an Agenten abgeben oder so, dann dann kann es das machen. Aber das war auch total faszinierend, weil ich schon ziemlich früh 2023 als mein eigenes Chatsystem gebaut habe und dann Function Calling hatte, da habe ich schon überlegt, was passiert eigentlich, wenn ich als Function dem LLM ein LLM mitgebe.

Ich habe das Mhm. inneren Gedankengang genannt und habe das als Function Calling mitgegeben und der hat es genutzt. Der hat einfach sich seine eigenen Prompts geschrieben und dann das LLM gestartet, z.B. für einen Code Review.

Und äh, ja, eigentlich war das damals schon ein moderner Agent. Ich wusste damals noch nicht, aber es hat funktioniert, war cool. Und es ist eben auch cool, wenn man eben die Technologie mal so ähm ja richtig erfährt, selbst erfährt, dass das eben ja einfach nur eine einfache API ist, die man eben im Loop aufruft. Und dann ist dann treten eben auch die die Skills und äh Subagents und sonstwas finde ich ein bisschen in den Hintergrund.

Ich habe so ähm vier Punkte, wo ich sag, ein Agent macht Sinn, das ist, wenn ich äh zu wenig Kontext habe, wenn ich Kontext auslagern möchte, wenn ich Geschwindigkeit brauche, also Parallelität. Wenn ich äh Fokus brauche, dass eben ähm die Aufgabe vorne im Kontext steht und nicht irgendwo weiter hinten, wo der Kontext schon stattgefunden hat. Und äh der dritte Punkt steht auf der Folie in meinem Training. Guter Verweis, äh wer quasi da äh mehr mehr sehen, mehr hören will von dir, der kann Training buchen.

Findet man glaube ich auch bei LinkedIn, wenn man nicht wenn ich es richtig erinnere. Genau. Dann haben wir das auch untergebracht. Äh ich hab schon ein paar Nuggets für mich mitgenommen.

Äh ich finde äh auch äh ich glaube, das haben wir noch nie besprochen, Sebastian hier, ne? Aber diese Fehlinterpretationen oder diese erste Reaktion, Agentic ist ein Agent, ne? Das das ist äh das hör ich immer wieder oder also diese Wahrnehmung auch, also quasi diese äh gefühlte falsche Übersetzung, also ähm False Friend, ähm gut, dass du das heute übernommen hast für uns, Ralf. Gerne doch.

Dafür bin ich da. Nein. Hat hat ja nur bis zur, weiß ich, 12. Episode oder so.

Genau. Alles klar. Gut, vielen Dank. Ja, das das ist genau das, was uns auch immer wieder interessiert, weil am Ende die meisten nutzen natürlich Cloud Code, aber die Art und Weise, wie Cloud Code benutzt wird, ist doch immer wieder unterschiedlich und deine Gedanken, die du jetzt gerade geteilt hast, sind da auch noch mal total spannend gewesen.

Erinnert mich ein bisschen an an den Mario Zechner, der auch eher sagt mit der Pi Coding Harness entwickelt, der auch eher sagt, er will eigentlich gar nicht so viel Zeug haben, sondern er will eher down to the Basics, möglichst kleiner System Prompt und dann eher sozusagen für den Anwendungsfall, den er gerade hat, das Tool bauen oder nutzen, was er dafür braucht, ne? Das erinnert mich ein bisschen daran. Ja. Das mit dem Tool bauen, wenn ich da gerade noch mal aufgreifen darf, das finde ich halt auch spannend, weil wenn ich merke, dass der die KI irgendwas für mich gut gemacht hat, z.B.

Bilder generiert, wer meine LinkedIn Post kennt, der wird merken, oh ja, das ist viel mit KI generiert. Und das ist irgendwo immer wieder der gleiche Stil, ja, dann sage ich irgendwann, das hast jetzt zweimal gut gemacht, jetzt schreib dir mal einen Skill dafür, aber schreib den selbst, ja, und dann dann weiß ich, es es kommt reproduzierbar wieder, ja. Das ist die Art und Weise, wie ich Skills verwende. Ja.

Exakt, exakt, genau. Gut, dann würde ich sagen, aber Tech Stack abgehakt und können zu the meat übergehen. Der Stefan hatte ja, weiß gar nicht, vor welchen, vor wie viel Folgen das war, aber zumindest als letztes Mal da war, hatte er einmal so dieses Name Dropping gemacht, Semantic Encas. Also, ich kann ehrlich zugeben, war mir bis dahin noch nicht ein Begriff und deswegen vielleicht auch einfach mal so für viele der Leute, die hier zuhören, was ist es denn aus deiner Sicht, Ralf?

Es wundert mich nicht, dass der Begriff nicht so noch nicht so bekannt ist. Ähm. Noch nicht. Das ist richtig.

Wo kommt das her? Stefan hat gesagt, das sind so Magic Spells. Dabei eigentlich sind sie dafür da, dass ich die Magie so ein bisschen rausnehme. Und ähm das Ganze hat angefangen, dass ich ähm so auf LinkedIn in immer geguckt habe.

Mensch, da sind so viele Leute, die die reden davon hier, dass die KI alles für sie macht und sie lassen über Nacht irgendwelches Swarms laufen und nächsten Morgen ist der Code fertig. Ich habe es nicht glauben können. Reuben Cohn war einer von denen und ich habe mir dann sein Spark Framework mal angeguckt, was irgendwie ein Shell Script war und dann habe ich mir das Shell Script angeguckt, habe festgestellt, das ist eigentlich kein Shell Script, sondern das ist ein parametrisierter Prompt. Dann habe ich mir den Prompt angeguckt und habe gemerkt, das Teil kann es kann ganz gut Test Driven Development.

Zuverlässig. Also habe ich geguckt in den Prompt, wo beschreibt er lang ausführlich das Test Driven Development und es war gar nichts drin. Es war nur TDD London School drin. Da habe ich mir gedacht, okay.

London School kenne ich nicht. TDD Test Driven Development, das soll ausreichen? Und dann habe ich mit Claude drüber gesprochen und Claude hat gesagt, ja ja, TDD London School kenne ich. Es gibt auch noch Chicago School.

Das ist so ähnlich wie Detroit School. Und auf einmal habe ich gemerkt, dieser Begriff hat irgendwas getriggert. Und ähm hat eben so eine so eine Wissensinsel in dem Lernwissen äh der KI getriggert. TDD selbst so Mock Test Driven Development wo er irgendwie ja.

Aber TDD London School ist halt ein Begriff, den ich vorher nicht kannte. Ist irgendwie Mock First und solche Geschichten. Und der ist so gut definiert, dass die, dass der KI das reicht, um mit diesem Begriff ordentlich gesteuert zu werden. Und dann habe ich mir gedacht, okay, gibt es noch mehr solche Wissensinseln, solche Begriffe, die etwas triggern?

Und ich habe noch mehr gefunden. Wir hatten gerade eben Arc 42, da weiß die KI schon gleich, okay, zwölf Kapitel, so und so strukturiert, funktioniert so und so. Ist schon mal ein ganz guter Trigger. Und das kann man auch noch kombinieren.

Wenn wir von Software-Architektur sprechen, dann haben wir immer wieder Architektur-Entscheidungen. Architecture Decision Records, ADRs. Ist noch kein starker Begriff, ja, Architecture Decision Record, kann ich irgendwie die Entscheidung aufschreiben. Wenn ich aber sag, Use ADRs according to Nygard oder ADRs nach Nygard, Nygard, Michael Nygard hat mal einen schönen Blogpost geschrieben, so schreibe ich ADRs.

Die KI weiß, okay, jetzt weiß ich genau, wie ich es mache. Und dann mache ich es ganz gerne, dass ich eine Entscheidungsmatrix in den ADR reinbringe, um eben ähm ja, eine Übersicht über die Optionen zu haben. Und da habe ich in meiner Six Sigma Zeit äh Prozessoptimierung gelernt, dass es eine Pugh-Matrix gibt. Und das ist auch wieder ein sehr wohldefinierter Begriff.

Kann ich noch verfeinern, 3-Punkt-Pugh-Matrix. So. Jetzt habe ich drei Anker genannt, Arc 42, ADR nach Nygard und 3-Punkt-Pugh-Matrix. Und wenn ich diese Anker jetzt vereinige und sage, schreibe mir eine Architektur-Dokumentation im Arc 42 Template mit ADRs nach Neigart und für jeden ADR eine 3.

Puma Matrix. Dann habe ich in einem Satz mit wenigen Worten ganz genau beschrieben, wie diese Architektur aussehen soll. Weil ich da mehrere Wissensinseln getriggert habe. Und das ist das ist powerful.

Das ist das, was Stefan Schmidt als Magic Spells bezeichnet hat, ne? Der, der sie kennt, kann sie nutzen gegenüber der KI. Und wow, auf einmal gerade bei dem Test-Driven Development. Ich sag immer, wenn ich das so manuell aufbaue, wenn ich der KI Test-Driven Development beibringen will, dann sage ich meistens der KI, du schreib mir mal einen Prompt für ein LLM, dass das LLM Test-Driven Development macht.

Ich habe es mal gemacht, 150 Zeilen Beschreibung. Kann ich ersetzen durch TDD London School. Und auf einmal 150 Zeilen Prompt sind nicht mehr maintainable. Die kann ich nicht verwalten.

Ich weiß nicht, wie ich ihn da zu was anderem bringe. Aber TDD London School oder Arc 42, wo ich schon über Neigart und Puma Matrix das Ganze modifiziert habe, das ist auf einmal etwas, was maintainable ist, wo ich auch erkenne in den Prompts, was passiert und warum. Weil eben Arc 42 und Neigart und Puma Matrix das genauso definiert, deswegen verhält er sich so. Und das ist eigentlich die Magie dahinter.

Und das ist das, wo Claude sagt, ja, das nennt man eigentlich Semantic Anchors, semantische Anker, Anker im Wissensgebiet. Mhm. Alles super spannend. Ich muss ehrlich sagen, ich habe auch 100 % also A verstanden jetzt, was es im Detail ist.

Also danke dir dafür. Ich verstehe ehrlich gesagt auch warum Stefan gesagt hat, Magic Spells. Ähm. Äh, wie wie wie ähm Also ich nehme an, komme auch gleich noch drauf.

Wir haben noch nicht alle entdeckt. Wie stabil sind denn die? Weil so Modelle ändern sich ja. Ähm Habt ihr eine Idee?

Also fallen da mal Sachen weg? Kommen da Sachen dazu? Ich würde jetzt im ersten Moment denken, das ist wahrscheinlich relativ stabil, weil die Basis da drunter ja eher sich nicht so stark ändert, aber habt ihr da irgendwelche Erkenntnisse? Hast du da irgendwelche Erkenntnisse?

Das sind ja eigentlich Fachbegriffe. Und ähm als Fachbegriffe sind sie eigentlich in den Trainingsdaten stabil drin. Vieles davon steht einfach in der Wikipedia. Aber die Frage kam immer wieder auf.

Ja, wenn ich jetzt in einem Modell so einen Anker gefunden habe, bedeutet das auch, dass das in dem anderen Modell funktioniert? Wahrscheinlich doch nicht. Ich habe immer gesagt, doch doch, wird wahrscheinlich funktionieren, weil es ja einfach Fachbegriffe sind. Und ähm ich habe mir tatsächlich mal die Zeit genommen, zusammen mit Claude, dass wir Evaluations geschrieben haben.

Wir haben für die LLMs Multiple-Choice-Tests gebaut. Ich glaube, es sind irgendwie 190 oder so geworden. Und die haben wir tatsächlich mehreren LLMs vorgesetzt. Wenn man auf der Website ist, unten rechts im Footer sind die Evaluations.

Und die Foundation Modelle, die verstehen die Begriffe alle gleich gut. Und erst wenn man in die ganz kleinen Modelle reingeht oder lokale Modelle, dann merkt man auf einmal, da gibt's Probleme. Dass irgendwas nicht ganz genau verstanden ist. Und das ist auch klar, weil nicht jedes Modell ist halt in dieser Tiefe trainiert.

Die großen Modelle schon, aber gerade wenn ich jetzt spezialisierte Modelle hätte oder eben kleine, dann nicht. Ich kann dann aber mit diesen Evaluations notfalls quasi dem Modell einen Spickzettel mitgeben. Das wenn ich erkenne, okay, das ist z.B. das Product Requirements Document, das PRD, das ist so ein so ein Anker, der ist nicht so stark.

Der versagt manchmal bei den Modellen. Dann kann ich ihm das aber eben als Spickzettel mitgeben. Im System Prompt und dann würde es funktionieren, wenn ich so ein z.B. ein lokales Modell nutzen würde.

Verstanden. Ja, das wäre auch eine meiner anderen Fragen gewesen. Das ist eine ist halt Modelle entwickeln sich vorwärts. Nicht alle Modelle sind gleich groß, ne?

Das halt das wird dann zusammengedrückt. Kannst ja auch quant quantisieren, ne? Quantizieren, danke dir. Ich würde quantifizieren, quantisieren.

Okay, verstanden. Wenn ich jetzt ich habe jetzt nicht wirklich das eins zu eins durchgezählt, aber würde sagen nördlich der 50 Enkers, also quasi Schlagworte, Fachworte, habt ihr. Quasi gibt's so, also Gibt's Also, wie sucht ihr da nach neuen drinne? Also, das 50 wird ja nicht das Ende gewesen sein.

Keine Ahnung, wenn wir uns in einem halben Jahr treffen, ob es dann 100 sind, wo es halt abebbt. Also, habt ihr da eine Strategie, um das rauszufinden und um das auch zu validieren? tatsächlich bei 131 momentan. Und ähm Ach, du.

Es gut geschätzt, Mensch. Es fällt halt auch immer wieder auf, wenn man irgendwelche Begrifflichkeiten hat, die irgendwie was triggern. Ähm ein so ein Beispiel war ähm Sota. Ähm wo wo wo mir jemand auf LinkedIn gesagt hat, Sota ist doch sicher auch so ein Begriff.

Ähm Learn it Sota hat irgendwer immer wieder verwendet. Und da habe ich mir überlegt, was was was soll das jetzt bedeuten? Sota State of the Art. Und wenn ich dem Modell sage, mach dich mal über, keine Ahnung, Microservice Sota schlau.

Dann weiß das LLM, okay, ich muss jetzt hier aktuelle Informationen ziehen, ja? Und und dann merkt man auf einmal, das könnte ein Anker sein. Faszinierend an den Ankern ist, finde ich so ein bisschen. Man könnte jetzt sagen, es sind ja eigentlich einfach Fachbegriffe.

Alle, jeder Fachbegriff ist ein Anker. Aber. Die Fachbegriffe sind unterschiedlich stark. Also wir hatten es jetzt zum Beispiel bei dem ADR, das ADR nach Neigart stärker ist.

Und. Viele Fachbegriffe. Sind halt auch. Unbekannt.

Eigentlich wie Magic Spells, ne? Also jetzt TDD Land School. Die meisten, die ich so treffe, die sagen, nee, was soll das sein? Ja?

Ähm. Aber auf eben Sota Mesi Puma Tricks, ja? Aber wenn ich auf einmal merke, das ist ein ein Magic Spell, ein Zauberwort für die KI. Dann kann ich es doch auch einsetzen.

Und dann lerne ich das. Und im Gegensatz zu, wenn ich mich jetzt mit. Mit einem Experten unterhalte. Ähm.

Dann ist es trotzdem meistens so, dass ich diese Fachbegriffe. Oft gar nicht so verwende. Weil ich jetzt dann doch nicht weiß. Ist jetzt so was wie Arc 42 Aski Doc.

Ähm bekannt oder muss ich es noch mal ausholen und erklären? Bei diesen Ankern weiß ich, die KI, die LLMs kennen es. Ich kann diese Begriffe verwenden und sie zünden im Wissen des KIs ein Feuerwerk. Gibt es dann ein zu viel?

Ähm also quasi, wenn ich in einem Prompt halt irgendwie. Zehn Ankers rein packe, also quasi verliert sich, also gibt es dann einen. Äh quasi einen. Wie soll ich sagen, also einen Tipping Point, wo sich es dann wieder umkehrt, die Nützlichkeit?

Also ich könnte mir vorstellen, dass es ähm. Widersprechende Anker gibt. Ähm, wenn ich die dann verwenden würde, dann wäre es bisschen blöd. Ähm, wobei ich glaube, ein Überlagern funktioniert ganz gut, denn Arc 42 hat z.B.

auch Architekturentscheidung, hat sie nicht ganz so ähm stark definiert wie Neigart und wenn ich dann sag, mach die ADRs nach Neigart, dann ist das so ein so ein Überlagern. Ein zuviel des Guten habe ich noch nicht kennengelernt. Aber ich ich entdecke immer wieder Anker, die mich wirklich erfreuen. Ich sehe z.B.

gerade auf dem Bildschirm gutes Deutsch nach Wolf Schneider. Wow, also, wenn ihr wollt, dass die KI so schreibt, dass nicht aussieht wie KI, dann sagt ihr, schreib. Entsprechend dem guten Deutsch nach Wolf Schneider, der hat irgendwie so eine Style Bibel mal aufgelegt oder im Englischen Plain English according to Strunk and White. Wieder zwei so Begriffe, die äh ich würde jetzt mal tippen, ihr kanntet die vorher nicht.

Ich kannte sie vorher auch nicht. Aber jetzt sind sie hier in der. In der Library der Semantic Ankers und jeder kann sie nachschlagen. Ähm, vielleicht ganz kurz dazu.

Ich glaube, es macht einen Unterschied, ob du ein Mixture of Experts Model nimmst oder ein Dense Model, weil bei einem Mixture of Experts Model werden ja nur bestimmte quasi Experten aktiviert und da kann es sein, dass sozusagen ein äh im Kontext früher gebrachter Anker ähm schon oder dass mehrere die Experten schon so saturieren, dass dann ein Anker weiter hinten gar nicht mehr nützt oder dass dann bestimmte aktiviert werden und andere nicht. Ne, bei einem Dense Model sollte es wahrscheinlich aber keinen Unterschied machen, sondern. Am Ende dazu führen, hoffentlich, dass alle im Kontext landen in irgendeiner Form. Du erwischst mich gerade auf dem auf dem falschen Fuß.

Also Mixture of of Experts und Dance Model, ich bin da nicht so tief drin, dass ich da zu sagen könnte. Bei Mixture of Experts habe ich gelernt, ich habe früher immer gedacht, dass Mixture of Experts so ja, da ist ein da ist ein neuronales Netz für Physik, eins für Biologie, eins für Mathe, eins für Deutsch. Habe ich dann gelernt, ist falsch, sondern ist eher so. Na ja, der weiß, jetzt kommt ein Satzzeichen und jetzt schmeiße ich den Expert für Satzzeichen an oder sowas.

Ähm. Ich habe eben zumindest gelernt, dass bei den LLMs, die ich verwende, bei den Foundation Modellen und eben auch bei lokalen, das gut funktioniert und das eben zur Steuerung super klasse funktioniert. Und es am Ende ja, sagen wir mal, erfüllt ja gleich. Zwei wichtige Funktionen.

Das eine ist, dass es A Token spart, ne, also Kontext rot vermindert, also diesen 150 Zeilen TDD Description zusammengedampft auf TDD London School. Und zum anderen noch mal den den anderen Effekt hat, dass du genau das bekommst, was du erwartest, so ne, das also wie wie du gesagt hast, ein ADR kann man auf verschiedene Arten und Weisen schreiben, gibt es verschiedene Artikel, wie das aufgebaut sein muss. Wenn du aber sagst nach. Garten ist relativ, also nicht relativ, sondern sehr klar, wie der aufgebaut ist.

Und von daher ist es also auch für mich gerade eine coole Erkenntnis. Ich habe habe mir neulich, ich weiß gar nicht, ob ihr es kennt, aber ich habe mir neulich mal Caveman als Plugin installiert, was was also ja, sowas ähnliches macht, ne, im Prinzip auch die die Sprache so ein bisschen, sagen wir mal, runter dumpt, also viel so ähm äh Squish rausnimmt, der irgendwie Semantic Sugar ist, aber jetzt keine keine wirkliche Bedeutung hat und äh wenn man das kombiniert noch mit so einer Liste an an äh Semantic Encas, äh dann äh hat man, glaube ich, den Kontext schon mal oder zumindest den Tokenverbrauch reduziert und damit den Kontext auch ein Stück weit aufgeräumt. Das ist übrigens ein interessanter äh Stichpunkt, weil ähm jemand aus der Community, ich weiß jetzt gerade leider nicht den Namen, ähm hat tatsächlich für die Semantic Encas einen Skill gebaut, der eben den kann ich fragen, ähm du, wenn ich jetzt eine Architekturbeschreibung ähm prompten möchte, ähm welchen Anker kann ich verwenden? Und der sucht den Anker dann raus, also so bisschen Caveman-mäßig, ne?

Das ähm eben was Aufwendiges übersetzt wird in was Einfaches. Ja, ich glaube, super, super wichtig, das wäre auch eins meiner Fragen gewesen, damit einer mit einer wachsenden Menge an Encas, wie quasi quasi behält man im Hinterkopf, wann man was halt irgendwie einsetzen kann. Also gerade auch, wenn man wenn es wächst, ja, ähm und man vielleicht eben nicht das Latest Greatest gerade gehört hat. Ähm okay, aber gibt's das schon?

Schade, hätten wir bauen können, Sebastian, am Wochenende. Ihr könnt's mal testen, wie gut es ist und dann vielleicht äh verbessern, wenn da noch was zu verbessern ist. Oder vielleicht fallen euch äh semantische Anker ein. Das ist übrigens total spannend, wenn man Open Source arbeitet, also wie Arc 42 z.B.

oder ADRs nach Nygard, ähm dann kann es sehr gut sein, dass ähm dieses Wissen ein ein ein Anker bildet, also dass ich die letzten 10 Jahre Docusaurus Code Public Open Source gemacht habe, bedeutet, ähm ja, ich kann der KI einfach sagen, benutze den Docusaurus-Code-Ansatz. Ich kann aber auch sagen, benutze den Docusaurus-Code-Ansatz nach Ralf D. Müller und die KI sagt, "Ah ja, okay, dann willst du äh DocToolchain als Tooling und du willst AsciiDoc anstelle von Markdown. Ja, prima.

Ähm. Ist super. Und ähm dieses dieses komprimieren, das führt halt auch dazu, dass ich ja, ich brauche eigentlich keine Skills, weil ähm wenn ich einfach sag, schreib mir jetzt ein ADR nach Neigart. Ähm ja, ich hätte ein ADR Skill bauen können, wo noch ein ADR Template und sowas drin ist.

Aber schreib mir ein ADR nach Neigart, ähm das tippe ich einfach so aus den Fingern rein, das äh ist schon im Muskelgedächtnis drin der Finger, das rauscht einfach so über die Tastatur. Jetzt jetzt erkenne ich gerade ein Pattern. Liegt das äh liegt die Tatsache, dass da immer äh quasi mache XX äh mache XYZ nach ABC, ist das tatsächlich die Power, also dass man eben nicht einen verwaschenen Begriff nimmt, also quasi ADR, sondern ADR nach Neigart ist ja eben wiederum sehr sehr präzise. Ist das vielleicht noch quasi etwas, was diese Magie stärker werden lässt oder wirken lässt?

tatsächlich, ähm wenn man einen Fachbegriff hat, dann kann man auch noch mal eben einen Namen hinten dran hängen und dann wird es präziser. Also z.B. Microservice nach Eberhard Wolff wird auch präziser sein als einfach nur Microservices. Und das tatsächlich bei vielen ähm Ankern ist das so zu merken.

Akt 42 ist z.B. für für sich selbst ein starker Anker, da brauche ich nicht noch sagen nach ähm Starke und Ruschka. Ähm. Mhm.

Andere Sachen, ja, da setze ich das nach gutes Deutsch nach Wolf Schneider oder so noch hinten dran, damit er genau die Definition kennt und eben das Buch und Blogposts und sonst was in den Trainings äh im Trainingsdata ähm sich zieht. Jetzt mal so ein bisschen in vielleicht hat der der ein oder andere halt irgendwie Lust dazu Kontributen. Ah, wie geht denn das und B. Wohnen auch wie messten ihr Stärke?

Also wenn wir jetzt immer quasi darüber gesprochen, dass ein Wort eine gewisse Magie auslöst, was also wie lässt sich ein Magie messen? Also total klasse. Claude hat da ein ein Template gebaut, ein Issue Template, wo man neue Anker submiten kann. Das heißt, man muss nur den Anker, den man vermutet, eingeben.

Ich habe früher immer den GitHub Copilot dann drauf angesetzt und der Copilot hat dann gesagt. Nee, triggert bei mir nichts oder ja, triggert bei mir was, ja? Und hat dann eben entsprechend den den Pull Request gemacht, bis dann Claude vor zwei Wochen gesagt hat, du der Copilot, der der vergisst da immer noch die deutsche Übersetzung und dies und jenes. Lass mich das machen.

Und jetzt immer, wenn da so ein Issue aufgemacht wird für einen neuen Anker, dann setze ich Claude drauf an und der macht dann den Pull Request, überprüft, ob es ein guter Anker ist oder nicht. Und wir haben tatsächlich manche Anker auch als Gegenbeispiel. Dass wir sagen, zum Beispiel. Um.

TLDR. Wurde als Anker submitted. Ja, ist ein feststehender Begriff. Aber.

Das das triggert keine Aktion. Um. Bluff. Bottom Line Upfront.

Kannte ich vorher noch nicht. Hat die KI dann vorgeschlagen, das triggert eine Aktion. Nämlich das zusammengefasst wird mit der Bottom Line Upfront. Wow.

Damit habe ich die Zusammenfassung mein TLDR. Kann aber eben auch weiterlesen. Die Semantic Ankers, das ist das, was im Wissen vorhanden ist, im in den Trainingsdaten des LLMs. Und es einer mal auf mich zu und hat gesagt, das ist ja schön und gut.

Jetzt habe ich eigene Begriffe. Ähm, die sind in den Trainingsdaten nicht drin. Wie mache ich daraus semantische Anker? Ich habe z.B.

Arc 42 als Architekturdokumentation, aber Betriebsmanual, da kenne ich nichts, was irgendwie Open Source ist, ähm, was ich da als Begriff nehmen kann. Also habe ich wieder mit Cloud gequatscht und Cloud hat gemeint, ja, ähm, ist ja kein Problem. Wir können ja in so einem System Prompt oder in einem anderen File, in einem Agents MD, Begriffe definieren. Mhm.

Und wie könnten wir das nennen? Ja, das könnten wir Semantic Contracts nennen. Also, eine ein ein Contract, ein Vertrag zwischen mir und dem LLM. Wenn ich sage Betriebshandbuch, dann meine ich Folgendes.

Geht so ein bisschen in die Richtung von Skills. Und äh auch das gibt es auf der auf der Website und das wird jetzt dann total spannend, weil auf der Website ist z.B. Das sind so semantische Contracts wie Spezifikation. Spezifikation, ja, wieder ungenau.

Wenn ich aber sage, when we talk about a specification or spec, we mean use cases with main flow, alternative flows, activity diagrams for all flows, acceptance criteria in Gherkin format. Ja, Activity Diagramme ist ein Trigger, Use Cases ist ein leichter Trigger, Gherkin ist ein starker Trigger. Ja? Dann fasse ich auf einmal so so Trigger zusammen und kann eben auch sagen, du, wenn wir über Architekturdokumentation sprechen, dann meinen wir immer Arc 42 mit ADRs nach Neigard und 3.

Q Matrix. Und das ist dann so eine Definition, die nehme ich jetzt immer ganz gerne, wenn ich ein neues Projekt starte und auf der Website kann man sich diese Contracts zusammenklicken und sagen so, das alles rüberkopieren, dann kopiere ich mir das rüber in meine Agents MD und benutze es dann in meinem Workflow. Das ist so wie ich dann die nächste Komponente, die aus dem Ganzen entstanden ist, ähm ein Workflow, mit dem ich Agenty Coding mache und diese Agenty Coding nur aus kleinen Prompts aufbaue, weil diese kleinen Prompts halt aus semantischen Ankern bestehen. Und damit kommt man verdammt weit, also das ist quasi meine ähm Dark Factory, wo ich mit der KI am Anfang nur über meine Requirements spreche, ähm die KI baut mir dann die Spec, baut mir dann die 41 Dokumentation.

Da gucke ich dann noch mal drüber, das ist so mein Dashboard, wo ich sehe, macht die KI das so, wie ich will. Die KI weiß schon, ADRs werden mit mir durchgesprochen. Und dann wird aus der Spec werden die Epics und die Stories generiert und dann fängt die KI an umzusetzen. Und wow, das funktioniert klasse.

Wie wie lang ist denn so ein Dark Factory Run sozusagen deines Agenten mit diesem Flow, den du erreichst? Also momentan steuere ich noch relativ viel, dass ich immer sag so, was ist das nächste Issue, zeig mir die mal und ja, mach das und dies und jenes. Ähm ich hatte aber auch schon Runs, ein Run war 2 Stunden 40. Ähm ich habe da so eine Phase, wo ich zum Schluss sag, ja, okay, alle Tests sind grün, aber jetzt nimmst du mal dieses Tool bans CLI Tool und teste es.

Teste es ausführlich manuell. Und versuch über Edge Cases Fehler zu finden. Und dann findet der tatsächlich 12 Issues. Erstellt die als GitHub Issues, macht eine Analyse.

Und dann sage ich ihm, ja, und jetzt fix du bitte die 12 Issues. Und dann hat er eben da schon mal zwei Stunden 40 dran gearbeitet, kam dann wieder und hat gesagt, so, das passt jetzt aber. Und das Das ist dann so ein so ein Punkt. Mittlerweile vertraue ich ihm, dass die Tests eben ähm passen, weil er die Tests vorher schreibt und ich hatte mal so eine Phase, wo ich gemerkt habe, er hatte acht grüne Tests, vier rote Tests und er hat sich im Kreis gedreht.

Er hat die die roten Tests nicht grün gekriegt. Ich habe ihn gestoppt, habe gesagt, du du musst jetzt irgendwie anders vorgehen, dass du das Verhältnis zwischen grünen und roten Tests verbesserst. Hat er gesagt, ja, danke für den Hinweis, hat zwei rote Tests gelöscht und hat gemeint, jetzt ist das Verhältnis besser. Und das ist halt mit Instruction Following und eben Ankern, die dir der Trick, dass man da dann vielleicht doch in die richtige Richtung geht.

Ja. Gut, hat ja deine Instruction befolgt, ne? Und hat dann das Verhältnis verbessert. war dann so ein Beispiel, dass ich mich unklar ausgedrückt habe, ne?

Und mit den Ankern drücke ich mich klarer aus. Und man muss auch dazu sagen, mit der Dark Factory, ich habe so ein so ein White Coding Risk Radar. Auch wieder Dark Factory, ich habe den Code nie gesehen, aber ist total praktisch, weil ich kann da einstellen, wie ja, was was mein Code ist, auf was für Daten er zugreift, welche Sprache ich verwendet habe, typisiert oder weniger typisiert, kann ich irgendwie mit Pointern Probleme kriegen und so. Und dann fängt er an.

Das zu bewerten. Kriegt halt eine Risikokategorie raus. Und er hat so schöne Beispiele genommen. Also, wenn ich jetzt eine Product Landing Page habe, ja, also, wenn die gut aussieht, dann brauche ich mir den Sourcecode nicht anzugucken.

Wenn ich jetzt aber Firmware für medizinische Hardware habe, dann sollte ich da noch mal drüber gucken, ja. Und dementsprechend nimmt er diese Risikokategorie. Und spuckt dann vier Level aus. Und hat dann auch Mitigations.

Dass er sagt, im Level eins, na ja, du solltest einen Linter haben und du solltest automatisch kompilieren und dies und jenes. Kategorie zwei hat er dann, glaube ich, schon einen AI Review. Human Review kommt erst in Kategorie drei rein. Und da habe ich tatsächlich auch einen Skill entwickeln lassen von Claude.

Der das unterstützt. Das heißt, ich kann jetzt einen Claude Skill laden, um eine Risikoanalyse zu machen. Der geht über den Code drüber, bespricht mit mir die verschiedenen, die ähm. Fünf Dimensionen des Radars.

Und erzeugt dann einen ADR. Diesen ADR kann man dann natürlich mit seinen Security Menschen durchsprechen. Geht ihr mit? Und anschließend setzt Claude tatsächlich oder die gewählte KI die Mitigations um.

Und hey, seitdem ich das habe, habe ich auf einmal Pre Commit Hooks und so was, was ich vorher nie in meinen Open Source Projekten drin hatte. Und Lighthouse Tests, ja, die Websites, die erstellt werden, sind auf einmal performant und ähm. Ja, accessible, wo ich früher bei Open Source nicht drauf geachtet habe. Und ähm, ist äh tatsächlich dann so ein so ein Tool, wo ich dann eben auch entscheiden kann, mache ich jetzt Dark Factory?

Ähm, muss ich mir den Sourcecode angucken oder nicht? Super spannend, das auch noch mal im Kontext deiner Arbeit zu verstehen. Ähm, glaube jetzt, da wird mir auch noch mal klar, also mir war schon war schon vorher klar, was ein bisschen wie die Magie ist, aber das noch mal so an konkreten Beispielen zu hören, äh hilft noch mal mehr, das einzuordnen. Ich bin gespannt, wie viel äh Magic Spells oder Semantic Ankers nach dem Podcast dazu kommen.

Ist ja doch relativ leicht, was einzureichen. Ich habe vorhin übrigens, also jetzt zu kurz zu ruhig war, habe ich überlegt, was ich einreichen will. Ähm, nur so im Kopf die Sachen mal so durchgegangen, ja. Mal gucken.

Sehr gut. Ja. Ich das glaube, The Meat haben wir damit, also den Hauptgang, ne? Es ist ja, wenn man das wie ein äh Menü äh betrachtet, dann haben wir den Hauptgang jetzt hinter uns gebracht.

Kommen wir langsam zum Dessert. Ähm, genau. Und äh Dessert bei uns äh ist so ein Segment, wo wir mal fragen, also, da geht es um Reality Check, ne? Hast du auch ab und zu so What the Momente, wo du dir denkst so, wir sind so weit, aber diese Kleinigkeit, die klappt jetzt nicht.

Gab es da zuletzt sowas? Also, ich habe beim Bild ge- Bild generieren immer wieder solche Effekte. Beim Bild generieren, da ähm findet man leichter so weiße Flecken in der Landkarte des Wissens, ne? Ähm, ich habe z.B.

ähm mal ein altes Radio mit Radiobuttons generieren lassen wollen. Er weiß, was Radiobuttons sind, aber also, in HTML und irgendwo, ja, aber auf einem Radio kennt er keine Radiobuttons. Oder ein kleinen Teleprompter auf dem Schreibtisch kriegt er auch nicht hin. Einen großen Teleprompter, ja, das kriegt er hin.

Aber einen kleinen Teleprompter und da da bin ich immer wieder erstaunt und da merke ich auch bei meinen LinkedIn Posts, wo da irgendwelche Grenzen sind, wo ich dann merke, okay, hier brauche ich nicht weiter den Prompt zu verfeinern, er kriegt es halt einfach nicht hin bzw. Claude macht das ja für mich, also ich schreibe ja auch nicht die Bildprompts, sondern das macht ja Claude. Aber auch umgekehrt, diese diese Wow-Effekte, ja, die die wo ich eigentlich irgendwo schon früh gedacht habe, okay, das das war jetzt cool, aber jetzt ist es normal und ähm da kommt nichts mehr, ja. Ich habe irgendwie, würde ich sagen, fast jede Woche wieder so Wow-Effekte, ähm wo ich sag, Mensch, das ist aber cool, was die KI da kann.

Und was war so so ein Beispiel zuletzt, was du hattest? Also, es gibt eigentlich ich habe es ständig, ja. Äh und wenn ich z.B. mein Bildgenerator, ähm wie die KI selbstständig sich zurechtfindet, die APIs sich anguckt und eben dann auch auf die Idee gekommen ist, dass ich arbeite viel mit Referenzbildern und die Referenzbilder, ja, sie funktionieren einigermaßen, wenn man ein Bild direkt generieren lassen will, aber die KI hat dann schon gemerkt, nee, nee, also es ist besser, wenn erst mal ein generisches Bild generiert wird und dann über die Edit API mit den Referenzbildern gearbeitet wird, ja.

Und das sind so Sachen, wo ich sag, jo, das das hätte mich verdammt lange Zeit gekostet, um da selbst draufzukommen und so macht es die KI quasi im Dark Factory Mode. Zeigt mir immer mal wieder Bilder und ich sag, A ist besser als B und wow, diese diese Eigenständigkeit und wie die KI sich mittlerweile selbst zu helfen weiß, finde ich klasse. Wobei einmal fand ich es auch total witzig, da hatte ich der KI gesagt, sie soll mir eine Linkliste von der Webseite ziehen. Und das war noch mein mein eigener Chatbot und da war ein Fehler, der hat es nicht geschafft über über so ein fetch die Seiten zu ziehen, also ist er irgendwie auf die Besch gegangen, hat es mit curl probiert, hat es auch nicht hingekriegt und man kennt das ja so, dass die KI ebenso immer, wenn der eine Weg nicht funktioniert, sie einen anderen Weg nimmt.

Und ich erinnere mich noch ganz genau daran, wie die KI mit den Tools gescheitert ist und zum Schluss gesagt hat, ich schaffe es nicht, aber du hast doch einen Browser vor dir, kannst du bitte auf die Webseite gehen und Steuerung A, Steuerung C und dann hier bei mir Steuerung V rein. Das fand ich schon, ja, der User als Tool Fallback. Sehr gut. Rent the Human.

Genau. Ja, cool. Dann vielleicht noch als letzter Punkt, hast du irgendeine Prediction, die du mit unseren Hörern teilen möchtest? Also, ich habe einen ganzen Talk, wo ich Predictions mache.

Und viele dieser Predictions sind schon eingetreten oder gerade nicht eingetreten. Und eine der Predictions war so, na ja, die die Komplexität der Software, die von KI erzeugt wird, ne? Ich habe mir so gedacht, na ja, momentan erzeugt die KI Software mit einer Komplexität, da können wir den Code reviewen. Und wir sollten ihn ja auch reviewen, zumindest hat man es damals gesagt.

Und ich habe mir überlegt, was passiert, wenn die KI immer besser wird und die Komplexität des Codes steigt, dass sie über unseren kognitiven Fähigkeiten ist und wir das gar nicht mehr reviewen können. Und es ist anders gekommen, wir haben es alle gemerkt, es es ist nicht, dass die Komplexität steigt, sondern einfach die Menge an Code, die von KI generiert wird. Wenn die KI in fünf Minuten Code erzeugt, wo ich fünf Stunden brauche, um ein Review zu machen, dann hat die KI in den fünf Stunden schon wieder so viel Code erzeugt, ich kann diese Reviews gar nicht mehr machen. Und deswegen ist meine Prediction, dass wir halt in diese Richtung Dark Factory gehen müssen und wir müssen eben in diese Richtung gehen, dass wir der KI vertrauen können, keine Reviews mehr machen müssen.

Und da fand ich einen Vortrag von Ingo Eichhorst super spannend, der eben die KI mit Shannons Theorem verglichen hat, Shannon mit einem Noisy Channel, ich bringe Fehlerkorrektur drauf und kann den Kanal somit ja fehlerfreier gestalten. Und wenn ich das LLM als fehlerbehafteten Kanal ansehe, nicht deterministisch, dann kann ich eben auch für mit Fehlerkorrekturen, z.B. den Compilerlauf, eben den Determinismus reinbringen und damit ja, das Vertrauen stärken. Aber ich glaube, das wäre dann für eine andere Folge.

Definitiv, das haben wir ja schon paar Mal gesagt, als ich gesagt habe, gefühlt bei jedem Gast, wir müssen uns noch mal in paar Monaten wieder treffen, wiedersehen, dann quasi noch mal schauen, wo wir stehen oder anderes Thema besprechen. Mit Stefan haben wir das ja schon gemacht, insofern glaube, würde uns freuen, Ralf, wenn du noch mal wiederkommst und wir das wiederholen. Du hast ein super wichtiges Thema angesprochen, haben Sebastian und ich schon noch neulich mal diskutiert, Dark Factories, das werden wir sicherlich in einer der nächsten Folgen mal besprechen, mal gucken, ob allein oder ob wir dann noch irgendjemanden finden, mit dem wir das halt irgendwie diskutieren können. Auf jeden Fall vielen vielen Dank.

Ja, wie gesagt noch mal danke für die Einladung. Hat Spaß gemacht. Jederzeit gerne wieder. Der HMZ E Podcast ist ein gemeinsames Projekt von Sebastian Heidemeier zu Erpen und Andre 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, z.B. wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an Vielen Dank für deine Zeit. Wenn es dir gefallen hat, abonniere den Podcast.

Bis zur nächsten Folge.