bist. Die Zeit nehmen wir uns natürlich. bist. Wir starten auch mit dir mit der klassischen Beyond-Code-Frage. Wann hast du denn eigentlich das letzte Mal Code geschrieben und was für ein Code war das?

Ja, das ist schwierig zu sagen. Also ehrlich gesagt, ich erinnere mich gar nicht mehr dran, wann ich selbst Code geschrieben habe. Ich lasse ja jetzt Code schreiben. Ich setze nicht mehr den Cursor in die IDE, in den Editor, sondern ich gebe nur noch Claude meine Anweisungen oder einen anderen KI. Und das ist total faszinierend. ich habe jetzt ein paar Tage Urlaub gehabt und habe meinen Home Assistant aufsetzen lassen. Und die KI hat das alles für mich gemacht. Also ich

weiß gar nicht, was man da konfigurieren kann oder sonst was. Claude hat das alles gemacht und von daher, ich selbst schreibe keinen Code mehr und das ist tatsächlich jetzt schon etwas länger her. Ende 2023 habe ich noch mein eigenes Chat-System gebaut, die KI näher kennenzulernen und irgendwann hat es dann aufgehört, dass ich selbst Code schreibe.

heißt, du schaust dir noch den Code an und schreibst nicht mehr oder ist selbst komplett hands-off bei dir.

Also ich habe es geschafft, dass ich komplett hands-off arbeite, dass ich den Code noch nicht mal mir anschaue. Ich schaue mir die Architektur an, die die KI entwirft. Das ist für mich mein Dashboard, zu sehen, dass die richtigen Komponenten drin sind. Manchmal beim, ja, wenn Probleme auftreten oder so, dann unterhalte ich mich mit der KI quasi wie Architekt zu Architekt.

dass man vielleicht doch eine andere Entscheidung treffen sollte oder so. Aber direkt den Code, da verlasse ich mich tatsächlich auf andere Mechanismen.

Sehr spannend. Der entscheidende Punkt bei Home Automation ist für mich immer der Woman Acceptance Factor, weil sehr viele Leute optimieren das sehr. Der Wind steht hier, die Sonne steht da, Rollladen gehen runter, Licht geht an, alles durch automatisiert und dann sitzt die Frau dann und Schatz, hier ist ein bisschen dunkel, kannst du es nicht mal schnell heller machen? Und dann explodiert das ganze System. Wie hast du mit KI genau das Thema ausgehebelt, dass du jederzeit auch in der Lage bist, auf die Requests

Deine Liebsten zu hören.

Das ist tatsächlich in der Architektur für mein Home Assistant System das erste Qualitätskriterium, der Women Acceptance Factor. Claude versteht das, weiß, was zu tun ist und eine Entscheidung war zum Beispiel, dass Claude über einen zweiten Raspberry Pi eine Sprachausgabe realisiert hat. Das der Hans Olo, haben wir ihn genannt. der sagt dann eben, so Ansagen wie

Jetzt könnte mal die Markise ausfahren zur Verschattung.

Ist das Open Source? Kann man das irgendwie sich anschauen?

Die Config ist hier privat, aber der Rest ist, also das ist ja alles nur zusammengesteckt, das sind ja alles irgendwelche Komponenten. Das sind so Sachen wie, ich bin durch den Ikea geschlendert und da gab es für 5 Euro einen Bluetooth-Lautsprecher. 5 Euro, nehme ich mal mit, ja. Und so auf der Heimfahrt habe ich mir schon überlegt, was machst du denn jetzt damit, Und als ich dann zu Hause war,

Da habe ich dann Claude gesagt, du, ich habe hier einen Bluetooth-Lautsprecher, einen, ich weiß gar nicht, wie der heißt, also ich habe den Namen genannt und der ist gerade im Pairing-Modus. Kannst du den irgendwie an den Raspberry Pi connecten? Dann hat er losgelegt, hat gesagt, ja, hier habe ich einen Lautsprecher gefunden und jetzt installiere ich mal hier Text to Speech und guck mal, hat er was gesagt? Und ja, es kam was raus, kam Blechern raus. Dann habe ich gesagt,

Können wir das ein bisschen moderner machen? Ja, hier gibt es noch eine neue Library. Was für eine Stimme möchtest du haben? Und schon war der Lautsprecher angebunden. Fand ich ziemlich cool. Was ich nicht so cool fand, war, dass Claude ab dem Zeitpunkt auch die Alexa bedienen konnte. ja, sollte ich Claude nicht zu direkt sagen, was Claude damit machen kann.

seitdem kommen die Pakete in hoher Frequenz bei dir zu Hause an. Sehr schön.

Noch nicht.

Ralf, wir haben im Podcast ein anderes Format noch und zwar bringe ich eine Frage mit von der folgenden Folge und das interessante ist, der Folge Gast wusste nicht, wem er die Frage stellen wird und das war Adam Seligmann. Wir haben dort mit dem Titel The Crucial Balance Between AI Engines, Autonomy

Control.

Also wir haben so bisschen über Governance gesprochen, wie man Agenten kontrollieren soll, wie man den Zugang beschränkt im CPU-Protokolle. Super spannend. Und seine Frage an dich ist, wie weit sind wir von einem Agenten entfernt, der deine Rechnungen bezahlt mit echten Zugriff auf dein Bankkonto? Würdest du das zulassen? Wie weit bist du davon entfernt?

Also ich habe tatsächlich mit Claude mal darüber gesprochen, ob er sich nicht irgendwie was überlegen kann, wie er meine Rechnungen zahlen kann, wie er irgendwie Geld verdienen kann. Aber ich glaube, das ist ein anderes Thema. Hier geht es ja, glaube ich, den Zugriff auf das Bankkonto. Und diesen Zugriff, ich finde es spannend, weil ich setze meine KI immer nicht so auf, dass sie Zugriff auf meine Accounts sondern dass sie eigene Accounts hat. Und das ist total klasse, weil ich dann eben

tatsächlich sehe, was habe ich gemacht, was hat die KI gemacht, wo hat die KI irgendwie Code verändert, wo habe ich Code verändert. Am Anfang war das noch spannend, jetzt macht nur noch die KI alles, also das war dann nicht notwendig, sage ich mal. Aber so würde ich eben auch mit irgendwelchen Accounts umgehen. Und ich könnte mir schon jetzt vorstellen, der KI so ein Taschengeld zu geben. Also jetzt mit dem Home Assistant System.

Da haben wir ständig irgendwelche Ideen, was wir noch machen können. Da hat mich die KI für eine Bluetooth nach MQTT Bridge gefragt, hast du einen ESP32 rumhängen? Dann schließ den mal hier an den Raspberry Pi an und dann flash ich den. Da könnte ja eigentlich die KI den auch notfalls bestellen. Welchen brauchst du? Und also ich traue der KI das schon zu, dass sie mit einem eigenen Account umgehen kann, aber ich habe

überall eben meine Guardrails, dass die KI nicht ganz so uneingeschränkt zugreifen kann. Also ich bin froh, dass ich meinen Flatrate-Account habe. Da, wo ich irgendwelche APIs nutze, da habe ich den Prepaid-Mechanismus, dass irgendwann halt das Geld für die API aufgebraucht ist und ich bewusst die Entscheidung treffen muss, nachzuladen.

Das heißt klare Limits setzen und den Zugriff ermöglichen, aber Grenzen für den Agenten vorzugeben, die er nicht überschreien kann. Prepaid Karten oder ein Sitekonto, was kein Limit hat zum Überziehen. Damit würdest du dich wohlfühlen.

Genau, also momentan ja klare Limits, aber das Vertrauen steigt ja immer weiter. Und das ist schon irgendwie krass, wie man der Maschine vertraut über die Zeit. Und da sehe ich

auch, dass die Schere auseinandergeht. Es gibt sehr, sehr vorsichtige Leute und es gibt Leute, die sagen, die KI macht das alles für mich und natürlich lasst die auf mein System drauf.

Wie

sieht das bei dir persönlich aus? du so ein Sandboxing die Agenten auch, die zu isolieren oder laufen die bei

fiese

Frage, weil da muss ich zugeben, dass ich tatsächlich wenig Sandboxing habe. Aber es kommt ein bisschen drauf an. Also ich mag das, wenn die KI in der Cloud läuft. Ich mag das, wenn ich zum Beispiel einen GitHub Workspace aufmache und da die KI laufen lasse, weil ich dann weiß, da kann überhaupt nichts passieren. Aber ich habe dann tatsächlich doch auch auf meinem privaten Gerät einiges

Ja, im Chat-Modus, im Assistant-Modus, doch ganz gut ohne Sandbox am Laufen. Die KI hat einen Raspberry Pi, auf den sie zugreifen darf, den sie konfigurieren darf. Über den Raspberry Pi kann sie mir Mikrocontroller flashen. Und sie hat da schon ganz schön viele Freiheiten. Aber die hat sie sich auch langsam verdient, indem sie Vertrauen aufgebaut hat. Und ich hoffe, dass das Vertrauen nie verletzt wird.

Also

ich muss halt auch zu dieser Frage muss ich auch sagen, ich hätte ganz gerne gute Sandbox, aber die meisten Sandboxes halten nicht. Es gibt Wege raus und selbst es gibt so viele Dinge, an die man überhaupt nicht denkt. Sobald das System Zugriff aufs Internet hat.

kann es auf irgendwelche Webseiten drauf gehen, wo es rausschleusen kann oder selbst wenn ich da versuche, das irgendwie einzuschränken, dann habe ich auf einmal nicht die Programmierarbeit, aber die Arbeit das Ganze zu pflegen. Und wenn da einer eine coole Lösung hätte, die wirklich gut funktioniert, das wäre der Hammer.

Also

hier Aufruf an die Community. Wenn ihr coole Sandboxen kennt, die Ralf das Leben vereinfachten, gerne bitte in die Kommentare reinschreiben. Vielleicht findet sich hier was, was uns wirklich weiterbringt.

Vielleicht

gerade dazu noch ein Beispiel, wenn ich dich gerade nochmal

