speaker-0: Willkommen zur zweiten Folge von Zwischen zwei Stacks, dem Podcast, in dem Christoph und ich euch ein Einblick darangeben, was unsere täglichen Projekte, Erfahrungen und Learnings sind im Bereich Product und Tech. Ja, vielleicht kurz zu mir. Ich bin Jens, selbstständiger Softwareentwickler und arbeite hauptsächlich an Web-Anwendungen, das heißt Websites, Condom-Management-Systeme, Web-Apps, Infrastruktur, hauptsächlich für Firmen im Dachraum und beschäftige mich dabei besonders viel mit Payload CMS und jetzt die letzten Monate, Jahre eben auch mit AI-Integration.

speaker-1: Ich bin Christoph, hallo. Ich bin seit 20 Jahren oder sogar über 20 Jahren, ich habe nachgerechnet, in letzten Folge habe ich gesagt, glaube ich gesagt knapp 20 Jahre, aber es über 20 Jahre im Bereich SEO und Produktentwicklung unterwegs und berichte eben hier auch über meine Geo-Product-Development-Sachen und SEO-Sachen und freue mich auf die heutige Folge. Ja Jens, ich starte mal direkt. Unsere letzte Folge war die Pilotfolge. Wir haben uns gerade noch dazu entschieden, dass das jetzt die Folge 2 ist. Wir haben ein bisschen überlegt, wie macht man das jetzt eigentlich. Aber wir ja die Pilotfolge veröffentlicht und wir haben uns entschieden, das ist die Folge 2. Und das lief schon ganz gut. Also wir haben ein tolles Feedback bekommen. Danke an jeden, der uns geschrieben hat. Das war echt cool, das zu lesen und zu hören. was wir gelernt haben ist, wir müssen auf jeden Fall die Videos auch auf den anderen Plattformen wie Spotify und Apple Podcasts veröffentlichen. Spotify klappt auf jeden Fall schon bei der Folge, die wir jetzt gerade aufnehmen. Das haben wir herausgefunden, wie es geht. Und bei Apple kann es sein, dass es noch bisschen dauert. Aber ich denke, dass wir die Videos auf YouTube haben und auf Spotify ist dann schon ganz cool. Und... Das wird... Und ansonsten, genau, wir wollen uns auch mehr Mühe geben, dass das Ganze auch für die Zuhörer, die nur per Audio dabei sind, dass das auch besser funktioniert. Das heißt, wir werden versuchen, das, was wir auf dem Bildschirm zeigen, noch besser zu beschreiben und schauen mal. Wir freuen uns auf weiteres Feedback dazu. Genau, darf gerne so weitergehen. Ja, Jens, was hast du denn für Themen mitgebracht heute?

speaker-0: Ja, ich hatte ja beim letzten Mal über eins meiner Open Source Projekte gesprochen und zwar über diese Payload Content CLI. Und da gibt es jetzt noch ein, zwei Dinge, die ich heute zeigen will, an denen ich gearbeitet habe. Und da geht es vor allem um Schema-Validierung, auch um so ein Experiment, was ich gemacht habe mit so einer Content Sandbox. Und mein zweites Thema ist ein Projekt, was ich mir jetzt schon länger anschauen wollte. Und das habe ich endlich mal heute morgen gemacht. Es ist ein Open Source Projekt auch und da geht es um so ein Agent Harness Framework. Ja, ich freue mich auf jeden Fall, dass wir da gleich darüber sprechen und euch was zeigen kann.

