1
00:00:00,480 --> 00:00:02,960
Mit zunehmender 
Leistungsfähigkeit von Coding 

2
00:00:02,960 --> 00:00:05,440
Agenten hat sich ein Muster 
heraus kristallisiert. 

3
00:00:05,600 --> 00:00:08,160
Du beschreibst ein Ziel, du 
bekommst einen Codeblock zurück 

4
00:00:08,160 --> 00:00:12,240
und oft sieht er richtig aus, 
aber funktioniert nicht ganz, 

5
00:00:12,240 --> 00:00:15,600
der Code kompiliert nicht oder 
löst nur einen Teil des Problems

6
00:00:15,920 --> 00:00:18,720
oder ist einfach nicht genau so 
gebaut wie du ihn geschrieben 

7
00:00:18,720 --> 00:00:20,840
hättest. 
Das Problem ist hier ganz oft 

8
00:00:20,840 --> 00:00:23,120
nicht die Coding 
Leistungsfähigkeit der KI 

9
00:00:23,120 --> 00:00:27,440
Modelle, sondern dass wir sie 
mit zu wenig oder zu unpräzisen 

10
00:00:27,440 --> 00:00:29,520
Anweisungen und Kontext 
versorgen. 

11
00:00:29,760 --> 00:00:33,680
Wir müssen also an unserer 
Spezifikation arbeiten und genau

12
00:00:33,680 --> 00:00:36,640
hier kommt Spec driven 
Development ins Spiel. 

13
00:00:41,600 --> 00:00:48,480
Und damit herzlich Willkommen zu
Folge 137 this to do Developer 

14
00:00:48,480 --> 00:00:53,280
Podcast tatsächlich 137 und 
nicht 136, da wir nachher 

15
00:00:54,000 --> 00:00:57,400
gemerkt haben, dass wir die 
Folge 135 zweimal angekündigt 

16
00:00:57,400 --> 00:01:01,280
haben, sehen wir jetzt die 136 
in der Ankündigung und sind 

17
00:01:01,280 --> 00:01:05,760
sofort bei 137 wir haben. 
Uns ein einziges Mal verzählt in

18
00:01:05,760 --> 00:01:08,080
136 Folgen. 
Ich glaube, dass. 

19
00:01:08,800 --> 00:01:12,240
Verzeihen uns die Leute? 
Ja, aber trotzdem vielen Dank 

20
00:01:12,240 --> 00:01:16,280
für die Hinweise an diejenigen, 
die uns darauf hingewiesen haben

21
00:01:16,280 --> 00:01:18,720
und wir das direkt am Montag 
zumindest in der Podcast 

22
00:01:18,720 --> 00:01:20,800
Beschreibung korrigieren 
konnten. 

23
00:01:21,200 --> 00:01:23,680
Ja, der to do Developer Podcast 
ist. 

24
00:01:24,240 --> 00:01:26,560
Ein gemeinsames Projekt von 
Robin Manuel Thiel. 

25
00:01:26,560 --> 00:01:31,120
Er ist Director icloud bei Jtl 
Software und mir malte Lantin 

26
00:01:31,120 --> 00:01:34,040
ich bin Solutions Engineer bei 
github und wir machen den 

27
00:01:34,040 --> 00:01:37,480
Podcast privat und in unserer 
Freizeit und unterhalten uns 

28
00:01:37,480 --> 00:01:41,360
hier über diverse Themen aus dem
Developer Alltag, immer 

29
00:01:41,360 --> 00:01:44,640
abwechselnd mit einer 
Themenfolge wie heute und einer 

30
00:01:44,800 --> 00:01:48,720
News Folge, die jeweils am 
Montag erscheint. 

31
00:01:49,120 --> 00:01:51,320
Und ihr habt uns nicht nur 
Bescheid gesagt, dass wir uns 

32
00:01:51,320 --> 00:01:53,600
verzählt haben. 
Sondern ihr habt uns auch Kaffee

33
00:01:53,600 --> 00:01:55,200
ausgegeben. 
Einen davon habe ich gleich 

34
00:01:55,200 --> 00:01:58,280
heute Morgen am Bahnhof 
eingelöst. 

35
00:01:58,280 --> 00:02:01,920
Wir haben 5 Kaffee von Me and 
Company, wer auch immer das ist,

36
00:02:01,920 --> 00:02:05,280
bekommen ganz herzlichen Dank. 
Vielen Dank dafür. 

37
00:02:05,920 --> 00:02:08,160
Und damit steigen wir auch 
direkt ins Thema ein. 

38
00:02:08,160 --> 00:02:11,560
Dieses Mal wie gesagt wieder 
eine Themenfolge und wir reden 

39
00:02:11,560 --> 00:02:16,600
heute über Specdriven 
Development, vielleicht ganz 

40
00:02:16,600 --> 00:02:19,360
kurz zum Einstieg. 
Was verbirgt sich dahinter? 

41
00:02:19,840 --> 00:02:23,280
Ja, kurz gesagt, bevor wir 
anfangen zu coden oder auch in 

42
00:02:23,280 --> 00:02:26,440
der KI zu coden zu lassen, 
setzen wir uns im Specdriven 

43
00:02:26,440 --> 00:02:29,040
Development hin und arbeiten 
eine detaillierte. 

44
00:02:29,040 --> 00:02:32,840
Das ist wichtig Spezifikation 
aus, das müssen wir gar nicht 

45
00:02:32,840 --> 00:02:35,360
immer alles selber machen, 
dieses Ausarbeiten, das können 

46
00:02:35,360 --> 00:02:37,840
wir auch gemeinsam mit der KI 
oder mit dem Agenten machen, das

47
00:02:37,840 --> 00:02:40,000
kann auch teilweise richtig lang
werden, also das sind viele, 

48
00:02:40,000 --> 00:02:43,520
viele 100 Zeilen, meistens 
irgendwie markdown Code. 

49
00:02:43,960 --> 00:02:46,240
Und in dieser Spezifikation 
beschreiben wir eben nicht nur 

50
00:02:46,240 --> 00:02:48,560
genau, was wir haben wollen, 
sondern auch, warum wir es haben

51
00:02:48,560 --> 00:02:51,760
wollen, unter welchen Umständen 
das wie funktionieren soll. 

52
00:02:51,760 --> 00:02:54,480
Edge Cases und all die Sachen, 
die man ja auch sonst irgendwie 

53
00:02:54,720 --> 00:02:57,800
bespricht, vielleicht mit einem 
menschlichen Developer, und das 

54
00:02:57,800 --> 00:03:00,640
lassen wir uns dann aber auch 
wieder challengen ebenfalls von 

55
00:03:00,640 --> 00:03:03,360
der KI, vor allem auf 
Vollständigkeit und auf 

56
00:03:03,360 --> 00:03:06,320
Nachvollziehbarkeit und 
Konsistenz und. 

57
00:03:06,880 --> 00:03:10,480
Und dann coden wir aber quasi, 
indem wir das Ganze erst 

58
00:03:10,640 --> 00:03:13,480
ausarbeiten und dann der KI 
mitgeben in den Kontext. 

59
00:03:13,480 --> 00:03:15,200
Wir schreiben also eigentlich 
eine sehr detaillierte 

60
00:03:15,200 --> 00:03:18,520
Anleitung, gar nicht unbedingt, 
wie jetzt genau gecoded werden 

61
00:03:18,520 --> 00:03:22,520
soll, sondern eher was und warum
es gecoded werden soll und geben

62
00:03:22,520 --> 00:03:24,600
das in die KI mit rein. 
Da gibt es verschiedene Tools 

63
00:03:24,600 --> 00:03:26,680
und Framework Streams auch dabei
helfen eben diese Anleitung 

64
00:03:26,680 --> 00:03:30,400
diese Spezifikation zu 
erstellen, aber das. 

65
00:03:30,640 --> 00:03:33,680
So ganz neu ist es eigentlich 
nicht. 

66
00:03:33,680 --> 00:03:37,960
Es gab in der Geschichte immer 
mal wieder und also sowas, dass 

67
00:03:37,960 --> 00:03:39,600
man sich irgendwie erst 
hingesetzt hat und sehr, sehr 

68
00:03:39,600 --> 00:03:41,680
viel spezifiziert hat, und dann 
ist das irgendwie wieder 

69
00:03:41,680 --> 00:03:44,080
verschwunden und wurde abgelöst 
von anderen Sachen und dann kam 

70
00:03:44,080 --> 00:03:46,880
es wieder in anderer Form. 
Malte, du hast da mal ein 

71
00:03:46,880 --> 00:03:49,160
bisschen recherchiert und hast 
eine kleine Geschichtsstunde für

72
00:03:49,160 --> 00:03:52,080
uns. 
Ja, tatsächlich war es nie 

73
00:03:52,080 --> 00:03:53,760
wirklich weg. 
Aber es ist so ein bisschen ein 

74
00:03:53,760 --> 00:03:55,920
Pendel, was hin und Her 
schwingt. 

75
00:03:56,880 --> 00:04:00,400
Zwischen mehr Struktur und 
vielleicht ein bisschen mehr 

76
00:04:00,400 --> 00:04:03,080
Chaos, ein bisschen mehr 
Flexibilität oder ein bisschen 

77
00:04:03,080 --> 00:04:06,880
mehr Planung. 
Und tatsächlich haben wir heute 

78
00:04:06,880 --> 00:04:09,440
eigentlich eine Beschleunigung 
dieser Dynamik, wir haben es 

79
00:04:09,440 --> 00:04:12,000
über die letzten Jahre gesehen, 
es kamen immer mehr KI 

80
00:04:12,000 --> 00:04:15,440
Development Tools raus und mit 
diesem Coding Agenten, Du 

81
00:04:15,440 --> 00:04:18,560
hattest es vorhin gesagt, egal 
ob es jetzt irgendwie cursor, 

82
00:04:18,560 --> 00:04:20,480
co, Pilot Devin etc. 
Ist. 

83
00:04:20,959 --> 00:04:24,720
Ist natürlich dieser Begriff des
Vibe Codings so ein bisschen en 

84
00:04:24,720 --> 00:04:27,040
vogue geworden. 
Immer mehr Leute beschäftigen 

85
00:04:27,040 --> 00:04:30,840
sich mit der Softwareentwicklung
über einfaches Prompting, und da

86
00:04:30,840 --> 00:04:34,720
ist natürlich das ganze Thema, 
das ganze Thema Planung, so ein 

87
00:04:34,720 --> 00:04:37,840
bisschen ins Hintertreffen 
geraten und man hat da mehr, 

88
00:04:37,840 --> 00:04:41,920
vielleicht fokussiert auf 
Geschwindigkeit und Dynamik und 

89
00:04:41,920 --> 00:04:45,200
weniger irgendwie Intention und 
Planung und. 

90
00:04:45,720 --> 00:04:49,440
Wirklich das Ziel, wirklich 
langfristig stabile Software zu 

91
00:04:49,440 --> 00:04:52,080
bauen und so ein bisschen das 
Gefühl entsteht, dass wir uns 

92
00:04:52,080 --> 00:04:55,760
jetzt so ein bisschen in der 
Mitte einpendeln mit Specdriven 

93
00:04:55,760 --> 00:04:58,000
Development. 
Wie genau das funktioniert, das 

94
00:04:58,000 --> 00:05:02,120
besprechen wir ja gleich noch 
mal im Detail, aber vielleicht 

95
00:05:02,120 --> 00:05:05,360
noch mal ganz kurz für 
diejenigen von euch, die sich 

96
00:05:05,360 --> 00:05:07,680
nicht so mit der 
Softwareentwicklungsmethodik 

97
00:05:07,680 --> 00:05:11,080
über die letzten Jahrzehnte 
beschäftigt haben, fassen wir 

98
00:05:11,080 --> 00:05:13,280
noch mal so ein bisschen die 
Historie zusammen. 

99
00:05:14,160 --> 00:05:18,240
Und zwar kennen viele von euch 
wahrscheinlich das Wasserfall 

100
00:05:18,240 --> 00:05:20,840
Modell. 
Man hat in den 70er Jahren, als 

101
00:05:20,840 --> 00:05:24,080
das Thema Softwareentwicklung 
immer populärer wurde und immer 

102
00:05:24,080 --> 00:05:26,400
mehr Leute sich mit dem Thema 
beschäftigt haben, sich 

103
00:05:26,400 --> 00:05:28,400
erstmalig Gedanken darüber 
gemacht, wie kann man 

104
00:05:28,480 --> 00:05:31,840
softwareentwicklungsprozesse 
gerade für komplexe große 

105
00:05:31,840 --> 00:05:35,280
Softwaresysteme managen und da 
ist dieses. 

106
00:05:35,920 --> 00:05:40,000
Sehr bekannte Wasserfall Modell 
rausgefallen, wo wir tatsächlich

107
00:05:40,000 --> 00:05:43,120
erst am Anfang uns mit den 
Anforderungen beschäftigen, dann

108
00:05:43,120 --> 00:05:45,520
designen wir das System, dann 
implementieren wir das System 

109
00:05:45,520 --> 00:05:48,560
und am Ende schauen wir, ob 
entsprechend die Implementierung

110
00:05:48,720 --> 00:05:50,960
zu unseren Anforderungen passt. 
Und dann geht es in einen 

111
00:05:50,960 --> 00:05:53,120
Wartungsmodus, das heißt, wir 
haben wirklich wieso ein 

112
00:05:53,120 --> 00:05:56,720
Wasserfall, es gibt dort keine 
Iteration, wie wir es vielleicht

113
00:05:56,720 --> 00:05:58,080
in der modernen 
Softwareentwicklung haben, 

114
00:05:58,080 --> 00:06:00,720
sondern wir fangen mit einer 
Planung an, am Ende haben wir 

115
00:06:01,160 --> 00:06:04,240
ein fertiges Stück Software und 
das ist so ein bisschen auch so.

116
00:06:04,720 --> 00:06:07,440
In der Ausbildung zum 
Negativbeispiel für einen 

117
00:06:07,440 --> 00:06:10,240
schlechten Prozess verkommen, 
obwohl es eigentlich sehr gut 

118
00:06:10,240 --> 00:06:13,680
gedacht war, weil wir hier 
natürlich wenig Möglichkeiten 

119
00:06:13,680 --> 00:06:15,840
haben, Nachzusteuern. 
Das heißt, man beschäftigt sich 

120
00:06:15,840 --> 00:06:20,280
sehr lange damit, diese 
Dokumentation am Anfang über die

121
00:06:20,280 --> 00:06:22,560
Requirements zu erstellen. 
Man hat irgendeinen 

122
00:06:22,800 --> 00:06:25,720
Pflichtenheft, man hat ein 
Lastenheft und geht erst, wenn 

123
00:06:25,720 --> 00:06:29,160
das alles irgendwie vollständig 
und abgenommen ist, in die 

124
00:06:29,160 --> 00:06:32,240
Implementierung und kann dann 
natürlich sehr gut 

125
00:06:32,240 --> 00:06:36,640
nachvollziehen, warum man etwas.
Etwas gebaut hat, wie man etwas 

126
00:06:36,640 --> 00:06:40,960
gebaut hat und hat natürlich 
damit auch die Möglichkeit, an 

127
00:06:40,960 --> 00:06:44,960
Projekten, die sehr groß sind 
und vielleicht an sehr strikte 

128
00:06:44,960 --> 00:06:47,680
Anforderungen gebunden sind. 
Gerade wenn es jetzt irgendwie 

