#137 Topic: Spec-Driven-Development

0:00 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.

0:29 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.

1:08 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.

1:49 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.

2:08 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.

2:29 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.

2:51 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.

3:13 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.

3:30 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.

3:56 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.

4:20 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.

4:45 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.

5:14 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.

5:35 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.

6:04 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

6:47 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.

7:12 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.

7:39 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.

8:13 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,

8:49 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.

9:10 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.

9:31 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.

10:03 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.

10:25 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.

11:01 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.

11:24 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.

11:46 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.

12:04 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

12:46 ü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.

13:13 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.

13:40 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.

13:57 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?

14:33 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.

14:57 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.

15:15 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.

15:45 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.

16:05 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.

16:30 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.

16:53 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.

17:20 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

17:56 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.

18:12 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

18:54 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.

19:33 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,

20:06 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.

20:23 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.

20:48 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.

21:18 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.

21:54 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.

22:12 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

22:47 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.

23:20 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,

23:48 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.

24:10 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.

24:27 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.

24:56 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.

25:29 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.

25:47 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.

26:01 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

26:37 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

27:19 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.

28:05 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.

28:34 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.

28:57 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.

29:24 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.

29:43 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.

30:08 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.

30:28 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.

30:56 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.

31:33 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.

31:56 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.

32:27 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

33:02 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

33:33 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.

34:04 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

34:42 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

35:22 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.

35:48 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.

36:14 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.

36:53 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.

37:21 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.

37:48 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

38:32 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.

39:03 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

39:37 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

40:17 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.

40:42 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.

41:01 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ß

41:35 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.

41:53 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

42:29 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.

42:46 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.

43:10 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.

43:28 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

44:07 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.

44:31 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

45:04 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

45:44 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.

46:01 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

46:51 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.

47:11 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

47:54 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.

48:09 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.

48:28 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

49:07 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

49:44 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.

50:12 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.

50:41 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.