speaker-1: Ich habe auch zwei Themen wieder mit dabei. Einmal das Thema Grounding Page. Da freue ich mich ehrlich gesagt schon ziemlich drauf, was dazu zu sagen. Und ansonsten dachte ich mir, zeige ich mal, wie ich ein Cloud Code Projekt starte von Null. Also wenn ich eine Idee habe, wie mache ich das eigentlich, weil ich gemerkt habe, es gibt da mittlerweile eigentlich einen festen Prozess, ich folge. Und genau, das habe ich so ein bisschen aufbereitet. Und dann würde ich sagen, starten wir direkt mit dem ersten Thema. Ich starte eben mit dem Thema mit der Grounding Page. Ich teile jetzt mal meinen Bildschirm und wie gesagt, ich gebe mir Mühe, dass ich das besser beschreibe. Auch für die Leute, die nur zuhören. Und ja, Grounding Page. Also ich habe mir überlegt, bevor ich jetzt direkt bei Grounding Page einsteige, möchte ich erstmal erklären, ist das Thema, was ist Grounding eigentlich? Ich denke, das muss man erstmal verstehen. Also ich habe jetzt hier eine kleine, wirklich eine super simple Folie vorbereitet, wo ich das mal zeige, weil es ist auch gar nicht schwer zu verstehen. Grounding, eigentlich wenn man es ganz einfach runterbricht, bitte korrigiert mich, wenn es jemand besser weiß, ich freue mich auf jeden Kommentar, eigentlich ist was Grounding die KI-Recherche, die quasi stattfindet. Also ich habe hier mal zwei Beispiele, ich hier zeige. Beispiel eins, ein Prompt ohne Grounding. Das würde bedeuten, ich frage zum Beispiel, was ist Next.js und die Antwort könnte das LLM direkt geben, weil es ist in den Trainingsdaten mit drin. Wenn ich aber frage, welche Next.js Version ist aktuell, dann würde das LLM wahrscheinlich eine Recherche starten und würde den Grounding-Prozess starten und mir dann eine Antwort mit den Quellen geben. Ich habe übrigens einfach mal ein Buch dabei, das ich jedem empfehlen, dem das Thema GEO, also Generative Engine Optimization interessiert. Und zwar ist das Generative Engine Optimization im Rheinwerk-Verlag erschienen. Ich verlinke das auf jeden Fall in den Show Notes. Das wirklich noch gar nicht so lange auf dem Markt, Buch, aber wirklich eine gute, gute Grundlage, ⁓ mal zu verstehen, wie das Ganze funktioniert, worauf es da ankommt. Und dort ist eben auch eine Beschreibung von Grounding. Und ich dachte, ich lese das einfach ganz kurz, es ist echt nur ein Satz. Und zwar ... stellt fest, dass ihr Wissen lückenhaft oder nicht aktuell genug ist, startet sie den Grounding-Prozess. Sie führt eine aktive Websuche durch und greift auf andere gespeicherte Datenfällen zurück, ⁓ aktuelle und relevante Informationen zu finden. Sie stützt sich also bei der Antwort auf überprüfbare Quellen. Die KI verfolgt damit das Ziel, Output zu erstellen, der mit hoher Wahrscheinlichkeit korrekt ist. Also warum ich das auch noch mal so vorgelesen habe, dass es nur die Recherche ist, wer, glaube ich, bisschen zu einfach erklärt. Da ist eben wirklich ein ein Prozess noch mit dabei, der auch versucht zu überprüfen, dass das korrekt ist. Genau, also das ist Grounding. Und dann gibt es ein tolles Projekt von einem bekannten deutschen Zeo, ich jetzt sagen. Also ich glaube, er ist Gründer von Cystrix auch. Cystrix kennt man vielleicht, wenn man im Zeo-Bereich ist, ein Zeotool. Und muss ich zugeben, ich habe jetzt den Namen auch ganz ganz vergessen. Genau, das ist ja Hans Kronenberg. genau. Entschuldige bitte, falls Hans Kronenberg zuschaut. Entschuldige bitte, dass ich nachgucken musste. Aber er hat ein tolles Projekt gemacht und zwar groundingpage.com. Also dabei geht es darum, einen offenen Standard zu entwickeln, wie man faktenbasierte Informationen für KI bereitstellt. Diese Seite grounding-pagecode.com oder diesen Standard, den gibt es auch schon bisschen länger. Ich glaube, habe den auch schon vor ein paar Monaten das erste Mal gesehen. Im Moment ist das die Version 1.5. Und es gibt hier ein Playbook und es gibt den Standard an sich beschrieben und es gibt Beispiele und es gibt auch mittlerweile Tools, habe ich auch mal geprüft, wo man seine eigene Grounding-Page einfach mal checken kann, wie, ob die... gut genug ist oder oder dann kriegt so ein Scorer zurück, was echt ziemlich cool ist. Und dabei geht es eben wirklich darum, dass das maschinenlesbare Fakten sind. Für mich war es tatsächlich, ich habe mich die letzten zwei Wochen intensiv damit beschäftigt und ich fand es echt sehr spannend, weil ich bisher immer davon ausgegangen bin, wenn ich strukturierte Daten auf meiner Website einbaue, dann reicht das aus. Ist aber nicht so. Also es ist wirklich so, dass diese strukturierten Daten tatsächlich wohl teilweise gar nicht gelesen werden von der KI, sondern eben nur der Text, der dort wirklich zu sehen ist. ja, also empfehle ich jedem mal diese Seite sich anzugucken, dieses Playbook mal durchzuspielen und ich habe mich aber jetzt vor allem auch damit beschäftigt, wie ist das denn in der Praxis schon umgesetzt und wer macht das denn schon? Und da sind also zwei spannende Beispiele habe ich gefunden. Und zwar einmal die Santander Bank kennt man wahrscheinlich einfach. Tatsächlich haben die schon wirklich auch eine grounding page. Die heißt dann auch so. Ich bin jetzt hier im Browser, zeige ich jetzt auch gerade diese Seite. Und da sieht man mal, wie so was in live aussieht. Also es geht wirklich darum, das ja quasi in als Entität quasi zu beschreiben, was das ist, was ist die Santander Bank und eben so genau wie möglich zu beschreiben, was die macht und vor allem auch, was ich spannend finde, Teil der Grounding-Page ist ganz oft die Abgrenzung. Also was ist Santander nicht oder was ist die Brand oder was auch immer ich beschreibe eben nicht. Und das ist eben total spannend. Ja, kann man sich eben mal angucken. Man sieht auch hier, es ist nichts, keine wahnsinnig umfangreiche Seite. Es sind wirklich einfach Fakten, die hier stehen. Und wichtig ist auch zu verstehen, dass eine Grounding-Page nichts mit einer Landing-Page zu tun hat oder so. Ich hab dann, als ich jetzt mit dem Thema mich intensiv auseinandergesetzt hab, gedacht, okay, das bedeutet also, ich muss jetzt meine About-Me-Page oder so was auf meinen Webseiten noch umbauen, damit sie eine Grounding-Page sind. Kann man machen, ist auch völlig in Ordnung, aber eigentlich ist die Idee, dass diese Grounding-Pages ein eigener Layer auf der Webseite werden. Und das heißt nicht, dass jede Seite wie so einen Schatten braucht, der quasi dann die Fakten darstellt, sondern diese Browning-Pages, die können eine komplett eigene Struktur darstellen der Webseite. Aber es sind wirklich Seiten, die nur dafür gedacht sind, dass das hier, also hier steht es auch bei der Santander Bank, Hinweise für menschliche Leser sogar. Diese Seite dient als verlässliche faktenbasierte Referenz für Submaschinen, KI-Systeme und anderen automatisierten Informationsdiensten. Also ist es wirklich so gedacht. Und das ist also ein Praxisbeispiel, was ich hier auch spannend fand. Die Frage, die mich beschäftigt hat, wie verlinke ich das denn? Also ich muss es ja irgendwie erreichbar machen und das finde ich halt auch spannend, dass das hier, wenn wir ganz kurz gucken, ich glaube es war hier unten. Genau, ich bin jetzt auf der Santander.de slash Privatkunden, also im Privatkundenbereich und das ist wirklich, die Grounding Page ist hier unten im Futter direkt bei den Legal Pages und so weiter verlinkt, also direkt neben der Sitemap und hier kann ich dann diese Grounding Page erreichen. Also fand ich spannend, ehrlich gesagt. Und dann habe ich noch ein zweites Beispiel gefunden und zwar von SkiData, muss ich zugeben, ich habe keine Ahnung was diese Firma macht. Vielleicht ist es total bekannt, ich weiß es nicht.

speaker-0: Das so ein Schieliften. Da gibt es immer diese Automaten, wo du deine Karte dran hältst und da steht immer Skidata drauf. Aber ich weiß auch nicht genau, was sie da im Hintergrund machen.

speaker-1: Scheint auf jeden Fall wirklich eine spannende Firma zu sein. Und die haben dann bei skidata.com slash AI einen ganzen Grounding Hub erzeugt. Und das ist jetzt eigentlich das, ich mir nicht sage, es muss nicht jede Seite jetzt eine Faktenseite im Hintergrund irgendwo haben, sondern die haben wirklich einen eigenen Fakten Hub erzeugt. Und das finde ich auch ein spannendes Beispiel, weil das wirklich ein bisschen mehr advanced ist hier. Und die zeigen dann eben verschiedene grounding subpages wiederum. wie hier zum Beispiel dann ihre Segmente quasi, also dass sie Airport, Parking, Cityparking, ⁓ okay, Jens, ich glaube es geht eher ⁓ Parkplätze. Ja, das merk ich gerade. Aber ja, also dass sie ihre ganzen Segmente, in denen sie unterwegs sind, quasi auch als eigene grounding page beschreiben. Also ich klicke jetzt hier zum Beispiel mal auf City Parking, dann komme ich auf eine eigene Grounding-Page nur zum Thema City Parking, die das genau beschreibt. ja, also fand ich wirklich sehr spannend. auch diese, genau, ist hier unten verlinkt im Futter mit dem Link Facts. Genau, fand ich also wirklich interessant, wie das in der Praxis umgesetzt wird. Ich habe dann auch auf meiner eigenen Seite, vielleicht mal als bisschen Kontext, ich habe tatsächlich immer eigene Testseiten, muss ich sagen. Also im Moment habe ich drei, die wirklich aktiv sind und ich nutze die sehr, ⁓ einfach Sachen zu lernen, ⁓ wirklich in der Praxis mitreden zu können, weil man kann natürlich nicht immer alles in Projekten usw. ausprobieren und manchmal ist es auch cool, wenn man es vorher mal geübt hat und dann vielleicht erst in einem Kundenprojekt einsetzt. Und eine dieser Seiten ist die Auto-Auction-Atlas, genau so dieser Bereich B2B, Vehicle Auctions, der verfolgt mich schon seit vielen Jahren. es gibt jetzt eine weltweite Übersicht dieser Auktionsplattform, wo man im B2B Bereich Autos versteuern oder handeln kann in einem Auktionsformat. Und das ist eben meine Testseite dazu. Ich habe da 120 Plattformen gelistet und die sind dann mit strukturierten Daten aufbereitet und so weiter. Also das ist eine Directory-Page. Und was ich gemacht habe, ich habe hier auch eine Grounding-Page erstellt und zwar unter slash facts slash Auto-Auktion-Atlas. Also ich habe mich für diesen Pfad quasi entschieden und die ist dann eben auch nach diesem Standard von groundingpage.com erstellt worden und so sieht die jetzt gerade aus. ich habe so Fakten, wer steckt dahinter. Ich habe auch hier einen AI Transparency Guide mit drin. Also die Recherche und die Aufbereitung der Daten habe ich mit AI gemacht und da gehe ich auch ganz transparent mit ⁓ und genau da ist eben wirklich alles mit drin. Und dann eben auch dieser Scope, also was ist Auto-Auction-Atlas und was ist es nicht? Das ist hier auch ganz klar beschrieben. Und, ja, also das ist alles sehr strukturiert, faktanbasiert quasi aufbereitet. Was ich jetzt noch nicht gemacht habe, dass ich eben für jede Plattform, die ich hier liste, eigene Grounding-Page gemacht habe, könnte so ein nächster Schritt sein. Aber was ich total spannend fand, ich habe am nächsten Tag die ersten Besucher über TGPT auf dieser Seite gehabt. Und das fand ich wirklich spannend, weil es hat mich nämlich dann im nächsten Schritt beschäftigt, wie kriege ich denn die Seite jetzt in den Index, was auch immer der Index ist, also jetzt die SEO-Perspektive. Ich mache eine Änderung auf meiner Webseite, ganz einfach, ich gehe in die Suchkonsole und sage, hey, Crol bittet meine Seite nochmal und beantrage die Indexierung oder die erneute Indexierung. Aber wie mache ich das denn bei LLMs eigentlich. mit dem Thema habe ich mich dann auch auseinandergesetzt und habe festgestellt, es gibt eigentlich so drei Methoden, so gesehen, oder drei Mechanismen, mit denen man da rechnen muss. Das eine ist eben der Training-Crawler. Also das ist der Crawler, der wirklich dann die Trainingsdaten sich holt. Der ist natürlich nur alle paar Wochen oder Monate oder keine Ahnung wie unterwegs. Auf den würde ich mich nicht verlassen, dass meine Inhalte da schnell in sichtbar werden. Dann den Search-Index, das heißt es gibt LLMs, die einen eigenen Index pflegen, also wie zum Beispiel der Perplexity Bot, der wirklich wie Google eben einen eigenen Index haben und dann aber die User Triggered Fetch, also sprich, das ist dann wirklich das ganz aktuelle und da wird eine Live-Versuche gemacht und das ist genau das, wo eben auch das Grounding stattfindet und Das ist wirklich so, dass einfach sofort aktuellste Informationen findet. Und ich fand's spannend. Also in der Praxis wirklich, ich am nächsten Tag über JTBT Besucher gehabt. Übrigens auch hier so ein Sonderfall. Google AI nutzt quasi den bestehenden Search Index. Also das heißt, da lohnt es sich dann trotzdem zu sagen, ich gehe jetzt in die Suchkonsole und lasse diese Sachen die neuen Seiten indexieren oder die Änderungen, ich gemacht habe.