unterbrechen darf. So was wie Zugriff auf E-Mails. Lesender Zugriff ist das eine, aber dann möchte man ja auch, dass die KI einem irgendwie antworten kann. Und da finde ich so spannend, dass es eigentlich gar nicht darum geht, ob die KI E-Mails schreiben darf, sondern es geht darum, wem darf sie E-Mails schreiben. Mir kann sie all meine Daten schicken, so ungefähr. Aber nicht irgendwie

in die Welt raus und diese Einschränkung, diese Guardrail aufzusetzen, dass eben die Berechtigung nicht auf der Funktion liegt, sondern auf dem Blast Radius, auf den Empfängern. Das habe ich halt nirgendswo bislang gesehen.

Ja, so eine spannende Diskussion hatten wir in letzten Episode. Da war es dann so, dass man gesagt hat, ... die E-Mail wird vorbereitet ... und dann gibt es noch mal so einen Human in the Loop, wo man sagt, absenden, ... ja oder nein, ... und es wird der Empfänger bewertet. Also wenn der Empfänger jetzt ein CEO ist ... und da wichtige Businessgeschäfte hinter sind, dann ist das eine hochkritische E-Mail. Die darf zum Beispiel nicht ... verschickt werden von der KI ... und wenn es irgendwie so ein Newsletter ist ... oder sonst irgendwas, ... ... ist das eine Sache, wo man eventuell auch ... einen Auto-Approve machen kann. Und alles was wichtig ist, ...

muss dann jemand wirklich sagen, hier bitte raussenden. Das könnte ein spannender Ansatz sein, dass man einfach satt in Hand des Empfängers ein Risikoprofil auswerten und dann dementsprechend entweder nochmal vorlegen oder ganz anders noch damit verfahren. Wie siehst du das?

Ja und

ich bin da meistens noch so einen Schritt davor. Ich gebe es ja zu, meine LinkedIn Posts sind mit der KI vorbereitet. Und da macht die KI zum Beispiel für mich immer eine lokale Website auf, wo dann eben der Text noch mal in der Text-Area drin steht mit einem Share-Button. Die Bilder drunter, da ich sie einfach rüber ziehe und dadurch habe ich dann eben noch mal so eine Hürde, dass die KI nicht direkt

auf das System, auf LinkedIn drauf geht, sondern der Human-Inns-Loop. Auch wenn ich den Human-Inns-Loop gar nicht so gern mag, dem Fall macht es Sinn.

Ja, kommt aufs Risikoprofil an. Also wenn es irgendwie für dich super wichtig ist, dass es, bevor es in die Öffentlichkeit geht, dass du nochmal draufschaust, warum nicht? Und das kommt dann zu deinem Vertrauensthema dazu, ist sozusagen Trust but Verify. Bei wichtigen Sachen

Ja.

dann einfach doch nochmal eine Interaktion mit einbauen. Ja, die Themen rund KI bewegen sich ja unheimlich schnell. Du bist wissensechnisch sehr weit vorne. Wie bleibst du am Ball? Wie schaffst du das, diese ganzen...

Informationen

für dich einzusortieren. Was für Tipps hast du, auf was sollte man achten, wo sollte man drauf schauen, was kann man ignorieren? Wie gehst du damit

Das

ist eine verdammt schwierige Frage und ich weiß nicht, ob ich eine gute Antwort darauf habe. Was ich gemerkt habe, ist, dass tiefes Verständnis hilft, dass wie funktioniert es, warum funktioniert es etwas. Das hat mir zum Beispiel in der Phase, wo ständig neue IDE Plugins rauskamen, geholfen, weil man weiß, die

Ja, die kochen auch alle nur mit Wasser. Da ist ein LLM drin, das kriegt Input rein und gibt Output raus, Token rein, Token raus. Und das ist eigentlich überall das Gleiche. Das heißt, die Teile unterscheiden sich nur von den Promts. da konnte ich dann über viele Sachen einfach hinweg sehen, wo ich sage, nee, interessiert mich nicht, weil die erklären mir jetzt gerade nicht, dass sie irgendwas tolles Neues haben, sondern

Die sagen nur sie sind besser, aber ohne Begründung. Und dann brauche ich da keinen Blick drauf zu werfen. Was ich viel mache ist, dass ich selbst ausprobiere und dass ich mir auch von der KI viel erklären lasse. Und das ist echt, finde ich, der Hammer. Es ist jetzt gar nicht so lange her, dass ich da so einen Prompt aufgebaut habe, der

entstammt eigentlich einem Post, das Entrophic das so macht, die KI anweist, einem durch Fragen etwas zu erklären. Den Prompt habe ich für mich verbessert. Und das funktioniert total klasse, dass man hat irgendein Thema, man will tiefer einsteigen und die KI stellt erst mal ein paar Fragen, zu gucken, wo man eigentlich steht, wo sie einen abholen muss.

und stellt dann eben genau die richtigen Fragen, die richtigen Aspekte zu erarbeiten. Und es entsteht dadurch ein tiefes Verständnis. Das hilft mir weitaus mehr, wenn ich mir irgendwelche Artikel oder Posts durchlese. Wenn ich Artikel oder Posts oder Videos habe oder so, wo ich sage, das scheint interessant zu sein. Aber gerade bei Videos ist ja dann

viel Geplänkel, wo man sagt, ja, komm mal zum Punkt. Und ich muss zugeben, ich nehme diese YouTube Links, gebe die Claude, sag, zieh mal die Transcription raus und fass mir das zusammen, sag mir, was für mich neu drin ist, weil Claude kennt mich mittlerweile. Also meine eine Session, die ist zwar ständig compactet worden, aber die läuft seit Anfang des Jahres.

und da weiß Claude, was für mich da neu ist und was nicht. Und das hilft mir halt, dieses eine vom anderen zu unterscheiden.

Ja, das ist diese Gedanke, dass man durch KI lernen kann, dass man jetzt nicht einfach alles blind sich schreiben lassen oder gerenen lässt, sondern dass man das nutzt als eine Art Tutor oder Lehrer. Wenn man jetzt schaut, es gibt ja immer so die zwei Lage, die einen sagen, dass die Models werden so viel besser und die Models sind das Wichtigste und alles, jetzt hier passiert, ist im nächsten Generation der Model wieder hinfällig.

und dann gibt es andere Lager, die Models sind egal, der Harness ist das Wichtige, also wie der Prompt aufbereitet wird, das Tool ist das Wichtige. Kannst du deine Position beziehen, bist in dem Lager, die Funktionalitäten der Models auszuschöpfen? Also zum Beispiel der Boris Cherny der Entwickler von Claude Code, sagt, du sollst alle paar Monate deine

Claude

MD und diese ganzen Steeringfiles alle löschen und sollst einfach mal gucken, was es neu geht bei den Modellen, weil du brauchst dann gar nicht mehr so viel, die Modelle werden besser. Und andere Leute sagen natürlich, hey, der Harnes ist das Entscheidende.

Der hat gut reden.

Also Boris Cherny hat ja als Entwickler von Claude Code den Vorteil, er kann seine Claude MD kurz halten, indem er einfach die Sachen in den Systemprompt reinschreibt und somit das System verbessert. Oder eben auch allgemein das System verbessert, dass er das Zeugs nicht mehr in der Claude MD drin braucht. Das Ganze ist, finde ich, ein zweischneidiges Schwert. Ich habe so das Gefühl, dass

sehr, sehr viele Leute bei uns in der Branche eben versuchen, das Agents coding richtig hinzubekommen. Da gehöre ich natürlich auch dazu, hab da meine Spielwiese, meinen Ansatz und viele Leute schaffen es mittlerweile durchzukommen mit dem Agents coding. läuft und dann klopfen sie sich selbst auf die Schulter, sagen, jo, ich hab's geschafft. Und dabei merken sie gar nicht, dass tatsächlich die Modelle und der Harnes, den sie

so out of the box verwenden, einiges besser geworden ist, sodass man das ganze drum herum gar nicht mehr braucht. Das ist die eine Seite, die ich sehe. Und die andere Seite sehe ich aber auch, dass wenn wir mit schwächeren Modellen arbeiten wollen, mit lokalen Modellen, was immer dringender wird, ja.

dann sind das nicht die starken Modelle, die schon alles drinnen haben, sondern dann brauche ich wieder ein Harnes, dann brauche ich wieder irgendwie Loop Engineering und Graph Engineering und sonst was, damit ich eben einen starken Harnes aufbaue, das schwache Modell zu führen. Und das ist, glaube ich, eine ziemlich große Herausforderung, weil einfach nur

mit einem starken Modell ein Chat-System, einen Assistenten zu bauen, das geht super einfach. Das habe ich Ende 2023 selbst gemerkt. Das war, man muss ihm einfach die Freiheit lassen und er arbeitet eigenständig. Und das finde ich auch übrigens spannend, weil das Wort agentic, wir im Deutschen sagen immer Ja, das ist mit Agenten. aber es hat im Englischen eigentlich auch noch diese Bedeutung von Eigenständigkeit.

die mag ich viel mehr, dass das System eigenständig arbeitet. das ist so dieses, wenn ich einen Assistenten habe, dann ist es halt der Unterschied, ob der Assistent sagt, guck mal, hier ist Code, führ den mal bitte aus. Oder ob der Agent selbst sagt, so, ich habe jetzt Code geschrieben, ich habe den ausgeführt, da war ein Fehler drin und jetzt habe ich es nochmal korrigiert. Das ist das Eigenständige. Das ist das, was wir haben wollen.

Diese Unterscheidung ist für mich immer wichtig.

habe jetzt rausgehört, dass der Harn ist auf jeden Fall wichtig ist und flexibel von Modell zu Modell zu wechseln, eventuell auch lokale Modelle zu bedienen, aber sich trotzdem zu hinterfragen, wenn es neue Modelle gibt, die Funktionalitäten quasi der Modelle dann auch zu nutzen, alles Steering, Dokumente und Prompts kleiner zu halten, mehr Platz für den Kontext zu haben. Gehst du damit?

Ja,

also mit den Fähigkeiten der Modelle, da frage ich mich auch teilweise, was sind tatsächlich Fähigkeiten in den Gewichten der Modelle und was sind vorgeschaltete Fähigkeiten? Ich bin auf der Seite nicht so tief drin, ich bin vor allem auf der Anwenderseite. Aber als das mit den Reasoning Modellen aufkam oder diese Modelle, die eben selbst entscheiden, ob sie jetzt nur

