Skip to content
Melo Podcasts Home
CategoriesLanguagesFollowing

Episode 721 · Working Draft

Revision 721: Designsysteme, Headless CMS und KI-gestützte Content Operations. Mit Jonas Ulrich

21 Jul 2026 · 1 hr 10 min

Play episode WhatsApp Download

Episode notes

Wir sprechen mit Jonas Ulrich von der Ruhmesmeile in Bonn über Designsysteme, Headless-CMS-Workflows und darüber, warum kickstartDS nicht nur als Komponentenfundament, sondern auch als strukturierte Wissensbasis für KI-gestützte Redaktionsarbeit interessant ist. Nachdem Jonas bereits in Revision 538 und Revision 607 bei uns zu Gast war, schauen wir diesmal darauf, wie sich Designsysteme, JSON Schema, Model Context Protocol und Headless-Systeme wie Storyblok zu einem Workflow verbinden lassen, der Frontend, CMS und Redaktion enger zusammenbringt. UNSER SPONSOR Im Webcafé, dem Podcast zu…

Transcript

Read the transcript · about 12,320 words, follows along as you listen

Wie müssen Bilder und Text positioniert sein? Wie bleibt das accessible und so? Das sind sehr übergreifende Themen, wenn ich über Websites rede. Und deswegen hat sich es da so angeboten zu sagen, das können wir einfach schon schlüsselfertig mitgeben. Wenn das halt so adaptiv ist, dass wenn was Neues aufkommt, es halt weiter Sinn macht. Dass es jetzt so viel Sinn macht, ist auch irgendwie Glück natürlich. Es beweist irgendwie trotzdem so eine gewisse Resilienz, die in so einem Konzept drin steckt.

Wir haben alles, was wir machen, sehr bewusst an Storyblock drumherum vorbei gebaut. Wenn du später mal von Storyblock zu Sanity wechseln möchtest, wir wollen nicht der Grund sein, dass dein Frontend jetzt damit sterben muss. Diese Revision von Working Draft wird euch präsentiert von Webcafé, der Podcast zu Webentwicklung, Webdesign und Unternehmenskultur. Liebe Hörerinnen, liebe Hörer, falls ihr auf Podcast zu Webentwicklung steht, und ich habe da ja so einen Anfangsverdacht, dann möchte ich euch an dieser Stelle ins Webcafé einladen.

In diesem Podcast nehmen euch die Hosts Felix und Kai jede Woche mit auf eine Reise quer durch den Arbeitsalltag einer Agentur. Das berührt alles zwischen PHP und TypeScript bis hin zu Herausforderungen der Unternehmens- und Personalführung. Webcafé ist nicht ganz wie Working Draft. Es geht nicht permanent um technisches Tieftauchen und Felix und Kai tun auch alles, um auch Junioringe, Programmiererinnen und Programmierer sowie nicht-technisches Führungspersonal abzuholen.

Klingt gut? Dann hört rein! Das Webcafé findet ihr auf webcafé-podcast.de und überall sonst, wo frische Podcasts angeboten werden. Das war nochmal. webcafé-podcast.de oder die Podcast-Plattform eurer Wahl. Wir danken Webcafé für die Unterstützung von dieser Revision von Working Draft. Revision 721. Wir werden heute zu zweit. Aus dem Team bin nur ich dabei, der Shep. Und das bedeutet, wir haben einen Gast. Und zwar ist das der Jonas Ulrich. Hallo Jonas. Hallo. Schön, wieder da zu sein.

Genau. Du deutest es an. Du warst schon zu Gast, nämlich ganze zweimal. Und dieses Mal war ich ganz überrascht, dass es gar nicht so lange her ist. Also jeweils immer im Zweijahrestakt. Das heißt also, 24 warst du als Gast da und 22. Man könnte dich noch kennen aus diesen Aufnahmen, aber vielleicht ist auch einiges wieder verschütt gegangen gedanklich und deswegen erzähl doch nochmal, wer du bist und was du oder was ihr macht. Genau, also, mein Name ist Jonas, ich komme ursprünglich mal aus Paderborn, bin zum Studium dann nach Bonn gezogen, da so meine Liebe für die Informatik entdeckt, würde ich behaupten und in nächster Instanz dann auch die Liebe für die Webentwicklung, recht früh mit Kollegen aus dem Studium entschlossen, selber eine Firma zu gründen.

Und wenn ich das jetzt ganz verkürzt sagen will, sind wir da immer noch. Also diese Firma gibt es immer noch, da arbeite ich immer noch. Auf dem Weg natürlich viele Stationen mitgemacht von kleinen Handwerkerseiten zu quasi Service Agentur mit durchaus auch einer Reihe Mitarbeitern. Dann 2021 einen starken Pivot gemacht hin eher zu so einer, ich würde sagen, Beratung und Boutique Entwicklungsagentur, die versucht recht früh in Prozessen andere Unternehmen in ihren Entscheidungen zu beraten, immer noch im Frontend-Bereich und auch dann in dem Kontext, in dem wir hier in dem Working Draft schon zweimal zusammengekommen sind, nämlich Designsysteme.

Also so ein bisschen spezifischer, wie kann ich nachhaltig, strukturiert an meine Frontendentwicklung drangehen, sodass ich vielleicht nicht alle zwei Jahre alles neu machen und wegschmeißen muss und da ein langatmiges Asset für mich irgendwie erhalte. Das ist so. Meine Passion, würde ich auch sagen, war schon eher der technische Hut auf meinem Kopf gewesen, und dementsprechend sehr daran interessiert, wie kann man Frontend bauen, wie braucht man performantes Frontend, zugängliches Frontend und all die vielen Aspekte, die man, wenn man das aus unserer Sicht professionell machen möchte, eigentlich heute auf dem Schirm haben sollte.

Ja, es sind ja weichlich Challenges. Sonst gäbe es ja auch unseren Podcast wahrscheinlich nicht mit so vielen Ausgaben, wenn es da nicht so viele Facetten gäbe, die man da irgendwie einfließen lassen kann. Selbst auf UI beschränkt. Ich habe mittlerweile dann schon irgendwie Action-Script geschrieben, um irgendwelche Flex-Anwendungen zu bauen in Flash im Grunde Zeit, hin zu irgendwelchen FAT-Clients mit Java, die über APIs arbeiten. Also da hat sich auch so viel getan im Laufe der Zeit, einfach nur in der Art der Arbeit, also gar nicht so sehr in dem Ergebnis, was rauskommt, sondern die Art, wie man das Ganze tut, dass es einfach aus der Sicht allein schon, finde ich, immer noch ein super reizvolles Gebiet ist, auch wenn es für manche vielleicht nicht erklärlich ist, warum es da anderen was Neues gibt.

Ich finde das schon immer noch auch eine nette Sache. Ja, und es ist ja dann doch überraschend schwer, also gerade so auf den letzten Metern was Gutes zusammenzubringen, also dass es sich gut bedienen lässt und barrierefrei ist und so. Also das ist so ein bisschen wie dieses goldene HiFi-Kabel, wo der Preis dann exponentiell steigt, um irgendwie wirklich dann ans Limit zu kommen. Ob man das dann immer braucht, das steht natürlich auf einem anderen Blatt.

Das ist dann kontextabhängig. Das ist vielleicht auch eine gute Analogie. Also ich würde sagen, bei Designsystemen ist das sehr ähnlich. Nicht jeder braucht halt auch ein Designsystem. Das ist auch ein großer Fehler, ein Designsystem zu starten, wenn ich gar keins benötige. Weil dann ist es im Kern vor allem Overhead, den ich nicht gebraucht habe. Ja, wenn du die Ernte nicht einfallen kannst, ne? Genau. Also wir reden da schon über Projekte und Kunden, die eine gewisse Größe haben, sodass sie davon auch nachhaltig profitieren können überhaupt.

Und sonst würden wir auch jemandem gar nicht dazu raten, ein Designsystem aufzubauen. Aber dann liefert es eben sehr gute Antworten darauf, wie man eben doch skalierbar Qualität einhalten kann, auch in größeren Projekten und auch nachhaltig sein kann, was ja häufig irgendwie, zumindest meiner Wahrnehmung, immer noch nicht so gelebt wird. Also ich sehe immer noch sehr, sehr viel Frontend-Churn, wo eigentlich jedes Mal das meiste weggeschmissen wird, wenn ein neues Design rankommt.

Und das ist halt was, was ich sehr schade finde, wenn man sieht, wie viel, und manchmal auch in solchen Projekten schon, wie viel User-Research und wie viel Arbeit eigentlich in ein Interface reingeht, wie schnell das dann doch aber wieder verworfen wird, wenn was nächstes ansteht. Und das finde ich ist einfach schade und nicht sehr nachhaltig. Und macht es dann so teuer auch. Deswegen ist es dann auch so teuer. Wenn ich all diese Schritte immer wieder durchlaufen muss, ja gut, dann wird es immer jedes Mal wieder sehr teuer sein. Ich sehe das immer so ein bisschen so.

Dass es auch so ein bisschen so ein Goodie, dass sich diese Firmen dann leisten, das alles neu zu machen, weil sie es einfach möchten. Die möchten dann nicht so eine Stange haben. Die möchten das eben nach ihren Wünschen, nach ihrem Design haben. Ist nicht effizient. Aber wenn die die Zeit und das Geld haben, dann können sie sich das eben gönnen. Aber weiß ich halt nicht, ob sie es sich hinten raus dann wirklich immer gönnen können, wenn man sich die Ergebnisse manchmal anguckt, weil es dann halt schon schwierig ist, das so nachhaltig zu tun und, Ja, aber es ist komisch, also wir kaufen ja Autos von der Stange, können Farben auswählen, ein paar Extras und so, zunehmend weniger.

Mittlerweile sind das ja alles nur noch irgendwie so zwei oder drei Paketlinien, wo alles drinsteckt. Aber bei Frontend hat man so einen Reflex. Das Rad neu zu erfinden. Ob das dann immer gut ist, ist halt die Frage. Also was wir merken, ist so ein bisschen, die Leute merken halt, dass man es sich oft nicht leisten kann. Also ganz banal kommt man dann mit den Euro-Zeichen doch immer nochmal durch Türen durch, weil die Leute halt merken, ja gut, dann kann ich es ja doch vielleicht erstmal sehr günstig ausprobieren und muss es gar nicht so teuer machen.

Wenn ich es dann nicht gut finde, lasse ich es halt sein und so kriegen wir dann zumindest den einen oder anderen doch geködert, auch wenn er erst denkt, was dann viele ab einer gewissen Größe leider denken, dass sie so unik sind, dass das alles bespoke sein muss. Das muss alles genau für mich hergestellt sein. Am Ende bezahlen will das aber wirklich quasi keiner. Ja, da muss natürlich die Telekom sein. Und dann, ja, okay, fair. Die Telekom soll halt immer ihr Ding machen. Das ist auch völlig okay, aber da kann man sich jetzt schwer mit vergleichen.

Ja, klar. Ja, da gibt es nicht viele Firmen. Also die Deutsche Bahn wäre vielleicht noch so eine Firma. Ihr seid aber da auch in einer guten Position, deswegen wart ihr auch schon zweimal bei uns zu Gast. Also euer Hintergrund ist ja der, dass ihr als Agentur im Grunde euer internes, Designsystem aufgebaut habt, weil ihr auch für euch natürlich gesagt habt, das ist ja irgendwie nicht so ressourcenschonend, wenn wir immer alles neu bauen müssen und das ist halt auch irgendwie nervig.

