YT YouTube2Text

YouTube2Text → Transcripts → Der Moment, der die Softwareentwicklung geändert hat!

Der Moment, der die Softwareentwicklung geändert hat! — Transcript

by David Tielke · 7,589 words · 1,269 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Und ich habe während dem ganzen
0:01Experiment immer wieder eingeschätzt,
0:02wie viel schneller bin ich mit der KI
0:04als die Mensch. Und ich hatte am Anfang
0:05war ich mir sicher zweimal werde ich es
0:07auf jeden Fall sein. Hab dann
0:08zwischendrin das Gefühl gehabt, oh
0:09vierfach könnte auch realistisch sein.
0:11Und so gegen Eng dachte ich mir, jo,
0:13achtfach könnte es auch sein. Aber es
0:15war ganz anders, denn in Wirklichkeit
0:17war der Faktor.
0:21Wenn ihr viel Content hier auf YouTube
0:22verfolgt, wisst ihr, es gibt zahlreiche
0:24Videos, wo Leute innerhalb von kürzester
0:26Zeit mit kaum Wissen ganze Apps nur
0:28anhand von ihrer Sprache entwickeln.
0:30Aber sind wir mal realistisch, für uns
0:31in der professionellen
0:32Softwareentwicklung haben diese Aussage
0:33überhaupt keine Bewandnis und kein Wert,
0:35weil wir arbeiten mit riesengroßen
0:37Infrastrukturen, Bergen von Anforderung,
0:39richtig großen Enterprise Architekturen
0:41und mit einem sehr, sehr hohen Anspruch
0:43an die Qualität. Seit Jahren mache ich
0:44Beratung und Consulting genau in diesem
0:46Bereich. Große Enterprise Anwendung,
0:48große Architekturen, tausende von
0:50Anforderung mit einem sehr, sehr hohen
0:51Anspruch an die Qualität. Und ich habe
0:53mich gefragt, was wäre, wenn man mal ein
0:56Experiment macht? und in diesem
0:57Experiment eine große große Enterprise
1:00Anwendung entwickelt mit allem Pipapo,
1:02mit allem Zip und Zap, das was ihr jeden
1:04Tag in der Software Entwicklung braucht.
1:06Wie sieht es dann aus? Wie gut ist dann
1:08KI Mitte 2026? Deswegen habe ich einen
1:11Selbstversuch gestartet. Ihr habt
1:12vielleicht gemerkt, seit Anfang des
1:14Jahres gab es sehr wenig Videos und das
1:15hatte einen guten Grund, denn ich habe
1:17mich die letzten vier Monate 6 Monate
1:19eingeschlossen und habe versucht so viel
1:21Zeit neben meinem normalen Beruf wie
1:22möglich auch zu wenden, um ein
1:24komplettes Projekt mit einer großen
1:25Architektur mit hohen
1:26Qualitätsanforderung zu entwickeln von
1:28Anfang bis Ende und das ist jetzt durch.
1:31Und die Ergebnisse,
1:33die sind ehrlich gesagt unfassbar und
1:36die lassen mich seit einigen Wochen
1:38nicht schlafen. Aber genau das gucken
1:40wir uns jetzt mal in diesem Video an.
1:41Nach dem Intro geht's los. Viel Spaß.
1:45[musik]
1:47Ich habe euch ja in den letzten zwei
1:49oder drei Videos sogar gesagt, da ist
1:51etwas passiert anfang des Jahres, was
1:52die ganze Softwareentwicklung mit KI
1:55revolutioniert hat und was die ganzen
1:57Karten neu mischen wird. Und in diesem
1:59Video jetzt wollen wir uns mal genau
2:00dieser Thematik widmen und ich habe eine
2:02ganze Menge Zeit und Energie jetzt in
2:04das Video gesteckt, um euch so viele
2:06Insights wie möglich zu geben. Möchte
2:08aber auf der anderen Seite ähm das Ganze
2:10so kurz wie möglich halten, sonst würde
2:11das Video hier über Stunden gehen.
2:13Deswegen werden wir heute mal in diesem
2:14Video mal den ersten Abriss machen zu
2:17genau diesem Thema. Ich werde euch mal
2:18das Projekt vorstellen und die
2:19Ergebnisse vorstellen. Wichtig dabei
2:21ist, wir versuchen es abstrakt zu
2:22halten. Noch nicht zu technisch, weil
2:23ich möchte, dass dieses Video ja eine
2:25Menge Leute erreicht, die nicht nur
2:26jetzt Softwareentwickler sind, sondern
2:28auch Architekten, Tester, Entscheider
2:30und so weiter und so fort. Ich nutze KI
2:32jetzt seit anderthalb Jahren ganz
2:34exzessiv in Kundenprojekten. In manchen
2:35mehr, in manchen weniger. Viel setzen
2:38wir es bei Anforderung ein, für Quality
2:39Gates ein, natürlich zur Generierung von
2:41Codes ein, zur Validierung von
2:43Architekturen und so weiter und so fort.
2:45Aber in den meisten Projekten wird es
2:46nur partiell genutzt, nicht wirklich
2:47zusammenhängend, um mal wirklich so ein
2:49Software Lebenszyklus von Anfang bis
2:50Ende durchzudenken. Eben genau mit
2:53dieser KI. Und ich habe die ganze Zeit
2:55immer das Gefühl gehabt, okay, gerade
2:57mit diesem Event, kommen wir gleich
2:58drauf, Ende letzten Jahres oder Anfang
3:00diesen Jahres, da geht wesentlich mehr,
3:02da geht wesentlich mehr Qualität und da
3:04geht vor allen Dingen wesentlich mehr
3:05Geschwindigkeit. Was meine ich jetzt
3:07genau mit diesem Ding, was da Ende
3:08letzten Jahres, Anfang diesen Jahres
3:10passiert ist? Ich würde es mal aus
3:11meiner Sicht aus der professionellen
3:13Softwareentwicklungssicht als eine neue
3:15Era interpretieren. Neue Era bedeutet,
3:17wir haben zu die bis zu diesem Zeitpunkt
3:19eine ganze Menge Modelle gehabt. Ich
3:20habe jetzt hier mal nur Claud Opos und
3:23GBT dargestellt und diese Modelle sind
3:25immer besser geworden. Das hat, denke
3:26ich mal, jeder gemerkt in relativ kurzen
3:28Zeitspannen. Aber so Ende letzten
3:30Jahres, also so Ende 2025, Anfang 2026
3:34gab es einen kompletten Schift, weil
3:35plötzlich kam Modelle raus, die etwas
3:37ganz ganz besonders gut konnten, was
3:39vorher aber so nicht möglich war und das
3:41war die Treue, was Richtlinien angeht,
3:43was Guidelines anging. Das heißt, vor
3:45wenn man ihm Vorgaben gemacht hat, wie
3:47eine Anwendung strukturiert geschrieben
3:48werden sollte, hat er die Solala LA
3:50verfolgt. ganz oft vor allen Dingen bei
3:51großen Projekten hat er dann irgendwann
3:52angefangen, die komplett zu missachten,
3:54aber mit dieser neuen Generation
3:56ungefähr ab Obus 45 hat sich das
3:58komplett geändert und plötzlich war so,
4:00dass man größere Vorgaben machen konnte,
4:01größere Richtlinien, größere Guidelines
4:03ihm geben konnte und Guardrails und er
4:05plötzlich angefangen hat, sich penibel
4:07genau an diese Sachen zu zu halten und
4:09die Anwendung genauso aufzubauen, wie
4:11man das tatsächlich haben wollte.
4:13Deswegen schon meine angesprochene
4:14Mission. Ich habe versucht, mir von
4:16Anfang des Jahres bis heute so viel Zeit
4:18wie möglich zu zu nehmen und eine
4:20größere Anwendung wirklich neu zu
4:22entwickeln. Diese Anwendung entwickle
4:24ich schon seit 18 Jahren. Das ist meine
4:25private Anwendung, meine Buchhaltung,
4:27meine Backoffice Anwendung und meine
4:29Maßgabe war so viel KI wie möglich zu
4:31benutzen, eine Enterprise
4:32Systemarchitektur zu verwenden, eine
4:34Enterprise Software Architektur zu
4:35verwenden und einen Qualitätsstandard zu
4:38nehmen, wie in meinen, ja, ich sag mal,
4:40penibelsten Kundenprojekten gemacht
4:41wird, also wo wir wirklich auf alles
4:43achten. Ich möchte, dass das Ganze
4:44getestet wird, ich möchte, dass es
4:46dokumentiert wird. Ich möchte, dass das
4:47Ganze spezifiziert wird. Und das ganze
4:49nicht an der kleinen iPhone Anwendung
4:50oder was ihr sonst schon gesehen habt,
4:52sondern es soll wirklich eine große
4:53Anwendung werden. Diese Anwendung, die
4:55ich seit 18 Jahren entwickel, die habe
4:56ich neu entwickelt und nicht nur diese
4:58Anwendung, sondern sie hat am Ende
4:59ungefähr den, denke 12, 15 faachen
5:02Funktionsumfang. Also sie ist schon für
5:04meine Verhältnisse alleine entwickelt
5:06schon wirklich groß geworden. Und dabei
5:08ging es mir konkrete Fragestellung. Ich
5:09wollte A wissen, ist das überhaupt mit
5:11den aktuellen LMs, mit den aktuellen KI
5:13Agenten möglich, so große Anwendung mit
5:15einem guten Qualitätsniveau zu bauen?
5:16Dann aber auch wie schnell ist das Ganze
5:19und wie qualitätsmäßig am Ende die
5:21Ergebnisse aussehen. Also ob wir
5:22wirklich die Ergebnisse oder die
5:24Qualitätsniveaus erreichen können, die
5:25ich normalerweise in großen Projekten
5:27bei großen Kunden habe und natürlich
5:29auch der Punkt der Kosten. Was am Ende
5:31kostet es, wenn ich alleine so eine
5:33Anwendung mit vorgegebenen hohen
5:35Qualitätsstandard entwickel und zwar
5:36endto? Diese alte Anwendung, von der wir
5:38jetzt reden, das ist meine alte
5:39Backoffice Anwendung. Ihr seht ihr nur
5:41einen Screenshot und ich nutze diese
5:42Anwendung seit 18 Jahren, meine Rechnung
5:44zu erstellen, meine Belege zu erstellen,
5:45meine Kunden zu verwalten etc. pp. Die
5:47ist aber sehr an die Jahre gekommen. Das
5:49ist eine DNET Framework Anwendung noch
5:51mit uraltem uralter UI Technologie und
5:53im Endeffekt mache ich so von den
5:55Modulen her, also von den
5:56Funktionalitäten her alles, was ich
5:57normalerweise gebraucht habe im Laufe
6:00dieser verschiedenen Jahre. Aber man
6:01muss dazu sagen, ich habe immer nur ein
6:03Bruchteil von den Funktionalitäten, die
6:04ich gerne gehabt hätte, implementiert.
6:06Da geht noch wesentlich wesentlich mehr.
6:07Und dieses wesentlich mehr möchte ich
6:08gerne in der neuen Anwendung
6:09implementieren. Diese Anwendung soll im
6:11Endeffekt aus mehreren Bestandteilen
6:12bestehen. Einmal das Backoffice, also
6:14das, was ich jetzt in der alten
6:15Anwendung schon so ein bisschen hatte,
6:16aber nur mit wesentlich wesentlich mehr
6:18Funktion mit moderner Oberfläche und mit
6:20einer ganzen Menge Dinge, die noch im
6:21Hintergrund funktionieren, E-Mails
6:22automatisch verschicken etc., weil die
6:24alte Anwendung und meine Homepage z.B.
6:27die war komplett ja entkoppelt. Das
6:28heißt, wenn ein Kunde eine Anfrage
6:30gestellt habe, habe ich eine E-Mail
6:31bekommen. Die E-Mail habe ich dann von
6:32Hand im Backoffice eingetragen etc. Und
6:34das ganze möchte ich jetzt komplett
6:35integriert haben. Ich möchte ein riesen
6:36umfangreiches Backoffice System haben
6:38und das soll an eine neue auch ebenfalls
6:40in diesem Projekt jetzt neu entwickelte
6:42Homepage integriert werden, wo man
6:44Workshops buchen kann, sich für E-Mail
6:47Newsletter eintragen kann, auf
6:48Wartelisten eintragen lassen kann,
6:49Projektanfrage stellen kann und so
6:51weiter und so fort. Damit die
6:53Kommunikation mit meinen Kunden für mich
6:54reibungsloser läuft, wollte ich auch
6:55eine Kundenkommunikationsseite haben.
6:57Das heißt, mein Kunde bekommt E-Mails,
6:58wo Termine für ihn reserviert sind. Da
7:00kann er dann auf den Link klicken, kommt
7:01dann auf diese Customer Area und kann
7:03dann dort keine Ahnung Termine
7:05bestätigen, sich ein Angebot ein Angebot
7:06bestätigen oder eine Rechnung noch mal
7:08runterladen oder irgendwelche anderen
7:09Dinge, die bei mir in der
7:10Kundenkommunikation auftreten. Und ich
7:12persönlich, ich hasse Büroarbeit. Ich
7:15mache diesen Job Beratung, Training,
7:16Consulting, total gerne, aber ich mag
7:19Bürofice Arbeit einfach nicht. Und das,
7:21was ihr hier seht, das Backoffice, die
7:22Homepage, die Customer Area, das ist für
7:24mich nice to have. Okay, die Homepage
7:26nicht, die ist natürlich wichtig, die
7:27ist für euch, die Kunden, aber die
7:28restlichen Sachen sind für mich nice to
7:30have, weil wenn alles ideal läuft,
7:31möchte ich im Backoffice gar nicht
7:33wirklich unterwegs sein, will ich gar
7:34nicht wirklich arbeiten, sondern ich
7:36möchte, dass im Hintergrund ein KI
7:37System läuft, nämlich Hermies. Hermes
7:39ist der neueste Agentenschreis Schrei
7:42scheiß Schrei wollte ich sagen, der dort
7:45draußen rumläuft und ich möchte gerne,
7:47dass dieser Agent für mich über die API
7:50in dieser Anwendung Großteil mal eine
7:51Anwendung macht. Rechnung erstellt,
7:53Belege erstellt, Belege automatisch
7:54verbucht, ein Teil der
7:55Kundenkommunikation übernimmt etc. pp,
7:57weil mein Ziel ist es bis Ende 2026 80
8:0090% der Dinge, die mir bei der
8:03Büroarbeit immer wieder auf die Nerven
8:04gehen, komplett zu automatisieren und
8:05zwar zu automatisieren mit Hermes und
8:07ganz wichtig mit lokaler KI. Ich habe
8:09natürlich relevante Kundeninformationen,
8:11die niemals in die Cloud dürfen. Ich
8:12habe sehr sensible Kunden, deswegen soll
8:14das hier alles lokal funktionieren.
8:16Kommen wir in späteren Videos zu, aber
8:18das ist mein Scope. Ich hatte ja gesagt
8:19Enterprise Architektur. Enterprise
8:21Architektur. meint natürlich jetzt eine
8:23ganze Menge Architekturformen, aber ich
8:24habe mich für eine Microservice
8:25Architektur entschieden. Brauche ich
8:27diese Microservice Architektur? Nein,
8:28was brauche ich? Absolut nicht. Keine
8:30von diesen Aspekten ist für mich
8:31relevant, aber in den letzten 15 Jahren
8:34hat diese Backoffice Anwendung, die ich
8:35schon gebaut habe, immer für meine
8:36Architekturworkshops als Beispiel
8:38hergehalten. Das gibt es als
8:39monolitische Architektur, Märschlichen
8:41Architektur und Komponentenarchitektur.
8:42Und hier dachte ich mir jetzt für die
8:44zukünftigen Workshops wäre ein
8:45Microservice Beispiel, was vor allen
8:46Dingen noch mit KI entwickelt ist, eine
8:48ziemlich coole Sache. Deswegen
8:49Microservices, diese Microservices oder
8:52diesen Microservices vorgeschaltet ist
8:53eine API Gateway, ist mit Traffic gelöst
8:56und zusätzlich oben drauf dann diese
8:57drei Clients, die ihr gerade gesehen
8:59habt, also die Homepage Customer UI und
9:01das Backoffice. Unten drunter dann gibt
9:02es noch eine Workflow Engine N8N und
9:05diese Workflow Engine soll die ganzen
9:06Geschäftsprozesse und die Abarbeitung,
9:08die Orchestrierung von verschiedenen
9:10Domainen übernehmen. dazu machen beim
9:11folgen, keine Ahnung zwei d Wochen mal
9:13ein Video, dann seht ihr, wie das
9:15genauer funktioniert. Das heißt nicht
9:16nur die Kommunikation von oben nach
9:18unten, sondern die einzelnen Services
9:20können Domaenevents auslösen und die
9:21werden dann von Workflows in ein N8N
9:24verwendet. Nächster Schritt ist, dass es
9:26natürlich noch externe Services gibt,
9:28also Office 365, Google, Trello, alle
9:31möglichen Dinge, wo ich E-Mails
9:32verschicke, Kalendereinträger eintrage,
9:34Teams Meetings erstelle oder im Google
9:36Sheets irgendetwas festhalte, Karten in
9:39Trello anlege, dass ich quasi eine
9:40einheitliche Übersicht habe, was noch zu
9:41machen ist und so weiter und so fort.
9:43Also auch eine ganze Menge Services.
9:45Dann natürlich noch die lokale KI. Wie
9:47gesagt, ich möchte, dass ein Großteil
9:48der Arbeit hier am automatisiert von KI
9:51Agenten übernommen wird. Dafür brauche
9:52ich eine lokale KI. Ich habe mich jetzt
9:54für Gen ähm Gen äh äh für Alibaba Gwen
9:5936 entschieden. 36 Milliarden
10:01Parametermodell, glaube ich, Mix of
10:03Expert Modell und machen wir auch noch
10:05ein Video zu. Und das ganze läuft lokal
10:07auf meiner Hardware und wird nach
10:08obenhin angeboten in die weite
10:10Intranetwelt bei mir über einen MCPS
10:12Server. Das heißt, der sagt in diesem
10:14Buchhaltungssystem, liebe KI, kannst du
10:16die und die Operationen aufrufen,
10:17Rechnungen anlegen, keine Ahnung, Belege
10:19verbuchen und so weiter und sofort und
10:21oben und top da sitzt dann der Hermes
10:23Agent, der auf meinem Server läuft und
10:25diese ganzen Dinge weitesgehend autonom
10:27übernehmen soll. So, die Architektur ist
10:28natürlich jetzt nur eine Sache, denn
10:30Defops Bereich wollte ich auch
10:31weitesgehend so abdecken, wie das
10:32normalerweise in Praxisprojekten ist.
10:34Das heißt, wir haben erstmal zwei
10:35verschiedene Umgebungen, die
10:36Wellumgebung und meine
10:37Produktionsumgebung. Ich habe keine
10:39Serverinfrastruktur, ich habe nur ein
10:40Nasssystem hier auf beiden, auf meinem
10:43Desktop PC und auf dem Nasssystem läuft
10:45Docker. Und ich habe immer zwei PCs
10:47gehabt. Einmal den, der hier an meinem
10:48Schreibtisch ist und dann oben bei
10:49meiner Tochter im Büro äh im Schle im
10:51Kinderzimmer habe ich noch ein Zweitbüro
10:53aufgebaut, wo ich dann abends immer bis
10:55tief in die Nacht arbeiten konnte.
10:57Übrigens, vielen Dank an die netten äh
10:58Kollegen, die in den letzten zwei, drei
11:00Videos geschrieben haben, wie scheiße
11:02ich aussehe, dass ich ja aussehe, als
11:04wenn mich irgendjemand überfahren hätte.
11:05Das waren genau die vier Monate, wo ich
11:07meistens bis tief in die Nacht
11:08gearbeitet habe. So, auf jeden Fall zwei
11:10Development Maschinen und die
11:11Nassumgebung und erstmal die Coding
11:14Agents, die ich verwendet habe. Am
11:15Anfang sehr viel Codex, später fast
11:17ausschließlich Cloud und auch noch
11:19lokale KI, aber da reden wir im nächsten
11:21oder übernächsten Video mal drüber. Die
11:23haben Zugriff auf der einen Seite
11:24natürlich auf ein Code Repository, wo
11:26der ganze Quellcode abgelegt wurde, aber
11:28natürlich auch auf ein anderen Ordner in
11:29dem Spezifikationen sind. Kommen wir
11:31gleich zu und da steht drin, was jetzt
11:33genau fachlich in dieser Anwendung rein
11:35soll. also welche Module, welche
11:36Funktionen etc. Gleichzeitig hat der m
11:39Coding Agent aber auch noch Zugriff auf
11:41sogenannten Harness und dieser Harness
11:43gibt jetzt nicht vor, was implementiert
11:44werden soll, also die Funktion, sondern
11:46wie es implementiert wird, welche
11:47Architektur wie codiert werden soll, wie
11:49die einzelne Umgebung angesprochen
11:50werden und so weiter, kommen wir gleich
11:52auch noch drauf. Und auf den lokalen
11:53Entwickler PCs natürlich Docker for
11:55Desktop installiert, auf die die Coding
11:57Agents direkt zugreifen konnten. Das
11:59heißt, die können den Quellcode nicht
12:00nur entwickeln, sondern auch deployen
12:02und dann auf Docker laufen lassen, sich
12:03die Logfes angucken etc. Wenn jetzt ein
12:05neuer Stand da ist, dann kann der
12:07gepusht werden Richtung Gitty. Gitty ist
12:08eine leichtgewichtige Alternative zu
12:10Gitlab und dieses Gitty nutzt dann einen
12:14Build Agent und dieser Build Agent pusht
12:15dann in zwei verschiedene Umgebungen auf
12:17dem Lass. Einmal eine Testumgebung und
12:19eine Production Umgebung. In der
12:21Testumgebung Production Umgebung laufen
12:23diese beiden Anwendung noch mal. In der
12:25Testumgebung seht ihr an dieser kleinen
12:26Maske hier ist noch ein Zusatz dabei,
12:28weil das seht ihr später. Ich muss da,
12:30um die Workflows besser testen zu
12:32können, noch eine neue Komponente
12:33reinbringen. Aber das hier vom Setup her
12:36würde ich sagen, ist so bei 80 90% der
12:38Kunden, die ich habe, die mit
12:39Microservices arbeiten, so oder so
12:42ähnlich. Letzte wichtige Teil, weil ich
12:43möchte, dass der KI-Agent weitesgehend
12:45autonom arbeitet, hat er per SSH Zugriff
12:47auf das Nass. Hat im der Testumgebung so
12:50gut wie alle Möglichkeiten mit Docker
12:51quasi zu arbeiten, Lockfiles zu ziehen
12:53und so weiter, neue Container
12:54aufzusetzen. In der Produktionsumgebung
12:56habe ich das Ganze eingeschränkt. Er
12:57kann sich zumindestens die Logfiles
12:58holen. Das heißt, wenn ich merke, da
13:00gibt's ein Problem in der Production
13:01Umgebung, dann kann ich direkt den
13:03Coding Agent nutzen, um dort zu
13:04analysieren, dass er mir zielgerichteter
13:06sagen kann, was genau nicht in Ordnung
13:07ist. Wichtig natürlich bei der ganzen
13:08Sache ist, ich will nicht nur, dass das
13:09Ganze nachher qualitäts und
13:11strukturmäßig gut ist, sondern ich
13:12möchte natürlich auch, dass es
13:13nachweislich funktioniert. Und deswegen
13:15habe ich mich beim Testen auf zwei Dinge
13:16ähm reduziert oder mich für zwei Dinge
13:18entschieden. Einmal API Tests und die
13:20Workflow Tests. Man kann eine ganze
13:22Menge mehr testen. Ich könnte Unit Tests
13:23machen und Oberflächentests, aber für
13:25mich ist ja wichtig, dass der dass der
13:27der Hermes Agent später mit einer
13:29sauberen Backend Infrastruktur mit einer
13:31gut funktionierenden Backend
13:32Infrastruktur arbeiten kann. Und
13:33deswegen habe ich einmal die Endpunkte
13:34getestet für die einzelnen Tests. Das
13:36bedeutet, wenn ich jetzt hier so ein
13:38Service habe, hat er seine eigene
13:39Datenbankinstanz in der Testumgebung und
13:41dann kann der Test oben auf diesen ähm
13:43auf diesem Service verschiedene
13:44Operationen ausführen und kann er
13:46natürlich auf der einen Seite die
13:47Responses auswerten, also testen, ob er
13:49die richtigen Antworten gibt. Er kann
13:50aber auch hingehen und kann gucken, ob
13:52die richtigen Events, die Domainen
13:53Events ausgelöst werden. Also, wenn ein
13:54neuer Kunde angelegt wird, dann sollte
13:56idealerweise auf den Message Bus eine
13:58Nachricht wie neue äh Kundennachricht
14:00auf den Bus gelegt werden, z.B. Aber er
14:02kann auch direkt Searchs machen auf die
14:04Datenbank und mal gucken, ob
14:05irgendwelche Manipulationsoperationen
14:08auf der Datenbank richtig gemappt
14:09wurden. Bei den Workflow Tests jetzt
14:11geht's darum, dass wir einmal die ganze
14:13Umgebung hochfahren mit allen Services,
14:14weil oben drauf läuft ja diese Workflow
14:16Engine N8N und das Ziel ist es jetzt,
14:19dass ich Tests geschrieben habe oder
14:20Tests habe schreiben lassen, die
14:21natürlich diese Workflows ausführen, die
14:23im Hintergrund mit allen Services und
14:25der richtigen DAT, also der richtigen
14:26Datenbank mit Testdaten arbeiten und
14:28dann kann dieser Test wieder natürlich
14:29den die Antwort von dem N8N Workflow
14:32verifizieren und ausführen und auf
14:34derselben Ebene natürlich auch wieder
14:35die Datenbank asserten, also gucken, ob
14:37der Workflow die Daten in der Datenmark
14:38richtig asserted hat Und da kommt jetzt
14:40dieser Zusatzpunkt dabei aus der
14:42Testumgebung, den ich eben angesprochen
14:44habe. Diese Workflow Engines schicken
14:45natürlich E-Mails über Office 365 oder
14:47legen Trello Karten an oder öffnen
14:49Google Sheets oder was auch immer und
14:50das sind immer Restaufe in Systeme, die
14:53nicht in meiner Testumgebung sind
14:54Richtung Office, Richtung Google etc.
14:56Deswegen habe ich mich für Wemmck
14:58entschieden und Wemmck ja täuscht quasi
15:00Docker so, dass dieser diese Aufrufe
15:02zwar eigentlich gegen Office 365 gehen,
15:04z.B., will aber von Wiremog abgefangen
15:06werden und dann eben entsprechende MOK
15:09Daten wieder zurückgegeben werden, auf
15:10die dann später dieser Test hier das Set
15:12machen kann. Das heißt, die für meinen
15:14KI Agenten zukünftig extrem wichtigen
15:16Komponenten Backend und Workflows sind
15:18damit einigermaßen ausreichend getestet.
15:21Nachdem wir über das was geredet haben,
15:22also was entwickelt wurde, wie das Ganze
15:24erzielt werden sollte, mit welcher
15:26Architektur, mit welcher Umgebung kommen
15:27wir jetzt zu der Art und Weise, wie ich
15:29vorgegangen bin. Ich habe am Anfang
15:30angefangen mit einer relativ naiveren
15:32Art und Weise, weil ich verschiedene
15:33Vorgehen miteinander vergleichen wollte
15:35und vor allen Dingen die Endqualität
15:37miteinander vergleichen wollte. Ich habe
15:38in der Phase 1 angefangen, die nenne ich
15:40immer Micromanagement. Das kennt ihr
15:42selber, wenn ihr mit LMS arbeitet, habt
15:44ihr am Anfang einen Prompt und aus
15:45diesem Prompt lasst ihr euch Quellcode
15:47generieren. Dieser Quellcode wird dann
15:48entsprechend gereviewt, ob die
15:50Funktionalität passt, ob die
15:51Codestruktur passt etc. und dann
15:53iteriert man darüber. Das heißt, man
15:55geht weiter zum nächsten Brom. Das ist
15:56natürlich sehr sehr kleinteilig und hat
15:58immer wieder das Problem, dass das LM
15:59ganz oft Quellcode ausspuckt,
16:01Architekturansätze, Designs ausspuckt,
16:03die überhaupt nicht wirklich passend
16:04sind. Deswegen bin ich relativ schnell
16:06zur zweiten Phase übergegangen. Ich habe
16:08es mal Quality Driven genannt. Das
16:10heißt, wir starten noch immer mit
16:11unserem Query, also mit dem Prompt, den
16:13wir an das LM schicken. Aber dieses Mal
16:16haben wir vor einen sogenannten Harness
16:17definiert. Ein Harnis könnt ihr euch so
16:19vorstellen wie Lightblanken für das LM.
16:21Das LM normalerweise weiß nichts über
16:23unsere Anwendung, unsere Architektur,
16:25unsere Absichten, die wir in der
16:26Anwendung haben und in diesem Harness
16:27versuchen wir jetzt diesem LN mehr
16:29Intention zu geben, wie die Architektur,
16:31der Quellcode etc. aussehen soll. Wir
16:33haben also in diesem HNS verschiedene
16:34Dateien und aus diesen Dateien wird dann
16:36sogenannter System prompt generiert. Das
16:38heißt, immer wenn ich eine neue Session
16:40mit Cloud, mit Codex aufmache,
16:41aufgemacht habe, dann wurde quasi der
16:44Inhalt des Harnesses aufbereitet, an das
16:46LM geschickt. Das LM wusste also genau,
16:48wie möchte ich entwickeln, welche
16:50Richtlinien sollen befolgt werden und so
16:52weiter. Dann habe ich wieder diese
16:54Prompts generell aus dem Prompt, wie
16:55vorher auch schon den Quellkrot und dann
16:57kam der erste Unterschritt steht, denn
16:58ich bin hingegangen, habe Tools in
17:00diesen Hannes eingebaut und
17:01normalerweise kann man ja das LM prüfen
17:03lassen, ob der Quellcode gemäß eine
17:05Vorgabe Richtlinie ist, aber jetzt wisst
17:07ihr a ist das nicht besonders genau und
17:09vor allen Dingen dauert das relativ
17:10lange. Ich bin hingegangen und habe mit
17:11statistischen Tools gearbeitet. In
17:13diesem Fall Pend und Resharper für die
17:15Quellcode Ebenene. Und mit dieser
17:17Kombination aus Guidelines, aus
17:19statischer Codeanalyse und statischer
17:21Strukturanalyse konnte ich
17:22sicherstellen, dass das LM nach jeder
17:24Codeung sicherstellen konnte, dass die
17:26Codeänderung im Rahmen meiner
17:27Richtlinien war. Für dieses Experiment
17:29habe ich zwei verschiedene Richtlinien
17:31verwendet. einmal die
17:32Architekturrichtlinie, die die
17:33Systemarchitektur beschreibt. Die durfte
17:35ich aus einem Kundenprojekt rausnehmen
17:36für Andypend, wie gesagt, mit 880 Regeln
17:39und eine sehr umfangreiche Codieriglinie
17:41für CSARP, aber auch für Blazer. Das ist
17:45die Frontte Technologie bei Microsoft.
17:48So, nach dieser Toolüberprüfung, nachdem
17:49wir sicherstellen konnten, okay, das ist
17:50jetzt alles gemäß Architektur entworfen,
17:53dann bin ich hingegangen und habe wieder
17:54die Kontrolle gemacht. Diesmal aber
17:56nicht mehr so die Kontrolle, wo es um
17:57die Funktionalität ging, weil meistens
17:59war es so, dass die Funktionalität schon
18:00richtig implementiert wurde. Wir kommen
18:02gleich noch zum nächsten Schritt,
18:03sondern es ging viel mehr darum zu
18:04beobachten, okay, der Quellcode, der
18:06jetzt rausgekommen ist, ist er so, wie
18:07er im Haris gefordert war. Wenn
18:09irgendwelche Abweichung drin war, dann
18:11war klar, der Harness muss korrigiert
18:13werden. Das hier nennt man auch Harness
18:14Correction Development, wo man also
18:15immer wieder iterativ hingeht und diesen
18:17Harness korrigiert. Phase 3, dann war
18:20Specriven. Specdriven bedeutet, dass wir
18:22hingehen und nicht mehr primär mit Proms
18:24arbeiten, sondern wir bringen jetzt
18:25unserem LM bei wie aus Anforderung quasi
18:29wie wie eine Anforderung zerlegt wird in
18:31einzelne Entwicklungsaufgaben. Und dem
18:33Moment, wo wir unserem LM in diesem
18:34Harnet das mitteilen, wie wir das machen
18:36möchten, wie wir uns das vorstellen,
18:37können wir hingehen und können direkt
18:39Specs nehmen, also direkte Stories, die
18:41ihr normalerweise aus Asure und Asure
18:42Defops und Gira kennt und können die dem
18:45LM geben und das LM zerlegt diese dann
18:47in verschiedene Prompts, arbeitet die
18:48dann ab, entwickelt wieder Quellcode.
18:50Dieser Quellcode wird dann wieder Tool
18:52unterstützt geprüft, ob er gemäß Design
18:53und Architekturrichtlinie ist. Dann wird
18:55wieder kontrolliert, ob das alles
18:56richtig ist, ob die Anforderung richtig
18:58zerlegt wurde, die Architektur richtig
18:59implementiert wurde und gegebenenfalls
19:01dieser Hannes kontrolliert,
19:03kontrolliert, korrigiert.
19:05Phase 4, dann ist Testdriven. Ich habe
19:07direkt von Anfang an mit Tests
19:08gearbeitet, habe die ersten Tests noch
19:10von Hand geschrieben, habe die
19:11analysieren lassen, bin dann aber
19:12schnell dazu übergegangen, im Harnis
19:13wieder festzulegen, wie wollen wir dann
19:15testen? Das heißt, eine neue Datei
19:17beschreibt genau, wie eine ein Test
19:19strukturiert werden sollte, was getestet
19:20werden soll, was nicht, wie die Tests
19:22aufgebaut werden sollten, wie die
19:23ausgeführt werden sollten und so weiter
19:25und so fort. S, dass wir nach dieser
19:27Speck, aus der wir den Pompt generieren,
19:28als erstes mal ein Testfall generieren
19:30lassen. Und wichtig hier, viele zeigen
19:32immer die Tests so in den Videos, wo
19:34Quellcode genommen wird, dazu wird ein
19:35Test generiert. Das macht natürlich
19:36nicht wirklich viel Sinn, weil dann
19:37testet der Test einfach nur den
19:39Quellcode, der da war. Wir wollen ja in
19:41der Softwareentwicklung Tests generieren
19:42und diese Tests verifizieren ein
19:44Systemverhalten, ein
19:45Anforderungsverhalten. Wenn wir also 10
19:47Anforderungen haben mit keine Ahnung 30,
19:4940 Akzeptanzkriterien, ist ja Sinn der
19:51Test nicht irgendwas zu testen, dass wir
19:53im Quellcode geschrieben haben, sondern
19:55es sollen Tests geschrieben werden, die
19:56das Spezifikationsverhalten
19:58verifizieren. Und hier werden diese
20:00Tests direkt aus den Anforderungen, aus
20:02den Akzeptanzkriterien, die ich dort
20:03reingeschrieben habe, abgeleitet. Der
20:05weitere Verlauf ist dann as usual oder
20:08wie im vorigen Schritt, wir generieren
20:09Quellcode. Dann führen wir die Test
20:10natürlich einmal aus, gucken, ob der
20:12Quellcode das gewünschte Systemverhalten
20:14erzielt hat. Dann wieder die Prüfung, ob
20:16die Architektur in Ordnung war, die
20:18Verifikation, gucken, ob die Tests
20:20passen, ob die Implementierung der
20:21Architektur passt und gegebenenfalls
20:23dann wieder diese Korrektur von dem
20:25Harness.
20:26Vierte Schritt dann ist die Idea Driven
20:28Phase, wo man hingeht und sagt, okay,
20:30wir haben jetzt unsere LM so weit
20:31gebracht, dass wir in der Lage sind,
20:33Spezifikationen in unser LM reinzugeben
20:35oder in unseren Coding Agenten. Und wir
20:37gehen jetzt noch einen Schritt weiter,
20:38weil wenn wir uns mal genau anschauen,
20:39was in der Phase der Anforderungsanalyse
20:41eigentlich passiert, dort haben wir
20:42Ideen von Stakeholdern, die sammeln wir,
20:44bereiten die auf und generieren daraus
20:46Anforderung. Aber auch das ist mehr oder
20:47weniger einfach nur ein Task, wo wir
20:49Textdateien transformieren am Ende des
20:51Tages und deswegen kann man diesem
20:52Harness auch beibringen, wie Ideen
20:54aussehen, wie Ideen beschrieben werden
20:56sollten. Und dann kann der Harness diese
20:58Idee, die wir haben und die können wir
21:00ihm geben, kann er in Anforderung
21:01zerlegen und diese Anforderung, die dann
21:02auf Business Niveau geschrieben sind,
21:04die können wir dann quasi ins Review
21:06mitnehmen, können uns die angucken, ob
21:07die vollständig geschrieben sind, ob die
21:08Akzeptanzkriterien passen etc. pp. Und
21:11dann können wir quasi aus dieser D alle
21:13generierten Spezifikationen in das
21:15System reingeben und dann werden sie
21:17entsprechend entwickelt. Und der letzte
21:19Schritt, die Phase 5, das ist dann das
21:21Voice Driven Development, wo ich als
21:23Entwickler sich mir die Fußnägel
21:25hochrollen, aber es ist leider leider
21:26gut. Also, wir gehen einfach hin und
21:28auch dieses Beschreiben einer Idee ist
21:30ja nichts anderes als dass wir
21:31Informationen aufnehmen und dann dieses
21:33Ideendokument fertig machen. Und ich
21:35habe dem Harness dann beigebracht, wie
21:37Ideen formuliert werden sollten in
21:38unserer Situation und dann habe ich
21:40einfach das ganze ihm die Ideen per
21:42Sprache diktiert und wichtig dabei, ihr
21:43müsst das jetzt nicht so vorstellen,
21:45dass ich ihn d vi Stunden zugequatscht
21:47habe und alles fleißig mitgemeißelt
21:49habe. Ich habe ihm gesagt: "Hey, ich
21:50möchte mit dir an Ideen arbeiten und
21:52Ideen bedeutet immer, ich habe gewisse
21:53Ideen für das System, gewisse
21:55Vorstellung. Du hast einen Überblick
21:57über das gesamte System, über alle
21:58Spezifikationen, alle Tests etc. Ich
22:00will, dass du mit mir kritisch über
22:01genau diese Funktionalitäten diskutierst
22:03und das hier ich das tut mir wirklich
22:05selber weh, das als Softwareentwickler
22:07zu sagen, ist einfach unglaublich gut.
22:09Ich bin einmal nach Wien gefahren zu
22:10einem Kunden und habe auf der Fahrt nach
22:12Wien das größte Modul quasi mit ihm
22:14durchgesprochen, die Workshop Planung
22:16und diese Planung hat 4er Stunden
22:17gedauert. Ich habe vier Stunden mit ihm
22:19im Voiceemode mit mit Claud diskutiert,
22:22wie wir das Ganze umsetzen. Der hat
22:23immer wieder gesagt, ja, aber denk daran
22:24und DMDUL ist das so gemacht und
22:26rechtlich gesehen müsstest du das so und
22:27so umsetzen. Das heißt im Endeffekt am
22:30Anfang habe ich gestartet in der ersten
22:31Phase so bisschen als Entwickler. In der
22:33zweiten, dritten Phase bin ich dann so
22:34in die Rolle des des Architektenfass
22:37reingerutscht. Dann in der in der
22:39vierten, fünften Phase oder in der
22:40vierten Phase bin ich dann in die Rolle
22:42des PO reingerutscht nur noch und jetzt
22:44hier in Phase 5 war ich rausgedrückt aus
22:45der ganzen Softwareentwicklung in diese
22:47Rolle eigentlich des Stakeholers und ein
22:50Großteil der Anwendung, die ihr die ihr
22:52seht gleich bei der Zusammenfassung ist
22:53alles IDE driven Driven entwickelt. Das
22:55heißt viele von euch werden sich fragen,
22:57hast du den Quellcode angeguckt etc. pp.
22:59Ja, habe ich gemacht am Anfang, aber
23:01ganz ehrlich, irgendwann war es einfach
23:03überflüssig, sich den Quellcode
23:04anzugucken, weil ich wusste, durch die
23:06Tools, die ich integriert habe, Resarper
23:07Independ, ist der Quellcode immer so,
23:09wie ich ihn geschrieben hätte. Also die
23:10Struktur ist genauso, die Klassen
23:12genauso, die Komponenten genauso. Er hat
23:13sich an alle Vorgaben gehalten und das
23:16was er wo er noch ein bisschen
23:17Kreativität hatte, war auf der Quellcode
23:19Ebene und die hat er manchmal nicht so
23:20geschrieben, wie ich sie geschrieben
23:21hätte, aber er hat sie auch nicht
23:22schlecht geschrieben. Das heißt, ich
23:24kann sichergehen, dass wenn ich mit
23:25diesem System so arbeite, wie ihr es
23:26hier seht, dass am Ende Funktionalität
23:28rauskommt, die getestet ist, die genau
23:30zu dem passt, was ich spezifiziert habe.
23:32Und die Struktur, die im Hintergrund
23:33entsteht, die ist mehr oder weniger
23:35genauso als wenn ich sie geschrieben
23:36hätte. Jede einzelne Klasse, jeder
23:38einzelne Methode. Beim Quellcode weicht
23:40das ein bisschen ab, aber sind wir
23:41realistisch, wenn ich mit anderen
23:42Kollegen programmieren würde, da würde
23:43ich den Quellcode auch nicht immer 100%
23:45so finden, wie ich ihn haben wollte.
23:47Aber hier schulotenmäßig gesehen, der
23:49schlechteste Quellcode, den ich jemals
23:50gesehen habe, der war eine zwei. Der
23:51Rest war immer zwischen 1 und 2. Was ist
23:53jetzt das Ergebnis der ganzen Nummer,
23:55die ihr gesehen habt? Also das Projekt
23:57ist sehr groß geworden, sehr umfangreich
24:00geworden, das kann man nicht anders
24:01sagen. Also ich habe im Endeffekt, lass
24:03mich kurz auf die Specs schielen hier,
24:04213 User Stories implementiert, 4083
24:09Akzeptanzkriterien. Es sind 10 Services,
24:11also Microservices geworden. Am Ende 420
24:13Endpoints. In meinem MCP Server gibt es
24:16108 Tools, die aufgerufen werden können.
24:18Das System alleine verschickt 135
24:20E-Mails über N8N. Super gut aussehen die
24:23E-Mails by the way 88 Workflows
24:26innerhalb von N8N und es sind 10
24:28Datenbanken passen zu den Services mit
24:29113 Tabellen und 1300 Seiten
24:32Dokumentationen und auch die
24:33Dokumentation muss man auch sagen super
24:35gut super strukturiert gemacht und vor
24:37allen Dingen ich habe immer eine den
24:38großen der großen Probleme gehabt, dass
24:40die Dokumentation relativ schnell out of
24:41Synk war mit der Implementierung. Ich
24:43habe mir irgendwann nach 2 d Tagen einen
24:45Daily Nightly Task gebaut, das jeden
24:47Nacht auf dem Bildserver mit Cloud Code
24:50einen komplett neue Dokumentation
24:51erstellt wurde. Das heißt, ich hatte
24:52morgens immer die Innk Dokumentation mit
24:54dem Rest und ich habe seltener in den
24:56Quellcook geschaut als wirklich in der
24:58Dokumentation, die ist die ist wirklich
24:59extrem gut geworden. Aber die Dinge, die
25:01natürlich relevant sind für uns, das
25:03sind die Ergebnisse auf Code eben und
25:04wenn wir uns das mal anschauen, dann
25:05haben wir 2900 API Tests geschrieben.
25:08Also für die Endpunkte, für die Workflow
25:10Tests 392 und sind bei 420.000
25:15Zahlen Code gelandet und das ist schon
25:17eine ganze ganze Menge. Klar, ihr habt
25:19vielleicht Projekte, die wesentlich
25:20größer sind, aber wir müssen ja gleich
25:21noch über den Scope sprechen. Und bei
25:23diesen 420.000 Zahlen Code, dass die
25:25erstellt werden können, dass was
25:26hinkriegt, das war mir klar. Das war
25:27jetzt keine großartige Überraschung.
25:29Überraschung war dann schon eher die
25:30Qualität, denn qualitätsmäßig habe ich
25:33schon gesagt, für mich zählt sowas wie
25:34die Testüberdeckung und wir haben eine
25:35Testüberdeckung im Backend und
25:37Workflows, weil das sind die Tests, die
25:38ich definiert habe von 85%. Es sind
25:40keine 100, aber diese 85% decken die
25:43kritischten Fade ab, die in der
25:44Anwendung drin sind und wesentlich mehr
25:46als das. Die 15%, die jetzt hier fehlen,
25:48die sind einzig und alleine deswegen
25:50fehlen, weil ich die Workflows, die
25:51getriggert werden durch Office oder
25:53durch Outlook, also wo der Trigger von
25:55extern kommt, die habe ich nicht
25:57gemockt. Wäre auch möglich. Ich könnte
25:58auch 100% kommen, aber ich habe nachher
26:00für mich selber gesagt, okay, der
26:01Tradeoff zwischen dem Investor sich da
26:03reinstecken müsste und dem was
26:04rauskommen würde, das ist es nicht wert.
26:06Nächste Bank ist die Analyse der
26:08strukturellen Schulden. Also die
26:09Anwendung, die entwickelt wurde, wie
26:10genau hält die sich an die
26:11Architekturvorgaben, die ich gemacht
26:13habe, wie genau halten sie sich an die
26:15Designvorgaben? Wie genau ist der
26:16Quellcode so geschrieben, wie ich ihn
26:18haben möchte? Und es sind 0%. Das heißt,
26:21die gesamte Anwendung, jede Klasse, wie
26:23eben schon gesagt, jede Methode und die
26:25meisten Quellcodzahlen sind so
26:26geschrieben, als wenn ich sie
26:27geschrieben hätte. Und das ist das
26:28eigentliche, genau dieser Ganger, von
26:30dem ich geredet habe. Ich kann dem LM
26:32beibringen, dass er genauso entwickeln
26:34soll, wie ich das möchte oder wie euer
26:36Team das möchte oder sonst irgendetwas.
26:38Das heißt, diese ganzen Ausreden, die es
26:39immer gibt, oh, da wird noch Slop
26:41produziert, die Qualität, die
26:42Architektur ist schlecht. Ja, mag sein.
26:44Wenn ihr aber lernt und versteht, wie
26:45das richtig funktioniert, dann ist das
26:47kein Problem. Und dasselbe hatte ich
26:49gerade schon für die Dokumentation
26:50angesprochen. Die ist wirklich extrem
26:52gut. Und hier, ihr seht, hier steht DDOG
26:54für die Developer Documentation. Also,
26:56ich habe ein Entwicklerhandbuch bauen
26:57lassen mehr oder weniger. Und SPT steht
26:59für Structural Dept, also hier reden wir
27:01nicht von technischen Schulden, sondern
27:02von strukturellen Schulden. Wie nah ist
27:04die fertige Anwendung an den
27:06Architekturvorgaben? Wenn wir uns jetzt
27:07mal mit den Kosten beschäftigen, dann
27:08wird das Ganze noch wesentlich
27:11schockierender, interessanter,
27:12schockierender. Seht's, wie ihr wollt.
27:14Ich habe für die gesamte Anwendung, wie
27:15gesagt, versucht mir vier bis sech
27:17Monate Zeit zu nehmen. Zeit zu nehmen
27:19bedeutet bei mir, ich bin in
27:20Kundenprojekten drin, ich bin unterwegs,
27:21ich bin in Reviews und habe Trainings
27:23und Workshops etc. Ich habe es
27:25geschafft, mir innerhalb von diesem
27:27halben Jahr 45 Tage komplett frei zu
27:29machen. Meistens nachts, aber diese 45
27:32Tage a 8 Stunden pro Tag muss man
27:34vielleicht dazu sagen, die habe ich in
27:36dieses System reinvestiert. Und wenn ihr
27:38jetzt die Quellkundmenge betrachtet und
27:40überlegt, dass das mit 0% strukturellen
27:42Schulden und 85% Testüberdeckung
27:44rausgekommen ist, dann merke ich schon
27:45in welche Richtung es geht. Diese 45
27:47Tage, wenn wir die mit einem
27:48Vollkostensatz von 500 € für ein
27:50Entwickler nehmen, das ist ein relativ
27:51gängiger Satz, dann landen wir bei
27:53Personalkosten von 22500 €. Aber ich
27:56habe ja nicht nur Personalkosten gehabt,
27:58ich habe auch ein LM benutzt an zwei
28:00verschiedenen Rechnern. Ich habe am
28:01Anfang mit Codex angefangen, aber
28:02relativ schnell zu Cloud gewechselt,
28:04weil ich Cloud wesentlich besser und
28:06wesentlich genauer finde, vor allen
28:08Dingen für diese Guideline Sache. Und am
28:10ersten Rechner habe ich insgesamt am
28:1220,2 Milliarden Token verballert und am
28:15zweiten PC 6,8 Milliarden Token. Das
28:17wirkt jetzt gewaltig für all diejenigen,
28:19die sich schon mal mit sowas beschäftigt
28:20haben, aber ihr müsst dazu euch
28:21anschauen, oben sind relativ viele Cash
28:23Read Tokens dabei. Also es sind gar
28:25keine generierten Tokens, sondern die
28:26Tokens kamen aus dem KV Cash in Summe
28:29aber 27 Milliarden Tokens. Und viele von
28:32euch haben mal Sorgen, dass die
28:33Tokenpreise bald steigen. Deswegen habe
28:34ich mal mit den aktuellen Tokenpreisen
28:36gerechnet, nicht mit dem Abo und da
28:38hätte ich 21 000 € bei Tropic bezahlt.
28:40Für diese Tokens und kleine Sene hätte
28:42ich ein chinesisches Modell genommen,
28:44z.B. Deepse V4 Pro, auch ein sehr gutes
28:47Modell. Dann hätte ich nur 2000 €
28:49bezahlt. Machen wir auch noch mal ein
28:50spezielles Video zu, weil da klaffen die
28:52Welten auch gewaltig auseinander. Aber
28:54ich habe gar nicht gar nicht von diesen
28:55beiden Dingen bezahlt. Ich habe ein
28:57Cloud 20 ein Cloud 20 Max Abo gehabt und
29:00zwar zwei Stück. Ähm ich habe irgendwann
29:02bin ich immer wieder ans Wochenlimit
29:04gestoßen, deswegen habe ich 6 Monate
29:06lang eins benutzt und noch mal 3 Monate
29:08ein zweites gebucht. Das heißt in Summe
29:09habe ich 1620 €. Das heißt, wenn wir das
29:12mal zusammenfassen, die AI hat 45 Tage
29:15gebraucht, 25 000 € hat mich die ganze
29:17Sache gekostet, 0% Schulden,
29:19strukturelle Schulden, 100%
29:21Entwicklerdokumentation, 85% Tests. Und
29:24damit wir das jetzt irgendwie so ein
29:25bisschen gegeneinander halten können,
29:26habe ich jetzt einfach mal ein
29:27Entwicklungsteam oder zwei
29:28Entwicklungsteam bei meinen Kunden
29:30rausgesucht und zwar das eine Team hat
29:32fünf Entwickler, 350.000 1000 Zahlen
29:34Code hat deren aktuelle Anwendung, die
29:36hat ungefähr 24 Personen Jahre Umfang
29:38und das zweite Team, das hat vier
29:40Entwickler, 300000 Zahlencode und 17
29:43Personen Jahre Umfang ungefähr. Und die
29:46habe ich mal schätzen lassen, hab
29:47gesagt, okay, guckt euch mal die Specs
29:48an, guckt euch mal die Defop Struktur
29:50an, Architektur, Coding, Testing und
29:52Dokumentation und schätzt mal, wie lange
29:54das Ganze dauert, wenn wir das bei euch
29:56im Team entwickeln würden. Und von
29:57diesen beiden Teams habe ich die Zahlen
29:58zurückbekommen. Das waren einmal 23
30:01Personenjahre und 15 Personenjahre. Und
30:02als ich die Zahlen das erste Mal gesehen
30:04habe, da war ich noch am Coden, habe ich
30:05das kann ja nicht sein, das wird ja viel
30:07zu weit auseinanderlufen. Habe dann
30:09quasi Claud und Codex einmal schätzen
30:11lassen, die waren bei 20 und dann habe
30:12ich mich an den ganzen Tag genommen, hab
30:14mal meine eigene Schätzung gemacht und
30:16ich bin bei 18 rausgekommen. Und jetzt
30:18versteht ihr ungefähr in welche Richtung
30:19das geht. Wenn wir diese vier mitteln
30:21würden, wären wir bei 19 Personenjahren.
30:23Und wenn wir das jetzt mal hochrechnen,
30:24diese 19 Personenjahre sind 4180
30:26Arbeitstage und bei 500 € wieder
30:29Vollkostensatz für ein Entwickler sind
30:31wir bei 2 Millionen Euro Projektosten.
30:35Bei der Qualität, die jetzt zu bestimmen
30:36wird es natürlich ein bisschen
30:37schwieriger. Ich habe jetzt einfach die
30:38Projekte genommen von den beiden Teams,
30:40weil in diesem ersten Team haben wir 14%
30:42technische Schulden, 40% dokumentierte
30:45und die Entwickler sagen selber, die
30:46Duckung von uns ist sehr weit von der
30:48Realität entfernt und 60 bis 70% Test
30:50Coverage. Die beiden Teams haben
30:51übrigens auch sowohl die Workflow Tests
30:53implementiert als auch die API Tests.
30:54Deswegen habe ich die unter anderem mit
30:55ausgewählt. Und das zweite Team hat 11%
30:58Schulden, 25% am dokumentierten
31:01Quellcode, die sind ein bisschen genauer
31:02und 55% Descoverage. Das heißt, wenn wir
31:05das jetzt mal mitteln würden, könnte man
31:06sagen, okay, so ein Team hat im Schnitt
31:0813% strukturelle Schulden, 33%
31:10dokumentiert und 60% Testcoverage. Und
31:13wenn wir das dann mal gegeneinander
31:14halten, dann kommen wir genau zu diesen
31:16Ergebnissen, von denen ich am Anfang
31:17geredet habe. Wir haben 4180
31:20Arbeitstage, 2 Millionen Euro Produkt
31:22Projektosten gegen 45 Arbeitstage und 25
31:25€ Projektkosten und die AI hat
31:27wesentlich bessere strukturelle,
31:29dokumentatorische und testmäßige
31:31Ergebnisse geliefert, als es das Team
31:33geliefert hätte. Und ich habe während
31:34dem ganzen Experiment immer wieder
31:35eingeschätzt, wie viel schneller bin ich
31:36mit der KI als die Menschen. Und ich
31:38hatte am Anfang war ich mir sicher,
31:40zweimal werde ich es auf jeden Fall
31:41sein. Hab dann zwischendrin das Gefühl
31:42gehabt, oh, vierfach könnte auch
31:44realistisch sein. Und so ging dachte ich
31:46mir, jo, achtfach könnte es auch sein.
31:48Aber es war ganz anders, denn in
31:50Wirklichkeit war der Faktor
31:5393 93 mal so schnell mit der KI wie das
31:58menschliche Entwicklungsteam. Und wir
31:59können jetzt eine ganze Menge über
32:00diesen Faktor diskutieren und können
32:02sagen, was er für uns bedeutet, wie auf
32:04andere übertragbeist. Das werden wir
32:05auch in den nächsten Videos machen. Ganz
32:06großes Ehrenwort. Aber ähm erstmal
32:08müssen wir für uns selber festhalten,
32:10wir haben einfach eine unglaublichen
32:12Geschwindigkeitsboost beim
32:13gleichzeitigen Qualitätsboost auch noch
32:16dabei. Und wir können jetzt hier bei dem
32:18Faktor 93 diskutieren, ja, da sind jetzt
32:20die Tests mit drin und die ganze Doku
32:21mit drin, das brauchen wir alles nicht.
32:23Okay, geschenkt, sagen wir, der Faktor
32:24ist nicht 93, sondern nur 60. Und ihr
32:26könnt jetzt sagen, oh, aber die Teams,
32:28die haben ja nicht so viel, haben nur
32:29einen Tag Zeit gehabt, die ganzen Sachen
32:31zu schätzen und vielleicht passt dies
32:32und jenes nicht und andere macht was ihr
32:34wollt, gehen wir runter auf 25. Das
32:36heißt, wir sind mittlerweile beim
32:37Viertel, es wäre immer noch 25 mal so
32:40schnell als ein menschliches Team. Und
32:42die Anwendung, die ich entwickelt habe,
32:43ist riesengroß. Die ist voll gepackt mit
32:45Funktionen. Die ist super getestet,
32:47läuft mittlerweile super stabil. Es ist
32:49wirklich enorm, es ist wirklich
32:51erstaunlich, was da am Ende des Tages
32:52rausgekommen ist. Was habe ich jetzt
32:54daraus gelernt? eine ganze Menge. Die
32:56Videoliste ist voll, die wir demnächst
32:58machen werden. Wir werden auch ein
32:59höherer Frequenzvos machen, genau zu
33:00diesem Thema. Und es wird zum auf meinem
33:03Newsletter gibt's am Mittwoch die erste
33:04Ausgabe mit Lessens Learn. Genau zu
33:06diesem Projekt. Noch habt ihr Zeit
33:07anzumelden. Für diejenigen, die sich
33:09später anmelden, ich mache gleich mit
33:11Cloud noch einen Haken hin, dass ihr
33:12auch den letzten Newsletter euch noch
33:13zuschicken lassen könnt.
33:16Erstmal, wenn ihr euch den Faktor
33:18anschaut, nehmen wir wieder den Faktor
33:1996. Bin ich stolz darauf. Auf diesen
33:21Faktor freue ich mich. Ich bin
33:24Softwareentwickler, mein ganzes Leben
33:26gefühlt. Ich habe mit 8 Jahren
33:27angefangen zu programmieren. Seit ich 13
33:2814 bin, versuche ich das Ganze hier
33:30professionell zu machen. Hab es
33:31irgendwann zu meinem Beruf gemacht. Ich
33:33habe alles das hier, was wir machen, von
33:34der Piker aufgelernt mit viel Schweiß,
33:36mit vielen Nächten Arbeit, mit tausenden
33:38von Büchern, die ich gelesen habe, mit
33:40tausend Experimenten etc. Ich habe mir
33:42das ja alles selber beigebracht. Das ist
33:43heute hier in diesem Job mein Kapital.
33:45Trotzdem ist dieses Ding hier in dem
33:48Beispiel 93 mal so schnell wie ich. die
33:51Qualität ist wesentlich besser und das
33:53ganze für ein Bruchteil der Kosten, die
33:55ich normalerweise gebraucht hätte. Und
33:57das ist
33:59auf der einen Seite natürlich extrem
34:00cool. Es hat viel Spaß gemacht, das zu
34:01machen, auch die ganzen Nächte bis
34:03morgens um 4 Uhr und ich habe echt wenig
34:04geschlafen, das glaubt könnt ihr mir
34:06glauben. Es hat viel Spaß gemacht, es
34:08ist hoch interessant, aber auf der
34:09anderen Seite ist natürlich sieht man,
34:10wie viel schneller das geht und man kann
34:12sich die ganze Zeit, wenn man viel wie
34:13ich in den verschiedenen Teams und
34:15Branchen und in der Industrie unterwegs
34:16ist, kann man sich ausmalen, was das für
34:18unsere Branche bedeutet, was das für
34:20euer Unternehmen bedeutet, für eure
34:21Teams, für dich als einzelne Entwickler.
34:23Das macht mir, wenn ich ganz ehrlich
34:25bin, natürlich schon Sorgen, aber auf
34:26der anderen Seite die KI ist da, die
34:28wird nicht weggehen. Wir müssen uns
34:29genau mit dieser Sache arrangieren. Das
34:31heißt, ihr müsst nicht nur diese
34:33Wahrheit annehmen, so wie sie ist. Ob es
34:35jetzt bei euch 96 mal so schnell ist
34:36oder 25 mal oder vielleicht 150, keine
34:39Ahnung, das sollte das Experimente gar
34:40nicht zeigen, aber wir können
34:41unglaublich schnell sein mit einer
34:43unglaublichen Qualität und das ganze
34:46heute schon im Jahre 2026. Das KI
34:48schnell ist geschenkt, dass man mit
34:50Vibecoding auch größere Projekte machen
34:51kann, auch geschenkt, aber für mich war
34:54die eigentliche Überraschung und die
34:55eigentliche Sensation, dass es nicht nur
34:57so schnell geht, sondern vor allen
34:58Dingen mit der Qualität. Das hat mich
35:00wirklich sprachlos gemacht und mich
35:02würde gerade mal interessieren, lasst
35:03uns mal in den Kommentaren diskutieren.
35:05Mich würde mal interessieren, ob euch
35:06die Qualität hier überrascht od ob ihr
35:07selber schon so arbeitet, ob ihr in die
35:09Richtung geht, weil das hier ist die Art
35:11und Weise, wie wir heute entwickeln
35:12können. Aber ich glaube bei mir, wenn
35:13ich mal alle Kunden übereinander nehme,
35:14habe ich vielleicht zwei Kunden, die in
35:17einer ähnlichen Art und Weise wie hier
35:18schon entwickeln und dann haben wir eben
35:19die ganze Bandbreite, die die ersten
35:21paar Promps gemacht haben, die schon ein
35:22bisschen mehr machen. Und das hier muss
35:23ich wirklich sagen ist sensationell.
35:25Heißt es jetzt jeder kann so eine
35:26Anwendung entwickeln. Jeder kann mit der
35:28Qualität, mit der Geschwindigkeit einer
35:29Anwendung entwickeln. Nein, die Qualität
35:31am Ende ist deswegen so gut, weil ich so
35:33viel Zeit, so viel Energie in den Harnis
35:35gesteckt habe, weil ich seit vielen
35:36Jahren, Jahrzehnten, Qualität in
35:37Architektur mache. Ich weiß, wie ich
35:39sowas für ein Team beschreiben muss und
35:41da ist auch der Weg nicht weit, das
35:42Ganze für eine KI zu beschreiben. Und
35:44deswegen, wenn ihr euch mit sowas
35:45beschäftigen wollt, lernt die
35:46Grundlagen. Wie ich immer schon gesagt
35:48habe, KI ist eine super super Werkzeug,
35:50wenn ihr Grundlagen Softwareentwicklung,
35:51Software Architektur verstanden habt und
35:53das ist auch bei KI super hilfreich. an
35:55der Stelle habt die Einblendung eben
35:56gesehen, ich habe die Workshops
35:58umgestellt auf KI für Entwickler, ähm
36:00Anforderung mit KI und KI Strategie für
36:02Unternehmen. Und da kümmern wir uns
36:03genau darum, wie ihr als Entwickler so
36:04etwas aufbaut, wie ihr quasi Anforderung
36:06für System entwickelt und aber auch wie
36:08ihr als Unternehmen euch strategisch neu
36:10auf dieser KI einrichtet, weil je später
36:13ihr das macht, umso ja schwieriger wird
36:15es nachher noch hinterherzukommen. Jetzt
36:17ist es schon ein bisschen zu spät, aber
36:18noch könnt ihr das als Entwickler, als
36:19Unternehmen schaffen. Deswegen lass uns
36:21das zusammen angehen und nicht nur in
36:23den Workshops, sondern auch in diesen
36:25Videos. Wir starten ab der nächsten
36:26Woche wieder zeitiger oder frequenter
36:29mit den Videos, dann arbeiten wir das
36:30Ganze ab. Wenn ihr noch besondere Fragen
36:32zu diesen Sachen habt, was wir in
36:33welchem Video diskutieren sollten, könnt
36:35ihr auch noch gerne unten in die
36:36Kommentare schreiben, dass ihr gerne den
36:37Hahnes sehen wollt oder sonst
36:39irgendetwas, dann machen wir das auch.
36:41Das war mein Experiment. Ich bin noch
36:43immer schockiert, sage ich euch ganz
36:45ehrlich und ich bin mal gespannt,
36:47wirklich gespannt, was ihr dazu sagt.
36:48Ich wünsche euch einen schönen Tag, viel
36:50Spaß beim Arbeiten, bis zum nächsten
36:52Video und ciao.

About this transcript

This page contains the full transcript of Der Moment, der die Softwareentwicklung geändert hat! by David Tielke, generated from the public captions YouTube serves with the video. The transcript has 7,589 words across 1,269 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.