leicht denken oder ob sie die große Engine anschmeißen. Da ist ja glaube ich eher nochmal sowas vorgeschaltet, was dann sagt, okay, jetzt nimmst du bitte das GPT-4 Mini und jetzt nimmst du bitte GPT-5. Deswegen ist ja auch der Temperaturparameter irgendwann aus der API verschwunden, weil man gesagt hat, das Modell macht das selbst. Also diese Verschiebung.

Funktionalität aus dem Harness rein in die Modelle, das ist halt auch so ein Punkt, auf den man achten muss. Also Reasoning konnte man auch mit Nicht-Reasoning-Modellen im Harness machen, indem man entsprechend Promts mitgegeben hat und solche Geschichten, aber jetzt ist es halt in den Modellen drin.

Ja,

nochmal zwei, drei Schritte zurück. Du hast so einen Nebensatz erwähnt. Loop Engineering und Graph Engineering. sind natürlich solche Buzzwords jetzt durch Social Media gehen. Kannst du erklären, was Loop Engineering ist und was Graph Engineering ist?

Das Spannende ist, finde ich, wir haben jetzt viele neue Begriffe in unserer Branche, die einfach verwendet werden und jeder nimmt die anders auf. Zum Beispiel mit dem Harness. Ist für mich immer noch unklar, ob das jetzt einfach nur quasi das Chat-System ist oder ob eben die ganzen Guardrails und alles drum herum gemeint ist.

Es wird unterschiedlich verwendet. Ähnlich wie der Begriff Agent, der total verheizt ist, weil er sehr unterschiedlich verwendet wird. Kommt immer darauf an, ist es der Engineer, ist es der Manager oder ist es der Callcenter-Leiter, für den die Person am Telefon tatsächlich der Agent ist. Das finde ich spannend. Aber du hast jetzt, jetzt bin ich abgedriftet. Genau, Loop Engineering.

Wir haben ja schon ziemlich früh gemerkt, dass dieses Eigenständige, dieses Agentech, das kann die KI ziemlich gut eigentlich selbst. Sie hat Tools, Function Calling oder jetzt MCP und schmeißt den Compiler an und wenn der Compiler eine Fehlermeldung zurückgibt, dann greift das LLM die auf und sagt, da muss ich noch mal ran. Also das ist erstmal

so ein Loop, der ganz automatisch funktioniert. Ich kann aber diese Loops auch direkt steuern. Wenn ich das LLM, den Compiler ausführen lasse, dann kommt der ganze Output irgendwo in den Chat mit rein und ich verbrenne Token. Wenn ich jetzt in dem Beispiel außerhalb des LLMs den Compiler anschmeißen würde und nur die Fehlermeldung zurückliefer.

Das könnte sparsamer sein. Das könnte eine Form von Loop Engineering sein. Aber eben auch die ganzen, ja, die ganzen Methoden, eben Guardrails am Laufen zu halten, eben diesen Development Loop irgendwo am Laufen zu halten, die Eigenständigkeit des LLMs zu fördern und auch in

ja, in starren Grenzen zu halten. Also ich hatte zum Beispiel mit einem älteren Modell das Problem, dass er Test Driven Development gemacht. Prima. Es waren irgendwie acht Tests grün und vier waren rot und er hat sich im Kreis gedreht. Er hat das Verhältnis nicht verbessert. Ich habe ihn gestoppt. Ich habe gesagt, hier, musst das Verhältnis zwischen grün und roten Tests verbessern. Er hat gesagt, danke für den Hinweis.

hat zwei rote gelöscht, hat gesagt, jetzt ist das Verhältnis besser. Und das ist jetzt so eine Eigenständigkeit, wo er aus dem korrekten Loop ausgebrochen ist. Und da hätte ich damals gesagt, na ja, okay, ich muss irgendeinen Weg finden, dass er halt in der Phase des Programmierens die Tests nicht anfasst, sondern eben so lange programmiert, bis die Tests alle rot sind. Äh, grün sind, sorry.

Das ist natürlich eine Steuerung, die ich übernehmen kann. Und das ist tatsächlich eben auch so ein Feature, was du angesprochen hast, was in die LLMs reingerutscht ist, weil ich habe das Instruction Following. Das war halt damals noch nicht so stark. Wenn ich gesagt habe, mach Test Driven Development, dann hat die KI sich gesagt, da kann ich jetzt auch mal was löschen.

Und heutzutage ist das Instruction Following halt viel stärker, dass er sich viel stärker dran hält. meine, wer sich länger mit den LLMs beschäftigt, weiß ja auch so Instructions, naja, die ersten drei, das klappt noch ganz gut. Und dann vier, fünf, da ist er abgewichen. Und jetzt ist das Instruction Following teilweise schon wieder im Weg. Also dieses Engineering, dass diese

Development Loop, der Arbeitsloop, etwas. Wie war das? Ich krieg jetzt den Deming Cycle, das glaube ich nicht perfekt hin. Was ist das?

plan, do, act, check

Genau, Plan Do Check Act.

Mhm.

Das ist halt so ein typischer Loop, den man eben auch in der Entwicklung

aufsetzen kann, wo man ihm beibringen kann, wie er planen soll, ob er jetzt einen Markdown-File anlegt oder ob er gleich ein Issue anlegt und solche Geschichten. Aber das sind halt auch Sachen, wo ich mittlerweile sage, die Unterschiede, das was ich sehe, sind gering. Der macht das einfach prima, wenn man es ihm sagt.

Ja, das ist so der generelle Ansatz dieses nicht immer ein Prompt schreiben, warten, noch ein Prompt schreiben, warten, sondern dass man in diesen Loop kommt, dass sich die KI dann vielleicht eine eigene Prompt schreibt, sich selbst zu verbessern und immer wieder darüber iteriert, bis das Ziel erreicht ist. Und das hilft uns ja auch in den Schritt zur Selbstständigkeit. Jetzt war das irgendwie vor zwei Wochen kam jetzt, ich weiß nicht, ob es spaßhalber war oder nicht, das Thema Graph Engineering,

als Darstellung. Hast du schon Zeit da mal rein zu gucken oder ist das jetzt einfach nur

Ja.

ein Hype, im Moment sich erstmal sacken lassen muss für dich?

Ich meine, vieles ist ja Hype und die Begriffe müssen sich irgendwie klären. Und das, du gerade eben so nebenbei noch angesprochen hast, ich hatte ja nur quasi den inneren Loop. Aber da ich noch einen äußeren Loop aufbaue, quasi die Instructions, den Prompt zu verbessern, ja, in diese Situation kommen die meisten Leute eigentlich gar nicht rein, weil es eben schon vorher ganz gut funktioniert. Und das Graph Engineering, so wie ich es verstanden habe, so ein

Loop ist ja auch ein zyklischer gerichteter Graph, ist also eine einfache Form und beim Graph Engineering kann ich da halt eben auch einen Graph aufbauen und ausbrechen, einen Workflow. Und mit dem Workflow Engineering oder Graph Engineering finde ich faszinierend, weil damit hat man ziemlich früh eigentlich, es ist ein eigentlich alter Hut, ja, der Begriff ist jetzt neu, hat man ziemlich früh versucht,

das Instruction Following zu verbessern. Und der Oliver Jägler hat zum Beispiel einen MCP gebaut, was einfach nur einen Workflow zur Verfügung stellt und dem LLM die Aufgabe gibt, du bringst jetzt den Workflow ans Ende. Und das LLM rafft am Anfang gar nicht, dass der Workflow Test Driven Development ist. Und der Workflow sagt dann eben im ersten Schritt, so, du schreibst jetzt bitte mal Tests und

Kommt wieder, wenn du fertig bist. Und dann kommt die nächste Aufgabe. Und was ich daran so faszinierend finde, sind die unterschiedlichen Ansätze. Also, ziemlich früh gab es schon diese starren Workflows, dass man gesagt hat, hier Schritt 1, der und der Agent wird aufgerufen, Schritt 2, der und der Agent wird aufgerufen. Und wenn man sich das dann anguckt, die meisten Schritte waren dann deterministisch und nur in manchen Schritten hätte man tatsächlich ein LLM gebraucht.

Aber total starr, da war keine Möglichkeit Claude hat mir gesagt, eigentlich wie ein Schienensystem, wenn es keinen Weg irgendwie an einem Bahnhof vorbeigeht, Bahnhof ist blockiert, dann kommst halt nicht dran vorbei. Und dieser Ansatz von Oliver Jägler, dass man einen Workflow in einem MCP hat und

dass LLM das durchspielen soll, das hat halt sowas eher von Navigationssystemen, Also ich sag dir, wo es langgeht, aber wenn du merkst, keine Ahnung, die Straße ist überschwemmt, dann kannst du vom Navi auch abweichen. Und das finde ich halt bei LLMs eben spannend, wieder die Eigenständigkeit, dass das LLM merken kann, ne, der Workflow, ist nicht so ganz mein Ding. Und dazwischen gibt es dann eben auch nochmal

Dinge, dass ich eben, ich kann rein versuchen mit Instruction Following zu arbeiten. Das war eine Zeit lang, wo man das sehr stark gemacht hat, dass man eben in die, ja, wenn man mit Agents gearbeitet hat, in die Agent Instructions reingeschrieben hat, du machst jetzt Test-Driven-Development und du machst bitte in folgenden, keine Ahnung, acht Oder man nimmt halt

ein Framework, mit dem man tatsächlich den Workflow aufbaut. Ich bin gespannt, was sich daraus ergibt, ob es tatsächlich da neue Erkenntnisse gibt. Aber ich glaube, für die meisten Anwender ist das ziemlich egal.

Ja,

das interessante ist, dass viele Beobachter auf Social Media natürlich auch gleich den Autoren unterstellt haben, dass diese Methoden natürlich extrem gut sind, wenn man maximalen Zugriff auf Tokens hat, weil sie natürlich immer wieder jede Menge Tokens verbrauchen und sehr intensiv sind. Aber auch diese Instruction sieht man ja im Spec Driven Development Ich schreibe mir erstmal runter, was ich genau machen möchte, was meine Spezifikationen sind und versuche dann nach und nach die einzelnen Themen abzuarbeiten.