speaker-0: wäre nämlich auch eine Frage von mir gewesen, ob man die Seiten auch trotzdem auch bei Google indexieren lässt. das würde ja dann schon Sinn machen.

speaker-1: Genau. Und trotzdem finde ich jetzt, wie gesagt, ich freue mich wirklich über jegliche Kommentare, wenn da jemand eine andere Meinung zu hat oder auch Wissen, Erfahrung. Ich finde, hier geht es ja nur ⁓ KI. Also die Seiten würde ich jetzt nicht nur für KI machen, sondern eben auch für So-Maschinen einfach. Und ja, finde ich eigentlich total spannend. Und ja, letzter Fakt, den ich noch nennen wollte. Fakt. Ich habe, es war ja diese UMR, Online Marketing Rockstars. Ich bin nicht der größte Fan davon, kein Ahnung, ist so ein Festival, glaube ich. Aber es gibt da ein Video, ein Talk von Philipp Klöckner, der das anscheinend dort jedes Jahr macht, The State of AI. Ich habe sie, glaube ich, auch geschickt, Jens. Und da gab es einen spannenden Fakt, wie oft zum Beispiel Anthrophic eine Seite crawlt, bevor sie einen Besucher schickt. Und das fand ich wirklich krass. Also es war so, sind quasi Daten von Cloudflare, glaube ich, die veröffentlicht worden sind. Und Anthrophic ist 24.000 Mal auf einer Seite oder quality-Seite, bevor sie einen Besucher schickt. Also, ich nenne jetzt einfach diese Zahl, ja, ich habe mich darauf verlassen, da diese Cloudflare-Statistiken da irgendwie stimmen, aber fand ich total krasse Zahl. Ja, das mal so zu dem Thema.

speaker-0: Ja, richtig, richtig spannend. Auch coole Demos oder hier die Visualisierung, die du vorbereitet hast. Ja, also finde es sehr, spannend und bin auch sehr gespannt, wo sich diese Standards ja so hinentwickeln werden. Ich fand immer dieses Konzept von diesen strukturierten Daten, von diesem Schema, fand ich eigentlich echt immer super, weil du sehr gut und differenziert eben und eben strukturiert darum geht es ja, so hervorheben kannst, worum geht es auf dieser Seite. Produkt, vielleicht irgendwie ein FAQ drin. und so weiter und so fort. Aber ich sehe auch jedenfalls auch hier den Reiz daran, das alles ein bisschen visueller zu machen, weil das Ding bei den strukturierten Daten ist ja eben, dass sie meistens im Hintergrund bleiben, dass sie sozusagen unsichtbar sind und nur für die sichtbar, die sich halt irgendwie auswerten dieses Thema. Von daher bin ich mal sehr gespannt.

speaker-1: Vielleicht ein wichtiger Hinweis noch, weil ich das glaube ich gar nicht erwähnt habe. Also die grounding pages beinhalten trotzdem noch strukturierte Daten. wenn ich jetzt auf meinem Beispiel hier habe ich unten auch FAQs mit drin. Moment, wo sind meine FAQs? Jetzt habe ich wieder Käse erzählt. Also auf jeden Fall hier sind komplett Ich habe noch weitere Facts Pages, deswegen habe ich das verwechselt. Ich habe da auch schon andere, ich habe da auch wirklich die strukturierten Daten mit drin und das ist auch die Empfehlung dieses Standards von Hans Kronenberg dort, auch strukturierte Daten zu verwenden.

speaker-0: Ja, das finde ich super.

speaker-1: Ja und irgendwie so einen Satz, ich auch noch sagen möchte, es geht wirklich in Zukunft wahrscheinlich nicht mehr darum, möglichst viele Besucher zu bekommen auf die Webseite, sondern möglichst viele Mansions und Citations und so weiter.

speaker-0: Ja, sehr, spannend. für den Einblick.

speaker-1: So Jens, ich würde an dich.