129
00:06:47,680 --> 00:06:51,880
um Militär und Raumfahrttechnik 
geht, wo ja die 

130
00:06:51,880 --> 00:06:54,640
Softwareentwicklung zunächst 
groß geworden ist. 

131
00:06:55,440 --> 00:06:58,080
Da hat man natürlich viele 
Vorteile, weil man da natürlich 

132
00:06:58,080 --> 00:07:01,680
lange planungszeiträume hat, 
aber auf der anderen Seite 

133
00:07:01,680 --> 00:07:05,480
können wir natürlich Fehler oder
neue Entwicklungen relativ 

134
00:07:05,480 --> 00:07:10,880
schnell relativ schlecht in die 
Implementierung reinbringen. 

135
00:07:12,160 --> 00:07:14,040
Ja, eigentlich ist es ein 
bisschen endlich. 

136
00:07:14,040 --> 00:07:16,600
Jetzt werden wir gleich gleich 
sehen zu dem, was suspectrim 

137
00:07:16,600 --> 00:07:18,080
Development macht. 
Das ist gar nicht gar nicht so 

138
00:07:18,080 --> 00:07:20,160
weit weg davon, früher hast du 
halt irgendwie einen Wasserfall 

139
00:07:20,160 --> 00:07:21,440
so. 
Ja, auch sehr viele 

140
00:07:21,440 --> 00:07:23,400
Dokumentationen geschrieben, 
also hast ein Pflichtenheft 

141
00:07:23,400 --> 00:07:26,920
erstellt, ein Lastenheft 
erstellt und dann eigentlich nur

142
00:07:26,920 --> 00:07:31,120
noch so ein bisschen die die 
Spezifikation runter gecoded und

143
00:07:31,120 --> 00:07:34,480
es ist halt auch irgendwie 
einfacher ein fertiges Dokument 

144
00:07:35,120 --> 00:07:38,520
zu implementieren, also auch 
irgendwie für jemanden, der 

145
00:07:38,520 --> 00:07:39,600
vielleicht gar nicht so tief 
technisch ist. 

146
00:07:39,600 --> 00:07:41,840
Es ist natürlich einfacher, auch
dieses Dokument dann zu 

147
00:07:41,840 --> 00:07:44,640
schreiben, anstatt den Code 
nachher zu coden. 

148
00:07:44,640 --> 00:07:47,360
Klar, die meisten die hier den 
Podcast zuhören, die Coden 

149
00:07:47,360 --> 00:07:49,680
wahrscheinlich lieber, aber 
einfacher ist es ja nicht 

150
00:07:49,680 --> 00:07:52,440
unbedingt und. 
Und das Ganze kam auch so ein 

151
00:07:52,440 --> 00:07:55,120
bisschen aus einer Zeit, wo es 
so ganz klare verschiedene 

152
00:07:55,120 --> 00:07:56,920
Rollen in der 
Softwareentwicklung gab, wo man 

153
00:07:56,920 --> 00:07:59,600
sich auch gegenseitig vielleicht
gar nicht so viel vertraut hat, 

154
00:07:59,600 --> 00:08:02,560
wo wirklich, ganz klar, wir 
müssen hier alles ganz genau 

155
00:08:02,560 --> 00:08:05,280
spezifizieren und 
runterschreiben und dann geben 

156
00:08:05,280 --> 00:08:08,880
wir das ab woanders hin, in so 
eine Art Blackbox und kriegen 

157
00:08:08,880 --> 00:08:11,240
dann irgendwann ein Ergebnis und
können eigentlich nur hoffen, 

158
00:08:11,240 --> 00:08:13,440
dass das sehr, sehr nah an 
dieser Spezifikation ist. 

159
00:08:13,760 --> 00:08:17,200
Und deswegen. 
Investieren wir auch so viel 

160
00:08:17,200 --> 00:08:19,400
Energie, diese Spezifikation zu 
schreiben? 

161
00:08:19,400 --> 00:08:21,320
Diese Pflichtenhefte wurden ja 
sehr, sehr lang und sehr, sehr 

162
00:08:21,320 --> 00:08:25,360
groß dann irgendwann, aber 
dieses ich vertraue gar nicht 

163
00:08:25,360 --> 00:08:28,680
genau dem Ergebnis und ich gebe 
das in so eine Blackbox rein, 

164
00:08:28,680 --> 00:08:31,120
das sind ja 2 Dinge, die gar 
nicht so weit weg sind vom Vibe 

165
00:08:31,120 --> 00:08:33,520
Coding, wo ich dann irgendwas 
einem KI Modell gebe, was dann 

166
00:08:33,520 --> 00:08:36,799
einen Code ausspuckt oder wo ich
dann halt auch dieses Tiefe 

167
00:08:36,799 --> 00:08:39,320
Vertrauen, ob das jetzt wirklich
so ist wie ich das haben will ja

168
00:08:39,320 --> 00:08:41,320
auch nicht da ist. 
Ja, als du das gerade 

169
00:08:41,320 --> 00:08:43,559
beschrieben hast, hatte ich 
tatsächlich auch gedacht, das 

170
00:08:43,559 --> 00:08:47,040
hört sich eigentlich genauso an 
wie heute mit KI Agenten 

171
00:08:47,040 --> 00:08:49,600
gemeinsam entwickelt wird. 
Wir machen uns Gedanken darüber,

172
00:08:49,600 --> 00:08:54,160
was wir implementieren wollen 
und der KI Agent baut das dann 

173
00:08:54,400 --> 00:08:56,840
für mich und man hat so ein 
bisschen immer darüber 

174
00:08:56,840 --> 00:08:59,240
gesprochen, gerade in diesen 
traditionellen 

175
00:08:59,240 --> 00:09:01,160
Softwareentwicklungsmodellen, 
dass man dann irgendwie so ein 

176
00:09:01,160 --> 00:09:03,280
Anforderungsdokument irgendwann 
Zaun wirft zu einem 

177
00:09:03,280 --> 00:09:05,760
Entwicklungsteam und irgendwann 
kommt dann die fertige Software 

178
00:09:05,760 --> 00:09:08,440
zurück. 
Und das Ganze hat sich natürlich

179
00:09:08,440 --> 00:09:10,000
im Laufe der Zeit 
weiterentwickelt. 

180
00:09:10,000 --> 00:09:13,200
In Deutschland wird dann das v 
Modell entwickelt, was quasi 

181
00:09:13,200 --> 00:09:18,280
dieser sehr linearen Abfolge 
noch einen zweiten Ast 

182
00:09:18,280 --> 00:09:21,000
hinzugefügt hat, das heißt, wir 
haben auf der einen Seite die 

183
00:09:21,000 --> 00:09:23,760
eine Seite des Vs, wo wir 
runtergehen von der 

184
00:09:23,760 --> 00:09:27,120
Spezifikation bis hin am Ende 
zur Implementierung und dann der

185
00:09:27,120 --> 00:09:30,640
andere Ast sind entsprechend die
Validierung. 

186
00:09:31,760 --> 00:09:34,800
Punkte in der Implementierung, 
das heißt, Wir haben auf der 

187
00:09:34,800 --> 00:09:39,840
einen Seite unsere User Stories,
die am Ende von Usern auch 

188
00:09:39,840 --> 00:09:42,000
abgenommen werden, wenn die 
Software fertig ist. 

189
00:09:42,000 --> 00:09:47,200
Wir haben unsere Code Ebene, die
am besten durch Tests abgedeckt 

190
00:09:47,200 --> 00:09:50,800
wird und wir haben natürlich 
diese verschiedenen Module, in 

191
00:09:50,800 --> 00:09:52,720
die wir runtergebrochen haben, 
die am Ende durch 

192
00:09:52,720 --> 00:09:56,480
Integrationstests. 
Geprüft werden, das heißt, alle 

193
00:09:56,480 --> 00:10:00,400
diese Dinge, die wir quasi sehr 
linear aufgebaut haben, werden 

194
00:10:00,400 --> 00:10:03,360
auf der anderen Seite jeweils 
validiert. 

195
00:10:03,440 --> 00:10:06,800
Und das sind ja durchaus alles 
Patterns, die man auch heute in 

196
00:10:06,800 --> 00:10:11,400
der Softwareentwicklung. 
Immer noch sehr stark beherzigt,

197
00:10:11,400 --> 00:10:14,080
egal ob man jetzt in so einem 
sehr strikten Modell ist und 

198
00:10:14,080 --> 00:10:17,200
ganz viele Unternehmen sind noch
in einer Welt, wo man 

199
00:10:17,200 --> 00:10:20,680
tatsächlich sich noch an diesem 
v Modell orientiert, weil man 

200
00:10:20,680 --> 00:10:25,600
dort immer noch sehr klassische 
Entwicklungsprozesse hat. 

201
00:10:25,600 --> 00:10:29,160
Auch größere Projekte baut, weil
man zum Beispiel in der 

202
00:10:29,160 --> 00:10:31,920
Automobilindustrie auf einen 
speziellen. 

203
00:10:32,320 --> 00:10:36,080
Tag hin arbeitet zu dem Halt das
Fahrzeug vom Band rollt und da 

204
00:10:36,080 --> 00:10:40,200
kann man jetzt nicht komplett 
komplett flexibel in so einem 

205
00:10:40,200 --> 00:10:43,280
agilen Modell arbeiten, sondern 
man hat tatsächlich ein festes 

206
00:10:43,280 --> 00:10:47,400
Enddatum zu dem Halt eine vorher
spezifizierte Anzahl von 

207
00:10:47,400 --> 00:10:51,360
Funktionalitäten validiert, 
geprüft, mit einem ganz hohen 

208
00:10:51,360 --> 00:10:54,160
Sicherheitsstandard verfügbar 
sein muss und dementsprechend 

209
00:10:54,240 --> 00:10:58,000
orientiert man sich immer noch 
heute ganz grob an diesem v 

210
00:10:58,000 --> 00:11:00,720
Modell in vielen Bereichen und 
da gibt es auch eine. 

211
00:11:01,120 --> 00:11:04,560
Iteration das sogenannte v 
Modell XT, was einem aber ein 

212
00:11:04,560 --> 00:11:08,080
bisschen mehr Flexibilität und 
auch Agilität in diesem Modell 

213
00:11:08,240 --> 00:11:09,680
einräumt. 
Ja, das wird immer so ein 

214
00:11:09,680 --> 00:11:11,160
bisschen belächelt. 
Es gibt dann irgendwie so auf 

215
00:11:11,160 --> 00:11:13,720
Konferenzen wird sich darüber 
lustig gemacht, wenn man da wird

216
00:11:13,720 --> 00:11:16,400
Wasserfall noch irgendwie so als
als so ein Urzeitding gemacht, 

217
00:11:16,400 --> 00:11:20,560
so du bist ein v Modell oder du 
entwickelst nicht agil oder 

218
00:11:20,560 --> 00:11:22,440
irgendwie sowas. 
Dabei hat das ja, wie du gerade 

219
00:11:22,440 --> 00:11:24,400
richtig sagst, auch immer mal 
wieder seine Berechtigung. 

220
00:11:24,400 --> 00:11:26,960
Es gibt ja durchaus Prozesse, 
keiner, wenn ich jetzt in der 

221
00:11:26,960 --> 00:11:30,040
Industriefertigung bin, da kann 
ich nicht agil entwickeln und 

222
00:11:30,040 --> 00:11:34,440
alle alle 3 Wochen irgendwie 
meine meine Fertigungsstraße 

223
00:11:34,440 --> 00:11:36,800
nochmal ändern oder anpassen, da
werden dann teilweise auch 

224
00:11:37,760 --> 00:11:41,040
Schablonen für Teile gegossen 
oder sowas, die dann einfach 

225
00:11:41,040 --> 00:11:43,200
nicht mehr veränderbar sind, da 
macht es ja durchaus auch Sinn 

226
00:11:43,360 --> 00:11:45,920
in diesen in diesen Schritten zu
arbeiten und wie groß die. 

227
00:11:46,400 --> 00:11:49,000
Wie lang ein so ein Wasserfall, 
wie lang ein so ein Zweig von so

228
00:11:49,000 --> 00:11:50,600
einem v Modell ist, das kann ja 
durchaus variieren. 

229
00:11:50,600 --> 00:11:53,400
Man kann ja auch so, gibt ja 
diese Wasserfallentwicklung auf,

230
00:11:53,400 --> 00:11:56,040
wo man trotzdem versucht so 
einen sprintigen Wasserfall oder

231
00:11:56,040 --> 00:11:57,680
sowas zu bauen. 
Also ich finde das immer, ich 

232
00:11:57,680 --> 00:11:59,600
finde es eigentlich so ein 
bisschen schade, dass das immer 

233
00:11:59,600 --> 00:12:02,120
so halt immer nur negativ 
gesehen und belichtet wird, 

234
00:12:02,120 --> 00:12:03,760
zumindest irgendwie so ein 
bisschen in meiner. 

235
00:12:04,160 --> 00:12:07,080
Wahrnehmung ja, und wie wichtig 
das ist, merkt man dann glaube 

236
00:12:07,080 --> 00:12:10,120
ich auch heute, dass man eine 
gewisse Struktur braucht. 

237
00:12:10,320 --> 00:12:12,920
Ich meine, da wo wir heute 
vielleicht irgendwie gelandet 

238
00:12:12,920 --> 00:12:16,320
sind mit vipe Coding, da sind 
wir natürlich auch hingekommen 

239
00:12:16,320 --> 00:12:19,520
über die ganzen agilen Methoden,
die wir über die letzten 

240
00:12:19,520 --> 00:12:24,520
Jahrzehnte immer mehr verbreitet
haben, egal, ob es jetzt 

241
00:12:24,520 --> 00:12:27,480
irgendwie. 
Scrum ist, ob Scanban ist 

242
00:12:27,480 --> 00:12:29,880
Extreme Programming. 
Das Ganze gibt es erst seit 

243
00:12:29,880 --> 00:12:34,320
Anfang der 2000 er Jahre und da 
war die Grundidee zu sagen okay 

244
00:12:34,320 --> 00:12:36,680
wir brauchen weniger Prozess, 
wir müssen uns mehr auf die 

245
00:12:36,680 --> 00:12:39,280
Menschen konzentrieren, wir 
müssen uns auf funktionierende 

246
00:12:39,280 --> 00:12:42,720
Software statt Dokumentation 
konzentrieren, wir brauchen eher

247
00:12:42,720 --> 00:12:46,000
regelmäßige Zeremonien, wo die 
Menschen zusammenkommen und sich

248
00:12:46,000 --> 00:12:49,040
über bestimmte Dinge abstimmen 
und einig sind, als dass wir 

249
00:12:49,040 --> 00:12:53,600
alles niederschreiben. 
Und das Ganze hat auch für viele

250
00:12:53,600 --> 00:12:56,160
Bereiche, ich glaube, gerade 
jetzt, wenn wir über die ganzen 

251
00:12:56,160 --> 00:12:58,360
Web und mobile Applikationen, 
die wir über die letzten 

252
00:12:58,360 --> 00:13:01,520
Jahrzehnte gesehen haben, sehr 
gut funktioniert, weil da kann 

253
00:13:01,520 --> 00:13:04,560
man natürlich sehr schnell 
iterieren, man kann sehr schnell

254
00:13:04,560 --> 00:13:10,080
neue Features schippen, man kann
sehr, wirklich tagesaktuell 

