1
00:00:00,160 --> 00:00:03,560
Beim Coding mit KI Agenten kann 
man sich wahnsinnig verkünsteln 

2
00:00:03,560 --> 00:00:07,440
nur mit geschickten Prompts, 
einer Vorauswahl an cleveren MCP

3
00:00:07,440 --> 00:00:11,200
Tools und ellenlangen Custom 
Instructions noch mehr 

4
00:00:11,200 --> 00:00:14,720
Performance rauskitzeln. 
Oder aber man macht es mit dem 

5
00:00:14,720 --> 00:00:18,880
Holzhammer und prügelt das KI 
Modell förmlich zu einem, dann 

6
00:00:18,880 --> 00:00:21,200
aber auch doch erstaunlich gutem
Ergebnis. 

7
00:00:21,520 --> 00:00:25,360
Die sogenannte Ralph Wiggam 
Methode ist die dümmste 

8
00:00:25,360 --> 00:00:29,360
anzunehmende aber trotzdem. 
Erstaunlich erfolgreiche 

9
00:00:29,360 --> 00:00:32,960
Vorgehensweise, um aus KI 
Agenten noch mehr rauszuholen. 

10
00:00:33,360 --> 00:00:35,520
Frei benannt nach dem Simpsons 
Charakter. 

11
00:00:35,840 --> 00:00:38,640
Wir schauen uns heute an, was 
eigentlich dahinter steckt. 

12
00:00:44,560 --> 00:00:48,600
Und damit Hallo und herzlich 
Willkommen zu Folge 149 des To 

13
00:00:48,640 --> 00:00:52,400
do Developer Podcast und wie 
immer hört ihr hier mich malte 

14
00:00:52,400 --> 00:00:56,160
Lantin und Robin, Manuel Thiel 
Robin Manuel ist Director AI und

15
00:00:56,160 --> 00:00:58,720
Claude beim E Commerce Software 
Unternehmen Jtl. 

16
00:00:58,880 --> 00:01:02,000
Ich bin Solutions Engineer bei 
github, den Podcast machen wir 

17
00:01:02,000 --> 00:01:05,600
natürlich privat und in unserer 
Freizeit, aber wie immer findet 

18
00:01:05,600 --> 00:01:09,360
ihr auch in dieser Folge ganz 
viel Erfahrung aus dem echten 

19
00:01:09,360 --> 00:01:13,440
Leben, aus unserem Job und 
natürlich aus dem Austausch mit 

20
00:01:13,440 --> 00:01:16,480
euch in der kommenden. 
Community und wir diskutieren 

21
00:01:16,560 --> 00:01:21,120
heute die Ralf Methode. 
Aber bevor wir auf das Thema 

22
00:01:21,120 --> 00:01:24,480
eingehen, natürlich erstmal noch
den üblichen Dank an euch in der

23
00:01:24,480 --> 00:01:25,120
Community. 
Genau. 

24
00:01:25,280 --> 00:01:27,440
Wir haben wieder Kaffee 
ausgegeben bekommen. 

25
00:01:27,440 --> 00:01:30,560
Vielen Lieben Dank dafür. 
Der Liebe Martin hat uns einen 

26
00:01:30,560 --> 00:01:34,040
Kaffee ausgegeben, ein anderer 
Martin hat uns 2 Kaffee 

27
00:01:34,080 --> 00:01:38,400
ausgegeben und der Dominik hat 
auch 2 Kaffee ausgegeben, ganz 

28
00:01:38,400 --> 00:01:41,280
herzlichen Dank, damit ist das 
Koffein. 

29
00:01:42,320 --> 00:01:45,680
Level wieder aufgeladen und wir 
können mit voller Energie in die

30
00:01:45,680 --> 00:01:47,520
Folge starten. 
Ganz, ganz herzlichen Dank. 

31
00:01:47,840 --> 00:01:50,600
Und heute beschäftigen wir uns 
mit einem Thema, was jetzt 

32
00:01:50,600 --> 00:01:54,880
gerade über die letzten Monate 
häufiger mal irgendwo auf Social

33
00:01:54,880 --> 00:01:59,640
Media in Blogs auftauchte und 
eigentlich spannend war, weil 

34
00:01:59,640 --> 00:02:02,560
man dann immer das Gefühl hatte,
KI wird immer komplexer. 

35
00:02:02,560 --> 00:02:07,760
Aber plötzlich kam mit der Ralf 
Methode etwas total simples. 

36
00:02:08,280 --> 00:02:12,320
Und das Ganze adressiert 
eigentlich dieses Problem, was 

37
00:02:12,320 --> 00:02:15,600
wir bei der Nutzung von Coding 
Agenten immer häufiger sehen. 

38
00:02:15,840 --> 00:02:19,520
Dass der Agent sagt, Ich habe 
die Aufgabe erfolgreich erledigt

39
00:02:19,680 --> 00:02:21,760
und wenn man dann ins Detail 
geht. 

40
00:02:22,000 --> 00:02:26,680
Merkt man so richtig fertig ist 
das Ganze nicht und dann startet

41
00:02:26,680 --> 00:02:31,040
man mit einem weiteren prompt 
neu und genau das wollen wir 

42
00:02:31,040 --> 00:02:32,800
jetzt adressieren. 
Genau. 

43
00:02:32,800 --> 00:02:35,320
Und jetzt gibt es ein paar 
Leute, die gesagt haben, weißt 

44
00:02:35,320 --> 00:02:37,680
du was, ich habe eigentlich gar 
keine Lust, dem Agenten immer 

45
00:02:37,680 --> 00:02:40,560
wieder quasi schon so Mantra 
mäßig zu sagen, ja, bist du 

46
00:02:40,560 --> 00:02:42,520
überprüft bitte mal deine 
Arbeit, bist du auch wirklich 

47
00:02:42,520 --> 00:02:45,920
fertig und die haben einfach 
angefangen, die KI Coding 

48
00:02:45,920 --> 00:02:50,080
Agenten, sogenannte Ralf Loop. 
Zu stecken also quasi eine 

49
00:02:50,160 --> 00:02:55,920
erzwungene Weitermacherei und 
dazu so ein paar harte, prüfbare

50
00:02:55,920 --> 00:02:58,120
Kriterien. 
Und haben jetzt quasi was, wieso

51
00:02:58,120 --> 00:03:00,120
eine Autor loop und so eine 
inner Loop gebaut. 

52
00:03:00,120 --> 00:03:04,240
Also es gibt einen Coding 
Agenten der läuft los und wenn 

53
00:03:04,240 --> 00:03:06,920
der fertig ist wird er einfach 
wieder neu gestartet und sagt ja

54
00:03:06,920 --> 00:03:09,200
aber guck mal ob du dich noch 
mal irgendwie ein bisschen was 

55
00:03:09,360 --> 00:03:11,040
was machen solltest. 
Und wenn der dann wieder fertig 

56
00:03:11,040 --> 00:03:13,720
ist wird wieder kurz 
automatisiert gecheckt und dann 

57
00:03:13,720 --> 00:03:16,920
wird ach lauf doch einfach noch 
mal eine Runde los und. 

58
00:03:16,920 --> 00:03:21,600
Und so baut man eigentlich eine 
Endlosschleife, in der man immer

59
00:03:21,600 --> 00:03:24,800
wieder einem Co Agenten dieselbe
Aufgabe gibt und hofft dann, 

60
00:03:25,040 --> 00:03:26,760
dass sich dadurch dieses Problem
löst. 

61
00:03:26,760 --> 00:03:29,600
Dass Dki sagt, dass sie fertig 
ist, aber vielleicht noch gar 

62
00:03:29,600 --> 00:03:32,480
nicht wirklich fertig ist. 
Ja, und am Ende ist die Idee, 

63
00:03:32,480 --> 00:03:34,800
dass wir jetzt nicht immer 
wieder prompt müssen, sondern 

64
00:03:34,800 --> 00:03:38,640
das Ganze so ein bisschen auf 
Autopilot läuft und das Ganze so

65
00:03:38,640 --> 00:03:39,800
ein bisschen angelehnt. 
Aber. 

66
00:03:40,080 --> 00:03:42,800
An ein etwas dümmliches 
Verhalten, bei dem man einfach 

67
00:03:42,800 --> 00:03:45,800
immer wieder über eine Aufgabe 
drüber geht, bis es dann 

68
00:03:45,800 --> 00:03:49,280
irgendwann mal gut ist und 
deswegen auch diese Referenz auf

69
00:03:49,280 --> 00:03:52,160
diesen Charakter. 
Ralph Wiggam was du vorhin 

70
00:03:52,160 --> 00:03:55,360
erwähnt hattest. 
Und heute hören wir, natürlich 

71
00:03:55,520 --> 00:03:59,040
gehen wir natürlich ein bisschen
tiefer in das Thema rein und 

72
00:03:59,120 --> 00:04:02,280
schauen uns an, wann diese 
Methode sinnvoll ist und wann 

73
00:04:02,280 --> 00:04:04,240
sie vielleicht nicht zum Ziel 
führt. 

74
00:04:04,440 --> 00:04:06,160
Genau um das ein bisschen besser
zu verstehen. 

75
00:04:06,400 --> 00:04:08,000
Lass uns doch mal reinschauen, 
was ist denn eigentlich das 

76
00:04:08,000 --> 00:04:10,560
Grundproblem, warum scheitern 
die KI Agenten denn eigentlich 

77
00:04:10,560 --> 00:04:13,120
und was sind die pain Points, 
die Ralf damit so aufgreift? 

78
00:04:13,120 --> 00:04:16,880
Da muss man sagen, es gibt 
eigentlich ein Problem in den 

79
00:04:17,360 --> 00:04:20,160
großen bestehenden KI Modellen 
die diese Agenten unter der 

80
00:04:20,160 --> 00:04:24,080
Haube nutzen und. 
Das nennt man Self Assessment 

81
00:04:24,080 --> 00:04:26,720
Failure. 
Das heißt, dass das Lnm einfach 

82
00:04:26,720 --> 00:04:29,040
glaubt, dass es fertig ist, 
obwohl noch gar nichts stimmt, 

83
00:04:29,200 --> 00:04:31,760
dass sie nicht gut in der Lage 
sind, ihre eigene Arbeit zu 

84
00:04:31,760 --> 00:04:35,360
überprüfen und selbst wenn sie 
es können, dann geben sie 

