Beim Coding mit KI Agenten kann man sich wahnsinnig verkünsteln
nur mit geschickten Prompts, einer Vorauswahl an cleveren MCP
Tools und ellenlangen Custom Instructions noch mehr
Performance rauskitzeln. Oder aber man macht es mit dem
Holzhammer und prügelt das KI Modell förmlich zu einem, dann
aber auch doch erstaunlich gutem Ergebnis.
Die sogenannte Ralph Wiggam Methode ist die dümmste
anzunehmende aber trotzdem. Erstaunlich erfolgreiche
Vorgehensweise, um aus KI Agenten noch mehr rauszuholen.
Frei benannt nach dem Simpsons Charakter.
Wir schauen uns heute an, was eigentlich dahinter steckt.
Und damit Hallo und herzlich Willkommen zu Folge 149 des To
do Developer Podcast und wie immer hört ihr hier mich malte
Lantin und Robin, Manuel Thiel Robin Manuel ist Director AI und
Claude beim E Commerce Software Unternehmen Jtl.
Ich bin Solutions Engineer bei github, den Podcast machen wir
natürlich privat und in unserer Freizeit, aber wie immer findet
ihr auch in dieser Folge ganz viel Erfahrung aus dem echten
Leben, aus unserem Job und natürlich aus dem Austausch mit
euch in der kommenden. Community und wir diskutieren
heute die Ralf Methode. Aber bevor wir auf das Thema
eingehen, natürlich erstmal noch den üblichen Dank an euch in der
Community. Genau.
Wir haben wieder Kaffee ausgegeben bekommen.
Vielen Lieben Dank dafür. Der Liebe Martin hat uns einen
Kaffee ausgegeben, ein anderer Martin hat uns 2 Kaffee
ausgegeben und der Dominik hat auch 2 Kaffee ausgegeben, ganz
herzlichen Dank, damit ist das Koffein.
Level wieder aufgeladen und wir können mit voller Energie in die
Folge starten. Ganz, ganz herzlichen Dank.
Und heute beschäftigen wir uns mit einem Thema, was jetzt
gerade über die letzten Monate häufiger mal irgendwo auf Social
Media in Blogs auftauchte und eigentlich spannend war, weil
man dann immer das Gefühl hatte, KI wird immer komplexer.
Aber plötzlich kam mit der Ralf Methode etwas total simples.
Und das Ganze adressiert eigentlich dieses Problem, was
wir bei der Nutzung von Coding Agenten immer häufiger sehen.
Dass der Agent sagt, Ich habe die Aufgabe erfolgreich erledigt
und wenn man dann ins Detail geht.
Merkt man so richtig fertig ist das Ganze nicht und dann startet
man mit einem weiteren prompt neu und genau das wollen wir
jetzt adressieren. Genau.
Und jetzt gibt es ein paar Leute, die gesagt haben, weißt
du was, ich habe eigentlich gar keine Lust, dem Agenten immer
wieder quasi schon so Mantra mäßig zu sagen, ja, bist du
überprüft bitte mal deine Arbeit, bist du auch wirklich
fertig und die haben einfach angefangen, die KI Coding
Agenten, sogenannte Ralf Loop. Zu stecken also quasi eine
erzwungene Weitermacherei und dazu so ein paar harte, prüfbare
Kriterien. Und haben jetzt quasi was, wieso
eine Autor loop und so eine inner Loop gebaut.
Also es gibt einen Coding Agenten der läuft los und wenn
der fertig ist wird er einfach wieder neu gestartet und sagt ja
aber guck mal ob du dich noch mal irgendwie ein bisschen was
was machen solltest. Und wenn der dann wieder fertig
ist wird wieder kurz automatisiert gecheckt und dann
wird ach lauf doch einfach noch mal eine Runde los und.
Und so baut man eigentlich eine Endlosschleife, in der man immer
wieder einem Co Agenten dieselbe Aufgabe gibt und hofft dann,
dass sich dadurch dieses Problem löst.
Dass Dki sagt, dass sie fertig ist, aber vielleicht noch gar
nicht wirklich fertig ist. Ja, und am Ende ist die Idee,
dass wir jetzt nicht immer wieder prompt müssen, sondern
das Ganze so ein bisschen auf Autopilot läuft und das Ganze so
ein bisschen angelehnt. Aber.
An ein etwas dümmliches Verhalten, bei dem man einfach
immer wieder über eine Aufgabe drüber geht, bis es dann
irgendwann mal gut ist und deswegen auch diese Referenz auf
diesen Charakter. Ralph Wiggam was du vorhin
erwähnt hattest. Und heute hören wir, natürlich
gehen wir natürlich ein bisschen tiefer in das Thema rein und
schauen uns an, wann diese Methode sinnvoll ist und wann
sie vielleicht nicht zum Ziel führt.
Genau um das ein bisschen besser zu verstehen.
Lass uns doch mal reinschauen, was ist denn eigentlich das
Grundproblem, warum scheitern die KI Agenten denn eigentlich
und was sind die pain Points, die Ralf damit so aufgreift?
Da muss man sagen, es gibt eigentlich ein Problem in den
großen bestehenden KI Modellen die diese Agenten unter der
Haube nutzen und. Das nennt man Self Assessment
Failure. Das heißt, dass das Lnm einfach
glaubt, dass es fertig ist, obwohl noch gar nichts stimmt,
dass sie nicht gut in der Lage sind, ihre eigene Arbeit zu
überprüfen und selbst wenn sie es können, dann geben sie
manchmal einfach zu schnell auf, dann selbst, wenn man gesagt
hat, Pass auf, du musst so lange Code generieren, bis alle Unit
Tests grün sind, dann kann es einfach auch manchmal passieren,
dass das Ding trotzdem aufhört und sagt, ja ich.
Sind es hier nicht grün, aber ich glaube, ich komme auch
irgendwie nicht mehr weiter. Und einer der Gründe, warum das
passiert, ist sogenannter Kontext, rot oder Kontext
blowde, also dass der Kontext so ein bisschen verrottet, indem er
immer länger wird, denn je länger so eine Coding Session
ist, je mehr der quasi Chat History habe ich ja auch, je
mehr Dinge habe ich, die in dem Kontext liegen, die den Agenten
ablenken können. Und gerade wenn, zumindest wenn
irgendwann mal das Kontext Windows voll ist und diese Code
Agenten anfangen müssen, auch Dinge zusammenzufassen, dann
habe ich oft dramatisch schlechtere Qualität und es wird
Müll produziert und ich habe Fehler im Ablauf und deswegen
haben wir jetzt mal hingegangen und gesagt, Pass auf, solange
wir das nicht lösen können, können wir ja mal versuchen
einfach ab einer gewissen Zeit zu sagen, so wenn du jetzt
fertig bist, schmeiße ich den ganzen Kontext weg und.
Nun starte ich es einfach noch mal neu und sage okay guck mal,
tu mal so, als würdest du jetzt das allererste Mal von diesem
prompt hören. Der Code, den du in der letzten
Literation geschrieben hast, der bleibt aber schon da und so
hofft man dann einfach, dass man, wenn man dem gleichen
Agenten das gleiche Problem hundertmal in Folge gibt,
zumindest dieses diesen Self Assessment ferion diesen Kontext
rot entgegenwirken kann. Ich meine, du hast jetzt schon
ganz viele Begriffe verwendet, die vielleicht gar nicht allen,
die hier zuhören, vertraut sind. Vielleicht gehen wir noch mal
ganz schnell. Über diese Begriffe drüber.
Wir reden jetzt hier über Coding Agenten und wir haben in der
Vergangenheit über zahlreiche gesprochen, aber primär reden
wir über solche, die dann sich auch über die Cii nutzen lassen.
Wir haben hier über Germany Cloud Code, Get up Co Pilot
gesprochen und so ein Agent läuft quasi auch schon in einer
Schleife, weil wir haben ja ein Large Language Model dahinter
und dieses Large Language Model wird immer wieder angefragt mit
neuen Informationen generiert, neue Informationen, zum Beispiel
Quelltext und fügt diesen dann entsprechend.
Brechend ein und am Ende geht das Light Language Model hin und
versucht selber zu entscheiden, wie du gerade gesagt hattest,
bin ich fertig und dann dir zu sagen okay ich habe die Aufgabe
erledigt und du kannst mir jetzt eine neue Aufgabe geben und alle
diese Informationen, also mein prompt und natürlich meinen
ganzen Code und alles was ich an Instructions gebaut habe, das
geht in dieses sogenannte context Window rein und wie du
gesagt hattest ich. In dieser Schleife wird ja die
Information immer weiter aufgebläht, weil alles, was in
diesem Loop schon passiert ist, in der Vergangenheit und gerade
wenn du dann noch mal einen Follow machst, muss ja dann in
dieses Kontextfenster auch mit rein.
Und natürlich werden diese Kontextfenster bei den modernen
Large Language Models immer größer.
Aber das ändert nichts da dran, dass umso mehr Informationen ich
da reinwerfe, umso ungenauer das wird.
Und tatsächlich, wie du gesagt hast, wenn diese dann irgendwann
sogar komprimiert werden müssen, dann gehen einfach Informationen
verloren, das nur noch als Kontext für diejenigen, die
jetzt noch nicht so lange zuhören.
Ich glaube, wir können auch nicht annehmen, dass alle.
Schon seit Jahren dabei sind und alle unsere Folgen zu diesen Ki
Themen gehört haben. Deswegen wollte ich es einmal
noch schnell erläutern, aber jetzt lass uns dann tatsächlich
noch mal ins Detail reingehen, wie setze ich das ganze jetzt
mit der Ralf Methode auf? Genau.
Gute Ergänzung, eine Sache nur noch, wenn der Malte jetzt hier
von der Schleife spricht, die immer voll und im Kontext der
immer voller wird in dieser Schleife, dann sprechen wir da
natürlich von der eigentlichen Agent Loop, also von dem, was
der Agent schon ohnehin macht und.
Und jetzt ist diese Ralf Methode eigentlich hingegangen und setzt
dann noch mal eine Schleife drumherum.
Ich glaube, das muss man noch mal differenzieren, also man der
Agent selber, der hat ja heutzutage schon nicht mehr nur
noch einen Input und einen Output, sondern macht das ein
bisschen mit sich selber aus und in dieser Schleife bläht sich
der Kontext auf und die Ralf Methode ist jetzt quasi noch mal
eine Endlosschleife da drumherum, das heißt, wenn der
Agent sagt, Ich bin fertig, der einfach wieder von vorne
gestartet wird. Dann.
Dann lass uns mal kurz in diesen Wahlflug einsteigen und ich
glaube, es ist ganz gut so ein bisschen so die Geschichte
dahinter kennenzulernen. Du hast ein bisschen
recherchiert, wo kommt das ganze ursprünglich her?
Ja, ist ganz lustig. Also eigentlich in einem in
einem Rahmen von einem YC Agent Hackathon entstanden, also YCSY
Combinator, der bekannte Tech Investor aus den USA, die machen
immer wieder so Hackathons und da.
Haben Entwickler ausprobiert, einfach so einen KI Coding
Agenten in der Endlosschleife laufen zu lassen, um größere
Aufgaben autonom zu erledigen. Und dabei haben Sie Cloud Code
benutzt und eben so eine Bashloop drumherum geschrieben,
damit die KI wieder immer wieder dieselben Aufgaben bekam und
immer wieder weiter an dem Code arbeiten konnte bis alles
erledigt war und das haben sie eigentlich gemacht um das so im
Hintergrund laufen zu lassen und ihre eigene Produktivität zu
steigern und diese ja doch eher ungewöhnliche Hackathon
Experiment Idee. Hat dann dazu geführt, dass
mehrere Positories über Nacht automatisch portiert wurden,
also von einer Programmiersprache in die andere
bearbeitet wurden und die sind dann am nächsten Morgen wieder
zurückgekommen und alles war fertig und das Experiment ist
quasi so ein bisschen aus Zufall geglückt und dieses Muster des
Wiederholenden Ki codings wurde dann ein bisschen später populär
und. Weiß ich gar nicht genau, wo es
herkommt, aber eben als die Ralf Methode nach diesem Simpsons
Charakter Ralf Viggam benannt. Das bedeutet also, die Idee war
von vornherein, diesen Agent inner Loop durch einen Outer
Loop quasi zu ergänzen und damit dann auch sicherzustellen, dass
nicht mehr der Agent selber entscheidet, ob die Aufgabe
erledigt ist, sondern dass es klar verifizierbare
Erfolgskriterien gibt. Das heißt, ich habe jetzt nicht
einen relativen Wagen prompt wie baue Authentication.
In meine Anwendung ein an den Coding Agenten übergeben,
sondern ich habe eine genaue Beschreibung der Aufgabe plus
ganz klare Erfolgskriterien definiert, die in diesem
Autaloop validiert werden. Das heißt, in diesem Autaloop
wird zum Beispiel validiert, dass alle Testcases grün sind
und diese Testcases habe ich vorab.
Geschrieben, ich habe sie vorab definiert, damit ist es ganz
klar verifizierbar, dass die Aufgabe wirklich erledigt wurde
und der Coding Agent entscheidet nicht selber.
Authentification habe ich jetzt eingebaut, damit bin ich fertig,
sondern es ist ganz klar prüfbar und wenn diese Prüfung
fehlschlägt, dann geht es einfach noch mal von vorne los
und das Ganze wird noch mal bearbeitet.
Genau das läuft dann über sogenannte Stop Hooks.
Also wenn ich so wie Cloud Code nehme, da gibt es wenn wenn das
Modell sagt ich bin fertig, dann kann man sich da.
Quasi drauf dieses Event abonnieren und das genau macht
diese Auto loop, die sagt okay, dass sie das Modell sagt Ich bin
fertig, ich überprüfe jetzt aber auch mit einem Skript, was ich
vielleicht noch dabei gelegt habe, ob das Modell wirklich
fertig ist. Also ich nehme diese
Verantwortung von dem Modell weg, mir ist total egal, ob das
Modell jetzt entscheidet fertig zu sein, das zählt gar nicht, es
wird sofort wieder neu gestartet, wenn das System nicht
entschieden hat, dass es fertig ist als wenn diese Auto loop das
nicht entschieden hat. Da kann man natürlich noch n
Paar so Sicherheitsmechanismen drumherum bauen.
Also es gibt es gibt schon so die ersten jetzt wirklich
fertigen Ralf Coding Plugins, die haben dann auch so Sachen
wie Max. Maximale Iterationen da
eingebaut, dass man da wieso eine Kostenexplosion auch
vermeiden kann. Aber die Idee ist eigentlich
immer die Gleiche. Ich lege einmal fest, wie das
System überprüfen kann, ob ob die Aufgabe erfüllt ist und dann
rennt das Ding einfach, entscheidet die Autalob
eigentlich wie oft die KI auf die gleiche Aufgabe losgelassen
wird? Ja, und die Idee, warum das
Ganze dann am Ende auch so effizient ist oder tatsächlich
funktioniert, ist. Dass der Kontext immer wieder
frisch ist, das bedeutet, ich starte immer wieder eine neue
Agent Session und habe dementsprechend keinen Kontext
blowde oder eine entsprechende Komprimierung der Informationen,
sondern tatsächlich kommt immer wieder ein ganz frischer Coding
Agent mit der gleichen Aufgabe. Schaut auf den aktuellen Stand
des Quelltextes und nimmt dann Überarbeitung vor und das Ganze
läuft wie gesagt in dieser Schleife bis die Aufgabe.
Neutral, objektiv beurteilt, erledigt ist.
Das heißt, die Wahrheit oder die Validierung des Zustandes kommt
jetzt nicht aus dem Large Language Model, sondern ist halt
ganz klar auf Basis meines Repositories auf den Dateien
basierend und dementsprechend können wir damit die Realität
abprüfen. Das heißt, wir sehen tatsächlich
was. Sagen meine Tests.
Was sagen die Logs, welche Dateien wurden erstellt und auf
Basis dieser nicht veränderbaren Wahrheit quasi entscheiden wir,
wann unser Outer Loop stoppen muss, das.
Ist natürlich trotzdem nicht jeder einzelne Run von dem
Agenten. Jeder einzelne Inner Loop
komplett wieder von vorne oder gar nicht einzigartig?
Ich kann dem Modell natürlich sagen, dass es, wenn es fertig
ist, eine Zusammenfassung von den letzten Runs oder von allem,
was es gemacht hat in so einer temporären Textdatei ablegen
kann, die dann die nächste Iteration wieder aufgreifen
kann. Das heißt, das kann ich zum
Beispiel einfach in den Custom Instructions hinzufügen, da kann
ich so eine to do Liste sagen, das einfach pflegen soll zum
Beispiel, und die wird abgehakt und so was, dass die nächste
Iteration nicht natürlich nicht diesen ganzen, die ganze
Historie im Kontext hat, aber durchaus mal so eine
Zusammenfassung, was denn eigentlich in der vorherigen
Iteration passiert ist. Und so läuft das dann auch
quasi. Also so der typische Ablauf
eigentlich von so einem Drive Development ist.
Man legt vorher einfach einmal einen Plan an von dem was man
machen will, den legt man ins Repository, zum Beispiel als
Makler und Datei. Idealerweise macht man das
direkt mit so einem Specdriven Development Ansatz, da haben
wir. Auch mal in Folge 137 drüber
gesprochen. Das heißt, man nimmt sich
wirklich ein bisschen Zeit, eine gute Spezifizierung zu schreiben
und das ist ganz wichtig, weil ich lasse das Ding ja vielleicht
sogar über Stunden idealerweise so laufen, dass es dann keinen
extra Input mehr von einem Menschen braucht, weil ich will
in der Zeit was anderes machen oder es läuft über Nacht oder
sowas, das heißt, es lohnt sich auf jeden Fall die vor die
Aufgabe ordentlich auszuspezifizieren Spectrive
Development kann dabei einmal ein bisschen helfen, auch
kritische Rückfragen zu stellen. Ja, und dann geht es eben los.
Man sagt dem Agenten, nimm dir genau eine Task und
Implementiere das so minimal wie es geht und führe Tests aus und
den Linter und guckt, dass das Ding baut und wenn du
erfolgreich bis machen komm mit und dann ist das Ding meistens
immer fertig und dann startet eigentlich schon die nächste
Iteration, die sich das dann anschaut und überlegt okay
vielleicht ist der Agent hier noch nicht fertig, ich gebe das
jetzt wieder rein und so geht es Iteration um Iteration bis ich
entweder wirklich fertig bin oder?
Oder das Limit erreicht ist. Wie oft ich da eigentlich drüber
iterieren möchte. Am Ende ist es so, als würde ich
dir eine Aufgabe geben und sagen, deine Meinung
interessiert mich nicht. Es müssen folgende neutrale
Kriterien erfüllt sein, erst dann bist du fertig.
Das bedeutet, wenn du behauptest fertig zu sein und meine
Evaluationskriterien fehlschlagen, dann setzt du dich
einfach noch mal dran und arbeitest noch mal drüber das
können. Test Cases sein, die vorher
geschrieben haben. Das können aber auch andere
Kriterien sein. Ich kann dir natürlich auch eine
Aufgabe geben, du musst mindestens so und so viel Tests
geschrieben haben und die müssen alle erfolgreich sein, aber es
kann auch was völlig anderes sein, das heißt ich kann
natürlich auch andere Evaluationskriterien da
ansetzen, Tests sind jetzt hier nur ein.
Beispiel, was häufig verwendet wird.
Letzten Endes kann ich alles, was ich wirklich neutral
auswerten kann, dort als Abbruchkriterium verwenden.
Jetzt hast du dir Ralf ja schon mal so ein bisschen angeguckt,
dann auch so ein bisschen in die Community reingehorcht, wo das
gut funktioniert und wo das nicht gut funktioniert.
Hast du da irgendwie ein paar Beispiele, so für uns, wo du
sagst, das ist was, da kann man Ralf gut für einsetzen oder
vielleicht gibt es auch irgendwie andere Sachen wo du
sagst, dafür ist es irgendwie gar nichts da, weil ich muss
zugeben, ich habe jetzt auch so ein bisschen was darüber gelesen
in der Vorbereitung. Ich habe es aber noch nicht
selber ausprobiert und du hattest das Thema ja mitgebracht
und gesagt, Ey, das ist eigentlich erstaunlich gut, dass
das funktioniert. Was würdest du sagen, wofür ist
es besonders gut geeignet und wofür vielleicht auch irgendwie
gar nicht? Ja, wir hatten es ja gerade
quasi schon gesagt. Überall wo du eine klare so
Definition of Done hast. Das können zum Beispiel Bugfixes
sein, wenn du. Regression Tests hast die
Fehlschlagen kannst du sagen, Fixt das und dann weißt du der
Test ist am Ende grün oder ich habe jetzt irgendwie einen
Linter der bestimmte Kriterien vorgibt, die erfüllt sein müssen
und solange dieser Linter fehlschlägt oder bestimmte
Warnings ausgibt, muss ich entsprechend das ganze
überarbeiten. Es können auch.
CI getriebene Definition von dann sein.
Das heißt ich kann das auch irgendwo in meiner CI Pipeline
laufen lassen um bestimmte Dinge sicherzustellen, dass das.
Das entsprechend erfolgreich erledigt ist, weil am Ende kann
ich natürlich mit solchen KI Coding Agenten auf der Command
Line auch andere Dinge tun. Wir haben jetzt immer das
Beispiel so der Softwareentwicklung wo ich Code
schreibe verwendet, aber ich kann natürlich auch solche
Coding Agenten verwenden um zum Beispiel Dokumentation zu
ergänzen, habe ich letzten ganz spannenden Use Case gesehen und
da kannst du natürlich auch sagen okay du bist erst fertig
wenn es zu allen neuen Features die jetzt implementiert wurden
entsprechende Dokumentationsdatei gibt und die
einen bestimmten. Umfang hat und folgende Themen
abdeckt. Und das ist deine Definition of
done, also überall wo du sowas klar evaluieren kannst und in
der Regel habe ich dann irgendwelche statischen Tools
hier laufen, das kann irgendwie ein Build tool sein, das
kanntest Framework sein, das kann Linda sein, überall wo ich
halt am Ende ja oder Nein zurückbekomme.
Okay also gute Use Case würde ich dann sagen.
Sind eigentlich so kleine Bugfixes oder mechanische
Refactorings oder ich soll irgendwelche Backend Endpunkte.
Punkte ausspezifizieren oder implementieren also sozusagen
schon auch eher kleine Tasks, weil das klingt jetzt ja erstmal
so, als wäre es natürlich für alles nicht geeignet, wo ich
auch viel menschlichen Input natürlich haben will oder wo ich
mehrere Versionen von irgendwas erstellt, wenn ich sage ey,
machen wir mal 2 Vorschläge wie der Button aussehen könnte,
finde die besten User Experience von irgendwie sowas.
Oder so migriere mir mal das komplette Projekt jetzt
irgendwie von der einen Cloud in die andere rüber oder sowas, wo
ich ja vielleicht auch nur wirklich Rückfragen, auch dann
auf dem Weg irgendwie auftauchen.
Das sind ja wahrscheinlich so Sachen, die dann eher ungeeignet
sind, oder? Ja oder auch wo ich dann
tatsächlich im Entwicklungsprozess dann
irgendwie das Feedback brauche, weil ich zum Beispiel ein
Debugging mache und dann irgendwie auch eine.
Fehlermeldung Zurückbekomme, die ich interpretieren muss oder
wenn ich irgendwelche Tests durchlaufen lasse, die irgendwie
flakey sind, weil du bestimmte nichtdeterministische Faktoren
da drin hast, dann kann es natürlich sein, dass ich die
Implementierung erfolgreich abgeschlossen habe, aber
trotzdem schlägt ab und zu mal ein Testfehl.
Also bei solchen Dingen funktioniert das nicht.
Es müssen aber nicht unbedingt nur kleinere Dinge sein.
Gerade das, was du als Ursprungsstory gerade
mitgebracht hat, es war ja durchaus etwas Größeres, wo sie
gesagt haben, wir portieren hier etwas von einer Sprache in eine
andere, aber da kannst du natürlich auch ganz klar sagen,
okay welche Features müssen vorhanden sein, welche Tests
müssen erfolgreich durchlaufen, damit diese Portierung
vollständig und korrekt ist. Also da habe ich auch eine ganz
klare Art und Weise, wie ich das Ganze checken kann und was.
Genau so haben Sie es damals gemacht.
Das heißt, es muss jetzt nicht unbedingt etwas Kleines sein,
sondern es kann auch etwas Größeres sein.
Du musst halt immer nur sicherstellen können, dass du
objektiv beurteilen kannst, ob das Ganze erfolgreich war.
Genau das heißt aber nicht, dass ich da jetzt nicht trotzdem
irgendwie menschlich noch mal ein Feedback geben kann.
Also ich kann trotzdem so einen human in The Loop Modus auch
beim Ralf Code natürlich haben, erhoffe mir davon aber
natürlich, dass der deutlich seltener auftritt, in dem zum
Beispiel a ich jetzt erstmal nicht überprüfen muss, ob die
Loop fertig ist und wieder neu starten muss.
Aber trotzdem muss ich ja auch nicht im Yolo Modus, dem alle
Tool Calls erlauben und kann er trotzdem auch in dieser Look
einen Agenten starten, der sich ab und zu Feedback von Menschen
einholt. Das geht natürlich dann
trotzdem, es gibt aber auch so diese afk Methode wo ich sage
okay ich möchte damit gar nichts zu tun haben, ich lege mich
vielleicht sogar schlafen und lass das Ding wirklich im Batch
Mode irgendwas abarbeiten und sage dann auch ganz klar beim
starten ich möchte, dass du dich nicht fragst ob du irgendwelche
Dinge tun darfst. Ich gebe dir eine ganz klare
Liste von vielleicht auch MCP Tools die du aufrufen darfst
und. Und das bietet sich natürlich
auch nur an, wenn die Kriterien halbwegs stabil sind.
Also je besser diese diese diese Testumgebung, die malte Rad
schon so viel beschrieben hat, je besser die ist, desto eher
kann ich natürlich in diese afk Methode reingehen, aber es ist
natürlich auch eine, hat natürlich auch irgendwo seine
Grenzen, also ist natürlich auch eine sehr stumpfe Art und Weise.
An so einen Ansatz ranzugehen, ist also jetzt nicht so, wie
dieses Cursor. Beispiel, was wir in der letzten
News Folge hatten, wo Cursor ja mit ganz vielen verschiedenen
Agenten, die sich gegenseitig orchestrieren, so einen ganz
neuen Browser gebaut haben, ist also auch nicht immer die
Lösung, es gibt nur eben gesagt, für bestimmte Ansätze kann man
einfach sagen, weißt du was? Bevor ich mir jetzt hier im
Detail angucke, warum die KI jetzt an dem ein Ding nicht
weiterkommt, lege ich die einfach mal in so eine Ralf Flup
rein und deswegen macht es ja vielleicht Sinn, dass wir uns
mal im Vergleich angucken, was gibt es denn eigentlich so für
Ansätze? Noch mal ein bisschen also
bestimmte Coding Agenten in einer bestimmten Art und Weise
aufzurufen. Und ja, wie differenzieren die
sich denn eigentlich zu Ralf als Referenzpunkt?
Ja, da haben wir einmal diese React Methode, da ist so ein
bisschen so das klassische wie diese.
Coding Agenten arbeiten, das heißt, Es gibt am Anfang so eine
Thought oder reasoning Phase, dann werden die Aufgaben
umgesetzt, dann wird das Ergebnis beobachtet und dann
wird eine Entscheidung getroffen, ob das Ganze
erfolgreich war und. Und da ist natürlich das ganze
relativ chatty bei Ralf natürlich durch diese klaren
Kriterien nicht. Und ich habe natürlich hier auch
durch den Neustart pro Iteration einen sehr aufgeräumten Kontext.
Bei explorativeren Aufgaben, wie du vorhin auch schon sagtest,
ist vielleicht so ein klassischer Ansatz wie dieses
React sinnvoller, aber wenn ich tatsächlich nur etwas ausführen
und am Ende validieren muss, ob das Ganze erfolgreich war, dann
funktioniert natürlich diese Drive Methode sehr gut.
Ja, was auch jetzt, gerade im Moment ja viele machen, ist so
erstmal planen und dann ausführen, das ist auch das, wo
ich gerade eigentlich so am meisten Spaß mit habe, weil ich
auch finde, dass extrem gut funktioniert.
Das geht so ein bisschen, diesen diesen specdriven Ansatz, den
wir auch vor ein paar folgen mal hatten.
Das heißt, du baust wirklich erst mit der KI einen Plan, der
wird dann mehr oder weniger eingefroren, und dann hat die KI
diesen Plan abzuarbeiten. Bei Ralf kannst du jetzt
natürlich das trotzdem ein bisschen kombinieren, du kannst
ja trotzdem sagen, dass dieser Plan in diesem Repo liegt und
dann iteriert halt irgendwie. Ralf über diesen Plan rüber, das
ist gar nicht so weit weg. Wenn ich natürlich jetzt sage,
ich nehme mir extrem viel Arbeit, schon in diesen Plan
vorher rein und schreibe da wirklich extrem viel runter und
dann würde ich mir noch mal angucken, ob ich dann überhaupt
Ralf brauche, weil dann habe ich mir vorher schon wirklich ganz
genaue Arbeit gemacht, dem Modell auch ganz genau zu sagen,
wann es fertig ist. Und davon würde ich mir jetzt
auch erhoffen, dass es seltener zu diesem Stand kommt, wo das
Modell einfach aufhört oder aufgibt dann.
Das heißt, bei Ralf würde ich eher sagen, das nehme ich an,
wenn ich eben nicht die Zeit habe, wirklich einen ultra
ausführlichen Plan zu schreiben, sondern er sagt Ja, Pass auf,
hier und da sind ein paar technische Kriterien, die ich
habe. Jetzt iterierst du da einfach
ganz stumm solange drüber, bis die da sind.
Und dann kann man das ja noch in den Kontext setzen zu diesen
Orchestration Frameworks. Du hattest es gerade erwähnt am
Beispiel von Cursor, aber wir hatten ja in einer der letzten
News folgen auch dieses Gas Town Projekt erwähnt und das ist
quasi eine. Paradisierung oder
Orchestrierung von ganz vielen dieser Agenten, die Stumpf eine
Aufgabe abarbeiten. Und dementsprechend würde ich
das jetzt nicht als entweder oder sehen, sondern die Ralf
Methode hat quasi diesen Loop, der durchläuft und am Ende habe
ich einen Orchestrater, der dann.
Einzelnen dieser Agenten jeweils Aufgaben gibt, die diese in
diesem Loop abarbeiten. Und dazu gehört natürlich auch
irgendwie ein Task und State Management.
Da gibt es Open Source Projekte wie zum Beispiel Bets, was auch
bei Gas Town Anwendung findet, wo halt so in einer Datenbank
der aktuelle Zustand des Projektes und die Aufgaben
gehalten werden auf die dann letzten Endes diese
verschiedenen Agenten zugreifen können.
Für vieles reicht diese reif Methode, weil ich ja häufig gar
nicht so ganz große, sehr komplexe Aufgaben habe.
Aber wenn ich ein sehr komplexes Projekt habe mit ganz vielen
verschiedenen Aufgaben, die auch unabhängig voneinander sind und
wo verschiedene Agenten dann auch parallel arbeiten an
unterschiedlichen Aufgaben, brauche ich am Ende so einen
Orchestraitor, der das Ganze entsprechend komplex macht, aber
mir dann auch die Möglichkeit gibt, das Ganze zu skalieren,
weil am Ende ist natürlich diese gerne.
Erst Methode, irgendwie gefühlt Single Threaddit und ich gebe
eine Aufgabe und weiß wann diese erledigt ist.
Aber sobald ich halt eine große Anzahl von Aufgaben habe und
diese parallelisieren möchte, brauche ich dann auch ein
entsprechendes Orchestrater Framework.
Ja, wenn ihr jetzt Lust habt, auch mal irgendwie Ralf
auszuprobieren, dann lasst doch mal gucken, wie man das jetzt
irgendwie mit minimalstem Aufwand mal irgendwie machen
kann, weil die Ergebnisse sind schon irgendwie ganz lustig und
ist schon auch irgendwie beeindruckend, wenn man das auf
der eigenen Maschine sieht. Und das kann man eigentlich
relativ leicht ausprobieren, wenn man irgendwie einen CLI
getriebenen Coding Agenten hat wie Cloud, wie Kodex oder
Germany CLI oder Github CLI. Was auch immer.
Da kann ich nämlich einfach mal wirklich hingehen und auf meine
meine Kommandozeile aufbauen, wirklich einfach eine while
Schleife bauen, also wirklich while gar nichts, also eine
Endlosschleife und dann hole ich mir einfach irgendwie meinen
prompt den ich in Textdatei geschrieben habe und Pipe den in
meinen Coding Agenten rein, das ist jetzt so die allereinfachste
Geschichte, da muss ich dann natürlich irgendwann auch mal
abbrechen und. Jetzt gibt es aber auch schon
die ersten Coding Agenten, die da wirklich ein Plugin für
haben. Es gibt zum Beispiel für Claude
God schon einen Ralf Plugin, verlinken wir auch mal irgendwie
in den Shownotes und da kann ich dann natürlich auch schon so ein
bisschen detaillierter Sachen mitgeben.
Also ich kann damit, ich könnte wirklich genau sagen, Pass
aufrufe dieses Plugin auf und dann kann ich über Parameter
mitgeben in welchem Zugriffsrechte Modus das Ding
eigentlich laufen soll, also dass ich zum Beispiel Änderungen
an Dateien automatisch akzeptiere.
Änderungen oder Aufführungen von noch nicht approvten MCP Tools,
aber vielleicht selber noch mal entscheiden möchte und dann kann
ich ihm eine Textdatei mitgeben, indem er den Fortschritt quasi
tracken kann. Das ist das, was wir vorhin
erwähnt haben, so diese Zwischenergebnisse von den
Iterationen und gibt dann einen prompt mit, der schon so einem
bestimmten Format folgt, wo ich einfach den Task definiere, was
zu tun sein soll, den Branch, auf dem er arbeiten soll, die
maximalen Iterationen, die durchgegangen werden soll,
success Kriterien. Die muss ich dann auch nicht in
irgendwelchen Skripten ausarbeiten, sondern da kann ich
einfach irgendwie sagen, keine npm Run Tests muss erfolgreich
mit einem Code 0 aufhören und sowas kann ein paar Sachen
haben, die ich auf jeden Fall machen will.
Kann ein paar Dinge per Hand quasi reinschreiben, die das
Modell in Betracht ziehen soll, wenn es die nächste Loop
aufruft, also woran es auch vielleicht erkennen soll, dass
es vielleicht keine gute Idee ist weiterzumachen und was so
ein bisschen der Output ist, das heißt, da kann man dann schon
relativ suffisticated reingehen, wenn man diese Plugins benutzt.
Aber am Anfang kann man es einfach mal ausprobieren, indem
man einfach eine while Schleife baut und sich mal ein bisschen
mit einem cleveren prompt anguckt, was da rauskommt.
Das ist eigentlich auch. Schon ganz witzig, ja.
Und weil das jetzt vielleicht in so einem Podcast gar nicht so
greifbar oder gut vorstellbar ist, haben wir auch noch einen
passenden Blog, Post und der Blog Post kommt von unseren
früheren Kollegen Darius. Schöne Grüße an dieser Stelle
den Blog Post zur Ralf William Methode, den Darius geschrieben
hat, verlinken wir in den Show Notes, schaut ihn euch mal an.
Können dort sind auch die entsprechenden Codebeispiele
drin, die ihr entsprechend nachbauen könnt, um das ganze
Mal selber auszuprobieren. So, dann fassen wir das ganze
Mal zusammen. Ich möchte aber auf jeden Fall
auf eine Sache auch noch ein Augenmerk legen, das ist
natürlich auch so ein bisschen dieser Kostenfaktor, weil wie
man sich ja bestimmt denken kann, wenn man jetzt die Folge
bis hierhin gehört hat, ist, dass so ein KI Agent, der ist ja
schon nicht wahnsinnig günstig oder kann, da können die Kosten
bei langen Sessions ja auf jeden Fall auch in die Höhe getrieben
werden. Und wenn ich jetzt so einen KI
Agenten immer und immer und immer wieder abfeuer, dann ist
ja glaube ich völlig klar, dass das auch einiges an Geld kostet.
Da sind natürlich zum einen so Computerkosten mit dabei, also
wenn ich das Ding nicht mal nur auf meiner Maschine ist, sondern
vielleicht sogar irgendwie auf einer remote Maschine laufen
lasse, dann zahle ich da ja auch oft pro Minute, wenn ich viele
Tool runs habe, die ganzen Tokens die ich, die ich für die
Verbrate wir haben da teilweise wirklich auch schon.
Beispiele gesehen, wo Kosten ja bis zu dreistellige Summen dann
halt irgendwie sind. Wenn ich das Ding einfach mal so
im afk Modus über Nacht laufen lasse, das jetzt keine
Seltenheit und auch kosten, die dann oft ja vielleicht vergessen
werden ist, dass das Ding ja ja Blödsinn voll auch irgendwelche
Schrott commits erzeugt. Merge Konflikte die ich danach
irgendwie wieder aufarbeiten muss, das heißt ich habe auch
Engineering kosten, irgendeiner muss das Ding ja reviewen ich
muss danach vielleicht noch mal die wagen wenn ich merke, dass
es vielleicht in die falsche Richtung gegangen ist.
Vielleicht sind doch alle Tests grün.
Ich merke in meinen Tests aber irgendwas funktioniert nicht und
ich drill dann noch mal rein, ich glaube das sind generelle
Kosten und Risiken bei relativ autonomer KI Steuerung, aber
wenn ich es wirklich mit dieser Holzhammer Methode Drive da
immer und immer wieder drauf gucken lasse, dann entsteht auch
natürlich einer auf viel viel mehr commits, viel mehr Code,
vielleicht auch viele Änderungen die in der nächsten Iteration
wieder zurückgenommen werden und.
Das ist natürlich auch nicht außer 8 zu lassen.
Also es ist auf keinen Fall was, was jetzt in jede Codingumgebung
quasi bei Default mit mit eingebaut werden sollte, sondern
wäre eher ein Werkzeug, was man sehr bewusst einsetzt, wenn man
sagt, ich habe jetzt hier vielleicht gar nicht die Zeit
oder die Energie oder die Fähigkeiten auf andere Art und
Weise das Modell so in die richtige Richtung zu schubsen,
dann kann man sich überlegen, da mit Ralf Mal drauf zu prügeln.
Muss ja aber auch Bewusstsein, dass das dann wahrscheinlich
auch sehr viele Tokens kostet. Ja, ich glaube, zusammenfassend
lässt sich sagen, wir gehen so ein bisschen Weg von KI, denkt
nach und entscheidet selber zu. Das System prüft und die KI
iteriert einfach nur, das ist ziemlich stumpf, aber in vielen
Fällen funktioniert das Halt einfach.
Die Frage ist, wie lange brauchen wir das noch?
Also werden die KI Modelle und auch die Coding Agenten bald so
gut, dass wir diese Schleife gar nicht mehr brauchen oder diese
Schleife quasi implizit wird. Aber heute merken wir, dass wir
nicht immer die intelligenteste Lösung brauchen, sondern
manchmal auch einfach eine verlässliche Methode, um zu
prüfen, ob die Kriterien erfüllt sind und dann das Ganze
erfolgreich abschließen können und damit mit den Tools, die wir
heute schon haben vielleicht. Solche langlaufenden Aufgaben
erledigen können, ohne jetzt darauf zu warten, dass wir
irgendwelche noch besseren KI Agenten bekommen.
Am Ende muss man ja ganz klar sagen, dass es ja eigentlich nur
ein Workaround ist für die mangelnde Fähigkeit der KI
Modelle im Moment an der richtigen Stelle zu erkennen,
dass sie wirklich fertig sind und.
Und wieso? Oft ja, kann ich mir fast schon
nicht vorstellen, dass wir in einem Jahr noch über Ralf Coding
sprechen, weil wahrscheinlich die KI Provider nachgeliefert
haben. Im Moment funktioniert es aber
gut und wenn ihr jetzt im Moment ein cooles Ergebnis braucht,
dann ist es auf jeden Fall ein cooles Tool, was man sich
angucken kann. Ich glaube, man kann sagen,
Ralf, das ist jetzt nicht wahnsinnig intelligent, das ist
ja nicht wahnsinnig clever, den Agenten einfach noch mal neu zu
starten, aber es funktioniert verlässlich.
Wenn eure Kriterien verlässlich sind, also wenn man ganz klar
gesagt hat, woran kann ich Ende oder Erfolg erkennen,
idealerweise natürlich in Software Development durch
unitests Ich kann das dann auch einfach durch Menschen
geschriebene Prompts ein Modell versuchen zu erklären und kriegt
dann auf jeden Fall bessere Ergebnisse als bisher.
Und uns würde natürlich auch interessieren, ob ihr das Ganze
schon mal ausprobiert habt oder wenn ihr es jetzt nach dieser
Folge ausprobiert. Lasst uns gerne.
Hören wie euer Feedback ist, habt ihr Ralf getestet,
vielleicht in Human in The Loop Modus oder vielleicht sofort afk
yolo und über Nacht würde uns interessieren, was ihr da an
Tokens verbrannt habt und wie eure Ergebnisse auch sind.
Also schreibt uns gerne eine E Mail oder lasst uns einen
Kommentar auf Spotify oder youtube da.
Uns wird natürlich auch interessieren, wie euch die
Folge gefallen hat. Lasst uns also gerne eine gute
Bewertung da oder Daumen oder Sternchen, je nachdem auf
welcher Podcast Platz. Form ihr uns hört und wir freuen
uns natürlich auch immer sehr, wenn ihr uns einen Kaffee
ausgeben möchtet. Da findet ihr einen Link zu
Bimir Coffee auch in den Shownotes zusammen mit auch
allen Links, die wir jetzt hier in der Folge besprochen haben.
Und ansonsten freuen wir uns natürlich, wenn ihr auch nächste
Woche wieder mit dabei seid. Der to do Developer Podcast
erscheinen, die jeden Montag abwechselnd in einer Themenfolge
wie diese Woche und einer News Folge wie nächstes Mal.
Dann hören wir uns nächsten Montag wieder.
Macht's gut. Bis bald und schreibt ganz viel
Code, vielleicht sogar in der Loop.
Bis dann.