00:00:00Die meisten von euch kennen shadcn bereits als eine der am häufigsten verwendeten UI-Bibliotheken,
00:00:04aber wenn man einen KI-Agenten damit arbeiten lässt,
00:00:06kann das problematisch werden.
00:00:07Wenn ihr einmalige Landing Pages erstellt,
00:00:09werdet ihr keine großen Probleme haben,
00:00:11aber wenn ihr eine neue App entwickelt oder ein neues Feature implementiert,
00:00:14gehen Dinge kaputt und diese brechen dann auch andere Teile der App.
00:00:17Aber das ist nichts Neues – dieses Problem wurde bereits gelöst,
00:00:20und genau so entwickeln Entwickler heutzutage Apps.
00:00:22KI-Agenten testen immer den Code,
00:00:24den sie schreiben,
00:00:24aber diese Agenten werden bei großen Kontexten unzuverlässig.
00:00:27Daher brauchen wir eine Möglichkeit sicherzustellen,
00:00:29dass Agenten die ihnen zugewiesene Arbeit abschließen.
00:00:32Hier kommt das Konzept der agentischen Schleifen ins Spiel,
00:00:34und Anthropic löst dies mit dem RALPH-Loop.
00:00:36Um mein UI-Problem zu lösen,
00:00:38habe ich versucht,
00:00:38den RALPH-Loop zu implementieren,
00:00:40und anfangs ist es komplett fehlgeschlagen.
00:00:42Aber ich habe schnell gelernt,
00:00:43dass es nicht am RALPH-Loop lag,
00:00:44sondern am Prozess,
00:00:45den ich damit implementiert hatte.
00:00:47RALPH ist also eigentlich ein neues Plugin,
00:00:49das von Anthropic selbst veröffentlicht wurde,
00:00:51aber das war nicht ihre ursprüngliche Idee – es basiert auf einer Technik von jemand anderem,
00:00:55und Anthropic hat es implementiert und als Open Source zur Verfügung gestellt.
00:00:58Im Grunde ist RALPH eine Schleife,
00:01:00und wenn ihr Claude Code Hooks kennt,
00:01:01nutzt es diese Stop-Hooks,
00:01:02die ausgeführt werden,
00:01:03wenn Claude aufhört,
00:01:04eine Antwort auszugeben.
00:01:05Sobald es stoppt,
00:01:06wird dem KI-Agenten seine ursprüngliche Prompt-Datei erneut zugeführt,
00:01:09und das ermöglicht es ihm,
00:01:10seine Arbeit iterativ zu verbessern.
00:01:12Jetzt die wichtige Frage: Wann bricht es tatsächlich aus der Schleife aus?
00:01:15Es gibt etwas namens Completion-Promise,
00:01:17das ein beliebiges Wort sein kann,
00:01:18das ihr eingebt.
00:01:19Wenn Claude das Gefühl hat,
00:01:20dass seine Aufgabe abgeschlossen ist,
00:01:22gibt es dieses Versprechen von selbst aus.
00:01:23In diesem Fall ist das Versprechen zum Beispiel das Wort 'complete'.
00:01:26Wenn das Versprechen im Return-Prompt enthalten ist,
00:01:29läuft die Schleife nicht erneut.
00:01:30Solange Claude also kein Versprechen ausgibt,
00:01:32hört es nicht auf.
00:01:33Das stellt sicher,
00:01:34dass Claude nicht einfach aufhört,
00:01:35wann immer es will.
00:01:36Nach der Installation des Plugins habt ihr drei Befehle: den RALPH-Loop-Befehl,
00:01:39einen Abbruch-Befehl und einen Hilfe-Befehl.
00:01:41Im Loop-Befehl müsst ihr den Prompt angeben,
00:01:43der dem Agenten immer wieder zugeführt wird.
00:01:45Manchmal bekommt es eine unmögliche Aufgabe,
00:01:47die es nicht lösen kann,
00:01:48und es könnte in einer Endlosschleife feststecken.
00:01:50Daher ist das Festlegen einer maximalen Iterationsanzahl eine wirklich gute Praxis.
00:01:54Ich werde unten den Link zum Repository hinterlassen,
00:01:56weil dort einige gute Best Practices für die Prompts stehen,
00:01:59die ihr dem RALPH-Loop geben könnt.
00:02:00Aber in diesem Video werde ich nur die besprechen,
00:02:02die mit dem UI-Workflow zu tun haben,
00:02:04den ich euch zeigen werde.
00:02:05Nehmen wir also an,
00:02:06wir wollen zwei Features in dieser App implementieren.
00:02:08Eines ist eine Befehlspalette,
00:02:10bei der wir ein Menü hinzufügen,
00:02:11um durch unsere App zu suchen und andere Befehle auszuführen.
00:02:14Um sicherzustellen,
00:02:15dass dieses neue Feature keine anderen Teile der App kaputt macht,
00:02:17würdet ihr mit den Tests beginnen.
00:02:19Das nennt man testgetriebene Entwicklung.
00:02:21Falls ihr damit nicht vertraut seid,
00:02:22könnt ihr Claude Code bitten,
00:02:24die TDD-Struktur für euch einzurichten,
00:02:25wo es einen End-to-End-Testordner erstellt,
00:02:27einen Screenshot-Ordner,
00:02:28um UI-Probleme zu überprüfen,
00:02:30und auch den entsprechenden Test.
00:02:31Das andere Feature,
00:02:32das wir implementieren werden,
00:02:33ist eine Board-Ansicht in der Datenbank,
00:02:35ähnlich wie Notion es mit ihren Datenbanken ermöglicht.
00:02:37Falls ihr es noch nicht begriffen habt: Testgetriebene Entwicklung ist ein Ansatz,
00:02:41bei dem Tests geschrieben werden,
00:02:42bevor der Code implementiert wird.
00:02:44Aber das bedeutet,
00:02:44dass die anfänglichen Tests immer fehlschlagen werden.
00:02:47Wenn ich also das Befehlspaletten-Feature implementiere,
00:02:49würde ich nicht einfach anfangen,
00:02:51den Code dafür zu schreiben.
00:02:52Stattdessen würde ich zuerst ausführliche Tests dafür schreiben.
00:02:55Dann schreiben wir die minimale Menge an Code,
00:02:57die erforderlich ist,
00:02:58um diese Tests zu bestehen.
00:02:59Sobald das erledigt ist,
00:03:00refaktorieren wir und fügen mehr Funktionalität hinzu,
00:03:02und bei jeder Ergänzung stellen wir sicher,
00:03:04dass die Tests immer noch bestehen.
00:03:06Eine weitere interessante Sache ist,
00:03:07dass diese Tests automatisiert sind und Playwright importiert und für die visuelle Verifizierung verwendet werden kann.
00:03:12Wenn ihr denkt,
00:03:13dass wir das Playwright-MCP nutzen,
00:03:15um dies autonom über den Browser zu verifizieren,
00:03:17liegt ihr falsch.
00:03:17Bei TDD könnt ihr für jedes funktionale Verhalten Screenshots machen.
00:03:20Wenn das funktionale Verhalten zum Beispiel das Hinzufügen einer Karte ist,
00:03:24würde der Screenshot eine Karte zeigen,
00:03:25die zum Board hinzugefügt wurde.
00:03:27Jetzt muss der KI-Agent also nur noch diese Screenshots anschauen und sicherstellen,
00:03:30dass es keine Probleme in der Art und Weise gibt,
00:03:33wie diese shadcn-Komponenten implementiert wurden.
00:03:35Diese Testdateien stellen sicher,
00:03:36dass bei jeder neuen Ergänzung oder während ein Feature entwickelt wird,
00:03:39alle unsere Verhaltensanforderungen erfüllt werden.
00:03:41Aber in unserem Fall wollen wir die Screenshots rein für die UI-Verifizierung verwenden.
00:03:45Aber wenn wir bereits TDD haben,
00:03:47warum brauchen wir dann den RALPH-Loop?
00:03:48Wie ich bereits gesagt habe: Bei größeren Aufgaben,
00:03:51wenn die Kontextfenster fast gefüllt sind,
00:03:52brechen diese Modelle ihre Aufgaben abrupt ab und benötigen ständig menschliche Eingaben.
00:03:56Daher kann ich im Voraus Tests für jede Art von Funktion schreiben,
00:03:59die ich möchte,
00:04:00dann die Schleife verwenden,
00:04:01um ihm zu sagen,
00:04:02was zu tun ist,
00:04:02und es kann autonom arbeiten,
00:04:04indem ich ihm sage,
00:04:05welchem Workflow es folgen soll,
00:04:06und ihm dann die Bedingung gebe,
00:04:07wann es das Versprechen ausgeben kann.
00:04:09Es schließt die Aufgabe ab und verlässt die Schleife,
00:04:11was in diesem Fall ist,
00:04:12wenn es alle 25 einzigartigen Tests besteht.
00:04:14Mit dem RALPH-Slash-Befehl habe ich ihm also einen Prompt gegeben,
00:04:17damit es iterativ das Befehlspaletten-Feature entwickelt.
00:04:20Im Prompt haben wir ihm im Grunde gesagt,
00:04:21das Feature zusammen mit einigen grundlegenden Anforderungen zu implementieren,
00:04:25die nicht wirklich wichtig sind,
00:04:26weil die Anforderungen auch in den Tests zu finden sind.
00:04:29Aber wir haben den gesamten Workflow skizziert.
00:04:31In diesem Workflow sollte es mit dem Ausführen der Tests beginnen.
00:04:34Es weiß,
00:04:34dass die Tests fehlschlagen werden,
00:04:36und danach muss es die Komponenten implementieren,
00:04:38um sie zu bestehen.
00:04:39Das ist also das ganze Ziel.
00:04:40Wenn dies nun eine viel umfassendere Aufgabe wäre,
00:04:42stehen die Chancen gut,
00:04:43dass Claude,
00:04:44wenn das Kontextfenster sich füllt oder Claude verwirrt ist,
00:04:46automatisch aufhört.
00:04:47Es wird niemals das Completion-Promise ausgeben,
00:04:49und da es das Versprechen niemals ausgibt,
00:04:51wird der Prompt erneut zugeführt und es muss von vorne beginnen,
00:04:54was bedeutet,
00:04:54dass es iterativ weiter daran arbeitet.
00:04:56Da dies aber eine kleinere Aufgabe war,
00:04:58konnte es tatsächlich alles in einem Durchgang implementieren,
00:05:01alle Komponenten ausschreiben und alle Tests bestehen lassen.
00:05:03Nachdem die Tests bestanden sind,
00:05:05sagt ihm der Workflow,
00:05:06dass es alle Screenshots für die Befehlspalette überprüfen soll.
00:05:08Das sind Screenshots,
00:05:09die in verschiedenen Phasen aufgenommen werden,
00:05:11um sicherzustellen,
00:05:12dass die UI – egal ob shadcn oder eine andere Komponentenbibliothek,
00:05:15die ihr verwendet – korrekt implementiert ist und dass es keine kleineren Probleme gibt.
00:05:19Danach sollte es die Tests erneut ausführen und sicherstellen,
00:05:22dass sie nach den UI-Änderungen immer noch bestehen.
00:05:24Da alle Tests bestanden wurden und die Screenshots überprüft wurden,
00:05:27gab es das Completion-Promise aus.
00:05:29Hier stoppte die Schleife und lief nicht mehr weiter.
00:05:31Aber es gab ein wirklich großes Problem damit,
00:05:33das mir beim Befehlspaletten-Feature nicht aufgefallen ist,
00:05:35weil es dort sehr wenige Chancen für UI-Fehler gab.
00:05:38Als ich jedoch zur Implementierung der Board-Ansicht überging,
00:05:40stellte ich fest,
00:05:41dass es einen riesigen Fehler im System gab.
00:05:43Ich begann damit,
00:05:44das Board mit demselben Prompt zu implementieren.
00:05:46Die Anforderungen waren natürlich anders,
00:05:48aber der Workflow war ziemlich gleich.
00:05:49Jetzt war ich irgendwie überrascht,
00:05:51als es alle Anforderungen in einem Durchgang abschloss.
00:05:53Versteht mich nicht falsch – es stellte tatsächlich sicher,
00:05:56dass alle Tests bestanden wurden,
00:05:57aber während es das tat,
00:05:58gab es Fälle,
00:05:59in denen die Anzahl der erfolgreichen Tests tatsächlich abnahm,
00:06:02weil es durch die Änderung von etwas etwas anderes kaputt machte.
00:06:04Und deshalb ist TDD tatsächlich wirklich wichtig,
00:06:06wegen dieses rekursiven Testens und der Sicherstellung,
00:06:09dass alles funktioniert.
00:06:10Aber das Hauptproblem war,
00:06:11dass es,
00:06:11nachdem es verifiziert hatte,
00:06:13dass es fertig war,
00:06:14und ich die UI überprüft hatte,
00:06:15die meisten Dinge korrekt implementiert waren,
00:06:17aber es hatte einige UI-Fehler komplett übersehen,
00:06:19wie diesen hier.
00:06:20Ich habe auch die Screenshots überprüft,
00:06:22und die Fehler wurden auch in diesen Screenshots angezeigt.
00:06:24Also fragte ich es,
00:06:25und wir analysierten,
00:06:26was tatsächlich schiefgelaufen war.
00:06:27Das eigentliche Problem war ein Prozessfehler,
00:06:29speziell in Bezug auf die Behebung der UI.
00:06:31Was passiert ist,
00:06:32war,
00:06:32dass es alle Tests bestanden hat,
00:06:34weil es die Testdateien immer wieder ausführen sollte,
00:06:36aber es gab keinen spezifischen Test für die UI außer den Screenshots.
00:06:39Es warf einen Blick auf einige von ihnen und ignorierte sogar einige der UI-Fehler,
00:06:43die es gesehen hatte.
00:06:44Einige Dateien wurden komplett ignoriert.
00:06:46Das Hauptproblem war also,
00:06:47dass es seine Promise-Anweisung zu früh ausgegeben hatte und nicht überprüft hatte,
00:06:50ob die UI tatsächlich behoben war.
00:06:52Wir hatten eine ganze Brainstorming-Sitzung darüber,
00:06:54wie wir das beheben könnten,
00:06:55und ich habe sogar die Best Practices für das Prompt-Schreiben aus dem Repository an Claude Code gegeben.
00:07:00Aber am Ende kamen wir auf einige spezifische Regeln und eine Änderung im Prozess,
00:07:03die sicherstellen würde,
00:07:04dass die UI immer korrekt ist.
00:07:06Jetzt hatte das nichts mit den Tests zu tun,
00:07:08weil sie immer laufen werden.
00:07:09Der Prompt,
00:07:09den wir für die Befehlspalette verwendet haben,
00:07:12ist wirklich hilfreich,
00:07:13wenn das Feature oder die Implementierung sehr groß ist,
00:07:15wo Claude nicht halluziniert,
00:07:16dass es die Aufgabe abgeschlossen hat,
00:07:18sondern aufgrund eines vollen Kontextfensters oder der Komplexität der Aufgabe abrupt aufhört.
00:07:22Claude Code ist jetzt schon wirklich autonom,
00:07:24daran gibt es keinen Zweifel,
00:07:25aber es gibt immer noch Probleme wie dieses,
00:07:27die wir beheben müssen.
00:07:28Also haben wir eine Reihe von Dingen im Haupt-Prompt geändert.
00:07:31Das Erste war das Screenshot-Verifizierungsprotokoll.
00:07:33Wir haben ein einfaches Präfix zu jedem Bild hinzugefügt,
00:07:36das Claude sagte,
00:07:36ob es den Screenshot gelesen hatte oder nicht.
00:07:38Aber als ich das zum ersten Mal implementiert habe,
00:07:41hat es immer noch nicht alle Bilder gelesen.
00:07:43Es würde einige lesen,
00:07:44'verified' darauf schreiben und genau wie zuvor vorzeitig aufhören.
00:07:46Um das zu lösen,
00:07:47haben wir es ermutigt,
00:07:48auf eine andere Weise zu denken.
00:07:50Wir haben ihm gesagt,
00:07:50dass es,
00:07:51nachdem es alle Screenshots umbenannt hat,
00:07:53das Versprechen noch nicht ausgeben sollte,
00:07:55was bedeutet,
00:07:55dass es die Aufgabe nicht als abgeschlossen betrachten sollte,
00:07:58und es sollte die nächste Iteration die Vervollständigung bestätigen lassen.
00:08:01Also sollten mindestens zwei Schleifen laufen.
00:08:03Was in der nächsten Verifizierung passiert,
00:08:05ist,
00:08:06dass Claude überprüft,
00:08:07ob alle Dateien das verified-Präfix haben.
00:08:08Das bedeutete natürlich,
00:08:09dass wir die Tests ändern und die Bildverifizierung von den funktionalen Tests trennen mussten.
00:08:14Die nächste Iteration stellt sicher,
00:08:15dass alle Bilder verifizierte Ergebnisse haben,
00:08:17und falls Claude welche verpasst,
00:08:19schaut es sie sich wieder an und korrigiert die Ausgabe.
00:08:21Mit dieser Änderung wurden die kleinen UI-Fehler,
00:08:23mit denen wir konfrontiert waren,
00:08:25endlich behoben,
00:08:25und es konnte alle diese Features korrekt implementieren.
00:08:28Als es also in die nächste Schleife eintrat,
00:08:30führte es die Tests erneut aus.
00:08:31Da es einige Fehler fand,
00:08:32behob es sie,
00:08:33und weil alle Dateien das Wort 'verified' in sich hatten,
00:08:35führte es einen finalen Test durch.
00:08:37Dieses Mal schloss es seine Aufgabe in zwei Schleifen ab und konnte alle großen UI-Fehler in der App beheben.
00:08:42Lass uns jetzt über Automata sprechen.
00:08:43Nachdem wir Millionen von Menschen beigebracht haben,
00:08:46wie man mit KI baut,
00:08:47haben wir angefangen,
00:08:47diese Workflows selbst zu implementieren.
00:08:49Wir haben entdeckt,
00:08:50dass wir bessere Produkte schneller als je zuvor entwickeln können.
00:08:53Wir helfen dabei,
00:08:54eure Ideen zum Leben zu erwecken,
00:08:55egal ob es Apps oder Websites sind.
00:08:57Vielleicht habt ihr unsere Videos gesehen und gedacht: Ich habe eine großartige Idee,
00:09:00aber ich habe kein Tech-Team,
00:09:02um sie zu bauen.
00:09:02Genau da kommen wir ins Spiel.
00:09:04Stellt euch uns als euren technischen Co-Piloten vor.
00:09:06Wir wenden die gleichen Workflows,
00:09:07die wir Millionen beigebracht haben,
00:09:09direkt auf euer Projekt an und verwandeln Konzepte in echte,
00:09:12funktionierende Lösungen,
00:09:13ohne die Kopfschmerzen durch Einstellung oder Verwaltung eines Dev-Teams.
00:09:16Bereit, eure Idee in die Realität zu beschleunigen?
00:09:18Meldet euch unter hello@automata.dev.
00:09:20Wenn ihr den Kanal unterstützen und uns helfen möchtet,
00:09:22weiterhin Videos wie dieses zu machen,
00:09:24könnt ihr das mit dem Super-Thanks-Button unten tun.
00:09:26Wie immer,
00:09:27danke fürs Zuschauen,
00:09:27und wir sehen uns im nächsten Video..