85
00:04:35,360 --> 00:04:37,800
manchmal einfach zu schnell auf,
dann selbst, wenn man gesagt 

86
00:04:37,800 --> 00:04:42,360
hat, Pass auf, du musst so lange
Code generieren, bis alle Unit 

87
00:04:42,360 --> 00:04:44,920
Tests grün sind, dann kann es 
einfach auch manchmal passieren,

88
00:04:44,920 --> 00:04:47,440
dass das Ding trotzdem aufhört 
und sagt, ja ich. 

89
00:04:48,480 --> 00:04:50,360
Sind es hier nicht grün, aber 
ich glaube, ich komme auch 

90
00:04:50,360 --> 00:04:54,800
irgendwie nicht mehr weiter. 
Und einer der Gründe, warum das 

91
00:04:54,800 --> 00:04:59,280
passiert, ist sogenannter 
Kontext, rot oder Kontext 

92
00:04:59,280 --> 00:05:01,920
blowde, also dass der Kontext so
ein bisschen verrottet, indem er

93
00:05:02,080 --> 00:05:04,760
immer länger wird, denn je 
länger so eine Coding Session 

94
00:05:04,760 --> 00:05:08,800
ist, je mehr der quasi Chat 
History habe ich ja auch, je 

95
00:05:08,800 --> 00:05:12,080
mehr Dinge habe ich, die in dem 
Kontext liegen, die den Agenten 

96
00:05:12,080 --> 00:05:15,080
ablenken können. 
Und gerade wenn, zumindest wenn 

97
00:05:15,080 --> 00:05:17,520
irgendwann mal das Kontext 
Windows voll ist und diese Code 

98
00:05:17,520 --> 00:05:21,440
Agenten anfangen müssen, auch 
Dinge zusammenzufassen, dann 

99
00:05:21,440 --> 00:05:24,320
habe ich oft dramatisch 
schlechtere Qualität und es wird

100
00:05:24,320 --> 00:05:28,800
Müll produziert und ich habe 
Fehler im Ablauf und deswegen 

101
00:05:28,880 --> 00:05:31,160
haben wir jetzt mal hingegangen 
und gesagt, Pass auf, solange 

102
00:05:31,160 --> 00:05:33,840
wir das nicht lösen können, 
können wir ja mal versuchen 

103
00:05:33,840 --> 00:05:36,880
einfach ab einer gewissen Zeit 
zu sagen, so wenn du jetzt 

104
00:05:36,880 --> 00:05:39,280
fertig bist, schmeiße ich den 
ganzen Kontext weg und. 

105
00:05:40,040 --> 00:05:42,800
Nun starte ich es einfach noch 
mal neu und sage okay guck mal, 

106
00:05:42,960 --> 00:05:45,280
tu mal so, als würdest du jetzt 
das allererste Mal von diesem 

107
00:05:45,280 --> 00:05:47,400
prompt hören. 
Der Code, den du in der letzten 

108
00:05:47,400 --> 00:05:50,080
Literation geschrieben hast, der
bleibt aber schon da und so 

109
00:05:50,080 --> 00:05:51,920
hofft man dann einfach, dass 
man, wenn man dem gleichen 

110
00:05:51,920 --> 00:05:54,480
Agenten das gleiche Problem 
hundertmal in Folge gibt, 

111
00:05:54,640 --> 00:05:57,920
zumindest dieses diesen Self 
Assessment ferion diesen Kontext

112
00:05:57,920 --> 00:06:00,560
rot entgegenwirken kann. 
Ich meine, du hast jetzt schon 

113
00:06:00,560 --> 00:06:04,080
ganz viele Begriffe verwendet, 
die vielleicht gar nicht allen, 

114
00:06:04,080 --> 00:06:06,600
die hier zuhören, vertraut sind.
Vielleicht gehen wir noch mal 

115
00:06:06,600 --> 00:06:08,880
ganz schnell. 
Über diese Begriffe drüber. 

116
00:06:09,040 --> 00:06:11,760
Wir reden jetzt hier über Coding
Agenten und wir haben in der 

117
00:06:11,760 --> 00:06:14,720
Vergangenheit über zahlreiche 
gesprochen, aber primär reden 

118
00:06:14,720 --> 00:06:18,000
wir über solche, die dann sich 
auch über die Cii nutzen lassen.

119
00:06:18,000 --> 00:06:21,360
Wir haben hier über Germany 
Cloud Code, Get up Co Pilot 

120
00:06:21,360 --> 00:06:25,520
gesprochen und so ein Agent 
läuft quasi auch schon in einer 

121
00:06:25,520 --> 00:06:27,920
Schleife, weil wir haben ja ein 
Large Language Model dahinter 

122
00:06:28,080 --> 00:06:31,920
und dieses Large Language Model 
wird immer wieder angefragt mit 

123
00:06:31,920 --> 00:06:35,200
neuen Informationen generiert, 
neue Informationen, zum Beispiel

124
00:06:35,200 --> 00:06:37,480
Quelltext und fügt diesen dann 
entsprechend. 

125
00:06:37,560 --> 00:06:41,200
Brechend ein und am Ende geht 
das Light Language Model hin und

126
00:06:41,200 --> 00:06:43,880
versucht selber zu entscheiden, 
wie du gerade gesagt hattest, 

127
00:06:43,880 --> 00:06:47,600
bin ich fertig und dann dir zu 
sagen okay ich habe die Aufgabe 

128
00:06:47,600 --> 00:06:51,680
erledigt und du kannst mir jetzt
eine neue Aufgabe geben und alle

129
00:06:51,680 --> 00:06:55,000
diese Informationen, also mein 
prompt und natürlich meinen 

130
00:06:55,000 --> 00:06:58,280
ganzen Code und alles was ich an
Instructions gebaut habe, das 

131
00:06:58,280 --> 00:07:01,200
geht in dieses sogenannte 
context Window rein und wie du 

132
00:07:01,200 --> 00:07:04,600
gesagt hattest ich. 
In dieser Schleife wird ja die 

133
00:07:04,600 --> 00:07:08,200
Information immer weiter 
aufgebläht, weil alles, was in 

134
00:07:08,200 --> 00:07:11,120
diesem Loop schon passiert ist, 
in der Vergangenheit und gerade 

135
00:07:11,120 --> 00:07:14,960
wenn du dann noch mal einen 
Follow machst, muss ja dann in 

136
00:07:14,960 --> 00:07:16,600
dieses Kontextfenster auch mit 
rein. 

137
00:07:16,600 --> 00:07:20,160
Und natürlich werden diese 
Kontextfenster bei den modernen 

138
00:07:20,160 --> 00:07:22,080
Large Language Models immer 
größer. 

139
00:07:22,640 --> 00:07:25,360
Aber das ändert nichts da dran, 
dass umso mehr Informationen ich

140
00:07:25,360 --> 00:07:27,840
da reinwerfe, umso ungenauer das
wird. 

141
00:07:27,840 --> 00:07:30,800
Und tatsächlich, wie du gesagt 
hast, wenn diese dann irgendwann

142
00:07:30,800 --> 00:07:34,000
sogar komprimiert werden müssen,
dann gehen einfach Informationen

143
00:07:34,000 --> 00:07:36,760
verloren, das nur noch als 
Kontext für diejenigen, die 

144
00:07:36,760 --> 00:07:38,160
jetzt noch nicht so lange 
zuhören. 

145
00:07:38,160 --> 00:07:40,320
Ich glaube, wir können auch 
nicht annehmen, dass alle. 

146
00:07:41,280 --> 00:07:44,480
Schon seit Jahren dabei sind und
alle unsere Folgen zu diesen Ki 

147
00:07:44,480 --> 00:07:46,440
Themen gehört haben. 
Deswegen wollte ich es einmal 

148
00:07:46,440 --> 00:07:49,640
noch schnell erläutern, aber 
jetzt lass uns dann tatsächlich 

149
00:07:49,640 --> 00:07:51,840
noch mal ins Detail reingehen, 
wie setze ich das ganze jetzt 

150
00:07:52,080 --> 00:07:54,320
mit der Ralf Methode auf? 
Genau. 

151
00:07:54,320 --> 00:07:56,640
Gute Ergänzung, eine Sache nur 
noch, wenn der Malte jetzt hier 

152
00:07:56,640 --> 00:08:00,000
von der Schleife spricht, die 
immer voll und im Kontext der 

153
00:08:00,000 --> 00:08:03,280
immer voller wird in dieser 
Schleife, dann sprechen wir da 

154
00:08:03,280 --> 00:08:06,360
natürlich von der eigentlichen 
Agent Loop, also von dem, was 

155
00:08:06,360 --> 00:08:08,480
der Agent schon ohnehin macht 
und. 

156
00:08:08,520 --> 00:08:10,760
Und jetzt ist diese Ralf Methode
eigentlich hingegangen und setzt

157
00:08:10,760 --> 00:08:13,200
dann noch mal eine Schleife 
drumherum. 

158
00:08:13,200 --> 00:08:16,480
Ich glaube, das muss man noch 
mal differenzieren, also man der

159
00:08:16,480 --> 00:08:19,720
Agent selber, der hat ja 
heutzutage schon nicht mehr nur 

160
00:08:19,720 --> 00:08:22,080
noch einen Input und einen 
Output, sondern macht das ein 

161
00:08:22,080 --> 00:08:24,400
bisschen mit sich selber aus und
in dieser Schleife bläht sich 

162
00:08:24,400 --> 00:08:28,080
der Kontext auf und die Ralf 
Methode ist jetzt quasi noch mal

163
00:08:28,080 --> 00:08:30,360
eine Endlosschleife da 
drumherum, das heißt, wenn der 

164
00:08:30,360 --> 00:08:32,440
Agent sagt, Ich bin fertig, der 
einfach wieder von vorne 

165
00:08:32,440 --> 00:08:33,640
gestartet wird. 
Dann. 

166
00:08:33,640 --> 00:08:37,640
Dann lass uns mal kurz in diesen
Wahlflug einsteigen und ich 

167
00:08:37,640 --> 00:08:39,840
glaube, es ist ganz gut so ein 
bisschen so die Geschichte 

168
00:08:39,840 --> 00:08:42,360
dahinter kennenzulernen. 
Du hast ein bisschen 

169
00:08:42,360 --> 00:08:44,960
recherchiert, wo kommt das ganze
ursprünglich her? 