255
00:13:10,080 --> 00:13:13,160
quasi auf die Anforderungen der 
User reagieren und. 

256
00:13:13,520 --> 00:13:17,680
Und ich glaube, damit hatte das 
auch absolut und hat auch 

257
00:13:17,680 --> 00:13:22,320
weiterhin seine Berechtigung, 
dass man in vielen Bereichen so 

258
00:13:22,320 --> 00:13:27,360
agil arbeitet, sofern man das 
dann auch mit der mit den 

259
00:13:27,360 --> 00:13:31,120
nötigen Anforderungen auch an 
langfristige Zuverlässigkeit 

260
00:13:31,120 --> 00:13:32,880
verbindet. 
Ja, da ist dann ja auch dieses 

261
00:13:32,960 --> 00:13:36,720
agile Manifesto entstanden und 
diese ganzen Methoden sind da 

262
00:13:36,720 --> 00:13:40,280
irgendwie drumherum. 
Drum gesponnen worden. 

263
00:13:40,280 --> 00:13:42,360
Also jetzt gar nicht gesponnen 
im Sinne von die Spinnen, 

264
00:13:42,360 --> 00:13:47,360
sondern entstanden gewebt 
worden, dass man eben möglichst 

265
00:13:47,360 --> 00:13:51,120
viele Feedback Loops einbaut, 
möglichst oft auch alle 

266
00:13:51,120 --> 00:13:53,840
Stakeholder immer mal wieder an 
den Tisch holt und abholt, dass 

267
00:13:53,840 --> 00:13:57,120
es eigentlich auch ein Produkt 
hat, was konstant shippable ist.

268
00:13:57,120 --> 00:13:59,520
Da geht es wirklich darum, dass 
ich am Ende von einem Sprint, 

269
00:13:59,520 --> 00:14:02,000
zum Beispiel wenn ich jetzt in 
Scrum denke oder so was, halt 

270
00:14:02,000 --> 00:14:05,040
jederzeit was releasen kann in 
kleinen Iterationen. 

271
00:14:05,840 --> 00:14:08,160
Mir Feedback einholen kann und 
so weiter und da muss man sich 

272
00:14:08,160 --> 00:14:11,280
natürlich fragen, ob das was 
ist, was ich in so einer in so 

273
00:14:11,280 --> 00:14:15,840
einer Welt von von KI Agenten, 
ob ich das überhaupt möchte, 

274
00:14:15,840 --> 00:14:18,960
weil die ich denke mir immer so,
ja, das ist richtig, wenn man 

275
00:14:18,960 --> 00:14:22,480
mit Menschen arbeitet, aber 
vielleicht ist das ja genau die 

276
00:14:22,480 --> 00:14:24,520
Trennung, die ich habe, aber das
ist ja auch oft so die Frage, 

277
00:14:24,520 --> 00:14:27,000
irgendwie keine Ahnung, wenn wir
von KI genten ersetzt oder 

278
00:14:27,000 --> 00:14:30,680
programmieren wir Seite an Seite
an Seite mit ihnen oder gibt es 

279
00:14:30,680 --> 00:14:32,600
bestimmte Aufgaben, die wir 
denen geben, oder? 

280
00:14:33,040 --> 00:14:36,280
Und bei einem KI Agent ist es ja
genau das, was ich vermeiden 

281
00:14:36,280 --> 00:14:38,600
will ist, dass der mich 
eigentlich ständig wieder um 

282
00:14:38,600 --> 00:14:40,640
Feedback bittet und dass er mich
eigentlich ständig fragt, weil 

283
00:14:40,640 --> 00:14:43,720
der große Vorteil gegenüber 
einem Menschen, wenn ich mit 

284
00:14:43,720 --> 00:14:47,240
einer KI beite, der ist ja, dass
ich da 30 Stück von parallel im 

285
00:14:47,240 --> 00:14:50,960
Hintergrund laufen lassen kann 
und wenn die aber alle mit mir 

286
00:14:50,960 --> 00:14:54,000
ein Scrum Meeting machen wollen,
einmal einmal alle paar Stunden 

287
00:14:54,000 --> 00:14:57,280
oder sowas und alle morgens ein 
Stand up oder sowas und. 

288
00:14:57,640 --> 00:15:00,040
Dann bin ich dann natürlich sehr
mit beschäftigt und das ist auch

289
00:15:00,040 --> 00:15:01,840
so ein bisschen die Gefahr. 
Dann die Menschen sehen, dass 

290
00:15:01,840 --> 00:15:04,000
ich eigentlich nur noch in so 
einen KI orchestraitor oder 

291
00:15:04,000 --> 00:15:08,000
sowas verfalle, weil ich ja 
vielleicht da genau sagen will, 

292
00:15:08,000 --> 00:15:09,320
ich möchte den Task, den du 
arbeitest. 

293
00:15:09,320 --> 00:15:11,760
Das ist ja auch dann kein ganzes
Projekt, was über Monate geht, 

294
00:15:12,080 --> 00:15:15,200
aber die Sachen halt ganz klar 
einmal spezifizieren. 

295
00:15:15,200 --> 00:15:18,000
Wir klären jetzt am Anfang 
einmal alle Fragen, die du hast 

296
00:15:18,160 --> 00:15:20,120
und dann rennst du bitte los und
programmierst so lange bis das 

297
00:15:20,120 --> 00:15:21,720
Ding fertig ist. 
Und zum Beispiel würde ich mit 

298
00:15:21,720 --> 00:15:23,280
einem Menschen ja irgendwie 
anders machen. 

299
00:15:24,160 --> 00:15:26,240
Und das ist dann vielleicht 
genau der Unterschied, dass 

300
00:15:26,240 --> 00:15:30,240
diese diese agile Revolution, 
die da irgendwie so um die 

301
00:15:30,240 --> 00:15:32,560
Jahrtausendwende, ich glaube so 
2001 und so was ist dieses 

302
00:15:32,560 --> 00:15:36,120
Manifesto entstanden, losging. 
Vielleicht, und das ist eine 

303
00:15:36,120 --> 00:15:37,760
ganz offene Frage, die werden 
wir heute auch nicht lernen 

304
00:15:37,760 --> 00:15:42,320
können, aber vielleicht in so 
einer ernstzunehmenden 

305
00:15:42,320 --> 00:15:45,600
enterprising Ki Welt noch mal 
überdacht werden muss. 

306
00:15:45,920 --> 00:15:48,400
Also wie du gerade gesagt hast, 
es ist was anderes, wenn ich mit

307
00:15:48,400 --> 00:15:51,560
Menschen zusammenarbeite und 
wenn ich vielleicht in hybriden 

308
00:15:51,560 --> 00:15:54,520
Teams mit KI Agenten und 
Menschen arbeite oder wenn ich 

309
00:15:54,520 --> 00:15:58,840
vielleicht nur mit KI Agenten 
zusammenarbeite, weil du 

310
00:15:58,840 --> 00:16:02,520
natürlich bei Menschen auch zum 
einen langsamere 

311
00:16:02,520 --> 00:16:05,120
Implementierungszeiten hast. 
Das heißt die Zyklen. 

312
00:16:05,360 --> 00:16:10,080
Sind dort langsamer und Menschen
können auch vielleicht viel 

313
00:16:10,320 --> 00:16:12,480
weiter mitdenken. 
Das heißt, die können halt auch 

314
00:16:12,480 --> 00:16:15,600
über das, was du ihnen 
präsentierst, Hinausdenken. 

315
00:16:15,600 --> 00:16:18,960
Das heißt, die sehen den 
breiteren Kontext, selbst wenn 

316
00:16:18,960 --> 00:16:21,520
du ihnen den nicht explizit 
vorliegst. 

317
00:16:21,680 --> 00:16:24,720
Und ich glaube, da muss man 
natürlich solche KI Systeme mehr

318
00:16:24,720 --> 00:16:27,400
an die Hand nehmen, und ich 
glaube, da gab es schon auch in 

319
00:16:27,400 --> 00:16:29,680
der Vergangenheit einige 
Ansätze, die einem dann. 

320
00:16:30,080 --> 00:16:34,960
In die Richtung gute Ansätze 
geboten haben, wie zum Beispiel 

321
00:16:34,960 --> 00:16:37,600
Behavior Driven Development, wo 
man tatsächlich aus der 

322
00:16:37,600 --> 00:16:40,920
Nutzersicht die verschiedenen 
Szenarien, die man 

323
00:16:40,920 --> 00:16:44,000
implementieren möchte, 
beschrieben hat und das Ganze 

324
00:16:44,000 --> 00:16:47,080
dann genutzt hat, um die 
Entwicklung in die richtige 

325
00:16:47,080 --> 00:16:50,120
Richtung zu steuern. 
Ich glaube, solche Themen greift

326
00:16:50,120 --> 00:16:53,120
dann letzten Endes auch das Back
Driven Development auf. 

327
00:16:53,680 --> 00:16:56,880
Ja, das finde ich ganz spannend.
Auch, dass du vorhin noch mal 

328
00:16:56,880 --> 00:16:58,560
gesagt hast, dass der große 
Unterschied ja vielleicht auch 

329
00:16:58,560 --> 00:17:00,520
ist irgendwie, dass so ein 
Karrieregger natürlich viel 

330
00:17:00,520 --> 00:17:02,520
schneller programmiert und 
teilweise parallel programmiert 

331
00:17:02,520 --> 00:17:04,359
ist und ich da viel, viel öfter 
dann an diese Feedbackschleife 

332
00:17:04,359 --> 00:17:06,880
gehen muss, wenn ich mit einem 
Menschen arbeite, dann kann ich 

333
00:17:06,880 --> 00:17:09,119
mir erst mal eine Woche lang ein
Feature implementieren lassen, 

334
00:17:09,119 --> 00:17:12,480
der denkt im Idealfall selber 
mit und wenn der jetzt nach 2 

335
00:17:12,480 --> 00:17:14,560
Tagen stecken bleibt, dann sagt 
er mir Bescheid, normalerweise 

336
00:17:14,560 --> 00:17:16,440
nicht und Agent ist. 
Er tippt ja viel, viel, viel, 

337
00:17:16,440 --> 00:17:18,640
viel viel schneller diesen Code 
runter und vielleicht braucht 

338
00:17:18,640 --> 00:17:20,280
man da so ein bisschen andere 
Methoden und. 

339
00:17:20,640 --> 00:17:23,280
Und ein Vorschlag für eine 
andere Methode ist jetzt genau 

340
00:17:23,280 --> 00:17:25,599
dieses Specdriven Development, 
was sich so ganz vielen Dingen 

341
00:17:25,599 --> 00:17:27,560
bedient. 
Werden wir jetzt so ein bisschen

342
00:17:27,560 --> 00:17:30,040
sehen, die es eigentlich auch in
der Vergangenheit schon mal gab.

343
00:17:30,040 --> 00:17:32,400
Also da sind Teile vom 
Wasserfall vom v Modell, aber 

344
00:17:32,400 --> 00:17:35,360
auch vom Agile mit drin und 
eigentlich ist Specdriven 

345
00:17:35,360 --> 00:17:38,240
Development so ein bisschen so 
neuer Ansatz, bei dem die 

346
00:17:38,240 --> 00:17:43,040
Spezifikation selbst, die wird 
zum zentralen Artefakt um die 

347
00:17:43,040 --> 00:17:48,000
sich alles drumherum dreht. 
Die ist Maschinenlesbar, die ist

348
00:17:48,160 --> 00:17:50,160
also meistens wird sie einfach 
irgendwie markdown oder halt 

349
00:17:50,160 --> 00:17:53,840
Text sein, die ist versioniert, 
eventuell wird die auch in ein 

350
00:17:53,840 --> 00:17:56,640
Git Repository mit eingecheckt 
und da arbeiten wir eben 

351
00:17:56,640 --> 00:17:59,840
Kollaborativ mit mehreren Leuten
dran und anstatt jetzt zuerst zu

352
00:17:59,840 --> 00:18:02,360
programmieren und dann die 
Dokumentation zu schreiben, 

353
00:18:02,360 --> 00:18:04,440
beginnst du eben beim Spec 
Driven Development erst mit der 

354
00:18:04,440 --> 00:18:06,640
Spezifikation und das ist dann 
ein Vertrag darüber, wie sich 

355
00:18:06,640 --> 00:18:10,280
dein Code genau verhalten soll, 
so die Single Source of Truth, 

356
00:18:10,280 --> 00:18:12,160
das hatten wir ja Intro ja schon
mal so ein bisschen gesagt. 

357
00:18:12,720 --> 00:18:14,920
Und dann geht es darum eben, 
dass ich alle meine technischen 

358
00:18:14,920 --> 00:18:17,760
Entscheidungen eindeutig 
überprüfbar und 

359
00:18:17,760 --> 00:18:22,800
entwicklungsfähig niederschreibe
und diese dann eventuell auch 

360
00:18:22,800 --> 00:18:26,200
noch mal challengen lasse. 
Das heißt, ich kann sowohl auch 

361
00:18:26,200 --> 00:18:28,640
der KI sagen, Hey, ist das 
irgendwie klar ist, das ist, das

362
00:18:29,200 --> 00:18:32,800
ist das konsistent und was da 
rauskommt, sind einmal, man 

363
00:18:32,800 --> 00:18:34,960
nennt das so, ein bisschen in 
dieser Spectral Development Welt

364
00:18:34,960 --> 00:18:39,280
constitutions, das sind so die 
nicht verhandelbaren Prinzipien 

365
00:18:39,280 --> 00:18:41,840
in meinem Projekt. 
Ist zum Beispiel auch ein guter 

366
00:18:41,840 --> 00:18:45,760
Ort, wo man so vergangene 
Entscheidungen es gibt so dieses

367
00:18:45,920 --> 00:18:49,160
Ad RS, das steht für 
Architecture architecture 

368
00:18:49,160 --> 00:18:52,280
decision record, wo man sowas 
verlinkt, da wird dann irgendwie

369
00:18:52,280 --> 00:18:54,640
genau beschrieben, warum haben 
wir damals welche Entscheidungen

370
00:18:54,640 --> 00:18:59,040
getroffen, aber auch so Dinge 
die die einfach für unser, unser

371
00:18:59,040 --> 00:19:02,480
Projekt oder unser Team nicht 
verhandelbare Grundprinzipien 

372
00:19:02,480 --> 00:19:03,720
sind. 
Das ist zum Beispiel auch was, 

373
00:19:03,720 --> 00:19:06,720
wo man so die Agent MD s und die
klassischen Anweisungen an den 

374
00:19:06,720 --> 00:19:11,520
Agenten definiert. 
Und dazu zu dieser Constitution 

375
00:19:11,520 --> 00:19:15,400
kommen dann eben Spezifikationen
für einzelne Features, die man 

376
00:19:15,400 --> 00:19:18,480
den Agenten gibt. 
Das heißt, das Ergebnis ist am 

377
00:19:18,480 --> 00:19:20,480
Ende dann eine sehr sehr 
detaillierte, gehen wir gleich 

378
00:19:20,480 --> 00:19:23,360
noch mal darauf an, wie das 
aussieht, Feature Spezifikation 

379
00:19:23,840 --> 00:19:27,040
und das bringt einem deutlich 
bessere Ergebnisse in dieser KI 

380
00:19:27,040 --> 00:19:28,160
Welt. 
Das Ergebnis ist dann zum 

381
00:19:28,160 --> 00:19:30,880
anderen erstmal weniger 
Rätselraten von der KI, weil ich