Das, was du sagst, das ist halt auch wirklich so Punkt. Ingo Eichhorst hat das mal auf LinkedIn Post gehabt, wo er gesagt hat, na, gucken wir doch mal, wer sind die führenden Köpfe und wie teuer sind für die die Tokens oder wie gut haben sie Zugriff auf die Tokens? Und da ist echt eine Korrelation. Die Leute entweder weil sie sie gratis Tokens von ihrem Arbeitgeber bekommen oder weil Geld bei ihnen keine Rolle spielt.

Da entstehen dann so Systeme wie Gastown oder so, wo einfach die Tokens verheizt werden können. Und das ist natürlich ein schneller Weg, zu lernen. Und die hohe Kunst ist, wir hatten es ja vorhin, wie halte ich mich auf dem Laufenden, dass man eben solche Systeme auch mal einen Blick drauf wirft und sich überlegt, was wird da gemacht?

Ja, aber vielleicht ist es auch so ähnlich wie bei Formel 1 Sport. Da hast du ja auch mit dem Formel 1 Auto ein riesen teures Auto mit der N gleich 1 oder 2,3 maximal. Und sehr viele Technologien, im Autosport in Formel 1 irgendwie mal gestartet sind, sind jetzt in der Serie gelandet, aber in ganz anderen Preisniveau in anderen Herstellern. Aber dass man halt einfach auch diese Leute braucht, die dann mit extremen Ressourcen vielleicht experimentieren und auch ein bisschen die Grenzen verschieben.

und sich das dann hoffentlich irgendwie in dem Mainstream dann so nutzbar widerspiegeln lässt.

absolut.

Wenn

wir von den Instructions sprechen, du persönlich bist bekannt für das Thema Semantic Anchors und hast da einen Weg gefunden, wie man sehr gut verschiedene Instructions bündeln kann. vielleicht erklärst du einfach mal, was sind Semantic Anchors und warum sind sie so wichtig?

Jetzt wo du es so ansprichst und unser Gesprächsfahrt dieses, wie eignet ich mir Wissen an, das passt da eigentlich ganz gut dazu. Weil auf LinkedIn hat der Roy Van Cohn, heißt er glaube ich, immer viel über sein Framework, sein Spark Framework berichtet und dass er damit keine Ahnung wie viel Agents laufen lässt und am nächsten Morgen steht die Software. Und das war zu einem Zeitpunkt,

wo noch nicht viele Leute, eigentlich so wenig Leute, dass man das nicht glauben konnte, es geschafft haben, dass die KI eigenständig programmiert. Und ich habe mir dieses Spark-Framework mal angeguckt und hatte da einen Heidenrespekt davor. Das war irgendein Shell-Script, wo ich mir gedacht habe, was macht der da für Magie? Und das Shell-Script, das war eigentlich nur ein parametrisierter Prompt. Yo.

Parameter reingegeben, Prompt rausgekriegt und dann war es ein großer Prompt. Und ich habe ihn ausprobiert und das Teil hat sehr gut Test Driven Development gemacht. Und ich habe mir gedacht, okay, ich suche jetzt mal im Prompt die Stelle, wo er dieses Test Driven Development ganz genau beschreibt. Und da war nichts. Da war nur use TDD London School. Und ich so,

ist das alles?

Und dann habe ich mit Claude drüber gequatscht. Also du siehst, ich gucke mir etwas an und dann quatsche ich mit der KI drüber. Und die KI sagt, ich wusste nicht, was London School ist. Und die KI sagt, ja, das ist halt so ein bestimmter Ansatz und TDD London School bedeutet, du machst folgende zehn Schritte, du beachtest diese Ansätze. Und ich so, ach ja.

Und die KI so, übrigens gibt auch Detroit School. ja, und was macht das? Ja, das ist dann so und so. Ich hab's mir nicht gemerkt. Ich hab mir einfach nur gemerkt, es hilft, in der KI einfach mit TDD London School oder TDD Detroit School aus den Trainingsdaten eine ganz genaue Definition zu laden, zu invoken.

Stefan Schmidt hat so schön gesagt, das ist eigentlich wie Zaubersprüche. Wenn ich diese Zaubersprüche kenne, dann entfache ich da ein Feuerwerk.

Wenn ich so ausprobiere, der KI sagt, du schreib mir mal einen Prompt für Test Driven Development, dann kommen da so 190 Zeilen raus. 190 Zeilen, die ich halt irgendwo in meine Agents MD reinschreibe und die für jeden Request Token verheizen. Und ich kann es abkürzen, indem ich einfach sage, use TDD London School.

Das war mein

erster semantische Anker.

Ja, spannend. Das heißt, du hast vorhin so schön gesagt, Zaubersprüche, die in der KI was auslösen, die deine Abfolge an Tätigkeiten ausführen, die du gar nicht mitschicken musst im Prompt. Und das hast du gemerkt und dann hast du wahrscheinlich angefangen, Prompt zu sammeln. Was sind so deine top drei, vier sematischen Anker, die dich sehr erstaunt haben und die du immer wieder gerne benutzt?

Also es gibt ein paar Anker, die ich einfach so ganz gern benutze, wie zum Beispiel, Deutsch nach Wolf Schneider. Ich hab Wolf Schneider vorher nicht gekannt, aber er irgendwie so ein Style-Papst. Wenn ich der KI sag, ich schreib in gutem Deutsch nach Wolf Schneider, dann weiß die KI kein Passiv, kurze Sätze, einen Gedankengang pro Absatz. ja, okay. Im Englischen ist es, plain English according to Strunk and White.

habe ich dann auch mal so gelernt. Das hat mir die KI dann gesagt. Das ist so für Texte eigentlich ganz nett. Aber so mein Lieblingsanker, also wie gesagt, auf der Website heißt es, ich, One Word and the AI gets it. Und ARC42 ist so mein Grundanker, den ich als Softwarearchitekt sehr gern mag. Ich sage der KI einfach, schreibe Architekturdokumentation nach ARC42 und die KI weiß, ja,

zwölf Kapitel und weiß, was wo reinkommt. Und dann kommt gleich zum Tragen noch so ein zweites Konzept, dass ich die Anker verfeinern kann. Weil ARC42 hat zwar Architekturentscheidungen, aber das sind einfache Architekturentscheidungen, das sind keine ADRs, Architecture Decision Records. Michael Neigert hat den Begriff geprägt und hat einen Blogpost geschrieben,

wo er genau beschreibt, was in so einem Architecture Decision Record drin sein soll. Also sage ich der KI jetzt schreibt bitte Dokumentation nach ARC42 mit ADRs nach NEIGARD. Und NEIGARD hat leider keine Entscheidungstabelle drin, also ergänze ich noch jeden ADR bitte mit einer 3-Punkt-Pugh-Matrix, was eine Entscheidungstabelle ist, die ich aus dem Six-Sigma-Umfeld kenne.

Und somit ist mit diesen paar Wörtern habe ich immer die gleiche Architekturdokumentation, die gleiche Qualität. Und ich nenne diese Wörter, diese Zaubersprüche und habe dieses Feuerwerk an Definitionen, was ich einfach aus dem Trainingswissen der KI ziehe.

Sehr cool. du das auf einer Webseite dokumentiert, die wir verlinken können?

Ja, das ist total klasse. Also mittlerweile, wenn man nach Semantic Anchors sucht oder Semantisch Anchor, dann finden die Suchmaschinen eigentlich die Seite schon. Das ist eine Open Source Seite, da kann jeder neue Anchor vorschlagen. Und ich glaube, wir haben momentan so 190 Anchor. Und das ist eher so ein Nachschlagewerk, dass man mal so ein bisschen Ideen bekommt, was man an Anchor verwenden kann. Und eigentlich ist jeder Fachbegriff.

Anker. So im normalen Gespräch benutzen wir so von Mensch zu Mensch die relativ selten, weil ich weiß jetzt nicht, ob du jetzt schon viel mit ARC42 gearbeitet hast, ob du das Template kennst, ja, aber bei der Maschine weiß ich es. Und bei der Maschine ist auch spannend, dass man sich mal anguckt, welche Definition kennt die Maschine. Denn wir haben zum Beispiel Simon Martinelli hat mich drauf gebracht bei

Use cases. Fully dressed use cases according to Cockburn oder fully dressed use cases, da spuckt er halt die nach Cockburn aus. Und Simon hat gesagt, die nach Cockburn eigentlich ist use case v3 nach Jakobsen, das Aktuelle. Aber die KI, Jakobsen, das ist irgendwie nicht so stark in den Trainingsdaten drin.

Cockburn mit seinem Buch und lauter Referenzen auf das Buch ist stärker vertreten und deswegen ist halt diese Definition von Cockburn hängen geblieben. Und deswegen macht es eben auch Sinn, das mal nachzuschlagen und zu gucken, ob das passt. Und mittlerweile sind auch bei diesen ganzen Ankern auch teilweise Kritikpunkte genannt, weil zum ja, so dieser

Wolf Schneider als Style Papst ist nicht ganz akzeptiert von allen. Manchmal sagt man, der sieht das alles zu eng und man sollte doch mehr in den Absatz reinhängen oder so. Aber auch das kennt die KI und das hat es dann da eben entsprechend notiert, dass man weiß, wo man vorsichtig sein muss.

Wir werden auf jeden Fall die Seite verlinken in den Show Notes und ich habe einiges jetzt, was ich recherchieren muss für meine semantischen Anker, einfach auch Text für den Prompt zu

Ich muss gerade die Chance nutzen, sorry, wenn ich dich nochmal unterbreche,

wenn ich über die 500 Stars kommen würde. Ich glaube, wir sind gerade bei 440 Stars. Das wäre cool. Also wenn ihr die

semantischen Anker cool findet, hinterlasst auf GitHub einen Stern.

Ich

werde auf jeden Fall den Stern klicken. Einen hast du schon mehr. Wenn ich jetzt... Wie überprüft man sowas eigentlich? Mir fällt jetzt irgendwas ein aus meiner Branche. Irgendwie ein Verfahren, eine Theorie oder sowas. Ich kenne da vielleicht auch einen Namen dazu. Und was ja die LLMs immer machen, die geben dir auf jeden Fall eine Antwort. Also woran weiß ich, ist es jetzt eine LLM-Antwort?