Also warum sollten wir das tun? Und kumuliert ist das darin, dass ihr tatsächlich ein schlüsselfertiges Designsystem hingestellt habt. Kickstarter-TS heißt das. Und warum ich das erzähle, ist, und du hast es eben angedeutet, dass, glaube ich, dass ihr dieses Designsystem schon habt und man das eben sofort einsetzen kann, können auch kleine Kunden, das hatten wir in der Vorbesprechung auch besprochen, also nicht nur die Großen, die das eben skalieren können, sondern auch kleine Kunden, die eben so, ein Proof of Concept bauen müssen, können eigentlich mit diesem Designsystem, was ihr kreiert habt, relativ schnell an den Start gehen und eben schauen, ob das Produkt irgendwie taugt oder nicht und das aber auch eben in einer sehr hohen Qualität, also eben nicht dahingerotzt, sondern eben aufbauend auf.

Den Schultern von Giganten, die eben alle Kunden vor ihnen und eben euer Know-how sind. Ja, das kann man gut so zusammenfassen, würde ich auch sagen. Und was man auch sagen muss, ist natürlich, dass wir jetzt nicht für jeden die perfekte Website dann mitbringen können mit so einem Designsystem, weil da logischerweise irgendwo der kleinste gemeinsame Nenner ja immer drinstecken muss in etwas, was immer wieder verwendet wird. Und was wir halt nur gesehen haben, ist, wenn wir den kleinsten gemeinsamen Männer-Performance-Marketing, Marketing-Pages und so weiter uns anschauen.

Dann ist das wahrscheinlich sogar wahr. Also die sehen wirklich tatsächlich alle, wenn man sich den Aufbau anguckt der Informationen, alle gleich aus. Natürlich sind die leicht anders angemalt und haben hier mal noch irgendwie einen Schnörkel dran, wo der andere es nicht hat. Aber im Kern, jetzt mal so, die Informationen, die man sich anschaut, reduziert, sind die tatsächlich gleich, weil es einfach nur darum geht, wie kann ich effektiv Informationen kommunizieren und da unterscheidet es sich jetzt eigentlich nicht groß, ob ich eine Bohrmaschine in der Hand halte, oder eine Finanzdienstleistung verkaufe.

Da geht es dann darum, wie müssen Bilder und Text positioniert sein? Wie muss sich das Responsiv-Fruit korrekt verhalten? Wie bleibt das Accessible und so? Das sind sehr übergreifende Themen, wenn ich über Websites rede. Und deswegen hat es sich da so angeboten zu sagen, das können wir einfach schon schlüsselfertig mitgeben. Und den ganzen Rest, der spezifisch ist, den kannst du dir dann noch zubauen. Und dann hast du den riesen Vorteil, es ist ein Design-System, es ist super regelbasiert.

Im Grunde musst du nicht rätseln, wie du jetzt eine neue Komponente hinzufügst, sondern es ergibt sich ganz automatisch aus der Systematik schon so. Und das ist die Herangehensweise. Wir wollen jetzt auch nicht das nächste Bootstrap sein, wo dann 20 Komponenten drinstecken und alle nutzen nur die und der Rest ist dann wieder nur Individualisierung. Wir wollen schon, was die Leute selber nachhaltig frontend bauen dann mit ihrer Lösung. Ja, also die Anschubhilfe sozusagen, ne?

Was du auch erzählt hattest in der Vorbesprechung, was ganz interessant ist, ist, ihr macht viel zusammen mit Story-Blog. Ja, egal welchen von beiden du jetzt nennst, Story-Book oder Blog, mit beiden machen wir viel. Ja, ja, genau. Da muss ich manchmal so kurz, nicht das Falsche sagen, ja, genau, Blog. Genau, Story-Book macht ihr natürlich als Design-System auch viel, zumal ihr ja, glaube ich, also wenn ich mich recht erinnere, Also seid ihr ja auf, lauft ihr auf React, ne? Ja, genau. Oder ist das auf React aufgebaut?

Und genau, und das ist natürlich sehr Storybook-kompatibel. Das ist halt super supported, ne? Absolut. Und wir sind auch lange schon mit den Core-Maintainern connected, haben da einen ganz guten Draht. Also das hat schon immer Spaß gemacht, damit zu arbeiten. In Kundengesprächen ist es leider trotzdem der totale Fluch, weil beide sind öffentlich wirkbar in unserer Kommunikation und alle sind immer verwirrt. War es jetzt das Storybook? War es das Storybook? Das ist wirklich zu ähnlich. Ja. Ja, ja.

Es ist eigentlich witzig. Also es ist witzig, dass es das so gibt. Es ist auch schön, dass sie sich nicht gegenseitig irgendwie aufs Maul hauen, dass sie zu nah beieinander sind vom Namen her. Nee, nee. Ich habe es noch nicht mitgekriegt zumindest. Ja. Aber sie ergänzen sich ja auch, wie du sagst, ganz gut. Sind auch gar nicht so unähnlich. Also mir ist das schon mal aufgefallen, wenn man sich sowas wie Storybook anguckt und solche Systeme, die Storyblock, die sind ja meistens auch Multiframework.

Also Storyblock ist ja headless. Also sagt ja gerade, dein Frontend diktiere ich dir eben nicht. Wenn du nicht React benutzen willst, dann benutze halt nicht React. Und wenn du dein eigenes erfundenes Framework nutzt, dann nutze halt das. Es ist eine REST-Stelle. You do you, so ungefähr. Das ist uns eigentlich nicht wichtig. Und dann bieten sie auch SDKs in allen Sprachen an. Das finde ich schon wiederum auch ganz nett zu sehen bei allem React-Fokus, den es gibt.

Und wir sind auch, wenn man so will, Teil des Problems. Aber dann ist es schön, eine gewisse Vielfalt repräsentiert zu sehen in diesen Ansätzen. Und auch das finde ich persönlich einen großen Vorteil an Headless-Systemen, dass sie halt dem Team die Entscheidung zur Technologie ein Stück weit offen lassen, während ja so diese klassischen Monolithen, ob es jetzt WordPress, 2.3, Drupal sind, das hat sehr festgelegt. Klar, die kannst du dann alle auch vielleicht im Headless-Modus betreiben und dann ist das ähnlich, aber das ist nicht ganz so connected, nicht ganz so nativ im Gefühl.

Die sind halt nicht so von Grund auf dafür gebaut worden. So wie so ein Elektroauto, das so eigentlich ein Verbrennermodell war, das dann so retrofitted, wo das immer noch ein Kader am Tunnel mittendrin hat, den man nicht braucht und so Zeugs. Ja, das ist richtig, das ist ein guter Vergleich, ja. Wir haben auch viel mit Storybrock zu tun. Das ist so ein bisschen das aktuellere Thema bei uns, würde ich fast sagen, nachdem wir gemerkt haben, dass Designsysteme zwar total schön und auch aus solch total wichtig sind, aber jetzt auch nicht das Erste sind, nachdem jemand fragt.

Und wenn man mal den Vergleich gelesen hat, Designsysteme sind wie eine Versicherung. Die hast du gerne, wenn es darauf ankommt. Aber vorher merkst du gar nicht, dass du sie gerne hättest. Wenn der neue Designer kommt und sagt, das muss jetzt alles so aussehen, dann hättest du gerne ein Designsystem, um zu verstehen, was überhaupt zu tun ist. Bis dahin bist du schwer davon zu überzeugen, dass du es brauchst. Und das ist auch so ein bisschen das, was wir auch gemerkt haben.

Und selte Systeme sind halt ein ziemlicher Natural Fit für Designsysteme. Gerade React-basierte Designsysteme noch umso mehr, weil da sehr, sehr viel an Ökosystemen existiert. Und das ist seitdem so ein bisschen unser neuer Fokus, irgendwie Integration, könnte man es nennen, für von uns entwickelte oder auf unserem Best-Practice-Ansatz basierende Designsysteme automatisch in bestimmte andere Systeme zu integrieren. Und das sind jetzt primär auch bei unserer Historie, wir haben vorher Typo 3 gemacht, wir haben immer schon Websites gebaut, sind es auch weiterhin Websites und da dann eben Headless-Systeme.

Die sich dann eben auch auf einer zweiten Ebene nochmal irgendwie konzeptuell deutlich mehr mit unseren Ideen etwas teilen als jetzt die klassischen Websysteme, weil sie fast alle auch schon selber JSON-basiert denken. Das heißt, irgendwie deinen Inhalt schon auf und die haben da jeder ihre eigene Struktur, die sind auch alle ganz kreativ dabei. Am Ende bricht es aber alles aufs Gleiche runter, weil JSON halt jetzt auch nicht beliebig kompliziert als Format ist. Es gibt Objects, Arrays, Strings, Integers und dann war es das auch schon bald mit so ein paar Haken und Ösen noch. Ja.

Die landen eigentlich alle beim selben Feature-Set am Ende des Tages. Und das ist, was wir halt früh gesehen haben und gesagt haben, okay, wir haben JSON-Schema, wir beschreiben selber schon super strukturiert, das ist unser Hero, der Hero hat ein Title, ein Title ist vom Typ String oder vielleicht sogar Markdown oder so. Dass diese Informationen sich perfekt eignen, um so eine CMS-Konfiguration halt nicht komplett von Hand anlegen zu müssen. Sprich, nicht den riesen Aufwand zu haben, da in dem System irgendwie.

Dass es 15 Komponenten sein, die jeweils irgendwie 10 bis 15 Einstellungen haben, dass du einfach schon arbeitest, das auf Stand zu halten. Und das Zweite, was wir oft gesehen haben in solchen Systemen, ist, dass es dann auch so einen Drift gibt. Das heißt, die Entwicklung im Frontend arbeitet an den Komponenten dort und die Redaktion oder vielleicht die Administrationsebene der Redaktion arbeitet über die Strukturen im System und dann läuft das auseinander.

Weil es ja eben dann doch nicht so einfach ist, mal eben ein Feld im Headless-Thema hinzuzufügen und dann zu sagen, ja, aber wo ist es denn jetzt im Frontend? Sondern es muss ja schon noch irgendwer hin und es verdrahten. Und auch da haben wir gesehen, dass es halt super nützlich ist, diese Quelle der Wahrheit im eigenen Repository liegen zu haben. Also die Schema-Beschreibung deiner Designsystem-Komponenten als Contract tatsächlich zu verstehen, der für alle definiert, wie sieht das aus.

Und da haben wir gesehen, dass das einfach in diesen Headless-Systemen allgemein sehr, sehr gut zusammengeht, könnte man so sagen. Also auch belastbar ist. Du kannst dann auch in deinem Schema ein Feld ergänzen, lässt den Converter drüber laufen, lässt den das wieder reinpushen ins System, dann wird auch nur das Feld ergänzt. Das ist jetzt nicht so ein reines Bootstrapping-Tool, sondern ist aus unserer Sicht schon so ein echter Connect an der Stelle, der auch aufrechterhalten bleibt im Projekt.

Ja, das heißt also, ihr im Grunde eure Herangehensweise ist, also wenn ich das richtig verstanden habe, ihr. Assembliert im Grunde ein Frontend, wie ihr das braucht auf Basis des Designsystems und dann, wenn ihr sozusagen, das macht ihr halt mit irgendwie Dummy-Daten wahrscheinlich erstmal, um so Prototypen zu bauen, wenn ihr das habt, Dann könnt ihr auf den Knopf drücken und in Anführungszeichen wahrscheinlich, also idealerweise ist es nur ein Knopf, und ihr konfiguriert euch euer Headless-System dann, also die Datenstruktur darin, so wie die Anforderungen des eben gerade eben konzipierten Frontends das erfordern. Genau.

Also man kann sich das so vorstellen, es gibt so ein paar allgemeingültige Konzepte. Das ist jetzt auch nicht mehr rein Designsystem spezifisch. Ich würde sagen, Designsystem enthält erstmal schon Komponenten. Jetzt über Page-Templates reden, wenn man zumindest mich persönlich fragen würde, würde ich sagen, die haben im Designsystem nichts zu suchen, weil die sind schon anwendungsspezifisch. Die sind irgendwo weiter downstream im Prozess. Die sind eher in einer der Systemintegrationen beheimatet.