speaker-0: gebe ich jetzt auch mal meinen Bildschirm frei. Ich habe es diesmal auch bisschen größer gemacht. ich zeige jetzt, ja, switch immer so bisschen hin und her zwischen meiner IDE, indem ich jetzt als Beispiel mal unsere zwischen zwei Stacks Website habe. ja, switch dann hin und her zwischen der Codebase und eben dem Browser. Genau, also ich hatte ja beim letzten Mal über die Payload, ja über meine Payload CLI gesprochen, mit der man eben den Content sich quasi einmal pullen kann, sozusagen, man so einen Snapshot hat. von dem ganzen Content aus dem CMS. Und da habe ich jetzt noch eine Sache eingebaut, die ich ganz interessant und auch wichtig fand und zwar, also man sieht jetzt gerade hier auf meinem Screen diese ganzen JSON-Files von allen Dokumenten, wir im CMS haben. Und was jetzt neu passiert ist, wenn dann auch immer ich mit der CLI sozusagen den Content einmal pulle. Dann werden hier auch zwei neue Dateien abgelegt und zwar einmal so eine Schema.json-Datei. Das ist dann einmal wirklich das normalisierte Schema dessen, was man im payload.cms eben angegeben hat. Also zum Beispiel ein Autor hat immer eine Autorenseite, hat zum Beispiel immer einen Slug, hat eine Parent-Page, hat einen Pfad, Predcrumbs und so weiter und so fort. Das wird einmal erstellt, was natürlich sehr wichtig ist für die Agents, ⁓ zu wissen, was für eine Struktur haben die Seiten. Und dann wird auch noch so eine JSON Schema Punkt JSON Datei abgelegt. Und JSON Schema ist ja so ein Standard, der eben ja ein Schema von einem JSON Objekt festlegt. Und das wird dann auch hier bei diesem Pull-Command erstellt. Das heißt, da steht dann zum Beispiel drin, dass jedes Autorenobjekt hat gewisse Properties und ein paar davon sind eben verpflichtend und andere eben nicht. Und dann eben auch noch was die für ein Schema haben, zum Beispiel das created ad in dem Fall einfach ein String ist. Und was jetzt ganz cool ist, ist, dass es generell in den meisten IDEs die Möglichkeit gibt, dass wenn du ein JSON-File hast und da eine URL zu einem JSON-Schema anlegst, dass die IDE dir dann direkt direkt warnt, wenn dieses JSON-Dokument nicht mehr dem Schema entspricht. Und das mache ich mir hier zu nutzen. indem ich einfach diese generierten JSON Schema Dateien hier oben verlinke. Und was dann passiert, wenn ich jetzt mal hingehen würde und würde hier statt excerpt, das ist quasi immer festgeschrieben, das heißt jeder Autor hat so eine Kurzbeschreibung zu sich. Wenn ich das jetzt mal umbenennen würde, dann warnt mich meine IDI hier sofort, okay, da fehlt eine Property. Und ja, kommt quasi, ganze Validierung kommt sozusagen geschenkt. Das Einzige, was es braucht, ist eben hier oben diese Ja, diese Verweisung, genau, eben diese Referenz zu diesem Schema. Das nutzt zum Beispiel Versal auch. Es gibt ja, man irgendwelche Projekte anlegt, so Konfigurationsdateien wie Versal.json, wo du dann Dinge konfigurieren kannst und die benutzen das zum Beispiel auch, ⁓ eben sicherzustellen, dass diese Datei, die du benutzt, dass die immer dem richtigen Schema folgt, dass Versal das eben auch richtig verarbeiten kann. Ja, und das war so die erste Sache, die ich eingebaut habe und die natürlich dann auch den Agents weiterhilft, weil die ja eben auch die Möglichkeit haben, sich über so einen MCP, der in diese IDEs eingebaut ist, einfach die Diagnosen beziehen können, in welcher Datei gerade irgendwo ein Fehler ist. Und dann würde der Agent zum Beispiel direkt merken, wenn irgendwo jetzt eine Änderung gemacht hat, die aber eigentlich gar nicht dem Schema entspricht, bevor er das Ganze dann später irgendwie hochpusht zum CMS. Genau. Und dann habe ich noch eine andere Sache gemacht. zwar, habe eine Kundin, für die habe ich schon vor längerer Zeit eine Website entwickelt, auch mit Astro und Payload CMS. Und die Website sollte jetzt eben redesigned werden. Und da habe ich mir dann überlegt, okay, wie mache ich das jetzt? Im Endeffekt geht es wirklich sehr, viel ⁓ Redesign. So paar Blöcke, die es dann auch im CMS gibt, sollen schon angepasst werden. Aber so im Großen und Ganzen bleibt das Projekt eigentlich gleich. Dann habe ich mir überlegt, okay, macht es wahrscheinlich am meisten Sinn, ich einfach einen neuen Git Branch dafür anlege. Dann kann ich da einfach mit Cloud Code schnell drüber iterieren und diese Design Anpassung machen, mit der Kunden teilen. Dann habe ich mir über die Frage gestellt, will ich jetzt wirklich nochmal meinen CMS duplizieren, neue Datenbank dafür anlegen für diese Entwurfsphase, will ich das wirklich? Und dann bin ich zu der Erkenntnis gekommen. Oder was ich ja schon hatte zu dem Zeitpunkt war, dass ich mir einfach hier die Dateien vom CMS alle runterpullen kann. Das Problem war halt nur immer, dass die Website, also nehmen wir zum Beispiel mal an, ich zeige hier die zwischen zwei Stacks Website, die nutzt ja trotzdem das CMS als Source of Truth für den Content. Das heißt, der benutzt einfach die REST API, ⁓ den Content zu beziehen. Das heißt, dieses Pushen und Pullen müsste ja trotzdem noch stattfinden und ich bräuchte trotzdem noch das CMS. Dann habe ich mir aber gedacht, Nach diesem Pull habe ich ja den gesamten Content sowieso schon in der Codebase drin. Ich habe ja diese ganzen JSON-Dateien. Warum nicht so einen kleinen Layer einfach einbauen, dass die Website, also die Astro-Page direkt den Content aus der Codebase beziehen kann, sodass ich quasi gar nicht den Schritt gehen muss zum CMS. Und das, dachte ich mir, könnte man dann vielleicht irgendwie so bisschen als so Local Content Sandbox bezeichnen. Cool. Weil ich erstmal wirklich dem ganz viel interieren kann und das Design anpassen kann, aber auch schon mal den Content anpassen kann und auch sehen kann, wie sieht es dann auf der Website aus, ohne eben das TMS zu involvieren.

speaker-1: Das finde ich so in der Praxis, wenn man dann den Content wirklich setzt, also Figma Designs, im Endeffekt nehmen wir mal diesen Standardprozess, Figma Designs, da ist der Content drin und dann setzt du den Content wirklich, dann musst du den umbrüchen, dann guckst du nochmal, möchtest du was anpassen, dann machst du wieder einen Deploy und so weiter, wirst du wieder warten, bis der Deploy durch ist. Ich glaube aus so Marketingperspektive ist das manchmal das Leben, glaube ich und das wäre dann cool.

speaker-0: Genau, also im Endeffekt denkt quasi die Astro Website immer noch, sie kommuniziert mit dem CMS, aber in Wahrheit greift sie eben auf den lokalen Content zu. Das kommt natürlich auch mit vielen Nachteilen. Wie gesagt, das ist einfach nur ein Experiment für mich jetzt auch gewesen und das hat sicherlich auch auch Nachteile und auch noch gewisse Probleme, wenn man jetzt an virtuelle Felder denkt oder an gewisse Custom Endpoints, das CMS hat. Das kann man natürlich dann schwer replizieren. Aber ich fand es zumindest für so einen Test und vor allem für so eine Entwurfsphase sehr, sehr spannend. Und wir können das mal hier kurz testen. Also ich habe jetzt bei mir in der IDE Cloud Code gerade gesagt, er soll eben von unserer zwischen zwei Stacks Content eben auf der Startseite einmal die Hero-Section anpassen und da irgendwie noch irgendwie unseren Namen mit reinbringen. Ich suche es mal kurz hier genau. Und jetzt würde ist gerade Cloud Code dabei, sich den Content zu suchen. Der ist ja schon gepullt und hat jetzt hier, man sieht das, noch unsere Namen, also mit Christoph und Jens, mit eingefügt. Und im Hintergrund, ich habe hier die Website offen, passiert das quasi in real-time, das heißt innerhalb von ein paar Millisekunden, dass hier sich das direkt aktualisiert, ohne dass nochmal der ganze Content bezogen muss vom CMS und so weiter und so fort. Und das würde ich jetzt mal gerne in den nächsten Wochen ein bisschen ausprobieren. Ja, mir da so ein kleines Setup aufzubauen, dass ich wirklich einfach einen Agent habe, der die Contentänderung macht, der aber auch an den Browser angeschlossen ist und quasi direkt sehen kann, wie sich die Contentänderungen auswirken. Ich kann das hier gerne auch nochmal zeigen. Also wenn ich jetzt hier oben das mit Christopher Jens nochmal rausmach und einmal Speicher, dann ist es halt direkt da. Also quasi wirklich Realtime. Und das fand ich ja, fand ich irgendwie ganz spannend.