170
00:08:45,440 --> 00:08:47,200
Ja, ist ganz lustig. 
Also eigentlich in einem in 

171
00:08:48,080 --> 00:08:52,720
einem Rahmen von einem YC Agent 
Hackathon entstanden, also YCSY 

172
00:08:52,720 --> 00:08:58,080
Combinator, der bekannte Tech 
Investor aus den USA, die machen

173
00:08:58,080 --> 00:08:59,600
immer wieder so Hackathons und 
da. 

174
00:09:00,040 --> 00:09:02,800
Haben Entwickler ausprobiert, 
einfach so einen KI Coding 

175
00:09:02,800 --> 00:09:06,080
Agenten in der Endlosschleife 
laufen zu lassen, um größere 

176
00:09:06,080 --> 00:09:10,480
Aufgaben autonom zu erledigen. 
Und dabei haben Sie Cloud Code 

177
00:09:10,480 --> 00:09:12,760
benutzt und eben so eine 
Bashloop drumherum geschrieben, 

178
00:09:12,760 --> 00:09:15,320
damit die KI wieder immer wieder
dieselben Aufgaben bekam und 

179
00:09:15,320 --> 00:09:17,120
immer wieder weiter an dem Code 
arbeiten konnte bis alles 

180
00:09:17,120 --> 00:09:18,960
erledigt war und das haben sie 
eigentlich gemacht um das so im 

181
00:09:18,960 --> 00:09:22,160
Hintergrund laufen zu lassen und
ihre eigene Produktivität zu 

182
00:09:22,480 --> 00:09:27,360
steigern und diese ja doch eher 
ungewöhnliche Hackathon 

183
00:09:27,360 --> 00:09:30,640
Experiment Idee. 
Hat dann dazu geführt, dass 

184
00:09:30,800 --> 00:09:34,080
mehrere Positories über Nacht 
automatisch portiert wurden, 

185
00:09:34,080 --> 00:09:35,840
also von einer 
Programmiersprache in die andere

186
00:09:35,840 --> 00:09:38,480
bearbeitet wurden und die sind 
dann am nächsten Morgen wieder 

187
00:09:38,480 --> 00:09:40,880
zurückgekommen und alles war 
fertig und das Experiment ist 

188
00:09:40,880 --> 00:09:46,240
quasi so ein bisschen aus Zufall
geglückt und dieses Muster des 

189
00:09:46,240 --> 00:09:49,360
Wiederholenden Ki codings wurde 
dann ein bisschen später populär

190
00:09:49,360 --> 00:09:51,160
und. 
Weiß ich gar nicht genau, wo es 

191
00:09:51,160 --> 00:09:53,680
herkommt, aber eben als die Ralf
Methode nach diesem Simpsons 

192
00:09:53,680 --> 00:09:58,080
Charakter Ralf Viggam benannt. 
Das bedeutet also, die Idee war 

193
00:09:58,080 --> 00:10:02,160
von vornherein, diesen Agent 
inner Loop durch einen Outer 

194
00:10:02,160 --> 00:10:06,720
Loop quasi zu ergänzen und damit
dann auch sicherzustellen, dass 

195
00:10:06,720 --> 00:10:11,040
nicht mehr der Agent selber 
entscheidet, ob die Aufgabe 

196
00:10:11,040 --> 00:10:13,880
erledigt ist, sondern dass es 
klar verifizierbare 

197
00:10:13,880 --> 00:10:16,400
Erfolgskriterien gibt. 
Das heißt, ich habe jetzt nicht 

198
00:10:16,800 --> 00:10:20,080
einen relativen Wagen prompt wie
baue Authentication. 

199
00:10:20,240 --> 00:10:24,360
In meine Anwendung ein an den 
Coding Agenten übergeben, 

200
00:10:24,360 --> 00:10:28,720
sondern ich habe eine genaue 
Beschreibung der Aufgabe plus 

201
00:10:28,880 --> 00:10:32,480
ganz klare Erfolgskriterien 
definiert, die in diesem 

202
00:10:32,480 --> 00:10:35,720
Autaloop validiert werden. 
Das heißt, in diesem Autaloop 

203
00:10:35,720 --> 00:10:39,240
wird zum Beispiel validiert, 
dass alle Testcases grün sind 

204
00:10:39,240 --> 00:10:41,440
und diese Testcases habe ich 
vorab. 

205
00:10:41,800 --> 00:10:45,440
Geschrieben, ich habe sie vorab 
definiert, damit ist es ganz 

206
00:10:45,440 --> 00:10:48,960
klar verifizierbar, dass die 
Aufgabe wirklich erledigt wurde 

207
00:10:49,120 --> 00:10:51,120
und der Coding Agent entscheidet
nicht selber. 

208
00:10:51,280 --> 00:10:54,240
Authentification habe ich jetzt 
eingebaut, damit bin ich fertig,

209
00:10:54,480 --> 00:10:57,760
sondern es ist ganz klar prüfbar
und wenn diese Prüfung 

210
00:10:57,760 --> 00:11:00,560
fehlschlägt, dann geht es 
einfach noch mal von vorne los 

211
00:11:00,560 --> 00:11:02,560
und das Ganze wird noch mal 
bearbeitet. 

212
00:11:02,720 --> 00:11:04,880
Genau das läuft dann über 
sogenannte Stop Hooks. 

213
00:11:04,880 --> 00:11:08,800
Also wenn ich so wie Cloud Code 
nehme, da gibt es wenn wenn das 

214
00:11:09,120 --> 00:11:11,600
Modell sagt ich bin fertig, dann
kann man sich da. 

215
00:11:11,800 --> 00:11:15,000
Quasi drauf dieses Event 
abonnieren und das genau macht 

216
00:11:15,000 --> 00:11:17,680
diese Auto loop, die sagt okay, 
dass sie das Modell sagt Ich bin

217
00:11:17,680 --> 00:11:21,240
fertig, ich überprüfe jetzt aber
auch mit einem Skript, was ich 

218
00:11:21,240 --> 00:11:23,440
vielleicht noch dabei gelegt 
habe, ob das Modell wirklich 

219
00:11:23,440 --> 00:11:24,640
fertig ist. 
Also ich nehme diese 

220
00:11:24,640 --> 00:11:27,120
Verantwortung von dem Modell 
weg, mir ist total egal, ob das 

221
00:11:27,120 --> 00:11:29,920
Modell jetzt entscheidet fertig 
zu sein, das zählt gar nicht, es

222
00:11:29,920 --> 00:11:33,200
wird sofort wieder neu 
gestartet, wenn das System nicht

223
00:11:33,200 --> 00:11:35,440
entschieden hat, dass es fertig 
ist als wenn diese Auto loop das

224
00:11:35,440 --> 00:11:38,320
nicht entschieden hat. 
Da kann man natürlich noch n 

225
00:11:38,320 --> 00:11:40,000
Paar so Sicherheitsmechanismen 
drumherum bauen. 

226
00:11:40,000 --> 00:11:42,720
Also es gibt es gibt schon so 
die ersten jetzt wirklich 

227
00:11:42,720 --> 00:11:45,840
fertigen Ralf Coding Plugins, 
die haben dann auch so Sachen 

228
00:11:46,000 --> 00:11:49,760
wie Max. 
Maximale Iterationen da 

229
00:11:49,760 --> 00:11:51,840
eingebaut, dass man da wieso 
eine Kostenexplosion auch 

230
00:11:51,840 --> 00:11:53,880
vermeiden kann. 
Aber die Idee ist eigentlich 

231
00:11:53,880 --> 00:11:55,320
immer die Gleiche. 
Ich lege einmal fest, wie das 

232
00:11:55,320 --> 00:11:58,160
System überprüfen kann, ob ob 
die Aufgabe erfüllt ist und dann

233
00:11:58,160 --> 00:12:00,480
rennt das Ding einfach, 
entscheidet die Autalob 

234
00:12:00,480 --> 00:12:04,160
eigentlich wie oft die KI auf 
die gleiche Aufgabe losgelassen 

235
00:12:04,160 --> 00:12:06,720
wird? 
Ja, und die Idee, warum das 

236
00:12:06,720 --> 00:12:10,560
Ganze dann am Ende auch so 
effizient ist oder tatsächlich 

237
00:12:10,560 --> 00:12:13,600
funktioniert, ist. 
Dass der Kontext immer wieder 

238
00:12:13,600 --> 00:12:16,760
frisch ist, das bedeutet, ich 
starte immer wieder eine neue 

239
00:12:16,760 --> 00:12:20,240
Agent Session und habe 
dementsprechend keinen Kontext 

240
00:12:20,240 --> 00:12:25,040
blowde oder eine entsprechende 
Komprimierung der Informationen,

241
00:12:25,120 --> 00:12:28,720
sondern tatsächlich kommt immer 
wieder ein ganz frischer Coding 

242
00:12:28,720 --> 00:12:32,160
Agent mit der gleichen Aufgabe. 
Schaut auf den aktuellen Stand 

243
00:12:32,160 --> 00:12:36,480
des Quelltextes und nimmt dann 
Überarbeitung vor und das Ganze 

244
00:12:36,480 --> 00:12:40,080
läuft wie gesagt in dieser 
Schleife bis die Aufgabe. 

245
00:12:40,640 --> 00:12:43,640
Neutral, objektiv beurteilt, 
erledigt ist. 

246
00:12:43,640 --> 00:12:48,440
Das heißt, die Wahrheit oder die
Validierung des Zustandes kommt 

247
00:12:48,440 --> 00:12:50,720
jetzt nicht aus dem Large 
Language Model, sondern ist halt

248
00:12:50,720 --> 00:12:54,560
ganz klar auf Basis meines 
Repositories auf den Dateien 

249
00:12:55,040 --> 00:12:59,440
basierend und dementsprechend 
können wir damit die Realität 

250
00:12:59,440 --> 00:13:01,520
abprüfen. 
Das heißt, wir sehen tatsächlich

251
00:13:02,080 --> 00:13:03,920
was. 
Sagen meine Tests. 

252
00:13:03,920 --> 00:13:06,560
Was sagen die Logs, welche 
Dateien wurden erstellt und auf 

253
00:13:06,560 --> 00:13:10,880
Basis dieser nicht veränderbaren
Wahrheit quasi entscheiden wir, 

254
00:13:10,880 --> 00:13:13,000
wann unser Outer Loop stoppen 
muss, das. 