die sie versucht zu konstruieren oder wann habe ich so einen magic moment wie du in ihm beschrieben hast, wann ist es wirklich ein semantischer Anker, gibt es da Hinweise oder wie du das verifizierst?

Das ist das Schwierige und das Tolle. Also das Schwierige ist, ich kann nicht einfach die KI fragen, du kennst du semantische Anker. Die Tiefe der Definition ist meistens recht unklar. Aber wenn ich ein Wort gefunden habe, was ein Anker sein könnte, dann kann ich die KI fragen. Also tatsächlich ist es auf der Website so, dass es da ein Issue-Formular gibt und

Da brauche ich eigentlich nur den Begriff einzutragen. Und die KI überprüft das. Und so kann ich auch die KI tatsächlich fragen. Es gibt auf der Website eine slash llms.txt. Wenn ich denen link diese URL in die KI reingebe und dann sag, so jetzt weißt du, was semantische Anker sind. Guck mal, ich habe hier einen neuen Begriff. Ist das ein semantischer Anker? Dann

gibt es so, ich glaube, drei Punkte, die die KI überprüft, ob es eben eine tiefe Definition ist, ob es wahrscheinlich ist, dass verschiedene LLMs die gleiche Definition haben und solche Geschichten. Und das LLM macht selbst die Bewertung, weil ja, wer soll das besser machen als das LLM? Deswegen ist das so ein spannendes Thema, dass das relativ leicht funktioniert.

Hört sich sehr gut an. Du bist ja in deinem Hauptberuf Architekt, bist aber auch Softwareentwickler und da gibt es auch so ein gespaltenes Lager, wie viel Code sollte denn automatisch geschrieben werden und wir hatten glaube ich auch schon mal das Thema Dark Factories, Lights off Production und du bist einer der seltenen, die sagen, ja will ich, also ich will, dass das passiert. hatten auch schon

Ganz andere Stimmen hier im Podcast, auch sehr spannend und auch valide Argumente haben. Wo siehst du denn die Chance, dass wir wirklich komplett autonom Software entwickeln können? Und warum funktioniert das für dich?

Also ich denke, es ist notwendig, dass wir diesen Weg gehen. Und es gibt so ein Sprichwort, wer will, sucht Wege, wer nicht will, sucht Gründe. Und da kann man mal so drauf achten, wenn man den Leuten zuhört, warum dies und warum jenes. Und ich bin halt der Meinung, wir sollten Wege finden, wie das geht, dass wir kein Review, kein Software Review mehr machen müssen.

sondern dass die KI eigenständig programmiert. Warum? Weil wenn die KI in fünf Minuten so viel Code erzeugt, dass ich fünf Stunden brauch, den zu reviewen, dann hat sie in den fünf Stunden idealerweise schon wieder so viel Code erzeugt, dass ich überhaupt nicht mehr hinterherkomme. Ich hab in einem Talk so einen Blick in die Glaskugel in die Zukunft mal gesagt, was passiert eigentlich, wenn die KI so komplexen Code erzeugt?

dass wir ihn nicht mehr reviewen können, weil wir ihn nicht mehr verstehen. Mittlerweile weiß ich, nein, da sind wir weit von entfernt, weil einfach die schiere Menge an Code bedeutet, wir können diese Reviews nicht mehr durchführen. Und das heißt, wir müssen uns überlegen, wie kommen wir dahin, dass wir diese Reviews nicht mehr durchführen müssen? Und da gibt es halt verschiedene Ansätze, was mir zum Beispiel aufgefallen ist.

Wenn die Leute sagen, jede Zeile Code, die von der KI generiert wird, muss gereviewt werden. Und dann sitzt man da vor dem CSS-File und denkt sich, what, was soll da schiefgehen? Was ist das Risiko? Und das war so ein Moment, wo ich gevibe-coded habe, ein Vibe-Coding-Riskradar findet man auch, wenn man danach sucht.

Und das hat so fünf Dimensionen und diese fünf Dimensionen kann ich halt einstellen und krieg dann so ein Risiko raus. Passt vielleicht nicht für jeden, aber es zeigt schon mal, dass Software nicht gleich Software ist. Also eine statische GitHub-Page, Landing-Page für ein Produkt. Was soll da groß schiefgehen? Da kann ich einfach visuell überprüfen, ob die Daten stimmen.

ob das jetzt mit einer Table oder einem Diff gesetzt ist, ist mir eigentlich ziemlich egal. Wenn ich aber zum Beispiel Firmware für ein medizinisches Gerät habe, ja dann sollte ich vielleicht doch, weil da hängt Leben von ab. Da ist der Blast-Radius und das Risiko einiges höher. Aber das haben wir auch im Menschlichen, dass so eine Firmware nicht von einem Einzelnen irgendwie entwickelt wird. Und das ist so der erste Punkt.

den man lernen muss. Und der nächste Punkt ist dann halt das, was wir eigentlich schon angesprochen haben. Das das Loop Engineering. Und wenn ich zum Beispiel sicherstelle über den Loop, dass der Compiler immer durchläuft, weil er keine Syntax Errors mehr findet, ja, dann brauche ich kein Review mehr auf Syntax Error zu machen. Und so kann ich mir dann überlegen, auf was mache ich eigentlich die Reviews? Wie kann ich im Loop

das überprüfen, dass es funktioniert. Und da finde ich so faszinierend, man lange Zeit gesagt hat, ja Mensch, AI-Slop und der Code ist schlecht. ich habe mich schon ziemlich früh auf die Bühne gestellt und habe vor versammelter Mannschaft gesagt, Leute, das, was die KI hier produziert, ist besser als das, was ich in den letzten 30 Jahren irgendwie erzeugt habe.

strukturiert, formatiert mit Kommentaren und und und und. Und jetzt geht es durch die Presse, dass hier das Mythos-Modell bessere Security Reviews macht als der Mensch und und Aber wir beharren weiterhin drauf, dass wir ein menschliches Review machen, obwohl das von der nachweislich anscheinend besser Und da finde ich so faszinierend,

Das war Anfang des Jahres, da hat Ingo Eichhorst einen guten Vergleich gebracht. Der hat nämlich das zweite Schennen-Theorien genommen und das besagt, dass wenn ich einen fehlerbehafteten Kommunikationskanal habe, dann habe ich eigentlich zwei Möglichkeiten ihn zu verbessern, die Fehler zu minimieren. Das eine ist, ich drehe die Lautstärke auf. Ich spreche halt einfach lauter ins Mikro und

Es kommt klarer rüber. Das sind eigentlich die semantischen Anker. Ich habe eine bessere Definition meiner Begriffe. Da fehlt die Ambiguität. Du weißt, was ich meine. Der zweite Weg ist die Fehlerkorrektur. Wenn wir so ein QR-Code nehmen, dann kann ich 30 Prozent davon zerstören und die Fehlerkorrektur

liefert mir immer noch den korrekten Inhalt. Und die Fehlerkorrektur haben wir überall im Digitalen. Das zweite Shannon-Theorien ist so wichtig. Und Ingo hat das genommen und hat es auf das LLM gemapped. Hat gesagt, das LLM ist unser fehlerbehafteter, nicht-deterministischer Kanal. Wir haben auf der einen Seite, wir geben rein eine Spezifikation. Wir geben das durch den Kanal raus und erwarten fehlerfreien Code.

aber er ist fehlerbehaftet. Und jetzt nehmen wir das Theorem, dass wir von der Kanalkapazität was abknöpfen und eben mit einem Loop die Fehlerkorrektur machen. Und ich finde das so wichtig, ich nenne das immer das Eichhorstprinzip, kein Theorem, weil es nicht bewiesen ist, sondern Prinzip. Und weil wir brauchen eben solche Begriffe. Und mit diesem Eichhorstprinzip

kann ich halt erklären, warum das Loop Engineering funktioniert. Weil ich eben Kanalkapazität nehme. Ich nehme Token, ich nehme Zeit, eben den Kanal zu korrigieren. Und umso mehr Aspekte ich korrigieren möchte, umso mehr Kapazität muss ich halt vom Kanal nehmen. Aber so kann ich mir dann überlegen, welche Aspekte möchte ich alles eben

automatisch korrigiert und das Ziel ist es, die richtigen Aspekte zu finden, sodass dann zum Schluss Software rauskommt, wo man sich sagt, okay, das Review hat stattgefunden, da sind keine Fehler mehr. Und da ist sicher Test Driven

Development ein großer Aspekt.

Das sind dann die Iterationen, die das Ganze immer wieder schärfen und die Fehlerkorrektur dann selbst durchführen. Habe ich das richtig verstanden?

Ja, sind eben diese, ja, kommt drauf an, wie man es implementiert, zum Beispiel Hooks oder eben einfach, dass das LLM selbst eben den Compiler anschmeißt oder dass man eben einen Graph hat, der sagt, du machst erst hier test driven development, da gehst du in den Loop und wenn du fertig bist, wenn die Tests grün sind, dann gehst du in den nächsten

Review Loop, dass du ein Security Review machst, dass du ein Code Review machst, dass du ein Maintainability Review machst, dass du ein Architektur Review machst, ja. Und dadurch kriegt man halt eine viel bessere Qualität.

Die sind für dich denn die Portionsgrößen? Sagst du, das ist eine Applikation, du schreibst sie runter über acht, neun Seiten und dann sagst du hier, machen und dann machst du Rechner, lässt vielleicht die Klappe auf, lässt den laufen und dann irgendwann ist es fertig oder sagst du, ich nehme ja Plöcke raus, einzelne Feature und hab damit die Bite Size vielleicht ein bisschen oder den Kontext für die

LLM fokussierter. Was ist da dein Erfolgsergebnis?

Ist es nicht spannend, dass wir tatsächlich all das, was wir die letzten Jahrzehnte gelernt haben und aufgebaut haben in Sachen Softwareentwicklung, wir jetzt eben einsetzen können? Denn genau das ist das. Wir müssen das Ganze modularisieren und zerlegen. wenn mir Leute sagen, sie können nicht mit der KI auf ihren Source Code draufgehen, weil