Und nichtsdestotrotz schreiben wir auch die halt mit JSON-Schema. Das heißt, du kannst wahrscheinlich, da gibt es eine Page.schema.json, und da drin steht, die hat irgendwie einen Titel, eine Description und irgendwie Sections. Und das ist jetzt so eine Art, wie wir halt schon sehr lange Seiten bauen, dass du im Grunde immer so Slices untereinander setzt, so Sections, und in den Sections dann deine Komponenten platzieren kannst. Eine Section kann dann irgendwie Sachen nebeneinander anordnen, Sachen untereinander anordnen, einen Slider daraus machen.

Es ist erstmal quasi die kleinste mögliche Layouting-Einheit, die dann auch ihr responsives Verhalten vor allem mitbringt. Und in die setzt du halt Komponenten ein. Und diese Struktur ist halt komplett im JSON-Schema schon definiert. Auch diese Abhängigkeiten dazwischen. Und so einen Konverter sagt man dann im Grunde, es gibt bei uns das Page-Template, das Blog-Template, das. Job-Template vielleicht noch und dann weiß das eben, das sind drei Template-Typen, der Rest sind Komponenten-Typen und kann das dann genauso zusammenbauen, dass der Redakteur auch genau diese Komponenten zur Verfügung hat, wenn er was baut.

Bei einem Block zum Beispiel ist das jetzt etwas weniger offen als bei einem reinen Page-Bilder, Vending-Page, würde ich mal sagen, weil da hast du dann sowas wie den Block-Header oder das Block-Assight-Modul, wo der Autor nochmal drinsteht. Das heißt, das ist an sich etwas weniger dynamisch, folgt aber der gleichen Systematik. Es gibt dann ein Blog-Schema-Json und da steht dann drin, das Aside ist dann die Referenz auf das Blog-Aside-Komponenten-Modell.

Und so dekompositioniert sich das quasi. Und das ist dann das, was genau so auch im CMS für den Redakteur verfügbar wird. Ja. Aber du hast es schon richtig gesagt. Wir nutzen das auch beim Storybook, um mit Demodaten schon mal irgendwie so ein bisschen Exploration zu machen. Das sind dann Sachen, die kann man dem Kunden schon mal zeigen. Er kann da drauf gucken und sagen, nee, das gefällt mir gut, jetzt wollen wir den Schritt weiter gehen. Es lässt auch so ein gewisses schrittweises Arbeiten zu, was an der Stelle tatsächlich echt ganz wertbringend ist.

Ja, ich mache das auch immer ganz gerne so, dass sie sozusagen. Erst mal im Frontend klar werden, wie wir es haben möchten und dann wir dann die Datenstrukturen irgendwie. Dem Backend vorgeben, die wir brauchen, weil andersrum sind die vielleicht irgendwie nicht so zusammensortiert oder sehr umständlich kopiert, sodass wir uns die zusammensuchen müssen. Oder es sind halt zu viele Daten, von denen wir am Ende merken, dass wir gar nicht alles brauchen oder auch natürlich dann Datenfelder, die uns fehlen, die das einfach nur merken, weil wir das Frontend eben.

Gebaut haben und wir dann sehen, oh okay, dann das bräuchten wir dann noch, weil wenn wir die Daten nicht haben, dann können wir das nicht, also dann können wir nichts nach Datum sortieren, wenn wir das Datum nicht bekommen oder irgendwie so Dinge. Also auch das merken wir. Es ist super, weil es ist nicht rein technisch. Also klar, JSON-Schema, wenn ich das jetzt als Wort sage und jemanden ein JSON-Schema sieht, dann ist es todestechnisch und der rennt weg wahrscheinlich, aber wenn man es vernünftig erklärt und rüberbringt, ist es gar nicht technisch.

Es geht genau um diesen API-Contract Und es geht eben genau darum, dass alle sich einig darüber werden, welche Felder braucht es. Und dazu zählt eben auch, welche Felder müssen aus dem Backend-Bob geliefert werden. Gibt es da Missverständnisse? Und das sind Gespräche, die führt man besser nicht, wenn man schon 20 Rack-Komponenten gebaut hat, weil dann wird es sehr traurig und teuer im Zweifel, weil dann ist es meistens zu spät oder dann wird es ineffizient und es müssen sehr komische Wege gegangen werden.

Also auch da, es hat einen echt bereinigenden Faktor über diese Struktur, unabhängig von, ist es grün oder blau, sieht es so aus oder so, einfach möglichst früh nachzudenken und die richtigen, Stakeholder an den Tisch zu holen, weil man sich damit so viel Ärger hinten raussparen kann und Missverständnisse. Und. Ich stelle mir das so vor, dass es zu Beginn noch eher ein bisschen. Dynamischer ist in der Form, als dass ja da vielleicht auch noch mehr Bewegung ist und vielleicht das Setup des Headless-CMS vielleicht hin und wieder nochmal auf links gedreht wird.

Und dann kommt ja wahrscheinlich ein bisschen Ruhe rein, wenn man so dann weiß, wo man hin will. Aber wenn man dann irgendwann später doch nochmal erweitern muss, dann geht das wahrscheinlich mit eurem Ansatz auch eher non-destruktiv, also dass man eben einfach mit eher Datenfeldern hinzufügt. Und genau, da gibt es jetzt ganz viele kleine Disclaimer-Sternchen, die man da wahrscheinlich dran machen könnte und müsste, weil es einfach bestimmte Szenarien gibt, wo das nicht destruktiv funktioniert.

So Klassiker, der eine benennt es um, der andere benennt es auch um. Wer hat jetzt recht? Jetzt hast du plötzlich eine Race Condition und die sind nicht trivial bis gar nicht auflösbar teilweise, diese Fälle. Aber wir haben halt sehr viel reingesteckt, dass die Fälle möglichst selten auftreten können. Zumal wir eigentlich, wie gesagt, sagen, du solltest im Atlas-CMS selber gar nicht die Konfiguration anpassen. Das ist in dem Moment tatsächlich einfach eine Engineering-Aufgabe, weil, wie gesagt, auch wir nie gesehen haben, dass das Sinn macht, dass jemand nur das Schema in einem Atlas-CMS anpassen kann, weil es hat gar keine Auswirkungen auf das Frontend und das Rendering.

Es ist ineffektiv, es bringt gar nichts, es macht andersrum einfach viel, viel mehr Sinn so. Wo wir wieder beim Contract sind, den du vorhin genannt hattest. Und der hat halt viele Vorteile. Wir haben auch schon den einen Kunden gehabt, ein größeres NGO. Die sind mal gestartet mit reinen React-Templates, die sich zusammen kopiert haben, auch schon mit solchen Blöcken damals. Die sind dann auf Netlify Create umgeschrieben, weil das irgendwie so als Lösung für die ganz cool war, weil die haben eben Markdown geschrieben.

Das Create von Netlify kann mit Markdown direkt arbeiten, hat dann einen Visual Editor dafür. Das war ein paar Jahre ein super System, dann ist das aber auch nicht wirklich weiterentwickelt worden, sind teuer geworden und jetzt sind die halt auch vor ein paar Monaten auf Storyblock gewechselt und die haben ja nicht einmal ihr Design weggeschmissen. In der Zwischenzeit haben sie ein Corporate Rebranding durchgemacht, welches auch im gleichen System stattgefunden hat.

Das existiert jetzt einfach seit sieben Jahren, dieses Frontend. Man könnte das schon so ein bisschen Schiff von Tesois-mäßig fragen, ist es eigentlich noch das gleiche Frontend? Weil irgendwie ist gefühlt jeder Part außer die Systematik mittlerweile ausgewechselt in der Zwischenzeit. Aber es war für die super effizient. Die waren immer super glücklich, dass das schnell ging und so. Das ist in dem Moment dann tatsächlich ein Wert, sowas in der Hand zu halten. Das ist dieser Versicherungsaspekt.

Wenn es dann eintritt, dann ist es irgendwie echt cool. Und wenn man das ein paar Mal zeigen kann, dann gewinnt man auch Kunden sehr schnell für sich. Ja, hört sich auf jeden Fall gut an. Und vielleicht müssen wir noch mal erzählen, wie wir jetzt hier zusammengekommen sind. Und zwar hatten wir bei uns im internen Slack einfach mal rumgefragt, ob irgendwer interessante Themen für uns hätte oder sich gerne selbst einladen wollen würde. Da hast du dich jetzt nicht gemeldet aber dein Mitstreiter der Daniel und der hatte einfach mal natürlich auch, aktuellen Zeiten entsprechend standesgemäß gepitcht KI im Zusammenspiel von Headless CMS und Design System und, ich weiß nicht was ihr macht und ich kenne KI im Zusammenhang mit Design System eigentlich immer eher so aus dem Umfeld Figma und Figma-MCP und dann bauen die da irgendwelche.

Visuellen Design-Systemen zusammen. Aber das wirst du mir gleich bestimmt erklären. Und ich vermute, dass einfach diese JSON-Schema und all diese Dinge natürlich sehr so an einem Experimentieren mit KI in dem Bereich total in die Hände spielen, oder? Genau, also das kann man ziemlich gut so sagen, ja. Also was du angesprochen hast, das beobachten wir auch viel und probieren wir auch viel aus. Also so Richtung UI-Generierung. Wie kann ich da vielleicht mit Figma-MCPs oder wie auch eigenen MCPs die eigene Entwicklung von Komponenten beschleunigen?

Und auch da muss man sagen, wenn man viele Regeln hat, wenn man ein gut ausgebildetes System hat, hat man die besten Voraussetzungen, wenn man das noch so ein bisschen blöd verpackt, um mit einem LLM damit zu arbeiten. Also auch wenn es um UI-Generierung geht, sehen wir da großes Potenzial. Was aus unserer Sicht aber eigentlich viel interessanter war, war immer die Frage, weil wir eben über Websites reden, wir reden viel über Redakteure, auch die Usability für Redakteure in ihren Redaktionssystemen, weil wir halt auch dafür gesehen haben, wenn der Redakteur nicht vernünftig arbeiten kann, wenn der nicht Spaß an der Arbeit hat, dann kannst du dir noch so viel Mühe auf technischer Ebene geben, auf Design-Ebene geben, dann kommt halt keine gute Website bei raus.

Und dann ist keiner von allen erfolgreich am Ende. Das heißt, das als Zahnrad nicht zu bedenken, ist, auch egoistisch gesehen, schon nicht geschickt und deswegen haben wir da immer schon gesagt, das ist uns aber super wichtig und deswegen auf uns die Frage viel interessanter, wie können wir denn den vielleicht in seiner täglichen Arbeit der Content Erstellung unterstützen, weil wir auch da merken, die Redaktionsteams bei den Kunden, mit denen wir reden, die gar nicht unbedingt so klein sind, die werden jetzt nicht größer so.

Das sind eher immer weniger Personen, an denen solche Hüte noch mit dranhängen, mal eben hier noch die Website zu bedienen und Und ja, das ist halt dann schwierig zu erledigen, wenn dann das System auch noch nicht so ganz mitspielt. Dann war unser Gedanke wirklich hier zu überlegen, wie können wir denn dieses ganze Wissen, dieses ganze auch strukturierte, schematische Wissen, was wir über Frontend schon haben, denn vielleicht so auch wieder repurposen, dass es auch an der Stelle ein Vorteil ist, genau zu wissen, wie etwas aufgebaut ist, genau zu wissen, wie Inhalt normalerweise aussieht.