speaker-1: echt cool. Spart wirklich in der Summe glaube ich manchmal Stunden. Ja. Cool. Ich finde auch das ist wieder so ein bisschen Praxis. Also ich finde viele Sachen funktionieren. Also in der Theorie sind die Sachen alle perfekt durchgeplant und so weiter. Diese ganzen CMS Geschichten und so. Aber in der Praxis, wenn du dann mal wirklich eine neue Company Website oder sowas machst und kleine Änderungen, dann gibt es solche Sachen am Schluss, die einfach immer wieder mal so vier, fünf Minuten dauern und in der Summe dann Stunden manchmal ausmachen. Und da kann man viel optimieren, finde ich.

speaker-0: Ja, definitiv. Vor allem in so Phasen, wo man einfach erstmal ganz viel draften will und ausprobieren will, kann man so einfach komplett vielleicht die Komplexität und den Zeitaufwand rausnehmen.

speaker-1: Und ich habe noch eine Frage zu diesem Jason Schema, nur damit ich richtig verstehe oder auch vielleicht die Zuhörer, Zuschauer. Aber das ist quasi eigentlich eine Metaebene von von dem eigentlichen CMS Schema, wo ich quasi die einzelnen Fields und Properties so beschreibe.

speaker-0: Genau, also im Endeffekt weiß ja Payload in dem Fall, also CMS, hat ja das Schema, das kannst du ja auch da angeben, was für Entitäten haben welche Felder und aufgrund dessen habe ich dann eben Skript geschrieben, das ist auch in meinem CLI-Project mit integriert, was das Ganze eben einmal umwandelt in dieses JSON-Schema-Format und das kann man dann natürlich in beliebigen Use-Cases eben benutzen.

speaker-1: Wichtigste Frage, open source, das schon nutzbar für die Zuschauer und Zuhörer?

speaker-0: Ja, also ich werde es auf jeden Fall verlinken in den Show Notes. Also die CLI, diese Content CLI für Payload, die ist open source und ist live. Die kann gerne genutzt werden. Und da bin ich auch sehr, sehr gespannt auf Feedback. Dieses ganze Experiment mit dieser Content Sandbox, das werde ich jetzt erstmal für mich ein bisschen testen. Aber ja, vielleicht würde ich da drüber vielleicht auch mal einen Blogpost schreiben, wo ich das ein bisschen erkläre. Und dann kann jeder, der das vielleicht in irgendeiner Weise in seinem Projekt gebrauchen kann, das auch einfach selbst implementieren. Aber ich glaube das große ist wirklich diese CLI, dass du eben diese JSON Schema bekommst. Push and Pull Commands und die sind alle open source und alle verfügbar.

speaker-1: Ja, stark. Cool.

speaker-0: Ja, dann...

speaker-1: Jetzt können wir noch mal über Zutierungen So und zwar wie angekündigt geht es jetzt bei meinem zweiten Thema darum, wie starte ich quasi so ein Cloud Code Projekt von Scratch. Ja, ich habe so gemerkt, dass ich eigentlich immer den gleichen Prozess habe, der hat sich so entwickelt und ich habe mal versucht den jetzt hier, ich zeige jetzt gerade so eine Folie mal darzustellen und zwar wäre das so, dass Der Schritt eins ist eigentlich der, ja, Scope definieren. Und zwar human only. Also ich mach mir wirklich, wirklich, bevor ich mittlerweile irgendwie einen ersten Prompt losjage, viele Gedanken dazu, was ich wirklich will, was ich brauche und was das Projekt, wie das aussehen soll am Ende. Und mach mir das wirklich ohne AI diese Gedanken, weil ich weiß nicht, wie es bei dir ist. Aber ich glaube, die schlimmsten Erfahrungen habe ich gemacht, wenn ich einfach drauf losgepromptet habe. Und dann würde ich sagen, dann ist das auch dieses Vibe-Coding oder so. Alles andere, was man mittlerweile mit Chord-Code macht, ich weiß nicht, ich finde den Begriff Vibe-Coding gar nicht mehr passend. Also, ja. Genau, das ist also der erste Schritt. Ich überlege mir wirklich, und das kann tatsächlich Stunden dauern. Also ich mache mir wirklich manchmal, ich setze mich hier eine Stunde lang und mache mir da Gedanken, ich haben möchte. Und bevor ich dann überhaupt Cloud Code aufmache, starte ich mit Cloud einfach im Chat, also auf Cloud AI. Und zwar gebe ich dann unstrukturiert eben das rein, diese ganzen Gedanken, die ich mir da gemacht habe. Meistens sind die natürlich ein bisschen strukturiert, aber ich habe da jetzt keine feste Reihenfolge oder sowas. Ich kippe da wirklich alles rein, alle Sachen, die mir wichtig sind, alle Abgrenzungen auch, wo ich schon sagen kann, das soll es nicht werden oder das ist nicht Teil des Scopes. Das ist übrigens total wichtig, immer zu sagen, das ist es nicht. Sieht man ja auch, wenn man jetzt noch mal kurz auf die Grounding-Page zurückkommt, da ist es ja auch wichtig, nochmal zu sagen, so, hey, da übrigens sind wir nicht, das machen wir nicht. Und dann benenne ich das Ziel des Chats. Also der Prompt hier ist nicht abgeschickt, aber ich sage natürlich dann im ersten Prompt so, was mein Ziel ist. Und mein Ziel ist, drei Dokumente zu erstellen, das sind immer die gleichen, und dann Was jetzt neu dazugekommen ist, eine Empfehlung für Skills. Da wollte ich auch gleich noch was zeigen. Das bedeutet, ich starte dann den Chat und sage so, hey, das ist eben das Ziel, dass diese drei Dokumente, ich gehe gleich auf die Dokumente auch noch mal ein. Also das sind, ich kann sie jetzt mal vorlesen, das sind die PRD Markdown-Datei, also Product Requirements Document, dann die Architecture MD und die Milestones MD. Das sind so meine drei Dateien, mit denen ich immer arbeite. Und dann Erzwinge ich so ein Interview. Ich sag dann so, hey, mach dir Gedanken über den strukturierten Prozess, also versuch den Scope mal in gute Schritte zu unterteilen und geh dann mit mir jeden Schritt einfach durch, bevor du überhaupt anfängst diese Dokumente zu schreiben. Und dann ist es eben wirklich so, dass man in so eine Interview-Routine reingeht mit Claude. Und was ich dann mache ist, dass immer ein Vorschlag erstellt werden soll und ich bestätige den dann oder korrigiere ihn und dann geht es erst zum nächsten Schritt. Und wenn dann alle Informationen da sind, dann lasse ich mir diese Markdown-Dateien schreiben und lasse mir eine Empfehlung ausgeben für welche, Skills Sinn machen. Und bei den Skills, ich weiß nicht, du kennst das bestimmt schon, aber dieses skills.sh ist also, ich zeige jetzt hier gerade die Webseite, hier steht Skills are reusable. Capabilities for AI agents, install them with a single command to enhance your agents with access to procedural knowledge. Es ist einfach ein Directory von Skills, die ich dann im Cloud, zum Beispiel bei Cloud Code, aber ich kann sie auch in anderen Agents oder anderen Setups quasi verwenden, dann eben nutzen kann. Jens, vielleicht deine Hilfe auch ganz kurz, aber nochmal der Unterschied zwischen einem Agent und einem Skill. Ich würde mal sagen, der Skill ist wirklich der Experte für eine bestimmte Sache und der Agent ist der, der eine Aufgabe übernehmen kann und in seinem eigenen Kontextfenster bearbeitet. Würdest du das auch so sehen oder?