die einzelne Klassen haben, die 100.000 Zeilen Code haben, dann muss ich halt sagen, da ist schon vorher was schiefgelaufen. Also den Menschen möchte ich sehen, der eben mit diesen Klassen arbeitet. Da braucht es dann erstmal ein gescheites Refactoring. Und ich finde, dass der Kontext der KI, der deckt sich eigentlich ganz gut mit auch meinem Horizont. Also

meinem kognitiven Horizont. Eigentlich ist die KI weiter, ja? Das heißt, das, was ich irgendwie bearbeiten kann, kann die KI schon längst bearbeiten. Und jetzt bin ich wieder abgeschwiffen. Was war deine eigentliche Frage?

große oder kleine Pakete, die ich der KI gebe,

große oder kleine Pakete. Ganz wichtig,

also momentan sind es für mich kleine Pakete, Baby-Steps. Aber ja, Module. Und diese Module müssen zerlegt werden in Use-Cases und diese Use-Cases müssen sehr gut beschrieben werden. Die brauchen zum Beispiel Activity-Diagramme, dass man den Ablauf hat. Bei mir haben die

Akzeptanzkriterien in Gerkin geschrieben. Und die werden dann wiederum in Epics und Issues umgesetzt, tatsächlich im Issue Tracker. Und diese Issues werden dann analysiert und die Analyse ergänzt. Und an dem Punkt ist dann alles so geil vorbereitet, dass das LLM das umsetzt wie

wenn heißes Messer durch Butter geht. Das ist dann überhaupt kein Problem mehr. Aber Baby-Steps. Und diese Baby-Steps, die helfen so extrem. Also es geht so weit, dass ich zum Beispiel selbst keine Issues aufmache, sondern ich sage dem LLM, du, ich habe dies und jenes gefunden, mach bitte ein Issue dafür auf. Das Issue, was das LLM schreibt, ist schon tausendmal besser als das, was ich dem LLM gesagt habe.

Wenn dann noch die Analyse draufkommt, dann ist das alles super. Und das ist auch wieder so ein Punkt. Ja, sowas kann auch irgendwo in die LLMs ins Backend reinwandern, oder in den Harness oder so. Aber momentan funktioniert das mit den Issue Trackern sehr gut und hat halt auch den großen Vorteil, dass ich eine Traceability im Issue Tracker habe und auch

Im Gegensatz zu dem Ansatz, den viele verfolgt haben, dass man in Markdown-Files den Plan speichert, habe ich eben den Vorteil, dass dieser Plan, dieses Issue, wenn es geschlossen ist, verschwindet. Trotzdem ist es nicht ganz Wenn irgendwo eine Referenz ist oder so, kann das LLM das jederzeit aufmachen, aber es belastet nicht den Kontext.

Aber Hand aufs Herz jetzt, wenn wir sagen Lights Out Factory, ist da noch ganz schön sehr viel Interaktion mit involviert. Kleine Häppchen bedeutet oft interagieren und das heißt die Zukunft geht dahin, aber sind wir schon dort, würdest du so eine komplette Produktionsstraße sehen?

Wenn du jetzt Produktionsstraße sagst, dann beschreibt das eigentlich dieses Ich erzeuge am Tag eine Million gleicher Bauteile. Und das haben wir ja bei Softwareentwicklung nicht, weil gleich bedeutet einfach Sondern alles ist eine neue Herausforderung, ist eine Manufaktur. Deswegen passt da dieses Lights Out nicht ganz so gut. Aber was erstaunlich gut passt, ist tatsächlich dieses

Ich gebe eine Anforderung und ich bekomme ein Ergebnis raus, was der Anforderung entspricht. Dass das vielleicht noch nicht meinem Wunsch entspricht, weil ich sage, die Überschrift, die hätte ich ganz gerne in einer anderen Farbe gehabt oder Das ist nochmal ein anderes Thema, weil die Spezifikation nicht genau genug war. Aber auch bei der Spezifikation hilft das LLM extrem.

Ja, da sind wir ja schon im Prinzip drei Schritte weiter. Wenn du überlegst, der Code kompalliert, ist lauffähig. Und oft ist es so, dass du dann beim ersten Durchtesten dann auch noch fährst, okay, damit habe ich ja gar nicht gerechnet. Eigentlich müsste das komplett anders sein. Und dann ist das eher so eine fachliche Herausforderung, du dann findest und dann nochmal quasi die Anforderungen korrigierst, so wie du es wirklich gemeint hast. Und das ist ja das Spannende an der Software. Du lernst ja mit

Der Software mit, also der erste Schuss sitzt meistens nie und man iteriert so lange, bis man quasi das gewünschte Ergebnis hat und die besser man beschreibt und so näher kommt man an das Ergebnis.

Ja, aber das, du gerade sagst, ist halt auch dieses iterieren und deswegen passt eigentlich Hands off als Bezeichnung ganz gut. Ja, ich setze den Cursor nicht mehr irgendwo in ein Editor Fenster, sondern es gibt Anweisungen. Die KI soll das ändern. Ja, also selbst wenn es nur eine kleine Änderung ist, ich mache das nicht selbst. Das muss die KI machen und sie sie lernt halt oder nein, ich möchte nicht sagen sie lernt, sondern sie

iteriert, das was du gerade beschrieben hast, dass die Spitzifikation im ersten Rutsch noch nicht ganz stimmt. Das habe ich tatsächlich mehrfach erlebt, dass die KI mir ein Tool, Spitzifikation geschrieben hat, alles mögliche berücksichtigt hat, nicht nur den Happy Pass, sondern auch den Fehlerfahrt und sonst was. Alles implementiert, ganz viele Tests, alle grün.

Und dann habe ich nochmal gesagt, und jetzt mach nochmal manuelle Tests, nimm das Tool, prüfe es auf Herz und Nieren, dein Ziel ist es Bugs zu Und dann findet es Bugs analysiert die Bugs und ja eigentlich ist es kein Bug, sondern es war so nicht spezifiziert, aber es entspricht halt nicht der Erwartungshaltung und deswegen

geht die KI rein und verbessert die Spezifikation und fixt dann eben diesen Bug. Und das ist dann eben früher haben wir zwischen Code und Executable das passiert jetzt halt eigentlich auch nicht mehr. Jetzt wird zwischen Spec und Executable iteriert. Also wenn man was anders haben will, wird die Spec angepasst, der KI gesagt und die KI

packt eben den Code an und das führt eben auch dazu, dass zum Beispiel Architekturentscheidungen, die ja dadurch definiert sind, dass sie schwer zu ändern sind, zum Beispiel die verwendete Programmiersprache, ist auf einmal gar keine Architekturentscheidung mehr, weil ich nehme halt die Spezifikation, die hat eine Referenz auf die Architektur, da stand erst Java drin, jetzt will ich es in Go haben, na dann schreibe ich halt Go rein und lass ihn das nochmal alles implementieren.

Und das geht halt in so einer Geschwindigkeit, dass... Wow!

sehr interessant. Du hattest, glaube ich, vorhin schon mal kurz erwähnt, man merkt ja deine Grundwissen, schaffst du aus der Architektur, du bist Architekt. Du hast auch gesagt, du gibst der KI auch Architektur, ja, Skizzen mit ARC42, Dokumente und so weiter. Wie weit hat denn das Arbeiten mit der KI deine Architektenarbeit verändert und

Was hat sich verändert? Was ist davon geblieben? Und wie setzt du dein Wissen der Architektur da ein?

Ich benutze mein Architekturwissen, so ein paar Sachen zu verifizieren. Das ist auch das, wo ich sage, ich nehme die Architektur als als Dashboard. Was du so unterschwellig halt quasi auch gerade genannt hast. Ja, ich arbeite mit einer Architektur. Und wenn du mal bei anderen Frameworks guckst, dann besteht die Architektur meistens nur aus dem Technologie Stack und nicht mehr. Keine echten Architektur.

Aber das ist halt eben faszinierend. Die Tool-Hersteller haben am Anfang gesagt, guck mal, die KI kann für dich Code schreiben und die KI kann jetzt auch noch Tests schreiben. Nein, das ist Development Driven Testing. Wir müssen erst den Test schreiben, dann den Code. Und dann kamen sie auch an und haben gesagt, guck mal, die KI kann dir auch die Dokumentation schreiben. Und das kann sie eben in dem Fall nicht, weil sie nicht weiß, warum der Code da ist. Sie kann nur schreiben, was der Code macht.

Und das war bei mir so der Durchbruch auch mit der Architektur. Erst wenn die KI alles vollständig mitmacht, weiß sie auch, warum der Code da ist. Und da kommt dann die Architektur rein, dass die Architekturentscheidungen, die ADRs nach Neigart, die sind so wichtig, dass man eben weiß, warum wird halt die und die Datenbank, das und das Frontend oder sonst verwendet.

Und wenn man dann noch mal weiterdenkt, diese ganze Architekturwissen, was ich eben über die Jahre gelernt habe, wenn man das mit rein nimmt, dann kann man sich fragen, ja, wie treffe ich denn die Entscheidung? Oft werden so Entscheidungen konferenzgetrieben gemacht, dass man sagt, wir haben jetzt alle über Microservices gesprochen, wir müssen auch Microservices machen. Aber wenn man mal ein ordentliches Review mitgemacht hat, zum Beispiel so ein ATAM Review.

dann merkt man beim Review wird erstmal auf die Qualitätskriterien geschaut. Wie viele Projekte haben denn gute Qualitätskriterien? Und das ist jetzt der Punkt, wo ich eben auch bei dem Agentic Coding ansetze, dass erstmal die Qualitätskriterien, wir hatten es vorhin der Women Acceptance Factor, Qualitätskriterium. Und wenn dieses Qualitätskriterium steht und die KI es kennt, dann kann sie bei jeder Entscheidung, die sie treffen soll,

oder treffen will, kann sie sagen, erfüllt diese Entscheidung dieses Qualitätskriterium, ja oder nein, ist die Entscheidung so korrekt getroffen und wenn sie dann noch die Instruktionen hat, die Entscheidung festzuhalten, dann habe ich halt echt eine tragbare, tragfähige Architektur und das ist ein Wert für sich.

