Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Vorstellung des Gastes
Ein Gast gestern noch auf der AI-Agent-Worldtour in Frankfurt, heute bei uns im Studio, Oliver Jägle.
Oliver, willst du dich kurz vorstellen?
Ja gerne, also mein Name ist Oliver Jägle.
Selbstbeschreibung
Wie der Ralf schon sagte, ich bin Soft-Werker; das sage ich immer, weil ich irgendwie dieses Werken ganz witzig finde und auch irgendwie wichtig.
Beruflicher Hintergrund
Also ich mache Software schon seit einer ziemlich langen Zeit, von Enterprise-Software bis hin ins Frontend.
Halt das, was anfällt.
Sehr cool.
Und du hast dich jetzt in letzter Zeit, wie die meisten von uns halt, mit AI beschäftigt.
Und du willst natürlich mit AI Software entwickeln und hast gemerkt, es läuft nicht ganz so gut.
Wir haben hier im Titel, in der Einladung von dem störrischen LLM gesprochen und du hast eine, wie ich finde, sehr coole Idee gehabt, wie man mit dem LLM besser umgehen kann.
Erzähl doch mal.
Initiale Erfahrungen mit KI
Ja, also eigentlich war das so ein bisschen so eine gewisse Identitätskrise Ende des letzten Jahres, durch die, denke ich mal, viele von anderen Software-Schaffenden auch gegangen sind.
Man hat auf einmal Tools gehabt, denen man einfach nur im Prompt hingeschmissen hat und innerhalb von kürzester Zeit ist eine Anwendung hinten rausgefallen, die auch noch zumindest auf der Oberfläche deutlich besser aussah als quasi alle Anwendungen, die ich so in meinem Frontend-Leben verbrochen habe.
Aber die auch unter der Haube gar nicht so schlecht war.
Qualität der Ergebnisse
Also wo man nicht einfach nur sagen konnte, der Code ist Grütze.
Wir haben alle generierten Code gesehen von Dreamweaver, generiertem HTML-Code bis hin zu Low-Code-Plattformen, die man debuggen musste.
Und das war auf einmal nicht mehr so, sondern eigentlich war es gar nicht störrisch, sondern fast eher das Gegenteil.
Am Anfang zumindest, da hatte ich das Gefühl, das fließt einfach so raus, wie so fließende Tinte aus einem Füller.
Das kommt einfach so direkt raus und sieht auch noch schick aus.
Und da hatte ich gar nicht das Gefühl, dass das störrisch ist.
Und dann, das denke ich mal, kennen viele andere Zuschauer auch, kommt man in so einen Flow rein und bestätigt quasi jede Rückfrage noch mal kurz, wenn überhaupt Rückfragen kamen.
Meistens kam ja einfach direkt was raus.
Und dann habe ich irgendwann nach dieser Magie gedacht, Moment, nimmt das mir meinen Job oder was macht das eigentlich?
Welchen Aspekt meiner Arbeit arbeitet jetzt dieses LLM oder diese Agenda ab?
Herausforderungen mit LLMs
Und dann habe ich gemerkt, dass ein ganz wesentlicher Teil, zumindest im Enterprise-Umfeld, dem ich ja auch bin, den wir bedienen müssen, da geht es eigentlich eher um Vorhersagbarkeit.
Erwartungskonformität
Also entspricht das Ergebnis der Erwartung.
Nicht nur ist es schick, ist es schnell, sondern diese Erwartungskonformität, die ist eigentlich total wichtig.
Und das haben mir wenige Tools gegeben.
Entwicklung des Workflow-Ansatzes
Und dann habe ich mich gefragt, woher das eigentlich kommt.
Und da bin ich jetzt sozusagen.
Woher kommt eigentlich Erwartungskonformität?
Wie erreichen wir das in der Software?
Und wie machen wir das jetzt mit LLMs zusammen?
Du sprichst da mit diesem Punkt an, dass man zwar mit einem kurzen Prompt echt ein cooles Ergebnis hat, was mittlerweile auch ziemlich funktioniert.
Und gerade Claude Sonnett denkt ja auch mit und macht noch ein paar Schleifchen dran.
Aber wenn man dann in den Code reinguckt, dann ist es dann doch nicht so ganz, wie man sich das vorgestellt hat, die Struktur und solche Geschichten, oder?
Ja, die Sache ist die, man kann nicht mal sagen, es ist schlecht, sondern es ist oft einfach anders.
Es entspricht einfach nicht der Erwartung oder auch den Artefakten, die ich zu diesem Zeitpunkt erwartet hätte.
Also zum Beispiel bedeuten früher Tests, als es Code macht.
Und das ist so diese Diskrepanz zwischen gar nicht mal falsch, auch definitiv nicht schlecht, aber halt nicht so, wie ich es gerne hätte.
Aber da haben wir ja dann alle angefangen, dass wir Mega-Prompts gebaut haben, in denen wir ganz genau beschrieben haben, du bitte benutze dies und jenes und mach Test-Driven und hier ist unser Style-Guide.
Und dann hatten wir damit zu kämpfen, dass manche Modelle das Instruction-Following besser können, andere schlechter.
Und du bist jetzt einen anderen Weg gegangen.
Genau.
Kontextsteuerung
Also das kommt eigentlich alles aus dieser Transformers-Architektur, wo eben Wahrscheinlichkeiten fürs nächste Token geraten werden.
Letzten Endes, je mehr wir reinstecken, desto schwieriger ist es auch Kohärenz für die Inferenz dann zu erreichen.
Weil es wird ja immer abgeleitet aus dem, was halt im Kontext drin steht.
Und wenn ich schon von Anfang an ein neues Projekt starte und in meinem riesigen Prompt schon Instruktionen hatte, wie gerne meine Tests geschrieben werden sollen, mit welchem Framework oder nach welcher Methodik oder wie auch immer.
Das ist am Anfang von meiner Projektphase nicht nur irrelevant, sondern ist sogar schädlich für die Inferenz, weil ich eben damit die Kohärenz von dem, woraus abgeleitet wird und das ist ja letzten Endes alles, worauf diese Gen-AI Sachen beruhen, worauf Transformers im Moment zumindest beruht.
Dann wird diese Kohärenz schlechter und meine Erkenntnis war eigentlich ganz wesentlicher Teil von dem, was wir mittlerweile auch Kontext-Engineering nennen, ist eigentlich nicht nur die richtige Information bereitzustellen für die Inferenz, sondern vor allem auch zum richtigen Zeitpunkt.
Und dann sind wir halt zurück: Erstes Semester Softwareentwicklung, V-Modell oder irgend so etwas.
Warum gibt es denn diese Phasen und was macht man denn eigentlich so in diesen Phasen?
Und ist das eigentlich noch State of the Art?
Wer entwickelt denn eigentlich noch ein V-Modell?
Manche entwickeln vielleicht nach TDD.
Das ist eine ganz andere Methodik.
Wenn ich einen Bug fixe, mache ich das ganz anders, als wenn ich ein neues Feature entwickle.
Da versuche ich erstmal zu reproduzieren.
Kann ich bei einer neuen Feature-Entwicklung gar nicht machen.
Also kurzum, ich habe gemerkt, dass diese Workflows, wie ich es dann genannt hatte, dass die total wichtig sind, nicht nur für uns Humanoide, sondern eben auch, wenn wir ein LLM führen wollen, dass wir dann diese Methodiken wiederverwenden können und eben zum richtigen Zeitpunkt die notwendige Information in den Kontext packen.
Wenn du von Workflows sprichst, dann habe ich gerade so im Kopf ganz viele Agentic Workflows, wo ein starrer Workflow genommen wird und von einer normalen Workflow-Engine ausgeführt wird und in manchen Stellen dann eben ein LLM irgendwie Arbeit verrichtet.
Jetzt hast du aber umgedreht.
Ja.
Du rufst nicht aus dem Workflow das LLM auf, sondern …
Ja.
Was ich gemacht hatte war, ich habe erstmal als Oliver, als Humanoide, dem über Prompts, dem LLM versucht beizubringen, in welchem Workflow oder in welchem Schritt in dem Workflow es sich befindet.
Das kennt ihr vielleicht auch, da habt ihr dann angefangen und gesagt, okay, jetzt wollen wir uns mal um die Requirements kümmern, bitte kümmere dich mal noch nicht um Tests, schreib keinen Code, schreib noch nicht mal Pseudocode, sondern lass uns erstmal nur überlegen, was da so dran ist.
Das habe ich ins Prompt reingetippt und das hat mich dann irgendwann, ich bin kein super disziplinierter Mensch, das hat mich dann irgendwann selbst genervt, dass ich immer wieder die gleichen Sachen reingepackt habe.
Ich konnte es aber auch nicht in Rules Files schreiben, weil die immer gleich im Kontext sind.
Also musste ich irgendwie mir ein Mittel schaffen, wie ich dem LLM eine Möglichkeit gebe zu erkennen, an welchem Schritt es in einem Workflow ist und eben nicht einen Agenten aufzuoktroyieren, der weiß, wie es abläuft, sondern einfach nur diesen Zustand zu exponieren, damit das LLM sich diesen Zustand holen und entsprechend darauf agieren kann.
Okay, also ich meine, wenn ich so ein Megaprompt geschrieben habe, dann war das immer so mit dem Ziel, ich schreibe einen Prompt und das LLM macht alles eigenständig, das heißt, ich habe in dem Prompt die verschiedenen Schritte schon vorgegeben.
Du sagst jetzt, du bist eher in den Dialog gegangen, hast gesagt, komm, jetzt lass uns erstmal die Requirements machen und wenn wir die Requirements haben, dann erzähle ich dir, was du damit wiederum machst, die Architektur erstellen, Pseudocode, solche Geschichten, die einzelnen Schritte.
Ich hatte immer so das Problem, wenn er in der Arbeit drin war, dann hat er diesen Prompt immer mehr vergessen.
Wenn du in den Dialog trittst, dann hast du natürlich immer die frischen Anweisungen, wobei du ja auch teilweise so ein Klotz und nett zurückhalten musst.
Du sagst, ich habe hier Requirements, ich lege gleich los.
Ja, absolut.
Und deshalb habe ich, also ich habe mich erstmal dann diszipliniert und immer wieder abgebrochen, wenn Claude zu hektisch war und dann gesagt, komm nochmal wieder zurück auf den Pfad.
Und ich habe gemerkt, dass es mich ermüdet und mich als Engineer stresst, dass ich eigentlich diesen Flow noch komplett erhalten muss, also den Workflow steuern muss und gleichzeitig auch noch Architekturentscheidungen oder Codeentscheidungen, Designentscheidungen treffen muss.
Und deshalb habe ich mir das dann ausgelagert an ein Tool, das dann diese Workflows abarbeitet, beziehungsweise nicht abarbeitet, sondern die Information über den Ablauf kontinuierlich und sehr persistent dem LLM immer wieder anrät.
Das MCP Tool
Das ist dann dein MCP, was daraus entstanden ist und was du veröffentlicht hast.
Ich laufe mal gerade hier die URL von dem Source Repository rein, dass man ein bisschen böbern kann.
Responsible Vibe MCP.
Erzähl mal, was macht das?
Namensgebung
Ja, also der Name, der ist, vielleicht gibt es auch nochmal ein Rebranding, das habe ich dir noch gar nicht gesagt.
Vielleicht gibt es auch nochmal ein Rebranding in Richtung Workflows, aber am Anfang fing es wirklich mit diesem Responsible Vibe an.
Mir hat ein Kollege, der Ralf, der hat mir gesagt, dass er diesen Begriff Vibe Coding gar nicht mag, weil das so nach Wegwerfen und ich mache mal nur schnell.
Ich habe gedacht, aber eigentlich dieses, ich finde das ganz nette, also ich habe das gerne, diese Idee, es ist ein Flow, in den man kommt, ein kreativer Flow.
Ich denke auch immer noch, dass unser Handwerk, also Software entwickeln, immer noch eine kreative Tätigkeit ist und dass man dann eben diesen Flow zu erhalten, dass das eine total wertvolle Sache ist.
Aber ich wollte es eben verantwortungsbewusst tun und habe das deswegen Responsible Vibe genannt und ich habe das als MCP Server implementiert.
Sollen wir nochmal sagen, was ein MCP Server ist?
Wir hatten letztens eine Folge, da sind wir tief in die Details reingegangen, also nicht ich, sondern ich weiß gar nicht mehr, wer das genau war.
Auf jeden Fall, ich hoffe, es ist hier jetzt bekannt, es ist Tool Calling für die LLMs.
Das heißt, die LLMs können da ein externes Tool verwenden, was ziemlich cool ist.
Ich wollte gerade noch ergänzen mit dem Responsible Vibe, dieses Vibe Coding.
Wir sind hier bei Software Architektur im Stream und Software Architektur und Vibe Coding, das passt halt irgendwie nicht so zusammen.
Vibe Coding hört sich an wie, naja, ich mache da mal was und dann die Architektur, die wird sich schon irgendwie finden.
Happenstance.
Genau.
Das glaube ich halt gerade nicht, sondern es geht darum, dass wir halt trotzdem ernsthafte Software engineeren und da finde ich es einfach einen wichtigen Aspekt.
Also ist Architektur ein wichtiger Aspekt, aber die Kreativität ist halt auch ein wichtiger Aspekt.
Also oft geht es auch darum, Sachen auszuprobieren, Alternativen zu evaluieren.
Ich hatte lange Zeit, ich hatte es gerade gesehen, dass der Eric gefragt hat, was wäre eine Alternative zu Vibe Coding.
Ich hatte tatsächlich vor einem Jahr oder sowas, als Bold New rauskam, das war für mich so der Moment, da habe ich das Prompt Driven Development genannt.
Weil ich gedacht habe, okay, das, was das Ganze treibt, ist das Prompt.
Aber ich finde auch diesen kreativen Flow einen total wichtigen Aspekt und das eben verantwortungsbewusst zu tun, finde ich.
Ich habe gerade nochmal nachgeschlagen, Martin Lippert hatte hier auf dem Kanal das MCP erklärt, das Protokoll Model Context Protokoll.
Ja, soll ich mal zeigen, wie sich das so verhält?
Also mal wirklich so Show Me Code in dem Sinne?
Ja, dann leg mal los und erklär mal die Idee am Beispiel.
Ich hoffe, dass die Schrift nicht zu klein ist.
Ja, man muss vielleicht einen großen Monitor, wir werden es aber alles erklären damit.
Genau, ein bisschen größer.
Praktische Demonstration
Ich habe mir jetzt hier tatsächlich, ich arbeite jetzt hier mit dem MSNQ CLI.
Warum ich das Tool nutze, könnt ihr mich gerne ansonsten auch nochmal fragen, aber ich nutze es jetzt einfach.
Es funktioniert dahingehend ganz gut, weil es relativ gut erklärt, was es eigentlich tut.
Man kann es relativ gut nachvollziehen, ohne dass es zu wild wird.
Das ist jetzt so ein CLI Chat Tool wie Cloud Code oder ich glaube es gibt auch von Google irgendwie so ein Gemini Tool.
Also sind alle relativ gleichwertig.
Genau, es ist halt nur so, wenn ich das in der IDE habe, also letzten Endes habe ich ja immer eine Anwendung und in dieser Anwendung, da ist oft noch so viel Feenstaub drüber gestreut, dass ich persönlich es manchmal gar nicht so einfach finde zu verstehen, was kommt jetzt aus der IDE?
Wo lädt die noch Kontext rein in meinen Prompt?
Und hier habe ich zumindest das Gefühl, dass ich eine bessere Kontrolle darüber habe.
Und ich nehme es jetzt, auch wenn du, Ralf, du hast es schon im vorherigen Gespräch gesagt, so eine To-Do App, die bauen die ganzen LLMs einfach aus ihrem Gedächtnis, das haben sie schon im Training drin.
Und To-Do, also es ist wirklich nichts für Software Architektur TV.
Ich werde auch nicht lange mich daran aufhalten, dass wir eine To-Do App brauchen, aber ich möchte gerne daran, weil es einfach schnell geht, wir brauchen nicht viel Code zu produzieren, wir haben auch nur begrenzte Zeit, möchte ich gerne kurz das Prinzip zeigen.
Und ich habe dem LLM jetzt hier gesagt, hier, ich möchte ein To-Do von der grünen Visa App bauen.
Und dann sehen wir halt, was die LLMs tun.
Die fangen direkt an und legen eine Index HTML Seite an.
Ich habe dem Ding nirgendwo gesagt, dass ich eine Web-Anwendung möchte.
Keine Ahnung, aber es ist halt so drin im Modell.
Da werden Annahmen getroffen und entspricht nicht meiner Erwartung.
Jetzt muss ich aber auch ganz selbstkritisch sagen, ich habe auch keine Erwartung geäußert.
Aber er hat auch nicht nachgefragt.
Also ich meine, normalerweise würde man ja unter Umständen nachfragen.
Es sei denn, man ist der HTML-JavaScript-Entwickler, aber man trifft so unterschwellig Annahmen, wenn man so eine Aufgabe kriegt.
Und jetzt starte ich das Gleiche und starte das mit einem konfigurierten Agenten.
Und damit das nicht als Magie hier stehen bleibt, mache ich das auch ganz transparent und zeige mal, was in dieser Agenten-Konfiguration drinsteht.
Wobei man muss glaube ich dazu sagen, die Agenten bei Amazon QCLI sind eher Profile.
Aber du zeigst ja jetzt gerade, was drinsteht.
Ich zeige jetzt, was drinsteht.
Das ist jetzt hier natürlich nicht super schön formatiert.
Worum es darum geht ist, das Ding hat einfach einen Namen, damit habe ich es aufgerufen.
Der wesentliche Teil, und den wollte ich nur zeigen, ist, auch hier hat man die Möglichkeit, einen Prompt zu hinterlegen.
Und der wesentliche Teil, auch wenn man das jetzt hier vielleicht nicht so schön formatiert sieht, ich habe ihn angewiesen, einfach nur die Tools aus dem Responsible Vibe MCP-Server nach jeder Nachricht zu rufen.
Mehr Magie ist da nicht drin.
Das heißt, es ist zwar auch ein Megaprompt, aber dieser Megaprompt ist quasi der letzte Megaprompt, den man braucht, weil er das LLM anweist, wie Responsible Vibe verwendet wird, dein MCP.
Genau.
Wobei dieser Prompt verglichen mit einem Megaprompt eher ein Miniprompt ist.
Also wenn ich das Ganze, also das passt locker auf, das sind glaube ich 50 Zeilen oder sowas, wenn man das mit einer normalen Schriftart ausgibt, verglichen mit den 2000 Zeilen von dem ersten V0 Megaprompt ist das also eher ein Miniprompt.
Vielleicht sollten wir auch erwähnen, dass du das Tool so gestrickt hast, dass wenn man den Setup macht, das Tool selbst einem diesen Prompt ausgeben kann, dass man den leicht rüberkopieren kann.
Auch wenn sich da was ändert oder so eine neue Installation, dann kann man den wieder rüberkopieren.
Genau und ich gucke mal gerade, das müsste ich noch irgendwo in der Shelfhistorie haben.
Hier sieht man es auch nochmal ein bisschen schöner, was da drin steht.
Also das hier ist der gesamte Prompt und da steht eben drin, was es tun soll.
Im Wesentlichen geht es da drum, das LLM dazu zu bringen, eben Tools aufzurufen.
Die Tools, die sehen wir dann hier.
Da sehen wir eben aus diesem Responsible Vibe MCP Server gibt es dann jetzt eben einige Tools und die zeige ich jetzt einfach in Aktion.
Ich glaube jetzt hier mag ich nicht ins Detail die Fragen dazu gerne auch im Chat.
Wenn es dann, das war gerade, in der Session ein Clear zu schreiben, das war jetzt nicht der Sinn.
Noch einmal hier Clear und dann noch einmal Agent Vibe.
Und jetzt wird einfach nur dieser System Prompt verwendet und es werden eben diese Tools initialisiert.
Und wenn ich jetzt den gleichen Prompt nehme, ich mache mal hier drüben das zu, damit wir etwas mehr Platz haben.
Und wenn ich jetzt das gleiche Prompt losschicke, dann macht jetzt in dem Fall das QCLI, aber das würde Cloud oder auch das Gemini CLI.
Da habe ich jetzt ungefähr 27 mal gesagt dieses Wort.
Ich zeige jetzt mal gerade, wie das aussieht.
Ja, Ralf, wolltest du noch was ergänzen?
Ne, ne, passt schon, dass du jetzt den Workflow zeigst, weil das finde ich das Spannende, dass es jetzt, das MCP implementiert quasi eine Workflow-Engine und die Aufgabe ist es jetzt, diesen Workflow zu durchlaufen für das MCP.
Workflow-Steuerung
Genau, also und es hat jetzt die Möglichkeit bekommen, diesen Workflow zu starten.
Es hat diesen Workflow auch selbst gewählt und zwar, das ist ja das Spannende an Tool Use mit LLMs, wenn in den Metadaten des Tools drin steht, welche Workflows es gibt und dafür habe ich natürlich gesorgt, dann weiß das LLM selbst, okay, ich habe hier einen Workflow, der heißt Greenfield und das ist ein Workflow, um neue Sachen from scratch anzufangen, wofür ich das brauchen kann und sowas und das wählt sich dann das LLM selbst.
Und es gibt ja auch andere Workflows, zum Beispiel gibt es eben einen Bugfix Workflow, den ich vorhin erwähnt hatte.
Der sieht halt ganz anders aus, wenn ich einen Bugfix machen möchte, dann fange ich erstmal an und hätte gerne eine Reproduktion von meinem Bug.
Das ist das allererste, was ich als Responsible Developer mache.
Ich widme mich der Reproduktion und danach analysiere ich den und fixe den.
Aber jetzt gehen wir mal kurz zurück zu dem Greenfield Workflow, den das LLM jetzt gedacht hätte, dass das eine coole Sache wäre, wenn man diesen nutzen würde und da sehen wir, der beginnt mit einem Schritt, der heißt Ideation.
Dann kommt eine Architektur, dann wird geplant, dann wird entwickelt und am Ende wird das Ganze abgeschlossen.
Das ist etwas, was ich mir ausgedacht habe, weil ich, Oliver, so arbeite.
Jetzt gehe ich mal hier weiter und sage, ja, das Tool, das lasse ich jetzt ausführen.
Das heißt, er hat jetzt verstanden, er soll mit dem Responsible Vibe, mit dem Workflow arbeiten.
Er hat jetzt sich den Greenfield Workflow ausgewählt.
Du hast ja auch gesagt, ich möchte das auf der grünen Wiese machen.
Er weiß, er soll es starten, deswegen Start Development.
Genau.
Und was sehen wir jetzt, was er zurückbekommen hat?
Nee, das sehen wir nicht.
Wir sehen das hier leider nicht.
Wir können das aber uns in dem MCP-Inspektor, was ja so ein bisschen wie das Tool ist, wie ein Open API für MCP.
Und da können wir uns das angucken.
Und da gibt es dann eben dieses Start Development Tool.
Und da sehen wir, wenn wir da reingucken, in den Metadaten des Tools steht eben drin, welche Workflows es gibt.
Und den hat es versucht auszuführen.
Und dann bekam es einen Fehler zurück und bekam gesagt, du, das kann ich noch gar nicht machen.
Moment.
Ich muss hier den Workflow Greenfield eintragen.
Führe ich den nochmal aus.
Und dann sagt er, kann ich gar nicht machen, habe ich mich vertippt.
Greenfield.
Also in der Beschreibung von dem Start Workflow hat er die verschiedenen Workflows, wofür die gut sind.
Wählt deswegen den aus.
Dann wird gestartet.
Success.
Genau.
Und dann sagt er noch, oh, ich würde noch gerne Projektdokumentationen anlegen, weil wir ja alle Dokumentation lieben.
Dokumentation hat meines Erachtens einen ganz wertvollen Aspekt in unserer zukünftigen Interaktion mit LLMs, weil es eben das Langzeitgedächtnis ist.
Also was ist denn eigentlich, wie sieht denn meine Anwendung eigentlich aus?
Wie sieht deren Architektur aus?
Ob das jetzt eine A42 ist oder irgendeine Freestyle Architektur.
Es gibt irgendwo ein Langzeitgedächtnis, in dem das Ganze dokumentiert ist.
Das, dass er die Dokumentation anlegen soll, steht das im System Prompt oder wo hat er das jetzt her?
Das hat er daher, weil der Workflow Greenfield auf Langzeitdokumentation zurückgreift.
Und wenn ich ihn starten will, dann gibt es dann einen Fehler.
Dann sagt er, du, ich kann das noch gar nicht machen, weil da gibt es noch keine Dokumentation.
Zeigt mir, lasst uns die doch gerade zuerst anlegen.
Und dann würde ich dem jetzt hier eben sagen, ja, das darfst du auch machen.
Und jetzt kann er dann auch diesen Workflow letztlich starten.
Was ich verstanden habe, ist, dass du das Feature ausnutzt, dass jede Antwort von dem MCP eben auch wiederum ein Prompt ist.
Und du ihm dadurch sagst, du, du kannst den Workflow noch gar nicht starten.
Ich brauche hier jetzt noch Dokumentation.
Bitte ruf nochmal die und die Methode Funktion auf.
Ja, das heißt, du nutzt das voll aus, dass das jede Antwort neuer Prompt ist.
Ja, also fast jede Antwort ist eine Antwort.
Diese Antwort ist eine strukturierte Antwort.
Und eine Property dieser strukturierten Antwort sind Instructions.
Und in dem System Prompt ist gesagt, wenn du die Tools aufrufst, dann bekommst du Instructions zurück.
Bitte befolge die.
Das ist, das ist die ganze, die ganze Magie.
Und jetzt hat das Tool eben angefangen, sich nicht nur diese, dieses Langzeit Gedächtnis anzulegen, sondern hat sich auch ein, ich sage immer Prozess Gedächtnis angelegt.
Ich zeige das einfach mal hier.
Denn wir wollen ja letzten Endes, das ist ja zumindest das Versprechen der heutigen Session.
Wir wollen ja gerne in dieser Session zeigen, wie man das störrische LLM irgendwie führt.
Und jetzt hatten wir schon gesagt, wir haben das Langzeit Gedächtnis in der Dokumentation.
Diese Dokumentation ist noch leer, können wir uns auch gleich angucken.
Und hier haben wir ein Prozess Gedächtnis und dieses Prozess Gedächtnis, das enthält die Phasen, die wir aus unserem Workflow kennen.
Weil zu jeder Phase etwas anderes relevant ist.
Und dieses Prozess Gedächtnis, das dient jetzt eben dafür, das LLM kontinuierlich daran zu erinnern, was in der jeweiligen Phase notwendig ist.
Das heißt, diese To-Do-Liste, die da jetzt angelegt worden ist, erkennt die Phasen des Workflows und legt deswegen für jede Phase was an?
Oder ist das jetzt ein Template, was vorgegeben ist und er ist einfach nur stur abarbeitet?
Ja, das Witzige ist, dass dieses Template halt aus dem Workflow generiert wird.
Also einfach für jeden Workflow Schritt wird ein eigener Abschnitt hier angelegt.
Da steht nur als Kommentar drin, ursprünglich, trag mal bitte hier in dieser jeweiligen Phase ein, was du da für Aufgaben hast.
Also Platzhalter sozusagen und dann erweisen wir einfach das LLM an, das zu füllen.
Und jetzt gibt es da eben aber auch noch mehr Instruktionen.
Ich kann ja mal die Instruktionen jetzt zeigen, die das LLM bekommen hat.
In der Ideation-Phase, da steht eben drin, du bist in der Ideation-Phase, verstehe, was das System tun soll, wer es verwendet, warum man es braucht und was in oder out of scope ist.
Gibt es da Grenzen oder sonst irgendwie?
Hast du schon validiert?
Das sind Fragen, die möchte ich eigentlich gestellt bekommen, wenn ich zu diesem Zeitpunkt meines Entwicklungsprozesses arbeite.
Ich möchte noch nichts über mein Test-Framework wissen.
Ich möchte ganz andere Fragen bekommen.
Und jetzt kriegt von deinem MCP das LLM diese Fragen und fängt an, die Antworten zu halluzinieren.
Genau, wenn man es einfach laufen ließe, würde es halluzinieren, also implizit halluzinieren.
Aber weil da eben drin steht in dem Prompt, verstehe das, dann fragt es eben nach.
Das weiß es noch nicht.
Es bekommt nicht gesagt, überleg dir was, sondern verstehe das und es reicht als Trigger, um eine Nachfrage zu stellen.
Man könnte auch explizit fragen, auch eine Zeit lang gemacht, es hat sich so hässlich gelesen.
Frag beim Benutzer nach, was dies und jenes ist.
Das steht einfach als Instructions drin, es kommt zurück.
Und das sind dann die Sachen, wo ich jetzt als Engineer anfange zu arbeiten. Überleg mir hier, was ich dem hier sagen möchte.
Und ich bin ja auch vollkommen schmerzlos, was irgendwie meine Sprache anbelangt oder sowas.
Ich will ja auch in den Fluss kommen.
Also manchmal sowas wie so ein Penster oder sowas, das schreibe ich einfach, weil es für mich den Fluss, ach komm, das brauchst du jetzt wirklich nicht fragen.
Ist natürlich irgendwo Blödsinn, aber es hilft mir und das ist der wesentliche Teil, es hilft mir als Engineer in diesen Flow, in einen kreativen Flow zu kommen.
Ist jetzt natürlich auch nur hier eine Demo und der begrenzten Zeit geschuldet, dass du jetzt hier nicht ausführlich deine Requirements runterschreibst.
Aber ich finde das schon mal sehr cool, dass er jetzt eben hier in den Lead geht und die Fragen stellt und nicht einfach loslegt.
Ich hätte gerne ein CLI.
Ich finde das immer klasse, wie der das mit der CLI macht.
Ja, weil es zu wenig CLI-To-Do-Apps gibt, finde ich auch.
Und ich werde das jetzt nicht komplett durchgehen.
Ich möchte jetzt einfach nur mal die Methodik hier in diesem Stream zeigen.
Das muss man einfach selbst mal ausprobieren.
Das ist eigentlich wie ein sehr renitenter Projektmanager, der mit dem LLM spricht und das LLM wiederum interagiert mit mir, um meine Informationen herauszuholen.
Und jetzt gucken wir uns an.
Okay, verstanden.
Das persönliche CLI-To-Do-App.
Klarer Scope.
Jetzt kommt die Kernkompetenz für mich von einem Engineer in Zukunft.
Man muss schnell und viel lesen können.
Okay.
Genau.
Jetzt fragt er mich hier nach Persistierung, nach Kategorien, nach Status, auch in Progress.
Einfache numerische Liste reicht.
Textdatei.
Ja, das ist schon interessant.
Also, das ist jetzt total…
Also, jedes Mal ist es ein bisschen anders.
Und schreiben wir jetzt einfach Persistenz in YAML.
Der hat jetzt aber noch zwischendrin einen anderen Function Call gemacht.
What’s next?
Genau.
Ah ja, dankeschön, dass du da…
Also, ganz unten, ne?
Ja, das wird aber im QCLI auch so rum angezeigt.
Also, hier unten steht nochmal ein What’s next.
Das verstehe ich ehrlicherweise nicht.
Ich glaube, das ist ein Anzeigefehler im QCLI.
Weil das hier war schon die Rückgabe.
Also, der wesentliche Teil war…
Aber dieser What’s next hier, der war relevant, ne?
Und…
Mal gucken.
Mal kurz schauen.
Nee.
Das ist dieser What’s next.
Aber der wird an der falschen Stelle eingefügt in der Konversation.
Aber das ist tatsächlich das, was als Kontext an das LLM rübergeht.
Das wird jetzt nur an der falschen Stelle hier ausgeprintet.
Deswegen gehe ich gerade hier so ein bisschen hoch, ne?
Ihr seht ja, dass…
Aber du sagst, was als Kontext rübergeht.
Das finde ich nämlich spannend.
Wenn ich das jetzt richtig sehe, hat dieser What’s next einen Parameter, nämlich den Kontext.
Und das LLM passt den Kontext zusammen und sagt sich, das ist jetzt für den Workflow relevant an Kontext.
Nicht der komplette Kontext bei 100.000 Token, sondern das, was relevant erscheint.
Genau.
Und das liegt daran, weil hier in diesem What’s next Tool einfach hier drin steht, als Kontext…
Brief description of what you’re currently working on or discussing with the user.
Und aufgrund dieser Metadaten geht dann das LLM hin, fasst die letzte Nachricht von mir zusammen oder bereitet sie auf.
Darum sind auch meine Rechtschreibfehler, meine Kürze.
Ist alles gar nicht mehr so super wichtig, sondern das geht einfach hier eben mit rüber, wird aufbereitet und damit kann ich halt wieder total gut arbeiten.
Also dieses hier persönlich CRI grundlegende Features einfach.
Das ist ja aufgrund von meiner kurzen Antwort, die ich gemacht hatte, hier zusammengefasst.
Und so wird halt der Kontext etwas kuratiert und prinzipiell qualitativ besser, als wenn ich das nicht hätte.
Okay, also das LLM hat den Workflow gestartet.
Es hat gelernt, dass es erstmal Dokumentation anlegen soll.
Hier eine To-Do-Liste.
Hat Nachfragen gestellt.
Weitere Nachfragen.
Okay, das heißt, du bist jetzt im Dialog mit dem LLM.
Nimmst ihm dadurch die Chance, irgendwie einfach loszulegen und HTML zu machen.
Jetzt bin ich gespannt.
Ah, er geht tatsächlich jetzt in die To-Do-Liste rein und sagt, wow, jetzt habe ich was geschafft, oder?
Ja, genau.
Er fängt jetzt hier an, weil wir in der Ideation-Phase sind.
Und das steht eben in meinem Prozessgedächtnis drin.
Jetzt fängt er an, sich nach und nach hier die Sachen abzuhaken, die er schon geklärt hat.
Die zieht er sich hier runter.
Die Struktur, nach der er das macht, oder E’s.
Ich finde eigentlich, man sollte sich das saarländische E’s mehr angewöhnen, weil die immer männlich sind.
Und ich habe noch niemanden gehört, der gesagt hat, sie, ich finde E’s.
Also E’s hat sich hier überlegt, jedenfalls, wie es diese Information abspeichert.
Und das ist mir auch total schnuppe, denn das ist das Prozessgedächtnis, das dazu dient, das LLM zu führen.
Und jedes LLM macht das auch ein bisschen anders.
Also wenn man mit dem Gemini arbeitet, dann schreibt es sich ein bisschen anders auf.
Aber das ist auch mir schnuppe, denn es geht darum, zu wissen, wo bin ich im Prozess.
Aber du benutzt ja jetzt hier Claude.
Also meine Erfahrung mit Claude ist, wenn ich sage, schreibe dir einen Plan, eine To-Do-Liste und implementiere erst dann und aktualisiere immer die To-Do-Liste, dann legt er los, bis er endlich irgendwann fertig ist mit der Applikation.
Und dann sagt er sich, wenn ich Glück habe, ach, da war ja noch eine To-Do-Liste im Plan und hakt alles ab.
Hier hast du ihn dazu gebracht, dass er tatsächlich eben zwischendurch, zwischen den Schritten, weil er eben jetzt diese Aufgabe hat, erst mal die Requirements abzufragen, das dann tatsächlich zwischendurch abhakt.
Genau.
Das ist ja schon mal eine gute Steuerung.
Genau.
Das liegt daran, weil er eben in diesem What’s Next als Steuerungsinformation stets zurückbekommt, was es tun soll.
Also hier steht dann drin, okay, guck dir die Plandatei hier an und fokussiere dich auf die Ideation-Phase.
Das steht hier drin in der Rückgabe von dem What’s Next.
Und dadurch motiviere ich, dass eben das Prozessgedächtnis erhalten und kontinuierlich gepflegt wird.
Nur noch mal ganz kurz dazu, das könnte ich auch alles ohne das Tooling machen.
Ich müsste nur eine sehr große Disziplin an den Tag legen, dass ich immer wieder unterbreche und diese Prompts zurückschicke und jedes Mal wieder sage, bitte guck dir die Plandatei an.
Das könnte ich genauso machen.
Das sind alles nur Informationen, phasengestützte Informationen, die an das LLM zurückgehen.
Das müsste ich nicht mit dem Tool machen.
Ich finde mein Tool natürlich großartig, sonst hätte ich es nicht geschrieben.
Das ist vor allem für meine eigene Disziplin.
Man kann das auch genauso einfach durch Prompts erreichen, die man zum richtigen Zeitpunkt dann eben bringt.
Aber was macht jetzt das What’s Next?
Ich sehe hier gerade bei mir den Flow.
Wir sind in der Ideation-Phase und jetzt suche ich einen Übergang.
What’s Next, den finde ich gerade nicht.
Der bleibt ja in derselben Phase.
Der What’s Next ist ja auch kein Phasenübergang.
Zu dem Phasenübergang kommen wir gleich, Ralf.
Er hat noch eine Sache.
Er sagt auch, jetzt brauche ich nur noch eine Info.
Nur noch eine Info liegt daran, dass hier drin steht, Text-Stack auswählen.
Er hat hier auch noch so ein paar andere Sachen.
Er hat mir noch rübergegeben, wie die CLI aussehen soll und wie die YAML-Struktur aussehen soll.
Die hat er hier mit zurückgegeben.
Da lohnt es sich dann immer mal zu lesen, was noch so hier zurückkommt.
Das sehen wir jetzt genau, dass das die Sachen hier sind.
Die Programmiersprache, die Kommandos, die hat er gerne noch mal bestätigt.
Und die YAML-Struktur, die hätte er hier gerne bestätigt.
Das sind die Sachen, die wir eigentlich jetzt auch darin gesehen hatten.
Und jetzt würde ich noch sagen, es ist natürlich ganz gefährlich, wenn ich jetzt sage, nimm irgendeine Programmiersprache, die ich nicht kenne.
Aber natürlich muss ich das machen, einfach weil ich es spaßig finde.
Und das würde ich natürlich in Produktion überhaupt nicht tun.
Sondern jetzt würde ich hier eigentlich genau diesen Teil machen und sagen, du, ich kenne meinen Framework, in dem ich arbeite.
Und natürlich wähle ich das aus.
Ich habe jetzt einfach nur was anderes genommen, weil ich es ansonsten langweilig finde.
Ich glaube, gestern habe ich Python genommen oder so.
Und jetzt nehme ich halt mal Colang.
Kenne ich ja auch nicht, aber soll ja toll sein.
Das wäre auch noch eine Variante gewesen.
Und jetzt, was jetzt eigentlich das Interessante ist, jetzt sagt er, okay, ich habe das jetzt alles gesammelt.
Und ich schreibe jetzt Langzeitgedächtnis.
Wir hatten das Prozessgedächtnis.
Und jetzt fügt er hier eben die Sachen halt ein ins Langzeitgedächtnis in Form der Requirements.
Und da steht jetzt eben drin, was wir eigentlich besprochen haben.
Und wir gucken, der wird wahrscheinlich auch dann noch hier…
Dann sagt er, okay, ich bin jetzt mit der Ideation fertig.
Gibt mir jetzt hier noch eine Zusammenfassung.
Ich würde natürlich, wenn wir jetzt nicht hier im Stream wären und ein bisschen unter Zeitdruck, würde ich natürlich sagen, du, lass mich da nochmal genauer drüber gucken.
Und das ist genau der Teil, wo ich dann viel mehr noch bewusste Entscheidungen treffen würde.
Dann hat er gesagt, okay, eigentlich habe ich alles abgehakt, was es in dieser Phase gibt.
Und jetzt gehe ich weiter zur Architektur.
Das Ergebnis von diesem Proceed-to-Phase, das sehen wir jetzt hier leider nicht, weil das QCLI nicht ausgibt, gingen jetzt die neuen Instruktionen wieder zurück, und zwar diese Instruktionen, die wir dann eben hier an der Architekturphase sehen.
Du bist jetzt in der Requirements-Phase, guck dir die Requirements aus diesem Requirements-Dokument an, designe eine technische Lösung, frag den Benutzer nach technischen Wünschen und Erfahrungen, challenge their choices by presenting authenticism, schauen was er tut.
Du hast jetzt an den einzelnen Spritten hast du Prompts dran, aber du hast auch an dem Übergang Instruktionen dran, wann er welchen Übergang nutzen soll und wenn er ihn nutzt, sehe ich hier, present the PRD to the user.
Genau, das ist hier drin und das hat er dann auch gemacht, er hat mir an diesem Übergang das eben dann gemacht und gibt mir jetzt nochmal hier eine Übersicht und jetzt fragt er mich eben, wie hätte ich denn gerne das Ganze, hätte ich das gerne, also ich gucke jetzt einfach nochmal drüber hier, was so geschrieben wurde, okay wir sind jetzt technische Architektur, ich muss jetzt zugeben, das ist jetzt halt für so ein CLI nicht so, also wenn wir jetzt eine Enterprise-Anwendung hätten, wäre hier ein bisschen mehr zu tun, und ob man das jetzt hier Architektur nennt, ich sehe schon Eberhard sich gerade die Haare raufen und sagen, das ist doch keine Architektur, du hast recht Eberhard, das ist keine Architektur, es sind Entscheidungen, ich würde eher sagen, es sind Design-Entscheidungen als Architektur-Entscheidungen.
Ja gut, ich meine Architektur ist die Summe der Entscheidungen, die über Erfolg oder Misserfolg bestimmen, also von daher, passt schon.
Genau, und dann sagt er hier, wollen wir eigentlich hier Cobra verwenden.
Was ist denn Cobra?
CLI-Framework Cobra.
Featurereich.
Das Flag Package.
Das sind aber jetzt Fragen, wenn ich jetzt Ahnung hätte von Golan, dann werden die mir hier präsentiert, und das ist eben genau dieser Prompt, der hier drin steht, da steht hier Challenge their choices by presenting alternatives.
Das ist einfach nur ein phasenorientiertes Prompt Engineering, und das tut das Tool jetzt hier, und ich treffe jetzt diese weiterhin, aber eben reproduzierbar oder predictable, responsible oder wie auch immer, ich treffe diese Entscheidung.
Aber sehe ich das richtig, du bist zwar jetzt quasi in diesem Workflow-getriebenen Prozess, du kannst aber jetzt an der Stelle temporär ausbrechen, indem du das LLM mal fragst, ja was ist denn Cobra eigentlich?
Das hatte er jetzt dankbarerweise ja schon drüber geschrieben, dass das ein CLI-Framework ist, und ich möchte es wirklich ultra-minimal haben, und ich treffe dann diese Entscheidung.
Und wie du gesagt hast, aber genau diese Entscheidungen, die sind das, was für mich auch das Software Engineering eigentlich reizvoll macht, weil ich eben das bekomme, was ich erwarte, also ein erwartbares Ergebnis und nicht ein schnelles oder beliebiges Ergebnis.
Genau, und wir würden jetzt da halt weitermachen, und es ist leider hier in dem QCLI, ich ärgere das, die haben das in einer der letzten Versionen beim Output irgendwie ein bisschen verbockt, dass jetzt das What’s Next immer nochmal unten geschrieben wird und ich scrollen muss, das war mal eine Zeitlang früher, ich habe jetzt eigentlich noch was zu wissen zur YAML-Library, und ihr seht, meine Antwort hier war jetzt sehr kompakt, ich habe einfach nur gesagt A, also viel kompakter gehen Antworten nicht.
Wir sehen jetzt, er trifft jetzt diese Entscheidung, er dokumentiert die, sowohl im Prozessgedächtnis, als auch dann später in der Architektur.
Auch hier entsteht jetzt ein Langzeitgedächtnis, ich habe jetzt hier kein, aufgrund von der Größe der Anwendung jetzt kein Arc42-Template oder sowas genommen, könnten wir aber natürlich auch daran arbeiten lassen, mit den entsprechenden Instruktionen, wenn wir das wollten, und er sagt, da könnten wir zur Planphase übergehen, was wollen wir denn noch haben, und ihr seht, die Nachricht, die ich geschickt hatte, war einfach nur A, und wir haben diesen Teil, hat es eben synthetisiert, aufgrund der Instructions.
So, ich weiß jetzt auch nicht, ob es jetzt Ziel ist, wirklich die dann funktionsfähige Golang-To-Do-App zu bauen, ich finde es natürlich witzig, aber vielleicht hast du ja auch noch andere Aspekte, die du abdecken möchtest, darum.
Also ich sage mal, ich finde das jetzt sehr spannend, ich habe jetzt gesehen, wie er durch den Workflow geht, was in dem Workflow alles definiert ist, womit er umgehen kann, ich glaube, wir können jetzt relativ zügig durch diesen Prozess durchgehen, dass wir ihm einfach sagen, komm, wieder mach, was du willst, so wie anfangs, aber wir haben ja eben jetzt auch ein paar Vorgaben gemacht.
Mich würde schon interessieren, wie dann das Ergebnis aussieht, aber ich finde das jetzt tatsächlich, ja, diese Idee, ein Workflow mitzugeben und damit das, was du normalerweise iterativ mit ihm erarbeitet hättest, also ihm immer wieder Anweisungen zu geben, werden die Anweisungen über den Workflow quasi abgespult, sie sind im aktuellen Kurzzeitgedächtnis, dadurch hält er sich sehr gut dran und geht in Interaktion mit dir, um eben einige Rückfragen und solche Sachen zu klären, das heißt, du bist weiterhin in der Kontrolle, du bestimmst, was das LLM machen soll.
Ja, genau, das ist auch der wesentliche Teil, weshalb ich denke, dass das jetzt hier vielleicht für das Zielpublikum auch relevant sein kann, weil es eben, ich finde, diese Tools, die sind oft, also gerade sowas wie V0 oder Bold New oder sowas, die haben oft einen ganz üblen Ruf, auch letztens gerade wieder hatte, glaube ich, jemand auf deinen LinkedIn-Post geantwortet und gesagt, das ist für ihn eigentlich nur Spielzeug und ich verstehe diese Ansicht absolut, aber wir geben auch nicht mehr Kontext rein und wenn wir nicht klar äußern können, was wir eigentlich wollen, dann kann auch die Inferenz von den Tools, mit denen wir zusammenarbeiten, nicht besser sein.
Darum müssen wir uns ein bisschen an die eigene Nase fassen und ehrlicherweise, so dem klaren Entwicklungsprozess folgen, ist nicht die Stärke jedes Softwareentwicklers, den ich in meinem Leben getroffen habe und darum hilft mir das Tooling.
Ja, es ist natürlich auch so, wie du es eigentlich gesagt hast, ja, am Anfang sagt man dem System erstmal Requirements und dann die Architektur und so, aber wenn man es immer wieder machen muss, dann nervt das ja immer und so ist das, ja, eigentlich ziemlich cool.
Jetzt gucke ich gerade mal, ist er jetzt bei dir schon fertig?
Ja, also er testet jetzt gerade hier, ich glaube wir können jetzt aber auch aufhören, also ich habe jetzt hier einfach mein kleines CLI.
Okay, er hat es jetzt wirklich als CLI-Tool umgesetzt, das heißt ich habe einzelne Kommandos und nicht auf dem Terminal eine Oberfläche, aber es funktioniert, er hat es geschafft, cool.
Jetzt werfe ich hier einen Blick auf die Workflows, weil oftmals ist es ja so, du hast jetzt gesagt Softwareentwicklung und ja, Greenfield Workflow, aber ich sehe hier noch andere interessante Workflows, du hast ja echt verdammt viele Workflows hier drin, ne?
Verschiedene Workflows
Ja, die sind ja auch alle noch nicht gefeilt, ist mal so zu sagen.
Also worum es mir jetzt mit diesem Tooling erstmal ging, war zu merken, bekomme ich es überhaupt hin ein LLM zu führen und da finde ich es eine total, da ist das Prinzip, bekomme ich ein Langzeitgedächtnis hin, bekomme ich ein Prozessgedächtnis hin, hält sich das Tool dran, übersteht es auch, wenn der Kontext komprimiert wird, wie kann ich dann wieder aufsetzen, das war jetzt vor allem mein Fokus.
Aber du hast recht, es gibt mittlerweile eine ganze Menge andere Workflows, zum Beispiel, was wir bei uns im Unternehmenskontext häufig haben, ist, dass wir Altsysteme haben, deren Dokumentation löchrig ist, ich weiß nicht, das kennt vielleicht auch der eine oder andere Zuschauer.
Nicht alle Dokumentation entspricht den Wünschen, die wir hätten und oft stehen auch noch Template-Elemente drin.
Altsystem-Analyse
Also was ich dann gerne hätte war, zu dieser Altsystem-Methode habe ich überlegt, wie würde denn Klein Oliver daran gehen, so ein Bestandssystem zu analysieren.
Und ich gucke da erstmal eine ganze Menge rum und das habe ich gedacht, das kann ich dir im LNN doch auch sagen.
Du analysierst ein Bestandssystem und hier wird erstmal ein ganz langes Template angelegt, dann steht hier drin, du hast hier ein Langzeitgedächtnis für die Analyse und jetzt, was du alles machen sollst, guck dir an, was du in dem System findest an Schnittstellen.
Und dann gehen wir eben nach C4-Methodik vor, also Context Container Component, also eigentlich nur C3, weil Code-Ebene möchte ich eigentlich gar nicht haben.
Also eigentlich ein C3-Analyse-Workflow, aber das kapiert dann keiner mehr.
Also Kontextanalyse, also wenn ich jetzt mir so ein Bestandssystem nehme und sage, ok, erkunde erstmal das System und danach fokussiere dich auf den Kontext.
Du hast hier so dir schonmal Notizen gemacht aus der Discovery-Phase und jetzt fokussierst du dich nur auf die externen Schnittstellen und Systemgrenzen, was ich so klassisch im C4-System-Kontext habe.
Und so würde dann das System eben abarbeiten und würde ganz methodisch alle externen Schnittstellen erarbeiten und sich dafür Notizen machen und das in dem Langzeitgedächtnis der Architektur festhalten.
Es zeigt ja eigentlich ganz gut, dass dieser Ansatz nicht nur einfach für jetzt Wipe-Coding funktioniert, eben, sondern auch für eine Projektanalyse.
Ich sehe jetzt hier auch noch, dass du ein Workflow für Slides hast.
Das ist ja auch noch faszinierend.
Das heißt, du fängst an, diesen Ansatz jetzt für jede Kommunikation mit dem LM zu nutzen.
Richtig?
Ja, also das CLI für mich ist mein neues Notepad.
Nur, dass ich dann weniger viel tippe.
Oder meine Idee.
Also zum Beispiel, wenn ich eben Folien erstelle für einen Vortrag, dann tippe ich auch einfach los, aber meistens kommt dann nichts Gutes raus.
Dann habe ich gedacht, okay, ich habe jetzt ein Tool an der Hand.
Warum soll ich nicht da auch einem strukturierten Prozess folgen?
Und wenn ich zum Beispiel Folien erstelle, erst mal wieder ein Gedächtnis aufbauen.
Für wen ist denn, also ich möchte ein Brainstorming haben und dabei agiere ich mit dem LLM als Innovationspartner.
Wer ist denn mein Zielpublikum?
Was sind meine Präsentationsziele?
Wie lange dauert das Ganze?
Dann arbeite ich mich zusammen mit dem LLM hier durch.
Erstelle danach eine grobe Struktur.
Mache einen Grobentwurf.
Danach style ich den.
Dann kommen auch visuelle Elemente hinzu.
Man kann eigentlich die meisten seiner Tätigkeiten, wenn man das möchte, so verpacken.
Und als nicht besonders strukturierter Mensch wird man dann eben extrinsisch strukturiert.
Okay, jetzt habe ich diese ganzen Phasenübergänge.
Und ja, Cloud würde ich jetzt zutrauen, dass Cloud einfach sagt, oh ja, ich gehe jetzt in die nächste Phase.
Ich gehe schon wieder in die nächste Phase und ich gehe einfach durch.
Hast du mal über Quality Gates nachgedacht?
Ja, natürlich.
Quality Gates
Also das sind zwei Aspekte.
Das eine ist, dass man wirklich das LLM unterbricht, ganz bewusst.
Das sieht man jetzt hier.
Bei Q ist es so, dass man in dieser Konfiguration des Agenten einstellen kann, welche Tools man erlaubt auszuführen.
Und ich habe schlicht und ergreifend erst mal dieses Tool Proceed to Phase.
Den vertraue ich nicht.
Das wirkt jetzt bei mir in dem QCLI, das gibt es bei Cloud Code, gibt es das genauso analog.
Da kann man sagen, dieses Tool hier, das darf automatisch ausgeführt werden.
Aber das Proceed to Phase bitte nicht.
Denn an diesem Phasenübergang möchte ich ein Review machen.
Das ist der eine Aspekt, also dieser bewusste Interrupt der Session durch schlicht und ergreifend nicht vertrauen.
Und ein zweiter Aspekt ist, dass ich manchmal auch noch ein Perspektivwechsel haben möchte.
Zum Beispiel in dem Wasserfall-Workflow gibt es das.
Da sieht man das.
Review-Prozess
Wenn ich Requirements gemacht habe, dann möchte ich danach ein Review haben.
Bevor dieser Phasenübergang mit einem Quality Gate passiert, kann ich sagen, ich hätte gerne hier ein Review von der Rolle Business Analyst und ein Review von der Rolle UX Expert.
Das sind wieder einfach nur Prompts, die da drin stehen, die dann mit zurückgehen.
Und dann haben die aber eben Zugriff auf den Konversationskontext und machen dann eben ein Review von dem, was passiert ist.
Das heißt, du hast jetzt nicht in dem Tool nochmal Zugriff auf ein LLM drin, das dieses Tool, dieses Quality Gate überprüft, sondern du gibst als Anweisung zurück.
Du nimmst jetzt bitte nochmal eine andere Perspektive ein und machst selbst das Review.
Guck bitte nochmal drüber, hast du alles richtig gerechnet?
So wie man das auch bei den Hausaufgaben macht.
Ja, aber das habt ihr vielleicht auch schon gemerkt, auch das ist wieder alles keine Magie.
Das kann man auch manuell machen.
Man kann manuell sagen, jetzt bin ich an dieser Stelle, zum Beispiel hier nach der Implementierung, guck dir das nochmal aus Performance-Gesichtspunkten an.
Dann kann ich einfach sagen, du, lieber CLI, guck dir bitte noch einmal, also das, was hier als Prompt steht, das kann ich auch einfach tippen.
Aber es ist halt aufwendig und ich muss dran denken.
Und so werde ich kontinuierlich geführt.
Letzten Endes ist aber die Entscheidung, ob ich zur nächsten Phase übergehe oder nicht, ist immer noch meine.
Cool.
Wir sind fast am Ende.
Und jetzt habe ich noch eine ganz freche Frage.
Ich finde es ja total cool, dass da eine Workflow-Visualisierung, zum Beispiel hier in deinem Tool auch drin ist.
Was denkst du, wie viel Prozent von dem Tool hast du selbst programmiert und was hast du geweibcoded?
Merke ich, dass es mir unangenehm ist, das zu sagen?
Ich habe vielleicht drei Zeilen selbst geschrieben.
Wow.
Aber es ist mir peinlich, das zu sagen, weil ich irgendwie das Gefühl habe, es ist nicht richtig.
Es ist nicht ernsthaft.
Aber andererseits, ich selbst sage ja, es ist halt responsible gemacht.
Das Tool habe ich natürlich mit sich selbst entwickelt und ich kann ganz wunderbar nachvollziehen.
Das kann ich einmal tatsächlich zeigen.
Ihr seht es ja auch, wenn ihr den Disresponsible Vibe, wo habe ich den denn?
Den sehe ich jetzt hier gar nicht.
Die Insights.
Wenn ich da Contributors aufrufe.
Ich kann ja hier auch auf GitHub gehen, dann sieht man das direkt.
Ich habe das ja alles mit eingecheckt.
Also ihr könnt das sogar nachvollziehen, weil ich natürlich hier dann die gesamten Entwicklungspläne, also pro Branch, wenn man sich einen Branch anlegt, hier seht ihr zum Beispiel, das war ein Bugfix.
Das war der Fix Reviews Branch.
Mal gucken, wo habe ich denn Reviews hier ergänzt?
Visualize Reviews.
Also im Vibe Verzeichnis sind die ganzen Pläne, die er sich gemacht hat, hier drin.
Und das ist nachvollziehbar, wie ich gearbeitet habe.
Es ist eine andere Art Software zu engineeren, nicht zu programmieren.
Die Programmierung, die hat Claude übernommen.
Aber das Engineering, das ist trotzdem meine Schöpfung.
Also wenn ich so einen Wunsch hätte, da Intellectual Property drauf zu kleben, dann wäre das ganz klar meins.
Das ist meine Schöpfung, aber ich habe es nicht programmiert.
So ähnlich, wie wenn ich bei der IDE so einen Quick Fix anwende, dann macht den auch die IDE.
Habe ich das dann noch programmiert?
Natürlich.
Aber es zeigt ja auch, dass dein Ansatz funktioniert.
Und das finde ich cool.
Ja, Oliver, herzlichen Dank.
Es hat total viel Spaß gemacht, mal hier in die Details von deinem Tool, deinem Web Coding Ansatz reinzugehen.
Und ich bin mir sicher, dass viele unserer Zuhörer und Zuseher, Zuschauer, diesen Ansatz jetzt auch mal ausprobieren werden.
Ich hoffe, dass du ganz viele Pull Requests von den KI Agenten der Zuschauer bekommst und auch noch ganz viele Stärkchen.
Hat Spaß gemacht.
Herzlichen Dank.
Ja, kein Geschehen.
Hat mir auch viel Spaß gemacht.
Ja, und dann…
Hier im Kanal oder über den Ralf, und dann werden wir es mal sehen.
Genau.
Oder über GitHub.
Genau.
Super.
Herzlichen Dank und allen ein schönes Wochenende und viel Spaß beim Web Coden.
Bis dann.
Tschau.
Adieu.