255
00:13:13,040 --> 00:13:17,040
Ist natürlich trotzdem nicht 
jeder einzelne Run von dem 

256
00:13:17,040 --> 00:13:18,720
Agenten. 
Jeder einzelne Inner Loop 

257
00:13:19,720 --> 00:13:23,600
komplett wieder von vorne oder 
gar nicht einzigartig? 

258
00:13:23,960 --> 00:13:26,040
Ich kann dem Modell natürlich 
sagen, dass es, wenn es fertig 

259
00:13:26,040 --> 00:13:28,400
ist, eine Zusammenfassung von 
den letzten Runs oder von allem,

260
00:13:28,400 --> 00:13:30,720
was es gemacht hat in so einer 
temporären Textdatei ablegen 

261
00:13:30,720 --> 00:13:34,160
kann, die dann die nächste 
Iteration wieder aufgreifen 

262
00:13:34,160 --> 00:13:35,200
kann. 
Das heißt, das kann ich zum 

263
00:13:35,200 --> 00:13:37,440
Beispiel einfach in den Custom 
Instructions hinzufügen, da kann

264
00:13:37,440 --> 00:13:39,600
ich so eine to do Liste sagen, 
das einfach pflegen soll zum 

265
00:13:39,600 --> 00:13:42,000
Beispiel, und die wird abgehakt 
und so was, dass die nächste 

266
00:13:42,000 --> 00:13:45,520
Iteration nicht natürlich nicht 
diesen ganzen, die ganze 

267
00:13:45,520 --> 00:13:47,760
Historie im Kontext hat, aber 
durchaus mal so eine 

268
00:13:47,760 --> 00:13:49,680
Zusammenfassung, was denn 
eigentlich in der vorherigen 

269
00:13:49,680 --> 00:13:52,880
Iteration passiert ist. 
Und so läuft das dann auch 

270
00:13:52,880 --> 00:13:54,600
quasi. 
Also so der typische Ablauf 

271
00:13:54,600 --> 00:13:56,000
eigentlich von so einem Drive 
Development ist. 

272
00:13:56,000 --> 00:13:59,360
Man legt vorher einfach einmal 
einen Plan an von dem was man 

273
00:13:59,360 --> 00:14:02,280
machen will, den legt man ins 
Repository, zum Beispiel als 

274
00:14:02,280 --> 00:14:04,840
Makler und Datei. 
Idealerweise macht man das 

275
00:14:04,840 --> 00:14:07,760
direkt mit so einem Specdriven 
Development Ansatz, da haben 

276
00:14:08,000 --> 00:14:10,800
wir. 
Auch mal in Folge 137 drüber 

277
00:14:10,800 --> 00:14:11,960
gesprochen. 
Das heißt, man nimmt sich 

278
00:14:11,960 --> 00:14:14,840
wirklich ein bisschen Zeit, eine
gute Spezifizierung zu schreiben

279
00:14:14,840 --> 00:14:17,160
und das ist ganz wichtig, weil 
ich lasse das Ding ja vielleicht

280
00:14:17,160 --> 00:14:20,800
sogar über Stunden idealerweise 
so laufen, dass es dann keinen 

281
00:14:20,800 --> 00:14:22,600
extra Input mehr von einem 
Menschen braucht, weil ich will 

282
00:14:22,600 --> 00:14:24,800
in der Zeit was anderes machen 
oder es läuft über Nacht oder 

283
00:14:24,800 --> 00:14:28,000
sowas, das heißt, es lohnt sich 
auf jeden Fall die vor die 

284
00:14:28,000 --> 00:14:31,040
Aufgabe ordentlich 
auszuspezifizieren Spectrive 

285
00:14:31,040 --> 00:14:33,080
Development kann dabei einmal 
ein bisschen helfen, auch 

286
00:14:33,080 --> 00:14:35,960
kritische Rückfragen zu stellen.
Ja, und dann geht es eben los. 

287
00:14:36,000 --> 00:14:40,320
Man sagt dem Agenten, nimm dir 
genau eine Task und 

288
00:14:40,320 --> 00:14:44,360
Implementiere das so minimal wie
es geht und führe Tests aus und 

289
00:14:44,360 --> 00:14:46,520
den Linter und guckt, dass das 
Ding baut und wenn du 

290
00:14:46,520 --> 00:14:49,320
erfolgreich bis machen komm mit 
und dann ist das Ding meistens 

291
00:14:49,320 --> 00:14:51,680
immer fertig und dann startet 
eigentlich schon die nächste 

292
00:14:51,680 --> 00:14:54,480
Iteration, die sich das dann 
anschaut und überlegt okay 

293
00:14:54,800 --> 00:14:56,920
vielleicht ist der Agent hier 
noch nicht fertig, ich gebe das 

294
00:14:56,920 --> 00:15:01,200
jetzt wieder rein und so geht es
Iteration um Iteration bis ich 

295
00:15:01,200 --> 00:15:02,760
entweder wirklich fertig bin 
oder? 

296
00:15:03,120 --> 00:15:05,720
Oder das Limit erreicht ist. 
Wie oft ich da eigentlich drüber

297
00:15:05,720 --> 00:15:08,160
iterieren möchte. 
Am Ende ist es so, als würde ich

298
00:15:08,160 --> 00:15:10,840
dir eine Aufgabe geben und 
sagen, deine Meinung 

299
00:15:10,840 --> 00:15:13,520
interessiert mich nicht. 
Es müssen folgende neutrale 

300
00:15:13,520 --> 00:15:16,160
Kriterien erfüllt sein, erst 
dann bist du fertig. 

301
00:15:16,480 --> 00:15:20,320
Das bedeutet, wenn du behauptest
fertig zu sein und meine 

302
00:15:20,320 --> 00:15:22,960
Evaluationskriterien 
fehlschlagen, dann setzt du dich

303
00:15:22,960 --> 00:15:25,520
einfach noch mal dran und 
arbeitest noch mal drüber das 

304
00:15:25,520 --> 00:15:27,600
können. 
Test Cases sein, die vorher 

305
00:15:27,600 --> 00:15:28,960
geschrieben haben. 
Das können aber auch andere 

306
00:15:28,960 --> 00:15:31,440
Kriterien sein. 
Ich kann dir natürlich auch eine

307
00:15:31,440 --> 00:15:34,080
Aufgabe geben, du musst 
mindestens so und so viel Tests 

308
00:15:34,080 --> 00:15:36,760
geschrieben haben und die müssen
alle erfolgreich sein, aber es 

309
00:15:36,760 --> 00:15:39,400
kann auch was völlig anderes 
sein, das heißt ich kann 

310
00:15:39,400 --> 00:15:43,160
natürlich auch andere 
Evaluationskriterien da 

311
00:15:43,160 --> 00:15:45,120
ansetzen, Tests sind jetzt hier 
nur ein. 

312
00:15:45,560 --> 00:15:47,200
Beispiel, was häufig verwendet 
wird. 

313
00:15:47,920 --> 00:15:50,880
Letzten Endes kann ich alles, 
was ich wirklich neutral 

314
00:15:50,880 --> 00:15:54,480
auswerten kann, dort als 
Abbruchkriterium verwenden. 

315
00:15:54,640 --> 00:15:56,520
Jetzt hast du dir Ralf ja schon 
mal so ein bisschen angeguckt, 

316
00:15:56,520 --> 00:15:59,120
dann auch so ein bisschen in die
Community reingehorcht, wo das 

317
00:15:59,120 --> 00:16:02,320
gut funktioniert und wo das 
nicht gut funktioniert. 

318
00:16:02,880 --> 00:16:05,160
Hast du da irgendwie ein paar 
Beispiele, so für uns, wo du 

319
00:16:05,160 --> 00:16:08,600
sagst, das ist was, da kann man 
Ralf gut für einsetzen oder 

320
00:16:08,600 --> 00:16:10,120
vielleicht gibt es auch 
irgendwie andere Sachen wo du 

321
00:16:10,120 --> 00:16:11,880
sagst, dafür ist es irgendwie 
gar nichts da, weil ich muss 

322
00:16:11,880 --> 00:16:13,840
zugeben, ich habe jetzt auch so 
ein bisschen was darüber gelesen

323
00:16:13,840 --> 00:16:16,120
in der Vorbereitung. 
Ich habe es aber noch nicht 

324
00:16:16,120 --> 00:16:18,440
selber ausprobiert und du 
hattest das Thema ja mitgebracht

325
00:16:18,440 --> 00:16:21,280
und gesagt, Ey, das ist 
eigentlich erstaunlich gut, dass

326
00:16:21,280 --> 00:16:23,840
das funktioniert. 
Was würdest du sagen, wofür ist 

327
00:16:23,840 --> 00:16:25,840
es besonders gut geeignet und 
wofür vielleicht auch irgendwie 

328
00:16:25,840 --> 00:16:27,760
gar nicht? 
Ja, wir hatten es ja gerade 

329
00:16:27,760 --> 00:16:31,520
quasi schon gesagt. 
Überall wo du eine klare so 

330
00:16:31,520 --> 00:16:35,280
Definition of Done hast. 
Das können zum Beispiel Bugfixes

331
00:16:35,280 --> 00:16:37,600
sein, wenn du. 
Regression Tests hast die 

332
00:16:37,600 --> 00:16:40,640
Fehlschlagen kannst du sagen, 
Fixt das und dann weißt du der 

333
00:16:40,640 --> 00:16:44,160
Test ist am Ende grün oder ich 
habe jetzt irgendwie einen 

334
00:16:44,160 --> 00:16:48,720
Linter der bestimmte Kriterien 
vorgibt, die erfüllt sein müssen

335
00:16:48,880 --> 00:16:52,000
und solange dieser Linter 
fehlschlägt oder bestimmte 

336
00:16:52,000 --> 00:16:55,840
Warnings ausgibt, muss ich 
entsprechend das ganze 

337
00:16:55,840 --> 00:16:58,000
überarbeiten. 
Es können auch. 

338
00:16:58,960 --> 00:17:01,560
CI getriebene Definition von 
dann sein. 

339
00:17:01,560 --> 00:17:04,720
Das heißt ich kann das auch 
irgendwo in meiner CI Pipeline 

340
00:17:04,720 --> 00:17:09,160
laufen lassen um bestimmte Dinge
sicherzustellen, dass das. 

341
00:17:09,160 --> 00:17:11,920
Das entsprechend erfolgreich 
erledigt ist, weil am Ende kann 

