# Semantic Anchors: Optimizing LLM Output with Precision Prompting

**Podcast:** HMZE
**Published:** 2026-04-18

## Transcript

Ich habe ihn gestoppt, habe gesagt, du musst jetzt irgendwie anders vorgehen, dass du das Verhältnis zwischen grünen und roten Tests verbessern.
Hat er gesagt, ja, danke für den Hinweis, had zwei rote Tests gelöscht und had gemeint, jetzt ist das Verhältnis besser.
Herzlich willkommen zu einer weiteren Episode unserer neuen Staffel von HMZE Beyond Vibecoding, der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin Sebastian Heidemeyer zu Erbten, CTO bei NorthIO.
Und ich bin André Neubauer, CTPO 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 ermöglichen, sehr präzise Ergebnisse basiert 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 Vibecoding.
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.
Danke.
Also erstmal danke für die Einladung.
Ralf D.
Müller, ich bin irgendwie seit zehn Jahren auf Konferenzbühnen, weil es einfach Spaß macht und beschäftige mich seit ungefähr zehn Jahren mit Architekturdokumentation.
Akt 42, da bin ich der dritte Mann hinter Gernot Starke und Peter Ruschka, derjenigen, der sich so ein bisschen um die Technik kümmert.
Und Ende 2023 bin ich zu dem Thema Genial 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 sehen im Kontext.
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.
Ich sehe Architekturdokumentation tatsächlich wenig in den Prozessen, so in dem Spec-Driven Development, ist aber total wichtig.
Habe ich gerade vorhin wieder ein Post abgelassen, weil ohne die Architektur weiß das LLM gar nicht so recht, naja, es wird was machen, ja, aber es wählt dann selbst die Architektur.
Und das sollte man nicht aus der Hand geben.
Und deswegen, wenn man es verstanden hat, dann merkt man, dass die Architektur wichtiger ist als vorher.
Weil früher im Team hat man sich so, ich sage immer, am Lagerfeuer ausgetauscht.
Wie machen wir das?
Gehen wir links oder rechts.
Das passt mit der KI nicht mehr so, weil die ist am Lagerfeuer nicht mit dabei.
Sondern die braucht es im Kontext.
Und dafür, ja, MD-Files machen Sinn.
Ich benutze ganz gern ASCII Doc.
Einfach aus dem Grund, ASCII Doc ist ein technisches Dokumentationsformat, eigentlich genauso leicht wie Markdown, aber es gibt zum Beispiel das Diagramm Makro.
Und wenn ich ASCII Doc verwende, dann kennt das die KI und kann gleich Diagramme schreiben.
Und AC42 ist halt das Template, ich glaube, wir haben es mittlerweile in zwölf Sprachen verfügbar, 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 sagt ACT42, dann weiß es ganz genau, zwölf Kapitel die und die Struktur.
Das ist natürlich ein unheimlicher Vorteil, wenn das nichts, ja, vielleicht ist es sogar was Proprietäres, aber was Bekanntes ist.
Schon mal das erste Nugget für mich mitgenommen, mir das ASCII-Doc anzuschauen.
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 es.
Ich würde sagen, in der Wikipedia sind so ungefähr 60 Dialekte aufgeführt.
Bei ASCII Doc gibt es nur einen.
Und das heißt, das Tooling, das passt immer, weil es immer der gleiche Source ist.
Ist halt präzise damit, ne?
Absolut.
Perfekt.
Ich glaube, wir haben ja, 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 denn dein aktueller Text-Stack oder Tool-Stack, experimentierst du viel und so weiter und so fort.
Also vielleicht kannst du da uns mal so ein Einblick geben, was so deine tägliche AI-Kostet.
Also experimentieren auf jeden Fall.
Und ich bin als Technology Evangelist unterwegs.
Das heißt, ich erkläre Leuten die Technologie, 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 zum Beispiel 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 Quicksort verwendet habe oder sowas, warum ich DOD-Datenbank verwendet habe, das warum ist heutzutage echt ein größeres Problem.
Und wenn wir vom Text-Stack reden, ist das total faszinierend, dass der eigentlich jetzt egal geworden ist.
Hauptsache die KI kann gut damit umgehen.
Und gerade heute habe ich mich wieder mit der KI drüber unterhalten, wie man den Loop hinbekommt 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, 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, für das Problem haben wir hier mit Python die besseren Libraries als mit Go.
Go wäre zwar typisierter und 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 eben so, dass ich als Java-Entwickler das verstehe.
Und damit ist der Technologie-Stack für mich relativ in den Hintergrund geraten.
Verrückt.
Ja, mach mal, Sebastian.
Mit Text-Stack, also die Frage hat auch eher den Hintergedanken, welcher KI-Tex-Text-Stack sozusagen.
Also ist es eher Cloud Code, ist es Codex, ist es Anti-Gravity oder nutzt du Cursor?
Und wie, ja, also welche wichtigsten Tools nutzt du so?
Hast du irgendwie bestimmte Skills oder Plugins, die dich extrem weitergebracht haben?
Der Text-Stack.
Okay.
Also ich benutze Cloud Code schon ziemlich lange.
Ich benutze auch Kiro und jeweils eben mit den Cloud-Modellen, wobei man mittlerweile auch ein bisschen hört, dass Cloud so ein bisschen, naja, verheizt jetzt mehr Tokens und wird teilweise schwieriger.
Ich bin mit Cloud noch ziemlich zufrieden.
Und ich benutze, ja, wenn ich Tools benutze, dann eben auf der CLI.
Also ich setze meinen Cursor nicht mehr in irgendeinen Editorfenster.
Deswegen selbst sowas wie Visual Studio Code für einen 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 ja, damit ist quasi eigentlich nur noch Modell und Harness.
Und was so Skills und Agenten angeht, ich versuche mit dem Modell den Agenc Flow durchzugehen.
Und das Agentic, ich musste da erstmal lernen als Non-Native Speaker.
Agentic hört sich für den Deutschen jetzt immer so an wie Agenten.
Und im Englischen heißt es eben auch eigenständig.
Und wenn einem das bewusst geworden ist, ja, mein Cloud Code arbeitet eigenständig.
Und wenn Cloud Code meint, es müsste noch irgendwie was an Agenten abgeben oder so, dann kannst du das machen.
Aber das war auch total faszinierend, weil ich schon ziemlich früh, 2023, als ich meinen eigenes Chat-System 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 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, zum Beispiel für einen Code Review.
Und ja, eigentlich war das damals schon ein moderner Agent.
Ich wusste es damals noch nicht.
Aber es hat funktioniert, war cool.
Und es ist eben auch cool, wenn man eben die Technologie mal so 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 Skills und Subagents und sonst was, finde ich, ein bisschen im Hintergrund.
Ich habe so vier Punkte, wo ich sage, ein Agent macht Sinn, das ist, wenn ich zu wenig Kontext habe, wenn ich Kontext auslagern möchte, wenn ich Geschwindigkeit brauche, also Parallelität.
Wenn ich Fokus brauche, dass eben die Aufgabe vorne im Kontext steht und nicht irgendwo weiter hinten, wo der Kontextrod schon stattgefunden hat.
Und der dritte Punkt steht auf der Folie in meinem Training.
Guter Verweis.
Wer quasi da mehr sehen, mehr hören will von dir, der kann einen Training buchen.
Findet man, glaube ich, per LinkedIn, wenn man nicht, wenn ich es richtig in den Norm habe.
Dann haben wir das auch untergebracht.
Ihr habt schon ein paar Nuggets für mich mitgenommen.
Ich finde auch, ich glaube, das haben wir noch nie besprochen, Sebastian hier, aber diese Fehlinterpreter oder diese erste Reaktion, Agentic ist ein Agent.
Das höre ich immer wieder.
Oder also diese Wahrnehmung auch, also quasi diese gefühlte falsche Übersetzung, also false Friend.
Gut, dass du das heute übernommen hast für uns, Ralf.
Ja, na doch.
Dafür bin ich da.
Nein.
Hat ja nur bis zur, weiß ich, zwölften Episode oder so.
Ja, genau.
Alles klar.
Gut, vielen Dank.
Ja, 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 nochmal total spannend gewesen.
Erinnert mich ein bisschen an den Mario Zechner, der ja auch eher sagt, mit der Pi als 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.
Und das erinnert mich ein bisschen daran.
Das mit dem Tool bauen, wenn ich da gerade nochmal aufgreifen darf, das finde ich halt auch spannend, weil wenn ich merke, dass die KI irgendwas für mich gut gemacht hat, zum Beispiel Bilder generiert, wer meine LinkedIn-Posts 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 du jetzt zweimal gut gemacht, jetzt schreib dir mal einen Skill dafür, aber schreib den selbst, ja.
Und dann weiß ich, es kommt reproduzierbar wieder, ja.
Das ist die Art und Weise, wie ich Skills verwende.
Ja, exakt.
Exakt.
Gut, dann würde ich sagen, aber Tech-Stack abgehakt und können zu The Meet übergehen.
Genau.
Der Stefan hatte ja weiß gar nicht, vor welchen, vor wie vielen Folgen das war, aber zumindest er das letzte Mal da war, hat er ja einmal so dieses Name-Dropping gemacht, Semantic Anchors.
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.
Noch nicht, genau.
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 das Ganze hat angefangen, dass ich so auf LinkedIn immer geguckt habe: Mensch, da sind so viele Leute, die reden davon hier, dass die KI alles für sie macht und sie lassen über Nacht irgendwelche Swarms laufen und nächsten Morgen ist der Code fertig.
Ich habe es nicht glauben können.
Roland Cohen war einer von denen.
Und ich habe mir dann sein Spark-Framework mal angeguckt, was irgendwie ein Shell-Skript war.
Und dann habe ich mir das Shell-Skript angeguckt, habe festgestellt, das ist eigentlich kein Shell-Skript, sondern das ist ein parametrisierter Prompt.
Dann habe ich mir den Prompt angeguckt und habe gemerkt, das Teil kann ganz gut Test-Driven Development.
Zuverlässig.
Also habe ich geguckt in dem Prompt, wo beschreibt er lang ausführlich das Test-Driven Development.
Und es war gar nichts drin.
Es war nur TDD land ein 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 hat eben so eine Wissensinsel in dem Lernwissen der KI getriggert.
TDD selbst, ja, mach ich test-driven development, or irgendwie, ja.
Aber TDD London School ist halt ein Begriff, den ich vorher nicht kannte.
Ist irgendwie Mox First und solche Geschichten.
Und der ist so gut definiert, dass der KI das reicht, um mit diesem Begriff ordentlich gesteuert zu werden.
And dann habe ich mir gedacht, okay, gibt es noch mehr solche Wissensinseln, solche Begriffe, die etwas triggern.
And ich habe noch mehr gefunden.
Wir hatten gerade eben Arkt 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 Softwarearchitektur sprechen, dann haben wir immer wieder Architekturentscheidungen.
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 NYGAD oder ADRs nach Niger.
Niger, Michael Neigart 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 eine Übersicht über die Optionen zu haben.
Und da habe ich in meiner Six-Sigma Zeit Prozessoptimierung gelernt, dass es eine Pew-Matrix gibt.
Und das ist auch wieder ein sehr wohl definierter Begriff, kann ich noch verfeinern, 3.Pew Matrix.
So, jetzt habe ich drei Anker genannt: Arc 42, ADR nach Niger und 3.Pew Matrix.
Und wenn ich diese Anker jetzt vereinige und sage, schreibe mir eine Architekturdokumentation im Arc 42 Template mit ADRs nach Niger und für jeden ADR eine 3.Pew 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 powerful.
Das ist das, was Stefan Schmidt als Magic Spells bezeichnet hat.
Der sie kennt, kann sie nutzen gegenüber der KI.
Und wow, auf einmal, gerade bei dem Test-Driven Development.
Ich sage immer, wenn ich das so manuell aufbaue, wenn ich der KI Test-driven development beibringen will, dann sage ich meistens zu der KI, du schreib mir mal ein Prompt für ein LLM, dass das LLM Test-Driven Development macht.
Ich habe es mal gemacht, 150 Zeilen Beschreibungen.
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 Nigerd und Pew 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 ARG 42 und Niger und Pew Matrix das genau so 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.
Super spannend.
Ich muss ehrlich sagen, ich habe auch 100%, also verstanden jetzt, was es im Detail ist.
Also danke dir dafür.
Ich verstehe ehrlich gesagt auch, warum Stefan gesagt hat, Magic Spells.
Also, ich nehme an, wir kommen auch gleich noch drauf, wir haben noch nicht alle entdeckt.
Wie stabil sind denn die?
Weil so Modelle ändern sich ja.
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 darunter ja eher nicht so stark ändert, aber habt ihr da irgendwelche Erkenntnisse oder hast du da irgendwelche Erkenntnisse?
Also es sind ja eigentlich Fachbegriffe.
Und 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 ein 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 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 rein geht oder lokale Modelle, dann merkt man auf einmal, da gibt es 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.
Okay, this is zum Beispiel the Product Requirements Document.
This is so anchor, der is not so stark.
Der versagt manchmal by density.
Dann kann ich ihm das aber eben als Spickzettel mitgeben im System Prompt, and then würde es funktionieren, wenn ich so ein Beispiel ein lokales Modell nutzen würde.
Verstanden.
Ja, das wäre auch eine meiner anderen Fragen gewesen.
Das eine is halt, Modelle entwickeln sich vorwärts, nicht alle Modelle sind gleich groß.
Das hat das zusammengedrückt.
Kannst du auch quantisieren, ne?
Quantisieren, dank dir.
Ich würde quantifizieren, quantisieren.
Okay, verstanden.
Ich habe jetzt nicht wirklich das 1 zu 1 durchgezählt, but ich würde sagen, nördlich der 50 Enkers, also quasi Schlagworte, Fachworte, habt ihr.
Quasi gibt es so, also wie sucht ihr danach neuen drin?
Also, das 50 wird ja nicht das Ende gewesen sein.
Keine Ahnung, wenn wir uns mit einem halben Jahr treffen, ob es dann 100 sind, wo es halt up-app.
Also, habt ihr dann eine Strategie, um das herauszufinden und um das auch zu validieren?
Also, wir sind tatsächlich bei 131 momentan.
Und es ist gut geschätzt, Mensch.
Es fällt halt auch immer wieder auf, wenn man irgendwelche Begrifflichkeiten hat, die irgendwie was triggern.
Ein, so ein Beispiel war Sota, wo mir jemand auf LinkedIn gesagt hat, Sota ist doch sicher auch so ein Begriff.
Learn it Sota hat irgendwer immer wieder verwendet.
Und da habe ich mir überlegt, was soll das jetzt bedeuten?
So, 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.
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, dass ADR nach Niger stärker ist.
Und viele Fachbegriffe sind halt auch unbekannt.
Eigentlich wie Magic Spells.
Also jetzt TDD London School, die meisten, die ich so treffe, die sagen, nee, was soll das sein?
Aber auch eben Sota, Messi, Pew-Matrix.
Aber wenn ich auf einmal merke, das ist 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 einem Experten unterhalte, dann ist es trotzdem meistens so, dass ich diese Fachbegriffe oft gar nicht so verwende.
Weil ich jetzt dann doch nicht weiß, ist jetzt sowas wie ARC 42, ASCII-Doc bekannt oder muss ich es nochmal 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.
Es dann ein zu viel.
Also quasi wenn ich in einem Prompt halt irgendwie zehn Anchors reinpacke, also quasi verliert sich, also gibt es dann ein quasi ein, wie soll ich sagen, also ein Tipping Point, wo sich es dann wieder umkehrt, die Nützlichkeit?
Also ich könnte mir vorstellen, dass es widersprechende Anker gibt.
Wenn ich die dann verwenden würde, dann wäre es ein bisschen blöd.
Wobei, ich glaube, ein Überlagern funktioniert ganz gut.
Denn ARG42 hat zum Beispiel auch Architekturentscheidungen, hat sie nicht ganz so stark definiert wie Niggaard.
Und wenn ich dann sage, macht die ADAs nach Niger, dann ist das so ein Überlagern.
Ein zu viel des Guten habe ich noch nicht kennengelernt.
Aber ich entdecke immer wieder Anker, die mich wirklich erfreuen.
Ich sehe zum Beispiel gerade auf dem Bildschirm gutes Deutsch nach Wolf Schneider.
Wow.
Also wenn ihr wollt, dass die KI so schreibt, dass es 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 ich würde jetzt mal tippen, ihr könntet die vorher nicht.
Ich kannte sie vorher auch nicht.
Aber jetzt sind sie hier in der Library der Semantic Anchors und jeder kann sie nachschlagen.
Vielleicht ganz kurz dazu, ich glaube, es macht einen Unterschied, ob du ein Mixture of Experts Model nimmst oder ein Dance-Model.
Weil bei einem Mixture of Experts Model werden ja nur bestimmte quasi Experten aktiviert und da kann es sein, dass sozusagen ein Kontext früher gebrachter Anker schon, oder das wäre die Experten schon so saturiert, dass dann ein Anker weiter hinten gar nicht mehr nützt oder dass dann bestimmte aktiviert werden und andere nicht.
Bei einem Dance-Model sollte es wahrscheinlich aber kein Unterschied machen, sondern am Ende dazu führen, hoffentlich, dass alle im Kontext landen in irgendeiner Form.
Wir erwischen mich gerade auf den falschen Fuß.
Also Mixture of Experts and Dance Model, ich bin da nicht so tief drin, dass ich da was zu sagen könnte.
Beim 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, naja, der weiß, jetzt kommt ein Satzzeichen und jetzt schmeiße ich den Expert für Satzzeichen an oder sowas.
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 SR-Tokens spart, also Kontext Rod vermindert, also diesen 150 Zeilen TDD-Description zusammengedampft auf TDD London School.
Und zum anderen nochmal den anderen Effekt hat, dass du genau das bekommst, was du erwartest.
Also, 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 Nigat, dann ist relativ, also nicht relativ, sondern sehr klar, wie der aufgebaut ist.
Und von daher ist es auch für mich gerade eine coole Erkenntnis.
Ich habe mir neulich, ich weiß gar nicht, ob ihr es kennt, aber ich habe mir neulich mal Caveman als Plugin installiert, was wahrscheinlich sowas ähnliches macht.
Im Prinzip auch die Sprache so ein bisschen, sagen wir mal, runterdunkt, also viel so Squish rausnimmt, der irgendwie Semantic Sugar ist, aber jetzt keine wirkliche Bedeutung hat.
Und wenn man das kombiniert noch mit so einer Liste an Semantic Anchors, dann hat man, glaube ich, den Kontext schon mal, oder zumindest den Token-Verbrauch reduziert und damit den Kontext auch ein Stück weit aufgerollt.
Das ist übrigens ein interessanter Stichpunkt, weil jemand aus der Community, ich weiß jetzt gerade leider nicht den Namen, hat tatsächlich für die Semantic Anchors einen Skill gebaut, der eben, den kann ich fragen, du, wenn ich jetzt eine Architekturbeschreibung prompten möchte, welchen Anker kann ich verwenden?
Und der sucht den Anker dann raus.
Also so ein bisschen Caveman-mäßig, dass eben was Aufwendiges übersetzt wird in was Einfaches.
Ich glaube, super, super wichtig, es wäre auch eins meiner Fragen gewesen, mit einer größten, mit einer wachsenden Menge an Anchors, wie quasi quasi Behälter im Hinterkopf, wann man was halt irgendwie einsetzen kann.
Also gerade auch wenn man, wenn es wächst, ja, und man vielleicht eben nicht das Latest Greatest gerade gehört hat.
Okay, aber gibt es das schon.
Schade, hätten wir bauen können, Sebastian am Wochenende.
Ihr könnt es mal testen, wie gut es ist und dann vielleicht verbessern, wenn da noch was zu verbessern ist.
Oder vielleicht fallen euch semantische Anker ein.
Das ist übrigens total spannend, wenn man Open Source arbeitet, also wie ARC42 zum Beispiel oder ADAs nach Niger, dann kann es sehr gut sein, dass dieses Wissen ein Anker bildet.
Also, dass ich die letzten zehn Jahre Doxis Code Public Open Source gemacht habe, bedeutet, ja, ich kann der KI einfach sagen, benutze den Doxis-Code-Ansatz.
Ich kann aber auch sagen, benutze den Doxis-Code-Ansatz nach Ralf D.
Müller und die KI sagt, ah ja, okay, dann willst du Doc Tool Chain als Tooling und du willst ASCII-Dock anstelle von Markdown?
Ja, prima.
Super.
Und dieses Komprimieren, das führt halt auch dazu, dass ich, ja, ich brauche eigentlich keine Skills.
Weil wenn ich einfach sag, schreib mir jetzt ein ADA nach Nigered, ja, ich hätte ein ADR-Skill bauen können, wo noch ein ADR-Template und sowas drin ist.
Aber schreibt man ein ADR nach Nigerd, das tippe ich einfach so aus den Fingern rein.
Das ist schon im Muskelgedächtnis drin, der Finger, das rauscht einfach so über die Tastatur.
Jetzt erkenne ich gerade den Pattern.
Liegt das, liegt die Tatsache, dass da immer quasi mache XX, mache XYZ nach ABC.
Ist das tatsächlich die Power?
Also, also dass man eben nicht einen verwaschenen Begriff nimmt, also quasi ADR, sondern ADR nach Neigart ist ja dann wiederum sehr, sehr präzise.
Ist das vielleicht noch quasi etwas, was diese Magie stärker werden lässt oder wirken lässt?
Das ist tatsächlich, wenn man einen Fachbegriff hat, dann kann man auch nochmal eben einen Namen hintendranhängen und dann wird es präziser.
Also zum Beispiel Microservices nach Eberhard Wolf wird auch präziser sein als einfach nur Microservices.
Und das ist tatsächlich bei vielen Ankern ist das so zu merken, Act42 ist zum Beispiel für sich selbst ein starker Anker.
Da brauche ich nicht noch sagen, nach Starke und Ruschka.
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, im Trainingsdata sich zieht.
Jetzt mal so ein bisschen in, vielleicht hat ja der ein oder andere halt irgendwie Lust dazu contributen.
A, wie geht denn das?
Und B, auch wie messen ihr Stärke?
Also wir haben 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 Template gebaut, ein Issue-Template, wo man neue Anker submitten 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 Pull Requests gemacht, bis dann Claude vor zwei Wochen gesagt hat, du, der Copilot, 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 TLDR wurde als Anker submitted.
Ja, ist ein feststehender Begriff, aber das triggert keine Aktion.
Bluff, Bottom Line up front.
Kannte ich vorher noch nicht.
Hat die KI dann vorgeschlagen, das triggert eine Aktion.
Nämlich, dass es zusammengefasst wird mit der Bottomline up front.
Wow.
Damit habe ich die Zusammenfassung, mein TLDR, kann aber eben auch weiterlesen.
Die Semantic Anchors, das ist das, was im Wissen vorhanden ist.
In den Trainingsdaten des LLMs.
Und es kam einer mal auf mich zu und hat gesagt, das ist ja schön und gut, jetzt habe ich eigene Begriffe.
Die sind in den Trainingsdaten nicht drin.
Wie mache ich daraus semantische Anker?
Ich habe zum Beispiel ARC 42 als Architekturdokumentation.
Aber Betriebsmanual, da kenne ich nichts, was irgendwie Open Source ist, was ich da als Begriff nehmen kann.
Also habe ich wieder mit Claude gequatscht und Claude hat gemeint, ja, ist ja kein Problem.
Wir können ja in so einem System Prompt oder in einem anderen File, in einem Agents MD, Begriffe definieren.
Und wie könnten wir das nennen?
Ja, das könnten wir Semantic Contracts nennen.
Also 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 auch das gibt es auf der Website und das wird jetzt dann total spannend, weil auf der Website ist zum Beispiel, das sind so semantische Contracts wie Spezifikation.
Spezifikation, ja, wieder ungenau.
When 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.
Activity Diagramme is a trigger, use cases is a leichter trigger.
GORKIN is ein starker Trigger.
Dann fasse ich auf einmal so Trigger zusammen und kann eben auch sagen, du, wenn wir über Architekturdokumentation sprechen, dann meinen wir immer ARC42 mit ADRs nach Nigert und 3.pew 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 anders rüber kopieren, dann kopiere ich mir das rüber in meine Agents MD und benutze es dann in meinem Workflow.
Das ist dann die nächste Komponente, die aus dem Ganzen entstanden ist.
Ein Workflow, mit dem ich agentic Coding mache und diese Agentic 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 Dark Factory, wo ich mit der KI am Anfang nur über meine Requirements spreche.
Die KI baut mir dann die Spec, baut mir dann die ARC 42 Dokumentation.
Da gucke ich dann nochmal 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 SPAC die EPICs und die Storys generiert und dann fängt die KI an, umzusetzen.
Und wow, das funktioniert klasse.
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 sage, so was ist das nächste Issue, zeig mir die mal und ja, mach das und dies und jenes.
Ich hatte aber auch schon Runs, ein Run war 2 Stunden 40.
Ich habe da so eine Phase, wo ich zum Schluss sage, ja, okay, alle Tests sind grün, aber jetzt nimmst du mal dieses Tool, warnt CLI-Tool und teste es.
Teste es ausführlich manuell und versuche über Edge Cases Fehler zu finden.
Und dann findet er tatsächlich zwölf Issues, erstellt die als GitHub-Issues, macht eine Analyse, und dann sage ich ihm, ja, und jetzt fixe bitte die zwölf 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 ist dann so ein Punkt.
Mittlerweile vertraue ich ihm, dass die Tests eben 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 roten Tests nicht grün gekriegt.
Ich habe ihn gestoppt, hab 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 halt mit Instruction Following und eben Ankern, die den Trick, dass man da dann vielleicht doch in die richtige Richtung geht.
Ja.
Na gut, hat ja deine Instruction befolgt, ne?
Und hat dann das Verhältnis verbessert.
Aber das war dann so ein Beispiel, dass ich mich unklar ausgedrückt habe.
Und mit den Ankern drücke ich mich klarer aus.
Und man muss auch dazu sagen, mit der Dark Factory, ich habe so ein Wipecoding Risk-Radar.
Auch wieder Dark Factory.
Ich habe den Code nie gesehen, aber it's total praktisch.
Weil ich kann da einstellen, wie mein Code ist, auf was für Daten er zugreift, welche Sprache ich verwendet habe, typisiert oder weniger typisiert, kann ich irgendwie mit Pointern Problemen kriegen und so.
Und dann fängt er an, das zu bewerten.
Kriegt er halt eine Risk-Kategorie 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 Source Code nicht anzugucken.
Wenn ich jetzt aber Firmware für medizinische Hardware habe, dann sollte ich da nochmal drüber gucken.
Und dementsprechend nimmt er diese Risikokategorien und spuckt dann vier Level aus und hat dann auch Mitigations.
Dass er sagt im Level 1, naja, du solltest einen Linter haben und du solltest automatisch kompilieren und dies und jenes.
Kategorie 2 hat er dann, glaube ich, schon einen AI-Revie.
Human Review kommt erst in Kategorie 3 rein.
Und da habe ich tatsächlich auch ein 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 fünf Dimensionen des Radars.
Und erzeugt dann ein 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 sowas, was ich vorher nie in meinen Open Source-Projekten drinnen hatte.
Und Lighthouse-Tests, ja, die Websites, die erstellt werden, sind auf einmal performant und ja accessible, wo ich früher bei Open Source nicht drauf geachtet habe.
Und das ist tatsächlich dann so ein so ein Tool, wo ich dann eben auch entscheiden kann, mache ich jetzt Dark Factory?
Muss ich mir den Source Code angucken oder nicht?
Super spannend, das auch nochmal im Kontext deiner Arbeit zu verstehen.
Ich glaube, jetzt, da wird mir auch nochmal klar, also war schon vorher klar, was ein bisschen wie die Magie ist, aber das nochmal so an konkreten Beispielen zu hören, hilft nochmal mehr, das einzuordnen.
Ich bin gespannt, wie viele Magic Spells oder Semantic Anchors nach dem Podcast dazukommen.
Ist ja doch relativ leicht, was einzureichen.
Ich habe vorhin übrigens, also jetzt zu kurz ruhig war, habe ich überlegt, was ich einreichen will.
Kopf die Sachen mal so durchgegangen.
Mal gucken.
Sehr gut.
Ja, ich glaube, The Meat haben wir damit, also den Hauptgang.
Das ist ja, wenn man das wie ein Menü betrachtet, dann haben wir den Hauptgang jetzt hinter uns gebracht.
Kommen wir langsam zum Dessert.
Genau.
Und Dessert bei uns 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 Fuck-Momente, wo du dir denkst, so, wir sind so weit, aber diese Kleidigkeit, die klappt jetzt nicht.
Gab's da zuletzt sowas?
Also, ich habe beim Bildgenerieren immer wieder solche Effekte.
Beim Bildgenerieren, da findet man leichter so weiße Flecken in der Landkarte des Wissens.
Ich habe zum Beispiel mal ein altes Radio mit Radio-Buttons generieren lassen wollen.
Er weiß, was Radio-Buttons sind, aber also in HTML und irgendwo, ja, aber auf einem Radio kennt er keine Radio-Buttons.
Oder einen kleinen Teleprompter auf dem Schreibtisch, kriegt er auch nicht hin.
Ein großen Teleprompter, ja, das kriegt er hin.
Aber einen kleinen Teleprompter, und 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.
Beziehungsweise, Claude macht das ja für mich.
Also ich schreibe ja auch nicht die Bildpromp, sondern das macht ja Claude.
Aber auch umgekehrt, diese Wow-Effekte, ja, wo ich eigentlich irgendwo schon früh gedacht habe, okay, das war jetzt cool, aber jetzt ist das normal und da kommt nichts mehr, ja.
Ich habe irgendwie, würde ich sagen, fast jede Woche wieder so Wow-Effekte, wo ich sage, Mensch, das ist aber cool, was die KI da kann.
Und was war so ein Beispiel zuletzt, was du hattest?
Also, es gibt eigentlich, ich habe es ständig, ja.
Und wenn ich zum Beispiel mein Bildgenerator, 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 erstmal ein generisches Bild generiert wird und dann über die Edit-API mit den Referenzbildern gearbeitet wird.
Und das sind so Sachen, wo ich sage, yo, das hätte mich verdammt lange Zeit gekostet, um da selbst drauf zu kommen.
Und so macht es die KI quasi im Dark Factory-Mode.
Zeigt mir immer mal wieder Bilder und ich sage, A ist besser als B und wow, 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 einer Webseite ziehen.
Und das war noch mein eigener Chatbot.
Und da war ein Fehler.
Der hat es nicht geschafft, über so ein Fetch die Seiten zu ziehen.
Also ist er irgendwie auf die Bash gegangen, hat es mit Curl probiert, hat es auch nicht hingekriegt.
Und man kennt das ja so, dass die KI eben so 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 schaff's nicht, aber du hast doch ein Browser vor dir.
Kannst du bitte auf die Website gehen und STRG A, STRG C und dann hier bei mir STRG V rein.
Das fand ich schon, ja, der User als Tool fallback.
Rent the human.
Genau.
Dann vielleicht noch als letzter Punkt, hast du irgendeine Prediction, die du mit unseren Hörern teilen möchte.
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, naja, die Komplexität der Software, die von KI erzeugt wird.
Ich habe mir so gedacht, naja, 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 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 einen 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 eine Fehlerkorrektur drauf und kann den Kanal somit fehlerfreier gestalten.
Und wenn ich das LLM als fehlerbehafteten Kanal ansehe, nicht deterministisch, dann kann ich eben auch mit Fehlerkorrekturen, zum Beispiel dem Compilerlauf, eben den Determinismus reinbringen und damit das Vertrauen stärken.
Aber ich glaube, das wäre dann für eine andere Folge.
Definitiv, das haben wir ja schon ein paar Mal gesagt.
Ehrlich gesagt, ich glaube, gefühlt bei jedem Gast, wir müssen uns nochmal ein paar Monaten wieder treffen, wo Wiedersehen, dann quasi nochmal schauen, wo wir stehen oder anderes Thema besprechen.
Mit Stefan haben wir das ja schon gemacht, insofern, ich glaube, würde uns freuen, Ralf, wenn du nochmal 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 da noch irgendjemanden finden, mit dem wir das halt irgendwie diskutieren können.
Auf jeden Fall vielen, vielen Dank.
Ja, wie gesagt, nochmal danke für die Einladung.
Hat Spaß gemacht.
Jederzeit gerne wieder.
Der HMZE Podcast ist ein gemeinsames Projekt von Sebastian Heidemeyer 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 checken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.