382
00:19:30,880 --> 00:19:33,040
sehr genau beschrieben habe, was
sie eigentlich haben will und. 

383
00:19:33,600 --> 00:19:35,960
Mit vor allem weniger 
Überraschungen und qualitativ 

384
00:19:35,960 --> 00:19:37,720
hochwertigerem Code. 
Und das spart mir dann ja auch 

385
00:19:37,720 --> 00:19:40,760
jede Menge Zeit und Tokens, denn
so n Coding Agent, der hat 

386
00:19:40,760 --> 00:19:43,320
theoretisch unendlich viel Zeit,
ja der kann sich ja die gesamte 

387
00:19:43,320 --> 00:19:46,360
Codebasis angucken und alles an 
Dokumentationen durchlesen was 

388
00:19:46,360 --> 00:19:49,360
existiert, aber je mehr 
Informationen je mehr ich den 

389
00:19:49,360 --> 00:19:51,600
Mitgebe und je präziser die 
sind, desto weniger muss ich 

390
00:19:51,600 --> 00:19:55,920
eben selber raussuchen. 
Und auch bei bei Unklarheiten 

391
00:19:55,920 --> 00:19:58,000
oder wenn der Kontext so lang 
geworden ist, dass er dann 

392
00:19:58,000 --> 00:20:00,720
zusammengefasst werden muss. 
Das ist unter anderem ein großes

393
00:20:00,720 --> 00:20:04,560
Problem bei Cloud Code, da Dropt
die Qualität dramatisch, sobald 

394
00:20:04,560 --> 00:20:06,640
der Kontext so lang ist. 
Zusammengefasst werden muss, 

395
00:20:06,960 --> 00:20:10,320
gibt es dann auch in dieser 
Spezifikation wieder einen Ort, 

396
00:20:10,560 --> 00:20:14,160
an dem der Agent immer wieder 
die Initialen Specs und diese 

397
00:20:14,160 --> 00:20:16,800
Constitution diese nonegotables 
nachschauen kann, die gehen halt

398
00:20:16,800 --> 00:20:18,720
nicht verloren im 
Gesprächsverlauf oder sind 

399
00:20:18,720 --> 00:20:20,640
vielleicht in der 
Zusammenfassung nicht mit drin 

400
00:20:21,120 --> 00:20:23,080
und so lohnt es sich am Ende, 
wenn. 

401
00:20:23,440 --> 00:20:25,680
Sehr viel Zeit oder? 
Auf jeden Fall deutlich mehr 

402
00:20:25,680 --> 00:20:29,920
Zeit als so ein Einsatz prompt 
in die initiale Spezifikation, 

403
00:20:29,920 --> 00:20:32,320
die ich mir meistens auch 
irgendwie abprompte zu stecken, 

404
00:20:32,640 --> 00:20:35,360
weil eben jetzt Experimente 
gezeigt haben, dass das Ergebnis

405
00:20:35,360 --> 00:20:39,240
so viel besser ist, dass ich 
halt nicht einen prompt schreibe

406
00:20:39,240 --> 00:20:42,120
wie im Vibe Coding dann mal 
machen lasse, dann wieder ein 

407
00:20:42,120 --> 00:20:44,360
Feedback gebe, weil nein, so 
wollte ich das vielleicht doch 

408
00:20:44,360 --> 00:20:46,400
nicht haben, das ist ja mehr so 
ein bisschen der iterative, 

409
00:20:46,400 --> 00:20:48,400
agile Weg, sondern dass die 
Qualität. 

410
00:20:48,920 --> 00:20:50,720
Und natürlich auch die Tatsache,
dass ich, wenn ich die 

411
00:20:50,720 --> 00:20:53,120
Spezifikation einmal deutlich 
geschrieben habe, da zahle, 

412
00:20:53,120 --> 00:20:55,280
Agenten im Hintergrund parallel 
dran laufen lassen kann und so 

413
00:20:55,280 --> 00:20:58,000
weiter, dass das Halt bessere 
Ergebnisse bringt. 

414
00:20:58,400 --> 00:21:02,200
Ja, du sagst ja auch gerade, man
spart ja auch Zeit, weil man 

415
00:21:02,200 --> 00:21:05,360
nicht tatsächlich entweder 
regelmäßige Rückfragen 

416
00:21:05,360 --> 00:21:09,440
beantworten muss oder so ein 
Coding Agent erst mal irgendwie 

417
00:21:09,440 --> 00:21:12,240
20 Minuten in die falsche 
Richtung läuft und man dann 

418
00:21:12,480 --> 00:21:15,840
nachsteuern muss und dann 
irgendwie die ganzen Codezahlen,

419
00:21:15,840 --> 00:21:18,200
die dann geschrieben wurden 
irgendwie wegschmeißt. 

420
00:21:18,200 --> 00:21:21,040
Das heißt man kann. 
Geht sofort in die richtige 

421
00:21:21,040 --> 00:21:25,760
Richtung und legt halt alle 
diese Informationen vorab fest, 

422
00:21:25,760 --> 00:21:28,080
damit man jederzeit darauf 
referenzieren kann. 

423
00:21:28,240 --> 00:21:31,400
Und das hilft mir natürlich 
auch, wenn ich letzten Endes 

424
00:21:31,400 --> 00:21:35,040
vielleicht mit dem Ergebnis von 
einem Coding Agenten oder einem 

425
00:21:35,040 --> 00:21:37,200
Sprachmodell nicht zufrieden 
bin, dann kann ich quasi die 

426
00:21:37,200 --> 00:21:39,840
gleiche Aufgabe auch vielleicht 
auch noch mal an einen anderen 

427
00:21:39,840 --> 00:21:43,200
Agenten geben und kann mir dann 
ein anderes paralleles Ergebnis 

428
00:21:43,200 --> 00:21:47,320
erzeugen lassen, aber auf genau 
der gleichen Spezifikation, das 

429
00:21:47,320 --> 00:21:49,280
heißt? 
Am Ende macht vielleicht die 

430
00:21:49,280 --> 00:21:52,720
Anwendung genau das gleiche, 
aber je nach Coding Agent wurde 

431
00:21:52,720 --> 00:21:54,160
ein bisschen anderer 
weggenommen. 

432
00:21:54,160 --> 00:21:56,600
Der Code wird vielleicht anders 
geschrieben, das Design sieht 

433
00:21:56,600 --> 00:21:58,720
vielleicht ein bisschen anders 
aus, damit kann man natürlich 

434
00:21:58,720 --> 00:22:02,200
auch so eine gewisse 
Vergleichbarkeit herstellen und 

435
00:22:02,200 --> 00:22:05,760
es ist halt nicht dieses One 
Shot Development oder 

436
00:22:05,760 --> 00:22:10,000
regelmäßige Prompting, was man 
im Wald Coding sonst hätte. 

437
00:22:10,480 --> 00:22:12,240
Ja, und ich kann natürlich eben 
wirklich hingehen. 

438
00:22:12,240 --> 00:22:15,920
Und ich sage mal, am Tag setze 
ich mich hin und spezifiziere 

439
00:22:15,920 --> 00:22:20,160
alle Features aus und. 
Und dann gebe ich 30 coding 

440
00:22:20,160 --> 00:22:22,760
Agenten, 30 Features und dann 
sind die halt am nächsten Tag 

441
00:22:22,760 --> 00:22:25,000
fertig und normalerweise würde 
ich mich hinsetzen und gebe das 

442
00:22:25,000 --> 00:22:27,120
dann halt und plane die 
irgendwelchen Sprints an 

443
00:22:27,120 --> 00:22:29,040
menschliche Developers ein. 
Also ich habe so ein bisschen, 

444
00:22:29,240 --> 00:22:32,240
eigentlich wird Markdown so 
diese zentrale ja fast schon so 

445
00:22:32,240 --> 00:22:34,800
Markdown als Programmiersprache,
weil ich einmal wirklich ganz 

446
00:22:34,800 --> 00:22:38,240
genau alles ausspezifiziere und 
unsere Rolle wird dann vielmehr 

447
00:22:38,240 --> 00:22:41,760
wieder die so von einem Product 
Owner, wo wir weniger coden aber

448
00:22:41,760 --> 00:22:44,000
mehr lenken. 
Unsere Rolle ist mehr so zu 

449
00:22:44,000 --> 00:22:47,040
verifizieren, dass die Annahmen,
die ein Coding Agent getroffen 

450
00:22:47,040 --> 00:22:48,480
hat. 
Die richtigen sind, bevor er 

451
00:22:48,480 --> 00:22:51,720
losgeht und das Codet. 
Und das ist ja jetzt mal ganz 

452
00:22:51,720 --> 00:22:53,600
ehrlich, beim menschlichen 
Developer nicht anders. 

453
00:22:53,760 --> 00:22:56,320
Nur die KI kann ich halt zwingen
dazu durch entsprechende 

454
00:22:56,320 --> 00:22:58,880
Anweisungen, dass sie 
Unklarheiten anspricht. 

455
00:22:59,520 --> 00:23:01,360
Und ich glaube, keiner will ja 
irgendwie. 

456
00:23:01,920 --> 00:23:04,000
Also ich glaube, man muss 
eigentlich sagen, Code ist ja 

457
00:23:04,000 --> 00:23:07,120
eigentlich eine schlechte 
Stelle, um Requirements zu 

458
00:23:07,120 --> 00:23:10,360
erfassen, weil klar, wir wollen 
alle irgendwie coden und Code 

459
00:23:10,360 --> 00:23:12,920
schreiben macht Spaß, aber 
keiner will Code schreiben und 

460
00:23:12,920 --> 00:23:15,720
danach inkrementell in diesem 
Code die ganze Zeit 

461
00:23:15,720 --> 00:23:18,320
Veränderungen machen, weil die 
Requirements sich ändern oder 

462
00:23:18,320 --> 00:23:20,720
dann erst irgendwie 
nachgeschärft und klar wurden. 

463
00:23:20,720 --> 00:23:22,640
Stell dir vor du Code ist 
irgendwas kommst zu mir, ich 

464
00:23:22,720 --> 00:23:25,040
sage ja nee, so habe ich das 
nicht gemeint und dann muss dann

465
00:23:25,040 --> 00:23:27,120
ist es ja frustrierend, dass du 
dann deinen Code wieder anpassen

466
00:23:27,120 --> 00:23:29,400
müsstest oder sowas oder auch 
irgendwie wie du gerade gesagt. 

467
00:23:29,480 --> 00:23:32,600
Das Code wegschmeißen muss und 
so, weil die Anforderungen nicht

468
00:23:32,600 --> 00:23:35,240
klar waren am Anfang, das ist, 
das ist ja auch, das ist ja 

469
00:23:35,240 --> 00:23:37,200
genauso frustrierend und genauso
quatschend, das ist ja auch 

470
00:23:37,200 --> 00:23:39,160
nicht das, was wir machen 
wollen, wenn wir Code schreiben 

471
00:23:39,160 --> 00:23:41,360
wollen. 
Natürlich wollen wir auch nicht 

472
00:23:41,360 --> 00:23:44,000
einfach nur eine Spezifikation 
irgendwie runter runterhämmern, 

473
00:23:44,000 --> 00:23:46,760
sondern ein bisschen kreativer 
arbeiten, aber von einer KI, wo 

474
00:23:46,760 --> 00:23:48,640
ich diese Kreativität ja 
vielleicht gar nicht haben will,

475
00:23:48,640 --> 00:23:51,440
weil das ja oft im Moment noch 
bei der aktuellen Modellqualität

476
00:23:51,440 --> 00:23:54,000
auch einfach in eine falsche 
Richtung gehen kann, da will ich

477
00:23:54,000 --> 00:23:56,800
das eben auch schreiben, und da 
ist Code nicht der richtige Weg,

478
00:23:56,880 --> 00:24:00,080
Sachen zu spezifizieren. 
Sondern baue mir erst diese 

479
00:24:00,080 --> 00:24:03,280
diese Spezifikation zusammen und
habe dann am Ende sowas wie User

480
00:24:03,280 --> 00:24:07,360
Stories, Functional Requirements
Acceptance, Creatorious, Edge 

481
00:24:07,360 --> 00:24:10,440
Cases aber auch so so eine 
Review Checkliste. 

482
00:24:10,440 --> 00:24:13,960
Also wenn du irgendwas änderst 
oder bitte beachte die und die 

483
00:24:13,960 --> 00:24:16,760
und die Punkte wenn du auf der 
Suche nach Innenkonsistenzen 

484
00:24:16,760 --> 00:24:20,240
gehst oder Unklarheiten das baue
ich am Ende alles aus ne Legend 

485
00:24:20,240 --> 00:24:22,280
of User Stories, functional 
requirements Acceptance 

486
00:24:22,280 --> 00:24:25,440
Creatorious Edge Cases das ist 
für uns als menschlich dir da 

487
00:24:25,440 --> 00:24:26,800
passt ja auch alles nichts 
Neues. 

488
00:24:27,160 --> 00:24:28,840
Und deswegen ist es ja 
eigentlich schon irre, dass wir 

489
00:24:28,840 --> 00:24:31,720
dachten, wir können irgendwie 
wie im vipe Coding mit 34 Sätzen

490
00:24:31,720 --> 00:24:33,720
eine ganze App oder ein Feature 
beschreiben und dann geht das 

491
00:24:33,720 --> 00:24:35,680
Ding los. 
Das funktioniert auch manchmal, 

492
00:24:35,680 --> 00:24:37,280
aber eben in einer 
Professionelleren oder 

493
00:24:37,600 --> 00:24:41,240
brownfield Umgebung nicht so gut
und deswegen das ist gar nicht 

494
00:24:41,240 --> 00:24:43,280
so weit weg von den Sachen, die 
wir eh auch irgendwie für 

495
00:24:43,280 --> 00:24:46,120
menschliche Developer schreiben 
und ausformulieren und die wir 

496
00:24:46,120 --> 00:24:50,160
dann eben in JIRA Tickets oder 
github Issues Gießen und das 

497
00:24:51,200 --> 00:24:54,320
dieser Challenge Part daran, 
aber den finde ich ultra 

498
00:24:54,320 --> 00:24:56,320
spannend, dass man hingeht und 
sagt Hey. 

499
00:24:56,960 --> 00:24:59,040
Karriergeld ne kann ich zwingen,
der mich einfach dazu kommt. 

500
00:24:59,040 --> 00:25:03,280
Schau dir das an und guck ob das
für dich Sinn ergibt und bitte 

501
00:25:03,360 --> 00:25:07,160
Bewerte das nach dieser 
folgenden Checkliste und hake 

502
00:25:07,160 --> 00:25:10,000
das Stück für Stück ab und wenn 
du da Dinge sind, die noch zu 

503
00:25:10,000 --> 00:25:13,680
klären sind. 
Dann lass uns das klären oder es

504
00:25:13,680 --> 00:25:15,920
gibt zum Beispiel, da kommen wir
gleich so ein bisschen in die 

505
00:25:15,920 --> 00:25:19,560
Implementierung, aber es gibt in
Cloud Codes einen eingebauten 

506
00:25:19,560 --> 00:25:23,440
Planungsmodus, zum Beispiel, der
Quist mich dann nachher noch, 

507
00:25:23,440 --> 00:25:26,560
also Quist heißt, der stellt mir
nachher Fragen, habe ich das 

508
00:25:26,560 --> 00:25:29,200
richtig verstanden, ist das A 
oder b, wie du es haben willst. 