342
00:17:11,920 --> 00:17:15,520
ich natürlich mit solchen KI 
Coding Agenten auf der Command 

343
00:17:15,520 --> 00:17:17,800
Line auch andere Dinge tun. 
Wir haben jetzt immer das 

344
00:17:17,800 --> 00:17:20,400
Beispiel so der 
Softwareentwicklung wo ich Code 

345
00:17:20,400 --> 00:17:22,960
schreibe verwendet, aber ich 
kann natürlich auch solche 

346
00:17:22,960 --> 00:17:26,480
Coding Agenten verwenden um zum 
Beispiel Dokumentation zu 

347
00:17:26,480 --> 00:17:29,360
ergänzen, habe ich letzten ganz 
spannenden Use Case gesehen und 

348
00:17:29,360 --> 00:17:32,480
da kannst du natürlich auch 
sagen okay du bist erst fertig 

349
00:17:32,480 --> 00:17:35,760
wenn es zu allen neuen Features 
die jetzt implementiert wurden 

350
00:17:35,760 --> 00:17:38,520
entsprechende 
Dokumentationsdatei gibt und die

351
00:17:38,520 --> 00:17:40,720
einen bestimmten. 
Umfang hat und folgende Themen 

352
00:17:40,720 --> 00:17:43,440
abdeckt. 
Und das ist deine Definition of 

353
00:17:43,440 --> 00:17:49,040
done, also überall wo du sowas 
klar evaluieren kannst und in 

354
00:17:49,040 --> 00:17:52,320
der Regel habe ich dann 
irgendwelche statischen Tools 

355
00:17:52,320 --> 00:17:55,200
hier laufen, das kann irgendwie 
ein Build tool sein, das 

356
00:17:55,200 --> 00:17:58,520
kanntest Framework sein, das 
kann Linda sein, überall wo ich 

357
00:17:58,520 --> 00:18:00,960
halt am Ende ja oder Nein 
zurückbekomme. 

358
00:18:01,200 --> 00:18:02,800
Okay also gute Use Case würde 
ich dann sagen. 

359
00:18:02,800 --> 00:18:06,160
Sind eigentlich so kleine 
Bugfixes oder mechanische 

360
00:18:06,160 --> 00:18:09,080
Refactorings oder ich soll 
irgendwelche Backend Endpunkte. 

361
00:18:09,160 --> 00:18:14,600
Punkte ausspezifizieren oder 
implementieren also sozusagen 

362
00:18:14,600 --> 00:18:17,440
schon auch eher kleine Tasks, 
weil das klingt jetzt ja erstmal

363
00:18:17,440 --> 00:18:21,160
so, als wäre es natürlich für 
alles nicht geeignet, wo ich 

364
00:18:21,160 --> 00:18:23,840
auch viel menschlichen Input 
natürlich haben will oder wo ich

365
00:18:23,840 --> 00:18:26,240
mehrere Versionen von irgendwas 
erstellt, wenn ich sage ey, 

366
00:18:26,240 --> 00:18:28,640
machen wir mal 2 Vorschläge wie 
der Button aussehen könnte, 

367
00:18:28,640 --> 00:18:31,280
finde die besten User Experience
von irgendwie sowas. 

368
00:18:32,920 --> 00:18:36,040
Oder so migriere mir mal das 
komplette Projekt jetzt 

369
00:18:36,040 --> 00:18:39,200
irgendwie von der einen Cloud in
die andere rüber oder sowas, wo 

370
00:18:39,200 --> 00:18:41,120
ich ja vielleicht auch nur 
wirklich Rückfragen, auch dann 

371
00:18:41,120 --> 00:18:43,040
auf dem Weg irgendwie 
auftauchen. 

372
00:18:43,240 --> 00:18:45,400
Das sind ja wahrscheinlich so 
Sachen, die dann eher ungeeignet

373
00:18:45,400 --> 00:18:47,920
sind, oder? 
Ja oder auch wo ich dann 

374
00:18:47,920 --> 00:18:51,080
tatsächlich im 
Entwicklungsprozess dann 

375
00:18:51,080 --> 00:18:54,240
irgendwie das Feedback brauche, 
weil ich zum Beispiel ein 

376
00:18:54,240 --> 00:18:56,480
Debugging mache und dann 
irgendwie auch eine. 

377
00:18:57,000 --> 00:19:00,000
Fehlermeldung Zurückbekomme, die
ich interpretieren muss oder 

378
00:19:00,000 --> 00:19:03,760
wenn ich irgendwelche Tests 
durchlaufen lasse, die irgendwie

379
00:19:03,760 --> 00:19:06,960
flakey sind, weil du bestimmte 
nichtdeterministische Faktoren 

380
00:19:06,960 --> 00:19:10,360
da drin hast, dann kann es 
natürlich sein, dass ich die 

381
00:19:10,360 --> 00:19:12,160
Implementierung erfolgreich 
abgeschlossen habe, aber 

382
00:19:12,160 --> 00:19:14,640
trotzdem schlägt ab und zu mal 
ein Testfehl. 

383
00:19:14,800 --> 00:19:16,880
Also bei solchen Dingen 
funktioniert das nicht. 

384
00:19:17,080 --> 00:19:19,760
Es müssen aber nicht unbedingt 
nur kleinere Dinge sein. 

385
00:19:19,760 --> 00:19:22,960
Gerade das, was du als 
Ursprungsstory gerade 

386
00:19:22,960 --> 00:19:25,600
mitgebracht hat, es war ja 
durchaus etwas Größeres, wo sie 

387
00:19:25,600 --> 00:19:29,760
gesagt haben, wir portieren hier
etwas von einer Sprache in eine 

388
00:19:29,760 --> 00:19:33,000
andere, aber da kannst du 
natürlich auch ganz klar sagen, 

389
00:19:33,000 --> 00:19:36,880
okay welche Features müssen 
vorhanden sein, welche Tests 

390
00:19:36,880 --> 00:19:39,920
müssen erfolgreich durchlaufen, 
damit diese Portierung 

391
00:19:40,000 --> 00:19:43,680
vollständig und korrekt ist. 
Also da habe ich auch eine ganz 

392
00:19:43,680 --> 00:19:47,000
klare Art und Weise, wie ich das
Ganze checken kann und was. 

393
00:19:47,080 --> 00:19:48,440
Genau so haben Sie es damals 
gemacht. 

394
00:19:48,440 --> 00:19:51,400
Das heißt, es muss jetzt nicht 
unbedingt etwas Kleines sein, 

395
00:19:51,400 --> 00:19:52,920
sondern es kann auch etwas 
Größeres sein. 

396
00:19:52,920 --> 00:19:55,040
Du musst halt immer nur 
sicherstellen können, dass du 

397
00:19:55,360 --> 00:19:58,720
objektiv beurteilen kannst, ob 
das Ganze erfolgreich war. 

398
00:19:59,040 --> 00:20:00,920
Genau das heißt aber nicht, dass
ich da jetzt nicht trotzdem 

399
00:20:00,920 --> 00:20:03,040
irgendwie menschlich noch mal 
ein Feedback geben kann. 

400
00:20:03,040 --> 00:20:06,160
Also ich kann trotzdem so einen 
human in The Loop Modus auch 

401
00:20:06,160 --> 00:20:09,680
beim Ralf Code natürlich haben, 
erhoffe mir davon aber 

402
00:20:09,680 --> 00:20:12,240
natürlich, dass der deutlich 
seltener auftritt, in dem zum 

403
00:20:12,240 --> 00:20:14,440
Beispiel a ich jetzt erstmal 
nicht überprüfen muss, ob die 

404
00:20:14,440 --> 00:20:16,160
Loop fertig ist und wieder neu 
starten muss. 

405
00:20:16,640 --> 00:20:19,280
Aber trotzdem muss ich ja auch 
nicht im Yolo Modus, dem alle 

406
00:20:19,280 --> 00:20:22,520
Tool Calls erlauben und kann er 
trotzdem auch in dieser Look 

407
00:20:22,520 --> 00:20:25,280
einen Agenten starten, der sich 
ab und zu Feedback von Menschen 

408
00:20:25,280 --> 00:20:26,360
einholt. 
Das geht natürlich dann 

409
00:20:26,360 --> 00:20:30,440
trotzdem, es gibt aber auch so 
diese afk Methode wo ich sage 

410
00:20:30,440 --> 00:20:32,640
okay ich möchte damit gar nichts
zu tun haben, ich lege mich 

411
00:20:32,640 --> 00:20:35,200
vielleicht sogar schlafen und 
lass das Ding wirklich im Batch 

412
00:20:35,200 --> 00:20:37,760
Mode irgendwas abarbeiten und 
sage dann auch ganz klar beim 

413
00:20:37,760 --> 00:20:40,640
starten ich möchte, dass du dich
nicht fragst ob du irgendwelche 

414
00:20:40,800 --> 00:20:42,560
Dinge tun darfst. 
Ich gebe dir eine ganz klare 

415
00:20:42,560 --> 00:20:45,600
Liste von vielleicht auch MCP 
Tools die du aufrufen darfst 

416
00:20:46,000 --> 00:20:47,880
und. 
Und das bietet sich natürlich 

417
00:20:47,880 --> 00:20:49,840
auch nur an, wenn die Kriterien 
halbwegs stabil sind. 

418
00:20:49,840 --> 00:20:54,720
Also je besser diese diese diese
Testumgebung, die malte Rad 

419
00:20:54,720 --> 00:20:56,800
schon so viel beschrieben hat, 
je besser die ist, desto eher 

420
00:20:56,800 --> 00:21:00,880
kann ich natürlich in diese afk 
Methode reingehen, aber es ist 

421
00:21:00,880 --> 00:21:02,920
natürlich auch eine, hat 
natürlich auch irgendwo seine 

422
00:21:02,920 --> 00:21:05,600
Grenzen, also ist natürlich auch
eine sehr stumpfe Art und Weise.

423
00:21:06,360 --> 00:21:08,760
An so einen Ansatz ranzugehen, 
ist also jetzt nicht so, wie 

424
00:21:08,760 --> 00:21:10,600
dieses Cursor. 
Beispiel, was wir in der letzten

425
00:21:10,600 --> 00:21:13,560
News Folge hatten, wo Cursor ja 
mit ganz vielen verschiedenen 

