Aber trotzdem war der Impact bei uns eigentlich eher gering,
Download transcript (.vtt)
0:00
0:04
0:07
0:12
0:20
0:24
0:28
0:32
0:36
0:39
0:44
0:46
0:50
0:52
0:56
1:01
1:05
1:09
1:13
1:16
1:20
1:25
1:31
1:36
1:40
1:42
1:46
1:50
1:54
2:00
2:06
2:11
2:15
2:20
2:26
2:32
2:37
2:39
2:43
2:49
2:54
2:59
3:04
3:07
3:10
3:19
3:22
3:27
3:31
3:36
3:41
3:46
3:51
3:56
4:03
4:08
4:10
4:14
4:19
4:23
4:27
4:32
4:37
4:40
4:43
4:46
4:49
4:55
4:59
5:04
5:07
5:13
5:19
5:24
5:28
5:32
5:33
5:37
5:41
5:45
5:50
5:53
5:57
6:01
6:06
6:10
6:14
6:22
6:27
6:33
6:37
6:40
6:43
6:47
6:52
6:55
6:59
7:03
7:08
7:13
7:19
7:25
7:29
7:31
7:35
7:39
7:43
7:52
7:58
8:02
8:04
8:08
8:12
8:16
8:21
8:25
8:30
8:33
8:36
8:38
8:41
8:45
8:48
8:52
8:55
9:00
9:03
9:08
9:13
9:17
9:20
9:23
9:27
9:29
9:34
9:37
9:43
9:46
9:51
9:53
9:57
10:04
10:07
10:10
10:13
10:17
10:20
10:24
10:29
10:33
10:35
10:40
10:44
10:47
10:53
10:59
11:03
11:09
11:12
11:18
11:23
11:28
11:31
11:36
11:39
11:43
11:46
11:49
11:55
12:00
12:06
12:09
12:13
12:17
12:22
12:26
12:32
12:35
12:40
12:47
12:51
12:55
13:00
13:03
13:06
13:13
13:15
13:20
13:23
13:27
13:31
13:34
13:37
13:40
13:43
13:46
13:50
13:54
14:01
14:04
14:09
14:14
14:19
14:24
14:29
14:34
14:37
14:41
14:46
14:52
14:56
15:02
15:07
15:11
15:15
15:20
15:23
15:26
15:31
15:35
15:42
15:47
15:52
15:57
16:02
16:05
16:11
16:15
16:18
16:21
16:26
16:31
16:36
16:40
16:44
16:49
16:52
16:56
16:59
17:05
17:08
17:12
17:16
17:19
17:22
17:27
17:29
17:33
17:36
17:41
17:44
17:50
17:53
17:58
18:02
18:05
18:10
18:12
18:16
18:19
18:24
18:27
18:31
18:35
18:39
18:43
18:47
18:50
18:54
18:57
18:59
19:03
19:08
19:14
19:20
19:24
19:27
19:30
19:33
19:38
19:43
19:46
19:51
19:55
19:59
20:04
20:09
20:13
20:16
20:19
20:24
20:26
20:32
20:36
20:39
20:44
20:47
20:51
20:55
20:59
21:02
21:05
21:10
21:15
21:20
21:27
21:31
21:35
21:40
21:43
21:46
21:48
21:51
21:54
21:58
22:04
22:07
22:09
22:14
22:18
22:21
22:25
22:29
22:33
22:36
22:42
22:46
22:49
22:51
22:54
22:56
22:59
23:03
23:05
23:09
23:11
23:14
23:18
23:22
23:25
23:28
23:31
23:35
23:37
23:41
23:44
23:49
23:52
23:58
24:03
24:06
24:10
24:15
24:19
24:21
24:25
24:29
24:33
24:36
24:40
24:45
24:49
24:54
24:59
25:01
25:05
25:11
25:14
25:18
25:21
25:26
25:28
25:34
25:36
25:39
25:42
25:46
25:50
25:54
25:58
26:00
26:04
26:07
26:13
26:16
26:21
26:23
26:29
26:33
26:36
26:39
26:42
26:44
26:48
26:51
26:55
27:00
27:04
27:08
27:13
27:16
27:20
27:23
27:28
27:32
27:37
27:40
27:45
27:48
27:51
27:57
28:02
28:06
28:09
28:13
28:16
28:20
28:24
28:28
28:32
28:34
28:37
28:41
28:46
28:50
28:56
29:02
29:05
29:08
29:12
29:17
29:18
29:23
29:28
29:34
29:37
29:40
29:45
29:48
29:51
29:54
29:57
30:01
30:06
30:10
30:15
30:18
30:23
30:28
30:33
30:39
30:42
30:46
30:51
30:56
31:00
31:01
31:05
31:09
31:12
31:18
31:23
31:25
31:29
31:32
31:37
31:41
31:45
31:48
31:52
31:55
31:59
32:03
32:06
32:10
32:14
32:17
32:20
32:24
32:29
32:33
32:36
32:39
32:43
32:44
32:48
32:52
32:54
32:57
33:00
33:03
33:07
33:10
33:16
33:20
33:25
33:27
33:31
33:34
33:39
33:43
33:48
33:54
33:58
34:03
34:07
34:10
34:13
34:17
34:19
34:22
34:25
34:29
34:34
34:36
34:40
34:44
34:48
34:51
34:54
34:58
35:02
35:06
35:10
35:13
35:16
35:20
35:24
35:28
35:31
35:36
35:39
35:43
35:46
35:50
35:55
35:58
36:02
36:05
36:08
36:12
36:15
36:20
36:24
36:28
36:33
36:36
36:40
36:43
36:46
36:50
36:53
36:56
36:59
37:05
37:09
37:13
37:18
37:23
37:27
37:30
37:35
37:39
37:43
37:46
37:51
37:53
37:57
38:01
38:07
38:11
38:16
38:21
38:24
38:30
38:35
38:38
38:41
38:44
38:47
38:51
38:57
39:02
39:06
39:11
39:15
39:19
39:24
39:28
39:31
39:35
39:41
39:44
39:47
39:51
39:54
39:57
40:01
40:05
40:09
40:12
40:15
40:19
40:26
40:30
40:33
40:36
40:42
40:45
40:49
40:54
40:57
41:02
41:07
41:12
41:16
41:21
41:24
41:26
41:30
41:32
41:36
41:40
41:46
41:50
41:55
41:59
42:03
42:07
42:11
42:15
42:18
42:21
42:24
42:26
42:30
42:36
42:41
42:46
42:51
42:55
43:00
43:05
43:11
43:15
43:19
43:24
43:30
43:36
43:42
43:44
43:48
43:52
43:56
44:00
44:05
44:09
44:13
44:18
44:27
44:32
44:37
44:42
44:48
44:53
44:57
45:01
45:05
45:09
45:13
45:18
45:22
45:27
45:31
45:33
45:37
45:43
45:49
45:53
45:59
46:02
46:04
46:08
46:12
46:16
46:24
46:30
46:34
46:39
46:43
46:45
46:51
46:55
46:58
47:01
47:05
47:24
weil Coding war bei uns eigentlich auch nie so richtig der Flaschenhals.
Es gibt halt noch sehr, sehr viel, was wir drumherum haben, was uns dann eher
langsamer gemacht hat, als den eigentlichen Code zu schreiben.
KI kann Code schreiben, das wissen wir alle. Aber wer im echten Entwicklungsteam
arbeitet, der weiß auch, Codeschreiben war nie das Problem.
Die Reibung steckt drumherum. Tickets verstehen, Tests schreiben,
Tools einbinden, deployen, debuggen und dabei auch noch reviewbare Ergebnisse
produzieren, das ist eine Herausforderung.
Unser nächster Speaker, das ist Fabian Mayer. Er ist Chapter Lead und Software
Engineer bei Eventim Tech.
Er leitet das Vue Chapter, entwickelt Frontend-Engineers weiter und treibt
technische Exzellenz voran.
Als technischer Lead verantwortet er den Event im TIX Online-Shop,
eine Ticketing-Plattform für über 100 Kunden aus Sport und Festivals. Kennen wir alle.
Er und sein Team haben ihre KI-Tools wie neue Entwickler eingearbeitet.
Mit Zugang zu GitLab und Jira, mit wiederverwendbaren Skills,
mit klaren Standards, vom Ticket bis zum fertigen Feature.
Wie das genau funktioniert, das wird er uns jetzt erzählen und ich freue mich
sehr darauf, dass er heute hier ist. Hallo, herzlich willkommen Fabian.
Ja, erstmal ein herzliches Moin aus Bremen.
Ja, ich freue mich sehr, den Vortrag heute zu machen. Spec-Driven Development in der Praxis.
Und ja, bin gespannt auf das Feedback und auch auf die Fragen am Ende.
Und ja, freue mich heute hier zu sein. Ja, super, klasse. Dann würde ich sagen,
fang einfach gleich mal an.
Und genau, wenn ihr Fragen habt, schreibt sie in den Chat. Und am Ende spreche
ich gerne mit dem Fabian noch einmal darüber. Bis gleich.
Ja, Spec-Driven Development in der Praxis. Heute soll es so ein bisschen darum
gehen, wie wir Spec-Driven Development bei Eventim leben.
Noch ein kleiner Klick auf den richtigen Bildschirm, dann kann es auch losgehen. Ja, Who am I?
Hendrik hat hier schon eine gute Einleitung gegeben, die hier schon einiges vorwegnimmt.
Und ja, das Thema des Talks lässt natürlich auch durchblicken.
Es ist eine gewisse Leidenschaft für Agentic Engineering und auch alle anderen
KI-Themen dabei und privat auch immer einige Projekte.
Ich bin Sportfan, ich mache sehr viel mit 3D-Druck und habe auch einen Homeserver
zu Hause stehen, wo ich immer viele Projekte drauf mache. Da läuft unter anderem
auch zum Beispiel ein Hermes-Agent.
Wer das Ganze kennt, wer sich dafür interessiert, da kann ich auch gerne Fragen
zu beantworten, wie gut sowas funktioniert und wo einem das auch was bringt.
Genau, Eventim und Tix. Eventim ist Europas führender Ticketing-Anbieter und
ich arbeite bei unserem Produkt Eventim Tix. Das ist unsere,
wie schon gesagt, Ticketing-Plattform für Sport und Festivals, über 200 Kunden sogar.
Da habe ich wohl einen kleinen Typo vorher gehabt.
Ja, wir arbeiten hauptsächlich mit PHP, haben mehrere Vue-Frontends,
wir haben auch so einen kleinen Legacy-Core und arbeiten mit fünf Teams zusammen auf einem großen GitLab,
und entwickeln da unsere Plattform weiter.
Große Kunden von uns, zum Beispiel fast jeder Verein in der Bundesliga ist tatsächlich
bei uns, dass man das nicht so sehr sieht, ist Teil des Designs.
Große Festivals, Rock am Ring, Rock am Park, Hurricane werden sicherlich einige
kennen. Das ist so der Stack und die Kunden, mit denen wir arbeiten.
Darum soll es heute allerdings nicht gehen, sondern um erstmal so einen Schritt
zurück zu gehen, bevor wir jetzt in Spec-Driven Development einsteigen.
Wie haben wir bei Eventim überhaupt mit KI angefangen?
Ja, der Start war wahrscheinlich wie bei den meisten, ich nenne es hier die Chat-GPT-Ära,
nach einigen Gesprächen mit unserer Datenschutz- und IT-Security-Abteilung haben
wir es dann geschafft für uns,
Chat-GPT-Enterprise zu bekommen, das haben wir dann auch,
über unsere komplette Firma direkt ausrollen können und am Anfang war das Ganze,
sage ich mal, für uns so ein Ersatz oder so ein Begleiter, den wir
so, wofür wir sonst, sage ich mal, Stack Overflow und Google genutzt haben,
ich habe hier ein Problem, ich habe da ein Problem, hat das schon mal jemand anderes gehabt,
dafür haben wir dann hauptsächlich ChatGPT genutzt, auch hin und wieder hat
man mal ein bisschen Code gemacht, man kopiert ein bisschen Code rein,
kopiert ein bisschen Code raus, aber hat da noch sehr, sage ich mal,
den Nachteil, dass man das dann selbst am Ende alles,
zusammenwurschteln muss, sage ich jetzt mal,
Und das war natürlich nicht sonderlich produktiv und hat bei uns in der Firma
jetzt auch nicht den riesigen Impact gehabt, sage ich mal.
Dann dazwischen, ich gehe nur ganz, ganz kurz drauf ein, war Copilot bei uns.
Das war dann so ein bisschen autocomplete auf Steroiden.
Das war allerdings nur ein sehr kurzer Akt bei uns. Wir hatten einmal 200 Lizenzen
geholt, aber auch da war die Adoption unter den Entwicklern nicht sonderlich groß.
Und dann kam, sage ich mal, der nächste große Schritt, Codex von ChatGPT und Claude Code.
Da hatten wir dann das erste Mal Tools, die wirklich in die Code-Basis gehen
konnten, sich in den richtigen Kontext sammeln konnten, okay,
was passiert hier überhaupt?
Dann haben wir so ein bisschen angefangen rumzuspielen, okay,
es gibt irgendwie einen Planmodus, da kann man sich dann schon mal so ein bisschen,
drauf vorbereiten, okay, was für eine Änderung möchte ich jetzt überhaupt machen?
Und dann läuft Claude oder Codex halt los und implementiert das Ganze und da
wird das Coding dann schon deutlich, deutlich schneller,
und da haben wir dann hier und da mal einen Bug gefixt, kleinere Features gebaut,
Refactorings, aber auch noch sehr, sehr im kleinen Rahmen,
und natürlich auch einiges an Dokumentation geschrieben, wo wir vorher teilweise
einfach ein bisschen zu faul für waren, kann man auch ganz ehrlich sein und
das haben wir inzwischen über unsere komplette Firma ausgerollt.
Jedenfalls bei uns in der Tech. Und ja, aber den großen Big Bang hatten wir da noch nicht.
Es gibt ja auch zum Beispiel eine Metastudie, die sagt, am Anfang sind erfahrene
Entwickler, also Senior und drüber, am Anfang 19% langsamer mit KI,
denken aber tatsächlich selber, dass sie 20% schneller sind.
Allerdings, wenn man sich einmal so richtig eingearbeitet hat,
ist man dann wirklich diese 20% schneller, die man sich auch vorstellt.
Natürlich gibt es viel, sage ich mal, auf LinkedIn und so. Der 10x Engineer,
das stimmt natürlich nicht so 100%, aber man kann da schon, sage ich mal,
merken, dass man doch deutlich schneller ist.
Aber trotzdem war der Impact bei uns...
Eigentlich eher gering, weil Coding war bei uns eigentlich auch nie so richtig
der Flaschenhals. Es gibt halt noch sehr, sehr viel, was wir drumherum haben,
was uns dann eher langsamer gemacht hat, als den eigentlichen Code zu schreiben.
Und nochmal so ein paar Zahlen. Wir haben das über circa 350 aktive Nutzer ausgerollt.
Wir nutzen hauptsächlich Claude Code und beziehen die Inference über AWS Bedrock,
sodass das Ganze dann zwar amerikanische Modelle, aber in Deutschland gehostet
und dadurch können wir halt auch,
Anmeldungen mit Microsoft und solche Sachen machen in einer großen Firma.
Ganz wichtig und auch wenn Tokens, sage ich mal, nicht die beste Metrik ist,
damit man so ein bisschen Eindruck bekommt, wie weit das bei uns schon verbreitet ist.
Bei uns verbrauchen wir derzeit circa so 3,7 Millionen Tokens am Tag mit diesen 350 Nutzern.
Genau. Der Agent schreibt den Code, aber ich mache immer noch, oder du, alles andere.
Ich muss immer noch in Jira reingehen und mir das Ticket anschauen.
Okay, wie detailliert ist das Ganze jetzt?
Ich muss mir im Kopf irgendwie einen Plan machen. Okay, ich möchte jetzt Feature X bauen.
Da muss ich in das und das Repository rein und dann muss ich mir im Kopf so
einen Plan machen, okay, wie gehe ich das Ganze an?
Okay, dann mache ich so ein bisschen einen Plan und lasse Claude das Ganze umsetzen
und teste das Ergebnis am Ende erstmal selber.
So, der nächste Schritt ist dann, einen Merge-Request zu erstellen und Reviewer zuweisen.
Da fangen die Probleme, sage ich mal, ein bisschen an. Ich kriege ein Code-Review,
12 Open Threads, oh Gott.
Und dann muss ich ein bisschen Babysitting in der Pipeline machen,
vielleicht fehlt ein Linter, Code-Style, Unit-Test.
Wir haben eine sehr große Pipeline in unserem Merge-Request,
um ganz, ganz viele Checks durchzuführen und da merke ich dann so langsam,
da hat es an einigen Stellen schon irgendwie ein bisschen gehapert und das Ergebnis
war dann vielleicht doch nicht ganz so, wie ich mir das erhofft hatte.
Dann muss ich am Ende noch deployen für unsere QA, dann schlägt vielleicht noch
einer der automatisierten End-to-End-Tests fehl und am Ende habe ich da,
sage ich mal, einen ganzen Haufen roter Pipelines, die ich am Ende jetzt trotzdem selber fixen muss.
Also, ich habe den Code zwar super schnell erstellt, vielleicht in nur ein paar
Minuten, aber am Ende muss ich dann trotzdem Stunden investieren,
um das Ganze dann wieder so ein bisschen aufzuarbeiten.
Das ist jetzt natürlich auch ein bisschen ins Extreme gezogen,
aber ich glaube, ihr versteht, worauf ich hinaus will.
Und so viel mehr kommt da noch dazu. Ups, da habe ich ein bisschen geschrumpft.
Genau. Das Codeschreiben war nie so wirklich der Flaschenhals, zumindest bei uns.
In Enterprise ist es eher der Prozess rund um den Code, wo man dann wirklich
stecken bleibt und wo man dann noch ganz viel Einzelarbeit dazu machen muss.
Genau, der Code wird schnell generiert, durch den Prozess kommen wir immer noch
langsam. Dann war mein erster Gedanke, hm, dann werfen wir den Prozess halt weg, oder?
Nee, das geht natürlich nicht und das wollen wir auch nicht,
weil dieser Prozess ist über Jahre entstanden und es hat auch seine Gründe,
warum wir da verschiedene Gates drin haben, warum wir Code Reviews machen, warum wir QA machen.
Das ist dann sozusagen bei uns immer der Human in the Loop,
also, dass wir halt beim Code Review und QA gucken, wir, okay,
werden unsere Standards, Guardrails eingehalten,
ist das Ganze sicher, können wir das jetzt so auf unser Produktionssystem deployen,
ohne dass wir Security-Issues bekommen.
Wir haben auch eine komplexe Infrastruktur. Wir haben sehr viele verschiedene
Repos, die zusammen mit vielen Applikationen eine Plattform bilden.
Und wir haben auch viele etablierte Prozesse in Jira, in GitLab,
wie wir Merge Requests erstellen und alles.
Das soll halt erstmal weiterhin so bleiben. Wir wollen Teilautomatisierung,
sage ich jetzt mal, weil wir den Human in the Loop ja behalten wollen,
aber wie kommen wir dahin, dass wir nicht nur den Code generieren,
sondern wirklich den Software Development Lifecycle so ein Stück weit automatisieren,
dass wir halt da nochmal ordentlich an Geschwindigkeit gewinnen.
So, jetzt erstmal ein kleiner Überblick, was ist Spec-Driven Development?
Ist es nur ein Buzzword? Jein.
So ein bisschen ist es ein Buzzword, weil es am Ende eigentlich gar nicht so
kompliziert ist, aber trotzdem halt in der Entwicklung wirklich sehr, sehr helfen kann.
Im Grunde teilt sich das Ganze immer in drei Schritte auf.
Spec Code Verify, das ist auch der Name von dem Workshop, der morgen stattfindet,
deswegen dachte ich, benutze ich das nochmal, weil es einfach so perfekt passt.
Also wir starten quasi ähnlich wie beim Plan Mode, nur bei Spec Driven Development
nennt man es dann Spec oder Spezifikation.
Der eine mag jetzt vielleicht so ein bisschen an Wasserfallmodell oder Pflichten-Lastenheft
denken, aber glaub mir, es ist ein bisschen anders.
Es läuft dann am Anfang so ab, dass ich einen detaillierten Plan,
wie ich Feature X in CodeBase X implementieren will, zusammen mit meinem Agenten,
ob das jetzt Claude Code ist oder Codex, ist am Ende eigentlich egal.
Was allerdings noch wichtig ist, dieser Plan wird am Ende, die ganzen Entscheidungen,
die da drin sind, die werden von mir getroffen.
Der Agent stellt mir nur die Fragen, um das Ganze halt zu machen.
Im nächsten Schritt lassen wir den Agenten das Ganze dann in einer neuen Session,
da gehe ich gleich nochmal drauf ein, implementieren und das Ganze basiert dann auf der Spec.
Und der letzte Schritt, wahrscheinlich auch mit Abstand der schwerste,
verify, dass wir den Agenten den Code gegen mehrere Quality Gates verifizieren lassen.
Quality Gates ist jetzt allgemein, das kann Code Review sein,
Linting, Unit Test, so viel wie möglich, sage ich mal, um am Ende sicher gehen
zu können, dass der Code, der da rauskommt, gut ist von der Qualität her und auch funktioniert.
Warum das Ganze überhaupt? Warum machen wir überhaupt Spec-Driven Development?
Was ist, sage ich mal, der Grund, dass das besser funktioniert,
als einfach, ich prompte ein Prompt nach dem anderen, bis es funktioniert?
Das kleine Bild, was ich euch hier eingeblendet habe, wenn ihr Claude Code nutzt,
könnt ihr euch das auch anzeigen lassen mit Slash-Context.
Das ist der Kontext. Jedes KI-Modell hat ein gewisses Kontext-Window,
wo X-Tokens reinpassen.
Bei den Claude-Modellen ist es normalerweise 200.000 Tokens oder eine Million
Tokens, wenn man das Größere wählt.
Ich glaube, bei Codex sind es 276.000 oder sowas.
Und das Ganze ist so, je voller dieser Kontext ist, desto schlechter ist die
Qualität vom Output des LLMs.
Das kommt einfach dadurch, das ist so ein bisschen wie beim Menschen,
wenn ich acht Stunden gearbeitet habe und dann in der letzten halben Stunde
versuche nochmal ein Code Review zu machen,
dann ist mein Kopf von dem ganzen Tag schon so voll mit Informationen,
dass dieses Code Review wahrscheinlich am Ende nicht das Beste ist.
Und mit dem Agenten ist es ganz ähnlich. Solange der Kontext noch leer ist,
da ist es 7 Uhr morgens, zwei Kaffee getrunken, man ist total dabei und kann
jedes Detail verstehen und noch ganz viel Informationen aufnehmen.
Sobald der Tag zu Ende ist oder der Nachmittag kommt, ist es dann schon ein bisschen schwieriger.
Und Spec-Driven Development gibt uns halt die Möglichkeit, durch dieses Spec
quasi eine neue Unterhaltung mit dem Agenten zu starten, wo er dann eine Datei
hat, wo eigentlich schon alle Infos drinstehen, die er am Ende wissen muss.
Und die Qualität dieses Plans oder dieser Spec ist auch sehr stark verbunden
mit der Qualität des Codes, der am Ende dabei rauskommt.
Es gibt verschiedene,
Spec-Driven Development Frameworks da draußen. Ich habe jetzt hier mal so ein
paar aufgelistet. OpenSpec, BMAD, PlanAct, SpecKit von GitHub.
Die haben alle verschiedene Schritte, die meist durch Skills implementiert werden.
Aber wenn man sich so ein bisschen die Namen des Ganzen durchliest,
Discover, Specify, Validate, dann haben wir Brainstorm, Architect,
Plan, Reflect, Spec, Test, Ship.
Was fällt dabei auf? Am Ende ist es eigentlich immer derselbe Vorgang.
Wir haben irgendeine Spezifikation oder Plan, der dabei rauskommt.
Der Agent implementiert das Ganze und am Ende versuchen wir zu reflektieren,
zu verifizieren, zu validieren.
Da kann man dann, kann man am Ende nennen, wie man will, aber im Grunde sind
es immer diese drei Schritte, die das Ganze durchläuft.
Genau. Da kann man noch mehrere Schritte dazwischen packen.
Das ist so ein bisschen dann auch nach Gusto. Genau. Für uns waren die ein guter Startpunkt.
Wir haben einige davon ausprobiert, haben auch hin und wieder mal was angepasst.
Und das ist, glaube ich, auch ein ganz wichtiger Schritt, den ich jedem ans Herz legen würde.
Guckt euch die Sachen mal an, geht auch wirklich rein in die Skills, die da drinstehen.
Am Ende sind das alles nur Textdateien, sage ich mal. Da steckt wirklich keine
Magie drin und man braucht auch keine Angst zu haben, da hin und wieder mal
was zu verändern, um sich an seinen eigenen Workflow anzupassen.
Für uns passte aber nichts davon so richtig.
Viele Frameworks haben irgendwie schon eingebaut, dass sie so ein bisschen von
einem Workflow in GitHub ausgehen.
Das hatten wir allerdings nicht. Wir nutzen GitLab und Jira für unsere Tickets.
Viele gehen auf das Thema Deploy gar nicht ein oder haben ein sehr einfaches
Deploy da drin. Wir hingegen hatten eine sehr komplexe Multi-App-Infrastruktur,
die wir halt auch irgendwo hin deployen müssen.
Oft sind die konzipiert für die Arbeit in einem einzelnen Repository,
aber wie es in vielen größeren Firmen so ist, hat man eine ganze Armada von
Repositories, die mit unterschiedlichen Beziehungen zueinander sind.
Das eine ist eine Library für was anderes, die sind über eine API verbunden,
die kommunizieren Event-Driven.
Diese ganzen Infos, sage ich mal, muss man auch noch irgendwie mit einbinden,
damit das Ganze gut funktioniert.
Und sie setzen meistens auch einen relativ flexiblen Prozess insgesamt in der
Softwareentwicklung voraus, während wir halt, ich möchte nicht sagen starr,
aber einen etablierten Enterprise-Prozess halt haben, den wir in unserem Team
halt auch entwickelt haben.
Und wir wollten diesen Prozess nicht aufgeben, sondern wollten ihn teilautomatisieren
und haben uns am Ende dann dafür
entschieden, dass wir unser eigenes Spec-Driven-Development-Framework
bauen wollen, damit wir auch verstehen, womit wir arbeiten.
Das ist uns persönlich immer ganz wichtig. Wir nutzen auch im Code selten Frameworks,
die, sage ich mal, viel Magic in Anführungszeichen haben.
Wir wollen immer bis zum, sage ich mal, letzten Punkt alles verstehen und dachten
dann, okay, wir bauen jetzt unser eigenes, dann verstehen wir,
womit wir arbeiten und haben etwas, was genau auf uns zugeschnitten ist.
Ja, und Henrik hat es ja am Anfang schon so ein bisschen eingeleitet.
Wir haben uns dann echt mal gefragt, welche Infos braucht unser Agent,
um produktiv zu sein und haben da so einige Parallelen zur generellen Einarbeitung
von Entwicklern bei uns gesehen.
Der Agent braucht erstmal den Zugang zu Jira. Er muss irgendwie Tickets lesen
können, er muss hier und da auch mal einen Kommentar machen können,
Tickets verschieben von Open zu In-Development und zu Ready-for-Review.
Er braucht Zugang zu unserem GitLab, muss Branches erstellen können,
Merge-Requests aufmachen, Pipelines ansehen, Code-Review machen.
Er muss unsere komplexen Multi-App-Deployments ausführen können.
Er braucht auch ein Pipeline-Monitoring, sodass er auch eine Merge-Request,
die er erstellt hat, sich anschauen kann, auf Fehler entsprechend reagieren kann.
Und er sollte am Ende, so wie wir das auch machen, Dokumentation schreiben und
zwar genau so, wie wir das machen.
Und am Ende, was sonst vielleicht der nette Kollege ist, der einem zur Einarbeitung
zugewiesen ist, ist hier dann der Human in the Loop, was so ein bisschen das
Pairing repräsentiert.
Das brauchen wir alles und das klingt am Ende schon sehr stark danach,
als wir bauen, wir arbeiten einen neuen Kollegen ein. Und im Grunde ist es auch,
sehr nah da dran. Nur nutzen wir da ein wenig andere Tools für.
Es gibt da zwei große Sachen, die man dafür nutzen kann, Agent-Skills und MCP.
Skills sind, sage ich mal, der Low-Effort-Way, das ist eigentlich relativ easy,
das sind am Ende einfach Markdown-Dateien mit Anweisungen.
Deswegen habe ich auch gesagt, bei den Spec-Driven-Development-Frameworks,
die man da draußen findet, einfach mal reingucken.
Am Ende ist das alles nur, sage ich mal, Prompts in Text-Dateien oder in Markdown-Dateien
in dem Fall. Das ist halt super, um Teamworkflows und Prozesse abzubilden.
Die sind auch sehr leicht zu reviewen, weil es am Ende halt einfach nur Text ist.
MCP ist dann schon ein leicht höheres Investment. Das würde ich empfehlen,
wenn die Tool-Anbindung so ein bisschen komplizierter ist.
Zum Beispiel GitHub bietet einen guten MCP GitLab auch.
Da ist es nur wichtig, darauf zu achten, je mehr Tools so ein MCP hat,
desto voller wird der Kontext halt automatisch.
Wir nutzen tatsächlich beides. Wir benutzen hauptsächlich Skills für große Teile
unseres Prozesses und auch für einige Tools.
Man kann Skills auch sehr gut benutzen, um gewisse CLI-Tools,
bei GitLab zum Beispiel G-Lab, es gibt auch für Jira einige CLI-Tools,
da sieht dieser Skill dann so aus, dass er so ein bisschen erklärt,
wie ist das Ganze zu benutzen und MCP dann entsprechend für komplexere Anbindungen,
wie zum Beispiel Logs aus Grafana auslesen.
Genau, dann haben wir uns noch Gedanken gemacht, okay, wie können wir jetzt
unseren Prozess abbilden? Wie lesen wir die Jira-Tickets? Welche Details stehen
da drin? Wie refined sind unsere Tickets eigentlich?
Wie dokumentieren wir genau? Welche Guidelines und Guardrails haben wir?
Welche Commands muss der Agent auch ausführen können, wo er möglichst dann nicht
uns nochmal fragen muss, ob wir das Ganze machen und er muss irgendwie unser
gesamtes Developer-Setup bedienen können.
Da ist es auch wichtig, lokale Ausführungen zu bevorzugen, weil dann kann der
Agent einfach schneller iterieren auf dem Ganzen, als wenn er jetzt jedes Mal,
sage ich mal, zu GitLab gehen muss und gucken muss, wie die Pipeline aussieht.
So, unser SDD-Framework. Das ist, wie ihr schon vorher wahrscheinlich vermutet
habt, gibt es da drei Phasen, die sich in mehrere Skills aufteilen und das sieht dann konkret so aus.
In unserem Spec-Skill holen wir das Jira-Ticket, recherchieren,
in der Code-Basis, das kann ein oder mehrere Repositories sein,
dann spezifizieren wir gemeinsam und das ist tatsächlich auch ein relativ langer
Teil, also es ist dann nicht so, dass man zwei, drei Fragen beantwortet,
sondern das kann bei einem komplexen Feature auch mal so sein,
dass da so 70 Fragen rauskommen.
Das ist kein Scherz, das dauert dann wirklich ein bisschen, da muss man sich
hinsetzen, so wie früher, wenn man sich, sage ich mal, mit dem ganzen Team vielleicht
überlegt hat, okay, wie wollen wir dieses große neue Feature,
umsetzen, setzt man sich jetzt mit seinem Claude Code oder seinem Codex hin und,
versucht gemeinsam halt ein Shared Understanding zu bekommen,
wie das Ganze jetzt am Ende aussehen soll.
Und der Output davon ist dann die strukturierte Spec als Kontext-Artefakt.
Als nächstes kommt dann der Codeschritt. Da machen wir eine neue Session auf,
um den Kontext zu schonen.
Wir arbeiten da ausschließlich nach TDD. Da gehe ich gleich nochmal drauf ein,
warum das für die Agents sehr hilfreich ist. Wir nutzen Conventional Commits.
Wir lassen den Agenten auch direkt auf unser GitLab pushen.
Natürlich nicht auf den Main, sondern auf seinen Feature-Branch dann.
Und der Agent arbeitet dann im SDD-Framework autonom, bis alle Tasks erledigt sind.
Und am Ende steht dann der Verify-Step. Wir gleichen ab mit der Spec,
die wir vorher geschrieben haben. Haben wir jetzt wirklich das implementiert,
was wir auch implementieren wollten?
Lassen lokale Checks oder auch Remote-Checks durchlaufen, je nachdem,
wie das Ganze aufgestellt ist.
Wir lassen dann Code-Review wieder durch einen frischen Agenten oder eine frische
Session durchführen, damit das Ganze auch nicht beeinflusst ist von dem Ganzen,
was er da vorgemacht hat.
Und der letzte Schritt, der auch nochmal sehr viel bringt, aber auch der komplizierteste
teilweise umzusetzen ist,
er nutzt Playwright, um wirklich auf unsere Development-Maschinen zu gehen,
wo das Feature dann deployed ist und das dann wirklich so zu testen,
wir nennen es bei uns mal DevTest, ich gehe auf die Maschine und mache den Idiotentest,
funktioniert das Ganze überhaupt, was ich hier gebaut habe,
das macht Claude dann auch entsprechend automatisch.
Gehen wir ins Detail.
Genau, für die Spec. Wir müssen erstmal Kontext sammeln. Was wollen wir tun?
Wir müssen den Kontext aus Jira holen.
Was ist das Ticket, das Feature, was für Akzeptanzkriterien gibt es,
Beschreibungen, verlinkte Tickets, eventuell noch Screenshots,
die der Agent dann entsprechend runterladen kann.
Womit arbeiten wir gerade überhaupt das heißt, er muss sich die Code-Basis angucken,
verwandte Komponenten, Patterns, Architektur in dem Teil, wo das Ganze eingebaut wird,
und dann kommt wie gesagt das Brainstorming und QA, der Agent erstellt Empfehlungen
also es gibt dann immer quasi, man hat dann das bestimmt schon mal gesehen,
so eine Fragenauswahl und es gibt auch immer eine Sache, die der Agent empfiehlt
aber da muss man vorsichtig sein, da darf man sich nicht immer drauf verlassen,
und das Ziel des Ganzen ist, ein gemeinsames Verständnis zu erarbeiten,
wie das Ganze am Ende implementiert wird.
Und der Output ist dann die strukturierte Spec, die enthält die Recherche,
Einschränkungen, Anforderungen, Entscheidungen, die wir getroffen haben,
Aufgaben, Verifikationskriterien, quasi alles, was der Agent braucht,
um das später dann auch wirklich umzusetzen.
Genau, die Spec ist am Ende dann der Transfer des ganzen Kontexts.
Ohne die müssten wir dann in der nächsten Session quasi alles nochmal herleiten.
Genau, ich habe jetzt hier mal so ein bisschen aufgebaut, wie das Ganze dann
ungefähr aussieht im Claude Code. Bei uns heißt der Skill, den wir dafür nutzen,
G-Plan, weil unser Team, das Grizzlies-Team, heißt, wir haben immer so die Teamnamen
von gewissen Sportteams.
Und ja, Tix ist dann in dem Fall unser Jira-Projekt, also geht es dann los,
er lädt das Ganze aus Jira, okay, wir sollen eine Event-Filter-Komponente hinzufügen.
In den Akzeptanzkriterien steht, okay, da muss es einen Datumsfilter geben,
einen Kategoriefilter und einen Filter nach dem Ort.
Dann geht er in den Code rein, liest wirklich die Komponenten,
die wirklich was damit zu tun haben. Es existiert schon eine Filter-Bar in Vue und eine Eventlist.
Diese Komponenten findet er dann.
Dann jetzt das interaktive Q&A in sehr, sehr klein. Wie wollen wir den Filterstate
in der URL persistieren?
Ja, lass uns das als Query-Parameter machen, das klingt gut.
Was sollen wir machen, wenn keine Ergebnisse angezeigt werden?
Dann machen wir einen Empty State mit Reset Link.
Und dann wird am Ende die strukturierte Spezifikation geschrieben.
Und was dann auch noch ganz cool ist, eine Zusammenfassung der ganzen Spezifikation
postet er dann noch als Kommentar an unser Jira-Ticket, sodass wir später auch
das Ganze entsprechend dokumentiert haben.
Und dieses Spec ist dann am Ende der Vertrag zwischen dir und dem Agenten.
Der ist natürlich an der Stelle nicht rechtsbindend.
Genau, schauen wir uns mal an, wie das dann aussieht. Wir haben hier am Ende eine Markdown-Datei.
Und wie das Ganze hier aussieht, kann man natürlich frei festlegen,
das ist dann später Part von dem Specify-Skill, bei uns hat das Ganze einen
Titel, einen Status, welche,
Jira dazu gehört, wie der Branch heißen wird und auch eine Liste von Repositories.
Das hier ist jetzt natürlich sehr stark runtergedampft, damit wir da jetzt gemeinsam
raufgucken können, normalerweise steckt hier sehr, sehr viel Detail drin und
das kann auch über mehrere Seiten gehen.
Sehen wir, der Online-Shop zeigt Events ohne Filtermöglichkeit an.
Kunden brauchen Datum, Kategorie, Ortfilter.
Jetzt hat er hier seine Research Findings aus dem ganzen Code.
Dann hat er hier seine Requirements. Okay, wir brauchen Datumfilter,
Kategoriefilter, Ortfilter und so weiter und so fort.
Daraus leitet er dann verschiedene Tasks ab und guckt auch, wie er das Ganze
angeht und wann das auch wirklich fertig ist.
Und am Ende hat er dann seine Verifikations-Step. In dem Fall führt er die Test-Suite
aus, macht ein Linting, macht ein Type-Check und hat hier auch Akzeptanzkriterien,
die dann wiederum verbunden sind mit den Requirements.
Hier steht das für Must-Have, Should-Have und Won't-Do.
Also er macht jetzt zum Beispiel kein serverseitiges Caching der Filterkombination.
Diese kommen dann aus dem entsprechenden Q&A vorher.
Genau, dann implementieren wir das Ganze. Das ist tatsächlich am Ende der einfachste Teil.
Der Agent liest einfach die Spec und hat auch einen entsprechenden Skill,
mit dem er das dann bearbeitet und er hat eigentlich schon alles, was er braucht.
Und da nutzt er jetzt TDD, in unserem Fall in einem vereinfachten Cycle.
Normalerweise ist es ja Red-Green-Refactor.
In unserem Fall ist es dann einfach nur Red-Green, weil wir gemerkt haben,
da haben wir einen zusätzlichen Schritt drin, der dem Agenten jetzt nicht so wirklich weiterhilft.
Aber das Gute an TDD ist, dadurch hat er schon während der Implementierung automatisch
so einen Verifikationsloop, mit dem man sehen kann, okay, ist der Code,
den ich jetzt überhaupt, den ich baue, überhaupt funktional?
Und ich sag mal, am Anfang, wenn man das Ganze noch ein bisschen weniger automatisiert
laufen lässt, ist das auch ein super Punkt, um zwischendurch mal reinzugucken,
hey, kriege ich hier die Ergebnisse, die ich wirklich haben möchte,
sehen die Tests so aus, wie ich sie vielleicht auch schreiben würde.
Und kann dann da an der Stelle theoretisch auch schon mal intervenieren.
Genau, wir nutzen Conventional Commits und ich glaube, mit allen Sachen,
die ähnlich sind wie Conventional Commits, wenn man das jetzt,
sage ich mal, über die Firma ausrollt, ist es vielleicht ein bisschen Aufwand.
Für den Agenten ist jede Art von Dokumentation in Nullzeit gemacht.
Also gerne so viel Dokumentation hinzufügen, wie es sinnvoll ist natürlich,
auch nicht einfach nur, um sie zu haben, sondern wo es Sinn ergibt,
aber das ist eine super Möglichkeit, auch um neue Habits im Entwickeln mit einzubinden.
Und am Ende pusht er zum Remote auf den Feature-Branch und hat dann seinen ersten
Done-State quasi erreicht.
Das ist wirklich der einfachste Schritt, weil in der Spec schon so detailliert
beschrieben ist, was am Ende implementiert werden muss, dass der Agent da eigentlich
gar keine Fragen mehr hat. Der läuft dann auch komplett da durch und muss keine
Rückfragen mehr stellen.
In 95% der Fälle natürlich gibt es auch Fälle, wo dann doch nochmal eine Rückfrage
ist und man da reingehen muss und dann schauen muss, okay, wo hapert es jetzt?
Wir können uns das Ganze auch nochmal in Aktion angucken und da sehen wir nochmal,
die Spec ist nicht das Einzige, was er liest. Was in der Spec halt nicht drin
steht, ist, was projektspezifisch ist.
Dafür kann man die CLAUDE.md nutzen oder halt auch noch weitere Dokumentationen
im Projekt, das ist auch sehr wichtig.
Das ist auch, da kann ich mal so einen kurzen Ausflug machen,
wenn das Ganze jetzt über mehrere Repositories ist, ist das Ganze so,
dass wir quasi einen Ordner haben,
der bei jedem gleich ist, wo alle Repositories drin sind und darin steckt dann
auch die entsprechende Dokumentation, wie diese Repositories miteinander interagieren.
Ist das hier eine Bibliothek, ist das eine Verbindung über eine API,
das steht dann alles entsprechend eine Ebene drüber, wir nennen das Meta-Root,
ist aber kein offizieller Begriff, sage ich mal.
Genau. Wenn er dann den Kontext gelesen hat, schiebt er das Ticket in Development,
so wie wir es als Entwickler auch machen würden und fängt dann mit dem TDD-Zyklus an.
Drei Tests fehlgeschlagen und am Ende, ja, sind die Tests dann grün.
Der Lint wurde bestanden, damit ist das Feature fertig, er committet das Ganze und pusht am Ende.
Ich habe das hier jetzt weitestgehend, sage ich mal, auf Deutsch übersetzt.
Ich würde allerdings jedem empfehlen, bei Claude Code, wer kann mit Englisch
zu arbeiten, das spart Tokens, man kommt nicht so schnell in die Limits.
Das funktioniert meistens etwas besser, weil er es intern übersetzen muss.
Genau, das Ganze ist so designt, dass keine Interaktion normalerweise nötig
ist, bis alle Tasks fertig sind.
Er ist dazu angehalten, in diesen Skills halt auf dem Ergebnis immer wieder
zu iterieren und jeden Task zu committen und das Ganze so lange zu wiederholen,
bis er alle Tasks halt bestanden hat.
Nur wenn wirklich ein sehr grobes Problem auftritt, muss man da nochmal rangehen.
Genau. Kommen wir zu Verify. Das ist am Ende wirklich der schwierigste Schritt.
Der erste Part ist noch relativ einfach.
Wir gleichen einfach den Code ab mit der Spec. Da hat man sonst dann vielleicht,
nachdem man das Ganze implementiert hat, nochmal ins Jira-Ticket geguckt.
Okay, habe ich jetzt überhaupt das gebaut, was der Produktmanager sich da am Ende vorgestellt hat?
Das macht der Agent oder Claude Code in dem Fall jetzt automatisch.
Ist das wirklich der Intent, der da ursprünglich gegeben war?
Erfüllt das alle Anforderungen, alle Akzeptanzkriterien?
Dann die lokalen Checks, Linting, Testing, Typecheck, Kompilieren,
kommt natürlich ganz auf das Projekt an.
Alles, was lokal geht und Autofix bei entsprechenden Fehlern.
Dann kommt das Code Review, da jagen wir dann nochmal einen frischen Agent da
drauf, da kann man auch so ein bisschen experimentieren, möchte man ihm die
Spec zur Verfügung stellen, dass er schon weiß, worum geht es hier überhaupt,
oder lässt man ihn tatsächlich ohne die Spec da drauf, einfach nur, sage ich mal,
wirklich ein stumpfes Code Review, ich weiß gar nicht direkt,
worum es geht, ich schaue mir den Code an, ergibt das alles Sinn,
und er geht dann auch hin und macht automatisch Kommentare auf GitLab,
die dann halt wieder gefixt werden.
Genau. Der letzte Teil ist dann der DevTest. Das ist der härteste Teil.
Das unterscheidet sich auch je nach Projekt. Bei uns ist eigentlich alles webbasiert.
Da nutzen wir Playwright.
Das funktioniert ziemlich gut. Je nach Komplexität der Anwendung muss man da
auch noch so ein bisschen Kontext liefern.
Okay, wie bediene ich jetzt dieses Produkt?
Aber zum Beispiel unser Ticket-Online-Shop, da kann man den Agenten einfach
drauf loslassen, der weiß,
wie ein Shop generell funktioniert, es gibt eine Auswahl von Dingen,
die ich in den Warenkorb legen kann und dann muss ich Versand,
Zahlung und so weiter auswählen.
Da kann man ihn halt wirklich alleine durchlaufen lassen, da braucht man meistens
nur so ein bisschen Anlauf, dass er sich halt anmelden kann und alles,
aber sobald er dann erstmal drin ist, funktioniert das wirklich schon out of the box sehr, sehr gut.
Genau, jede dieser Schicht hat einen Autofix-Loop, also immer wenn ein Fehler
erkannt wird, wird der Agent dann in dem entsprechenden Skill dazu angehalten,
das Ganze wieder zu fixen
und dann weiterzumachen, sodass wir halt möglichst viel Automatisierung da drin
haben und nur an den Schritten, wo wir wirklich, sag ich mal,
wollen, dass wir manuell reingehen, das dann auch tun.
Genau, schauen wir uns das nochmal an. Wir haben den gepushten Code auf dem
entsprechenden Branch aus dem G-Dev-Skill, dann gehen wir in Verify rein und
er createt erstmal eine Draft Merge Request, prüft die auf Vollständigkeit und Anforderungen,
dann macht er lokal die Tests, Lint, Unit, Build, funktioniert alles,
Self-Review, findet was, eine fehlende Nullprüfung in Zeile 47,
fixt das Ganze automatisch, pusht nochmal hin, dann ist die Pipeline grün und
wir updaten den Merge-Request auf Ready.
Und das ist dann der Punkt, wo wir dann quasi tätig werden und wir sehen dann
auch auf unserem Jira-Board, hey, hier ist dieses Ticket auf Ready for Review
und unserem Team zugewiesen.
Dann gehen wir auf GitLab, schauen uns die Kommentare an, was halt richtig cool
ist. Automatisch macht der Agent dann auch, schon wenn er die Merge-Request
erstellt, meistens eine sehr gute Beschreibung, was hier passiert ist.
Also wir können dann schon direkt sehen, okay, das und das wurde gemacht.
Und haben es dann sogar beim Review noch ein bisschen einfacher.
Aber wir sind noch an dem Punkt, wo wir wirklich noch die Tickets am Ende reviewen,
auch wenn sich das natürlich hin und wieder mal ein bisschen staut.
Genau, dann kommt der Dev-Test. Obwohl das auch Part von Verify ist,
ist es halt der härteste Teil, deswegen haben wir das nochmal in den eigenen
Skill ausgelagert, der dann GQA heißt,
das heißt, unser Agent nutzt noch einen anderen Skill, den wir gebaut haben,
TIXX-Deploy heißt der in diesem Fall, der halt,
ein Branch oder ein Ticket, der zieht sich die Branches dann entsprechend aus
dem Ticket und kann dann auf ein bestimmtes Environment das Ganze deployen.
Dafür, wir hatten schon eine UI, mit der wir deployen können,
die wir uns selber gebaut haben. Da haben wir dann ein Skill erstellt,
die ihm beibringt, wie er diese UI bedient.
Und dann öffnet er mit Playwright hier einen Headless, einen echten Browser
und geht halt wirklich rein in den Shop, geht dann auf die Events,
testet die Filter aus, die er da findet,
funktioniert das alles, gibt es Fehler in der Dev-Konsole, im Browser,
das checkt er halt alles und dokumentiert das Ganze.
Und das ist dann wirklich so einer der Momente, wo es so ein bisschen magisch
war, wenn man in das Ticket dann reinguckt und dann sieht man da drin schon
Screenshots von einem funktionierenden Feature, was der Agent dann angehangen hat.
Da denkt man sich schon wirklich, oha, das ist schon krass.
Genau, sollte er Fehler finden, dann versucht er den Code zu fixen,
das Ganze neu zu deployen und das Ganze erneut zu testen.
Und dann, wenn das Ganze durch ist, geht das Ticket bei uns Ready for QA und
der Mensch macht dann die finale QA.
Aber der Agent hat schon quasi die komplette Vorarbeit geleistet.
So, kommen wir langsam so ein bisschen zum Ende.
Was sind jetzt unsere Erfahrungen, wo wir das jetzt seit Anfang des Jahres,
sage ich mal, sind wir komplett mit Spec-Driven Development unterwegs und allgemein
versuchen wir über die ganze Company AI-First zu entwickeln,
also dass wirklich jeder mit Claude Code seine Entwicklungen macht,
das ist nach einigen Ausprobieren unser Tool der Wahl.
Wir haben allerdings auch eine kleine Codex-Lizenz noch, für das man hin und
wieder mal vergleichen kann.
Wir haben tatsächlich mit externem Mentoring auch angefangen.
Da möchte ich einen Shoutout an Hackers & Wizards geben.
Könnt ihr gerne googeln, das war sehr, sehr gut. Dadurch haben sich,
sage ich mal, einige motivierte Engineers bei uns dann gefunden,
die das dann auch weiter in der Firma getragen haben.
Und bei uns hat das halt dazu geführt, dass wir dieses ganze Framework dazu entwickelt haben,
allerdings hatten wir hin und wieder auch das Gefühl, wir over-engineeren es
ein bisschen und jeder Dev hat seine eigenen Präferenzen,
deswegen haben wir das Framework so ein bisschen auch angepasst immer wieder,
um halt auch so ein bisschen individuelle Freiheit für jeden Entwickler zu machen,
aber dass wir halt alles, was wir im Team, sage ich mal,
zusammen auf die gleiche Weise machen sollen, ist dann ein Shared Skill Set,
was wir über ein Repository teilen, was dann wiederum ein Claude Marketplace
macht, sodass sich diese Skills auch updaten können automatisch.
Was ist uns noch aufgefallen? Tempo. Alles entwickelt sich extrem schnell.
Wir haben jede Woche einen Austausch bei uns im Team.
Es gibt immer ein neues Thema. Es gibt hier ein neues Modell, da ein neues Modell.
Ich habe das hier ausprobiert, ich habe das ausprobiert und ich kann euch wirklich
sagen, regelmäßiger Austausch ist da essentiell.
Und es ist auch schwer, ein gewisses Vertrauen in das, was man hat,
aufzubauen, weil es sich halt stetig weiterentwickelt, aber wir kommen da immer mehr hin.
Und eine ganz wichtige Sache am Ende, Ownership.
Am Ende besitzt du oder ihr oder ich am Ende trotzdem den Output.
Bugs, die entstehen, Architektur-Drift, Security, alles bleibt in der Verantwortung
der Entwicklung und nicht bei dem Agenten.
Genau. Aber perfekt ist der Feind von gut genug. Liefern, lernen, iterieren.
Was hat uns geholfen? Weniger ist mehr. Kurze, fokussierte Skills sind besser
als ewig lange Textblocks.
Coding Guidelines mussten wir nochmal deutlich verschärfen und deutlich klarer
machen, um halt Regeln für Mensch und Agent zu haben.
Viele Tests. Wir haben sehr, sehr viele Tests mit der KI geschrieben.
Da muss man wirklich drauf achten, dass man wirklich auch immer das Verhalten
testet. Der Agent neigt gerne dazu, den Code zu testen, anstatt des Verhaltens.
Wir haben unsere ADRs in die Repositories teilweise gepullt,
damit der Agent auch vergangene Architekturentscheidungen und Einschränkungen versteht.
Wir versuchen mehr in Richtung DDD zu gehen. Das ist halt auch super für Agenten,
weil Du hast einen kleinen Kontext, klare Grenzen und er weiß genau,
wo er arbeiten darf und wo er nicht arbeiten soll.
Saubere Architektur generell, sehr, sehr wichtig, um dem Agenten das Ganze zu machen.
Da wird der Legacy Talk bestimmt noch drauf eingehen. Der Agent kopiert halt
gerne, was er drumrum sieht. Und wenn das halt nicht gut ist,
dann produziert er halt auch keine gute Architektur.
Nichts davon ist wirklich neu, aber alles davon wird jetzt immer wichtiger.
Mit Blick auf die Zeit muss ich mich, glaube ich, ein bisschen beeilen.
So, wie war der Einfluss auf die Zusammenarbeit? Ich gehe da mal so ein bisschen
schneller durch. Am meisten haben wir es natürlich bei unserem Produktmanager gemerkt.
Wir waren jetzt ein bisschen schneller unterwegs und er musste versuchen mitzuhalten.
Also, was haben wir gemacht? Wir haben uns einmal mit ihm hingesetzt,
unsere ganzen relevanten Repos bei ihm auf dem Rechner aufgesetzt,
Claude Code installiert und mit ihm auch so ein paar eigene Jira-Skills,
mit denen er refinen kann und sowas aufgesetzt.
Und das Coole ist, er kann jetzt oft einfach auch Claude fragen,
anstatt dass er einen Entwickler direkt fragen muss,
um halt die ganze Security sowohl bei der Entwicklung als auch in der Applikation
halt hochzuhalten, haben wir auch gemeinsam Skills mit unserem Security-Team entwickelt.
Bei QA und UX haben wir ähnlich das wie bei dem Produktmanager gemacht und wir
haben auch eine größere Überlappung festgestellt.
Unser PM kriegt immer mehr technisches Wissen, wie die Applikation funktioniert
und wir müssen durch das schnellere Arbeiten halt auch immer mehr Produktentscheidungen selber treffen.
Und was man auch merkt, wenn man sich das Ganze durchliest, zwar hat man an
einigen Stellen weniger Zusammenarbeit, wenn man mit dem Agenten ist,
aber man kann auch Inselwissen abbauen, indem man halt mit den verschiedenen,
Parts halt eigene Skills entwickelt.
Wo anfangen? Um das Ganze selber zu implementieren, ich würde einen sparsamen
erstmal Spec- und Dev-Skill entwickeln und damit halt starten und dann nach
und nach die Quality Gates dazuholen. Da stelle ich auch am Ende was zur Verfügung.
Noch einfacher, einfach den Plan-Mode ausprobieren, aber einfach mit dem kleinen
Satz, interview mich bis ins letzte Detail, wie wir das implementieren wollen.
Das macht schon sehr, sehr viel und was dann immer ganz cool ist,
wenn die Session vorbei ist und das hat gut funktioniert für euch,
könnt ihr eben einfach sagen, mach mir daraus direkt einen Skill und das könnt
ihr dann immer wieder wiederverwenden.
Und der eine oder andere mag jetzt denken, okay, da passiert so viel automatisch,
brauchen wir noch Entwickler. Aber ich würde sagen, Entwickler sind wichtiger denn je.
Niemand wird ersetzt werden. Man muss mit der Zeit gehen, das war in diesem Feld aber immer so.
Und der Change, der kommt, in Zukunft entwickeln wir Agenten und Spec-Driven
Development Frameworks und alles drumherum, anstatt die Applikation selbst.
Ja, vielen, vielen Dank fürs Zuhören. Ich beantworte gerne noch ein paar Fragen.
Auf meinem GitHub findet ihr die eben erwähnten Starter-Skills.
Um selber zu starten und in dem Workshop morgen gehen wir natürlich nochmal
richtig ins Detail, wie ihr das Ganze implementieren könnt. Vielen Dank.
Ja, vielen Dank dir, Fabian. Schön, dass du auch nochmal auf den Workshop verwiesen
hast, denn da geht es dann, glaube ich, so wirklich ans Eingemachte.
Ich habe tatsächlich auch Fragen hier.
Ich fange mal an mit dem Tobias. Ups, jetzt springt es wieder,
weil noch Fragen reinkommen.
Ihr seid ja ein Frontend-Team. Wie macht ihr das mit Features,
die auch Backend-Änderungen erfordern? Wird das dann zum Bottleneck eventuell am Ende?
Das ist tatsächlich vom Titel nicht so richtig erkennbar, aber bei uns ist tatsächlich
so gut wie jeder Fullstack und ich habe sozusagen eine zweigeteilte Rolle.
Ich bin der Chapter-Lead für Vue, also für Frontend, aber das Team,
in dem ich Delivery mache und Tech-Lead bin, arbeitet tatsächlich Fullstack.
Also das wird für uns nicht zum Bottleneck. Wir entwickeln die Sachen dann gemeinsam.
Also wir nehmen dann die API und das Frontend und bauen das Feature halt zusammen.
Also wir haben am Ende dann eine Spezifikation, wo quasi beides abgedeckt wird.
Super, alles klar. Ingo hat noch eine Frage. Wo landen die generierten Specs?
Wird die entstehende Markdown-Datei direkt mit eingecheckt?
Das ist eine sehr, sehr gute Frage. Da gibt es verschiedene Ansätze.
Da hatte ich auch einen Artikel gewesen auf martinfowler.com tatsächlich, glaube ich.
Wir sind aktuell mit Spec First, nennt man es, unterwegs, wo wir das Ganze nicht einchecken.
Wir haben am Anfang die Specs eingecheckt, dass sie halt da sind und man sich
im Nachhinein nochmal das Ganze angucken kann.
Am Anfang haben wir sogar die Brainstorming-Session noch persistiert.
Also, was für Fragen wurden gestellt, welche Antworten, Möglichkeiten gab es
und welche haben wir gewählt, um wirklich alles nachvollziehen zu können.
Aber wir haben gemerkt, dass das halt durch die Entwicklung ganz schnell halt
outdated ist und wir das halt auch nicht, wir wollen das natürlich nicht aktuell halten,
und am Ende, da der Agent automatisch auch sehr detailliert ist bei Commit Messages,
Kommentare schreibt in Code, haben wir einfach nicht den Sinn gesehen,
diese ganzen Dateien noch zu behalten, aber da gibt es auch andere Ansätze.
Cool, danke dir vielmals. André hat die Frage, wie setzt ihr Coding-Guides um?
Eigentlich nicht groß anders als vorher. Also wir setzen uns mit dem Team zusammen
und schauen dann, wie wollen wir entwickeln.
Im PHP-Space ist es so, dass wir hauptsächlich PSR12, das ist so ein Standard,
wie kurz geschrieben wird, so vom Style her nutzen und da noch so ein paar kleine Anpassungen machen.
Im Vue-Bereich haben wir halt relativ umfangreiches Linting und alles,
sag ich mal, was man automatisieren kann, was dann am Ende über irgendein Skript
funktioniert, ist halt am besten, weil das ist dann ganz klar für den Agenten,
es funktioniert oder es funktioniert nicht.
Ansonsten verlinken wir das dann entsprechend in eine CLAUDE.md oder packen das
in einen eigenen Skill, das kommt so ein bisschen drauf an.
Okay, und ganz kurz mal zwischendurch, hier kommt auch noch ein lobendes,
sehr guter Vortrag. Dankeschön.
Genau. Und Ingo hat noch eine Frage zu den Kosten, falls du dazu Einblick geben
kannst. Habt ihr Daten zu den Kosten? Vor allem zum Vergleich Entwicklung durch
Agent versus Entwicklung durch den Menschen.
Was ist für euch der größte Mehrwert? Mehr Entwicklungskapazität,
bessere Resultate oder tatsächlich geringere Kosten?
Das ist eine ausgezeichnete Frage. Also, da ich ja am Anfang die Zahlen genannt
habe, also wir fahren das tatsächlich so, das machen, glaube ich, auch wirklich wenige.
Bei uns gibt es keine Limits. Jeder kann so viel KI-Tokens nutzen, wie er möchte.
Natürlich, wenn man sehr, sehr viel nutzt, gibt es auch hin und wieder mal eine
Nachfrage, hey, wofür war das?
Hat das Sinn ergeben? Aber solange es Sinn ergeben hat, ist es auch okay,
wirklich mal 500 Dollar an einem Tag zu verbraten, sage ich jetzt mal so.
Und wir sind da schon sehr weit oben.
Also das liegt schon im sechsstelligen Bereich, was wir da im Monat an AWS in dem Fall zahlen müssen.
Das ist schon recht viel. Und ich würde sagen, der Hauptbenefit ist wirklich,
dass wir ein bisschen mehr Kapazität dadurch kriegen.
Ich würde sagen, die Qualität ist in etwa gleich.
So, ich würde jetzt nicht sagen, dass die KI deutlich besseren Code schreibt,
als jetzt zum Beispiel ein Seniorentwickler.
Allerdings, wenn man es mit einem Junior vergleicht, ist es natürlich deutlich, deutlich darüber.
Genau, also die Kapazität würde ich sagen, ist der größte Benefit.
Ich danke dir nochmal vielmals für deinen Vortrag. Ich bin mir sicher,
dass die Leute auch morgen im Workshop noch so einiges mitnehmen können.
Und ja, ich würde sagen bis zum nächsten Mal.
Ja, bis dann.
Rheinwerkverlag.de slash Newsletter.