509
00:25:29,200 --> 00:25:31,440
Und da kannst Du anklicken, AB 
oder nicht ganz anders, ich 

510
00:25:31,440 --> 00:25:36,080
sag's dir mal, oder sollen wir 
die mobile App nativ bauen oder 

511
00:25:36,080 --> 00:25:38,040
mit einem Cross Plattform 
Framework, weil das hast du 

512
00:25:38,040 --> 00:25:41,000
irgendwie gar nicht spezifiziert
und er stellt mir dann nachher 

513
00:25:41,000 --> 00:25:44,040
wirklich so fragen. 
Sagen über die Spezifikation, wo

514
00:25:44,040 --> 00:25:45,400
ich mir an, wo ich dann zu 
stellen komme, wo ich mir 

515
00:25:45,400 --> 00:25:47,240
wirklich vielleicht noch keine 
Gedanken darüber gemacht habe. 

516
00:25:47,240 --> 00:25:49,200
Und gesagt, Oh ja, stimmt, das 
habe ich dir gar nicht gesagt 

517
00:25:49,600 --> 00:25:52,160
und diese Iteration, diese Loop,
das ist, glaube ich, die Magie. 

518
00:25:53,000 --> 00:25:55,600
Ich finde das ganz interessant, 
wenn man darüber spricht, dann 

519
00:25:56,080 --> 00:25:58,720
sieht man so diese Verbindung zu
den Dingen, die in der 

520
00:25:58,720 --> 00:26:01,840
Vergangenheit auch schon gemacht
wurden oder passiert sind. 

521
00:26:01,840 --> 00:26:03,840
Deswegen haben wir ja gerade 
diesen historischen Abriss 

522
00:26:03,840 --> 00:26:07,200
gemacht, man sieht wirklich auch
Elemente aus dem 

523
00:26:07,200 --> 00:26:09,440
Wasserfallmodell, dass man ganz 
klare. 

524
00:26:09,680 --> 00:26:12,960
Requirements Niederschreibt und 
dann sieht man aber auch diese 

525
00:26:12,960 --> 00:26:15,280
agilen Elemente. 
Du sagst gerade, dass vielleicht

526
00:26:15,280 --> 00:26:18,560
mal jemand drüber schaut und 
sagt, OK, das hast du in deinen 

527
00:26:18,560 --> 00:26:20,480
Requirements vielleicht 
vergessen, weil ich glaube wir 

528
00:26:20,480 --> 00:26:23,520
alle haben das in unserem. 
Developer Alltag mindestens 

529
00:26:23,520 --> 00:26:26,400
einmal erlebt, dass wir 
irgendwas implementiert haben 

530
00:26:26,400 --> 00:26:29,280
und dann am Ende von einem 
Sprint dann am Ende der Product 

531
00:26:29,280 --> 00:26:31,360
Ordner gesagt hat, so hatte ich 
mir das eigentlich nicht 

532
00:26:31,360 --> 00:26:34,000
vorgestellt und dann ja dann 
hätte das mal ordentlich 

533
00:26:34,000 --> 00:26:37,440
spezifizieren sollen und genau 
dieses Feedback bekommt man ja 

534
00:26:37,440 --> 00:26:41,760
jetzt auch sofort ad hoc und 
wenn man das dann noch mit 

535
00:26:41,760 --> 00:26:45,840
bestimmten Elementen aus diesem 
v Modell zusammenbringt, dass 

536
00:26:45,840 --> 00:26:49,600
man zum Beispiel Integration 
Tests baut, dass man Unit Tests 

537
00:26:49,600 --> 00:26:52,040
baut und dann alle diese 
Elemente gegengetrieben. 

538
00:26:52,120 --> 00:26:54,520
Gecheckt werden und nicht nur 
meine User Stories. 

539
00:26:54,520 --> 00:26:56,720
Da hat es gerade gesagt, ich 
kann dann in so einen Plan Mode 

540
00:26:56,720 --> 00:27:00,400
gehen und kriege dann auch 
Rückfragen ob denn meine meine 

541
00:27:00,400 --> 00:27:03,160
Planung vollständig ist. 
Aber genau so kann ich natürlich

542
00:27:03,160 --> 00:27:06,840
dann auch nachher auf der Code 
Ebene und Integrations oder 

543
00:27:06,840 --> 00:27:09,880
Module Ebene die ganzen 
Validierungen vornehmen und dann

544
00:27:09,880 --> 00:27:12,520
ist man ja schon wieder relativ 
nah an dem was man in der 

545
00:27:12,520 --> 00:27:14,800
Vergangenheit hat. 
Das heißt man sieht wirklich wie

546
00:27:14,800 --> 00:27:19,680
diese verschiedenen Trends hier 
zusammenkommen und das Ganze 

547
00:27:19,680 --> 00:27:24,000
kann man dann natürlich auch. 
Entsprechend in Tooling Gießen, 

548
00:27:24,080 --> 00:27:27,040
das heißt, ich muss das jetzt 
nicht alles wissen, ich muss 

549
00:27:27,040 --> 00:27:29,840
diese Prozesse jetzt nicht 
kennen und erlernen, sondern ich

550
00:27:29,840 --> 00:27:32,520
habe natürlich auch heutzutage 
Möglichkeiten, das in 

551
00:27:32,520 --> 00:27:36,720
entsprechende Werkzeuge zu 
gießen, die mich dann durch 

552
00:27:36,720 --> 00:27:40,960
diesen Prozess führen und die 
dann quasi dafür sorgen, dass 

553
00:27:40,960 --> 00:27:45,200
ich am Ende wirklich alle diese 
Artefakte erstellt habe, dann 

554
00:27:45,200 --> 00:27:48,960
die entsprechenden. 
Spezifikationen gebaut habe, um 

555
00:27:48,960 --> 00:27:53,800
in die Implementierung zu gehen 
und da gibt es zum Beispiel das 

556
00:27:53,800 --> 00:27:56,880
Spec Kit, was ein Open Source 
Projekt ist, was von github 

557
00:27:56,880 --> 00:28:01,360
vorangetrieben wird, was einige 
dieser Phasen dann in feste 

558
00:28:01,360 --> 00:28:04,960
Aufgaben oder Kommandos auf der 
Kommandozeile gießt. 

559
00:28:05,800 --> 00:28:07,880
Genau da gibt es natürlich noch 
ganz viele andere Tools. 

560
00:28:08,080 --> 00:28:10,320
Also Spackit ist jetzt ein 
Beispiel, was gerade irgendwie 

561
00:28:10,320 --> 00:28:12,240
sehr populär ist und wo es auch 
gerade irgendwie viel 

562
00:28:12,240 --> 00:28:15,440
Aufmerksamkeit gibt, weil es 
sehr, sehr detailliert durch 

563
00:28:15,440 --> 00:28:19,040
diesen Anforderungsprozess, 
diesen Anforderungsprozess 

564
00:28:19,040 --> 00:28:20,800
führt. 
Es gibt aber noch andere, es 

565
00:28:20,800 --> 00:28:24,960
gibt Open Spec oder es gibt von 
von Amazon dieses Kairo oder 

566
00:28:24,960 --> 00:28:28,000
kiro Projekt, die haben das 
Ganze so ein bisschen eigentlich

567
00:28:28,000 --> 00:28:31,120
losgetreten und gestartet, es 
gibt auch das Spark Framework 

568
00:28:31,120 --> 00:28:32,240
und. 
Und wie gesagt, immer mehr 

569
00:28:32,240 --> 00:28:34,560
Editoren und Coding Agenten 
haben das mit eingebaut. 

570
00:28:34,560 --> 00:28:36,560
Also ich habe ja gerade eben 
schon erwähnt, Crowd Code hat so

571
00:28:36,560 --> 00:28:40,480
eine Plan Phase eingebaut, die 
auch so Review Loops hat, es 

572
00:28:40,480 --> 00:28:43,080
gibt den Cursor und eine Visual 
Studio Code mittlerweile auch so

573
00:28:43,080 --> 00:28:45,400
eine To do Liste die der Agent 
sich selber schreibt die man 

574
00:28:45,400 --> 00:28:48,440
irgendwie reviewen kann, die 
verlinken wir natürlich alle in 

575
00:28:48,440 --> 00:28:50,320
den in den Show Notes von der 
Folge, da könnt ihr euch 

576
00:28:50,320 --> 00:28:53,560
angucken was ein bisschen für 
euch funktioniert, aber wir 

577
00:28:53,560 --> 00:28:56,880
würden jetzt einfach hier mal am
Beispiel von von Spec Kit. 

578
00:28:57,400 --> 00:29:00,720
Als ein Tooling Beispiel das 
ganze durchgehen, also diese 

579
00:29:00,720 --> 00:29:03,160
Tools machen eigentlich alle das
Gleiche, das sind irgendwelche 

580
00:29:03,160 --> 00:29:08,920
oft irgendwelche Generatoren 
oder ja, fertige Proms und 

581
00:29:08,920 --> 00:29:12,640
templates, die dann eben uns 
dabei helfen, für Spec driven 

582
00:29:12,640 --> 00:29:14,960
Development diese Specs zu 
bauen, also das was früher so 

583
00:29:14,960 --> 00:29:17,920
ein bisschen händische Arbeit 
war, jetzt explizite in 

584
00:29:17,920 --> 00:29:21,000
explizite Spezifikationen zu 
gießen und die dann eben auch 

585
00:29:21,000 --> 00:29:23,840
wieder mit einer Ki challengen 
zu lassen. 

586
00:29:24,880 --> 00:29:27,640
Ja und was das Back it so 
beliebt macht, ist nicht nur, 

587
00:29:27,640 --> 00:29:30,800
dass es Open Source ist, sondern
dass es auch diverse Coding 

588
00:29:30,800 --> 00:29:32,800
Agenten unterstützt. 
Das heißt? 

589
00:29:32,840 --> 00:29:34,080
Fast alle eigentlich. 
Genau. 

590
00:29:34,080 --> 00:29:37,120
Es erzeugt mir entsprechende 
Shortcuts, die ich in meinem 

591
00:29:37,120 --> 00:29:39,960
Coding Agenten, egal ob es jetzt
einen Cloud Code, einen github 

592
00:29:39,960 --> 00:29:43,200
co. 
Paletten in Germany ist. 

593
00:29:43,360 --> 00:29:45,080
Egal was ich jetzt hier 
verwende, kriege ich 

594
00:29:45,080 --> 00:29:49,520
entsprechende Shortcuts um durch
diese Prozessschritte des 

595
00:29:49,520 --> 00:29:53,840
Backdriven Development 
durchzugehen und dort. 

596
00:29:54,440 --> 00:29:57,360
Dort beginne ich mit dem, was du
vorhin schon erwähnt hast. 

597
00:29:57,360 --> 00:30:00,800
Ich beginne mit einer 
Constitution, also quasi der 

598
00:30:00,800 --> 00:30:04,760
Verfassung für mein 
Entwicklungsprojekt, wo ich halt

599
00:30:04,760 --> 00:30:08,800
genau diese grundlegenden 
Rahmenbedingungen festlege. 

600
00:30:08,800 --> 00:30:12,040
Du hast gerade gesagt, es kommt 
sehr nah dran an diese ganzen 

601
00:30:12,040 --> 00:30:14,160
Instructions, die ich 
üblicherweise vielleicht für so 

602
00:30:14,160 --> 00:30:16,720
einen Agenten auch in so eine 
Agents and MD. 

603
00:30:17,080 --> 00:30:20,800
Packe die halt grundlegende 
Informationen rund um mein 

604
00:30:20,800 --> 00:30:24,800
Projekt enthalten, die Halt 
immer berücksichtigt werden 

605
00:30:24,800 --> 00:30:27,920
müssen, egal an welchem Feature 
ich gerade implementiere. 

606
00:30:28,880 --> 00:30:30,240
Genau. 
Sobald ich die Constitution dann

607
00:30:30,240 --> 00:30:33,120
fertig habe, gehe ich in die 
erste richtige spec Phase. 

608
00:30:33,600 --> 00:30:36,640
Das heißt dann specify. 
Also das kann ich dann auch zum 

609
00:30:36,920 --> 00:30:41,240
Beispiel mit Specify aufrufen, 
wenn ich in zum Beispiel Cloud 

610
00:30:41,240 --> 00:30:43,600
Code oder gitarco Pilot 
unterwegs bin. 

611
00:30:43,960 --> 00:30:47,000
Ganz wichtig diese diese Slash 
Commands die das dieses Back it 

612
00:30:47,000 --> 00:30:48,720
mitbringt. 
Dahinter liegt eigentlich nichts

613
00:30:48,720 --> 00:30:51,360
anderes als ein fertiger prompt.
Also da hat jemand sich die Mühe

614
00:30:51,360 --> 00:30:55,200
gemacht einen sehr detaillierten
prompt zu schreiben, den ich 

615
00:30:55,200 --> 00:30:56,480
dann aber nochmal verfeinern 
kann. 

616
00:30:56,480 --> 00:30:59,680
Also ich tippe ein Specifi und 
gebe dann so eine High Level 

617
00:30:59,680 --> 00:31:03,440
Beschreibung von dem was ich da 
eigentlich bauen will und warum.

618
00:31:04,280 --> 00:31:06,280
Keine technologischen Dinge 
also. 

619
00:31:06,280 --> 00:31:08,400
Da schreibe ich jetzt noch nicht
auf welches welches Framework 

620
00:31:08,400 --> 00:31:12,240
oder sowas, sondern einzig und 
allein ja im Prinzip User 

621
00:31:12,240 --> 00:31:13,720
Stories. 
Also ich sage ey, ich möchte 

622
00:31:13,720 --> 00:31:17,280
jetzt hier irgendwie eine App 
bauen, die mir dabei hilft meine

623
00:31:17,280 --> 00:31:22,360
Fotos zu organisieren und in 
separate Fotoalben wie moved, 

624
00:31:22,360 --> 00:31:25,120
ich möchte in der Lage sein 
mehrere Fotos in dem gleichen 

625
00:31:25,120 --> 00:31:28,280
Fotoalbum zu haben oder auch ein
Foto in mehreren Fotoalben zu 

626
00:31:28,280 --> 00:31:30,320
haben, die sollen gruppiert 
werden können, die möchte ich 

627
00:31:30,480 --> 00:31:33,120
neu organisieren können, indem 
ich Drag and Drop verwende. 

628
00:31:33,640 --> 00:31:36,160
Es soll eine Mainpage und eine 
Unterpage geben und ich kann so 

629
00:31:36,160 --> 00:31:39,360
ein nested Albums machen und für
jedes Album möchte ich aber auch

630
00:31:39,360 --> 00:31:41,680
Fotos in so einer Preview dann 
sehen. 

631
00:31:41,680 --> 00:31:44,080
So und so weiter also ich 
schreibe diesen ganzen Kram 

632
00:31:44,400 --> 00:31:48,160
irgendwie auf und was Beckett 
halt eben macht ist, das nimmt 

633
00:31:48,240 --> 00:31:51,200
diese Anforderung und gießt es 
dann in ein Template in ein 

634
00:31:51,200 --> 00:31:55,200
markdown Template, wo im Detail 
diese Dinge beschrieben werden. 

635
00:31:56,000 --> 00:31:58,920
Ja, und zusätzlich zu diesem 
prompt, der da enthalten ist, 

636
00:31:58,920 --> 00:32:02,560
gibt es da auch ein paar Bash 
beziehungsweise Power Shell 