426
00:21:13,560 --> 00:21:15,600
Agenten, die sich gegenseitig 
orchestrieren, so einen ganz 

427
00:21:15,600 --> 00:21:18,880
neuen Browser gebaut haben, ist 
also auch nicht immer die 

428
00:21:18,880 --> 00:21:21,280
Lösung, es gibt nur eben gesagt,
für bestimmte Ansätze kann man 

429
00:21:21,280 --> 00:21:23,360
einfach sagen, weißt du was? 
Bevor ich mir jetzt hier im 

430
00:21:23,360 --> 00:21:26,080
Detail angucke, warum die KI 
jetzt an dem ein Ding nicht 

431
00:21:26,080 --> 00:21:29,680
weiterkommt, lege ich die 
einfach mal in so eine Ralf Flup

432
00:21:29,680 --> 00:21:31,960
rein und deswegen macht es ja 
vielleicht Sinn, dass wir uns 

433
00:21:31,960 --> 00:21:34,240
mal im Vergleich angucken, was 
gibt es denn eigentlich so für 

434
00:21:34,240 --> 00:21:36,720
Ansätze? 
Noch mal ein bisschen also 

435
00:21:36,720 --> 00:21:39,360
bestimmte Coding Agenten in 
einer bestimmten Art und Weise 

436
00:21:39,600 --> 00:21:42,880
aufzurufen. 
Und ja, wie differenzieren die 

437
00:21:42,880 --> 00:21:46,160
sich denn eigentlich zu Ralf als
Referenzpunkt? 

438
00:21:46,480 --> 00:21:49,040
Ja, da haben wir einmal diese 
React Methode, da ist so ein 

439
00:21:49,040 --> 00:21:50,880
bisschen so das klassische wie 
diese. 

440
00:21:50,880 --> 00:21:53,680
Coding Agenten arbeiten, das 
heißt, Es gibt am Anfang so eine

441
00:21:53,680 --> 00:21:57,040
Thought oder reasoning Phase, 
dann werden die Aufgaben 

442
00:21:57,040 --> 00:22:00,000
umgesetzt, dann wird das 
Ergebnis beobachtet und dann 

443
00:22:00,000 --> 00:22:01,680
wird eine Entscheidung 
getroffen, ob das Ganze 

444
00:22:01,680 --> 00:22:06,160
erfolgreich war und. 
Und da ist natürlich das ganze 

445
00:22:06,160 --> 00:22:09,680
relativ chatty bei Ralf 
natürlich durch diese klaren 

446
00:22:09,680 --> 00:22:11,840
Kriterien nicht. 
Und ich habe natürlich hier auch

447
00:22:11,840 --> 00:22:16,480
durch den Neustart pro Iteration
einen sehr aufgeräumten Kontext.

448
00:22:17,080 --> 00:22:20,840
Bei explorativeren Aufgaben, wie
du vorhin auch schon sagtest, 

449
00:22:20,840 --> 00:22:24,320
ist vielleicht so ein 
klassischer Ansatz wie dieses 

450
00:22:24,320 --> 00:22:29,280
React sinnvoller, aber wenn ich 
tatsächlich nur etwas ausführen 

451
00:22:29,280 --> 00:22:32,640
und am Ende validieren muss, ob 
das Ganze erfolgreich war, dann 

452
00:22:32,640 --> 00:22:35,200
funktioniert natürlich diese 
Drive Methode sehr gut. 

453
00:22:35,280 --> 00:22:37,440
Ja, was auch jetzt, gerade im 
Moment ja viele machen, ist so 

454
00:22:37,760 --> 00:22:41,280
erstmal planen und dann 
ausführen, das ist auch das, wo 

455
00:22:41,280 --> 00:22:43,600
ich gerade eigentlich so am 
meisten Spaß mit habe, weil ich 

456
00:22:43,600 --> 00:22:45,280
auch finde, dass extrem gut 
funktioniert. 

457
00:22:45,800 --> 00:22:48,960
Das geht so ein bisschen, diesen
diesen specdriven Ansatz, den 

458
00:22:48,960 --> 00:22:50,320
wir auch vor ein paar folgen mal
hatten. 

459
00:22:50,320 --> 00:22:53,040
Das heißt, du baust wirklich 
erst mit der KI einen Plan, der 

460
00:22:53,040 --> 00:22:56,920
wird dann mehr oder weniger 
eingefroren, und dann hat die KI

461
00:22:56,920 --> 00:23:02,000
diesen Plan abzuarbeiten. 
Bei Ralf kannst du jetzt 

462
00:23:02,000 --> 00:23:03,960
natürlich das trotzdem ein 
bisschen kombinieren, du kannst 

463
00:23:03,960 --> 00:23:06,760
ja trotzdem sagen, dass dieser 
Plan in diesem Repo liegt und 

464
00:23:06,760 --> 00:23:10,240
dann iteriert halt irgendwie. 
Ralf über diesen Plan rüber, das

465
00:23:10,240 --> 00:23:13,520
ist gar nicht so weit weg. 
Wenn ich natürlich jetzt sage, 

466
00:23:13,520 --> 00:23:16,080
ich nehme mir extrem viel 
Arbeit, schon in diesen Plan 

467
00:23:16,080 --> 00:23:18,640
vorher rein und schreibe da 
wirklich extrem viel runter und 

468
00:23:18,880 --> 00:23:20,880
dann würde ich mir noch mal 
angucken, ob ich dann überhaupt 

469
00:23:20,880 --> 00:23:23,120
Ralf brauche, weil dann habe ich
mir vorher schon wirklich ganz 

470
00:23:23,120 --> 00:23:25,440
genaue Arbeit gemacht, dem 
Modell auch ganz genau zu sagen,

471
00:23:25,440 --> 00:23:27,480
wann es fertig ist. 
Und davon würde ich mir jetzt 

472
00:23:27,480 --> 00:23:29,760
auch erhoffen, dass es seltener 
zu diesem Stand kommt, wo das 

473
00:23:29,760 --> 00:23:32,120
Modell einfach aufhört oder 
aufgibt dann. 

474
00:23:32,120 --> 00:23:34,200
Das heißt, bei Ralf würde ich 
eher sagen, das nehme ich an, 

475
00:23:34,200 --> 00:23:36,280
wenn ich eben nicht die Zeit 
habe, wirklich einen ultra 

476
00:23:36,280 --> 00:23:39,440
ausführlichen Plan zu schreiben,
sondern er sagt Ja, Pass auf, 

477
00:23:39,520 --> 00:23:41,320
hier und da sind ein paar 
technische Kriterien, die ich 

478
00:23:41,320 --> 00:23:42,560
habe. 
Jetzt iterierst du da einfach 

479
00:23:42,560 --> 00:23:44,160
ganz stumm solange drüber, bis 
die da sind. 

480
00:23:44,400 --> 00:23:47,680
Und dann kann man das ja noch in
den Kontext setzen zu diesen 

481
00:23:47,680 --> 00:23:51,080
Orchestration Frameworks. 
Du hattest es gerade erwähnt am 

482
00:23:51,080 --> 00:23:53,800
Beispiel von Cursor, aber wir 
hatten ja in einer der letzten 

483
00:23:53,800 --> 00:23:57,960
News folgen auch dieses Gas Town
Projekt erwähnt und das ist 

484
00:23:57,960 --> 00:24:00,320
quasi eine. 
Paradisierung oder 

485
00:24:00,320 --> 00:24:04,800
Orchestrierung von ganz vielen 
dieser Agenten, die Stumpf eine 

486
00:24:04,800 --> 00:24:07,880
Aufgabe abarbeiten. 
Und dementsprechend würde ich 

487
00:24:07,880 --> 00:24:11,600
das jetzt nicht als entweder 
oder sehen, sondern die Ralf 

488
00:24:11,600 --> 00:24:16,200
Methode hat quasi diesen Loop, 
der durchläuft und am Ende habe 

489
00:24:16,200 --> 00:24:17,920
ich einen Orchestrater, der 
dann. 

490
00:24:18,320 --> 00:24:21,720
Einzelnen dieser Agenten jeweils
Aufgaben gibt, die diese in 

491
00:24:21,720 --> 00:24:25,040
diesem Loop abarbeiten. 
Und dazu gehört natürlich auch 

492
00:24:25,040 --> 00:24:27,480
irgendwie ein Task und State 
Management. 

493
00:24:27,480 --> 00:24:30,560
Da gibt es Open Source Projekte 
wie zum Beispiel Bets, was auch 

494
00:24:30,560 --> 00:24:35,920
bei Gas Town Anwendung findet, 
wo halt so in einer Datenbank 

495
00:24:36,320 --> 00:24:39,760
der aktuelle Zustand des 
Projektes und die Aufgaben 

496
00:24:39,760 --> 00:24:42,720
gehalten werden auf die dann 
letzten Endes diese 

497
00:24:42,720 --> 00:24:45,280
verschiedenen Agenten zugreifen 
können. 

498
00:24:45,680 --> 00:24:48,720
Für vieles reicht diese reif 
Methode, weil ich ja häufig gar 

499
00:24:48,720 --> 00:24:51,840
nicht so ganz große, sehr 
komplexe Aufgaben habe. 

500
00:24:52,240 --> 00:24:56,240
Aber wenn ich ein sehr komplexes
Projekt habe mit ganz vielen 

501
00:24:56,240 --> 00:24:59,440
verschiedenen Aufgaben, die auch
unabhängig voneinander sind und 

502
00:24:59,440 --> 00:25:02,800
wo verschiedene Agenten dann 
auch parallel arbeiten an 

503
00:25:02,800 --> 00:25:06,000
unterschiedlichen Aufgaben, 
brauche ich am Ende so einen 

504
00:25:06,000 --> 00:25:10,480
Orchestraitor, der das Ganze 
entsprechend komplex macht, aber

505
00:25:10,480 --> 00:25:13,680
mir dann auch die Möglichkeit 
gibt, das Ganze zu skalieren, 

506
00:25:13,680 --> 00:25:15,560
weil am Ende ist natürlich diese
gerne. 

507
00:25:15,640 --> 00:25:20,640
Erst Methode, irgendwie gefühlt 
Single Threaddit und ich gebe 

508
00:25:20,640 --> 00:25:22,920
eine Aufgabe und weiß wann diese
erledigt ist. 

509
00:25:22,920 --> 00:25:27,200
Aber sobald ich halt eine große 
Anzahl von Aufgaben habe und 

