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.