637
00:32:02,560 --> 00:32:05,280
Skripte, die dann im Hintergrund
laufen und die dann bestimmte 

638
00:32:05,280 --> 00:32:08,320
Dateien erzeugen. 
Das heißt, das geht nicht alles 

639
00:32:08,320 --> 00:32:10,720
nur über das Large Language 
Model, sondern Teil dieses 

640
00:32:10,720 --> 00:32:13,360
Packets sind halt auch einige 
Skripte, die dann ausgeführt 

641
00:32:13,360 --> 00:32:15,840
werden, das heißt man sieht dann
auch, wenn man jetzt diesen 

642
00:32:15,840 --> 00:32:18,160
specify oder in der anderen 
Schritte durchläuft, dann fragt 

643
00:32:18,160 --> 00:32:21,120
mein Coding Agent auch, möchtest
du folgendes Shell Skript 

644
00:32:21,440 --> 00:32:24,240
ausführen und dieses Shell 
Skript erzeugt dann bestimmte 

645
00:32:24,240 --> 00:32:27,440
Informationen die dann weiter. 
Weiter verwendet werden können. 

646
00:32:27,440 --> 00:32:30,360
Und wenn ich jetzt wie gesagt 
dieses Mark Down file habe, dann

647
00:32:30,360 --> 00:32:33,040
kann ich das natürlich jetzt 
einfach so hinnehmen oder ich 

648
00:32:33,040 --> 00:32:35,080
kann natürlich auch einen 
manuellen Schritt noch mal 

649
00:32:35,080 --> 00:32:37,320
einführen und einfach mal drüber
lesen und sagen, macht das alles

650
00:32:37,320 --> 00:32:40,800
für mich Sinn, das heißt ich 
kann jetzt auch tatsächlich dort

651
00:32:41,040 --> 00:32:44,320
hingehen und diese Datei lesen, 
weil das ist ja halt nicht nur 

652
00:32:44,320 --> 00:32:47,040
maschinenlesbar, sondern auch 
von Menschen lesbar, das heißt, 

653
00:32:47,040 --> 00:32:48,920
ich habe eine Mark down Datei, 
die kann ich mir dann auch im 

654
00:32:48,920 --> 00:32:51,600
Preview Modus anschauen und. 
Und bekommen die auch schön 

655
00:32:51,600 --> 00:32:54,840
formatiert. 
Geh dann da durch und mach dann 

656
00:32:54,840 --> 00:32:59,080
noch mal eine Validierung, ob 
das was das Large Language Model

657
00:32:59,080 --> 00:33:02,160
der Wahl, der Coding Agent der 
Wahl dann aus meinem prompt 

658
00:33:02,160 --> 00:33:05,480
gemacht hat, auch das ist was 
ich mache und dann kann ich 

659
00:33:05,480 --> 00:33:06,960
natürlich in den nächsten 
Schritt springen. 

660
00:33:07,360 --> 00:33:10,000
Ja, und der ist dann dieser 
Quizmodus, also der ist dann 

661
00:33:10,160 --> 00:33:13,120
Specy heißt er clarify oder 
Clarify. 

662
00:33:13,280 --> 00:33:14,880
Dahinter liegt dann wieder ein 
prompt, der sagt EY das. 

663
00:33:15,440 --> 00:33:17,800
Guck dir das an, diese 
Spezifikation, die jetzt erst 

664
00:33:17,800 --> 00:33:19,840
mal durch KI erstellt wurde und 
dann, wie malte gerade gesagt 

665
00:33:19,840 --> 00:33:21,560
hat, vielleicht durch einen 
Menschen noch mal verfeinert 

666
00:33:21,560 --> 00:33:24,120
wurde, finde ich finde ich 
eigentlich einen sehr wichtigen 

667
00:33:24,120 --> 00:33:25,200
Punkt. 
Also ich sage nur, weil das von 

668
00:33:25,200 --> 00:33:27,360
KI jetzt erst mal generiert und 
dieses Template ausgefüllt 

669
00:33:27,360 --> 00:33:30,400
wurde, heißt es ja nicht, dass 
sich das auch nur noch mit KI 

670
00:33:30,400 --> 00:33:32,560
verändern kann, sondern das auch
selber natürlich noch mal 

671
00:33:33,280 --> 00:33:35,560
reviewen kann und. 
Und dann gehen wir eben in diese

672
00:33:35,560 --> 00:33:39,520
clarify Phase, weil diese 
Templates, die beinhalten, auch 

673
00:33:39,520 --> 00:33:42,240
schon so eine Review und 
Akzeptanz. 

674
00:33:42,240 --> 00:33:45,920
Checkliste zum Challengen von 
den Specs, die ich da reingebaut

675
00:33:45,920 --> 00:33:48,400
habe, gemeinsam mit dem KI 
Agenten, das heißt dieser 

676
00:33:48,560 --> 00:33:51,880
hinterlegte prompt hinter diesem
clarify Kommando, der geht 

677
00:33:51,880 --> 00:33:55,200
eigentlich hin, guckt sich diese
Checkliste an und ja Challenge 

678
00:33:55,200 --> 00:33:58,400
dann das Dokument was wir da 
gebaut haben anhand dieser 

679
00:33:58,400 --> 00:34:02,560
Checkliste und stellt mir fragen
ob er Dinge richtig richtig 

680
00:34:02,560 --> 00:34:04,520
verstanden hat oder ob das 
wirklich so oder. 

681
00:34:04,720 --> 00:34:06,720
Oder wenn er Unklarheiten 
entdeckt hat, lässt er mich das 

682
00:34:06,720 --> 00:34:09,920
nochmal verfeinern. 
Das ist eigentlich ein sehr, 

683
00:34:09,920 --> 00:34:12,280
sehr, sehr wichtiger Schritt, 
dass ich dann hingehe und gucke,

684
00:34:12,280 --> 00:34:15,560
okay sind wir hier alle, 
eigentlich haben wir alle hier 

685
00:34:15,560 --> 00:34:17,320
eigentlich die gleiche 
Wahrnehmung davon, von dem, was 

686
00:34:17,320 --> 00:34:19,760
gebaut werden soll. 
Ja, und hier sind wir 

687
00:34:19,760 --> 00:34:24,880
tatsächlich immer noch komplett 
auf der Requirement Seite auf 

688
00:34:24,880 --> 00:34:27,360
der Product owner Seite. 
Wir haben noch keine 

689
00:34:27,360 --> 00:34:29,639
technologischen Entscheidungen 
getroffen, sondern wir haben nur

690
00:34:29,639 --> 00:34:32,960
darüber gesprochen. 
Was wir erreichen wollen und 

691
00:34:32,960 --> 00:34:35,520
nicht wie wir es erreichen 
wollen, das kommt dann erst im 

692
00:34:35,600 --> 00:34:39,120
nächsten Schritt. 
Den sogenannten Plan Step im 

693
00:34:39,120 --> 00:34:42,960
Spec Kit, wo ich dann 
tatsächlich das Ganze in einen 

694
00:34:42,960 --> 00:34:46,080
technischen Plan gehe, wo ich 
dann zum Beispiel meinen Text 

695
00:34:46,080 --> 00:34:48,639
Stack. 
Festlege, wo ich bestimmte 

696
00:34:48,639 --> 00:34:50,880
technologische Entscheidungen 
treffe. 

697
00:34:51,120 --> 00:34:54,480
Auch dort ist das ganze 
Iterativ, das heißt, ich bekomme

698
00:34:54,480 --> 00:34:58,560
dort auch Feedback, teilweise 
Rückfragen zu bestimmten Dingen,

699
00:34:58,560 --> 00:35:01,120
die vielleicht noch nicht klar 
sind oder wo das Large Language 

700
00:35:01,120 --> 00:35:03,200
Model. 
Tatsächlich, eine bestimmte 

701
00:35:03,200 --> 00:35:06,080
Hypothese hat, und dann kann ich
das nochmal entsprechend 

702
00:35:06,080 --> 00:35:09,840
validieren und festlegen, damit 
wir nachher nicht nur unsere 

703
00:35:09,920 --> 00:35:13,040
Spezifikation haben, sondern 
auch einen technischen Plan, wie

704
00:35:13,200 --> 00:35:16,720
wir das Ganze umsetzen wollen. 
Und da können wir natürlich auch

705
00:35:16,720 --> 00:35:19,840
Hinweise geben, wo man 
vielleicht firmeninterne 

706
00:35:19,840 --> 00:35:22,840
technische Dokumentationen zum 
gewünschten Tool Stack hat, das 

707
00:35:22,880 --> 00:35:25,200
heißt, man muss das nicht immer 
alles manuell machen, sondern 

708
00:35:25,200 --> 00:35:28,000
man kann da natürlich auch auf 
Third Party. 

709
00:35:28,480 --> 00:35:31,040
Informationen verweisen. 
Man kann dort auch einen MCP 

710
00:35:31,040 --> 00:35:34,320
Server einbinden, der dann 
vielleicht einen Zugang zu dem 

711
00:35:34,320 --> 00:35:37,440
eigenen Dokumentationssystem, 
vielleicht zu einem Konfluence 

712
00:35:37,440 --> 00:35:40,000
bietet, wo alle Informationen zu
meinem Text Hack 

713
00:35:40,160 --> 00:35:42,240
niedergeschrieben sind. 
Das heißt, ich kann dann 

714
00:35:42,240 --> 00:35:45,040
natürlich auch die Integration 
in meine üblichen Prozesse 

715
00:35:45,040 --> 00:35:48,160
nutzen, um hier am Ende dieses 
Dokument zu bekommen. 

716
00:35:48,640 --> 00:35:50,600
Und der Outcome davon kann ja 
durchaus auch sein, was jetzt 

717
00:35:50,600 --> 00:35:53,360
wieder jemand anders. 
Also ein anderer menschlicher 

718
00:35:53,360 --> 00:35:56,960
Developer Reviewt während ich in
dieser Spezifikationsphase 

719
00:35:56,960 --> 00:35:59,680
vielleicht sehr eng den Product 
Owner mit Einbinde, würde ich 

720
00:35:59,680 --> 00:36:03,440
jetzt bei dem, was bei der Plan 
Phase rauskommt, sehr eng einen 

721
00:36:03,440 --> 00:36:05,960
technischen User, eventuell 
sogar einen Software Developer 

722
00:36:05,960 --> 00:36:08,480
mit einbinden und sagen Schau 
schau dir mal an ob das für dich

723
00:36:08,480 --> 00:36:12,560
alles aus einer technischen 
Perspektive sinnvoll ist und 

724
00:36:12,560 --> 00:36:14,000
Sinn ergibt was da geschrieben 
wurde. 

725
00:36:14,320 --> 00:36:16,640
Wenn du jetzt zum Beispiel 
spezifizierst, dass du gerne 

726
00:36:16,640 --> 00:36:20,160
vanilla, html CS und Java Script
haben möchtest und keine. 

727
00:36:20,360 --> 00:36:22,080
Keine. 
Keine Frontend Frameworks nutzt 

728
00:36:22,080 --> 00:36:25,120
oder was auch immer und dann 
aber irgendwie vielleicht später

729
00:36:25,280 --> 00:36:28,160
irgendwas von von irgendwelchen 
React Hooks oder so was 

730
00:36:28,160 --> 00:36:29,800
schreibt, dann ist das ja 
vielleicht eine Inkonsistenz, 

731
00:36:29,800 --> 00:36:31,880
die entweder menschlicher 
Developer oder natürlich auch 

732
00:36:31,880 --> 00:36:34,640
wenn ich es Challenger mit der 
KI wieder die KI finden kann, 

733
00:36:35,680 --> 00:36:39,720
nach der Planphase geht es dann 
jetzt in konkrete Tasks, also 

734
00:36:39,720 --> 00:36:42,520
das ist die Task Phase, da geht 
der Agenda wirklich hin und 

735
00:36:42,520 --> 00:36:46,400
nimmt diese Spezifikationen. 
Aus dem Vorvorherigen Schritt 

736
00:36:46,400 --> 00:36:49,240
nimmt den Plan aus dem 
vorherigen Schritt und bricht 

737
00:36:49,240 --> 00:36:53,560
die Rinta in wirklich ganz 
kleine atomare Work Items. 

738
00:36:53,560 --> 00:36:56,600
Also richtig, wieso eine to do 
Liste und das haben viele von 

739
00:36:56,600 --> 00:36:59,600
diesen Coding Tasks jetzt auch 
schon angefangen, wirklich im UI

740
00:36:59,600 --> 00:37:03,440
oder in in der Art und Weise wie
diese Coding Agenten. 

741
00:37:04,280 --> 00:37:06,320
Genau, die Agenten haben das 
eingebaut, nicht die Task. 

742
00:37:06,400 --> 00:37:08,800
Diese Taskliste haben viele 
Agenten auch schon mittlerweile 

743
00:37:08,960 --> 00:37:11,280
eingebaut, die wird dann 
wirklich Schritt für Schritt 

744
00:37:11,280 --> 00:37:14,040
auch in dieser Reihenfolge 
abgearbeitet, also das sind dann

745
00:37:14,040 --> 00:37:17,040
wirklich ganz konkrete 
Arbeitsanweisungen, die dann aus

746
00:37:17,040 --> 00:37:20,880
dem Plan und der Spezifikation 
abgeleitet werden. 

747
00:37:21,720 --> 00:37:24,720
Ich meine, wir kennen das 
wahrscheinlich alle aus diesen 

748
00:37:24,960 --> 00:37:29,360
agilen 
Softwareentwicklungsvorgehensmodellen,

749
00:37:29,360 --> 00:37:33,120
wo wir dann vielleicht eine user
Story implementieren und dann 

750
00:37:33,120 --> 00:37:35,760
das Erste, was wir als Developer
machen, ist natürlich, uns 

751
00:37:35,760 --> 00:37:39,920
Gedanken darüber machen, wie wir
es basierend auf dem Text Deck, 

752
00:37:39,920 --> 00:37:42,640
den wir haben, in einzelne 
Aufgaben runterbrechen, die wir 

753
00:37:42,640 --> 00:37:46,000
uns in unserem Planning und 
Tracking Tool der Wahl irgendwie

754
00:37:46,000 --> 00:37:48,000
aufschreiben, damit wir auch 
nach und nach. 

755
00:37:48,280 --> 00:37:51,600
Strukturiert an diesen Dingen 
arbeiten können und genau das 

756
00:37:51,680 --> 00:37:56,640
übertragen wir jetzt in diese KI
gestützte Welt, wo die Coding 

757
00:37:56,640 --> 00:38:01,040
Agenten natürlich auch mit 
diesen Aufgaben arbeiten und im 

758
00:38:01,040 --> 00:38:03,160
nächsten Schritt geht es dann 
natürlich in die 

759
00:38:03,160 --> 00:38:06,200
Implementierung. 
Dort ist auch jetzt in Speccit 

760
00:38:06,200 --> 00:38:10,080
ein Shortcut vorgesehen und 
dieser Shortcut triggert dann 

761
00:38:10,080 --> 00:38:12,960
entsprechend den Coding Agent, 
um mit der Implementierung zu 

762
00:38:12,960 --> 00:38:16,400
beginnen und man kann dort 
natürlich auch konkret mitgeben,

763
00:38:16,560 --> 00:38:19,960
welche der Aufgaben in. 
Implementiert werden sollen in 

764
00:38:19,960 --> 00:38:23,840
der Regel ist das so, dass meine
Spezifikationen und meine 