speaker-0: Ja, würde ich auch so sehen. im Endeffekt ist so ein Skill irgendwie, finde ich, immer fokussiert auf so eine gewisse Aufgabe oder auf ein Thema. Und verschiedene Agents nutzen vielleicht verschiedene Skills und ja, manche teilen sich sicherlich auch gewisse Skills, die eben oft notwendig sind. Und im Endeffekt vielleicht auch nochmal für die Zuschauer, die von den solchen Agent Skills jetzt noch nicht so viel gehört haben. Es geht wirklich im Endeffekt immer einfach ⁓ eine Markdown-Datei. wo eben textuell in Markdown eben Dinge beschrieben werden. Vielleicht kann man das so als eine Art Anleitung oder als eine Art Info zu einem gewissen Thema beschreiben. ja, ich finde hier dieses Skills.sh Seite auch sehr, sehr spannend und sehr, cool, wie viele Skills da wirklich schon mittlerweile existieren.

speaker-1: Ja, total. Und da habe ich jetzt eben angewöhnt, mir Claude dann wirklich direkt im ersten Schritt sagt, in diesem Projekt wird es total Sinn machen, das und das mit rein zu machen. Also ich hatte jetzt ein Firebase-Projekt zum Beispiel, wo es eine Firebase-Datenbank schon gab. Dann habe ich mir wirklich diese, das waren dann glaube ich die Firebase Authentication Basics, die ich mir dann reingeladen habe und die Firestore-Standards. Und das hast du wirklich gemerkt, dass das mit da drin ist. Das war wirklich cool. Aber trotzdem möchte ich mal so eine Warnung aussprechen. Man sollte sich natürlich immer auch das wirklich angucken, was man da so in sein Projekt reinlädt. wenn man sich einen Skill reinlädt, der irgendwie, keine Ahnung, irgendwelche Daten irgendwo hinsendet, das kann ja theoretisch auch irgendwie passieren. Also ich guckt euch... Bitte an, was ihr in euer Projekt reinlädt, weil ich finde gerade die letzten zwei Wochen, da geht echt, es ist einiges los, was Supply Chain Attacks und so weiter angeht. Man muss hier wirklich mittlerweile vorsichtig sein und zwar nicht nur bei den Skills, auch bei den Note Packages und so weiter. Einfach ⁓ das auch mal kurz zu sagen.

speaker-0: Ja, definitiv wichtiger Punkt.

speaker-1: Ja und dann, ich will es auch gar nicht in Länge ziehen, dann kommen am Ende diese drei Dokumente eben raus und einfach mal als Beispiel, ich habe mir die wirklich, also das sind, das habe ich extra für jetzt quasi machen lassen hier, keine echten Beispiele von mir, aber hier könnte man mal sehen, so ein Product Recurrents Dokument für einen Pomodoro Focus Timer und die Idee ist halt hier wirklich zu sagen, was bauen wir und was nicht, aber alles was tech ist, ist in einem Architecture. Dokument. Also hier geht es wirklich, das ist eigentlich die echte Product Perspektive so gesehen. Was soll da am Ende rauskommen? da steht dann, also hier sind zum Beispiel Sektionen wie Vision, das Problem Statement, wer ist die Zielgruppe, was sind die Ziele, was sind die Nicht-Ziele, die Core Features für das MVP und so weiter. Und dann gibt es eben die Architecture MD, die beschreibt dann eben wirklich schon das technische Setup, also was wird da verwendet und so weiter. Hier eine High-Level-Struktur, das Datenmodell kann da drin sein, schon die Ordnerstruktur des Projekts. Und dann lasse ich das Ganze noch in einem Milestones.Markdown kippen und mache mir sinnvolle Milestones, damit ich das Projekt von Null bis zum Ende, von dem was ich da möglich haben möchte, durchziehen lassen kann. Genau. Also ich mache dann auch wirklich in der Praxis Milestone 1, ich teste manuell, gebe Feedback, dann gebe ich erst zu zum nächsten Milestone. genau. ja, kleiner Tipp noch, das mache ich dann immer am Schluss, weil ich faul bin. Ich sage dann immer, wenn die Dokumente erstellt sind, sage ich so, okay, und jetzt gib mir bitte den konkreten ersten Claude Code Prompt für den Planmodus, mit dem ich loslegen kann. Also, dann erstellt er mir sogar direkt den Prompt, dann mache ich Claude Code auf meiner Maschine auf, packt die ganzen Dateien in den leeren Ordner, in einen am besten in so einem Docs-Folder oder so und dann geht es eigentlich direkt los. Ja, das ist so mein Prozess. Also ich bin mir sicher, Jens, du hast bestimmt vielleicht auch deinen eigenen Prozess und so. Fände ich auch mal spannend, übrigens mal zu hören oder zu sehen, aber das ist auf jeden Fall so meiner.

speaker-0: Ja, für Quill. Also bei mir ist es wirklich auch relativ ähnlich. Und vielleicht auch nochmal wichtig zu sagen, man kann diesen ganzen Prozess auch mit anderen Modellen nutzen. Also das ist jetzt alles überhaupt nicht an einen Cloth oder so gekoppelt, sondern ich glaube, hier geht es wirklich darum, sich so ein Framework zu schaffen, sich diese Setup einmal aufzustellen mit diesen verschiedenen Dateien. Und ja, ich benutze es auch. Ich benutze nicht alle von den Dateien, die du benannt hast, oder benutzt manche auch unterschiedlich. Ich meine, das kann man ja auch so machen, wie man Wie man es gerade für richtig hält, zum Beispiel habe ich bei ein paar Projekten so eine Roadmap.md-Datei einfach drin. Aber ich finde das sehr, sehr wichtig, dass man sich wirklich am Anfang, das hast du ja auch gesagt, Zeit dafür nimmt und wirklich da auch rein investiert, diesen Scope zu definieren, diese Architektur irgendwie festzulegen. Weil je mehr Zeit man da am Anfang reinsteckt in diesen Input, desto besser wird es auch hinten raus und desto einfacher wird es auch. Ja, deswegen sehr, sehr wichtiges Thema.

speaker-1: Und auch noch ein Satz, ich auch sagen möchte. Ich habe so gelernt für mich, es ist viel cooler zu sagen, ich arbeite immer mit diesen drei festen Dokumenten und habe immer meine Learnings, wie die Dokumente oder dieser Prozess noch ein bisschen besser werden kann, anstatt immer nach einem besseren Prozess zu suchen. Das sehe ich oft, dass Leute suchen immer den Shortcut oder das neueste Tool oder den neuesten Prozess. Aber ganz ehrlich, lieber habe ich einen Prozess, den ich immer nutze und mache meine echten eigenen Learnings in der Praxis damit. Ich glaube, es gibt nichts wertvolles als das, weil die Suche nach immer der Sache, die noch schneller ist und so weiter, kostet so viel Zeit. ⁓ das auch mal gesagt zu haben.