Und das ist halt, wo wir gesagt haben, wir bauen halt einen eigenen MCP-Server, der auf der einen Seite Storybrook gut kennt, jetzt hat seitdem auch Storybrook selber einen MCP-Server, das war Anfang des Jahres noch nicht der Fall. Das muss ich gleich nochmal erklären. Die meisten kennen wahrscheinlich, wissen, was MTP ist, aber manche auch nicht. Das ist letztendlich einfach so. Ein agreed upon Standard von Anthropic, glaube ich, mal irgendwann in die Welt hinaus erfunden.

Und darin beschreiben Systeme eben, was sie können und wie man eben dann dieses Können abruft. Ich nenne es mal so ein bisschen so eine spezifische API-Verschalung für LLMs. Also was ich ganz oft sehe, ist, Leute haben ja ganz viele APIs, aber sie wollen jetzt auch nicht unbedingt ein LLMA an solche vielen und diversen Daten anschließen, weil das oft Compliance-Problem ist oder auch einfach ineffizient. Gibt es ja verschiedene Gründe, das nicht zu wollen.

Und da macht es ja total viel Sinn zu sagen, wie verschalen wir denn vielleicht unsere existierenden APIs nochmal so neu, dass sie für einen LLM gut zugänglich sind, gut verständlich sind, der die Prozesse da irgendwie gut rauslesen kann und genau den richtigen Kontext kriegt. Das kann auch dann gleichzeitig so ein bisschen tokensparend wirken. Das ist auch jetzt immer mehr ein Argument, habe ich das Gefühl, wo überall die Kosten anziehen. Da kann ein MCP vieles leisten und er hat halt den großen Vorteil, er ist Infrastruktur, das heißt, du betreibst ihn, das heißt, du kannst ihn auch für viele Leute betreiben und wir haben es eigentlich immer mit Firmen zu tun, wo Teams arbeiten.

Und dann ist es irgendwie schon wichtig, dass sie die gleichen Regeln haben, dass es vielleicht im Zweifel auch ein Auditing gibt, dass es Permissions gibt. Das ist halt auch was, was ein MCP quasi so als Gateway, könnte man ja auch nennen, erlaubt an der Stelle. Ich weiß nicht, manche, die vielleicht mit Frontendentwicklung mehr zu tun haben, kennen Sie diesen Trend, ein Backend vor Frontend zu bauen. Also ich habe ein hochspezifisches Frontend, wie du es auch beschrieben hast.

Ich weiß sehr genau, welche Daten ich jetzt benötige. Ich weiß auch die Quellen und ich weiß auch schon, dass sie nicht zusammenpassen. Was mache ich jetzt so? Das ist eine Transformerschicht. Genau, die dann einfach dazwischen sitzt und dem Frontend genau seine Daten zur Verfügung stellen kann und für das Backend wiederum den Sicherheitsaspekt abbilden kann. Also irgendwie Tokens schützen kann, eine sichere Laufzeitumgebung bietet. Ähnlich ist das, finde ich, bei einem MCP. Nur, dass der halt gezielt als Adressaten dann ein LLM-System hat, wo ich dann sagen kann, was hast du denn für Tools für mich, was hast du für Prozessbeschreibungen für mich und dann semi-autark auch auf diesen Informationen selber seine weiteren Vorgehenden aufbauen kann.

Das ist, finde ich auch sagen, so eine der Hauptmöglichkeiten, das Ganze zu nutzen. Was wir überlegt haben bei uns ist noch, dass ein MCP selber, den kannst du jetzt über deine IDE, deine Programmierumgebung gut benutzen. Den kannst du auch durchaus in diesen Online-Web-Chat-Interfaces einbauen und verwenden. Es gibt N8N, das wird ziemlich viel benutzt in so dem, Umfeld, ich habe immer das Gefühl so ein bisschen mehr, wenn es so in Richtung Hustle-Richtung und Sales-Pipelines und irgendwie so nicht so ganz so nachhaltige Prozesse geht, um es vielleicht so zu sagen, spielt das da häufig gefühlt eine Rolle.

Das ist so ein IFTTT oder SAPI. Genau, so ein notbasiertes Tool, kann man zusammenknüpfen, wenn das passiert, mach das und dann ruf das und das auf und das halt kombiniert mit sehr viel AI. Lässt schon vieles irgendwie Interessantes zu. Kann man sich fragen, wie skalierbar das ist, ohne da jetzt zu sehr einzutauchen. Was wir halt immer noch interessant fanden, war dem Redakteur selber eine Komponente zu geben. Also in den Systemen, die man bei uns nutzt, kannst du dann so einen Prompt da einfügen und dann kannst du in dem Prompt da selber aussehen.

Ich möchte jetzt einen Inhalt generieren, ein paar Sektionen generieren und dann kann das der Redakteur auch, ohne dass er irgendwas außerhalb von dem Fall jetzt Storyblock bedienen, müsste komplett in seiner gewohnten Umgebung machen. Auch das ist so ein Aspekt, den ich immer ganz nett finde, dem User da zu begegnen, wo er hauptsächlich arbeitet. Ist das jemand, der eh den ganzen Cloud AI schreibt, dann findet er das total gut, dass er den MCP da einbinden kann und auch von da mal eine neue Seite erstellen kann.

Hat er da nichts am Gut, sondern ist einfach glücklich in seinem Storyblock, soll er ja auch nicht außen vor sein. Also das würde ich schon mal sagen, ist ein interessanter Aspekt. Welche Zugangshürden gibt es eigentlich oder wer kann wie Zugriff auf solche Funktionen bekommen und ich denke, im besten Falle hat möglichst jeder irgendwie, auch vergleichbaren Zugriff da drauf. Und das in der NCPS war ein so wichtiger Baustein, aber nicht wirklich alles, was es gibt. Ein so Dreh- und Angelpunkt, den man verschiedene Arten dann anbinden kann. Genau.

Wie würde das denn aussehen? Also ich stimme dir auf jeden Fall zu. Also ich fand auch immer so in meinen Arbeiten früher oder auch eigentlich immer noch, dass es hapert immer am Content. Man wartet immer lange auf Content. Und ja, das machen wir, das kriegen wir hin und dann kriegen wir es nicht hin. Weil es aber auch dann vielleicht nicht immer Profis sind, liegt auch daran, dass es einfach nicht deren Metier ist. Ja, und oft ist ja auch die Wahrscheinlichkeit mit Content, so einfach sich es erstmal anhört, jemandem auf die Füße zu treten, auch gar nicht so klein.

Also Leute sind dann auch gerne manchmal ein bisschen risikoavers darin vorzupreschen und Inhalt zu schreiben, weil dann kannst du halt dafür auch kritisiert werden oder von einer anderen Abteilung gefragt werden, warum geht das denn so und so da. Also es wird halt auch super schnell leider hochpolitisch manchmal dann. Ja, genau. Ja, das ist auch so. Also keiner will damit anfangen und wer damit anfängt, der weiß genau, also so wie ich das da geschrieben habe, geht das 100 pro erstmal in den Mülleimer rein, weil alle sich tauchstürzen, ja.

Und da ist tatsächlich AI, finde ich, ein ganz gutes Hilfsmittel, zumindest um mindestens in den ganz frühen Phasen schon einen relativ, richtigen Content zu haben, relevanten Content zu haben, weil das Gute ist, was wir dann schnell gesehen haben. Ich glaube, OpenAI waren die Ersten, die Structured Outputs damals rausgebracht haben. Das habe ich auch im Grunde im Announcement mir schon angeguckt gehabt und direkt gesehen, ja okay, die nutzen ja selber JSON-Schema.

Das ist so ein bisschen zurückgekappt. Die nutzen nicht das ganze Set davon, die können nicht jedes Keyword, aber die können offensichtlich die einfachen Dinge. Und wir reden jetzt auch nicht über Rapid Science, wenn es darum geht, ob eine Seite aus sieben oder zwölf Sektionen mit drei oder vier Elementen jeweils besteht. Das kann man alles locker beschreiben. Und damit hatten wir quasi das schon gewonnen, das Zielformat. Wir waren schon im Zielformat quasi. Das heißt, mit leichten Manipulationen konnte man das genau so an OpenAI rüberreichen.

Überreichen und die haben dir dann genau das richtige JSON formatiert zurückgeschickt. Das kannst du dynamisch in der React-Komponente als Preview rendern. Das kannst du durch den gleichen Converter schicken, der fürs CMS-System aufbereitet, damit es im CMS-spezifischen Format ist, um da Inhalt eingespielt zu werden. Und das ist so ein bisschen die absolute Kernidee, zu sagen, es ist immer gleiche Bild davon, wie ist mein Frontend aufgebaut, findet sich überall wieder.

Von den TypeScript-Types über das Format im Headless CMS über die Art, wie ein AI-System darüber nachdenkt. Und auch das profitiert dann davon, dass du einen Titel hast, dass du eine Description hast in deinem JSON-Schema. Und das ist, würde ich sagen, so die absolute Basis-Ebene, die schon viel besser ist, als zu sagen, schreit man Text und dann copy-pastet man irgendwie, hemmtsärmelig irgendwie Paragraf für Paragraf in sein CMS rüber. Das ist schon viel, viel besser als das.

Wir haben halt auch gesehen, die Qualität ist jetzt trotzdem noch nicht so super toll. Das ist immer noch One-Shot und One-Shot, eine ganze Seite, da brauchst du schon gut Input und selbst dann ist das schnell, dass der da komisch wird, irgendwie an der falschen Stelle sparsam wird mit Text und das war halt für uns der ausschlaggebende Punkt zu sagen, wie können wir denn noch einen Schritt weiter gehen? Ich finde, da wird es dann interessant, auch, subjektiv unterschiedlich, je nachdem, wer da was baut. Und bei uns ist es halt, wie gesagt, Design-CP, der da in der Mitte steht. Und der kennt halt Storybrock sehr, sehr gut.

Der kennt das Design-System sehr, sehr gut. Und der kennt alles dazwischen sehr, sehr gut. Das heißt, wir haben das quasi wieder genutzt, um das auszunutzen. Also du kannst zum Beispiel, das von mir schnell gesehen bringt einen Riesenunterschied, eine Analyse der bestehenden Inhalte in deiner Seite machen. Und dann weißt du danach, okay, wenn die erste Section ist ganz oft ein Hero, das ist jetzt noch relativ offensichtlich, wenn ein Hero, da steht es meistens ganz oben auf der Seite, solche Regeln kann man A sehr gut vorformulieren, das heißt, wir haben so eine Reihe an statischen Regeln, so Kompositionsempfehlungen quasi, einfach JSON abfolgen, diese Elemente machen Sinn.

Und dann gibt es darauf aufbauend noch einen zweiten Schritt, der deine tatsächlichen Inhalte sich anguckt, also tatsächlich schaut, wie ist es denn real in deinem System. Wie oft benutzt du denn ein Features-Element? Und wenn du es benutzt, wie viele Features zeigst du denn dann normalerweise? Eher zwei bis drei oder eher sechs bis sieben? Und das macht ihr aber, damit ihr sozusagen da eine Einheitlichkeit habt, eine Konsistenz. Genau, so einen gewissen Ton of Voice, eine gewisse Konsistenz in der Verwendung von Komponenten, weil wir gesehen haben, dass das sonst ganz, ganz schnell weit auseinanderläuft, weil das halt ohne Erdung passiert.

Also dann stellt es dann die eine Seite so, die nächste sieht ganz anders aus, obwohl der Prom vielleicht noch ähnlich aussah. Das ist wiederum nicht wirklich vereinbar mit einer langlebigen Inhaltsarbeit, wo man Inhalte auch nicht nur zum Wegwerfen kann. Wenn das nur Wegwerfartikel sind, die ich dann eine Woche bewerbe und dann nie wieder nutze, dann ist das fair als Vorgehen. Aber die meisten Kunden, mit denen wir zu tun haben, die haben schon bestimmte Bereiche auf ihren Websites und dann ist ihnen schon auch wichtig, dass innerhalb dieser Bereiche gewisse Grundstrukturen, natürlich mit Abweichungspotenzial, man steht da ein bisschen mehr, ein bisschen weniger, aber es soll dann auch nicht plötzlich auf einer einzigen Seite ein riesen Slider Gallery sein, wenn die da nie ist.

