Spec-Driven Development in der Praxis – vom Prompt zum Prozess (Fabian Meyer)

WEBVTT
00:00:00.005 --> 00:00:03.888
Aber trotzdem war der Impact bei uns eigentlich eher gering,
00:00:04.271 --> 00:00:07.575
weil Coding war bei uns eigentlich auch nie so richtig der Flaschenhals.
00:00:07.575 --> 00:00:12.355
Es gibt halt noch sehr, sehr viel, was wir drumherum haben, was uns dann eher
00:00:12.355 --> 00:00:15.133
langsamer gemacht hat, als den eigentlichen Code zu schreiben.
00:00:20.885 --> 00:00:24.725
KI kann Code schreiben, das wissen wir alle. Aber wer im echten Entwicklungsteam
00:00:24.725 --> 00:00:27.799
arbeitet, der weiß auch, Codeschreiben war nie das Problem.
00:00:28.287 --> 00:00:31.932
Die Reibung steckt drumherum. Tickets verstehen, Tests schreiben,
00:00:32.188 --> 00:00:36.555
Tools einbinden, deployen, debuggen und dabei auch noch reviewbare Ergebnisse
00:00:36.555 --> 00:00:38.904
produzieren, das ist eine Herausforderung.
00:00:39.560 --> 00:00:44.535
Unser nächster Speaker, das ist Fabian Mayer. Er ist Chapter Lead und Software
00:00:44.535 --> 00:00:46.166
Engineer bei Eventim Tech.
00:00:46.462 --> 00:00:50.225
Er leitet das Vue Chapter, entwickelt Frontend-Engineers weiter und treibt
00:00:50.225 --> 00:00:51.988
technische Exzellenz voran.
00:00:52.372 --> 00:00:56.232
Als technischer Lead verantwortet er den Event im TIX Online-Shop,
00:00:56.348 --> 00:01:01.606
eine Ticketing-Plattform für über 100 Kunden aus Sport und Festivals. Kennen wir alle.
00:01:01.913 --> 00:01:05.905
Er und sein Team haben ihre KI-Tools wie neue Entwickler eingearbeitet.
00:01:05.905 --> 00:01:09.727
Mit Zugang zu GitLab und Jira, mit wiederverwendbaren Skills,
00:01:09.988 --> 00:01:13.175
mit klaren Standards, vom Ticket bis zum fertigen Feature.
00:01:13.587 --> 00:01:16.945
Wie das genau funktioniert, das wird er uns jetzt erzählen und ich freue mich
00:01:16.945 --> 00:01:20.240
sehr darauf, dass er heute hier ist. Hallo, herzlich willkommen Fabian.
00:01:20.896 --> 00:01:24.181
Ja, erstmal ein herzliches Moin aus Bremen.
00:01:25.545 --> 00:01:30.404
Ja, ich freue mich sehr, den Vortrag heute zu machen. Spec-Driven Development in der Praxis.
00:01:31.263 --> 00:01:36.279
Und ja, bin gespannt auf das Feedback und auch auf die Fragen am Ende.
00:01:36.813 --> 00:01:40.885
Und ja, freue mich heute hier zu sein. Ja, super, klasse. Dann würde ich sagen,
00:01:40.885 --> 00:01:42.065
fang einfach gleich mal an.
00:01:42.385 --> 00:01:46.635
Und genau, wenn ihr Fragen habt, schreibt sie in den Chat. Und am Ende spreche
00:01:46.635 --> 00:01:49.079
ich gerne mit dem Fabian noch einmal darüber. Bis gleich.
00:01:50.989 --> 00:01:54.927
Ja, Spec-Driven Development in der Praxis. Heute soll es so ein bisschen darum
00:01:54.927 --> 00:01:58.836
gehen, wie wir Spec-Driven Development bei Eventim leben.
00:02:00.977 --> 00:02:05.397
Noch ein kleiner Klick auf den richtigen Bildschirm, dann kann es auch losgehen. Ja, Who am I?
00:02:06.177 --> 00:02:11.417
Hendrik hat hier schon eine gute Einleitung gegeben, die hier schon einiges vorwegnimmt.
00:02:11.997 --> 00:02:15.125
Und ja, das Thema des Talks lässt natürlich auch durchblicken.
00:02:15.647 --> 00:02:20.447
Es ist eine gewisse Leidenschaft für Agentic Engineering und auch alle anderen
00:02:20.447 --> 00:02:26.787
KI-Themen dabei und privat auch immer einige Projekte.
00:02:26.787 --> 00:02:32.336
Ich bin Sportfan, ich mache sehr viel mit 3D-Druck und habe auch einen Homeserver
00:02:32.656 --> 00:02:37.377
zu Hause stehen, wo ich immer viele Projekte drauf mache. Da läuft unter anderem
00:02:37.377 --> 00:02:38.937
auch zum Beispiel ein Hermes-Agent.
00:02:39.277 --> 00:02:42.965
Wer das Ganze kennt, wer sich dafür interessiert, da kann ich auch gerne Fragen
00:02:43.337 --> 00:02:47.319
zu beantworten, wie gut sowas funktioniert und wo einem das auch was bringt.
00:02:49.136 --> 00:02:54.137
Genau, Eventim und Tix. Eventim ist Europas führender Ticketing-Anbieter und
00:02:54.537 --> 00:02:58.657
ich arbeite bei unserem Produkt Eventim Tix. Das ist unsere,
00:02:59.317 --> 00:03:04.070
wie schon gesagt, Ticketing-Plattform für Sport und Festivals, über 200 Kunden sogar.
00:03:04.797 --> 00:03:06.577
Da habe ich wohl einen kleinen Typo vorher gehabt.
00:03:07.600 --> 00:03:10.977
Ja, wir arbeiten hauptsächlich mit PHP, haben mehrere Vue-Frontends,
00:03:10.977 --> 00:03:18.159
wir haben auch so einen kleinen Legacy-Core und arbeiten mit fünf Teams zusammen auf einem großen GitLab,
00:03:19.617 --> 00:03:22.917
und entwickeln da unsere Plattform weiter.
00:03:22.917 --> 00:03:27.557
Große Kunden von uns, zum Beispiel fast jeder Verein in der Bundesliga ist tatsächlich
00:03:27.557 --> 00:03:30.640
bei uns, dass man das nicht so sehr sieht, ist Teil des Designs.
00:03:31.457 --> 00:03:36.177
Große Festivals, Rock am Ring, Rock am Park, Hurricane werden sicherlich einige
00:03:36.177 --> 00:03:39.939
kennen. Das ist so der Stack und die Kunden, mit denen wir arbeiten.
00:03:41.669 --> 00:03:46.988
Darum soll es heute allerdings nicht gehen, sondern um erstmal so einen Schritt
00:03:46.988 --> 00:03:51.378
zurück zu gehen, bevor wir jetzt in Spec-Driven Development einsteigen.
00:03:51.758 --> 00:03:55.426
Wie haben wir bei Eventim überhaupt mit KI angefangen?
00:03:56.801 --> 00:04:03.198
Ja, der Start war wahrscheinlich wie bei den meisten, ich nenne es hier die Chat-GPT-Ära,
00:04:03.718 --> 00:04:08.648
nach einigen Gesprächen mit unserer Datenschutz- und IT-Security-Abteilung haben
00:04:08.648 --> 00:04:09.938
wir es dann geschafft für uns,
00:04:10.678 --> 00:04:14.391
Chat-GPT-Enterprise zu bekommen, das haben wir dann auch,
00:04:14.942 --> 00:04:19.468
über unsere komplette Firma direkt ausrollen können und am Anfang war das Ganze,
00:04:19.468 --> 00:04:22.854
sage ich mal, für uns so ein Ersatz oder so ein Begleiter, den wir
00:04:23.295 --> 00:04:27.448
so, wofür wir sonst, sage ich mal, Stack Overflow und Google genutzt haben,
00:04:27.448 --> 00:04:31.558
ich habe hier ein Problem, ich habe da ein Problem, hat das schon mal jemand anderes gehabt,
00:04:32.816 --> 00:04:37.208
dafür haben wir dann hauptsächlich ChatGPT genutzt, auch hin und wieder hat
00:04:37.208 --> 00:04:40.208
man mal ein bisschen Code gemacht, man kopiert ein bisschen Code rein,
00:04:40.208 --> 00:04:43.678
kopiert ein bisschen Code raus, aber hat da noch sehr, sage ich mal,
00:04:43.978 --> 00:04:46.318
den Nachteil, dass man das dann selbst am Ende alles,
00:04:46.823 --> 00:04:48.958
zusammenwurschteln muss, sage ich jetzt mal,
00:04:49.993 --> 00:04:55.358
Und das war natürlich nicht sonderlich produktiv und hat bei uns in der Firma
00:04:55.358 --> 00:04:58.292
jetzt auch nicht den riesigen Impact gehabt, sage ich mal.
00:04:59.918 --> 00:05:04.158
Dann dazwischen, ich gehe nur ganz, ganz kurz drauf ein, war Copilot bei uns.
00:05:04.158 --> 00:05:06.779
Das war dann so ein bisschen autocomplete auf Steroiden.
00:05:07.848 --> 00:05:13.808
Das war allerdings nur ein sehr kurzer Akt bei uns. Wir hatten einmal 200 Lizenzen
00:05:13.808 --> 00:05:18.648
geholt, aber auch da war die Adoption unter den Entwicklern nicht sonderlich groß.
00:05:19.295 --> 00:05:24.409
Und dann kam, sage ich mal, der nächste große Schritt, Codex von ChatGPT und Claude Code.
00:05:24.804 --> 00:05:28.428
Da hatten wir dann das erste Mal Tools, die wirklich in die Code-Basis gehen
00:05:28.428 --> 00:05:31.897
konnten, sich in den richtigen Kontext sammeln konnten, okay,
00:05:32.362 --> 00:05:33.758
was passiert hier überhaupt?
00:05:33.758 --> 00:05:37.368
Dann haben wir so ein bisschen angefangen rumzuspielen, okay,
00:05:37.368 --> 00:05:40.797
es gibt irgendwie einen Planmodus, da kann man sich dann schon mal so ein bisschen,
00:05:41.728 --> 00:05:44.825
drauf vorbereiten, okay, was für eine Änderung möchte ich jetzt überhaupt machen?
00:05:45.313 --> 00:05:50.108
Und dann läuft Claude oder Codex halt los und implementiert das Ganze und da
00:05:50.108 --> 00:05:52.992
wird das Coding dann schon deutlich, deutlich schneller,
00:05:53.468 --> 00:05:57.428
und da haben wir dann hier und da mal einen Bug gefixt, kleinere Features gebaut,
00:05:57.768 --> 00:06:01.275
Refactorings, aber auch noch sehr, sehr im kleinen Rahmen,
00:06:01.856 --> 00:06:06.328
und natürlich auch einiges an Dokumentation geschrieben, wo wir vorher teilweise
00:06:06.328 --> 00:06:10.268
einfach ein bisschen zu faul für waren, kann man auch ganz ehrlich sein und
00:06:10.268 --> 00:06:13.640
das haben wir inzwischen über unsere komplette Firma ausgerollt.
00:06:14.808 --> 00:06:21.587
Jedenfalls bei uns in der Tech. Und ja, aber den großen Big Bang hatten wir da noch nicht.
00:06:22.011 --> 00:06:27.648
Es gibt ja auch zum Beispiel eine Metastudie, die sagt, am Anfang sind erfahrene
00:06:27.648 --> 00:06:33.058
Entwickler, also Senior und drüber, am Anfang 19% langsamer mit KI,
00:06:33.209 --> 00:06:36.082
denken aber tatsächlich selber, dass sie 20% schneller sind.
00:06:37.423 --> 00:06:40.018
Allerdings, wenn man sich einmal so richtig eingearbeitet hat,
00:06:40.018 --> 00:06:43.728
ist man dann wirklich diese 20% schneller, die man sich auch vorstellt.
00:06:43.728 --> 00:06:47.798
Natürlich gibt es viel, sage ich mal, auf LinkedIn und so. Der 10x Engineer,
00:06:47.798 --> 00:06:52.828
das stimmt natürlich nicht so 100%, aber man kann da schon, sage ich mal,
00:06:52.828 --> 00:06:54.842
merken, dass man doch deutlich schneller ist.
00:06:55.689 --> 00:06:58.592
Aber trotzdem war der Impact bei uns...
00:06:59.719 --> 00:07:03.735
Eigentlich eher gering, weil Coding war bei uns eigentlich auch nie so richtig
00:07:03.735 --> 00:07:07.608
der Flaschenhals. Es gibt halt noch sehr, sehr viel, was wir drumherum haben,
00:07:08.965 --> 00:07:12.530
was uns dann eher langsamer gemacht hat, als den eigentlichen Code zu schreiben.
00:07:13.459 --> 00:07:19.200
Und nochmal so ein paar Zahlen. Wir haben das über circa 350 aktive Nutzer ausgerollt.
00:07:19.717 --> 00:07:24.918
Wir nutzen hauptsächlich Claude Code und beziehen die Inference über AWS Bedrock,
00:07:25.226 --> 00:07:29.935
sodass das Ganze dann zwar amerikanische Modelle, aber in Deutschland gehostet
00:07:29.935 --> 00:07:31.286
und dadurch können wir halt auch,
00:07:31.751 --> 00:07:35.054
Anmeldungen mit Microsoft und solche Sachen machen in einer großen Firma.
00:07:35.402 --> 00:07:39.215
Ganz wichtig und auch wenn Tokens, sage ich mal, nicht die beste Metrik ist,
00:07:39.215 --> 00:07:43.195
damit man so ein bisschen Eindruck bekommt, wie weit das bei uns schon verbreitet ist.
00:07:43.195 --> 00:07:50.470
Bei uns verbrauchen wir derzeit circa so 3,7 Millionen Tokens am Tag mit diesen 350 Nutzern.
00:07:52.166 --> 00:07:57.332
Genau. Der Agent schreibt den Code, aber ich mache immer noch, oder du, alles andere.
00:07:58.150 --> 00:08:02.125
Ich muss immer noch in Jira reingehen und mir das Ticket anschauen.
00:08:02.125 --> 00:08:04.600
Okay, wie detailliert ist das Ganze jetzt?
00:08:04.960 --> 00:08:08.623
Ich muss mir im Kopf irgendwie einen Plan machen. Okay, ich möchte jetzt Feature X bauen.
00:08:08.948 --> 00:08:12.315
Da muss ich in das und das Repository rein und dann muss ich mir im Kopf so
00:08:12.315 --> 00:08:14.892
einen Plan machen, okay, wie gehe ich das Ganze an?
00:08:16.621 --> 00:08:21.699
Okay, dann mache ich so ein bisschen einen Plan und lasse Claude das Ganze umsetzen
00:08:21.699 --> 00:08:24.580
und teste das Ergebnis am Ende erstmal selber.
00:08:25.967 --> 00:08:30.199
So, der nächste Schritt ist dann, einen Merge-Request zu erstellen und Reviewer zuweisen.
00:08:30.617 --> 00:08:33.641
Da fangen die Probleme, sage ich mal, ein bisschen an. Ich kriege ein Code-Review,
00:08:33.897 --> 00:08:35.189
12 Open Threads, oh Gott.
00:08:36.300 --> 00:08:38.859
Und dann muss ich ein bisschen Babysitting in der Pipeline machen,
00:08:38.859 --> 00:08:41.809
vielleicht fehlt ein Linter, Code-Style, Unit-Test.
00:08:41.809 --> 00:08:45.109
Wir haben eine sehr große Pipeline in unserem Merge-Request,
00:08:45.429 --> 00:08:48.959
um ganz, ganz viele Checks durchzuführen und da merke ich dann so langsam,
00:08:48.959 --> 00:08:52.269
da hat es an einigen Stellen schon irgendwie ein bisschen gehapert und das Ergebnis
00:08:52.269 --> 00:08:54.834
war dann vielleicht doch nicht ganz so, wie ich mir das erhofft hatte.
00:08:55.438 --> 00:09:00.059
Dann muss ich am Ende noch deployen für unsere QA, dann schlägt vielleicht noch
00:09:00.059 --> 00:09:03.709
einer der automatisierten End-to-End-Tests fehl und am Ende habe ich da,
00:09:03.709 --> 00:09:08.749
sage ich mal, einen ganzen Haufen roter Pipelines, die ich am Ende jetzt trotzdem selber fixen muss.
00:09:08.749 --> 00:09:13.009
Also, ich habe den Code zwar super schnell erstellt, vielleicht in nur ein paar
00:09:13.009 --> 00:09:17.799
Minuten, aber am Ende muss ich dann trotzdem Stunden investieren,
00:09:17.799 --> 00:09:20.579
um das Ganze dann wieder so ein bisschen aufzuarbeiten.
00:09:20.579 --> 00:09:23.619
Das ist jetzt natürlich auch ein bisschen ins Extreme gezogen,
00:09:23.619 --> 00:09:25.850
aber ich glaube, ihr versteht, worauf ich hinaus will.
00:09:27.046 --> 00:09:29.699
Und so viel mehr kommt da noch dazu. Ups, da habe ich ein bisschen geschrumpft.
00:09:29.879 --> 00:09:33.605
Genau. Das Codeschreiben war nie so wirklich der Flaschenhals, zumindest bei uns.
00:09:34.093 --> 00:09:37.689
In Enterprise ist es eher der Prozess rund um den Code, wo man dann wirklich
00:09:37.689 --> 00:09:41.709
stecken bleibt und wo man dann noch ganz viel Einzelarbeit dazu machen muss.
00:09:43.409 --> 00:09:46.658
Genau, der Code wird schnell generiert, durch den Prozess kommen wir immer noch
00:09:46.658 --> 00:09:50.636
langsam. Dann war mein erster Gedanke, hm, dann werfen wir den Prozess halt weg, oder?
00:09:51.106 --> 00:09:53.538
Nee, das geht natürlich nicht und das wollen wir auch nicht,
00:09:53.538 --> 00:09:57.538
weil dieser Prozess ist über Jahre entstanden und es hat auch seine Gründe,
00:09:57.538 --> 00:10:02.705
warum wir da verschiedene Gates drin haben, warum wir Code Reviews machen, warum wir QA machen.
00:10:04.075 --> 00:10:07.128
Das ist dann sozusagen bei uns immer der Human in the Loop,
00:10:07.128 --> 00:10:10.378
also, dass wir halt beim Code Review und QA gucken, wir, okay,
00:10:10.378 --> 00:10:13.018
werden unsere Standards, Guardrails eingehalten,
00:10:13.961 --> 00:10:17.988
ist das Ganze sicher, können wir das jetzt so auf unser Produktionssystem deployen,
00:10:17.988 --> 00:10:19.998
ohne dass wir Security-Issues bekommen.
00:10:20.398 --> 00:10:24.338
Wir haben auch eine komplexe Infrastruktur. Wir haben sehr viele verschiedene
00:10:24.338 --> 00:10:28.932
Repos, die zusammen mit vielen Applikationen eine Plattform bilden.
00:10:29.547 --> 00:10:33.038
Und wir haben auch viele etablierte Prozesse in Jira, in GitLab,
00:10:33.038 --> 00:10:34.998
wie wir Merge Requests erstellen und alles.
00:10:35.671 --> 00:10:40.998
Das soll halt erstmal weiterhin so bleiben. Wir wollen Teilautomatisierung,
00:10:40.998 --> 00:10:43.681
sage ich jetzt mal, weil wir den Human in the Loop ja behalten wollen,
00:10:44.395 --> 00:10:47.402
aber wie kommen wir dahin, dass wir nicht nur den Code generieren,
00:10:47.698 --> 00:10:53.048
sondern wirklich den Software Development Lifecycle so ein Stück weit automatisieren,
00:10:53.048 --> 00:10:56.394
dass wir halt da nochmal ordentlich an Geschwindigkeit gewinnen.
00:10:59.012 --> 00:11:02.837
So, jetzt erstmal ein kleiner Überblick, was ist Spec-Driven Development?
00:11:03.499 --> 00:11:05.738
Ist es nur ein Buzzword? Jein.
00:11:09.098 --> 00:11:12.718
So ein bisschen ist es ein Buzzword, weil es am Ende eigentlich gar nicht so
00:11:12.718 --> 00:11:18.052
kompliziert ist, aber trotzdem halt in der Entwicklung wirklich sehr, sehr helfen kann.
00:11:18.731 --> 00:11:22.592
Im Grunde teilt sich das Ganze immer in drei Schritte auf.
00:11:23.074 --> 00:11:28.278
Spec Code Verify, das ist auch der Name von dem Workshop, der morgen stattfindet,
00:11:28.278 --> 00:11:31.276
deswegen dachte ich, benutze ich das nochmal, weil es einfach so perfekt passt.
00:11:31.990 --> 00:11:36.628
Also wir starten quasi ähnlich wie beim Plan Mode, nur bei Spec Driven Development
00:11:36.628 --> 00:11:38.884
nennt man es dann Spec oder Spezifikation.
00:11:39.302 --> 00:11:43.748
Der eine mag jetzt vielleicht so ein bisschen an Wasserfallmodell oder Pflichten-Lastenheft
00:11:43.748 --> 00:11:46.471
denken, aber glaub mir, es ist ein bisschen anders.
00:11:46.878 --> 00:11:49.888
Es läuft dann am Anfang so ab, dass ich einen detaillierten Plan,
00:11:49.888 --> 00:11:55.808
wie ich Feature X in CodeBase X implementieren will, zusammen mit meinem Agenten,
00:11:55.808 --> 00:12:00.020
ob das jetzt Claude Code ist oder Codex, ist am Ende eigentlich egal.
00:12:00.734 --> 00:12:06.378
Was allerdings noch wichtig ist, dieser Plan wird am Ende, die ganzen Entscheidungen,
00:12:06.378 --> 00:12:08.553
die da drin sind, die werden von mir getroffen.
00:12:09.064 --> 00:12:13.412
Der Agent stellt mir nur die Fragen, um das Ganze halt zu machen.
00:12:13.848 --> 00:12:17.578
Im nächsten Schritt lassen wir den Agenten das Ganze dann in einer neuen Session,
00:12:17.578 --> 00:12:22.282
da gehe ich gleich nochmal drauf ein, implementieren und das Ganze basiert dann auf der Spec.
00:12:22.868 --> 00:12:25.881
Und der letzte Schritt, wahrscheinlich auch mit Abstand der schwerste,
00:12:26.305 --> 00:12:31.936
verify, dass wir den Agenten den Code gegen mehrere Quality Gates verifizieren lassen.
00:12:32.371 --> 00:12:35.538
Quality Gates ist jetzt allgemein, das kann Code Review sein,
00:12:35.538 --> 00:12:40.398
Linting, Unit Test, so viel wie möglich, sage ich mal, um am Ende sicher gehen
00:12:40.398 --> 00:12:45.495
zu können, dass der Code, der da rauskommt, gut ist von der Qualität her und auch funktioniert.
00:12:47.905 --> 00:12:51.815
Warum das Ganze überhaupt? Warum machen wir überhaupt Spec-Driven Development?
00:12:51.815 --> 00:12:55.295
Was ist, sage ich mal, der Grund, dass das besser funktioniert,
00:12:55.295 --> 00:12:59.509
als einfach, ich prompte ein Prompt nach dem anderen, bis es funktioniert?
00:13:00.218 --> 00:13:03.225
Das kleine Bild, was ich euch hier eingeblendet habe, wenn ihr Claude Code nutzt,
00:13:03.225 --> 00:13:06.139
könnt ihr euch das auch anzeigen lassen mit Slash-Context.
00:13:06.754 --> 00:13:12.733
Das ist der Kontext. Jedes KI-Modell hat ein gewisses Kontext-Window,
00:13:13.505 --> 00:13:15.206
wo X-Tokens reinpassen.
00:13:15.485 --> 00:13:20.415
Bei den Claude-Modellen ist es normalerweise 200.000 Tokens oder eine Million
00:13:20.415 --> 00:13:23.008
Tokens, wenn man das Größere wählt.
00:13:23.519 --> 00:13:27.008
Ich glaube, bei Codex sind es 276.000 oder sowas.
00:13:27.942 --> 00:13:31.895
Und das Ganze ist so, je voller dieser Kontext ist, desto schlechter ist die
00:13:31.895 --> 00:13:34.065
Qualität vom Output des LLMs.
00:13:34.065 --> 00:13:37.325
Das kommt einfach dadurch, das ist so ein bisschen wie beim Menschen,
00:13:37.325 --> 00:13:40.855
wenn ich acht Stunden gearbeitet habe und dann in der letzten halben Stunde
00:13:40.855 --> 00:13:42.778
versuche nochmal ein Code Review zu machen,
00:13:43.191 --> 00:13:46.407
dann ist mein Kopf von dem ganzen Tag schon so voll mit Informationen,
00:13:46.807 --> 00:13:49.715
dass dieses Code Review wahrscheinlich am Ende nicht das Beste ist.
00:13:50.133 --> 00:13:54.325
Und mit dem Agenten ist es ganz ähnlich. Solange der Kontext noch leer ist,
00:13:54.325 --> 00:14:01.345
da ist es 7 Uhr morgens, zwei Kaffee getrunken, man ist total dabei und kann
00:14:01.345 --> 00:14:04.181
jedes Detail verstehen und noch ganz viel Informationen aufnehmen.
00:14:04.872 --> 00:14:09.895
Sobald der Tag zu Ende ist oder der Nachmittag kommt, ist es dann schon ein bisschen schwieriger.
00:14:09.895 --> 00:14:14.439
Und Spec-Driven Development gibt uns halt die Möglichkeit, durch dieses Spec
00:14:14.718 --> 00:14:19.835
quasi eine neue Unterhaltung mit dem Agenten zu starten, wo er dann eine Datei
00:14:19.835 --> 00:14:23.704
hat, wo eigentlich schon alle Infos drinstehen, die er am Ende wissen muss.
00:14:24.249 --> 00:14:29.615
Und die Qualität dieses Plans oder dieser Spec ist auch sehr stark verbunden
00:14:29.615 --> 00:14:32.162
mit der Qualität des Codes, der am Ende dabei rauskommt.
00:14:34.896 --> 00:14:35.656
Es gibt verschiedene,
00:14:37.876 --> 00:14:41.356
Spec-Driven Development Frameworks da draußen. Ich habe jetzt hier mal so ein
00:14:41.356 --> 00:14:46.034
paar aufgelistet. OpenSpec, BMAD, PlanAct, SpecKit von GitHub.
00:14:46.818 --> 00:14:51.404
Die haben alle verschiedene Schritte, die meist durch Skills implementiert werden.
00:14:52.222 --> 00:14:56.196
Aber wenn man sich so ein bisschen die Namen des Ganzen durchliest,
00:14:56.196 --> 00:15:02.376
Discover, Specify, Validate, dann haben wir Brainstorm, Architect,
00:15:02.676 --> 00:15:06.311
Plan, Reflect, Spec, Test, Ship.
00:15:07.292 --> 00:15:11.766
Was fällt dabei auf? Am Ende ist es eigentlich immer derselbe Vorgang.
00:15:11.766 --> 00:15:15.193
Wir haben irgendeine Spezifikation oder Plan, der dabei rauskommt.
00:15:15.477 --> 00:15:20.316
Der Agent implementiert das Ganze und am Ende versuchen wir zu reflektieren,
00:15:20.316 --> 00:15:22.304
zu verifizieren, zu validieren.
00:15:23.236 --> 00:15:26.976
Da kann man dann, kann man am Ende nennen, wie man will, aber im Grunde sind
00:15:26.976 --> 00:15:30.036
es immer diese drei Schritte, die das Ganze durchläuft.
00:15:31.450 --> 00:15:34.504
Genau. Da kann man noch mehrere Schritte dazwischen packen.
00:15:35.616 --> 00:15:42.079
Das ist so ein bisschen dann auch nach Gusto. Genau. Für uns waren die ein guter Startpunkt.
00:15:42.764 --> 00:15:46.876
Wir haben einige davon ausprobiert, haben auch hin und wieder mal was angepasst.
00:15:47.623 --> 00:15:51.570
Und das ist, glaube ich, auch ein ganz wichtiger Schritt, den ich jedem ans Herz legen würde.
00:15:52.795 --> 00:15:57.216
Guckt euch die Sachen mal an, geht auch wirklich rein in die Skills, die da drinstehen.
00:15:57.216 --> 00:16:02.266
Am Ende sind das alles nur Textdateien, sage ich mal. Da steckt wirklich keine
00:16:02.266 --> 00:16:05.606
Magie drin und man braucht auch keine Angst zu haben, da hin und wieder mal
00:16:05.606 --> 00:16:09.990
was zu verändern, um sich an seinen eigenen Workflow anzupassen.
00:16:11.964 --> 00:16:15.121
Für uns passte aber nichts davon so richtig.
00:16:15.941 --> 00:16:18.911
Viele Frameworks haben irgendwie schon eingebaut, dass sie so ein bisschen von
00:16:18.911 --> 00:16:21.077
einem Workflow in GitHub ausgehen.
00:16:21.537 --> 00:16:25.258
Das hatten wir allerdings nicht. Wir nutzen GitLab und Jira für unsere Tickets.
00:16:26.069 --> 00:16:31.441
Viele gehen auf das Thema Deploy gar nicht ein oder haben ein sehr einfaches
00:16:31.441 --> 00:16:35.699
Deploy da drin. Wir hingegen hatten eine sehr komplexe Multi-App-Infrastruktur,
00:16:36.122 --> 00:16:38.485
die wir halt auch irgendwo hin deployen müssen.
00:16:40.447 --> 00:16:44.412
Oft sind die konzipiert für die Arbeit in einem einzelnen Repository,
00:16:44.638 --> 00:16:49.331
aber wie es in vielen größeren Firmen so ist, hat man eine ganze Armada von
00:16:49.331 --> 00:16:52.651
Repositories, die mit unterschiedlichen Beziehungen zueinander sind.
00:16:52.651 --> 00:16:56.951
Das eine ist eine Library für was anderes, die sind über eine API verbunden,
00:16:56.951 --> 00:16:58.652
die kommunizieren Event-Driven.
00:16:59.331 --> 00:17:04.840
Diese ganzen Infos, sage ich mal, muss man auch noch irgendwie mit einbinden,
00:17:05.287 --> 00:17:06.771
damit das Ganze gut funktioniert.
00:17:08.299 --> 00:17:12.751
Und sie setzen meistens auch einen relativ flexiblen Prozess insgesamt in der
00:17:12.751 --> 00:17:16.031
Softwareentwicklung voraus, während wir halt, ich möchte nicht sagen starr,
00:17:16.031 --> 00:17:19.611
aber einen etablierten Enterprise-Prozess halt haben, den wir in unserem Team
00:17:19.611 --> 00:17:20.763
halt auch entwickelt haben.
00:17:22.272 --> 00:17:27.351
Und wir wollten diesen Prozess nicht aufgeben, sondern wollten ihn teilautomatisieren
00:17:27.659 --> 00:17:29.721
und haben uns am Ende dann dafür
00:17:29.721 --> 00:17:33.251
entschieden, dass wir unser eigenes Spec-Driven-Development-Framework
00:17:33.251 --> 00:17:36.521
bauen wollen, damit wir auch verstehen, womit wir arbeiten.
00:17:36.521 --> 00:17:41.471
Das ist uns persönlich immer ganz wichtig. Wir nutzen auch im Code selten Frameworks,
00:17:41.471 --> 00:17:44.771
die, sage ich mal, viel Magic in Anführungszeichen haben.
00:17:44.771 --> 00:17:50.461
Wir wollen immer bis zum, sage ich mal, letzten Punkt alles verstehen und dachten
00:17:50.461 --> 00:17:53.111
dann, okay, wir bauen jetzt unser eigenes, dann verstehen wir,
00:17:53.111 --> 00:17:56.555
womit wir arbeiten und haben etwas, was genau auf uns zugeschnitten ist.
00:17:58.848 --> 00:18:01.774
Ja, und Henrik hat es ja am Anfang schon so ein bisschen eingeleitet.
00:18:02.093 --> 00:18:05.584
Wir haben uns dann echt mal gefragt, welche Infos braucht unser Agent,
00:18:05.584 --> 00:18:10.644
um produktiv zu sein und haben da so einige Parallelen zur generellen Einarbeitung
00:18:10.644 --> 00:18:12.089
von Entwicklern bei uns gesehen.
00:18:12.774 --> 00:18:16.884
Der Agent braucht erstmal den Zugang zu Jira. Er muss irgendwie Tickets lesen
00:18:16.884 --> 00:18:19.467
können, er muss hier und da auch mal einen Kommentar machen können,
00:18:19.763 --> 00:18:23.577
Tickets verschieben von Open zu In-Development und zu Ready-for-Review.
00:18:24.129 --> 00:18:27.634
Er braucht Zugang zu unserem GitLab, muss Branches erstellen können,
00:18:27.634 --> 00:18:30.826
Merge-Requests aufmachen, Pipelines ansehen, Code-Review machen.
00:18:31.651 --> 00:18:34.675
Er muss unsere komplexen Multi-App-Deployments ausführen können.
00:18:35.354 --> 00:18:38.727
Er braucht auch ein Pipeline-Monitoring, sodass er auch eine Merge-Request,
00:18:39.151 --> 00:18:42.669
die er erstellt hat, sich anschauen kann, auf Fehler entsprechend reagieren kann.
00:18:43.429 --> 00:18:47.104
Und er sollte am Ende, so wie wir das auch machen, Dokumentation schreiben und
00:18:47.104 --> 00:18:48.677
zwar genau so, wie wir das machen.
00:18:50.024 --> 00:18:54.134
Und am Ende, was sonst vielleicht der nette Kollege ist, der einem zur Einarbeitung
00:18:54.134 --> 00:18:57.774
zugewiesen ist, ist hier dann der Human in the Loop, was so ein bisschen das
00:18:57.774 --> 00:18:59.039
Pairing repräsentiert.
00:18:59.898 --> 00:19:03.619
Das brauchen wir alles und das klingt am Ende schon sehr stark danach,
00:19:03.828 --> 00:19:07.973
als wir bauen, wir arbeiten einen neuen Kollegen ein. Und im Grunde ist es auch,
00:19:08.658 --> 00:19:12.965
sehr nah da dran. Nur nutzen wir da ein wenig andere Tools für.
00:19:14.462 --> 00:19:19.657
Es gibt da zwei große Sachen, die man dafür nutzen kann, Agent-Skills und MCP.
00:19:20.417 --> 00:19:24.342
Skills sind, sage ich mal, der Low-Effort-Way, das ist eigentlich relativ easy,
00:19:24.342 --> 00:19:27.185
das sind am Ende einfach Markdown-Dateien mit Anweisungen.
00:19:27.789 --> 00:19:30.782
Deswegen habe ich auch gesagt, bei den Spec-Driven-Development-Frameworks,
00:19:30.782 --> 00:19:33.232
die man da draußen findet, einfach mal reingucken.
00:19:33.232 --> 00:19:38.192
Am Ende ist das alles nur, sage ich mal, Prompts in Text-Dateien oder in Markdown-Dateien
00:19:38.192 --> 00:19:43.222
in dem Fall. Das ist halt super, um Teamworkflows und Prozesse abzubilden.
00:19:43.222 --> 00:19:46.202
Die sind auch sehr leicht zu reviewen, weil es am Ende halt einfach nur Text ist.
00:19:46.794 --> 00:19:51.342
MCP ist dann schon ein leicht höheres Investment. Das würde ich empfehlen,
00:19:51.342 --> 00:19:54.370
wenn die Tool-Anbindung so ein bisschen komplizierter ist.
00:19:55.732 --> 00:19:58.915
Zum Beispiel GitHub bietet einen guten MCP GitLab auch.
00:19:59.710 --> 00:20:03.867
Da ist es nur wichtig, darauf zu achten, je mehr Tools so ein MCP hat,
00:20:04.610 --> 00:20:08.325
desto voller wird der Kontext halt automatisch.
00:20:09.079 --> 00:20:13.782
Wir nutzen tatsächlich beides. Wir benutzen hauptsächlich Skills für große Teile
00:20:13.782 --> 00:20:16.532
unseres Prozesses und auch für einige Tools.
00:20:16.532 --> 00:20:19.932
Man kann Skills auch sehr gut benutzen, um gewisse CLI-Tools,
00:20:19.932 --> 00:20:23.526
bei GitLab zum Beispiel G-Lab, es gibt auch für Jira einige CLI-Tools,
00:20:24.321 --> 00:20:26.712
da sieht dieser Skill dann so aus, dass er so ein bisschen erklärt,
00:20:26.712 --> 00:20:32.162
wie ist das Ganze zu benutzen und MCP dann entsprechend für komplexere Anbindungen,
00:20:32.162 --> 00:20:34.863
wie zum Beispiel Logs aus Grafana auslesen.
00:20:36.767 --> 00:20:39.812
Genau, dann haben wir uns noch Gedanken gemacht, okay, wie können wir jetzt
00:20:39.812 --> 00:20:44.362
unseren Prozess abbilden? Wie lesen wir die Jira-Tickets? Welche Details stehen
00:20:44.362 --> 00:20:46.908
da drin? Wie refined sind unsere Tickets eigentlich?
00:20:47.425 --> 00:20:51.285
Wie dokumentieren wir genau? Welche Guidelines und Guardrails haben wir?
00:20:51.697 --> 00:20:55.542
Welche Commands muss der Agent auch ausführen können, wo er möglichst dann nicht
00:20:55.542 --> 00:20:59.432
uns nochmal fragen muss, ob wir das Ganze machen und er muss irgendwie unser
00:20:59.432 --> 00:21:01.932
gesamtes Developer-Setup bedienen können.
00:21:02.361 --> 00:21:05.722
Da ist es auch wichtig, lokale Ausführungen zu bevorzugen, weil dann kann der
00:21:05.722 --> 00:21:10.512
Agent einfach schneller iterieren auf dem Ganzen, als wenn er jetzt jedes Mal,
00:21:10.512 --> 00:21:14.470
sage ich mal, zu GitLab gehen muss und gucken muss, wie die Pipeline aussieht.
00:21:15.504 --> 00:21:20.782
So, unser SDD-Framework. Das ist, wie ihr schon vorher wahrscheinlich vermutet
00:21:20.782 --> 00:21:26.892
habt, gibt es da drei Phasen, die sich in mehrere Skills aufteilen und das sieht dann konkret so aus.
00:21:27.269 --> 00:21:30.912
In unserem Spec-Skill holen wir das Jira-Ticket, recherchieren,
00:21:31.412 --> 00:21:35.123
in der Code-Basis, das kann ein oder mehrere Repositories sein,
00:21:35.547 --> 00:21:40.282
dann spezifizieren wir gemeinsam und das ist tatsächlich auch ein relativ langer
00:21:40.282 --> 00:21:43.652
Teil, also es ist dann nicht so, dass man zwei, drei Fragen beantwortet,
00:21:43.652 --> 00:21:46.202
sondern das kann bei einem komplexen Feature auch mal so sein,
00:21:46.202 --> 00:21:48.532
dass da so 70 Fragen rauskommen.
00:21:48.532 --> 00:21:51.092
Das ist kein Scherz, das dauert dann wirklich ein bisschen, da muss man sich
00:21:51.092 --> 00:21:54.912
hinsetzen, so wie früher, wenn man sich, sage ich mal, mit dem ganzen Team vielleicht
00:21:54.912 --> 00:21:58.123
überlegt hat, okay, wie wollen wir dieses große neue Feature,
00:21:58.932 --> 00:22:03.692
umsetzen, setzt man sich jetzt mit seinem Claude Code oder seinem Codex hin und,
00:22:04.172 --> 00:22:07.271
versucht gemeinsam halt ein Shared Understanding zu bekommen,
00:22:07.544 --> 00:22:09.262
wie das Ganze jetzt am Ende aussehen soll.
00:22:09.530 --> 00:22:13.877
Und der Output davon ist dann die strukturierte Spec als Kontext-Artefakt.
00:22:14.923 --> 00:22:18.451
Als nächstes kommt dann der Codeschritt. Da machen wir eine neue Session auf,
00:22:18.451 --> 00:22:20.210
um den Kontext zu schonen.
00:22:21.131 --> 00:22:25.851
Wir arbeiten da ausschließlich nach TDD. Da gehe ich gleich nochmal drauf ein,
00:22:25.851 --> 00:22:29.511
warum das für die Agents sehr hilfreich ist. Wir nutzen Conventional Commits.
00:22:29.511 --> 00:22:32.883
Wir lassen den Agenten auch direkt auf unser GitLab pushen.
00:22:33.063 --> 00:22:36.360
Natürlich nicht auf den Main, sondern auf seinen Feature-Branch dann.
00:22:36.958 --> 00:22:41.555
Und der Agent arbeitet dann im SDD-Framework autonom, bis alle Tasks erledigt sind.
00:22:42.322 --> 00:22:46.111
Und am Ende steht dann der Verify-Step. Wir gleichen ab mit der Spec,
00:22:46.111 --> 00:22:49.151
die wir vorher geschrieben haben. Haben wir jetzt wirklich das implementiert,
00:22:49.151 --> 00:22:50.809
was wir auch implementieren wollten?
00:22:51.267 --> 00:22:54.901
Lassen lokale Checks oder auch Remote-Checks durchlaufen, je nachdem,
00:22:54.901 --> 00:22:56.261
wie das Ganze aufgestellt ist.
00:22:56.261 --> 00:22:59.571
Wir lassen dann Code-Review wieder durch einen frischen Agenten oder eine frische
00:22:59.571 --> 00:23:03.581
Session durchführen, damit das Ganze auch nicht beeinflusst ist von dem Ganzen,
00:23:03.581 --> 00:23:05.161
was er da vorgemacht hat.
00:23:05.161 --> 00:23:09.771
Und der letzte Schritt, der auch nochmal sehr viel bringt, aber auch der komplizierteste
00:23:09.771 --> 00:23:11.167
teilweise umzusetzen ist,
00:23:11.503 --> 00:23:14.901
er nutzt Playwright, um wirklich auf unsere Development-Maschinen zu gehen,
00:23:14.901 --> 00:23:18.621
wo das Feature dann deployed ist und das dann wirklich so zu testen,
00:23:18.621 --> 00:23:22.711
wir nennen es bei uns mal DevTest, ich gehe auf die Maschine und mache den Idiotentest,
00:23:22.711 --> 00:23:24.767
funktioniert das Ganze überhaupt, was ich hier gebaut habe,
00:23:25.167 --> 00:23:27.721
das macht Claude dann auch entsprechend automatisch.
00:23:28.917 --> 00:23:29.776
Gehen wir ins Detail.
00:23:31.581 --> 00:23:35.048
Genau, für die Spec. Wir müssen erstmal Kontext sammeln. Was wollen wir tun?
00:23:35.048 --> 00:23:36.863
Wir müssen den Kontext aus Jira holen.
00:23:37.188 --> 00:23:41.019
Was ist das Ticket, das Feature, was für Akzeptanzkriterien gibt es,
00:23:41.385 --> 00:23:44.978
Beschreibungen, verlinkte Tickets, eventuell noch Screenshots,
00:23:44.978 --> 00:23:47.144
die der Agent dann entsprechend runterladen kann.
00:23:49.088 --> 00:23:52.898
Womit arbeiten wir gerade überhaupt das heißt, er muss sich die Code-Basis angucken,
00:23:52.898 --> 00:23:57.378
verwandte Komponenten, Patterns, Architektur in dem Teil, wo das Ganze eingebaut wird,
00:23:58.046 --> 00:24:02.608
und dann kommt wie gesagt das Brainstorming und QA, der Agent erstellt Empfehlungen
00:24:03.038 --> 00:24:06.098
also es gibt dann immer quasi, man hat dann das bestimmt schon mal gesehen,
00:24:06.098 --> 00:24:10.878
so eine Fragenauswahl und es gibt auch immer eine Sache, die der Agent empfiehlt
00:24:10.878 --> 00:24:14.741
aber da muss man vorsichtig sein, da darf man sich nicht immer drauf verlassen,
00:24:15.477 --> 00:24:19.288
und das Ziel des Ganzen ist, ein gemeinsames Verständnis zu erarbeiten,
00:24:19.288 --> 00:24:21.276
wie das Ganze am Ende implementiert wird.
00:24:21.816 --> 00:24:25.898
Und der Output ist dann die strukturierte Spec, die enthält die Recherche,
00:24:25.898 --> 00:24:29.461
Einschränkungen, Anforderungen, Entscheidungen, die wir getroffen haben,
00:24:29.821 --> 00:24:33.748
Aufgaben, Verifikationskriterien, quasi alles, was der Agent braucht,
00:24:33.748 --> 00:24:35.800
um das später dann auch wirklich umzusetzen.
00:24:36.954 --> 00:24:40.165
Genau, die Spec ist am Ende dann der Transfer des ganzen Kontexts.
00:24:40.717 --> 00:24:44.420
Ohne die müssten wir dann in der nächsten Session quasi alles nochmal herleiten.
00:24:45.802 --> 00:24:49.206
Genau, ich habe jetzt hier mal so ein bisschen aufgebaut, wie das Ganze dann
00:24:49.206 --> 00:24:54.036
ungefähr aussieht im Claude Code. Bei uns heißt der Skill, den wir dafür nutzen,
00:24:54.036 --> 00:24:59.086
G-Plan, weil unser Team, das Grizzlies-Team, heißt, wir haben immer so die Teamnamen
00:24:59.086 --> 00:25:00.226
von gewissen Sportteams.
00:25:01.667 --> 00:25:05.666
Und ja, Tix ist dann in dem Fall unser Jira-Projekt, also geht es dann los,
00:25:05.666 --> 00:25:10.443
er lädt das Ganze aus Jira, okay, wir sollen eine Event-Filter-Komponente hinzufügen.
00:25:11.198 --> 00:25:14.866
In den Akzeptanzkriterien steht, okay, da muss es einen Datumsfilter geben,
00:25:14.866 --> 00:25:17.373
einen Kategoriefilter und einen Filter nach dem Ort.
00:25:18.209 --> 00:25:21.146
Dann geht er in den Code rein, liest wirklich die Komponenten,
00:25:21.146 --> 00:25:25.883
die wirklich was damit zu tun haben. Es existiert schon eine Filter-Bar in Vue und eine Eventlist.
00:25:26.371 --> 00:25:27.932
Diese Komponenten findet er dann.
00:25:28.954 --> 00:25:34.716
Dann jetzt das interaktive Q&A in sehr, sehr klein. Wie wollen wir den Filterstate
00:25:34.716 --> 00:25:35.932
in der URL persistieren?
00:25:36.262 --> 00:25:38.863
Ja, lass uns das als Query-Parameter machen, das klingt gut.
00:25:39.519 --> 00:25:42.586
Was sollen wir machen, wenn keine Ergebnisse angezeigt werden?
00:25:42.586 --> 00:25:44.802
Dann machen wir einen Empty State mit Reset Link.
00:25:46.347 --> 00:25:49.963
Und dann wird am Ende die strukturierte Spezifikation geschrieben.
00:25:50.422 --> 00:25:54.334
Und was dann auch noch ganz cool ist, eine Zusammenfassung der ganzen Spezifikation
00:25:54.334 --> 00:25:57.957
postet er dann noch als Kommentar an unser Jira-Ticket, sodass wir später auch
00:25:58.276 --> 00:26:00.116
das Ganze entsprechend dokumentiert haben.
00:26:00.749 --> 00:26:04.084
Und dieses Spec ist dann am Ende der Vertrag zwischen dir und dem Agenten.
00:26:04.084 --> 00:26:06.074
Der ist natürlich an der Stelle nicht rechtsbindend.
00:26:07.558 --> 00:26:12.758
Genau, schauen wir uns mal an, wie das dann aussieht. Wir haben hier am Ende eine Markdown-Datei.
00:26:13.211 --> 00:26:16.934
Und wie das Ganze hier aussieht, kann man natürlich frei festlegen,
00:26:16.934 --> 00:26:21.664
das ist dann später Part von dem Specify-Skill, bei uns hat das Ganze einen
00:26:21.664 --> 00:26:23.274
Titel, einen Status, welche,
00:26:23.934 --> 00:26:29.064
Jira dazu gehört, wie der Branch heißen wird und auch eine Liste von Repositories.
00:26:29.511 --> 00:26:33.544
Das hier ist jetzt natürlich sehr stark runtergedampft, damit wir da jetzt gemeinsam
00:26:33.544 --> 00:26:36.544
raufgucken können, normalerweise steckt hier sehr, sehr viel Detail drin und
00:26:36.544 --> 00:26:38.138
das kann auch über mehrere Seiten gehen.
00:26:39.200 --> 00:26:42.014
Sehen wir, der Online-Shop zeigt Events ohne Filtermöglichkeit an.
00:26:42.014 --> 00:26:44.221
Kunden brauchen Datum, Kategorie, Ortfilter.
00:26:44.558 --> 00:26:48.244
Jetzt hat er hier seine Research Findings aus dem ganzen Code.
00:26:48.511 --> 00:26:51.684
Dann hat er hier seine Requirements. Okay, wir brauchen Datumfilter,
00:26:51.684 --> 00:26:54.397
Kategoriefilter, Ortfilter und so weiter und so fort.
00:26:55.036 --> 00:27:00.174
Daraus leitet er dann verschiedene Tasks ab und guckt auch, wie er das Ganze
00:27:00.174 --> 00:27:02.501
angeht und wann das auch wirklich fertig ist.
00:27:04.039 --> 00:27:08.524
Und am Ende hat er dann seine Verifikations-Step. In dem Fall führt er die Test-Suite
00:27:08.524 --> 00:27:13.094
aus, macht ein Linting, macht ein Type-Check und hat hier auch Akzeptanzkriterien,
00:27:13.094 --> 00:27:15.921
die dann wiederum verbunden sind mit den Requirements.
00:27:16.519 --> 00:27:19.770
Hier steht das für Must-Have, Should-Have und Won't-Do.
00:27:20.077 --> 00:27:23.380
Also er macht jetzt zum Beispiel kein serverseitiges Caching der Filterkombination.
00:27:23.613 --> 00:27:26.405
Diese kommen dann aus dem entsprechenden Q&A vorher.
00:27:28.308 --> 00:27:32.395
Genau, dann implementieren wir das Ganze. Das ist tatsächlich am Ende der einfachste Teil.
00:27:32.847 --> 00:27:36.534
Der Agent liest einfach die Spec und hat auch einen entsprechenden Skill,
00:27:37.346 --> 00:27:40.806
mit dem er das dann bearbeitet und er hat eigentlich schon alles, was er braucht.
00:27:40.916 --> 00:27:45.205
Und da nutzt er jetzt TDD, in unserem Fall in einem vereinfachten Cycle.
00:27:45.205 --> 00:27:47.482
Normalerweise ist es ja Red-Green-Refactor.
00:27:48.178 --> 00:27:51.563
In unserem Fall ist es dann einfach nur Red-Green, weil wir gemerkt haben,
00:27:51.882 --> 00:27:57.461
da haben wir einen zusätzlichen Schritt drin, der dem Agenten jetzt nicht so wirklich weiterhilft.
00:27:57.942 --> 00:28:02.715
Aber das Gute an TDD ist, dadurch hat er schon während der Implementierung automatisch
00:28:02.715 --> 00:28:06.455
so einen Verifikationsloop, mit dem man sehen kann, okay, ist der Code,
00:28:06.455 --> 00:28:09.156
den ich jetzt überhaupt, den ich baue, überhaupt funktional?
00:28:09.481 --> 00:28:13.165
Und ich sag mal, am Anfang, wenn man das Ganze noch ein bisschen weniger automatisiert
00:28:13.165 --> 00:28:16.675
laufen lässt, ist das auch ein super Punkt, um zwischendurch mal reinzugucken,
00:28:16.675 --> 00:28:20.035
hey, kriege ich hier die Ergebnisse, die ich wirklich haben möchte,
00:28:20.035 --> 00:28:22.699
sehen die Tests so aus, wie ich sie vielleicht auch schreiben würde.
00:28:24.197 --> 00:28:27.216
Und kann dann da an der Stelle theoretisch auch schon mal intervenieren.
00:28:28.185 --> 00:28:32.345
Genau, wir nutzen Conventional Commits und ich glaube, mit allen Sachen,
00:28:32.345 --> 00:28:34.835
die ähnlich sind wie Conventional Commits, wenn man das jetzt,
00:28:34.835 --> 00:28:37.575
sage ich mal, über die Firma ausrollt, ist es vielleicht ein bisschen Aufwand.
00:28:37.575 --> 00:28:41.805
Für den Agenten ist jede Art von Dokumentation in Nullzeit gemacht.
00:28:41.805 --> 00:28:46.225
Also gerne so viel Dokumentation hinzufügen, wie es sinnvoll ist natürlich,
00:28:46.225 --> 00:28:50.195
auch nicht einfach nur, um sie zu haben, sondern wo es Sinn ergibt,
00:28:50.195 --> 00:28:55.782
aber das ist eine super Möglichkeit, auch um neue Habits im Entwickeln mit einzubinden.
00:28:56.444 --> 00:29:02.825
Und am Ende pusht er zum Remote auf den Feature-Branch und hat dann seinen ersten
00:29:02.825 --> 00:29:04.623
Done-State quasi erreicht.
00:29:05.343 --> 00:29:08.525
Das ist wirklich der einfachste Schritt, weil in der Spec schon so detailliert
00:29:08.525 --> 00:29:12.935
beschrieben ist, was am Ende implementiert werden muss, dass der Agent da eigentlich
00:29:12.935 --> 00:29:17.335
gar keine Fragen mehr hat. Der läuft dann auch komplett da durch und muss keine
00:29:17.335 --> 00:29:18.530
Rückfragen mehr stellen.
00:29:18.686 --> 00:29:23.715
In 95% der Fälle natürlich gibt es auch Fälle, wo dann doch nochmal eine Rückfrage
00:29:23.715 --> 00:29:27.249
ist und man da reingehen muss und dann schauen muss, okay, wo hapert es jetzt?
00:29:28.532 --> 00:29:33.588
Wir können uns das Ganze auch nochmal in Aktion angucken und da sehen wir nochmal,
00:29:34.119 --> 00:29:37.749
die Spec ist nicht das Einzige, was er liest. Was in der Spec halt nicht drin
00:29:37.749 --> 00:29:40.223
steht, ist, was projektspezifisch ist.
00:29:40.565 --> 00:29:45.719
Dafür kann man die CLAUDE.md nutzen oder halt auch noch weitere Dokumentationen
00:29:45.719 --> 00:29:47.537
im Projekt, das ist auch sehr wichtig.
00:29:48.007 --> 00:29:51.569
Das ist auch, da kann ich mal so einen kurzen Ausflug machen,
00:29:51.569 --> 00:29:54.909
wenn das Ganze jetzt über mehrere Repositories ist, ist das Ganze so,
00:29:54.909 --> 00:29:56.604
dass wir quasi einen Ordner haben,
00:29:57.156 --> 00:30:01.359
der bei jedem gleich ist, wo alle Repositories drin sind und darin steckt dann
00:30:01.359 --> 00:30:06.466
auch die entsprechende Dokumentation, wie diese Repositories miteinander interagieren.
00:30:06.797 --> 00:30:10.413
Ist das hier eine Bibliothek, ist das eine Verbindung über eine API,
00:30:10.860 --> 00:30:15.049
das steht dann alles entsprechend eine Ebene drüber, wir nennen das Meta-Root,
00:30:15.049 --> 00:30:17.652
ist aber kein offizieller Begriff, sage ich mal.
00:30:18.767 --> 00:30:23.119
Genau. Wenn er dann den Kontext gelesen hat, schiebt er das Ticket in Development,
00:30:23.119 --> 00:30:28.095
so wie wir es als Entwickler auch machen würden und fängt dann mit dem TDD-Zyklus an.
00:30:28.531 --> 00:30:32.675
Drei Tests fehlgeschlagen und am Ende, ja, sind die Tests dann grün.
00:30:33.053 --> 00:30:38.341
Der Lint wurde bestanden, damit ist das Feature fertig, er committet das Ganze und pusht am Ende.
00:30:39.194 --> 00:30:42.569
Ich habe das hier jetzt weitestgehend, sage ich mal, auf Deutsch übersetzt.
00:30:42.569 --> 00:30:46.779
Ich würde allerdings jedem empfehlen, bei Claude Code, wer kann mit Englisch
00:30:46.779 --> 00:30:50.399
zu arbeiten, das spart Tokens, man kommt nicht so schnell in die Limits.
00:30:51.576 --> 00:30:55.222
Das funktioniert meistens etwas besser, weil er es intern übersetzen muss.
00:30:56.489 --> 00:31:00.204
Genau, das Ganze ist so designt, dass keine Interaktion normalerweise nötig
00:31:00.204 --> 00:31:01.754
ist, bis alle Tasks fertig sind.
00:31:01.754 --> 00:31:05.574
Er ist dazu angehalten, in diesen Skills halt auf dem Ergebnis immer wieder
00:31:05.574 --> 00:31:09.954
zu iterieren und jeden Task zu committen und das Ganze so lange zu wiederholen,
00:31:09.954 --> 00:31:12.924
bis er alle Tasks halt bestanden hat.
00:31:12.924 --> 00:31:17.467
Nur wenn wirklich ein sehr grobes Problem auftritt, muss man da nochmal rangehen.
00:31:18.517 --> 00:31:22.894
Genau. Kommen wir zu Verify. Das ist am Ende wirklich der schwierigste Schritt.
00:31:23.150 --> 00:31:25.094
Der erste Part ist noch relativ einfach.
00:31:25.419 --> 00:31:28.966
Wir gleichen einfach den Code ab mit der Spec. Da hat man sonst dann vielleicht,
00:31:29.378 --> 00:31:32.564
nachdem man das Ganze implementiert hat, nochmal ins Jira-Ticket geguckt.
00:31:32.564 --> 00:31:37.564
Okay, habe ich jetzt überhaupt das gebaut, was der Produktmanager sich da am Ende vorgestellt hat?
00:31:37.564 --> 00:31:41.464
Das macht der Agent oder Claude Code in dem Fall jetzt automatisch.
00:31:41.464 --> 00:31:45.064
Ist das wirklich der Intent, der da ursprünglich gegeben war?
00:31:45.064 --> 00:31:47.914
Erfüllt das alle Anforderungen, alle Akzeptanzkriterien?
00:31:48.651 --> 00:31:52.639
Dann die lokalen Checks, Linting, Testing, Typecheck, Kompilieren,
00:31:52.941 --> 00:31:54.671
kommt natürlich ganz auf das Projekt an.
00:31:55.118 --> 00:31:58.606
Alles, was lokal geht und Autofix bei entsprechenden Fehlern.
00:31:59.831 --> 00:32:03.784
Dann kommt das Code Review, da jagen wir dann nochmal einen frischen Agent da
00:32:03.784 --> 00:32:06.954
drauf, da kann man auch so ein bisschen experimentieren, möchte man ihm die
00:32:06.954 --> 00:32:10.697
Spec zur Verfügung stellen, dass er schon weiß, worum geht es hier überhaupt,
00:32:10.819 --> 00:32:14.621
oder lässt man ihn tatsächlich ohne die Spec da drauf, einfach nur, sage ich mal,
00:32:14.923 --> 00:32:17.104
wirklich ein stumpfes Code Review, ich weiß gar nicht direkt,
00:32:17.104 --> 00:32:20.101
worum es geht, ich schaue mir den Code an, ergibt das alles Sinn,
00:32:20.862 --> 00:32:24.316
und er geht dann auch hin und macht automatisch Kommentare auf GitLab,
00:32:24.890 --> 00:32:27.195
die dann halt wieder gefixt werden.
00:32:29.354 --> 00:32:32.779
Genau. Der letzte Teil ist dann der DevTest. Das ist der härteste Teil.
00:32:33.011 --> 00:32:36.471
Das unterscheidet sich auch je nach Projekt. Bei uns ist eigentlich alles webbasiert.
00:32:36.907 --> 00:32:38.798
Da nutzen wir Playwright.
00:32:39.298 --> 00:32:43.448
Das funktioniert ziemlich gut. Je nach Komplexität der Anwendung muss man da
00:32:43.448 --> 00:32:44.928
auch noch so ein bisschen Kontext liefern.
00:32:44.928 --> 00:32:48.008
Okay, wie bediene ich jetzt dieses Produkt?
00:32:48.008 --> 00:32:52.228
Aber zum Beispiel unser Ticket-Online-Shop, da kann man den Agenten einfach
00:32:52.228 --> 00:32:53.938
drauf loslassen, der weiß,
00:32:54.699 --> 00:32:57.678
wie ein Shop generell funktioniert, es gibt eine Auswahl von Dingen,
00:32:57.678 --> 00:33:00.958
die ich in den Warenkorb legen kann und dann muss ich Versand,
00:33:00.958 --> 00:33:03.312
Zahlung und so weiter auswählen.
00:33:03.620 --> 00:33:07.318
Da kann man ihn halt wirklich alleine durchlaufen lassen, da braucht man meistens
00:33:07.318 --> 00:33:10.768
nur so ein bisschen Anlauf, dass er sich halt anmelden kann und alles,
00:33:10.768 --> 00:33:15.397
aber sobald er dann erstmal drin ist, funktioniert das wirklich schon out of the box sehr, sehr gut.
00:33:16.995 --> 00:33:20.974
Genau, jede dieser Schicht hat einen Autofix-Loop, also immer wenn ein Fehler
00:33:20.974 --> 00:33:25.011
erkannt wird, wird der Agent dann in dem entsprechenden Skill dazu angehalten,
00:33:25.348 --> 00:33:26.695
das Ganze wieder zu fixen
00:33:27.118 --> 00:33:31.384
und dann weiterzumachen, sodass wir halt möglichst viel Automatisierung da drin
00:33:31.384 --> 00:33:34.954
haben und nur an den Schritten, wo wir wirklich, sag ich mal,
00:33:34.954 --> 00:33:38.531
wollen, dass wir manuell reingehen, das dann auch tun.
00:33:39.802 --> 00:33:43.914
Genau, schauen wir uns das nochmal an. Wir haben den gepushten Code auf dem
00:33:43.914 --> 00:33:48.874
entsprechenden Branch aus dem G-Dev-Skill, dann gehen wir in Verify rein und
00:33:48.874 --> 00:33:54.006
er createt erstmal eine Draft Merge Request, prüft die auf Vollständigkeit und Anforderungen,
00:33:54.437 --> 00:33:58.824
dann macht er lokal die Tests, Lint, Unit, Build, funktioniert alles,
00:33:58.824 --> 00:34:02.712
Self-Review, findet was, eine fehlende Nullprüfung in Zeile 47,
00:34:03.235 --> 00:34:07.794
fixt das Ganze automatisch, pusht nochmal hin, dann ist die Pipeline grün und
00:34:07.794 --> 00:34:10.038
wir updaten den Merge-Request auf Ready.
00:34:10.427 --> 00:34:13.614
Und das ist dann der Punkt, wo wir dann quasi tätig werden und wir sehen dann
00:34:13.614 --> 00:34:17.424
auch auf unserem Jira-Board, hey, hier ist dieses Ticket auf Ready for Review
00:34:17.424 --> 00:34:18.717
und unserem Team zugewiesen.
00:34:19.059 --> 00:34:22.784
Dann gehen wir auf GitLab, schauen uns die Kommentare an, was halt richtig cool
00:34:22.784 --> 00:34:25.904
ist. Automatisch macht der Agent dann auch, schon wenn er die Merge-Request
00:34:25.904 --> 00:34:29.294
erstellt, meistens eine sehr gute Beschreibung, was hier passiert ist.
00:34:29.294 --> 00:34:32.091
Also wir können dann schon direkt sehen, okay, das und das wurde gemacht.
00:34:34.135 --> 00:34:36.674
Und haben es dann sogar beim Review noch ein bisschen einfacher.
00:34:36.674 --> 00:34:40.244
Aber wir sind noch an dem Punkt, wo wir wirklich noch die Tickets am Ende reviewen,
00:34:40.244 --> 00:34:42.604
auch wenn sich das natürlich hin und wieder mal ein bisschen staut.
00:34:44.275 --> 00:34:47.745
Genau, dann kommt der Dev-Test. Obwohl das auch Part von Verify ist,
00:34:48.774 --> 00:34:51.975
ist es halt der härteste Teil, deswegen haben wir das nochmal in den eigenen
00:34:51.975 --> 00:34:54.167
Skill ausgelagert, der dann GQA heißt,
00:34:54.753 --> 00:34:58.805
das heißt, unser Agent nutzt noch einen anderen Skill, den wir gebaut haben,
00:34:58.805 --> 00:35:01.405
TIXX-Deploy heißt der in diesem Fall, der halt,
00:35:02.496 --> 00:35:06.295
ein Branch oder ein Ticket, der zieht sich die Branches dann entsprechend aus
00:35:06.295 --> 00:35:10.408
dem Ticket und kann dann auf ein bestimmtes Environment das Ganze deployen.
00:35:10.959 --> 00:35:13.865
Dafür, wir hatten schon eine UI, mit der wir deployen können,
00:35:13.865 --> 00:35:16.415
die wir uns selber gebaut haben. Da haben wir dann ein Skill erstellt,
00:35:16.415 --> 00:35:18.384
die ihm beibringt, wie er diese UI bedient.
00:35:20.207 --> 00:35:24.405
Und dann öffnet er mit Playwright hier einen Headless, einen echten Browser
00:35:24.405 --> 00:35:28.295
und geht halt wirklich rein in den Shop, geht dann auf die Events,
00:35:28.295 --> 00:35:31.184
testet die Filter aus, die er da findet,
00:35:31.579 --> 00:35:35.480
funktioniert das alles, gibt es Fehler in der Dev-Konsole, im Browser,
00:35:36.397 --> 00:35:39.427
das checkt er halt alles und dokumentiert das Ganze.
00:35:39.845 --> 00:35:43.215
Und das ist dann wirklich so einer der Momente, wo es so ein bisschen magisch
00:35:43.215 --> 00:35:46.265
war, wenn man in das Ticket dann reinguckt und dann sieht man da drin schon
00:35:46.265 --> 00:35:50.462
Screenshots von einem funktionierenden Feature, was der Agent dann angehangen hat.
00:35:50.880 --> 00:35:54.182
Da denkt man sich schon wirklich, oha, das ist schon krass.
00:35:55.845 --> 00:35:58.925
Genau, sollte er Fehler finden, dann versucht er den Code zu fixen,
00:35:58.925 --> 00:36:01.845
das Ganze neu zu deployen und das Ganze erneut zu testen.
00:36:02.222 --> 00:36:05.685
Und dann, wenn das Ganze durch ist, geht das Ticket bei uns Ready for QA und
00:36:05.685 --> 00:36:07.805
der Mensch macht dann die finale QA.
00:36:08.145 --> 00:36:11.237
Aber der Agent hat schon quasi die komplette Vorarbeit geleistet.
00:36:12.932 --> 00:36:15.847
So, kommen wir langsam so ein bisschen zum Ende.
00:36:15.847 --> 00:36:20.477
Was sind jetzt unsere Erfahrungen, wo wir das jetzt seit Anfang des Jahres,
00:36:20.477 --> 00:36:24.667
sage ich mal, sind wir komplett mit Spec-Driven Development unterwegs und allgemein
00:36:24.667 --> 00:36:27.851
versuchen wir über die ganze Company AI-First zu entwickeln,
00:36:28.455 --> 00:36:33.107
also dass wirklich jeder mit Claude Code seine Entwicklungen macht,
00:36:33.107 --> 00:36:36.106
das ist nach einigen Ausprobieren unser Tool der Wahl.
00:36:36.570 --> 00:36:40.447
Wir haben allerdings auch eine kleine Codex-Lizenz noch, für das man hin und
00:36:40.447 --> 00:36:41.603
wieder mal vergleichen kann.
00:36:43.362 --> 00:36:46.837
Wir haben tatsächlich mit externem Mentoring auch angefangen.
00:36:46.837 --> 00:36:49.753
Da möchte ich einen Shoutout an Hackers & Wizards geben.
00:36:50.334 --> 00:36:53.037
Könnt ihr gerne googeln, das war sehr, sehr gut. Dadurch haben sich,
00:36:53.037 --> 00:36:56.677
sage ich mal, einige motivierte Engineers bei uns dann gefunden,
00:36:56.677 --> 00:36:58.941
die das dann auch weiter in der Firma getragen haben.
00:36:59.795 --> 00:37:04.427
Und bei uns hat das halt dazu geführt, dass wir dieses ganze Framework dazu entwickelt haben,
00:37:05.256 --> 00:37:09.147
allerdings hatten wir hin und wieder auch das Gefühl, wir over-engineeren es
00:37:09.147 --> 00:37:12.885
ein bisschen und jeder Dev hat seine eigenen Präferenzen,
00:37:13.587 --> 00:37:18.255
deswegen haben wir das Framework so ein bisschen auch angepasst immer wieder,
00:37:18.683 --> 00:37:23.997
um halt auch so ein bisschen individuelle Freiheit für jeden Entwickler zu machen,
00:37:23.997 --> 00:37:26.417
aber dass wir halt alles, was wir im Team, sage ich mal,
00:37:27.177 --> 00:37:30.507
zusammen auf die gleiche Weise machen sollen, ist dann ein Shared Skill Set,
00:37:30.507 --> 00:37:35.007
was wir über ein Repository teilen, was dann wiederum ein Claude Marketplace
00:37:35.007 --> 00:37:37.707
macht, sodass sich diese Skills auch updaten können automatisch.
00:37:39.427 --> 00:37:43.417
Was ist uns noch aufgefallen? Tempo. Alles entwickelt sich extrem schnell.
00:37:43.417 --> 00:37:46.711
Wir haben jede Woche einen Austausch bei uns im Team.
00:37:46.920 --> 00:37:50.472
Es gibt immer ein neues Thema. Es gibt hier ein neues Modell, da ein neues Modell.
00:37:51.004 --> 00:37:53.957
Ich habe das hier ausprobiert, ich habe das ausprobiert und ich kann euch wirklich
00:37:53.957 --> 00:37:56.472
sagen, regelmäßiger Austausch ist da essentiell.
00:37:57.337 --> 00:38:01.501
Und es ist auch schwer, ein gewisses Vertrauen in das, was man hat,
00:38:01.698 --> 00:38:06.208
aufzubauen, weil es sich halt stetig weiterentwickelt, aber wir kommen da immer mehr hin.
00:38:07.496 --> 00:38:10.771
Und eine ganz wichtige Sache am Ende, Ownership.
00:38:11.021 --> 00:38:16.047
Am Ende besitzt du oder ihr oder ich am Ende trotzdem den Output.
00:38:16.047 --> 00:38:21.067
Bugs, die entstehen, Architektur-Drift, Security, alles bleibt in der Verantwortung
00:38:21.067 --> 00:38:23.281
der Entwicklung und nicht bei dem Agenten.
00:38:24.888 --> 00:38:29.149
Genau. Aber perfekt ist der Feind von gut genug. Liefern, lernen, iterieren.
00:38:30.246 --> 00:38:35.086
Was hat uns geholfen? Weniger ist mehr. Kurze, fokussierte Skills sind besser
00:38:35.086 --> 00:38:37.305
als ewig lange Textblocks.
00:38:38.042 --> 00:38:41.596
Coding Guidelines mussten wir nochmal deutlich verschärfen und deutlich klarer
00:38:41.596 --> 00:38:44.009
machen, um halt Regeln für Mensch und Agent zu haben.
00:38:44.607 --> 00:38:47.776
Viele Tests. Wir haben sehr, sehr viele Tests mit der KI geschrieben.
00:38:47.776 --> 00:38:51.586
Da muss man wirklich drauf achten, dass man wirklich auch immer das Verhalten
00:38:51.586 --> 00:38:55.589
testet. Der Agent neigt gerne dazu, den Code zu testen, anstatt des Verhaltens.
00:38:57.261 --> 00:39:02.266
Wir haben unsere ADRs in die Repositories teilweise gepullt,
00:39:02.266 --> 00:39:06.183
damit der Agent auch vergangene Architekturentscheidungen und Einschränkungen versteht.
00:39:06.816 --> 00:39:11.086
Wir versuchen mehr in Richtung DDD zu gehen. Das ist halt auch super für Agenten,
00:39:11.086 --> 00:39:15.906
weil Du hast einen kleinen Kontext, klare Grenzen und er weiß genau,
00:39:15.906 --> 00:39:18.252
wo er arbeiten darf und wo er nicht arbeiten soll.
00:39:19.059 --> 00:39:24.346
Saubere Architektur generell, sehr, sehr wichtig, um dem Agenten das Ganze zu machen.
00:39:24.346 --> 00:39:28.366
Da wird der Legacy Talk bestimmt noch drauf eingehen. Der Agent kopiert halt
00:39:28.366 --> 00:39:31.556
gerne, was er drumrum sieht. Und wenn das halt nicht gut ist,
00:39:31.556 --> 00:39:34.430
dann produziert er halt auch keine gute Architektur.
00:39:35.632 --> 00:39:39.150
Nichts davon ist wirklich neu, aber alles davon wird jetzt immer wichtiger.
00:39:41.460 --> 00:39:43.829
Mit Blick auf die Zeit muss ich mich, glaube ich, ein bisschen beeilen.
00:39:44.101 --> 00:39:47.760
So, wie war der Einfluss auf die Zusammenarbeit? Ich gehe da mal so ein bisschen
00:39:47.760 --> 00:39:51.049
schneller durch. Am meisten haben wir es natürlich bei unserem Produktmanager gemerkt.
00:39:51.362 --> 00:39:54.870
Wir waren jetzt ein bisschen schneller unterwegs und er musste versuchen mitzuhalten.
00:39:54.870 --> 00:39:57.225
Also, was haben wir gemacht? Wir haben uns einmal mit ihm hingesetzt,
00:39:57.777 --> 00:40:01.170
unsere ganzen relevanten Repos bei ihm auf dem Rechner aufgesetzt,
00:40:01.170 --> 00:40:05.730
Claude Code installiert und mit ihm auch so ein paar eigene Jira-Skills,
00:40:05.730 --> 00:40:08.835
mit denen er refinen kann und sowas aufgesetzt.
00:40:09.242 --> 00:40:12.410
Und das Coole ist, er kann jetzt oft einfach auch Claude fragen,
00:40:12.410 --> 00:40:14.652
anstatt dass er einen Entwickler direkt fragen muss,
00:40:15.790 --> 00:40:19.980
um halt die ganze Security sowohl bei der Entwicklung als auch in der Applikation
00:40:19.980 --> 00:40:24.510
halt hochzuhalten, haben wir auch gemeinsam Skills mit unserem Security-Team entwickelt.
00:40:26.082 --> 00:40:30.680
Bei QA und UX haben wir ähnlich das wie bei dem Produktmanager gemacht und wir
00:40:30.680 --> 00:40:33.370
haben auch eine größere Überlappung festgestellt.
00:40:33.370 --> 00:40:36.840
Unser PM kriegt immer mehr technisches Wissen, wie die Applikation funktioniert
00:40:36.840 --> 00:40:41.593
und wir müssen durch das schnellere Arbeiten halt auch immer mehr Produktentscheidungen selber treffen.
00:40:42.359 --> 00:40:45.650
Und was man auch merkt, wenn man sich das Ganze durchliest, zwar hat man an
00:40:45.650 --> 00:40:48.476
einigen Stellen weniger Zusammenarbeit, wenn man mit dem Agenten ist,
00:40:49.202 --> 00:40:53.852
aber man kann auch Inselwissen abbauen, indem man halt mit den verschiedenen,
00:40:54.484 --> 00:40:56.232
Parts halt eigene Skills entwickelt.
00:40:57.120 --> 00:41:02.450
Wo anfangen? Um das Ganze selber zu implementieren, ich würde einen sparsamen
00:41:02.450 --> 00:41:07.860
erstmal Spec- und Dev-Skill entwickeln und damit halt starten und dann nach
00:41:07.860 --> 00:41:11.220
und nach die Quality Gates dazuholen. Da stelle ich auch am Ende was zur Verfügung.
00:41:12.004 --> 00:41:16.660
Noch einfacher, einfach den Plan-Mode ausprobieren, aber einfach mit dem kleinen
00:41:16.660 --> 00:41:20.967
Satz, interview mich bis ins letzte Detail, wie wir das implementieren wollen.
00:41:21.124 --> 00:41:24.500
Das macht schon sehr, sehr viel und was dann immer ganz cool ist,
00:41:24.500 --> 00:41:26.910
wenn die Session vorbei ist und das hat gut funktioniert für euch,
00:41:26.910 --> 00:41:30.140
könnt ihr eben einfach sagen, mach mir daraus direkt einen Skill und das könnt
00:41:30.140 --> 00:41:31.375
ihr dann immer wieder wiederverwenden.
00:41:32.954 --> 00:41:36.712
Und der eine oder andere mag jetzt denken, okay, da passiert so viel automatisch,
00:41:36.712 --> 00:41:40.193
brauchen wir noch Entwickler. Aber ich würde sagen, Entwickler sind wichtiger denn je.
00:41:40.750 --> 00:41:45.364
Niemand wird ersetzt werden. Man muss mit der Zeit gehen, das war in diesem Feld aber immer so.
00:41:46.187 --> 00:41:50.252
Und der Change, der kommt, in Zukunft entwickeln wir Agenten und Spec-Driven
00:41:50.252 --> 00:41:54.083
Development Frameworks und alles drumherum, anstatt die Applikation selbst.
00:41:55.476 --> 00:41:59.582
Ja, vielen, vielen Dank fürs Zuhören. Ich beantworte gerne noch ein paar Fragen.
00:41:59.582 --> 00:42:02.802
Auf meinem GitHub findet ihr die eben erwähnten Starter-Skills.
00:42:03.182 --> 00:42:07.192
Um selber zu starten und in dem Workshop morgen gehen wir natürlich nochmal
00:42:07.192 --> 00:42:11.318
richtig ins Detail, wie ihr das Ganze implementieren könnt. Vielen Dank.
00:42:11.893 --> 00:42:15.732
Ja, vielen Dank dir, Fabian. Schön, dass du auch nochmal auf den Workshop verwiesen
00:42:15.732 --> 00:42:18.452
hast, denn da geht es dann, glaube ich, so wirklich ans Eingemachte.
00:42:18.923 --> 00:42:21.242
Ich habe tatsächlich auch Fragen hier.
00:42:21.762 --> 00:42:24.682
Ich fange mal an mit dem Tobias. Ups, jetzt springt es wieder,
00:42:24.682 --> 00:42:25.796
weil noch Fragen reinkommen.
00:42:26.655 --> 00:42:30.132
Ihr seid ja ein Frontend-Team. Wie macht ihr das mit Features,
00:42:30.132 --> 00:42:34.497
die auch Backend-Änderungen erfordern? Wird das dann zum Bottleneck eventuell am Ende?
00:42:36.061 --> 00:42:41.071
Das ist tatsächlich vom Titel nicht so richtig erkennbar, aber bei uns ist tatsächlich
00:42:41.071 --> 00:42:46.531
so gut wie jeder Fullstack und ich habe sozusagen eine zweigeteilte Rolle.
00:42:46.531 --> 00:42:51.131
Ich bin der Chapter-Lead für Vue, also für Frontend, aber das Team,
00:42:51.131 --> 00:42:55.241
in dem ich Delivery mache und Tech-Lead bin, arbeitet tatsächlich Fullstack.
00:42:55.241 --> 00:43:00.101
Also das wird für uns nicht zum Bottleneck. Wir entwickeln die Sachen dann gemeinsam.
00:43:00.101 --> 00:43:05.861
Also wir nehmen dann die API und das Frontend und bauen das Feature halt zusammen.
00:43:05.861 --> 00:43:10.028
Also wir haben am Ende dann eine Spezifikation, wo quasi beides abgedeckt wird.
00:43:11.189 --> 00:43:15.421
Super, alles klar. Ingo hat noch eine Frage. Wo landen die generierten Specs?
00:43:15.421 --> 00:43:19.258
Wird die entstehende Markdown-Datei direkt mit eingecheckt?
00:43:19.758 --> 00:43:23.781
Das ist eine sehr, sehr gute Frage. Da gibt es verschiedene Ansätze.
00:43:24.221 --> 00:43:29.173
Da hatte ich auch einen Artikel gewesen auf martinfowler.com tatsächlich, glaube ich.
00:43:30.201 --> 00:43:36.491
Wir sind aktuell mit Spec First, nennt man es, unterwegs, wo wir das Ganze nicht einchecken.
00:43:36.491 --> 00:43:42.331
Wir haben am Anfang die Specs eingecheckt, dass sie halt da sind und man sich
00:43:42.331 --> 00:43:44.501
im Nachhinein nochmal das Ganze angucken kann.
00:43:44.501 --> 00:43:48.331
Am Anfang haben wir sogar die Brainstorming-Session noch persistiert.
00:43:48.331 --> 00:43:52.631
Also, was für Fragen wurden gestellt, welche Antworten, Möglichkeiten gab es
00:43:52.631 --> 00:43:55.550
und welche haben wir gewählt, um wirklich alles nachvollziehen zu können.
00:43:56.531 --> 00:44:00.401
Aber wir haben gemerkt, dass das halt durch die Entwicklung ganz schnell halt
00:44:00.401 --> 00:44:05.201
outdated ist und wir das halt auch nicht, wir wollen das natürlich nicht aktuell halten,
00:44:05.661 --> 00:44:09.751
und am Ende, da der Agent automatisch auch sehr detailliert ist bei Commit Messages,
00:44:09.751 --> 00:44:13.461
Kommentare schreibt in Code, haben wir einfach nicht den Sinn gesehen,
00:44:13.821 --> 00:44:17.597
diese ganzen Dateien noch zu behalten, aber da gibt es auch andere Ansätze.
00:44:18.897 --> 00:44:24.017
Cool, danke dir vielmals. André hat die Frage, wie setzt ihr Coding-Guides um?
00:44:27.157 --> 00:44:32.223
Eigentlich nicht groß anders als vorher. Also wir setzen uns mit dem Team zusammen
00:44:32.223 --> 00:44:35.400
und schauen dann, wie wollen wir entwickeln.
00:44:37.323 --> 00:44:42.563
Im PHP-Space ist es so, dass wir hauptsächlich PSR12, das ist so ein Standard,
00:44:42.563 --> 00:44:48.733
wie kurz geschrieben wird, so vom Style her nutzen und da noch so ein paar kleine Anpassungen machen.
00:44:48.733 --> 00:44:53.463
Im Vue-Bereich haben wir halt relativ umfangreiches Linting und alles,
00:44:53.463 --> 00:44:56.930
sag ich mal, was man automatisieren kann, was dann am Ende über irgendein Skript
00:44:57.278 --> 00:45:01.527
funktioniert, ist halt am besten, weil das ist dann ganz klar für den Agenten,
00:45:01.632 --> 00:45:03.240
es funktioniert oder es funktioniert nicht.
00:45:05.503 --> 00:45:09.863
Ansonsten verlinken wir das dann entsprechend in eine CLAUDE.md oder packen das
00:45:09.863 --> 00:45:12.400
in einen eigenen Skill, das kommt so ein bisschen drauf an.
00:45:13.468 --> 00:45:17.723
Okay, und ganz kurz mal zwischendurch, hier kommt auch noch ein lobendes,
00:45:18.083 --> 00:45:20.743
sehr guter Vortrag. Dankeschön.
00:45:22.739 --> 00:45:27.083
Genau. Und Ingo hat noch eine Frage zu den Kosten, falls du dazu Einblick geben
00:45:27.083 --> 00:45:31.073
kannst. Habt ihr Daten zu den Kosten? Vor allem zum Vergleich Entwicklung durch
00:45:31.073 --> 00:45:33.333
Agent versus Entwicklung durch den Menschen.
00:45:33.716 --> 00:45:37.973
Was ist für euch der größte Mehrwert? Mehr Entwicklungskapazität,
00:45:37.973 --> 00:45:41.923
bessere Resultate oder tatsächlich geringere Kosten?
00:45:43.346 --> 00:45:49.235
Das ist eine ausgezeichnete Frage. Also, da ich ja am Anfang die Zahlen genannt
00:45:49.235 --> 00:45:53.435
habe, also wir fahren das tatsächlich so, das machen, glaube ich, auch wirklich wenige.
00:45:53.638 --> 00:45:59.115
Bei uns gibt es keine Limits. Jeder kann so viel KI-Tokens nutzen, wie er möchte.
00:45:59.115 --> 00:46:02.365
Natürlich, wenn man sehr, sehr viel nutzt, gibt es auch hin und wieder mal eine
00:46:02.365 --> 00:46:04.535
Nachfrage, hey, wofür war das?
00:46:04.535 --> 00:46:08.045
Hat das Sinn ergeben? Aber solange es Sinn ergeben hat, ist es auch okay,
00:46:08.045 --> 00:46:12.785
wirklich mal 500 Dollar an einem Tag zu verbraten, sage ich jetzt mal so.
00:46:12.785 --> 00:46:16.475
Und wir sind da schon sehr weit oben.
00:46:16.475 --> 00:46:24.485
Also das liegt schon im sechsstelligen Bereich, was wir da im Monat an AWS in dem Fall zahlen müssen.
00:46:24.485 --> 00:46:30.105
Das ist schon recht viel. Und ich würde sagen, der Hauptbenefit ist wirklich,
00:46:30.105 --> 00:46:33.275
dass wir ein bisschen mehr Kapazität dadurch kriegen.
00:46:34.099 --> 00:46:38.718
Ich würde sagen, die Qualität ist in etwa gleich.
00:46:39.101 --> 00:46:43.445
So, ich würde jetzt nicht sagen, dass die KI deutlich besseren Code schreibt,
00:46:43.445 --> 00:46:45.620
als jetzt zum Beispiel ein Seniorentwickler.
00:46:45.945 --> 00:46:50.479
Allerdings, wenn man es mit einem Junior vergleicht, ist es natürlich deutlich, deutlich darüber.
00:46:51.587 --> 00:46:54.333
Genau, also die Kapazität würde ich sagen, ist der größte Benefit.
00:46:55.407 --> 00:46:58.385
Ich danke dir nochmal vielmals für deinen Vortrag. Ich bin mir sicher,
00:46:58.385 --> 00:47:01.299
dass die Leute auch morgen im Workshop noch so einiges mitnehmen können.
00:47:01.827 --> 00:47:04.755
Und ja, ich würde sagen bis zum nächsten Mal.
00:47:05.735 --> 00:47:07.151
Ja, bis dann.
00:47:24.255 --> 00:47:27.218
Rheinwerkverlag.de slash Newsletter.