speaker-0: Ja, absolut. Und vielleicht noch ein Thema zu dem Thema Interview. Ich weiß nicht, ob du ihn kennst, aber es gibt Matt Pocock, der ist so ein ja, bekannter TypeScript-Entwickler auch und hat da ziemlich viele Kurse die letzten Jahre auch veröffentlicht und macht jetzt auch ziemlich viele Kurse, was AI angeht. Er zum Beispiel AI Hero heißt die Website. Können wir vielleicht auch mal verlinken. Und er ist jetzt ziemlich viral gegangen die letzten Wochen mit einem Skill und zwar heißt dieser Skill Quill Me. Und was der macht, das sind wirklich nur drei Sätze oder so, wo einfach drin steht, dass der Agent wirklich den User interviewen soll, wirklich sehr weitgehend interviewen soll und dann, wie du es auch glaube ich eben gesagt hast, ja zusammen man einfach so einen Plan erstellt und zusammen halt, ja also der Agent in dem Fall dann halt Fragen stellt, okay wir haben ⁓ drei verschiedene Wege das umzusetzen. Ich würde dir den und den vorschlagen und dann iteriert man wirklich mit dem Agent da durch, bis man irgendwann wirklich zu diesem Konsent kommt, wie man es eben dann umsetzt. Und ich glaube, das ist ziemlich ähnlich zu dem, was du auch in dieser Phase machst, oder?

speaker-1: Ja genau, also für mich geht es eigentlich immer darum, so in jedem Step so ein gemeinsames Commitment einfach zu finden mit dem Agent und vor allem eben auch, hey, das ist ein Tool. Also das muss ich auch immer wieder sagen, das ist ein Tool und nicht der Mitarbeiter oder so was oder jemand, den ich mich verlassen kann. Also ich möchte das nicht, es ist ein Tool und ich möchte die Zügel in Hand haben und das ist für mich so der Weg. dieses Interview nutze ich super oft, also nicht nur bei Claude Cote, sondern allgemein. Versuch immer zu sagen, überleg dir den strukturierten Prozess, geh mit mir Step by Step durch, lass uns am Ende jedes Schrittes eine Zusammenfassung machen und ich gebe dir nochmal das Go, ob du wirklich alles so verstanden hast, wie ich das möchte.

speaker-0: Ja, ich glaube, ist ein richtig guter Prozess.

speaker-1: Ich merke schon, Jens, die Folge wird ein bisschen länger, ich hoffe, es ist okay für jeden.

speaker-0: Ja, aber ich muss auch sagen, mein nächstes Thema ist gar nicht so lange. zwar wollte ich mich die letzten Wochen schon immer oder anders gesagt, ich habe ziemlich viel auf Twitter eben von diesem neuen Framework hier gelesen und zwar heißt es Flu und das ist entwickelt von Astro, also dem Framework, wir beide auch häufig eben nutzen. Und das ist so ein Agent Harness Framework und dieser Begriff Harness, ist ja Also ich habe den zumindest die letzten Wochen sehr, sehr viel gelesen und davor ja so gut wie noch nie. Und was dieser Begriff im Endeffekt beschreibt, einfach so eine Art Laufzeit und Kontrollumgebung rund ⁓ diese LLMs herum. Also zum Beispiel Claude Code wäre so ein Harness, der eben die Modelle von Anthropic benutzt oder auch Codex von OpenAI wäre dann so ein Harness. Und was dieses Projekt sich jetzt hier zur Aufgabe gesetzt hat, ist ja wirklich ein Framework, ⁓ diese Harnesses herum zu bauen. Und das habe ich mir heute morgen jetzt mal endlich angeschaut und da mal ein bisschen mit rum experimentiert. Und ja, wollte es jetzt einfach mal zeigen, was man damit so cooles machen kann. Also im Endeffekt geht es wirklich darum, dass es dir so eine Struktur gibt, wie du in deinem gewisse Agents erstellen kannst, die du dann halt auch wiederverwenden kannst und die du vor allem auch in der Cloud laufen lassen kannst, vielleicht in der Sandbox laufen lassen kannst, wie jetzt zum Beispiel so eine Linux Sandbox. Ich bin jetzt gerade hier auf der Website von flu-framework.com und hier sieht man jetzt zum Beispiel mal so ein Beispiel für so einen Agent, der so ein Triaging durchführen würde, bei zum Beispiel einem GitHub oder Issue oder Ticket. Du kannst wirklich ganz genau definieren, was für ein Modell du benutzen Willst du vielleicht irgendwie eine gehostete Sandbox benutzen, der das Modell läuft? Und dann kannst du eben Ich glaube, wir haben es jetzt schon ziemlich oft benannt, aber ein Skill eben aufrufen oder ein Skill referenzieren. Und in dem Fall ist es dann zum Beispiel so, dass in der Codebase würde dann so ein Triad Skill liegen, der dann eben einmal beschreibt, wie dieser Prozess eben ablaufen soll. also so wie ich es jetzt so gelesen habe, ist glaube ich wirklich der Hauptpunkt, der dir diese Framework gibt, dass du wirklich eine feste Struktur hast, wo du deine Skills, deine Agents drunter ancast. ⁓ die dann möglichst effizient und mit wenig Code eben dann auch zu benutzen und wiederverwendbar zu machen. Und in dem Fall ist es zum Beispiel so, dass man erstmal definiert, wie gesagt, welches Modell, dann erstellt man eine Agent-Session, dann würde man diesen Try-It-Skill verlinken, würde sagen, was bekommt der für Argumente, was hat der für ein Schema, was soll da wieder zurückkommen. Dann würde im Hintergrund quasi flusig ⁓ diesen ganzen Prozess kümmern im Sinne von, das Model aufzusetzen mit der SDK und so weiter und so fort. Und dann kannst du halt definieren, was soll danach passieren. Und in dem Fall ist es zum Beispiel so, dass man dann nochmal einen Agent promptet, der einfach einen GitHub Kommentar dalassen soll, der diesen Dryadge Prozesse eben zusammenfasst. Und wenn das dann eben in irgendeiner Umgebung läuft, wo du dann zum Beispiel auch die Git CLI benutzen kannst, dann kann das natürlich damit direkt auch passieren. Und Ja, das fand ich sehr, spannend und ich werde mir das jeden Fall noch bisschen weiter anschauen die nächsten Wochen. Und dann bestimmt auch damit mal was, was wir benutzen, also was implementieren. Ich habe es jetzt zum Beispiel auch mal mir vorhin hier dieses Beispielprojekt runtergeladen von Flu, wo es dann wirklich einige, ja, sage ich mal ganz simple Beispiele gibt, aber die halt helfen so bisschen zu verstehen, wie könnte man das in großem Umfang eben nutzen. Und im Endeffekt, was man halt hat, ist so ein neuer Punkt Flue unter, also so ein Ordner in seinem Projekt, wo man dann eben die Agents definieren kann, Connectoren, Rollen. Und es gibt jetzt hier so ein Beispiel, wo man, ich kann das gleich mal gerne ausführen, es gibt so ein Beispiel Agent, der dann so eine Rolle hat, man einfach nur, also wo man quasi, wo quasi der Name von der Person eingegeben wird. Und dann ist der Prompt einfach nur, dass der Nutzer gegrüßt werden soll. Und dann wird aber eben eine Rolle mitgegeben und diese Rolle ist in dem Fall greeter und das ist dann in der anderen Datei definiert, wo dann nochmal drin steht, dass er den User wirklich sehr warmly irgendwie begrüßen soll und dann eben noch so ein Funfact oder so eben dalassen soll. Und wenn wir das mal hier ausführen, also ich habe dieses Flu Projekt, das ist lokal bei mir laufen und könnte jetzt einfach über ein Postrequest eben hier was absenden und