Und das war aus unserer Sicht eine ganz geschickte Art, da ranzugehen, zu sagen, okay, dann schau doch einfach im System, wie oft ist denn dieses Element in so einer Seite drin und injekte das direkt mit in diese JSON-Schema-Beschreibung. Also, das wird tatsächlich in die Descriptions von deinem JSON-Schema mit injektet, welches dann ins LLM gehen. Das heißt, das ist auch ein sehr zentraler Bestandteil des Prompts, wenn man so möchte. Und das haben wir halt versucht, so ein bisschen auszureizen.

Also ich glaube, das Abgefahrenste ist Field Distributions, also auch so Geschichten wie, wenn das Element an fünfter Stelle steht, wie ist denn dann die Breite normalerweise eingestellt? Und wenn die immer gleich ist, also eigentlich dem Default entspricht, dann ist das nicht interessant, aber wenn da bestimmte Werte so ein Threshold übersteigen, also signifikant werden, dann werden sie automatisch dynamisch zu regeln. Eben sowas, wie ich gerade meinte. Wenn immer das erste Element das Hero ist und in der Section steht dann immer die Breite auf Vollbreit, damit das auch wirklich schön plakativ und groß ist, dann ist das ungewöhnlich im Vergleich mit anderen Sektionen.

Und weil es ungewöhnlich ist, wird es quasi zur Regel, wenn man das vereinfacht sagen möchte. Und dann haben wir die Erfahrung gemacht, dann wird es tatsächlich plötzlich auch qualitativ sehr viel besser. Dann muss ich nicht mehr alles komplett umarbeiten, wenn ich darüber hin bin. Vorher hatten wir Demos, die sahen ganz nett aus. Die sahen auch nach so einem kleinen Taschenspieler-Magietrick aus. Aber die haben einer nachhaltigen Betrachtung mich standgehalten.

Also da hast du den Inhalt dann wirklich nachhaltig angucken. Und gemerkt, naja gut, am Ende muss ich ja jetzt doch quasi an jeden Satz und an jedes Element nochmal dran. Und wahrscheinlich kennt jeder den Faktor so ein bisschen, der egal, womit KI arbeitet, dass man immer mal wieder darüber stolpert, dass man sich denkt, es hat sich so schnell angefühlt. Aber jetzt am Ende bin ich mir gar nicht mehr so sicher, ob es so viel schneller war als der manuelle Weg. Ja.

Und das ging uns dann halt auch häufig so. Und da hatten wir das Gefühl, dass das schon nochmal einen markanten Unterschied macht. Es setzt natürlich voraus, dass du auch schon innerhalb des Systems drin hast. Ja. Das ist so der Kerl. Macht Sinn, ja. Wenn das System komplett leer ist, dann kann er nicht viel mehr als unsere basalen, generischen Hinweise nehmen. Die sind dann immer noch besser, als einfach würfeln, welche Komponenten er nimmt.

Aber das ist irgendwie, fand ich, eine ganz interessante Herangehensweise gewesen, die auch tatsächlich gut funktioniert bisher. Na, dass ja KI auch echt gut einfach drin in so Muster erkennen. Voll. Perfekt, ja. Und wie würde ich mir das denn jetzt, also wie stelle ich mir das in der Praxis vor? Wie ist das, also die Vorgehensweise einer Redakteurin, eines Redakteurs in diesem Setup? Also es gibt eine Seite, die hat schon Inhalte, die aus denen halt eben Regeln abgeleitet werden und dann, gebt ihr denen die Möglichkeit, eben erstmal einen Seitenentwurf zu einem bestimmten Thema erzeugen zu lassen oder greift ihr da eher sozusagen etwas, seichter, subtiler hier und da ein, dass ihr irgendwie sagt so, hey….

Du hast jetzt hier drei von diesen Dingern drin, aber eigentlich haben wir mindestens immer fünf. Pack dir nochmal zwei dazu. Das ist so ein bisschen unterschiedlich. Also das meiste, wenn es um diese Positionierungsgeschichten und so geht, passiert eher in den externen Anbindungen. Also wenn ich mit einem Cloud-AI-Chat-Interface arbeite oder so. Wenn ich im Storybrook selber arbeite, habe ich eben so einen Prompt da. Der ist quasi wie eine Inhaltskomponente, kannst du dir vorstellen.

Das heißt, anstatt einer Sektion kannst du auch einen Prompt da einsetzen. Und den könntest du in eine komplett leere Seite einsetzen und sagen, ich möchte sieben Sektionen, die sollen bitte die ganze Seite beschreiben. Den könntest du aber auch an Position sechs einsetzen und sagen, ich brauche nur genau ein Features-Element oder so. Und das heißt, da ergibt sich die Flexibilität so ein bisschen aus der Art, wie sie Komponente angelegt ist für den Redakteur, dass er verschiedene Sachen kann.

Die ganzen Regeln, die ich meinte, laufen im Hintergrund trotzdem. Darauf hat der Redakteur noch keinen großen Einfluss. Also die sind quasi immer Teil dieser Generierungspipeline, dass diese Hints mit aufgenommen werden. Genauso ist das jetzt aber, wenn jemand sagt, ich arbeite irgendwie eben bei Cloud.ai oder bei JetGPT direkt auf der Website, haben wir halt auch da geguckt, dass der MCP möglichst viele Funktionen bietet. Also sowas wie, ja, setze mir bitte eine Section auf der Seite, rufe dann irgendwo hinten rum halt eine Replace-Section als Tool auf, während es genauso gut irgendwie eine Create-Page-Action gibt.

Das heißt, das kann der im Grunde dann über den MCP selber discovern, welche Tools es da gibt. Man kann auch einfach quasi dann fragen, kannst nur sagen, was kann ich denn mit einer Website eigentlich so machen? Also da ist dann eher so eine Chat-Modalität tatsächlich auch und funktioniert auch da ganz gut. Ja. Ich würde es nicht zu weit aus dem Fenster lehnen, weil es jetzt entwickelt sich alles so schnell und jetzt war ich auch schon ein paar Wochen nicht mehr dran.

Ich weiß, dass du damals noch viel mit Elicitation, das ist so ein Standard, der es erlaubt, Rückfragen an den User zu stellen, experimentiert haben. Also sowas wie, du hast jetzt drei Sections eingefügt, das dann als Elicitation zurückkommt. Ja, als vierte Section würde jetzt X ganz viel Sinn machen. Also so ein bisschen auch so einen interaktiveren Austausch, der etwas strukturierter ist mit dem Redakteur, der dann vor dem Chatbot sitzt, hinzukriegen.

Bis hin zu so kleinen UI-Previews. Das war damals sehr frisch Anfang des Jahres, dass du so MCP-Apps schreiben kannst, die auch wirklich UI dann im Interface rendern. Du also quasi eine Preview der generierten Section tatsächlich da siehst. Würde ich jetzt noch ein bisschen als Spielerei bezeichnen, weil es auch noch nicht so richtig stabil war. Aber das war schon so irgendwie ganz cool, als Richtung zu sehen. Du sagst irgendwie, hier, es gibt irgendwo die Über-uns-Seite und mir gefällt das Element X nicht. Kannst du das mal gegen ein anderes tauschen und mir das vorher zeigen?

Und es funktioniert halt einfach erstmal. Das ist irgendwie nochmal so eine andere Art, daran zu gehen. Und genauso gibt es dann irgendwie das N8N, wo vielleicht jeden Montag ein Trigger losläuft und dir ein Blogpost-Template ins System schreibt. Das war so ein anderer Use Case, den wir mal uns rausgegriffen haben, zu sagen, viele kommen nicht dazu, tagesaktuell ihre Blogposts zu schreiben. Aber wenn du einmal die Woche irgendwie, du haust da deinen RSS-Feed als Input rein, Das LM guckt einmal über den Feed drüber, was waren in der letzten Woche so die Branchen, News-Dusteller-Branche, was deckt sich denn am ehesten auch mit den Themen, die ich selber so abdecke und dann drafte ich einfach mal einen Vorschlag.

Das ist so, in dem Metier finden wir es eigentlich gerade noch interessanter, wie wir da halt eben diese Redaktionsarbeit tatsächlich unterstützen können. Nicht so sehr. Dass jemand wirklich dann eine Section über Cloud AI replaced. Also das hat schon viel auch irgendwie manchmal den Anflug von Spielerei finde ich. Aber so ein Blogbeitrag, das ist was sehr Reales. Irgendwie hatten wir jetzt mal die Anfrage, die wir mit dem NGO auch noch verfolgen.

Können wir denn nicht irgendwie unsere Seiten, also sie machen viel Aufruf natürlich mit Performance-Marketing-Pages, wenn irgendwo was ist, dann gibt es dann Aufrufe und darüber kann gespendet werden. Können wir die nicht noch Zielgruppen spezifischer ausspielen. Also wir wissen ja, eigentlich haben wir ja diese fünf verschiedene Zielgruppen. Es wäre ja total cool, wenn wir die Seite nur einmal bauen müssten und dann zumindest eine textliche oder vielleicht so eine leicht strukturelle Variabilität, automatisch daraus fällt.

Und ich finde, das sind so die wirklichen Hebel, die am Ende sind, etwas größeren, ernstzunehmenderen Projekten so wirklich interessant werden. Im Produktbereich hatten wir das Beispiel, du hast eine Messe und du weißt, 20 von meinen Produkten möchte ich auf der Messe bewerben. Niemand hat ja jetzt wirklich Lust, 20 Mal die gleiche Messeseite für die Produkte anzulegen. Bei dem LLM zu sagen, pack da halt einen Hero oben rein, ein paar Produktfacts und unten immer den gleichen CTA-Abbinder, das ist easy work.

Ja, KI ist halt auch einfach echt für so stupide Arbeit super. Total gut, ja. Also deswegen kommst du auf den Use Case an. Also kann an vielen Stellen passieren, können viele verschiedene Dinge auch sein. Quality Checks wäre so ein drittes Ding. Wir wissen sehr viel über dein System. Das heißt, wir können auch sehr gut und auch noch besser als andere SEO-Tools, die, andere Vorteile durch den Blick von außen haben, können wir, was die wirkliche Inhaltsqualität angeht, sehr viel informiertere Aussagen darüber treffen, wo bei dir vielleicht ein Element fehlt, wo du vielleicht einen Alttext nicht gepflegt hast, wo vielleicht der Kontext nicht so ganz korrekt ist oder so.

Wo eine Seite lange nicht geupdatet wurde. Auch sowas ist echt schön durch LLMs ziemlich wenig Aufwand abbildbar. Ja, das hört sich alles sehr cool an. Und irgendwie auch so serial und nicht, nur hier irgendwelche ja, komplett Automatisierungen. Also sehr viel Human in the Loop und einfach tatsächlich unterstützend oder den Writers Block irgendwie helfen zu überwinden und solche Dinge. Das finde ich fast schon philosophisch, moralisch auch einfach richtig, dass der Human in the Loop ist. Auf der anderen Seite, also die reinen Fakten sagen einem auch, das muss heute noch so sein.