verstehe ich das richtig, dass du sagst, wir kriegen einen großen Wert noch, dass wir nicht der KI nur sagen, benutze Go, Postgres und Vuejs sondern das sind die Entscheidungen, die mich dahin gebracht haben, diese Komponenten zu nutzen, aus diesen sieben Grund. Und das sind die Qualitätsmerkmale, die ich später erwarte. Und das gibt der KI nochmal mehr Informationen, das Richtige dann später zu prüfen und nicht einfach nur diesen Fakt zu haben, nimm die Technologie.

Absolut. Und das sind teilweise auch komische Qualitätskriterien. Ich hatte mal so ein Live-Coding, wo ich der KI gesagt habe, du, ich mache hier ein Demo, eine Stunde. Und die KI hat das ständig eben auch bei den Entscheidungen als Qualitätskriterium mitgenommen und gesagt, Stunde, wir haben nur noch 40 Minuten, dann mache ich das mal gerade so. Und ich lasse jetzt mal die Tests weg.

Das ist so wichtig, dass eben die richtigen Entscheidungen getroffen werden, wie rock solid muss das sein, was ist überhaupt. diese Qualitätskriterien, ich habe früher immer gedacht, Qualität ist unverhandelbar, ja, Qualität muss toll sein. Stefan Zörner hat in einem Talk mir dann die Augen geöffnet, weil er gesagt hat, er hat mal eine Schach-Engine geschrieben.

nur sie mit ARC42 zu dokumentieren, also ein gutes Beispiel zu haben, dann ein Buch zu schreiben, wie man eben Architekturen mit ARC42 dokumentiert. Diese Schachengine ist super modular und alles. Manchmal gewinnt sie auch gegen ihn. Er hat jemanden getroffen, der wohl die Schachengine Shredder heißt, die wohl programmiert hat, und hat sich mit dem unterhalten und der hat gesagt,

ist bei mir gar nichts. Ich selbst habe da teilweise Probleme, das Ganze weiterzuentwickeln. Aber das Teil sammelt halt Preise ein. Das ist ein ganz anderer Qualitätsanspruch und beide Ansprüche sind absolut valide. Und

Ja,

das hat mir die Augen geöffnet und deswegen weiß ich eben auch, wenn ich diese Qualitätsansprüche der KI nicht mitgebe, die Qualitätskriterien, Qualitätsszenarien und so,

Dann legt die immer los und macht ihre React Web Anwendung. vielleicht wollte ich gar keine React Web Anwendung.

Jetzt haben wir Qualitätsmerkmale von der Schach-Applikation, wo wir vergessen haben zu sagen, die sollte auch mal gewinnen, bis hin zu dem Boom-Acceptance-Faktor. Das sind ja ganz, ganz unterschiedliche Bereiche. Definier vielleicht noch mal für alle, was ist denn ein gutes Qualitätsmerkmal, was ist das denn eigentlich und wie kann ich auch für meine KI jetzt sagen, das sind die richtigen Qualitätsmerkmale, nicht dass es da so läuft wie bei dir mit der Zeit, dass die Zeit abläuft und dann irgendwie Abkürzungen genommen werden.

Erklär

Ja.

uns das doch mal bitte.

Wir haben früher das Ganze als Non-functional Requirements bezeichnet. als ich ein Rookie war, dann habe ich immer gedacht, Non-functional, was ist das? Bugs sind Non-functional. Ein blöder Begriff. Qualitätskriterien trifft das viel besser. was die Software machen soll, ist funktional, ist irgendwie in Use Cases beschrieben. Aber das

welche Qualität es haben soll, wie schnell zum Beispiel eine Antwort kommen soll. Da gibt es diese Stories, dass irgendwelche Teams ihre Software auf irgendwelche Millisekunden optimiert haben. Und als sie es dem Kunden gezeigt haben, hat der gesagt, also bis lang war ich es gewöhnt, dass die Antwort in acht Sekunden kommt. Ihr habt es jetzt auf 200 Millisekunden reduziert? Wow, aber das war jetzt gar nicht der Anspruch. Und die

Schwierigkeit ist bei den Qualitätskriterien, wenn ich zum Beispiel sage, das soll performant sein. Ja, was bedeutet das? Was ist performant? Ja, dann hilft es schon mal, wenn ich einen Vergleich habe. Guck mal, soll ungefähr so schnell antworten wie die und die Web-Applikation. Und wenn ich dann eben nochmal in diese Beispiel-Web-Applikation reingucken kann und Zeiten rausziehen kann, dass ich ein Szenario draus machen kann, also zu einem...

Qualitätskriterien gehören eigentlich auch so, ich sag mal, drei Qualitätsszenarien, die eben beschreiben. Wenn das passiert, das auf das System in dem und dem Zustand einwirkt, dann erwarte ich das und das. Und bei der Performance ist zum Beispiel ein User macht eine Suchanfrage auf das System, was schon 100 gleichzeitig User hat.

Dann erwarte ich, dass in 80 % der Zeit die Anfrage innerhalb von 400 Millisekunden den Server verlässt. Dann ist es definiert und messbar. Durch die 80 % der Zeit lasse ich eben da auch noch so bisschen Spielraum, damit auch mal so eine Anfrage länger dauern kann. Und dann habe ich es eigentlich sehr gut definiert und dann kann ich mir überlegen, ob ich...

bei 100 gleichzeitigem Usern, ob es da noch reicht, dass ich die Daten auf dem File System habe und ich über das File System suche oder ob ich einen Index in der Datenbank brauche. Und das kann man dann ziemlich gut entscheiden. Notfalls macht man Proof of Concept mit der KI, dass man sagt, du baumal hier diese Architektur und diese Architektur und probier's aus.

Und wie man den Women-Acceptance-Faktor misst, das erklären wir dann offline.

Ja, ist natürlich, das ist Bauchgefühl.

Sehr schön. Für dich war ja KI auch eine spannende Reise. Wir haben jetzt viel von deinem Architekturwissen gehört. warst klassischer Architekt, warst in ganz anderen Themen drin und hast ab einem gewissen Punkt gemerkt für dich, da ist das Ding KI. Und du hast dann angefangen, intensiv damit Und das hat dann auch eine Folge für deinen Beruf gehabt. Kannst du da uns vielleicht mal mit auf die Reise nehmen, wie du deinen eigenen Job transformiert hast,

Ja, das ist eigentlich eine spannende Frage. Ich weiß nicht, ob ich da so eine gute Antwort finde, weil ich bin eigentlich schon immer so ein neugieriger Geist gewesen, dass ich mich für alles Mögliche interessiert habe und die Sachen voranbringen wollte. Und so war das eben vor zehn Jahren hat es mit dem DOCSIS Code Ansatz angefangen, da ich mir gesagt habe, wie können wir die Systeme besser dokumentieren?

eben indem wir die Dokumentation zum Code legen und mit dem Code versionieren und habe das vorangebracht. als dann Ende 23 ich gemerkt habe, dass mit der KI ist irgendwie so ein Ding, das ist gekommen, zu bleiben, habe ich mich halt damit beschäftigt, bin rabbit hole mäßig da reingegangen und habe jetzt eben wieder den Dreh zurück zur Architektur geschafft. Das ist halt

viel Neugierde und viel auch Community Building, dass ich halt schon ziemlich früh die Chance genutzt habe, auf Konferenzen zu gehen, meine Ideen vorzutragen. Und das hat eben auch geholfen, man mit der Community über diese Ideen sprechen kann und mit der Community diese

Dinge vorantreiben kann. Und sobald man eben anfängt, solche Vorträge auszuarbeiten, wird man auch relativ schnell zum Experten. Und wenn man dann auf der Bühne steht und die Leute sehen, guck mal, der hat sich damit beschäftigt. Den könnten wir mal fragen. Da wandelt sich sehr schnell eben das Berufsbild,

Der Change ist halt da. noch eine Architektur von Hand erstellen, in spätestens fünf Jahren wird man da ganz anders drauf gucken als jetzt, wo dann eben viele noch sagen, ja, aber wir können nicht die Verantwortung abgeben. Andererseits

Definitiv.

geben eben viele schon die Verantwortung ab. Und das ist so eine Sichtweise von uns Techies.

dass wir sagen, wir müssen den Code reviewen, wir müssen die Architektur reviewen und so Product Owner, der sagt sich, was meint Ich habe schon immer irgendwie meine Storys in die Black Box reingegeben und habe gehofft, dass das Richtige rauskommt, aber nie ein Code Review Und das finde ich faszinierend, dass eben unterschiedliche Gruppen unterschiedliche Sichten haben.

Und dass wir da eben auch teilweise über unseren eigenen Schatten springen müssen und sehen müssen, wie sich unsere Arbeit transformiert. Und mit dieser Transformierung müssen wir eben mitgehen. die Informatik ist lifelong learning. wer da irgendwie sagt, nee, ich bin keine Ahnung, Oracle, DBA und das will ich auch noch bis zur Rente machen, dann das war nie so mein Ansatz.

sondern ich habe immer geguckt, was gibt es Neues? Was kann man machen? Und das hat mich getrieben. und seitdem ich das eben mein Wissen öffentlich teile, hat sich das eben nochmal beschleunigt.

spannend. Also, Communities waren ein großer Teil davon. Aber auch Social Media. Das heißt, du schreibst oft Artikel darüber, du teilst dein Wissen auf Social Media. Das hat dich so weit gebracht, dass dieses Wissen quasi außerhalb deiner Arbeit bei der Deutschen Bahn, auch intern bei der Deutschen Bahn, angekommen ist und du hier und da sehr gefragt bist als Enabler, als jemand, der intern das Wissen teilt, Wissen vermittelt.

Und hast dort vor vielen Leuten schon gesprochen, du hattest mir mal irgendwie erzählt, innerhalb von einer Woche hat es, glaube ich, 1.000 2.000 Leute erreicht, wo man einfach mal das Wissen geteilt hat intern, was eine riesen Menge ist. Was sind denn so deine Erfahrungen von dem Enablement? Was sind denn solche wichtigen Punkte, die da bei einer KI-Transformation mit reinmüssen, die vielleicht jetzt nicht auf der Hand liegen beim ersten

Hinsicht?

Die