speaker-1: Hehe.

speaker-0: Ja, habe jetzt hier was zurückbekommen. Hello Jens und dann eben eine Nachricht mit Emojis, die irgendwie ganz freundlich sind und dann unten irgendwie noch ein Funfact über Octopus in dem Fall. Und ja, das finde ich sehr, sehr spannend. Und ich habe mir da natürlich auch direkt gedacht, okay, wo oder wie könnte man dieses Framework jetzt mal einsetzen und mal wirklich in einem echten Projekt testen? Und was ich nach der letzten Folge erstellt habe, ist einen

speaker-1: ...

speaker-0: einen Agent Skill, ich kann den mal hier aufmachen, und zwar heißt der New Episode. Und da geht es wirklich darum, für unsere Website, zwischenstacks.de, dass wir da immer zu jeder Folge so eine Art, ja, nochmal so eine textuelle Zusammenfassung eben hochladen wollen. Das haben wir auch für die letzte Folge schon gemacht. Könnt ihr auch gerne mal reinschauen, wo wir dann auch nochmal Dinge verlinken können, Bilder reinpacken können. Und ja, mittlerweile macht man sowas ja nicht mehr per Hand, dass man das Skript einmal oder das Transkript einmal zusammenfasst, sondern Ich habe jetzt in dem Fall dafür so ein Skill erstellt, der wirklich einmal den ganzen Prozess beschreibt. Das heißt, dass einmal der RSS Feed eben bezogen werden soll. Ich kann das auch mal hier in Markthorn Preview öffnen. Genau, also hier ist der Prozess. Hier wird beschrieben, okay, die URL von dem RSS Feed, was der Agent herauslesen soll. Dann, dass er diese Content CLI benutzen soll, ⁓ zu schauen, was für Episoden haben wir schon in unserem CMS von der Website. Und dann eben Das Transkript durchgeht, es zusammenfasst und uns dann in einen Wurf erstellt in unserem CMS, den wir dann einmal nochmal durchgehen können, reviewen können, ⁓ zu schauen, ok, passt der, dann können wir noch ein paar Bilder einfügen und fertig. Aber da sind zumindest schon mal dieser ganze lästige Prozess abgenommen wird, uns diese ganzen Infos zusammenzusammeln. Und das haben wir jetzt gerade in unserer Codebase als Skill. Und den könnte man dann einfach über Cloud Code zum Beispiel aufrufen, bei sich lokal im Terminal. Und was jetzt cool wäre mit Flu, und das werde ich auch definitiv mal ausprobieren. Ich habe es mal kurz hier gedraftet, wie das aussehen könnte. Man könnte sich jetzt ganz einfach dafür einen Agent erstellen, der dann auch New Episode heißt. Und da könnte man dann definieren, was für ein Modell soll eben verwendet werden. In dem Fall jetzt Cloud Sonnet 4.6. Und dann würde man wirklich einfach nur den Skill referenzieren und kurz einmal sagen, was sind die Was ist der Input? Was ist der Output? In welchem Schema? Und dann könnte man das auch, wie ich es hier eben gesehen habe, über einen Webhook zum Beispiel dann triggern, sodass wir zum Beispiel sagen, nach jeder Veröffentlichung der Folge läuft das einmal automatisiert durch. Dauert dann einen Moment, wir müssen nichts dafür tun, wir müssen kein Terminal irgendwie offen haben und können dann im Endeffekt einmal ins CMS reinschauen, das nochmal überarbeiten, hochladen und fertig. Und das fand ich ja vom vom Konzept irgendwie ziemlich cool, dass man wirklich da solche Frameworks vielleicht in Zukunft benutzt für.

speaker-1: Ich finde, klingt erstmal voll, also wenn man es sieht, klingt es erstmal so bisschen einfach. Aber ich glaube, jetzt während du so gesprochen hast, habe ich gemerkt, wie mächtig das eigentlich auch sein kann. dass das so ein bisschen, ich hatte jetzt so so ein Gedanke kam mir, dass das wie so ohne Prompt AI verwenden eigentlich ist. Also viel strukturiert das Verwenden von verschiedenen Modellen und so weiter. Das ist schon ziemlich cool.

speaker-0: Ja, ich denke, da steckt wirklich sehr, viel dahinter. Und die haben auch viele... Ja, du kannst auch sehr, viele Dinge und eben anbinden. Also zum Beispiel habe ich auch gelesen, ich meine Astro wurde ja vor ein paar Monaten von Cloudflare gekauft eben. Und Cloudflare hat ja auch viele Produkte, wo es eben ⁓ Sandboxes geht, wo du deine Agents davon laufen lassen kannst oder auch diese ganzen anderen... Produkte, die die Cloudflare anbietet, ⁓ irgendwie Daten zu speichern. Und da gibt es dann natürlich auch gewisse Konnektoren, dass du dann auch diesem Agent so eine Art Gedächtnis oder so eine Ort gibst, wo er eben Dinge abspeichern kann, damit er eben in den weiteren Sessions wieder darauf zugreifen kann. Und das ist, ich, auch sehr, mächtig.

speaker-1: Gehen wir an. Echt spannend.

speaker-0: Ja, und ich werde dann mal bei der nächsten Folge berichten, wie dieser neue Episoden Agent mit Flu dann funktioniert.

speaker-1: Zuschauer werden es sehen.

speaker-0: Genau.

speaker-1: Cool. Ich glaube, dann sind wir so weit thementechnisch durch für heute. lange Folge, ich habe nicht so das Gefühl. 54 Minuten bis jetzt. ja, danke Jens auf jeden Fall auch für deine Themen. Ja, danke dir. Ich hoffe, dass es für die Zuschauer, Zuhörer spannend war. Ich hoffe, dass es auch für die Audio-Only, also für die Zuhörer, ein bisschen besser war, dem Ganzen zu folgen. Wir versuchen tatsächlich auch aus dem Podcast vielleicht jetzt ein paar Reels zu machen. Wir versuchen ja immer in zwei Wochen Takt jetzt zu veröffentlichen und dass wir dazwischen vielleicht mal ein paar Sachen so rausschneiden und die als Reels veröffentlichen oder als Videos veröffentlichen. Genau, mal gucken, das klappt. sind dran. Und ansonsten wollte ich noch sagen, freue ich mich sehr, wenn wir weiterhin so Feedback bekommen. Ja, ich muss natürlich jetzt irgendwie auch sagen, es wäre cool, wenn ein Leute Bewertungen auf den Plattformen hinterlassen. Also ich fange jetzt mal an mit diesem Satz. Also wenn ihr auf Spotify oder Apple Podcasts oder auf YouTube hört, wir freuen uns über jeden, der den Folgenbutton klickt und einen Kommentar hinterlässt und eine Bewertung. Und das wäre richtig cool. Ja, ich glaube, das gibt uns so jede Bewertung, jeder Kommentar, jeder Follower ist jetzt ein kleiner Boost für uns immer so am Anfang.

speaker-0: Genau.

speaker-1: Cool. Jetzt hast du noch was zu sagen.

speaker-0: Ich fand es richtig spannend heute und freue mich echt auf die weiteren Folgen und vor allem auch, wie du sagst, auf das Feedback von unseren Zuhörern und Zuschauern. Dann sehen wir uns auf jeden Fall in zwei Wochen nochmal zur nächsten Folge.

speaker-1: So ist es. All eine gute Zeit, dass dahin.

speaker-0: Bis dann, ciao!