Also so toll ich auch LLMs fürs Coding selbst schon finde und manchmal davon beängstigt bin, wie gut sie coden können, inhaltlich ist das schon immer noch mal so eine Geschichte. Und wenn man dann so einen gewissen Anspruch an seine Inhalte hat, da wird das schon noch sehr viel hallazioniert. Da muss einfach jemand drüber gucken. Also du kannst keine Funktion, die wir bisher gebaut haben, publish direkt was. Weil wir das auch nicht als korrekt ansehen und zweitens, zweiter Riesenpunkt LLMs können nicht so gut Bilder für dich raussuchen, also unsere ersten Versuche waren dann immer reine Textseiten, riesen Textwüsten, die dabei rausfallen, die halt wiederum gar nicht nützlich sind, weil der Redakteur muss ja dann alle Bilder noch einpflegen, indem man über die Bilder einpflegt, passt die Komposition ja aber gar nicht mehr.

Wie habt ihr das gelöst? Also wie habt ihr das letztendlich gelöst? Eigentlich auch ein ganz netter Trick. Es gibt ja so diverse Image-CDNs, wo du quasi leichte Image-Rendering-Funktionen hast. Und da gibt es halt auch, ich glaube, Facehold-CO ist so eine, da kannst du Strings mit übergeben. Und wir haben quasi das LLM instruiert, den Stream zu generieren, der das Bild beschreibt, was an der Stelle stehen soll. Und dann wird das auch automatisch ins Bild reingerendert, sodass du auch wirklich ein Blocker-Bild an der Stelle hast und der Redakteur gezielt reinklicken kann und das Bild halt durch ein echtes Asset ersetzen. Und das war auch zwingend möglich.

Und weiß, was so der Gedanke dahinter war. Ja, und der Redakteur wiederum auch eine Idee hat, was soll ich denn jetzt überhaupt ein Bild für einsetzen. Ja, klar. Ich meine, das ist ja so, der Redakteur muss sich ja auch erst mal eindenken in das, was er da vor einen Satz geknallt kriegt. Das ist ja so wie, wenn dein Agent dir Code geschrieben hat, musst du auch erst mal checken, was da los ist. Und das hilft natürlich dann sehr. Ja, genau. Das war da so eine natürliche Geschichte. Und alles andere, was Bilder angeht, natürlich kann man Bilder auch generieren.

Das wird aber A, irrsinnig teuer dafür, dass das fast immer Wegwerfbilder sind, und ist auch B, quasi nie der Anspruch. Also die Kunden, mit denen wir zu tun haben, die haben meistens große Asset-Lösungen, wenn die nicht sogar ein eigenes Digital Asset-Management-Tool haben. Das ist Bread and Butter für die, dass die irgendwo fettes Bildmaterial rumliegen haben, was sie dann nur noch reinlegen müssen. Das ist tatsächlich seltener das Problem, als dass der Inhalt geschrieben werden muss. Da tun sie sich wesentlich schwerer mit. Gefühlt.

Ja, das hört sich ziemlich, ziemlich cool an alles. Also gefällt mir sehr, bin sehr beeindruckt. Nicht nur von dem KI-Part, sondern von auch allen davor, über das wir gesprochen haben. Ich fand das total lustig, weil das haben wir uns ausgedacht, ohne jemals über AI oder LLMs nachzudenken, weil als wir es getan haben, gab es die in der Form nicht. Und das finde ich so ein starkes Konzept, wenn das halt so adaptiv ist, dass wenn was Neues aufkommt, es halt weiter Sinn macht.

Dass es jetzt da so viel Sinn macht, ist auch irgendwie Glück natürlich oder, kosmischer Zufall, egal wie, aber es beweist irgendwie trotzdem so eine gewisse Resilienz, die in so einem Konzept drin steckt, die glaube ich wichtig ist so. Ja genau, also ich meine, ich hätte es ja gesagt, du warst zum ersten Mal 2022 bei uns, also da gab es ja dann schon, sagen wir mal, ein paar Monate Chat-GPT, aber genau da war das ja noch alles, da wusste man ja auch nicht, wohin das alles weiter sich entwickelt.

Ich fände es auch total verrückt. Ich habe wirklich auch viel auf Coding-Seite ausgebildet, weil ich da schon ein großes Potenzial sehe, eben auch da eine Effizienz zu gewinnen. Und das hat für mich halt nie funktioniert. Und ich war immer total verplex, wie das für alle so gut funktionieren kann, wenn es für mich so gar nicht funktioniert. Sehr, sehr vieles Marketing, sehr viel ist der Hype-Cycle, der da existiert. Ich will auch gar nicht sagen, dass es da nicht auch irgendwo reale Sachen dazwischen gab, aber gefühlt ist es auch wirklich ganz stark Anfang des Jahres, so Januar rum, Opus 4.6 und so, hat da irgendwie zumindest in meiner Wahrnehmung einen echten Shift nochmal bedeutet, der Qualität, die da rausfällt.

Also direkt davor habe ich Code generiert und den gelesen und gedacht, naja gut, den kannst du halt nicht benutzen, das machst du doch besser selber so. Und danach ist es wirklich manchmal erschreckend, wie gut der Code ist, der da rausfällt. Gerade wenn die Code-Guess, wie gesagt, drumherum sehr strukturiert ist und sehr genau weiß, was sie möchte und tut, ist es fast etwas erschreckend, wie gut das LM sich dem annehmen kann. Ja, das sagen ja viele, dass es da einfach so diesen Zeitpunkt gab, ab dem das dann interessant wurde.

Ich hoffe, es haben alle genauso ihre VS Code-Abos ausgenutzt wie ich die ersten drei, vier Monate, wo es noch ging. Das war tatsächlich sehr nett, weil die irgendwie per Request abgelichtet haben, nicht per Token. Und das hat echt extrem viel Geld gespart. Mit den größeren Modellen. Dann haben sie jetzt auch alles gekippt, vor einem Monat gelaufen. Da muss man den kalten Entzug so ein bisschen überwinden. Nee, genau. Also ich finde, das ist einfach allein deswegen ein spannendes Thema, weil da so viel passiert in dem Bereich.

Weil es durchaus so reale Dinge, reale Werte zu finden gibt in den ganzen ominösen, was sich alles KI nennt. Ja, genau. Aber sehr einfach man muss das explorieren. Manche Dinge funktionieren nicht oder dann codet man viel und dann wird das Reviewen zum Bottleneck und, irgendwie Ja, und andere Sorgen. Wo kommen denn die Junioren eigentlich noch her? Also das ist, was mich so ein bisschen umtreibt. Wir haben immer Junioren auch gehabt, eigentlich die längste Zeit.

Und wenn ich jetzt auch andere, nicht nur Webentwickler, auch Softwarefirmen sehe, das ist echt ein schwerer Stand aktuell. Also selbst wenn du deine Junioren hast und die fangen aber direkt mit KI an, weiß ich halt nicht, ob die jemals dieses nachhaltige Level erreichen, das wirklich hinterfragen zu können, was sie da tun. Das finde ich schon irgendwie auch ein bisschen beunruhigend zu beobachten. Also, naja, genau, also es ist halt die Frage, ob man erfolgreich seine Skills.

Aufbauen kann, wenn man zu viel sich helfen lässt von denen. Aber genau, so ein bisschen so, die Fragestellung habe ich ja auch mit meinen, Kindern, die auch JGBT nutzen, machen auch echt coole Sachen damit, also lassen sich auch irgendwie Aufgaben, Sachen erklären, Aufgaben generieren. Manchmal sind sie eben faul und... Spulen dann sozusagen in die Zukunft, einfach indem sie sich da sehr weit tragen lassen davon. Es ist halt wirklich einfach zweischneidig.

So schnell es dann dich da leitet, irgendwie die Abkürzung zu nehmen, so sehr sehe ich auch die andere Seite, wo es manchmal besser als jeder Lehrer auf deine persönlichen Fragen eingehen kann und viel genauer mit dir etwas. Also es stimmt ja auch vieles, was da drin steht. Solange ich das irgendwie reflektiert mir anschaue und hinterfrage, finde ich es auch genauso falsch, es zu verteufeln. Weil da halt auch super viel Wert drin ist. Absolut. Ja, es ist halt so beides zugleich und darum explorieren ja auch alle und.

Gucken, wo uns das hinführt. Ich habe letztens eine Mini-Anekdote etwas von der Seite mein erstes Programmierbuch wieder gefunden. Es war tatsächlich ein Basic-Buch aus der städtischen Bibliothek hier, wo man so kleine Spiele abgetippt und nachgetippt hat. Ja, stimmt. In der ASM, also in dieser Zeitschrift früher, gab es auch immer Basic-Code, damit jemand abtippen musste, Also wenn man da eine Sache falsch eingeben hat, dann hat das alles nicht mehr funktioniert. Und dann war ja auch irgendwie zu doof zu verstehen, was man da tut.

Kam mir nur da wieder in den Sinn, weil der Gap so riesig ist zu, ich kann ein LLM befragen und das kann mir minutiös helfen. Ich habe das Heft vor mir liegen, da stehen kryptische Zeichen, das Heft ist auf Englisch und man ist irgendwie zwölf Jahre alt. Und irgendwie funktioniert es trotzdem. Also es ist halt dieses abgedroschene, wir hatten ja nichts. Genau, alter Mann. Ich mache den alten Mann. Ja, ich habe auch so einen jungen Kerl letztens auch beobachtet, der auch versucht hat, für Discord einen Node.js-basierten Chatbot zu bauen und der ist halt so all-in gegangen, mit KI und der hat wirklich nichts geschnallt, was er da gemacht hat.

Und er hat einfach nur Copy und Paste die ganze Zeit gemacht. Und jedes Mal kam auch irgendwie ein anderer Code raus, der so, Moment, warum macht er das denn jetzt? Nee, hör auf, kopier das nicht schon wieder da rein. Du weißt überhaupt, was du tust. Du weißt doch gar nicht. Und das war so, ah, kacke, ich kann da nicht mehr zugucken. Ich weiß auch nicht, wie es ausgegangen ist. Das war emotional zu anstrengend für mich. Und vielleicht ist es mal noch alt. Damals haben auch über Dreamweaver die gleiche, ähnliche Leute gesagt, das ist der Ende von allem.

Jetzt können die Leute das hier visuell hin und her schieben. Oh mein Gott. Ja, ich glaube, wahrscheinlich am Ende läuft es darauf hinaus, dass man Zeit nicht abkürzen kann. Du brauchst einfach dieses dich damit auseinandersetzen über eine lange Zeit. Ja, das muss einfach passieren, da kannst du gar nichts machen. Das muss einfach abwarten, Tee trinken und machen. Was mich so ein bisschen echt umtreibt bei dem Thema ist, wie viele Leute so bereitwillig jegliche Autonomie abgeben oder bereit sind abzugeben, wenn das LLM nur die Aufgabe übernimmt. Wie meinst du das?

Irgendwie ich fand es irgendwie noch nie erstrebenswert, dass mein Beruf komplett ersetzt wird durch ein besonders intelligentes LLM, weil was mache ich denn dann? Und ich kann ja Sachen auch gut so. Und ich bin ja auch der Meinung, dass ich die besser kann. Und wo ist dieser Anspruch, wo ist so dieser Eigenanspruch, der fehlt mir dann manchmal, wenn man sich anguckt, wie schnell Leute sagen, guck mal, wie geil das ist, mein Designsystem ist auf einem Prompt in Figma rausgefallen.

Da frage ich mich aber, warum ist das denn jetzt toll so? Also ja, wenn das alles erfüllt und wirklich so toll ist, dann kann man darüber ja reden. Aber warum findest du persönlich das eigentlich so toll? Darüber stolper ich manchmal so ein bisschen, dass ich denke, aber siehst du, glaube ich, einen Wert in deiner Arbeit so ungefähr, ne? Ja. Ja, ich meine, es ist ja erstaunt. Ich glaube, das ist vor allem auch die zeitliche Komponente, wie schnell das passiert.