Leute sind halt wissbegierig. Die meisten wollen dann doch das Wissen wie einen Schwamm aufsaugen. deswegen hat man es eben leicht in so einer Situation, wenn ein Thema neu ist, wenn man dann eben schon ein bisschen vor der Welle ist und wieder Einäugige den Blinden erzählen kann, was Sache ist.

Aber was für mich das allerwichtigste dabei ist beim Wissen weitergeben, es gibt diese Wissensquadranten und der blödste ist eigentlich der Quadrant mit dem Wissen, von dem ich nicht weiß, dass ich es nicht weiß. Weil dann kann ich auch gar nicht die Fragen stellen. Also zum Beispiel beim Handy, bei der virtuellen Tastatur, die Tricks, wie ich den Cursor bewegen kann.

Das wissen die meisten gar nicht. Ich glaube, bei iOS ist es mit zwei Fingern über die Tastatur streichen. Wenn ich nicht weiß, dass ich es nicht weiß, dann kann ich auch nicht danach fragen. Deswegen ist das bei der Wissensvermittlung auch eben dieser schwierige Quadrant, weil ich weiß ja auch nicht, was die anderen Leute wissen. Deswegen muss ich ausholen und muss tief reingehen. Und dieses Tiefe reingehen, das Wissen vermitteln,

damit die Leute auch verstehen, wie es funktioniert und warum es funktioniert. Das ist mir halt immer wieder ein Anliegen und ich glaube, das kommt auch ganz gut rüber. Aber wichtig ist halt auch, die Leute abzuholen mit der richtigen Sprache. Dass es jeder versteht und man nicht so eine eingeschränkte Zielgruppe von irgendwelchen KI-Nerds hat.

sondern eben gerade bei so einer Transformation, die alle betrifft, muss man auch alle abholen.

Ja, was auch spannend ist, ist diese... Also ich sage immer, wenn die Leute jetzt fragen, was kann ich denn machen und haben sehr viel Angst vielleicht vor dem Thema, dass der Job wegfällt oder sonst irgendwas, dann hilft das oft, das einfach mal auszuprobieren. Weil je mehr du weißt über das Prinzip, je mehr du ausprobiert hast, was passiert denn da im Hintergrund, was wird denn da wirklich gemacht, so...

weniger mystisch ist das große Fragezeichen dort. Also das heißt wirklich dort mal Hände rein und ausprobieren hilft vielen Leuten schon zum ersten Schritt. ich kann mich auch an eine Session erinnern, wo wir zweimal drin waren mit ganz vielen Leuten, wo wir einfach auch mal zugehört haben. Also diese Bedenken der Leute, dass sie sich einfach mal reflektiert haben, dass wir einfach mal zugehört haben, dass wir vielleicht unser Wissen geteilt haben.

Und das hat sehr viel positives Feedback gegeben. das wird aus meiner Sicht sehr oft unterschätzt, auch diesen Moment zum Atmen in so einer Transformation, wo sehr viel Bewegung drin ist, sehr viel Change drin ist, die Leute auch mal ausspeichern zu lassen. Was bewegt sie jetzt wirklich?

Ja, das sind natürlich jetzt auch wieder viele Aspekte, die du angesprochen hast, die es einfach mal ausprobieren. war ganz am Anfang war mein Tipp, dass man tatsächlich für die KI mal zahlt, weil damals war das GPT-3 Modell kostenlos. GPT-4 hat 20 Euro gekostet. Das GPT-3, das konnte man wegschmeißen. Damit konnte man nichts anfangen. Ja, das war ein Wow-Effekt, wenn ich mit GPT-4 gearbeitet habe. Diese Diskrepanz ist jetzt

ganz gut weg. Es reicht eigentlich mittlerweile, wenn man mit den kostenlosen Systemen arbeitet. Aber richtig tief reinzukommen, dass man versteht, wie das Ganze funktioniert, das empfinde ich als ziemlich wichtig. Deswegen finde ich es auch ganz gut, dass einige Videos von mir auch eben auf YouTube geteilt sind. Wobei man kann natürlich darüber diskutieren, wer jetzt tatsächlich es am besten irgendwie

rüberbringt, weil es gibt ja so eine schiere Menge an irgendwelchen Tutorial-Videos. Das ist echt schwierig, irgendwie die Spreu vom Weizen zu trennen. Spreu vom Weizen, genau. Und was du eben auch noch die Ängste, die du ansprichst. Ich war mal in einem KI-Training drin, wo ich selbst Teilnehmer war und zum Schluss hat jemand gefragt...

Wie ist denn das jetzt? Ich bin Software-Entwickler, muss ich jetzt meinen Job fürchten? Und der Trainer hat gesagt, also wenn dein Job es ist, Zeilen, Code zu schreiben, ja dann such dir was anderes. Wenn dein Job es ist, Probleme zu lösen, ja dann herzlich willkommen. Diese Leute brauchen wir auch in Zukunft. Und das ist halt immer so die Frage, wie definiert man seinen Job? Wie flexibel ist man? Und

wie bereit ist man eben jetzt eben auch selbst zu investieren, dass man sich diese Themen mal anguckt und dass man eben auch versucht, die Ängste irgendwo zu überwinden. Weil ich kann das gut verstehen, dass so ein System, was macht das mit meinen Daten, was ist das jetzt für eine Antwort und und und, das kann schon Angst machen. Aber man muss da eben rangehen, weil

Die Büchse der Pandora kriegen wir nicht mehr zu.

die ist geöffnet. glaube, Full Circle kann man auch zurückgehen und kann sagen, so wie du am Anfang beschrieben hast, wie du die KI nutzt, auch die KI einfach mal fragen, was passiert da im Hintergrund? Wie funktionieren denn solche Transformer? Und sich dort Wissen aufzubauen, weil aus meiner Sicht nach wie vor je mehr man versteht, umso besser kann man das Risiko einschätzen und so besser und so näher ist man jetzt dran und hat nicht dieses unwahrscheinliche oder die große unbekannte Vorsicht.

Ja, da gibt es bei der auf der Semantic Anchors Website gibt es auch einen Bereich Semantic Contracts. Das ist dann nicht unbedingt das Trainingswissen, sondern eben neues Wissen, was man eben zusammenfügt. Wir hatten vorhin das Beispiel der Architektur, dass ich eben ARC42, Neigard und Pugh Matrix zusammenfüge. Und da findet ihr auch den Prompt, ich glaube, Teach and Learn heißt der.

der die KI eben anweist durch Fragen einem etwas beizubringen und ich benutze das selbst so gerne, das funktioniert so prima. Wow.

Sehr schön. Und ansonsten kann man dich natürlich auch in dem Stream immer mal sehen auf Softwarearchitektur.tv. Da bist du Co-Host

Genau.

und spezialisiert auf das Thema KI. Kannst du vielleicht dazu kurz erklären, wann wird das ausgestrahlt, was für Themen behandelt du dort und...

Also es ist

Eberhard Wolf hat den Softwarearchitektur im Stream gegründet und ist da der Hauptmoderator und ich habe die Chance bekommen, ich da eben auch ab und zu mal einen Slot bekomme. Wir sind meistens freitags unterwegs von eins bis zwei und es sind sehr, sehr unterschiedliche Sessions, teilweise

zeigen wir einfach was, teilweise referieren wir über was. Die meiste Zeit haben wir sehr interessante Gesprächspartner, Interviewpartner. Ja, so wie du jetzt hier mich hast, wir da eben auch andere Architekten. Das Thema ist meistens eben Architektur, so wie der Titel es sagt. Und da kommt natürlich jetzt auch KI rein.

Definitiv ein Tipp zum Einschalten. werden auch den Link darauf in die Show Notes mit reinnehmen. Ralf, wir haben jetzt schon bisschen länger als eine Stunde gesprochen. Es hat mir riesig Spaß gemacht mit dir, uns mal wirklich auf Stand zu bringen wieder, wo du unterwegs bist. Wenn Leute dich im Internet finden wollen, wenn sie wissen wollen, was sind interessante Projekte, die du referenziert hast, wo können sie dich finden?

Also ich habe ja das Mittelinitial, das D, nicht umsonst, weil Ralf Müller ist einfach nur ein Sammelbegriff. Ralf D. Müller findet man tatsächlich nicht im Netz. Und ich habe es letzte Woche ausprobiert. Sogar die KI kennt mich mittlerweile, wenn man fragt, wer ist Ralf D. Müller? Also da findet man mich hauptsächlich dann eben auf LinkedIn mittlerweile und eben auf meinen Projekten wie doctoolchain.org.

oder den semantischen Ankern der Website.

Sehr schön. Softwarearchitektur TV werden wir auch noch mit reinnehmen in die Show Notes,

Genau.

wo man dich dann auch live sehen kann, wo du dein Wissen teilst. Wir haben die Show angefangen mit dem Format, wo ich eine Frage mitgebracht habe von meinem letzten Gast. Jetzt wäre die Bitte an dich. Hast du eine Frage für mich, die ich an den nächsten Gast mitnehme, ohne dass du natürlich weißt, wer es ist? Und welche spannende Frage hast du für mich?

Also ich würde passend zu unserem Gespräch heute den nächsten Gast fragen wollen, ob er noch Code Reviews macht und wenn ja, was eben ihm dazu fehlt, dass er keine Code Reviews mehr machen muss.

Alles klar. Frage ist, machst du noch Code Reviews? was fehlt dir, keine mehr machen zu müssen? Sehr spannend. Ich bin jetzt schon auf die Antwort. Ich hoffe, du schaust natürlich auch rein beim nächsten Mal und

Natürlich.

hörst dir die Antwort dann im Podcast an. Ja, Ralf, danke schön, dass du teilgenommen hast. Hat mir wirklich sehr viel Spaß gemacht. War ein tolles Gespräch. Danke, dass du dein Wissen geteilt hast.

Danke für die Einladung, es hat wirklich verdammt viel Spaß gemacht. Danke.

Und an alle anderen, vielen Dank, dass ihr wieder zugehört habt. ich habe eine Menge gelernt und ich hoffe ihr auch. Schreibt gerne Kommentare, liked und subscribed zu dem Podcast und wir sehen uns in der nächsten Episode. Bis dann, vielen Dank, ciao.