Mit zunehmender Leistungsfähigkeit von Coding
Agenten hat sich ein Muster heraus kristallisiert.
Du beschreibst ein Ziel, du bekommst einen Codeblock zurück
und oft sieht er richtig aus, aber funktioniert nicht ganz,
der Code kompiliert nicht oder löst nur einen Teil des Problems
oder ist einfach nicht genau so gebaut wie du ihn geschrieben
hättest. Das Problem ist hier ganz oft
nicht die Coding Leistungsfähigkeit der KI
Modelle, sondern dass wir sie mit zu wenig oder zu unpräzisen
Anweisungen und Kontext versorgen.
Wir müssen also an unserer Spezifikation arbeiten und genau
hier kommt Spec driven Development ins Spiel.
Und damit herzlich Willkommen zu Folge 137 this to do Developer
Podcast tatsächlich 137 und nicht 136, da wir nachher
gemerkt haben, dass wir die Folge 135 zweimal angekündigt
haben, sehen wir jetzt die 136 in der Ankündigung und sind
sofort bei 137 wir haben. Uns ein einziges Mal verzählt in
136 Folgen. Ich glaube, dass.
Verzeihen uns die Leute? Ja, aber trotzdem vielen Dank
für die Hinweise an diejenigen, die uns darauf hingewiesen haben
und wir das direkt am Montag zumindest in der Podcast
Beschreibung korrigieren konnten.
Ja, der to do Developer Podcast ist.
Ein gemeinsames Projekt von Robin Manuel Thiel.
Er ist Director icloud bei Jtl Software und mir malte Lantin
ich bin Solutions Engineer bei github und wir machen den
Podcast privat und in unserer Freizeit und unterhalten uns
hier über diverse Themen aus dem Developer Alltag, immer
abwechselnd mit einer Themenfolge wie heute und einer
News Folge, die jeweils am Montag erscheint.
Und ihr habt uns nicht nur Bescheid gesagt, dass wir uns
verzählt haben. Sondern ihr habt uns auch Kaffee
ausgegeben. Einen davon habe ich gleich
heute Morgen am Bahnhof eingelöst.
Wir haben 5 Kaffee von Me and Company, wer auch immer das ist,
bekommen ganz herzlichen Dank. Vielen Dank dafür.
Und damit steigen wir auch direkt ins Thema ein.
Dieses Mal wie gesagt wieder eine Themenfolge und wir reden
heute über Specdriven Development, vielleicht ganz
kurz zum Einstieg. Was verbirgt sich dahinter?
Ja, kurz gesagt, bevor wir anfangen zu coden oder auch in
der KI zu coden zu lassen, setzen wir uns im Specdriven
Development hin und arbeiten eine detaillierte.
Das ist wichtig Spezifikation aus, das müssen wir gar nicht
immer alles selber machen, dieses Ausarbeiten, das können
wir auch gemeinsam mit der KI oder mit dem Agenten machen, das
kann auch teilweise richtig lang werden, also das sind viele,
viele 100 Zeilen, meistens irgendwie markdown Code.
Und in dieser Spezifikation beschreiben wir eben nicht nur
genau, was wir haben wollen, sondern auch, warum wir es haben
wollen, unter welchen Umständen das wie funktionieren soll.
Edge Cases und all die Sachen, die man ja auch sonst irgendwie
bespricht, vielleicht mit einem menschlichen Developer, und das
lassen wir uns dann aber auch wieder challengen ebenfalls von
der KI, vor allem auf Vollständigkeit und auf
Nachvollziehbarkeit und Konsistenz und.
Und dann coden wir aber quasi, indem wir das Ganze erst
ausarbeiten und dann der KI mitgeben in den Kontext.
Wir schreiben also eigentlich eine sehr detaillierte
Anleitung, gar nicht unbedingt, wie jetzt genau gecoded werden
soll, sondern eher was und warum es gecoded werden soll und geben
das in die KI mit rein. Da gibt es verschiedene Tools
und Framework Streams auch dabei helfen eben diese Anleitung
diese Spezifikation zu erstellen, aber das.
So ganz neu ist es eigentlich nicht.
Es gab in der Geschichte immer mal wieder und also sowas, dass
man sich irgendwie erst hingesetzt hat und sehr, sehr
viel spezifiziert hat, und dann ist das irgendwie wieder
verschwunden und wurde abgelöst von anderen Sachen und dann kam
es wieder in anderer Form. Malte, du hast da mal ein
bisschen recherchiert und hast eine kleine Geschichtsstunde für
uns. Ja, tatsächlich war es nie
wirklich weg. Aber es ist so ein bisschen ein
Pendel, was hin und Her schwingt.
Zwischen mehr Struktur und vielleicht ein bisschen mehr
Chaos, ein bisschen mehr Flexibilität oder ein bisschen
mehr Planung. Und tatsächlich haben wir heute
eigentlich eine Beschleunigung dieser Dynamik, wir haben es
über die letzten Jahre gesehen, es kamen immer mehr KI
Development Tools raus und mit diesem Coding Agenten, Du
hattest es vorhin gesagt, egal ob es jetzt irgendwie cursor,
co, Pilot Devin etc. Ist.
Ist natürlich dieser Begriff des Vibe Codings so ein bisschen en
vogue geworden. Immer mehr Leute beschäftigen
sich mit der Softwareentwicklung über einfaches Prompting, und da
ist natürlich das ganze Thema, das ganze Thema Planung, so ein
bisschen ins Hintertreffen geraten und man hat da mehr,
vielleicht fokussiert auf Geschwindigkeit und Dynamik und
weniger irgendwie Intention und Planung und.
Wirklich das Ziel, wirklich langfristig stabile Software zu
bauen und so ein bisschen das Gefühl entsteht, dass wir uns
jetzt so ein bisschen in der Mitte einpendeln mit Specdriven
Development. Wie genau das funktioniert, das
besprechen wir ja gleich noch mal im Detail, aber vielleicht
noch mal ganz kurz für diejenigen von euch, die sich
nicht so mit der Softwareentwicklungsmethodik
über die letzten Jahrzehnte beschäftigt haben, fassen wir
noch mal so ein bisschen die Historie zusammen.
Und zwar kennen viele von euch wahrscheinlich das Wasserfall
Modell. Man hat in den 70er Jahren, als
das Thema Softwareentwicklung immer populärer wurde und immer
mehr Leute sich mit dem Thema beschäftigt haben, sich
erstmalig Gedanken darüber gemacht, wie kann man
softwareentwicklungsprozesse gerade für komplexe große
Softwaresysteme managen und da ist dieses.
Sehr bekannte Wasserfall Modell rausgefallen, wo wir tatsächlich
erst am Anfang uns mit den Anforderungen beschäftigen, dann
designen wir das System, dann implementieren wir das System
und am Ende schauen wir, ob entsprechend die Implementierung
zu unseren Anforderungen passt. Und dann geht es in einen
Wartungsmodus, das heißt, wir haben wirklich wieso ein
Wasserfall, es gibt dort keine Iteration, wie wir es vielleicht
in der modernen Softwareentwicklung haben,
sondern wir fangen mit einer Planung an, am Ende haben wir
ein fertiges Stück Software und das ist so ein bisschen auch so.
In der Ausbildung zum Negativbeispiel für einen
schlechten Prozess verkommen, obwohl es eigentlich sehr gut
gedacht war, weil wir hier natürlich wenig Möglichkeiten
haben, Nachzusteuern. Das heißt, man beschäftigt sich
sehr lange damit, diese Dokumentation am Anfang über die
Requirements zu erstellen. Man hat irgendeinen
Pflichtenheft, man hat ein Lastenheft und geht erst, wenn
das alles irgendwie vollständig und abgenommen ist, in die
Implementierung und kann dann natürlich sehr gut
nachvollziehen, warum man etwas. Etwas gebaut hat, wie man etwas
gebaut hat und hat natürlich damit auch die Möglichkeit, an
Projekten, die sehr groß sind und vielleicht an sehr strikte
Anforderungen gebunden sind. Gerade wenn es jetzt irgendwie
um Militär und Raumfahrttechnik geht, wo ja die
Softwareentwicklung zunächst groß geworden ist.
Da hat man natürlich viele Vorteile, weil man da natürlich
lange planungszeiträume hat, aber auf der anderen Seite
können wir natürlich Fehler oder neue Entwicklungen relativ
schnell relativ schlecht in die Implementierung reinbringen.
Ja, eigentlich ist es ein bisschen endlich.
Jetzt werden wir gleich gleich sehen zu dem, was suspectrim
Development macht. Das ist gar nicht gar nicht so
weit weg davon, früher hast du halt irgendwie einen Wasserfall
so. Ja, auch sehr viele
Dokumentationen geschrieben, also hast ein Pflichtenheft
erstellt, ein Lastenheft erstellt und dann eigentlich nur
noch so ein bisschen die die Spezifikation runter gecoded und
es ist halt auch irgendwie einfacher ein fertiges Dokument
zu implementieren, also auch irgendwie für jemanden, der
vielleicht gar nicht so tief technisch ist.
Es ist natürlich einfacher, auch dieses Dokument dann zu
schreiben, anstatt den Code nachher zu coden.
Klar, die meisten die hier den Podcast zuhören, die Coden
wahrscheinlich lieber, aber einfacher ist es ja nicht
unbedingt und. Und das Ganze kam auch so ein
bisschen aus einer Zeit, wo es so ganz klare verschiedene
Rollen in der Softwareentwicklung gab, wo man
sich auch gegenseitig vielleicht gar nicht so viel vertraut hat,
wo wirklich, ganz klar, wir müssen hier alles ganz genau
spezifizieren und runterschreiben und dann geben
wir das ab woanders hin, in so eine Art Blackbox und kriegen
dann irgendwann ein Ergebnis und können eigentlich nur hoffen,
dass das sehr, sehr nah an dieser Spezifikation ist.
Und deswegen. Investieren wir auch so viel
Energie, diese Spezifikation zu schreiben?
Diese Pflichtenhefte wurden ja sehr, sehr lang und sehr, sehr
groß dann irgendwann, aber dieses ich vertraue gar nicht
genau dem Ergebnis und ich gebe das in so eine Blackbox rein,
das sind ja 2 Dinge, die gar nicht so weit weg sind vom Vibe
Coding, wo ich dann irgendwas einem KI Modell gebe, was dann
einen Code ausspuckt oder wo ich dann halt auch dieses Tiefe
Vertrauen, ob das jetzt wirklich so ist wie ich das haben will ja
auch nicht da ist. Ja, als du das gerade
beschrieben hast, hatte ich tatsächlich auch gedacht, das
hört sich eigentlich genauso an wie heute mit KI Agenten
gemeinsam entwickelt wird. Wir machen uns Gedanken darüber,
was wir implementieren wollen und der KI Agent baut das dann
für mich und man hat so ein bisschen immer darüber
gesprochen, gerade in diesen traditionellen
Softwareentwicklungsmodellen, dass man dann irgendwie so ein
Anforderungsdokument irgendwann Zaun wirft zu einem
Entwicklungsteam und irgendwann kommt dann die fertige Software
zurück. Und das Ganze hat sich natürlich
im Laufe der Zeit weiterentwickelt.
In Deutschland wird dann das v Modell entwickelt, was quasi
dieser sehr linearen Abfolge noch einen zweiten Ast
hinzugefügt hat, das heißt, wir haben auf der einen Seite die
eine Seite des Vs, wo wir runtergehen von der
Spezifikation bis hin am Ende zur Implementierung und dann der
andere Ast sind entsprechend die Validierung.
Punkte in der Implementierung, das heißt, Wir haben auf der
einen Seite unsere User Stories, die am Ende von Usern auch
abgenommen werden, wenn die Software fertig ist.
Wir haben unsere Code Ebene, die am besten durch Tests abgedeckt
wird und wir haben natürlich diese verschiedenen Module, in
die wir runtergebrochen haben, die am Ende durch
Integrationstests. Geprüft werden, das heißt, alle
diese Dinge, die wir quasi sehr linear aufgebaut haben, werden
auf der anderen Seite jeweils validiert.
Und das sind ja durchaus alles Patterns, die man auch heute in
der Softwareentwicklung. Immer noch sehr stark beherzigt,
egal ob man jetzt in so einem sehr strikten Modell ist und
ganz viele Unternehmen sind noch in einer Welt, wo man
tatsächlich sich noch an diesem v Modell orientiert, weil man
dort immer noch sehr klassische Entwicklungsprozesse hat.
Auch größere Projekte baut, weil man zum Beispiel in der
Automobilindustrie auf einen speziellen.
Tag hin arbeitet zu dem Halt das Fahrzeug vom Band rollt und da
kann man jetzt nicht komplett komplett flexibel in so einem
agilen Modell arbeiten, sondern man hat tatsächlich ein festes
Enddatum zu dem Halt eine vorher spezifizierte Anzahl von
Funktionalitäten validiert, geprüft, mit einem ganz hohen
Sicherheitsstandard verfügbar sein muss und dementsprechend
orientiert man sich immer noch heute ganz grob an diesem v
Modell in vielen Bereichen und da gibt es auch eine.
Iteration das sogenannte v Modell XT, was einem aber ein
bisschen mehr Flexibilität und auch Agilität in diesem Modell
einräumt. Ja, das wird immer so ein
bisschen belächelt. Es gibt dann irgendwie so auf
Konferenzen wird sich darüber lustig gemacht, wenn man da wird
Wasserfall noch irgendwie so als als so ein Urzeitding gemacht,
so du bist ein v Modell oder du entwickelst nicht agil oder
irgendwie sowas. Dabei hat das ja, wie du gerade
richtig sagst, auch immer mal wieder seine Berechtigung.
Es gibt ja durchaus Prozesse, keiner, wenn ich jetzt in der
Industriefertigung bin, da kann ich nicht agil entwickeln und
alle alle 3 Wochen irgendwie meine meine Fertigungsstraße
nochmal ändern oder anpassen, da werden dann teilweise auch
Schablonen für Teile gegossen oder sowas, die dann einfach
nicht mehr veränderbar sind, da macht es ja durchaus auch Sinn
in diesen in diesen Schritten zu arbeiten und wie groß die.
Wie lang ein so ein Wasserfall, wie lang ein so ein Zweig von so
einem v Modell ist, das kann ja durchaus variieren.
Man kann ja auch so, gibt ja diese Wasserfallentwicklung auf,
wo man trotzdem versucht so einen sprintigen Wasserfall oder
sowas zu bauen. Also ich finde das immer, ich
finde es eigentlich so ein bisschen schade, dass das immer
so halt immer nur negativ gesehen und belichtet wird,
zumindest irgendwie so ein bisschen in meiner.
Wahrnehmung ja, und wie wichtig das ist, merkt man dann glaube
ich auch heute, dass man eine gewisse Struktur braucht.
Ich meine, da wo wir heute vielleicht irgendwie gelandet
sind mit vipe Coding, da sind wir natürlich auch hingekommen
über die ganzen agilen Methoden, die wir über die letzten
Jahrzehnte immer mehr verbreitet haben, egal, ob es jetzt
irgendwie. Scrum ist, ob Scanban ist
Extreme Programming. Das Ganze gibt es erst seit
Anfang der 2000 er Jahre und da war die Grundidee zu sagen okay
wir brauchen weniger Prozess, wir müssen uns mehr auf die
Menschen konzentrieren, wir müssen uns auf funktionierende
Software statt Dokumentation konzentrieren, wir brauchen eher
regelmäßige Zeremonien, wo die Menschen zusammenkommen und sich
über bestimmte Dinge abstimmen und einig sind, als dass wir
alles niederschreiben. Und das Ganze hat auch für viele
Bereiche, ich glaube, gerade jetzt, wenn wir über die ganzen
Web und mobile Applikationen, die wir über die letzten
Jahrzehnte gesehen haben, sehr gut funktioniert, weil da kann
man natürlich sehr schnell iterieren, man kann sehr schnell
neue Features schippen, man kann sehr, wirklich tagesaktuell
quasi auf die Anforderungen der User reagieren und.
Und ich glaube, damit hatte das auch absolut und hat auch
weiterhin seine Berechtigung, dass man in vielen Bereichen so
agil arbeitet, sofern man das dann auch mit der mit den
nötigen Anforderungen auch an langfristige Zuverlässigkeit
verbindet. Ja, da ist dann ja auch dieses
agile Manifesto entstanden und diese ganzen Methoden sind da
irgendwie drumherum. Drum gesponnen worden.
Also jetzt gar nicht gesponnen im Sinne von die Spinnen,
sondern entstanden gewebt worden, dass man eben möglichst
viele Feedback Loops einbaut, möglichst oft auch alle
Stakeholder immer mal wieder an den Tisch holt und abholt, dass
es eigentlich auch ein Produkt hat, was konstant shippable ist.
Da geht es wirklich darum, dass ich am Ende von einem Sprint,
zum Beispiel wenn ich jetzt in Scrum denke oder so was, halt
jederzeit was releasen kann in kleinen Iterationen.
Mir Feedback einholen kann und so weiter und da muss man sich
natürlich fragen, ob das was ist, was ich in so einer in so
einer Welt von von KI Agenten, ob ich das überhaupt möchte,
weil die ich denke mir immer so, ja, das ist richtig, wenn man
mit Menschen arbeitet, aber vielleicht ist das ja genau die
Trennung, die ich habe, aber das ist ja auch oft so die Frage,
irgendwie keine Ahnung, wenn wir von KI genten ersetzt oder
programmieren wir Seite an Seite an Seite mit ihnen oder gibt es
bestimmte Aufgaben, die wir denen geben, oder?
Und bei einem KI Agent ist es ja genau das, was ich vermeiden
will ist, dass der mich eigentlich ständig wieder um
Feedback bittet und dass er mich eigentlich ständig fragt, weil
der große Vorteil gegenüber einem Menschen, wenn ich mit
einer KI beite, der ist ja, dass ich da 30 Stück von parallel im
Hintergrund laufen lassen kann und wenn die aber alle mit mir
ein Scrum Meeting machen wollen, einmal einmal alle paar Stunden
oder sowas und alle morgens ein Stand up oder sowas und.
Dann bin ich dann natürlich sehr mit beschäftigt und das ist auch
so ein bisschen die Gefahr. Dann die Menschen sehen, dass
ich eigentlich nur noch in so einen KI orchestraitor oder
sowas verfalle, weil ich ja vielleicht da genau sagen will,
ich möchte den Task, den du arbeitest.
Das ist ja auch dann kein ganzes Projekt, was über Monate geht,
aber die Sachen halt ganz klar einmal spezifizieren.
Wir klären jetzt am Anfang einmal alle Fragen, die du hast
und dann rennst du bitte los und programmierst so lange bis das
Ding fertig ist. Und zum Beispiel würde ich mit
einem Menschen ja irgendwie anders machen.
Und das ist dann vielleicht genau der Unterschied, dass
diese diese agile Revolution, die da irgendwie so um die
Jahrtausendwende, ich glaube so 2001 und so was ist dieses
Manifesto entstanden, losging. Vielleicht, und das ist eine
ganz offene Frage, die werden wir heute auch nicht lernen
können, aber vielleicht in so einer ernstzunehmenden
enterprising Ki Welt noch mal überdacht werden muss.
Also wie du gerade gesagt hast, es ist was anderes, wenn ich mit
Menschen zusammenarbeite und wenn ich vielleicht in hybriden
Teams mit KI Agenten und Menschen arbeite oder wenn ich
vielleicht nur mit KI Agenten zusammenarbeite, weil du
natürlich bei Menschen auch zum einen langsamere
Implementierungszeiten hast. Das heißt die Zyklen.
Sind dort langsamer und Menschen können auch vielleicht viel
weiter mitdenken. Das heißt, die können halt auch
über das, was du ihnen präsentierst, Hinausdenken.
Das heißt, die sehen den breiteren Kontext, selbst wenn
du ihnen den nicht explizit vorliegst.
Und ich glaube, da muss man natürlich solche KI Systeme mehr
an die Hand nehmen, und ich glaube, da gab es schon auch in
der Vergangenheit einige Ansätze, die einem dann.
In die Richtung gute Ansätze geboten haben, wie zum Beispiel
Behavior Driven Development, wo man tatsächlich aus der
Nutzersicht die verschiedenen Szenarien, die man
implementieren möchte, beschrieben hat und das Ganze
dann genutzt hat, um die Entwicklung in die richtige
Richtung zu steuern. Ich glaube, solche Themen greift
dann letzten Endes auch das Back Driven Development auf.
Ja, das finde ich ganz spannend. Auch, dass du vorhin noch mal
gesagt hast, dass der große Unterschied ja vielleicht auch
ist irgendwie, dass so ein Karrieregger natürlich viel
schneller programmiert und teilweise parallel programmiert
ist und ich da viel, viel öfter dann an diese Feedbackschleife
gehen muss, wenn ich mit einem Menschen arbeite, dann kann ich
mir erst mal eine Woche lang ein Feature implementieren lassen,
der denkt im Idealfall selber mit und wenn der jetzt nach 2
Tagen stecken bleibt, dann sagt er mir Bescheid, normalerweise
nicht und Agent ist. Er tippt ja viel, viel, viel,
viel viel schneller diesen Code runter und vielleicht braucht
man da so ein bisschen andere Methoden und.
Und ein Vorschlag für eine andere Methode ist jetzt genau
dieses Specdriven Development, was sich so ganz vielen Dingen
bedient. Werden wir jetzt so ein bisschen
sehen, die es eigentlich auch in der Vergangenheit schon mal gab.
Also da sind Teile vom Wasserfall vom v Modell, aber
auch vom Agile mit drin und eigentlich ist Specdriven
Development so ein bisschen so neuer Ansatz, bei dem die
Spezifikation selbst, die wird zum zentralen Artefakt um die
sich alles drumherum dreht. Die ist Maschinenlesbar, die ist
also meistens wird sie einfach irgendwie markdown oder halt
Text sein, die ist versioniert, eventuell wird die auch in ein
Git Repository mit eingecheckt und da arbeiten wir eben
Kollaborativ mit mehreren Leuten dran und anstatt jetzt zuerst zu
programmieren und dann die Dokumentation zu schreiben,
beginnst du eben beim Spec Driven Development erst mit der
Spezifikation und das ist dann ein Vertrag darüber, wie sich
dein Code genau verhalten soll, so die Single Source of Truth,
das hatten wir ja Intro ja schon mal so ein bisschen gesagt.
Und dann geht es darum eben, dass ich alle meine technischen
Entscheidungen eindeutig überprüfbar und
entwicklungsfähig niederschreibe und diese dann eventuell auch
noch mal challengen lasse. Das heißt, ich kann sowohl auch
der KI sagen, Hey, ist das irgendwie klar ist, das ist, das
ist das konsistent und was da rauskommt, sind einmal, man
nennt das so, ein bisschen in dieser Spectral Development Welt
constitutions, das sind so die nicht verhandelbaren Prinzipien
in meinem Projekt. Ist zum Beispiel auch ein guter
Ort, wo man so vergangene Entscheidungen es gibt so dieses
Ad RS, das steht für Architecture architecture
decision record, wo man sowas verlinkt, da wird dann irgendwie
genau beschrieben, warum haben wir damals welche Entscheidungen
getroffen, aber auch so Dinge die die einfach für unser, unser
Projekt oder unser Team nicht verhandelbare Grundprinzipien
sind. Das ist zum Beispiel auch was,
wo man so die Agent MD s und die klassischen Anweisungen an den
Agenten definiert. Und dazu zu dieser Constitution
kommen dann eben Spezifikationen für einzelne Features, die man
den Agenten gibt. Das heißt, das Ergebnis ist am
Ende dann eine sehr sehr detaillierte, gehen wir gleich
noch mal darauf an, wie das aussieht, Feature Spezifikation
und das bringt einem deutlich bessere Ergebnisse in dieser KI
Welt. Das Ergebnis ist dann zum
anderen erstmal weniger Rätselraten von der KI, weil ich
sehr genau beschrieben habe, was sie eigentlich haben will und.
Mit vor allem weniger Überraschungen und qualitativ
hochwertigerem Code. Und das spart mir dann ja auch
jede Menge Zeit und Tokens, denn so n Coding Agent, der hat
theoretisch unendlich viel Zeit, ja der kann sich ja die gesamte
Codebasis angucken und alles an Dokumentationen durchlesen was
existiert, aber je mehr Informationen je mehr ich den
Mitgebe und je präziser die sind, desto weniger muss ich
eben selber raussuchen. Und auch bei bei Unklarheiten
oder wenn der Kontext so lang geworden ist, dass er dann
zusammengefasst werden muss. Das ist unter anderem ein großes
Problem bei Cloud Code, da Dropt die Qualität dramatisch, sobald
der Kontext so lang ist. Zusammengefasst werden muss,
gibt es dann auch in dieser Spezifikation wieder einen Ort,
an dem der Agent immer wieder die Initialen Specs und diese
Constitution diese nonegotables nachschauen kann, die gehen halt
nicht verloren im Gesprächsverlauf oder sind
vielleicht in der Zusammenfassung nicht mit drin
und so lohnt es sich am Ende, wenn.
Sehr viel Zeit oder? Auf jeden Fall deutlich mehr
Zeit als so ein Einsatz prompt in die initiale Spezifikation,
die ich mir meistens auch irgendwie abprompte zu stecken,
weil eben jetzt Experimente gezeigt haben, dass das Ergebnis
so viel besser ist, dass ich halt nicht einen prompt schreibe
wie im Vibe Coding dann mal machen lasse, dann wieder ein
Feedback gebe, weil nein, so wollte ich das vielleicht doch
nicht haben, das ist ja mehr so ein bisschen der iterative,
agile Weg, sondern dass die Qualität.
Und natürlich auch die Tatsache, dass ich, wenn ich die
Spezifikation einmal deutlich geschrieben habe, da zahle,
Agenten im Hintergrund parallel dran laufen lassen kann und so
weiter, dass das Halt bessere Ergebnisse bringt.
Ja, du sagst ja auch gerade, man spart ja auch Zeit, weil man
nicht tatsächlich entweder regelmäßige Rückfragen
beantworten muss oder so ein Coding Agent erst mal irgendwie
20 Minuten in die falsche Richtung läuft und man dann
nachsteuern muss und dann irgendwie die ganzen Codezahlen,
die dann geschrieben wurden irgendwie wegschmeißt.
Das heißt man kann. Geht sofort in die richtige
Richtung und legt halt alle diese Informationen vorab fest,
damit man jederzeit darauf referenzieren kann.
Und das hilft mir natürlich auch, wenn ich letzten Endes
vielleicht mit dem Ergebnis von einem Coding Agenten oder einem
Sprachmodell nicht zufrieden bin, dann kann ich quasi die
gleiche Aufgabe auch vielleicht auch noch mal an einen anderen
Agenten geben und kann mir dann ein anderes paralleles Ergebnis
erzeugen lassen, aber auf genau der gleichen Spezifikation, das
heißt? Am Ende macht vielleicht die
Anwendung genau das gleiche, aber je nach Coding Agent wurde
ein bisschen anderer weggenommen.
Der Code wird vielleicht anders geschrieben, das Design sieht
vielleicht ein bisschen anders aus, damit kann man natürlich
auch so eine gewisse Vergleichbarkeit herstellen und
es ist halt nicht dieses One Shot Development oder
regelmäßige Prompting, was man im Wald Coding sonst hätte.
Ja, und ich kann natürlich eben wirklich hingehen.
Und ich sage mal, am Tag setze ich mich hin und spezifiziere
alle Features aus und. Und dann gebe ich 30 coding
Agenten, 30 Features und dann sind die halt am nächsten Tag
fertig und normalerweise würde ich mich hinsetzen und gebe das
dann halt und plane die irgendwelchen Sprints an
menschliche Developers ein. Also ich habe so ein bisschen,
eigentlich wird Markdown so diese zentrale ja fast schon so
Markdown als Programmiersprache, weil ich einmal wirklich ganz
genau alles ausspezifiziere und unsere Rolle wird dann vielmehr
wieder die so von einem Product Owner, wo wir weniger coden aber
mehr lenken. Unsere Rolle ist mehr so zu
verifizieren, dass die Annahmen, die ein Coding Agent getroffen
hat. Die richtigen sind, bevor er
losgeht und das Codet. Und das ist ja jetzt mal ganz
ehrlich, beim menschlichen Developer nicht anders.
Nur die KI kann ich halt zwingen dazu durch entsprechende
Anweisungen, dass sie Unklarheiten anspricht.
Und ich glaube, keiner will ja irgendwie.
Also ich glaube, man muss eigentlich sagen, Code ist ja
eigentlich eine schlechte Stelle, um Requirements zu
erfassen, weil klar, wir wollen alle irgendwie coden und Code
schreiben macht Spaß, aber keiner will Code schreiben und
danach inkrementell in diesem Code die ganze Zeit
Veränderungen machen, weil die Requirements sich ändern oder
dann erst irgendwie nachgeschärft und klar wurden.
Stell dir vor du Code ist irgendwas kommst zu mir, ich
sage ja nee, so habe ich das nicht gemeint und dann muss dann
ist es ja frustrierend, dass du dann deinen Code wieder anpassen
müsstest oder sowas oder auch irgendwie wie du gerade gesagt.
Das Code wegschmeißen muss und so, weil die Anforderungen nicht
klar waren am Anfang, das ist, das ist ja auch, das ist ja
genauso frustrierend und genauso quatschend, das ist ja auch
nicht das, was wir machen wollen, wenn wir Code schreiben
wollen. Natürlich wollen wir auch nicht
einfach nur eine Spezifikation irgendwie runter runterhämmern,
sondern ein bisschen kreativer arbeiten, aber von einer KI, wo
ich diese Kreativität ja vielleicht gar nicht haben will,
weil das ja oft im Moment noch bei der aktuellen Modellqualität
auch einfach in eine falsche Richtung gehen kann, da will ich
das eben auch schreiben, und da ist Code nicht der richtige Weg,
Sachen zu spezifizieren. Sondern baue mir erst diese
diese Spezifikation zusammen und habe dann am Ende sowas wie User
Stories, Functional Requirements Acceptance, Creatorious, Edge
Cases aber auch so so eine Review Checkliste.
Also wenn du irgendwas änderst oder bitte beachte die und die
und die Punkte wenn du auf der Suche nach Innenkonsistenzen
gehst oder Unklarheiten das baue ich am Ende alles aus ne Legend
of User Stories, functional requirements Acceptance
Creatorious Edge Cases das ist für uns als menschlich dir da
passt ja auch alles nichts Neues.
Und deswegen ist es ja eigentlich schon irre, dass wir
dachten, wir können irgendwie wie im vipe Coding mit 34 Sätzen
eine ganze App oder ein Feature beschreiben und dann geht das
Ding los. Das funktioniert auch manchmal,
aber eben in einer Professionelleren oder
brownfield Umgebung nicht so gut und deswegen das ist gar nicht
so weit weg von den Sachen, die wir eh auch irgendwie für
menschliche Developer schreiben und ausformulieren und die wir
dann eben in JIRA Tickets oder github Issues Gießen und das
dieser Challenge Part daran, aber den finde ich ultra
spannend, dass man hingeht und sagt Hey.
Karriergeld ne kann ich zwingen, der mich einfach dazu kommt.
Schau dir das an und guck ob das für dich Sinn ergibt und bitte
Bewerte das nach dieser folgenden Checkliste und hake
das Stück für Stück ab und wenn du da Dinge sind, die noch zu
klären sind. Dann lass uns das klären oder es
gibt zum Beispiel, da kommen wir gleich so ein bisschen in die
Implementierung, aber es gibt in Cloud Codes einen eingebauten
Planungsmodus, zum Beispiel, der Quist mich dann nachher noch,
also Quist heißt, der stellt mir nachher Fragen, habe ich das
richtig verstanden, ist das A oder b, wie du es haben willst.
Und da kannst Du anklicken, AB oder nicht ganz anders, ich
sag's dir mal, oder sollen wir die mobile App nativ bauen oder
mit einem Cross Plattform Framework, weil das hast du
irgendwie gar nicht spezifiziert und er stellt mir dann nachher
wirklich so fragen. Sagen über die Spezifikation, wo
ich mir an, wo ich dann zu stellen komme, wo ich mir
wirklich vielleicht noch keine Gedanken darüber gemacht habe.
Und gesagt, Oh ja, stimmt, das habe ich dir gar nicht gesagt
und diese Iteration, diese Loop, das ist, glaube ich, die Magie.
Ich finde das ganz interessant, wenn man darüber spricht, dann
sieht man so diese Verbindung zu den Dingen, die in der
Vergangenheit auch schon gemacht wurden oder passiert sind.
Deswegen haben wir ja gerade diesen historischen Abriss
gemacht, man sieht wirklich auch Elemente aus dem
Wasserfallmodell, dass man ganz klare.
Requirements Niederschreibt und dann sieht man aber auch diese
agilen Elemente. Du sagst gerade, dass vielleicht
mal jemand drüber schaut und sagt, OK, das hast du in deinen
Requirements vielleicht vergessen, weil ich glaube wir
alle haben das in unserem. Developer Alltag mindestens
einmal erlebt, dass wir irgendwas implementiert haben
und dann am Ende von einem Sprint dann am Ende der Product
Ordner gesagt hat, so hatte ich mir das eigentlich nicht
vorgestellt und dann ja dann hätte das mal ordentlich
spezifizieren sollen und genau dieses Feedback bekommt man ja
jetzt auch sofort ad hoc und wenn man das dann noch mit
bestimmten Elementen aus diesem v Modell zusammenbringt, dass
man zum Beispiel Integration Tests baut, dass man Unit Tests
baut und dann alle diese Elemente gegengetrieben.
Gecheckt werden und nicht nur meine User Stories.
Da hat es gerade gesagt, ich kann dann in so einen Plan Mode
gehen und kriege dann auch Rückfragen ob denn meine meine
Planung vollständig ist. Aber genau so kann ich natürlich
dann auch nachher auf der Code Ebene und Integrations oder
Module Ebene die ganzen Validierungen vornehmen und dann
ist man ja schon wieder relativ nah an dem was man in der
Vergangenheit hat. Das heißt man sieht wirklich wie
diese verschiedenen Trends hier zusammenkommen und das Ganze
kann man dann natürlich auch. Entsprechend in Tooling Gießen,
das heißt, ich muss das jetzt nicht alles wissen, ich muss
diese Prozesse jetzt nicht kennen und erlernen, sondern ich
habe natürlich auch heutzutage Möglichkeiten, das in
entsprechende Werkzeuge zu gießen, die mich dann durch
diesen Prozess führen und die dann quasi dafür sorgen, dass
ich am Ende wirklich alle diese Artefakte erstellt habe, dann
die entsprechenden. Spezifikationen gebaut habe, um
in die Implementierung zu gehen und da gibt es zum Beispiel das
Spec Kit, was ein Open Source Projekt ist, was von github
vorangetrieben wird, was einige dieser Phasen dann in feste
Aufgaben oder Kommandos auf der Kommandozeile gießt.
Genau da gibt es natürlich noch ganz viele andere Tools.
Also Spackit ist jetzt ein Beispiel, was gerade irgendwie
sehr populär ist und wo es auch gerade irgendwie viel
Aufmerksamkeit gibt, weil es sehr, sehr detailliert durch
diesen Anforderungsprozess, diesen Anforderungsprozess
führt. Es gibt aber noch andere, es
gibt Open Spec oder es gibt von von Amazon dieses Kairo oder
kiro Projekt, die haben das Ganze so ein bisschen eigentlich
losgetreten und gestartet, es gibt auch das Spark Framework
und. Und wie gesagt, immer mehr
Editoren und Coding Agenten haben das mit eingebaut.
Also ich habe ja gerade eben schon erwähnt, Crowd Code hat so
eine Plan Phase eingebaut, die auch so Review Loops hat, es
gibt den Cursor und eine Visual Studio Code mittlerweile auch so
eine To do Liste die der Agent sich selber schreibt die man
irgendwie reviewen kann, die verlinken wir natürlich alle in
den in den Show Notes von der Folge, da könnt ihr euch
angucken was ein bisschen für euch funktioniert, aber wir
würden jetzt einfach hier mal am Beispiel von von Spec Kit.
Als ein Tooling Beispiel das ganze durchgehen, also diese
Tools machen eigentlich alle das Gleiche, das sind irgendwelche
oft irgendwelche Generatoren oder ja, fertige Proms und
templates, die dann eben uns dabei helfen, für Spec driven
Development diese Specs zu bauen, also das was früher so
ein bisschen händische Arbeit war, jetzt explizite in
explizite Spezifikationen zu gießen und die dann eben auch
wieder mit einer Ki challengen zu lassen.
Ja und was das Back it so beliebt macht, ist nicht nur,
dass es Open Source ist, sondern dass es auch diverse Coding
Agenten unterstützt. Das heißt?
Fast alle eigentlich. Genau.
Es erzeugt mir entsprechende Shortcuts, die ich in meinem
Coding Agenten, egal ob es jetzt einen Cloud Code, einen github
co. Paletten in Germany ist.
Egal was ich jetzt hier verwende, kriege ich
entsprechende Shortcuts um durch diese Prozessschritte des
Backdriven Development durchzugehen und dort.
Dort beginne ich mit dem, was du vorhin schon erwähnt hast.
Ich beginne mit einer Constitution, also quasi der
Verfassung für mein Entwicklungsprojekt, wo ich halt
genau diese grundlegenden Rahmenbedingungen festlege.
Du hast gerade gesagt, es kommt sehr nah dran an diese ganzen
Instructions, die ich üblicherweise vielleicht für so
einen Agenten auch in so eine Agents and MD.
Packe die halt grundlegende Informationen rund um mein
Projekt enthalten, die Halt immer berücksichtigt werden
müssen, egal an welchem Feature ich gerade implementiere.
Genau. Sobald ich die Constitution dann
fertig habe, gehe ich in die erste richtige spec Phase.
Das heißt dann specify. Also das kann ich dann auch zum
Beispiel mit Specify aufrufen, wenn ich in zum Beispiel Cloud
Code oder gitarco Pilot unterwegs bin.
Ganz wichtig diese diese Slash Commands die das dieses Back it
mitbringt. Dahinter liegt eigentlich nichts
anderes als ein fertiger prompt. Also da hat jemand sich die Mühe
gemacht einen sehr detaillierten prompt zu schreiben, den ich
dann aber nochmal verfeinern kann.
Also ich tippe ein Specifi und gebe dann so eine High Level
Beschreibung von dem was ich da eigentlich bauen will und warum.
Keine technologischen Dinge also.
Da schreibe ich jetzt noch nicht auf welches welches Framework
oder sowas, sondern einzig und allein ja im Prinzip User
Stories. Also ich sage ey, ich möchte
jetzt hier irgendwie eine App bauen, die mir dabei hilft meine
Fotos zu organisieren und in separate Fotoalben wie moved,
ich möchte in der Lage sein mehrere Fotos in dem gleichen
Fotoalbum zu haben oder auch ein Foto in mehreren Fotoalben zu
haben, die sollen gruppiert werden können, die möchte ich
neu organisieren können, indem ich Drag and Drop verwende.
Es soll eine Mainpage und eine Unterpage geben und ich kann so
ein nested Albums machen und für jedes Album möchte ich aber auch
Fotos in so einer Preview dann sehen.
So und so weiter also ich schreibe diesen ganzen Kram
irgendwie auf und was Beckett halt eben macht ist, das nimmt
diese Anforderung und gießt es dann in ein Template in ein
markdown Template, wo im Detail diese Dinge beschrieben werden.
Ja, und zusätzlich zu diesem prompt, der da enthalten ist,
gibt es da auch ein paar Bash beziehungsweise Power Shell
Skripte, die dann im Hintergrund laufen und die dann bestimmte
Dateien erzeugen. Das heißt, das geht nicht alles
nur über das Large Language Model, sondern Teil dieses
Packets sind halt auch einige Skripte, die dann ausgeführt
werden, das heißt man sieht dann auch, wenn man jetzt diesen
specify oder in der anderen Schritte durchläuft, dann fragt
mein Coding Agent auch, möchtest du folgendes Shell Skript
ausführen und dieses Shell Skript erzeugt dann bestimmte
Informationen die dann weiter. Weiter verwendet werden können.
Und wenn ich jetzt wie gesagt dieses Mark Down file habe, dann
kann ich das natürlich jetzt einfach so hinnehmen oder ich
kann natürlich auch einen manuellen Schritt noch mal
einführen und einfach mal drüber lesen und sagen, macht das alles
für mich Sinn, das heißt ich kann jetzt auch tatsächlich dort
hingehen und diese Datei lesen, weil das ist ja halt nicht nur
maschinenlesbar, sondern auch von Menschen lesbar, das heißt,
ich habe eine Mark down Datei, die kann ich mir dann auch im
Preview Modus anschauen und. Und bekommen die auch schön
formatiert. Geh dann da durch und mach dann
noch mal eine Validierung, ob das was das Large Language Model
der Wahl, der Coding Agent der Wahl dann aus meinem prompt
gemacht hat, auch das ist was ich mache und dann kann ich
natürlich in den nächsten Schritt springen.
Ja, und der ist dann dieser Quizmodus, also der ist dann
Specy heißt er clarify oder Clarify.
Dahinter liegt dann wieder ein prompt, der sagt EY das.
Guck dir das an, diese Spezifikation, die jetzt erst
mal durch KI erstellt wurde und dann, wie malte gerade gesagt
hat, vielleicht durch einen Menschen noch mal verfeinert
wurde, finde ich finde ich eigentlich einen sehr wichtigen
Punkt. Also ich sage nur, weil das von
KI jetzt erst mal generiert und dieses Template ausgefüllt
wurde, heißt es ja nicht, dass sich das auch nur noch mit KI
verändern kann, sondern das auch selber natürlich noch mal
reviewen kann und. Und dann gehen wir eben in diese
clarify Phase, weil diese Templates, die beinhalten, auch
schon so eine Review und Akzeptanz.
Checkliste zum Challengen von den Specs, die ich da reingebaut
habe, gemeinsam mit dem KI Agenten, das heißt dieser
hinterlegte prompt hinter diesem clarify Kommando, der geht
eigentlich hin, guckt sich diese Checkliste an und ja Challenge
dann das Dokument was wir da gebaut haben anhand dieser
Checkliste und stellt mir fragen ob er Dinge richtig richtig
verstanden hat oder ob das wirklich so oder.
Oder wenn er Unklarheiten entdeckt hat, lässt er mich das
nochmal verfeinern. Das ist eigentlich ein sehr,
sehr, sehr wichtiger Schritt, dass ich dann hingehe und gucke,
okay sind wir hier alle, eigentlich haben wir alle hier
eigentlich die gleiche Wahrnehmung davon, von dem, was
gebaut werden soll. Ja, und hier sind wir
tatsächlich immer noch komplett auf der Requirement Seite auf
der Product owner Seite. Wir haben noch keine
technologischen Entscheidungen getroffen, sondern wir haben nur
darüber gesprochen. Was wir erreichen wollen und
nicht wie wir es erreichen wollen, das kommt dann erst im
nächsten Schritt. Den sogenannten Plan Step im
Spec Kit, wo ich dann tatsächlich das Ganze in einen
technischen Plan gehe, wo ich dann zum Beispiel meinen Text
Stack. Festlege, wo ich bestimmte
technologische Entscheidungen treffe.
Auch dort ist das ganze Iterativ, das heißt, ich bekomme
dort auch Feedback, teilweise Rückfragen zu bestimmten Dingen,
die vielleicht noch nicht klar sind oder wo das Large Language
Model. Tatsächlich, eine bestimmte
Hypothese hat, und dann kann ich das nochmal entsprechend
validieren und festlegen, damit wir nachher nicht nur unsere
Spezifikation haben, sondern auch einen technischen Plan, wie
wir das Ganze umsetzen wollen. Und da können wir natürlich auch
Hinweise geben, wo man vielleicht firmeninterne
technische Dokumentationen zum gewünschten Tool Stack hat, das
heißt, man muss das nicht immer alles manuell machen, sondern
man kann da natürlich auch auf Third Party.
Informationen verweisen. Man kann dort auch einen MCP
Server einbinden, der dann vielleicht einen Zugang zu dem
eigenen Dokumentationssystem, vielleicht zu einem Konfluence
bietet, wo alle Informationen zu meinem Text Hack
niedergeschrieben sind. Das heißt, ich kann dann
natürlich auch die Integration in meine üblichen Prozesse
nutzen, um hier am Ende dieses Dokument zu bekommen.
Und der Outcome davon kann ja durchaus auch sein, was jetzt
wieder jemand anders. Also ein anderer menschlicher
Developer Reviewt während ich in dieser Spezifikationsphase
vielleicht sehr eng den Product Owner mit Einbinde, würde ich
jetzt bei dem, was bei der Plan Phase rauskommt, sehr eng einen
technischen User, eventuell sogar einen Software Developer
mit einbinden und sagen Schau schau dir mal an ob das für dich
alles aus einer technischen Perspektive sinnvoll ist und
Sinn ergibt was da geschrieben wurde.
Wenn du jetzt zum Beispiel spezifizierst, dass du gerne
vanilla, html CS und Java Script haben möchtest und keine.
Keine. Keine Frontend Frameworks nutzt
oder was auch immer und dann aber irgendwie vielleicht später
irgendwas von von irgendwelchen React Hooks oder so was
schreibt, dann ist das ja vielleicht eine Inkonsistenz,
die entweder menschlicher Developer oder natürlich auch
wenn ich es Challenger mit der KI wieder die KI finden kann,
nach der Planphase geht es dann jetzt in konkrete Tasks, also
das ist die Task Phase, da geht der Agenda wirklich hin und
nimmt diese Spezifikationen. Aus dem Vorvorherigen Schritt
nimmt den Plan aus dem vorherigen Schritt und bricht
die Rinta in wirklich ganz kleine atomare Work Items.
Also richtig, wieso eine to do Liste und das haben viele von
diesen Coding Tasks jetzt auch schon angefangen, wirklich im UI
oder in in der Art und Weise wie diese Coding Agenten.
Genau, die Agenten haben das eingebaut, nicht die Task.
Diese Taskliste haben viele Agenten auch schon mittlerweile
eingebaut, die wird dann wirklich Schritt für Schritt
auch in dieser Reihenfolge abgearbeitet, also das sind dann
wirklich ganz konkrete Arbeitsanweisungen, die dann aus
dem Plan und der Spezifikation abgeleitet werden.
Ich meine, wir kennen das wahrscheinlich alle aus diesen
agilen Softwareentwicklungsvorgehensmodellen,
wo wir dann vielleicht eine user Story implementieren und dann
das Erste, was wir als Developer machen, ist natürlich, uns
Gedanken darüber machen, wie wir es basierend auf dem Text Deck,
den wir haben, in einzelne Aufgaben runterbrechen, die wir
uns in unserem Planning und Tracking Tool der Wahl irgendwie
aufschreiben, damit wir auch nach und nach.
Strukturiert an diesen Dingen arbeiten können und genau das
übertragen wir jetzt in diese KI gestützte Welt, wo die Coding
Agenten natürlich auch mit diesen Aufgaben arbeiten und im
nächsten Schritt geht es dann natürlich in die
Implementierung. Dort ist auch jetzt in Speccit
ein Shortcut vorgesehen und dieser Shortcut triggert dann
entsprechend den Coding Agent, um mit der Implementierung zu
beginnen und man kann dort natürlich auch konkret mitgeben,
welche der Aufgaben in. Implementiert werden sollen in
der Regel ist das so, dass meine Spezifikationen und meine
Aufgaben dann vielleicht auch in unterschiedliche Phasen
gruppiert sind. Das bringt das Tooling an der
Stelle schon mit, dass ich zum Beispiel eine MVP Phase habe und
dann eine weitere Iteration und dann kann ich natürlich die
Tasks in Blöcken abarbeiten, zum Beispiel sage ich dann, bitte
bearbeite erstmal nur die Tasks, die Halt für den MVP notwendig
sind und dann geht der Coding Agent entsprechend hin über.
Übernimmt das Ganze unter Berücksichtigung natürlich des
Plans, der Constitution etc. Und am Ende kommt wie
üblicherweise, wenn ich mit so einem Coding Agenten arbeite,
dann eine kleinere oder größere Menge von neuen Dateien raus.
Neuen Codezeilen, die wir natürlich entsprechend
validieren und freigeben können. Was dieses Weggibt jetzt noch
ganz cool macht, das finde ich, dass es auch.
Auch ganz klar Anweisungen hat und auch Skripte dafür
hinterlegt. Hat das wirklich so ein bisschen
Get Native zu machen? Also die Tasks werden dann
wirklich auch in Comics abgearbeitet, sodass ich
theoretisch so ja so Checkpoints habe, denen ich wieder
zurückgehen kann, wo ich sage, ja die ersten 3 Tasks waren ja
okay, aber was du danach gemacht hast, da bist du völlig falsch
abgebogen, ich muss das glaube ich noch mal neu spezifizieren
und das alles, also das ist auch unter anderem jetzt der Grund
wo. Warum das, was wir jetzt mit
Speckkit einmal exemplarisch hier beschrieben haben, besser
ist als das bestehende Vibe Coding?
Weil das ist genau das, was ich gesagt habe.
Ich kann an einer bestimmten Stelle irgendwas ändern, es ist
reproduzierbar, wir kriegen ein kontrollierbares Ergebnis und wo
er sich dann auch wieder drüber iterieren kann, ich kann
manuelle Änderungen an den Specs machen und die dann einfach noch
mal neu implementieren lassen. Ich kann neue Features bauen,
die sich an alten Specs orientieren, weil ich glaube,
dieses Umdenken, dieser Shift, den wir jetzt machen müssen,
ist, dass das Reine Erstellen von Code wahnsinnig schnell und
wahnsinnig günstig passiert. Also ich kann einfach sagen, ah
nee, da habe ich, glaube ich, da war die Spezifikation noch
nicht, noch nicht eindeutig, ich schmeiß den Code weg und lass
den innerhalb von einer halben Stunde komplett noch mal neu
bauen. Das, was früher viele Tage
gedauert hätte, also ich glaube, das ist genau dieser Shift, dass
das. Erstellen von wahrscheinlich
mittelmäßig gutem Code sehr, sehr schnell und ungünstig
geworden ist in unserer Industrie und wir können den
besser machen, indem wir uns hinsetzen und die Zeit
investieren, darin ganz klare Anweisungen zu haben.
Also wir haben einen ultraschnellen Ultra fleißigen,
aber vielleicht nicht ganz so erfahrenen Mega Junior
Developer, der aber irre schnell coden kann und je besser wir den
anleiten, desto besser sind die Ergebnisse und.
Gerade wenn die, wenn diese Anleitung einfach immer wieder
von vorne von oben nach unten abgearbeitet wird, macht es uns
halt einfacher konsistente Software zu bauen.
Und vor allem habe ich weniger von diesen klassischen, ja
diesen vipe Coding Überraschungen, sondern.
Ich habe dann irgendwie Code, den der nachvollziehbar
entstanden ist und den ich auch wirklich auch über längere Zeit
hinweg in professionellen Umgebungen shippen kann und
drüber hinaus adressiert dieses ganze Spectrum Development jetzt
auch noch so ein paar Limitationen, die wir halt
haben, wenn das Kontextwindow irgendwie voll ist, dann muss
das meistens von einem Karrierenten zusammengefasst
werden. Ich habe aber bestimmte Dinge ja
in der Datei ausgelagert, so ein bisschen das Memory des Agenten
habe ich ja ausgelagert in die Dateien, die kann sich jederzeit
immer wieder reingucken und das ist auch, warum der ganze Spaß
funktioniert, weil all diese Szene.
Specs, die wir da schreiben, werdet ihr sehen, wenn ihr es
weg gibt oder irgendwas mal aussplitter.
Da kommen mehrere marktdown Dateien raus, die teilweise über
Hunderte von Zeilen haben, vielleicht hunderte, aber ne
irgendwie. Auf jeden Fall locker über 100
Zeilen haben und die werden dann zum Kontext.
Die werden mit Reingegeben und warum Kontext so wichtig ist.
Ich sage immer Kontext is king wenn ich über ki sowas mit
Leuten spreche, da haben wir in Folge 121 in der Folge Kontext
engineering ja schon mal schon mal im Detail drüber gesprochen
und der Ansatz ist eben da erfolgreich, wo wir wo wir
vorher gescheitert sind, indem wir halt KI so ein paar Zeilen
prompt mitgegeben haben und dann irgendwie neu iterieren mussten,
wenn irgendwelche. Änderungen da waren und die dann
auch wieder vielleicht überraschend waren oder nicht
mehr zu vorherigen Produkt gepasst haben und dass wir quasi
die KI immer wieder durch den gleichen Flow schicken können
sich diese ganzen Sachen im Kontext erst durchzulesen und
dann was zu implementieren, das hilft halt eben der KI
vernünftige Annahmen zu treffen, die wir ja schon mal validiert
haben und dann so zu implementieren, wie wir das auch
erwarten würden. Und eine Sache, die jetzt
tatsächlich in unserer Abhandlung von Specit und
Spectrip Development noch nicht vorkam.
Was wir vorhin im Kontext des v Modells schon erwähnt haben, ist
diese Validierung und. Und da hatte Spackit zunächst
diesen Test Driven Development Ansatz.
Das heißt, wenn ich speckit in einer der früheren Versionen
verwendet habe, dann wurde ich quasi gezwungen, immer zunächst
Tests zu definieren und Tests zu schreiben, bevor erst die
Funktionalitäten tatsächlich implementiert werden.
Das hat sich für viele User ein bisschen zu.
Strikt angefühlt, weil in vielen Fällen wollen wir das nicht,
oder wir machen gar kein Test driven development.
Das war an der Stelle ein bisschen zu Opiniated, das
heißt, sie sind da jetzt ein bisschen von weggegangen, aber
ich kann natürlich immer noch manuell.
Die Informationen reingeben, dass ich für jeden
entsprechenden Implementierungs step zunächst die Test Cases
definiere und hier weiterhin mit Test Driven Development arbeite,
weil du hast gerade gesagt, es ist vielleicht ein super
fleißiger, super schneller Junior Developer, aber
dementsprechend müssen wir vielleicht die Ergebnisse auch
noch mal validieren und nicht nur gegen die Spezifikation,
also quasi. Den User Acceptance Test,
sondern tatsächlich auch die technische Implementierung muss
validiert werden. Das kann ich natürlich in so
einem Spec Driven Development Ansatz absolut mit aufnehmen,
wir hatten es gerade nicht erwähnt, weil das jetzt nicht
die Default Einstellungen in diesem Tool gerade sind, aber
natürlich kann ich das auch weiterhin genauso machen, wenn
das mein Entwicklungsansatz ist und ich üblicherweise auch Test
driven development mache. Ja, zusammenfassend lässt sich
sagen. Vipe Coating ist so ein bisschen
mehr der agile Weg, wo ich sage, oh, ich mag irgendwas nicht, was
da rausgekommen ist. Dann poppe ich dazu einfach noch
mal neu. Ich habe viele Unterbrechungen
und wenn ich schon coden kann ehrlich gesagt auch nicht so
einen riesigen Produktivitätsgewinn.
Ja, ich tippe irgendwie schneller ab, ich komme relativ
schnell dann irgendwie an den Punkt, wo ich selber dann noch
mal irgendwie mir dann doch Gedanken machen muss, weil
irgendwas nicht funktioniert, das ist so Vipe Coating ist für
mich spannend für jemanden. Der oder die noch gar nicht
programmieren kann, aber für richtige Hardcore Developer kein
echter Produktivitätsgewinn. Aber das ist genau für mich dann
der Vorteil. Der große Vorteil bei so Spec
Driven Development, dass ich eben weniger Unterbrechungen
habe und weniger Unterbrechungen von meinem KI Agenten erwarte
und der somit länger und autonomer im Hintergrund laufen
kann und das teilweise ja auch parallel und ich in der Zeit was
anderes machen kann. Und ja ich kann 10 von diesen
Dingern parallel laufen lassen und das ist dann die.
Der richtige und richtige Produktivitätsgewinn für mich.
Und der bekommt da eben dadurch zustande, dass ich mich vorher
einmal hinsetze und versuche, alle eventuellen Fragen vorab zu
beantworten. Das ganze in technische, aber
auch nicht technische Spezifikationen gieße, die dann
eventuell auch gemeinsam mit einem Agenten erarbeitet und
gechallenged wird und Teil von meinem Kontext wird, also sehr
viel mehr Fokus auf einen richtig richtig, richtig guten
prompt. Da muss ich gar nicht genau
wissen, wie ich den schreibe, weil da kriege ich eben Hilfe
durch diese ganzen Tools wie unter anderem Spec Kit für und
dann eben diese Autonomität habe.
Das ist für mich so zusammenfassend eigentlich der
große große Benefit von Spec driven Development und ich bin
ganz überzeugt, dass wir davon noch mehr sehen werden.
Ja, und ich habe ein ganz interessantes Zitat gelesen.
Die Sprachmodelle sind super darin, Code zu schreiben, aber
nicht so super darin Gedanken zu lesen.
Und von daher ist es, glaube ich, super wichtig, dass man
seine Gedanken, seine Intentionen niederschreibt.
Und Spectrive Development ist quasi der Ansatz dafür, seine
Gedanken und Intentionen in einer strukturierten Art und
Weise so niederzuschreiben, dass KI Agenten sie aufnehmen und
umsetzen können. Das heißt, wir als Developer
oder Product Owner definieren und dokumentieren unsere
Absichten. Das heißt, wir gehen vielleicht
tatsächlich perspektivisch ein bisschen von der Implementierung
weg als Developer hinzu, dieser Spezifizierungsphase und
investieren dann mehr Zeit am Anfang des
Softwareentwicklungsprozesses, schreiben diese Dokumentation
und Tests und Code entstehen dann aus dieser Spezifikation
und die entsprechenden Tools bieten.
Bieten mir teilweise schon Bild in Methoden.
Du hattest es gerade erwähnt, dass es jetzt zum Beispiel bei
Cloud Code schon so einen Plan Mode gibt oder in ad ovds kero,
aber wenn ich das vielleicht in so einem ganzheitlichen Ansatz.
Nutzen möchte oder über verschiedene Tools hinweg, gibt
es natürlich Open Source Projekte wie Speck it.
Was wir vorhin erwähnt haben. Was mich durch diesen Prozess
leitet und am Ende ist vielleicht Speck it für mich
nicht das richtige, aber dann habe ich trotzdem so diesen
Prozess einmal kennengelernt und kann den natürlich dann auch mit
eigenen Prompts entsprechend nach meinen Wünschen umsetzen.
Ja, mir kam auch so ein abschließender Gedanke und ich
bin glaube ich selber auch noch nicht so ganz happy dadurch,
dass das alles so Massen am Markt Down Files in meinem
Projekt ist. Denn ich finde, eigentlich
sollten meine JIRA Tickets oder github issues schon eigentlich
90% von meiner Spezifikation ausmachen und da finde ich
gehört das eigentlich rein und die müssen vielleicht einfach
besser werden, weil das ist auch so der normale Flow und dann
hätte ich eigentlich gerne diese Review Phase mit meinem Agenten,
die finde ich, die ist eigentlich mein Lieblingsteil
aus diesem ganzen Specdriven Development und.
Und ich möchte eigentlich diese Review Phase mit meinem Agenten
haben und über diese JIRA Tickets oder github issues oder
was auch immer man verwendet drüber gehen.
Also ich will irgendwie vielleicht mit einem MCP Server
dann das Ganze verknüpfen und überprüfen ob meine
Anforderungen im JIRA Ticket alle Details beinhalten die ich
benötige als Mensch oder auch der KI benötigt um das alles
ordentlich umzusetzen. Also eigentlich finde ich
sollten diese Kids jetzt in der nächsten Iteration dahin gehen.
Sich diese Informationen aus meiner Konfluence Dokumentation
plus dem jeweiligen Ticket und so was rauszuziehen, dann zu
challengen hey, kann ich das sogar schon übernehmen als KI?
Ansonsten würde mir das und das und das noch fehlen und dann
kannst du das auch an mich übergeben und ich glaube das
werde ich mir jetzt irgendwie mal angucken, dass ich mir
irgendwie einen workform Hintergrund schreibe oder sowas
der. Unsere giva Tickets oder was
auch immer man dafür als Work Item Management verwendet, die
eigentlich challengen gucken, ob die nicht eigentlich die
Ursprungsquelle für meine, für mein Spec Driven Development in
der Zukunft sind. Ja, tatsächlich löst Spec Driven
Development viele der Probleme, die wir ohne Vipe Coding nicht
hätten. Und ich glaube, gerade in der
professionellen Softwareentwicklung haben wir
diese Probleme des Vipe Codings aktuell noch nicht.
Du sagst halt, Anforderungen werden.
Tatsächlich, dokumentiert sie, werden in JIRA Tickets oder
github issues oder wer weiß wo abgelegt.
Ja, wer nicht in dem Detail, gerade in dem das Spectrive
Development macht, über mehrere Seiten hinweg genau beschrieben,
was ich da eigentlich haben will, mit allen offenen Fragen
geklärt. Ja, wobei wenn du tatsächlich
dann dir so Requirements aus solchen klassischen v Modell
getriebenen Entwicklungsprozessen anschaust,
dann anschaust, dann sind wir in so einem Detaillierungsgrad und
ich glaube da kommen dann verschiedene Sachen zusammen und
ich glaube jetzt nicht, für jeden wird sowas wie Speckhit
die eigenen Probleme lösen. Du sagst gerade du wirst dir
deinen eigenen Workflow bauen, aber ich glaube wir können ganz
viel Inspiration und Ideen rausnehmen, die uns dann
natürlich in so einer neuen. Welt der Softwareentwicklung mit
KI Agenten helfen also ich habe extrem viel gelernt, als ich
mich mit dem Thema beschäftigt habe und auch gerade dieser
historische Abriss, die Einordnung hat mir da geholfen,
das Ganze so ein bisschen in Kontext zu setzen.
Ich hoffe, das war für euch genauso interessant wie für uns.
Falls ja, lasst uns gerne auch für diese Podcast folgen und
allgemein für den Podcast eine positive Bewertung da.
Das könnt ihr auf Apple Podcast oder Spotify machen auf youtube
freuen wir uns auch immer auf einen Daumen oder ein Abo.
Und natürlich freuen wir uns auch, wenn ihr Lust habt, uns
einen Kaffee auszugeben. Den wandeln wir dann direkt in
Code oder Podcast folgen um. Dazu findet ihr einen Link auch
unten in den Shownotes bei mir Coffee und.
Und ansonsten freuen wir uns am allermeisten, wenn ihr uns
nächste Woche wieder zuhört. Der to do Cast Developer Podcast
erscheint nämlich jeden Montag ganz frisch in dem Podcast
Player eurer Wahl, von daher habt eine gute Woche wir uns
nächste Woche wieder schreibt viel Coach und guckt, dass ihr
den vielleicht vorher mit Spec Kid irgendwie wie die
Anforderungen gut spezifiziert und habt eine gute Zeit bis
nächste Woche ciao. Bis dann.