Also ich meine, wir konnten ja immer schon so rein theoretisch irgendwie in Indien anrufen oder sonst wo und alles quasi offloaden dahin und die das bauen lassen, was wir gerne möchten. Also im Grunde gab es das ja immer schon, nur ging das eben nicht in einen Tag oder in ein paar Stunden. Und ich glaube, das ist vielleicht dann noch die faszinierende Komponente daran. Aber ich sehe das wie du. Also ich will diesen Denkprozess selber durchlaufen und ich mache das auch gerne.

Und ich habe das Gefühl, dass ich auch zu anderen Lösungen komme, wenn ich eben mit dem Material arbeite, als wenn ich... Einfach ein Ziel nehme, dass ich das ja nicht lange hinterfrage, dass zorglos über erscheint und mir das dann eben mich dahin bringen lasse, aber vielleicht wäre das gar nicht der Ort gewesen, an dem ich gelandet wäre, hätte ich mich eben mit der Materie beschäftigt. Das bietet immer die Gefahr, in so Plattitüden abzurutschen, aber der Weg ist das Ziel und auf dem Weg findet man ja auch noch Dinge darüber heraus, wie der Weg eigentlich aussieht und so.

Stimmt halt einfach. So komplexe Probleme müssen immer noch zerdacht werden, um zu einer Lösung zu kommen irgendwo. Und das ist auch tatsächlich was, was ich noch nicht gesehen habe, dass das ein LM tatsächlich abnehmen könnte. Also das macht ganz viele tolle Gedanken und das schreibt ein ganz tolles Paper und ein ganz tolles Konzept und Businessplan und so weiter. Aber die halten dann wiederum meiner Meinung nach oft nicht den eigenen Anspruch stand, den man hätte, wenn man sowas selber schreiben würde.

Denn man ja weiß, wie man sowas selber schreiben würde. Klar, wenn ich halt als Anfänger und deswegen ist da meine Sorge größer, kenne ich das ja gar nicht. Ich habe keine Referenz dafür. Wie soll ich es einschätzen, ob es jetzt gut ist, was da rauskommt? Ich glaube, wenn man erfahrene Senioren sich anschaut und wie die mit Leuten reden, wie die die richtigen Informationen rausfinden, auch das ist bei uns ein wichtiger Aspekt. Wir reden alle mit den Kunden. Es gibt keine PMs bei uns.

Weil wir es halt als super wichtig achten, dass wir alle den Kunden verstehen und auch die gleiche Sprache sprechen, ob das jetzt technisch, inhaltlich oder in der Design Sprache ist, ist das halt einfach super wichtig an der Stelle, dass man die Leute dann verstehen kann, das ganze Problem überhaupt erstmal übersetzen kann und so. Und das sind die wirklich komplizierten Themen und die, wo man auch viel Aufklärungsarbeit leistet und deswegen möchte ich da völlig recht geben, der Weg zeichnet sich erst, während ich hingehe.

Also zumindest mit den Kunden, mit denen wir arbeiten. Die finden dann erst raus, dass ihr SharePoint irgendwie doch anders funktioniert, als sie dachten. Und dann können die Files doch alle gar nicht im SharePoint liegen. Ja Mist, wo kommen die denn jetzt hin? Wenn ich dann halt schon mit dem fertig ausgerollten Plan da auflaufe, dann sehe ich halt auch aus wie ein Amateur irgendwann, so ne? Ja, es ist halt ganz viel Zwischenmenschliches und eben Denken, Interieren, Machen.

Gut, das tun KIs auch, aber genau, also. Ja, ich glaube, diesen interdisziplinären, auch intermenschlichen Kontakt, so, den können die halt noch nicht gut abbilden. Also sie haben jetzt ja doch kein Gedächtnis, sie können doch nicht wirklich gut und lange synthetisieren, so. Das sind schon Sachen, wo gerade Menschen mit Erfahrung halt irre gut drin sind, so, ne? Ja, und das war auch noch ein Gefehl, das ist dann ja auch noch. Ja, was ja irgendwie auch eigentlich mal Erfahrungen sind, die nicht mehr rationalisierbar sind, aber irgendwie tief in einem drin schlummern.

Ja, genau. Oder man ahnt schon, irgendwelche Probleme kommen, weil man es halt einfach schon so oft erlebt hat. Und dann riecht das schon danach. Wir haben halt selber ganz gute neuronale Netze an Wort. Ja, aber ich muss sagen, ich nutze KI tatsächlich gerne für einfach so, nimm mir stupide Arbeit ab, suche, recherchiere mir Dinge schon mal zusammen, das finde ich auch gut. Was finde ich noch gut? Hier eine Riesen-Codebase, die ich nicht geschrieben habe. Helf mir mal, mich darin zu finden. Dafür finde ich es auch super, ja.

Dokumentation. Ich lese da viel drüber, aber in fairer Weise, meine Dokumentation ist seit es KI gibt, deutlich besser geworden, weil ich sie jetzt überhaupt schreibe. Ja. Also davor ist dann mein Anspruch nicht gerecht geworden. Also ja, und gleichzeitig, also man kennt ja auch Doku, man weiß ja, wie schlecht schlechte Doku ist. Also will man ja auch dann eigentlich gute Doku schreiben, aber gute Doku ist halt echt aufwendig so. Auch da ist es schon teilweise sehr praktisch, wie schnell man auch Doku dadurch unterstützen kann. Ja.

Ich hasse ja diese automatisch generierten Dokus, die oft irgendwie gar nicht viel dokumentieren, weil sie automatisch generiert sind aus einfach den Code-Kommentaren und so. Also reine Dokumentare, die dann, ja. Ja, das ist, finde ich, auch dann verträgt, also darf eigentlich den Namen Doku nicht tragen. Das ist ja eigentlich nicht. Ja, Jonas, das war ein sehr schöner Plausch. Wenn man jetzt interessiert die Ohren gespitzt hat und Lust bekommen hat, sich tiefer in diese Themen, die wir heute besprochen haben, die ihr macht, begeben möchte, dann was würden die Leute tun?

Die können sich natürlich an euch wenden. Also die werden wir in jedem Fall ja auch da hier in den Show Notes verlinken. Ihr habt dieses Kickstarter-DS. Das ist ja auch der Design-System. Da kann man reinschauen. Und wahrscheinlich sind das so... Ich glaube so ein bisschen unsere Agentur-Seite und die Kickstarter-DS-Seite. Ich würde vielleicht einfach nochmal zwei Links raushauen. Ich habe einen Blog-Beitrag, der so einiges an den Ideen, die wir auch heute besprochen haben, in Kickstarter, der ist nochmal gut Zusammenfassung beschreibt.

Von da aus kann man es ja noch auf die Seite weiterklicken. Ähnlich gibt es nochmal so einen Blogbeitrag eher zu diesen KI-Content-Operations haben wir es mal eine Zeit lang genannt, Themen. Der ist dann auf dem Ruhmesmeile-Blog. Dann hat man da so ein bisschen den Einstieg. Genau, richtig. Und dann kann man da von beiden Seiten, wenn es einen tiefer interessiert, entweder bei Kickstarter eher an die technische Ebene oder auf unserer Agenturseite eher so ein bisschen in die redaktionell-inhaltliche Ebene eintauchen.

Aber ich glaube, das macht am meisten Sinn. Adressen findet man uns, früher hat man immer gesagt, auf allen Social-Netzwerken. Aber das stimmt halt einfach gar nicht mehr. Also wir sind es eigentlich nur auf LinkedIn, glaube ich. Und auf der Website. Also das sind die Kanäle, die wir noch haben. Wir machen auf X-Formerlin und Twitter nichts mehr. Wir haben mal ganz kurz ein bisschen auf Blue Sky geguckt. Aber da passiert halt auch viel zu wenig, dass das für uns irgendeine Relevanz hätte.

Und Facebook bin ich zumindest schon sehr lange los und überhaupt nicht traurig drüber, deswegen. Ja, bei LinkedIn ist so ein bisschen was, das ist wahrscheinlich das nötige Übel in der heutigen Zeit. Ja, LinkedIn, glaube ich, ist auch so. Ansonsten, wir sind bei Mail erreichbar, wir machen super gerne Calls, man kann auch einfach mal so mit sich uns austauschen, wenn einem das Thema interessiert. Wir machen auch gerne eine kleine Vorberatung, wenn jemand sagt, heute ist es interessant, dann habe ich nicht genau verstanden, könnt ihr das mir genauer erklären.

Da sind wir immer zu bereit, auch erstmal ein bisschen zu quatschen, bevor man da jetzt einen großen Auftrag ausfüllen muss. Also auch da gerne auf uns zukommen. Und seid ihr auf irgendeinem Event? Trifft man euch auf irgendeinem Event in nächster Zeit vielleicht? Auf der JoyConf. Die Storyblock kommt in Frankfurt dieses Jahr. Jetzt muss ich selber mal gerade gucken, dass ich jetzt kein falsches Datum nenne. Ist die wieder in Amsterdam? Nee, Frankfurt diesmal. Frankfurt, das hast du ja gerade gesagt. Nee, Mainz. Ich höre.

Mainz. Just 25 minutes from Frankfurt. Wahrscheinlich nicht deswegen. Ja. Das wird Mainz gar nicht gern hören, dass ich hier Frankfurt-Sache und Mainz nenne. Das ist so wie Düsseldorf-Wetze, der Flughafen, der halt irgendwie gar nicht in Düsseldorf ist. Ja, okay. Genau, ansonsten sind wir jetzt auch nicht auf Superfilm-Messen. Wir sind ein ziemlich kleines Team. Wir machen jetzt auch nicht irgendwie super viele parallele Aufträge. Das sind meistens zwei, drei größere Sachen, die wir parallel machen.

Ich dachte, es hat ja Potenzial, dass sie auch schon mal ab und zu vielleicht irgendwo auf einer Bühne steht. Und auch das, was du berichtet hast, hier erzählt hast, irgendwie in Talkform, zeigt. Das ist vielleicht noch ein bisschen abschließendes, halbes abschließendes Wort. Da tauchen wir nicht so häufig auf, weil wir versuchen immer unabhängig zu bleiben. Das schmeckt auch nicht jedem Systemanbieter unbedingt immer nur gut. Also auch ein Storyblock hat sehr viele eingebaute AI-Funktionen.

Wir haben alles, was wir machen, sehr bewusst an Storyblock drumherum vorbeigebaut. Eben aus genau diesen Gründen. Wenn du später mal von Storyblock zu Sanity wechseln möchtest, wir wollen nicht der Grund sein, dass dein Frontend jetzt damit sterben muss, sondern das sollte portable bleiben und da ist KI dann schon so wichtig, auch wiederum aus unserer Sicht, dass das gerade einer der Werte ist, dass wir diese ganze Infrastruktur unabhängig von Vendor-Login anbieten können.

Deswegen nur kurze Antwort quasi darauf, warum werden wir wahrscheinlich auch nicht unbedingt so primär auf solchen Bügen stehen, weil wir uns ungern bei einem Anbieter so stark anbieten. Ja, das könnten ja auch andere Konferenzen, allgemeine Konferenzen sein. Das stimmt, das stimmt. Aber du hast recht, also ich, früher war ja Contentful irgendwie sehr angesagt, ne, als Hackers CMS und dann haben die ja die Preise ordentlich nach oben geschraubt und dann sind ja auch viele dann.

Weg oder waren gefangen und das kann natürlich, also die Storyblock-Menschen sind alle mega, mega, mega lieb. Ja, die müssen auch Geld verdienen. Genau, die haben auch Venture Capital und irgendwann... Auch nicht zu knapp, also deswegen, da muss man... Ja, genau, und dann irgendwann liegt das auch nicht mehr ganz in deren Hand, was wieder die Business-Strategie ist. Ja, und das sagen wir Kunden auch offen dazu. Wenn ihr nicht einen großen Enterprise-Contract bei diesen Anbietern abschließt, dann seid ihr denen irgendwo auch ein Stück weit egal.