510
00:25:27,200 --> 00:25:30,960
diese parallelisieren möchte, 
brauche ich dann auch ein 

511
00:25:30,960 --> 00:25:32,960
entsprechendes Orchestrater 
Framework. 

512
00:25:33,120 --> 00:25:34,800
Ja, wenn ihr jetzt Lust habt, 
auch mal irgendwie Ralf 

513
00:25:34,800 --> 00:25:37,040
auszuprobieren, dann lasst doch 
mal gucken, wie man das jetzt 

514
00:25:37,040 --> 00:25:39,040
irgendwie mit minimalstem 
Aufwand mal irgendwie machen 

515
00:25:39,040 --> 00:25:41,080
kann, weil die Ergebnisse sind 
schon irgendwie ganz lustig und 

516
00:25:41,080 --> 00:25:42,720
ist schon auch irgendwie 
beeindruckend, wenn man das auf 

517
00:25:42,720 --> 00:25:45,600
der eigenen Maschine sieht. 
Und das kann man eigentlich 

518
00:25:45,600 --> 00:25:48,240
relativ leicht ausprobieren, 
wenn man irgendwie einen CLI 

519
00:25:48,240 --> 00:25:51,360
getriebenen Coding Agenten hat 
wie Cloud, wie Kodex oder 

520
00:25:51,520 --> 00:25:53,800
Germany CLI oder Github CLI. 
Was auch immer. 

521
00:25:53,800 --> 00:25:56,960
Da kann ich nämlich einfach mal 
wirklich hingehen und auf meine 

522
00:25:57,000 --> 00:25:58,880
meine Kommandozeile aufbauen, 
wirklich einfach eine while 

523
00:25:58,960 --> 00:26:01,960
Schleife bauen, also wirklich 
while gar nichts, also eine 

524
00:26:01,960 --> 00:26:04,760
Endlosschleife und dann hole ich
mir einfach irgendwie meinen 

525
00:26:04,760 --> 00:26:07,840
prompt den ich in Textdatei 
geschrieben habe und Pipe den in

526
00:26:07,840 --> 00:26:11,520
meinen Coding Agenten rein, das 
ist jetzt so die allereinfachste

527
00:26:11,520 --> 00:26:13,320
Geschichte, da muss ich dann 
natürlich irgendwann auch mal 

528
00:26:13,320 --> 00:26:15,320
abbrechen und. 
Jetzt gibt es aber auch schon 

529
00:26:15,320 --> 00:26:18,080
die ersten Coding Agenten, die 
da wirklich ein Plugin für 

530
00:26:18,080 --> 00:26:20,000
haben. 
Es gibt zum Beispiel für Claude 

531
00:26:20,000 --> 00:26:22,760
God schon einen Ralf Plugin, 
verlinken wir auch mal irgendwie

532
00:26:22,760 --> 00:26:25,320
in den Shownotes und da kann ich
dann natürlich auch schon so ein

533
00:26:25,320 --> 00:26:27,960
bisschen detaillierter Sachen 
mitgeben. 

534
00:26:27,960 --> 00:26:30,080
Also ich kann damit, ich könnte 
wirklich genau sagen, Pass 

535
00:26:30,320 --> 00:26:33,840
aufrufe dieses Plugin auf und 
dann kann ich über Parameter 

536
00:26:33,840 --> 00:26:37,400
mitgeben in welchem 
Zugriffsrechte Modus das Ding 

537
00:26:37,400 --> 00:26:39,240
eigentlich laufen soll, also 
dass ich zum Beispiel Änderungen

538
00:26:39,240 --> 00:26:40,960
an Dateien automatisch 
akzeptiere. 

539
00:26:41,440 --> 00:26:45,160
Änderungen oder Aufführungen von
noch nicht approvten MCP Tools, 

540
00:26:45,160 --> 00:26:48,480
aber vielleicht selber noch mal 
entscheiden möchte und dann kann

541
00:26:48,480 --> 00:26:52,120
ich ihm eine Textdatei mitgeben,
indem er den Fortschritt quasi 

542
00:26:52,120 --> 00:26:53,960
tracken kann. 
Das ist das, was wir vorhin 

543
00:26:53,960 --> 00:26:56,160
erwähnt haben, so diese 
Zwischenergebnisse von den 

544
00:26:56,160 --> 00:26:59,160
Iterationen und gibt dann einen 
prompt mit, der schon so einem 

545
00:26:59,160 --> 00:27:02,320
bestimmten Format folgt, wo ich 
einfach den Task definiere, was 

546
00:27:02,320 --> 00:27:05,200
zu tun sein soll, den Branch, 
auf dem er arbeiten soll, die 

547
00:27:05,200 --> 00:27:08,160
maximalen Iterationen, die 
durchgegangen werden soll, 

548
00:27:08,800 --> 00:27:11,400
success Kriterien. 
Die muss ich dann auch nicht in 

549
00:27:11,400 --> 00:27:13,240
irgendwelchen Skripten 
ausarbeiten, sondern da kann ich

550
00:27:13,240 --> 00:27:16,560
einfach irgendwie sagen, keine 
npm Run Tests muss erfolgreich 

551
00:27:16,560 --> 00:27:20,400
mit einem Code 0 aufhören und 
sowas kann ein paar Sachen 

552
00:27:20,400 --> 00:27:21,760
haben, die ich auf jeden Fall 
machen will. 

553
00:27:21,920 --> 00:27:25,680
Kann ein paar Dinge per Hand 
quasi reinschreiben, die das 

554
00:27:25,680 --> 00:27:29,440
Modell in Betracht ziehen soll, 
wenn es die nächste Loop 

555
00:27:29,440 --> 00:27:31,560
aufruft, also woran es auch 
vielleicht erkennen soll, dass 

556
00:27:31,560 --> 00:27:34,040
es vielleicht keine gute Idee 
ist weiterzumachen und was so 

557
00:27:34,040 --> 00:27:36,920
ein bisschen der Output ist, das
heißt, da kann man dann schon 

558
00:27:36,920 --> 00:27:39,840
relativ suffisticated reingehen,
wenn man diese Plugins benutzt. 

559
00:27:40,560 --> 00:27:42,600
Aber am Anfang kann man es 
einfach mal ausprobieren, indem 

560
00:27:42,600 --> 00:27:44,880
man einfach eine while Schleife 
baut und sich mal ein bisschen 

561
00:27:44,880 --> 00:27:47,320
mit einem cleveren prompt 
anguckt, was da rauskommt. 

562
00:27:47,320 --> 00:27:49,280
Das ist eigentlich auch. 
Schon ganz witzig, ja. 

563
00:27:49,280 --> 00:27:51,880
Und weil das jetzt vielleicht in
so einem Podcast gar nicht so 

564
00:27:51,880 --> 00:27:55,840
greifbar oder gut vorstellbar 
ist, haben wir auch noch einen 

565
00:27:55,840 --> 00:27:59,440
passenden Blog, Post und der 
Blog Post kommt von unseren 

566
00:27:59,440 --> 00:28:02,080
früheren Kollegen Darius. 
Schöne Grüße an dieser Stelle 

567
00:28:02,400 --> 00:28:07,520
den Blog Post zur Ralf William 
Methode, den Darius geschrieben 

568
00:28:07,520 --> 00:28:10,440
hat, verlinken wir in den Show 
Notes, schaut ihn euch mal an. 

569
00:28:10,520 --> 00:28:12,600
Können dort sind auch die 
entsprechenden Codebeispiele 

570
00:28:12,600 --> 00:28:16,560
drin, die ihr entsprechend 
nachbauen könnt, um das ganze 

571
00:28:16,560 --> 00:28:19,760
Mal selber auszuprobieren. 
So, dann fassen wir das ganze 

572
00:28:19,760 --> 00:28:21,440
Mal zusammen. 
Ich möchte aber auf jeden Fall 

573
00:28:21,440 --> 00:28:23,760
auf eine Sache auch noch ein 
Augenmerk legen, das ist 

574
00:28:23,760 --> 00:28:25,800
natürlich auch so ein bisschen 
dieser Kostenfaktor, weil wie 

575
00:28:25,800 --> 00:28:27,600
man sich ja bestimmt denken 
kann, wenn man jetzt die Folge 

576
00:28:27,600 --> 00:28:31,040
bis hierhin gehört hat, ist, 
dass so ein KI Agent, der ist ja

577
00:28:31,040 --> 00:28:34,440
schon nicht wahnsinnig günstig 
oder kann, da können die Kosten 

578
00:28:34,440 --> 00:28:36,600
bei langen Sessions ja auf jeden
Fall auch in die Höhe getrieben 

579
00:28:36,600 --> 00:28:38,760
werden. 
Und wenn ich jetzt so einen KI 

580
00:28:38,760 --> 00:28:40,880
Agenten immer und immer und 
immer wieder abfeuer, dann ist 

581
00:28:40,880 --> 00:28:44,560
ja glaube ich völlig klar, dass 
das auch einiges an Geld kostet.

582
00:28:44,960 --> 00:28:47,840
Da sind natürlich zum einen so 
Computerkosten mit dabei, also 

583
00:28:47,840 --> 00:28:49,640
wenn ich das Ding nicht mal nur 
auf meiner Maschine ist, sondern

584
00:28:49,640 --> 00:28:51,480
vielleicht sogar irgendwie auf 
einer remote Maschine laufen 

585
00:28:51,480 --> 00:28:54,960
lasse, dann zahle ich da ja auch
oft pro Minute, wenn ich viele 

586
00:28:54,960 --> 00:28:58,320
Tool runs habe, die ganzen 
Tokens die ich, die ich für die 

587
00:28:58,320 --> 00:29:00,320
Verbrate wir haben da teilweise 
wirklich auch schon. 

588
00:29:00,960 --> 00:29:04,720
Beispiele gesehen, wo Kosten ja 
bis zu dreistellige Summen dann 

589
00:29:04,720 --> 00:29:06,320
halt irgendwie sind. 
Wenn ich das Ding einfach mal so

590
00:29:06,320 --> 00:29:08,880
im afk Modus über Nacht laufen 
lasse, das jetzt keine 

591
00:29:08,880 --> 00:29:12,640
Seltenheit und auch kosten, die 
dann oft ja vielleicht vergessen

592
00:29:12,640 --> 00:29:15,760
werden ist, dass das Ding ja ja 
Blödsinn voll auch irgendwelche 