765
00:38:23,840 --> 00:38:26,560
Aufgaben dann vielleicht auch in
unterschiedliche Phasen 

766
00:38:26,560 --> 00:38:29,320
gruppiert sind. 
Das bringt das Tooling an der 

767
00:38:29,320 --> 00:38:32,440
Stelle schon mit, dass ich zum 
Beispiel eine MVP Phase habe und

768
00:38:32,440 --> 00:38:35,680
dann eine weitere Iteration und 
dann kann ich natürlich die 

769
00:38:35,680 --> 00:38:39,640
Tasks in Blöcken abarbeiten, zum
Beispiel sage ich dann, bitte 

770
00:38:39,640 --> 00:38:43,360
bearbeite erstmal nur die Tasks,
die Halt für den MVP notwendig 

771
00:38:43,360 --> 00:38:46,680
sind und dann geht der Coding 
Agent entsprechend hin über. 

772
00:38:46,760 --> 00:38:50,560
Übernimmt das Ganze unter 
Berücksichtigung natürlich des 

773
00:38:50,560 --> 00:38:56,160
Plans, der Constitution etc. 
Und am Ende kommt wie 

774
00:38:56,160 --> 00:38:58,800
üblicherweise, wenn ich mit so 
einem Coding Agenten arbeite, 

775
00:38:58,800 --> 00:39:03,360
dann eine kleinere oder größere 
Menge von neuen Dateien raus. 

776
00:39:03,360 --> 00:39:06,400
Neuen Codezeilen, die wir 
natürlich entsprechend 

777
00:39:06,400 --> 00:39:09,880
validieren und freigeben können.
Was dieses Weggibt jetzt noch 

778
00:39:09,880 --> 00:39:11,280
ganz cool macht, das finde ich, 
dass es auch. 

779
00:39:11,720 --> 00:39:14,520
Auch ganz klar Anweisungen hat 
und auch Skripte dafür 

780
00:39:14,520 --> 00:39:15,840
hinterlegt. 
Hat das wirklich so ein bisschen

781
00:39:15,840 --> 00:39:18,560
Get Native zu machen? 
Also die Tasks werden dann 

782
00:39:18,560 --> 00:39:20,720
wirklich auch in Comics 
abgearbeitet, sodass ich 

783
00:39:20,720 --> 00:39:23,560
theoretisch so ja so Checkpoints
habe, denen ich wieder 

784
00:39:23,560 --> 00:39:25,800
zurückgehen kann, wo ich sage, 
ja die ersten 3 Tasks waren ja 

785
00:39:25,800 --> 00:39:28,200
okay, aber was du danach gemacht
hast, da bist du völlig falsch 

786
00:39:28,200 --> 00:39:31,040
abgebogen, ich muss das glaube 
ich noch mal neu spezifizieren 

787
00:39:31,680 --> 00:39:35,280
und das alles, also das ist auch
unter anderem jetzt der Grund 

788
00:39:35,400 --> 00:39:37,040
wo. 
Warum das, was wir jetzt mit 

789
00:39:37,040 --> 00:39:39,760
Speckkit einmal exemplarisch 
hier beschrieben haben, besser 

790
00:39:39,760 --> 00:39:41,760
ist als das bestehende Vibe 
Coding? 

791
00:39:42,160 --> 00:39:44,840
Weil das ist genau das, was ich 
gesagt habe. 

792
00:39:44,840 --> 00:39:46,880
Ich kann an einer bestimmten 
Stelle irgendwas ändern, es ist 

793
00:39:47,040 --> 00:39:51,080
reproduzierbar, wir kriegen ein 
kontrollierbares Ergebnis und wo

794
00:39:51,080 --> 00:39:53,280
er sich dann auch wieder drüber 
iterieren kann, ich kann 

795
00:39:53,680 --> 00:39:57,400
manuelle Änderungen an den Specs
machen und die dann einfach noch

796
00:39:57,400 --> 00:40:00,320
mal neu implementieren lassen. 
Ich kann neue Features bauen, 

797
00:40:00,320 --> 00:40:02,800
die sich an alten Specs 
orientieren, weil ich glaube, 

798
00:40:02,800 --> 00:40:05,520
dieses Umdenken, dieser Shift, 
den wir jetzt machen müssen, 

799
00:40:05,520 --> 00:40:11,160
ist, dass das Reine Erstellen 
von Code wahnsinnig schnell und 

800
00:40:11,160 --> 00:40:13,680
wahnsinnig günstig passiert. 
Also ich kann einfach sagen, ah 

801
00:40:13,680 --> 00:40:17,640
nee, da habe ich, glaube ich, da
war die Spezifikation noch 

802
00:40:17,640 --> 00:40:19,720
nicht, noch nicht eindeutig, ich
schmeiß den Code weg und lass 

803
00:40:19,720 --> 00:40:21,680
den innerhalb von einer halben 
Stunde komplett noch mal neu 

804
00:40:21,680 --> 00:40:23,840
bauen. 
Das, was früher viele Tage 

805
00:40:23,920 --> 00:40:26,720
gedauert hätte, also ich glaube,
das ist genau dieser Shift, dass

806
00:40:26,720 --> 00:40:28,920
das. 
Erstellen von wahrscheinlich 

807
00:40:28,920 --> 00:40:32,080
mittelmäßig gutem Code sehr, 
sehr schnell und ungünstig 

808
00:40:32,080 --> 00:40:34,680
geworden ist in unserer 
Industrie und wir können den 

809
00:40:34,680 --> 00:40:39,200
besser machen, indem wir uns 
hinsetzen und die Zeit 

810
00:40:39,280 --> 00:40:42,480
investieren, darin ganz klare 
Anweisungen zu haben. 

811
00:40:42,480 --> 00:40:45,200
Also wir haben einen 
ultraschnellen Ultra fleißigen, 

812
00:40:45,280 --> 00:40:47,920
aber vielleicht nicht ganz so 
erfahrenen Mega Junior 

813
00:40:47,920 --> 00:40:50,720
Developer, der aber irre schnell
coden kann und je besser wir den

814
00:40:50,720 --> 00:40:52,720
anleiten, desto besser sind die 
Ergebnisse und. 

815
00:40:53,080 --> 00:40:54,960
Gerade wenn die, wenn diese 
Anleitung einfach immer wieder 

816
00:40:54,960 --> 00:40:58,160
von vorne von oben nach unten 
abgearbeitet wird, macht es uns 

817
00:40:58,160 --> 00:41:01,160
halt einfacher konsistente 
Software zu bauen. 

818
00:41:01,160 --> 00:41:03,680
Und vor allem habe ich weniger 
von diesen klassischen, ja 

819
00:41:03,680 --> 00:41:06,520
diesen vipe Coding 
Überraschungen, sondern. 

820
00:41:07,080 --> 00:41:09,720
Ich habe dann irgendwie Code, 
den der nachvollziehbar 

821
00:41:09,720 --> 00:41:12,440
entstanden ist und den ich auch 
wirklich auch über längere Zeit 

822
00:41:12,440 --> 00:41:15,680
hinweg in professionellen 
Umgebungen shippen kann und 

823
00:41:15,680 --> 00:41:18,000
drüber hinaus adressiert dieses 
ganze Spectrum Development jetzt

824
00:41:18,000 --> 00:41:19,680
auch noch so ein paar 
Limitationen, die wir halt 

825
00:41:19,680 --> 00:41:22,840
haben, wenn das Kontextwindow 
irgendwie voll ist, dann muss 

826
00:41:22,840 --> 00:41:24,640
das meistens von einem 
Karrierenten zusammengefasst 

827
00:41:24,640 --> 00:41:26,400
werden. 
Ich habe aber bestimmte Dinge ja

828
00:41:26,400 --> 00:41:29,760
in der Datei ausgelagert, so ein
bisschen das Memory des Agenten 

829
00:41:30,160 --> 00:41:32,720
habe ich ja ausgelagert in die 
Dateien, die kann sich jederzeit

830
00:41:32,720 --> 00:41:35,760
immer wieder reingucken und das 
ist auch, warum der ganze Spaß 

831
00:41:35,760 --> 00:41:37,000
funktioniert, weil all diese 
Szene. 

832
00:41:37,120 --> 00:41:39,600
Specs, die wir da schreiben, 
werdet ihr sehen, wenn ihr es 

833
00:41:39,600 --> 00:41:41,040
weg gibt oder irgendwas mal 
aussplitter. 

834
00:41:41,120 --> 00:41:44,480
Da kommen mehrere marktdown 
Dateien raus, die teilweise über

835
00:41:44,480 --> 00:41:47,960
Hunderte von Zeilen haben, 
vielleicht hunderte, aber ne 

836
00:41:47,960 --> 00:41:50,200
irgendwie. 
Auf jeden Fall locker über 100 

837
00:41:50,200 --> 00:41:53,600
Zeilen haben und die werden dann
zum Kontext. 

838
00:41:53,600 --> 00:41:56,360
Die werden mit Reingegeben und 
warum Kontext so wichtig ist. 

839
00:41:56,360 --> 00:41:59,400
Ich sage immer Kontext is king 
wenn ich über ki sowas mit 

840
00:41:59,400 --> 00:42:03,000
Leuten spreche, da haben wir in 
Folge 121 in der Folge Kontext 

841
00:42:03,000 --> 00:42:05,840
engineering ja schon mal schon 
mal im Detail drüber gesprochen 

842
00:42:05,840 --> 00:42:10,040
und der Ansatz ist eben da 
erfolgreich, wo wir wo wir 

843
00:42:10,040 --> 00:42:13,120
vorher gescheitert sind, indem 
wir halt KI so ein paar Zeilen 

844
00:42:13,520 --> 00:42:16,960
prompt mitgegeben haben und dann
irgendwie neu iterieren mussten,

845
00:42:16,960 --> 00:42:19,600
wenn irgendwelche. 
Änderungen da waren und die dann

846
00:42:19,600 --> 00:42:21,000
auch wieder vielleicht 
überraschend waren oder nicht 

847
00:42:21,000 --> 00:42:23,840
mehr zu vorherigen Produkt 
gepasst haben und dass wir quasi

848
00:42:23,840 --> 00:42:26,160
die KI immer wieder durch den 
gleichen Flow schicken können 

849
00:42:26,240 --> 00:42:29,040
sich diese ganzen Sachen im 
Kontext erst durchzulesen und 

850
00:42:29,040 --> 00:42:32,640
dann was zu implementieren, das 
hilft halt eben der KI 

851
00:42:32,640 --> 00:42:35,400
vernünftige Annahmen zu treffen,
die wir ja schon mal validiert 

852
00:42:35,400 --> 00:42:39,000
haben und dann so zu 
implementieren, wie wir das auch

853
00:42:39,000 --> 00:42:41,680
erwarten würden. 
Und eine Sache, die jetzt 

854
00:42:41,840 --> 00:42:44,960
tatsächlich in unserer 
Abhandlung von Specit und 

855
00:42:44,960 --> 00:42:46,840
Spectrip Development noch nicht 
vorkam. 

856
00:42:46,840 --> 00:42:50,160
Was wir vorhin im Kontext des v 
Modells schon erwähnt haben, ist

857
00:42:50,160 --> 00:42:54,200
diese Validierung und. 
Und da hatte Spackit zunächst 

858
00:42:54,200 --> 00:42:56,240
diesen Test Driven Development 
Ansatz. 

859
00:42:56,240 --> 00:42:59,280
Das heißt, wenn ich speckit in 
einer der früheren Versionen 

860
00:42:59,280 --> 00:43:03,400
verwendet habe, dann wurde ich 
quasi gezwungen, immer zunächst 

861
00:43:03,400 --> 00:43:07,800
Tests zu definieren und Tests zu
schreiben, bevor erst die 

862
00:43:07,800 --> 00:43:10,320
Funktionalitäten tatsächlich 
implementiert werden. 

863
00:43:10,400 --> 00:43:13,600
Das hat sich für viele User ein 
bisschen zu. 

864
00:43:14,160 --> 00:43:17,960
Strikt angefühlt, weil in vielen
Fällen wollen wir das nicht, 

865
00:43:17,960 --> 00:43:20,040
oder wir machen gar kein Test 
driven development. 

866
00:43:20,080 --> 00:43:22,760
Das war an der Stelle ein 
bisschen zu Opiniated, das 

867
00:43:22,760 --> 00:43:25,320
heißt, sie sind da jetzt ein 
bisschen von weggegangen, aber 

868
00:43:25,320 --> 00:43:27,520
ich kann natürlich immer noch 
manuell. 

869
00:43:28,040 --> 00:43:30,480
Die Informationen reingeben, 
dass ich für jeden 

870
00:43:31,120 --> 00:43:34,480
entsprechenden Implementierungs 
step zunächst die Test Cases 

871
00:43:34,480 --> 00:43:38,400
definiere und hier weiterhin mit
Test Driven Development arbeite,

872
00:43:38,400 --> 00:43:40,480
weil du hast gerade gesagt, es 
ist vielleicht ein super 

873
00:43:40,480 --> 00:43:42,520
fleißiger, super schneller 
Junior Developer, aber 

874
00:43:42,520 --> 00:43:45,120
dementsprechend müssen wir 
vielleicht die Ergebnisse auch 

875
00:43:45,360 --> 00:43:49,480
noch mal validieren und nicht 
nur gegen die Spezifikation, 

876
00:43:49,480 --> 00:43:52,640
also quasi. 
Den User Acceptance Test, 

877
00:43:52,640 --> 00:43:56,360
sondern tatsächlich auch die 
technische Implementierung muss 

878
00:43:56,360 --> 00:43:58,040
validiert werden. 
Das kann ich natürlich in so 

879
00:43:58,040 --> 00:44:01,680
einem Spec Driven Development 
Ansatz absolut mit aufnehmen, 

880
00:44:01,680 --> 00:44:03,640
wir hatten es gerade nicht 
erwähnt, weil das jetzt nicht 

881
00:44:03,640 --> 00:44:07,480
die Default Einstellungen in 
diesem Tool gerade sind, aber 

882
00:44:07,480 --> 00:44:10,480
natürlich kann ich das auch 
weiterhin genauso machen, wenn 

883
00:44:10,480 --> 00:44:13,960
das mein Entwicklungsansatz ist 
und ich üblicherweise auch Test 

884
00:44:13,960 --> 00:44:17,360
driven development mache. 
Ja, zusammenfassend lässt sich 

885
00:44:17,360 --> 00:44:20,280
sagen. 
Vipe Coating ist so ein bisschen

886
00:44:20,280 --> 00:44:23,320
mehr der agile Weg, wo ich sage,
oh, ich mag irgendwas nicht, was

887
00:44:23,320 --> 00:44:25,440
da rausgekommen ist. 
Dann poppe ich dazu einfach noch

888
00:44:25,440 --> 00:44:27,520
mal neu. 
Ich habe viele Unterbrechungen 

889
00:44:27,520 --> 00:44:29,960
und wenn ich schon coden kann 
ehrlich gesagt auch nicht so 

890
00:44:29,960 --> 00:44:31,840
einen riesigen 
Produktivitätsgewinn. 

891
00:44:31,840 --> 00:44:33,320
Ja, ich tippe irgendwie 
schneller ab, ich komme relativ 

892
00:44:33,320 --> 00:44:35,440
schnell dann irgendwie an den 
Punkt, wo ich selber dann noch 