Die sehen das als Self-Service, was man dann betreibt. Da gibt es nicht Groß-Support, da gibt es nicht irgendwie Einblick auf die Roadmap, das ist alles Friss oder Stirb ein gutes Stück weit. Die sind schon sehr, sehr auf den oberen Teil des Marktes fokussiert, alle in ihrer Sales-Strategie. Und dessen muss man sich einfach bewusst sein, wenn man sich darauf einlässt. Umso wertvoller wird es dann, eine Residenz da gegenüber zu haben, wenn so ein Switch ansteht, das dann nicht das ganze Kartenhaus bröselt.

Und wenn sich bei Storybook die Preise so dramatisch schlecht entwickeln, dass das keiner mehr nutzen will, sind wir ja die Ersten, die daran interessiert sind, einen neuen Converter zu schreiben und einen Migrationsassistenten zu schreiben, der es ermöglicht, einfach wieder rauszukommen. Das ist so das Reasoning dahinter. Ja, nee, macht auch total Sinn. Genau, alles schon mal gehabt und Firmen kommen und gehen und so ist das eben. Ja, das ist auch gut, das bringt auch Fortschritt. Also ich will das gar nicht verteufeln, man muss das nur korrekt wahrnehmen und berücksichtigen in seiner Entscheidungsfindung. Das ist halt wichtig.

Da gebe ich dir recht. Super. Vielen Dank, Jonas, für deine Zeit. Hat mir total Spaß gemacht. Ja, ebenso. Viel gelernt. Ich war auch gespannt, was KI, wie KI da eine Rolle spielt. Das war auch ganz anders, als ich gedacht hätte. Okay, das ist gut. Glaube ich. Hat mir sehr gefallen. Finde ich total schlüssig und gut. und so kann ich total d'accord mit, mag ich sehr. Ich fand es auch wie immer sehr angenehm. Ich war im letzten Termin immer so wahrgenommen und zum einen sehr nett Austausch hier.

Ich weiß nicht, ob wir uns dann 2028 irgendwie wieder treffen. Genau, kann man schon mal festmachen. Aber ja, kann ich mir gut vorstellen, dass es so kommt. Ich glaube, die interessanten Themen gehen einem zum Glück ja auch doch nie aus. Ist das schön. Und man schaut ja dann regelmäßig immer wieder in bestimmte Themen rein und, macht dann da so einen Stand der Dinge, Aufnahme und guckt, was sich da weiterentwickelt hat. Ach, super. Alles klar.

Der Krankenwagen kommt schon. Das heißt, wir müssen jetzt Schluss machen. Dankeschön. Liebe Grüße nach Bonn. Und den Hörerinnen und Hörern vielen Dank fürs Zuhören. Wenn ihr die voll gut fandet, dann tut es kund durch Daumen hoch oder Sterne. Und wenn ihr Fragen habt, ihr findet auf unserer Webseite alle möglichen Kontaktkanäle und natürlich auch alles rund um Jonas und die Rummesmeile und Kickstarter.ts in den Show Notes. Bis dahin, bis nächste Woche. Macht's gut. Tschüss.

Transcript supplied by the publisher with the episode.

Podcast

Working Draft

Vanessa Otto, Peter Kröner et al. · Tech & Science · German

Deutschsprachiger Podcast über Webentwicklung — HTML, CSS, JavaScript, Browser-APIs und alles rund ums moderne Web.

More from Working Draft All episodes →

  1. E726 · 25 Aug 2026 · 58 min

    Revision 726: Silverstripe CMS, mit Werner Krauß und Andreas Spannbauer

    Wir sprechen mit Andreas Spannbauer und Werner Krauß über das Silverstripe CMS, ein PHP-basiertes Open-Source-CMS, das sich vor allem an Entwickler:innen und individuell entwickelte Webprojekte richtet. Werner arbeitet seit mehr als 15 Jahren mit Silverstripe und ist in der Open-Source-Community aktiv, Andreas setzt das System mit seiner Wiener Webagentur vor allem für langfristige, maßgeschneiderte Kundenprojekte ein. Neben Architektur, Datenmodellierung, Frontend und Headless-Betrieb geht es um die europäische Silverstripe-Community, den Verein S2-Hub und die StripeCon Europe, die vom 16.…

  2. E725 · 18 Aug 2026 · 1 hr 49 min

    Revision 725: Die Browser haben wieder geliefert

    Wir werfen wieder einen Blick auf aktuelle Entwicklungen der Webplattform und sprechen über eine ganze Reihe neuer Browser-Features und Standards, die in den letzten Monaten ihren Weg in Chrome, Firefox oder Baseline gefunden haben. Dabei geht es sowohl um neue APIs und CSS-Features als auch um Verbesserungen für Accessibility und die Entwicklerwerkzeuge. UNSER SPONSOR Alle reden von Automation – aber wo betreibst du eigentlich deine Tools? Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration?…

  3. E724 · 11 Aug 2026 · 1 hr 16 min

    Revision 724: Die VoidZero-Akquisition, mit Alexander Lichter

    Wir sprechen mit Alexander Lichter (LinkedIn / Mastodon) über die Übernahme von VoidZero durch Cloudflare. Nachdem wir in Revision 673 bereits über die Gründung von VoidZero und die Vision einer nachhaltigen Finanzierung moderner JavaScript-Infrastruktur gesprochen haben, ziehen wir nun Bilanz: Warum wurde VoidZero übernommen, was bedeutet das für Vite, Rolldown und Co., und wie verändert sich dadurch die Arbeit der Maintainer? Außerdem sprechen wir über Open-Source-Finanzierung, die Rolle großer Unternehmen als Stewards wichtiger Infrastruktur, den Umgang mit AI-generierten Pull Requests,…

  4. E723 · 4 Aug 2026 · 1 hr 14 min

    Revision 723: Cross-Origin Storage API – Caching über Origins hinweg, mit Thomas Steiner

    Wir sprechen mit Thomas Steiner (Mastodon, Bluesky, LinkedIn) von Google über einen neuen Vorschlag für die Webplattform: die Cross-Origin-Storage API. Tom war bereits mehrfach bei uns zu Gast, zuletzt in Revision 677. Gemeinsam schauen wir uns an, welches Problem die API lösen soll, warum Browser heute identische Ressourcen mehrfach herunterladen und speichern und wie sich das mit einem hashbasierten, sicheren und datenschutzfreundlichen Ansatz vermeiden ließe. Dabei geht es längst nicht nur um KI-Modelle, sondern ebenso um WebAssembly-Pakete, Web Fonts und JavaScript-Bibliotheken.…

  5. E722 · 28 Jul 2026 · 1 hr 48 min

    Revision 722: Tailwind versus BEM, mit Jon Uhlmann

    Wir sind diesmal zu viert: Schepp, Vanessa und Peter diskutieren mit Jon Uhlmann über Utility-First CSS und insbesondere Tailwind CSS. Jon war bereits mehrfach bei uns zu Gast und meldete sich nach unserer Diskussion in Revision 715, weil ihm unsere damalige Einordnung von Tailwind zu einseitig erschien. Wir nehmen das zum Anlass, Tailwind noch einmal ausführlicher mit klassischem CSS, komponentenbasierten Ansätzen und BEM zu vergleichen. Dabei geht es weniger um ein einfaches Dafür oder Dagegen als um Wartbarkeit, lokale und globale Abhängigkeiten, Designsysteme, unterschiedliche…

  6. 17 Jul 2026 · 33 min

    On Tour @ #headinthecloud – What does a Fossil-Free Internet look like? With Chris Adams

    We caught up with Chris Adams (LinkedIn / Bluesky / Mastodon) at mittwald’s Head in the Cloud festival to talk about one of the less visible aspects of our industry: the energy that powers the internet. Chris is Director of Tech and Policy at the Green Web Foundation, where he works on making the web less dependent on fossil fuels and helping the industry understand the environmental impact of our digital infrastructure. SHOWNOTES [00:00:27] WHAT DOES A FOSSIL-FREE INTERNET LOOK LIKE IN GERMANY? Chris starts by explaining why Germany is such an interesting place to discuss a fossil-free…

  7. E720 · 14 Jul 2026 · 1 hr 6 min

    Revision 720: ARIA-Glücksrad – von abstrakten Rollen und konkreten Problemen

    Wir spielen wieder ARIA-Glücksrad und sprechen mit Paweł Masarczyk (Mastodon), Peter Krautzberger (LinkedIn / Mastodon) und Marco Bretschneider (Mastodon) über ARIA-Rollen und -Attribute, die uns unser Glücksrad ausspuckt. Daniela Kubesch (LinkedIn / Bluesky / Mastodon) musste leider erneut aussetzen, und Paweł wurde später von seiner Internetverbindung aus der Runde gewürfelt. Wir arbeiten uns durch abstrakte Landmark-Rollen, praktische Landmark-Navigation, die Rolle option, aria-required, ariaNotify() und schließlich role="form". Dabei geht es wie immer darum, was die Spezifikation meint,…

  8. 10 Jul 2026 · 22 min

    On Tour @ #headinthecloud – Der Ransomware-Angriff auf guenstiger.de mit Torben Mallwitz

    Wir waren dieses Jahr erneut auf der Head in the Cloud von mittwald in Espelkamp unterwegs und haben dort mit Torben Mallwitz über einen Vortrag gesprochen, den man so vermutlich nur selten auf einer Konferenz hört. Torben, CTO von guenstiger.de, hat sehr offen darüber berichtet, wie das Unternehmen im April 2025 Opfer eines Ransomware-Angriffs wurde und welche technischen, organisatorischen und menschlichen Herausforderungen die folgenden Tage und Wochen geprägt haben. SHOWNOTES [00:00:27] RANSOMWARE, REALITÄT UND WIEDERHERSTELLUNG Am Morgen des 23. April 2025 begann für das Team von…

  9. E719 · 7 Jul 2026 · 1 hr 15 min

    Revision 719: Der EU AI Act, mit Florian Sowade

    Wir haben diese Revision mit Florian Sowade über den EU AI Act gesprochen. Florian hat sich in die Regulierung eingelesen und erklärt uns, was die EU damit eigentlich regulieren will, welche Risikokategorien es gibt und warum der Act nicht primär ein Verbot von KI ist. Gemeinsam sortieren wir ein, welche Pflichten schon gelten, welche noch kommen, warum Hochrisiko-Anwendungen anders behandelt werden als alltägliche KI-Tools und weshalb gerade Transparenz, Schulungspflichten, Trainingsdaten, Deepfakes und Auditierbarkeit in der Praxis noch viele offene Fragen aufwerfen. SHOWNOTES [00:01:03]…

  10. 3 Jul 2026 · 23 min

    On Tour @ #headinthecloud – Die Website der Zukunft mit André Richter

    Wir waren dieses Jahr erneut auf der Head in the Cloud von mittwald in Espelkamp unterwegs und haben die Gelegenheit genutzt, mit André Richter über die Zukunft der Website zu sprechen. André ist seit den frühen Tagen des Webs im Agenturumfeld unterwegs und beschäftigt sich heute als Director Digital Experience mit der Frage, wie Unternehmen auch in einer von KI geprägten Welt digital relevant bleiben können. SHOWNOTES [00:00:26] DIE WEBSITE DER ZUKUNFT Sterben Websites aus? Für André Richter lautet die Antwort: nein, aber sie verändern sich grundlegend. Die klassische Vorstellung einer…

Take it with you

The Melo app keeps playing with the screen off, works in the car and on your watch, wakes you to your station, and browses the whole catalogue offline. Free, no ads, no account.

Get it on Google Play