593
00:29:15,920 --> 00:29:18,680
Schrott commits erzeugt. 
Merge Konflikte die ich danach 

594
00:29:18,680 --> 00:29:20,880
irgendwie wieder aufarbeiten 
muss, das heißt ich habe auch 

595
00:29:20,880 --> 00:29:23,720
Engineering kosten, irgendeiner 
muss das Ding ja reviewen ich 

596
00:29:23,720 --> 00:29:25,680
muss danach vielleicht noch mal 
die wagen wenn ich merke, dass 

597
00:29:25,680 --> 00:29:27,840
es vielleicht in die falsche 
Richtung gegangen ist. 

598
00:29:28,320 --> 00:29:29,720
Vielleicht sind doch alle Tests 
grün. 

599
00:29:29,720 --> 00:29:31,600
Ich merke in meinen Tests aber 
irgendwas funktioniert nicht und

600
00:29:31,600 --> 00:29:33,840
ich drill dann noch mal rein, 
ich glaube das sind generelle 

601
00:29:33,840 --> 00:29:38,040
Kosten und Risiken bei relativ 
autonomer KI Steuerung, aber 

602
00:29:38,080 --> 00:29:40,400
wenn ich es wirklich mit dieser 
Holzhammer Methode Drive da 

603
00:29:40,400 --> 00:29:42,760
immer und immer wieder drauf 
gucken lasse, dann entsteht auch

604
00:29:42,760 --> 00:29:45,560
natürlich einer auf viel viel 
mehr commits, viel mehr Code, 

605
00:29:45,560 --> 00:29:48,000
vielleicht auch viele Änderungen
die in der nächsten Iteration 

606
00:29:48,000 --> 00:29:50,080
wieder zurückgenommen werden 
und. 

607
00:29:50,880 --> 00:29:52,760
Das ist natürlich auch nicht 
außer 8 zu lassen. 

608
00:29:52,760 --> 00:29:58,240
Also es ist auf keinen Fall was,
was jetzt in jede Codingumgebung

609
00:29:58,240 --> 00:30:01,440
quasi bei Default mit mit 
eingebaut werden sollte, sondern

610
00:30:01,440 --> 00:30:04,800
wäre eher ein Werkzeug, was man 
sehr bewusst einsetzt, wenn man 

611
00:30:04,800 --> 00:30:06,880
sagt, ich habe jetzt hier 
vielleicht gar nicht die Zeit 

612
00:30:06,880 --> 00:30:10,240
oder die Energie oder die 
Fähigkeiten auf andere Art und 

613
00:30:10,240 --> 00:30:12,560
Weise das Modell so in die 
richtige Richtung zu schubsen, 

614
00:30:12,720 --> 00:30:15,520
dann kann man sich überlegen, da
mit Ralf Mal drauf zu prügeln. 

615
00:30:16,120 --> 00:30:17,640
Muss ja aber auch Bewusstsein, 
dass das dann wahrscheinlich 

616
00:30:17,640 --> 00:30:20,400
auch sehr viele Tokens kostet. 
Ja, ich glaube, zusammenfassend 

617
00:30:20,400 --> 00:30:24,000
lässt sich sagen, wir gehen so 
ein bisschen Weg von KI, denkt 

618
00:30:24,000 --> 00:30:28,600
nach und entscheidet selber zu. 
Das System prüft und die KI 

619
00:30:28,600 --> 00:30:31,760
iteriert einfach nur, das ist 
ziemlich stumpf, aber in vielen 

620
00:30:31,760 --> 00:30:33,520
Fällen funktioniert das Halt 
einfach. 

621
00:30:34,040 --> 00:30:36,360
Die Frage ist, wie lange 
brauchen wir das noch? 

622
00:30:36,360 --> 00:30:40,720
Also werden die KI Modelle und 
auch die Coding Agenten bald so 

623
00:30:40,720 --> 00:30:43,520
gut, dass wir diese Schleife gar
nicht mehr brauchen oder diese 

624
00:30:43,520 --> 00:30:48,760
Schleife quasi implizit wird. 
Aber heute merken wir, dass wir 

625
00:30:48,760 --> 00:30:51,360
nicht immer die intelligenteste 
Lösung brauchen, sondern 

626
00:30:51,360 --> 00:30:54,960
manchmal auch einfach eine 
verlässliche Methode, um zu 

627
00:30:54,960 --> 00:30:58,720
prüfen, ob die Kriterien erfüllt
sind und dann das Ganze 

628
00:30:58,720 --> 00:31:01,600
erfolgreich abschließen können 
und damit mit den Tools, die wir

629
00:31:01,600 --> 00:31:06,160
heute schon haben vielleicht. 
Solche langlaufenden Aufgaben 

630
00:31:06,400 --> 00:31:08,880
erledigen können, ohne jetzt 
darauf zu warten, dass wir 

631
00:31:08,880 --> 00:31:12,080
irgendwelche noch besseren KI 
Agenten bekommen. 

632
00:31:12,240 --> 00:31:14,360
Am Ende muss man ja ganz klar 
sagen, dass es ja eigentlich nur

633
00:31:14,360 --> 00:31:17,600
ein Workaround ist für die 
mangelnde Fähigkeit der KI 

634
00:31:17,600 --> 00:31:20,120
Modelle im Moment an der 
richtigen Stelle zu erkennen, 

635
00:31:20,120 --> 00:31:21,920
dass sie wirklich fertig sind 
und. 

636
00:31:22,040 --> 00:31:23,560
Und wieso? 
Oft ja, kann ich mir fast schon 

637
00:31:23,560 --> 00:31:25,840
nicht vorstellen, dass wir in 
einem Jahr noch über Ralf Coding

638
00:31:25,840 --> 00:31:28,520
sprechen, weil wahrscheinlich 
die KI Provider nachgeliefert 

639
00:31:28,520 --> 00:31:30,160
haben. 
Im Moment funktioniert es aber 

640
00:31:30,160 --> 00:31:32,800
gut und wenn ihr jetzt im Moment
ein cooles Ergebnis braucht, 

641
00:31:32,800 --> 00:31:34,520
dann ist es auf jeden Fall ein 
cooles Tool, was man sich 

642
00:31:34,520 --> 00:31:36,480
angucken kann. 
Ich glaube, man kann sagen, 

643
00:31:36,640 --> 00:31:38,520
Ralf, das ist jetzt nicht 
wahnsinnig intelligent, das ist 

644
00:31:38,520 --> 00:31:40,800
ja nicht wahnsinnig clever, den 
Agenten einfach noch mal neu zu 

645
00:31:40,800 --> 00:31:43,040
starten, aber es funktioniert 
verlässlich. 

646
00:31:43,560 --> 00:31:46,400
Wenn eure Kriterien verlässlich 
sind, also wenn man ganz klar 

647
00:31:46,400 --> 00:31:50,160
gesagt hat, woran kann ich Ende 
oder Erfolg erkennen, 

648
00:31:50,240 --> 00:31:52,880
idealerweise natürlich in 
Software Development durch 

649
00:31:52,880 --> 00:31:55,520
unitests Ich kann das dann auch 
einfach durch Menschen 

650
00:31:55,520 --> 00:31:59,160
geschriebene Prompts ein Modell 
versuchen zu erklären und kriegt

651
00:31:59,160 --> 00:32:00,960
dann auf jeden Fall bessere 
Ergebnisse als bisher. 

652
00:32:01,200 --> 00:32:04,720
Und uns würde natürlich auch 
interessieren, ob ihr das Ganze 

653
00:32:04,720 --> 00:32:07,840
schon mal ausprobiert habt oder 
wenn ihr es jetzt nach dieser 

654
00:32:07,840 --> 00:32:09,680
Folge ausprobiert. 
Lasst uns gerne. 

655
00:32:10,160 --> 00:32:13,840
Hören wie euer Feedback ist, 
habt ihr Ralf getestet, 

656
00:32:13,840 --> 00:32:18,480
vielleicht in Human in The Loop 
Modus oder vielleicht sofort afk

657
00:32:18,640 --> 00:32:23,200
yolo und über Nacht würde uns 
interessieren, was ihr da an 

658
00:32:23,360 --> 00:32:27,080
Tokens verbrannt habt und wie 
eure Ergebnisse auch sind. 

659
00:32:27,080 --> 00:32:29,520
Also schreibt uns gerne eine E 
Mail oder lasst uns einen 

660
00:32:29,520 --> 00:32:31,920
Kommentar auf Spotify oder 
youtube da. 

661
00:32:32,320 --> 00:32:33,800
Uns wird natürlich auch 
interessieren, wie euch die 

662
00:32:33,800 --> 00:32:35,960
Folge gefallen hat. 
Lasst uns also gerne eine gute 

663
00:32:35,960 --> 00:32:39,120
Bewertung da oder Daumen oder 
Sternchen, je nachdem auf 

664
00:32:39,120 --> 00:32:41,800
welcher Podcast Platz. 
Form ihr uns hört und wir freuen

665
00:32:41,800 --> 00:32:43,600
uns natürlich auch immer sehr, 
wenn ihr uns einen Kaffee 

666
00:32:43,600 --> 00:32:46,160
ausgeben möchtet. 
Da findet ihr einen Link zu 

667
00:32:46,160 --> 00:32:49,360
Bimir Coffee auch in den 
Shownotes zusammen mit auch 

668
00:32:49,440 --> 00:32:51,680
allen Links, die wir jetzt hier 
in der Folge besprochen haben. 

669
00:32:51,920 --> 00:32:54,600
Und ansonsten freuen wir uns 
natürlich, wenn ihr auch nächste

670
00:32:54,600 --> 00:32:57,200
Woche wieder mit dabei seid. 
Der to do Developer Podcast 

671
00:32:57,200 --> 00:33:01,120
erscheinen, die jeden Montag 
abwechselnd in einer Themenfolge

672
00:33:01,120 --> 00:33:04,960
wie diese Woche und einer News 
Folge wie nächstes Mal. 

673
00:33:05,280 --> 00:33:06,960
Dann hören wir uns nächsten 
Montag wieder. 

674
00:33:06,960 --> 00:33:09,920
Macht's gut. 
Bis bald und schreibt ganz viel 

675
00:33:09,920 --> 00:33:11,360
Code, vielleicht sogar in der 
Loop. 

676
00:33:11,760 --> 00:33:12,320
Bis dann.