893
00:44:35,440 --> 00:44:37,840
mal irgendwie mir dann doch 
Gedanken machen muss, weil 

894
00:44:37,840 --> 00:44:40,520
irgendwas nicht funktioniert, 
das ist so Vipe Coating ist für 

895
00:44:40,520 --> 00:44:43,320
mich spannend für jemanden. 
Der oder die noch gar nicht 

896
00:44:43,320 --> 00:44:47,120
programmieren kann, aber für 
richtige Hardcore Developer kein

897
00:44:47,120 --> 00:44:49,320
echter Produktivitätsgewinn. 
Aber das ist genau für mich dann

898
00:44:49,320 --> 00:44:52,000
der Vorteil. 
Der große Vorteil bei so Spec 

899
00:44:52,000 --> 00:44:55,440
Driven Development, dass ich 
eben weniger Unterbrechungen 

900
00:44:55,440 --> 00:44:58,240
habe und weniger Unterbrechungen
von meinem KI Agenten erwarte 

901
00:44:58,320 --> 00:45:01,440
und der somit länger und 
autonomer im Hintergrund laufen 

902
00:45:01,440 --> 00:45:04,640
kann und das teilweise ja auch 
parallel und ich in der Zeit was

903
00:45:04,640 --> 00:45:07,400
anderes machen kann. 
Und ja ich kann 10 von diesen 

904
00:45:07,400 --> 00:45:09,760
Dingern parallel laufen lassen 
und das ist dann die. 

905
00:45:09,920 --> 00:45:12,880
Der richtige und richtige 
Produktivitätsgewinn für mich. 

906
00:45:13,120 --> 00:45:15,840
Und der bekommt da eben dadurch 
zustande, dass ich mich vorher 

907
00:45:16,160 --> 00:45:20,080
einmal hinsetze und versuche, 
alle eventuellen Fragen vorab zu

908
00:45:20,080 --> 00:45:23,440
beantworten. 
Das ganze in technische, aber 

909
00:45:23,440 --> 00:45:27,520
auch nicht technische 
Spezifikationen gieße, die dann 

910
00:45:27,520 --> 00:45:30,400
eventuell auch gemeinsam mit 
einem Agenten erarbeitet und 

911
00:45:30,400 --> 00:45:34,080
gechallenged wird und Teil von 
meinem Kontext wird, also sehr 

912
00:45:34,080 --> 00:45:37,400
viel mehr Fokus auf einen 
richtig richtig, richtig guten 

913
00:45:37,400 --> 00:45:38,960
prompt. 
Da muss ich gar nicht genau 

914
00:45:38,960 --> 00:45:40,480
wissen, wie ich den schreibe, 
weil da kriege ich eben Hilfe 

915
00:45:40,480 --> 00:45:44,200
durch diese ganzen Tools wie 
unter anderem Spec Kit für und 

916
00:45:44,200 --> 00:45:45,680
dann eben diese Autonomität 
habe. 

917
00:45:45,680 --> 00:45:47,840
Das ist für mich so 
zusammenfassend eigentlich der 

918
00:45:47,840 --> 00:45:50,800
große große Benefit von Spec 
driven Development und ich bin 

919
00:45:50,960 --> 00:45:53,040
ganz überzeugt, dass wir davon 
noch mehr sehen werden. 

920
00:45:53,680 --> 00:45:55,920
Ja, und ich habe ein ganz 
interessantes Zitat gelesen. 

921
00:45:55,920 --> 00:45:59,120
Die Sprachmodelle sind super 
darin, Code zu schreiben, aber 

922
00:45:59,120 --> 00:46:01,280
nicht so super darin Gedanken zu
lesen. 

923
00:46:01,640 --> 00:46:04,200
Und von daher ist es, glaube 
ich, super wichtig, dass man 

924
00:46:04,200 --> 00:46:07,120
seine Gedanken, seine 
Intentionen niederschreibt. 

925
00:46:07,280 --> 00:46:12,120
Und Spectrive Development ist 
quasi der Ansatz dafür, seine 

926
00:46:12,120 --> 00:46:15,360
Gedanken und Intentionen in 
einer strukturierten Art und 

927
00:46:15,360 --> 00:46:19,200
Weise so niederzuschreiben, dass
KI Agenten sie aufnehmen und 

928
00:46:19,200 --> 00:46:22,800
umsetzen können. 
Das heißt, wir als Developer 

929
00:46:22,800 --> 00:46:27,600
oder Product Owner definieren 
und dokumentieren unsere 

930
00:46:27,600 --> 00:46:30,000
Absichten. 
Das heißt, wir gehen vielleicht 

931
00:46:30,160 --> 00:46:33,840
tatsächlich perspektivisch ein 
bisschen von der Implementierung

932
00:46:33,840 --> 00:46:39,200
weg als Developer hinzu, dieser 
Spezifizierungsphase und 

933
00:46:39,200 --> 00:46:41,720
investieren dann mehr Zeit am 
Anfang des 

934
00:46:41,720 --> 00:46:45,680
Softwareentwicklungsprozesses, 
schreiben diese Dokumentation 

935
00:46:45,680 --> 00:46:50,720
und Tests und Code entstehen 
dann aus dieser Spezifikation 

936
00:46:51,040 --> 00:46:53,280
und die entsprechenden Tools 
bieten. 

937
00:46:53,800 --> 00:46:56,680
Bieten mir teilweise schon Bild 
in Methoden. 

938
00:46:56,680 --> 00:46:58,880
Du hattest es gerade erwähnt, 
dass es jetzt zum Beispiel bei 

939
00:46:58,880 --> 00:47:02,400
Cloud Code schon so einen Plan 
Mode gibt oder in ad ovds kero, 

940
00:47:02,960 --> 00:47:05,760
aber wenn ich das vielleicht in 
so einem ganzheitlichen Ansatz. 

941
00:47:07,240 --> 00:47:09,680
Nutzen möchte oder über 
verschiedene Tools hinweg, gibt 

942
00:47:09,680 --> 00:47:11,680
es natürlich Open Source 
Projekte wie Speck it. 

943
00:47:11,680 --> 00:47:15,920
Was wir vorhin erwähnt haben. 
Was mich durch diesen Prozess 

944
00:47:16,080 --> 00:47:18,160
leitet und am Ende ist 
vielleicht Speck it für mich 

945
00:47:18,160 --> 00:47:20,480
nicht das richtige, aber dann 
habe ich trotzdem so diesen 

946
00:47:20,480 --> 00:47:23,680
Prozess einmal kennengelernt und
kann den natürlich dann auch mit

947
00:47:23,680 --> 00:47:26,960
eigenen Prompts entsprechend 
nach meinen Wünschen umsetzen. 

948
00:47:27,440 --> 00:47:30,320
Ja, mir kam auch so ein 
abschließender Gedanke und ich 

949
00:47:30,720 --> 00:47:32,800
bin glaube ich selber auch noch 
nicht so ganz happy dadurch, 

950
00:47:32,800 --> 00:47:35,440
dass das alles so Massen am 
Markt Down Files in meinem 

951
00:47:35,440 --> 00:47:39,840
Projekt ist. 
Denn ich finde, eigentlich 

952
00:47:39,840 --> 00:47:44,560
sollten meine JIRA Tickets oder 
github issues schon eigentlich 

953
00:47:44,560 --> 00:47:48,640
90% von meiner Spezifikation 
ausmachen und da finde ich 

954
00:47:48,640 --> 00:47:50,880
gehört das eigentlich rein und 
die müssen vielleicht einfach 

955
00:47:50,880 --> 00:47:54,320
besser werden, weil das ist auch
so der normale Flow und dann 

956
00:47:54,320 --> 00:47:57,120
hätte ich eigentlich gerne diese
Review Phase mit meinem Agenten,

957
00:47:57,120 --> 00:47:59,360
die finde ich, die ist 
eigentlich mein Lieblingsteil 

958
00:47:59,360 --> 00:48:01,800
aus diesem ganzen Specdriven 
Development und. 

959
00:48:01,880 --> 00:48:04,480
Und ich möchte eigentlich diese 
Review Phase mit meinem Agenten 

960
00:48:04,480 --> 00:48:08,160
haben und über diese JIRA 
Tickets oder github issues oder 

961
00:48:08,160 --> 00:48:09,760
was auch immer man verwendet 
drüber gehen. 

962
00:48:09,760 --> 00:48:12,480
Also ich will irgendwie 
vielleicht mit einem MCP Server 

963
00:48:12,480 --> 00:48:14,960
dann das Ganze verknüpfen und 
überprüfen ob meine 

964
00:48:14,960 --> 00:48:19,280
Anforderungen im JIRA Ticket 
alle Details beinhalten die ich 

965
00:48:19,600 --> 00:48:22,880
benötige als Mensch oder auch 
der KI benötigt um das alles 

966
00:48:22,880 --> 00:48:24,600
ordentlich umzusetzen. 
Also eigentlich finde ich 

967
00:48:24,600 --> 00:48:27,760
sollten diese Kids jetzt in der 
nächsten Iteration dahin gehen. 

968
00:48:28,280 --> 00:48:32,320
Sich diese Informationen aus 
meiner Konfluence Dokumentation 

969
00:48:32,320 --> 00:48:34,800
plus dem jeweiligen Ticket und 
so was rauszuziehen, dann zu 

970
00:48:34,800 --> 00:48:37,680
challengen hey, kann ich das 
sogar schon übernehmen als KI? 

971
00:48:37,920 --> 00:48:40,560
Ansonsten würde mir das und das 
und das noch fehlen und dann 

972
00:48:40,560 --> 00:48:42,800
kannst du das auch an mich 
übergeben und ich glaube das 

973
00:48:42,800 --> 00:48:44,520
werde ich mir jetzt irgendwie 
mal angucken, dass ich mir 

974
00:48:44,520 --> 00:48:48,160
irgendwie einen workform 
Hintergrund schreibe oder sowas 

975
00:48:48,640 --> 00:48:51,680
der. 
Unsere giva Tickets oder was 

976
00:48:51,680 --> 00:48:54,520
auch immer man dafür als Work 
Item Management verwendet, die 

977
00:48:54,520 --> 00:48:56,840
eigentlich challengen gucken, ob
die nicht eigentlich die 

978
00:48:56,840 --> 00:49:00,160
Ursprungsquelle für meine, für 
mein Spec Driven Development in 

979
00:49:00,160 --> 00:49:03,440
der Zukunft sind. 
Ja, tatsächlich löst Spec Driven

980
00:49:03,440 --> 00:49:07,360
Development viele der Probleme, 
die wir ohne Vipe Coding nicht 

981
00:49:07,360 --> 00:49:09,600
hätten. 
Und ich glaube, gerade in der 

982
00:49:09,600 --> 00:49:11,520
professionellen 
Softwareentwicklung haben wir 

983
00:49:11,520 --> 00:49:13,840
diese Probleme des Vipe Codings 
aktuell noch nicht. 

984
00:49:13,840 --> 00:49:16,000
Du sagst halt, Anforderungen 
werden. 

985
00:49:16,400 --> 00:49:19,600
Tatsächlich, dokumentiert sie, 
werden in JIRA Tickets oder 

986
00:49:19,600 --> 00:49:21,600
github issues oder wer weiß wo 
abgelegt. 

987
00:49:21,760 --> 00:49:23,960
Ja, wer nicht in dem Detail, 
gerade in dem das Spectrive 

988
00:49:23,960 --> 00:49:26,800
Development macht, über mehrere 
Seiten hinweg genau beschrieben,

989
00:49:26,800 --> 00:49:29,280
was ich da eigentlich haben 
will, mit allen offenen Fragen 

990
00:49:29,280 --> 00:49:31,600
geklärt. 
Ja, wobei wenn du tatsächlich 

991
00:49:31,600 --> 00:49:35,680
dann dir so Requirements aus 
solchen klassischen v Modell 

992
00:49:35,680 --> 00:49:37,680
getriebenen 
Entwicklungsprozessen anschaust,

993
00:49:37,680 --> 00:49:41,080
dann anschaust, dann sind wir in
so einem Detaillierungsgrad und 

994
00:49:41,080 --> 00:49:44,520
ich glaube da kommen dann 
verschiedene Sachen zusammen und

995
00:49:44,520 --> 00:49:48,000
ich glaube jetzt nicht, für 
jeden wird sowas wie Speckhit 

996
00:49:48,000 --> 00:49:50,640
die eigenen Probleme lösen. 
Du sagst gerade du wirst dir 

997
00:49:50,640 --> 00:49:52,960
deinen eigenen Workflow bauen, 
aber ich glaube wir können ganz 

998
00:49:52,960 --> 00:49:56,040
viel Inspiration und Ideen 
rausnehmen, die uns dann 

999
00:49:56,040 --> 00:50:00,320
natürlich in so einer neuen. 
Welt der Softwareentwicklung mit

1000
00:50:00,320 --> 00:50:04,960
KI Agenten helfen also ich habe 
extrem viel gelernt, als ich 

1001
00:50:04,960 --> 00:50:07,360
mich mit dem Thema beschäftigt 
habe und auch gerade dieser 

1002
00:50:07,360 --> 00:50:10,080
historische Abriss, die 
Einordnung hat mir da geholfen, 

1003
00:50:10,080 --> 00:50:12,240
das Ganze so ein bisschen in 
Kontext zu setzen. 

1004
00:50:12,320 --> 00:50:16,000
Ich hoffe, das war für euch 
genauso interessant wie für uns.

1005
00:50:16,360 --> 00:50:19,520
Falls ja, lasst uns gerne auch 
für diese Podcast folgen und 

1006
00:50:19,520 --> 00:50:22,400
allgemein für den Podcast eine 
positive Bewertung da. 

1007
00:50:22,400 --> 00:50:26,240
Das könnt ihr auf Apple Podcast 
oder Spotify machen auf youtube 

1008
00:50:26,240 --> 00:50:29,520
freuen wir uns auch immer auf 
einen Daumen oder ein Abo. 

1009
00:50:30,000 --> 00:50:31,720
Und natürlich freuen wir uns 
auch, wenn ihr Lust habt, uns 

1010
00:50:31,720 --> 00:50:34,800
einen Kaffee auszugeben. 
Den wandeln wir dann direkt in 

1011
00:50:35,200 --> 00:50:38,880
Code oder Podcast folgen um. 
Dazu findet ihr einen Link auch 

1012
00:50:38,880 --> 00:50:41,160
unten in den Shownotes bei mir 
Coffee und. 

1013
00:50:41,160 --> 00:50:43,840
Und ansonsten freuen wir uns am 
allermeisten, wenn ihr uns 

1014
00:50:43,840 --> 00:50:47,680
nächste Woche wieder zuhört. 
Der to do Cast Developer Podcast

1015
00:50:47,680 --> 00:50:51,200
erscheint nämlich jeden Montag 
ganz frisch in dem Podcast 

1016
00:50:51,200 --> 00:50:54,360
Player eurer Wahl, von daher 
habt eine gute Woche wir uns 

1017
00:50:54,360 --> 00:50:57,200
nächste Woche wieder schreibt 
viel Coach und guckt, dass ihr 

1018
00:50:57,200 --> 00:50:59,280
den vielleicht vorher mit Spec 
Kid irgendwie wie die 

1019
00:50:59,280 --> 00:51:02,480
Anforderungen gut spezifiziert 
und habt eine gute Zeit bis 

1020
00:51:02,480 --> 00:51:04,160
nächste Woche ciao. 
Bis dann.