NBA75: Verändert Vibe Coding agiles Arbeiten?

00:00:00: Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Jede Woche spreche

00:00:07: ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge habe

00:00:12: ich ein bisschen was zu Value-Based Pricing erzählt, also eine andere Art der Preisgestaltung,

00:00:18: wenn man für Kunden Projekte macht. Wenn dich das interessiert, hör da gerne rein. Den Link,

00:00:23: wie alle Links, die ich hier erwähne, findest du in den Shownotes. Heute in Folge 75 möchte ich

00:00:28: ganz gerne über Weibcoding sprechen und die Auswirkungen auf agiles Arbeiten. Weibcoding

00:00:34: ist ein großes Ding mittlerweile, das muss man ganz klar sagen. Und was bedeutet das und wie

00:00:42: verhält sich das, wenn man das jetzt noch mal skaliert, auf unsere Arbeitsmethoden, die sich

00:00:47: über 20 Jahre im Prinzip bewährt haben. Okay, vielleicht zur Einführung. Was ist überhaupt

00:00:52: jetzt wirklich Weibcoding? Den Begriff gibt es noch nicht lange. Ich glaube, der ist Anfang

00:00:57: 25 entstanden und der ist deswegen entstanden, weil es mittlerweile genug Tools gibt, in denen

00:01:03: ich im Prinzip eine oder mehrere Features beschreibe. Klar, gehört ein bisschen Skill

00:01:09: dazu, diese Features gut genug für eine AI zu beschreiben. Und die AI ist dann in der Lage,

00:01:16: mehr oder weniger unbeaufsichtigt, so ein Feature komplett zu entwickeln. Für diejenigen,

00:01:22: die das noch nicht gesehen oder erlebt haben, ihr müsst euch das so vorstellen,

00:01:26: dass ihr eine Story habt oder mehrere Storys, die ein ganzes Feature ausmachen und ihr beschreibt

00:01:32: das in einem Prompt. Wie gesagt, man muss schon ein bisschen Ahnung davon haben, wie schreibe ich

00:01:36: so einen Prompt und drückt Enter und dann läuft die Maschine los und entwickelt den Code. Diese

00:01:43: Agenten, diese Umgebungen sind mittlerweile so gut, dass sie sich selber auch To-Do-Listen

00:01:49: schreiben, sie selber im Prinzip so ein großes Feature in kleine Aufgaben zerteilen und dann,

00:01:56: ja, 20 Minuten, 30 Minuten, teilweise auch deutlich länger, komme ich nachher auch noch drauf,

00:02:02: vor sich hin arbeiten, bis sie denn der Meinung sind, sie sind fertig und dann habe ich ein

00:02:09: fertig entwickeltes Feature. Zumindest ist das das Versprechen. Ich selber habe mich da ja auch

00:02:16: immer und immer wieder und teilweise auch intensiv mit beschäftigt. Ich nutze das tatsächlich auch,

00:02:21: um mir kleinere Tools zu schreiben. Ich habe mir letztens zwei Bookmarklets geschrieben,

00:02:25: weil ich aus Microsoft DevOps Tasts und Task-Informationen in unser Jira übernehmen

00:02:32: muss und ich da bestimmte Dinge hin und her kopieren muss und dann immer zwischen zwei

00:02:36: Browsern wechseln, copy woanders einfügen, paste und so weiter und so fort. Ich kann nicht

00:02:41: programmieren, aber es war ziemlich easy. 15 Minuten hatte ich zwei Bookmarklets. Das ist

00:02:47: dann ja im Prinzip JavaScript fertig. Das eine Bookmarklet, was die Information aus Microsoft

00:02:53: DevOps aus einem Task rauskopiert und ein anderes Bookmarklet, das dann die Information an die

00:03:00: richtigen Stellen in einen neuen Jira-Task einfügt. Ein zweites Ding, was ich gemacht

00:03:05: habe, ist das Agile Echo, das Umfragetool, was ich für No-Bullshit-Agile geschrieben habe. Ein

00:03:11: drittes Tool wäre die A-Z-Liste, die ich da mitgeschrieben habe. Also, ich will sagen,

00:03:18: ich benutze das, komme ich nachher auch noch mal drauf und ja, ich kenne das ganz gut. Bin

00:03:25: bestimmt jetzt nicht der allergeilste Prompter, aber verfolge das zumindest intensiv. Also,

00:03:33: ich habe ein Feature und ich habe jetzt ein Tool, so würde ich es jetzt einfach mal nennen,

00:03:38: AI-Coding-Tool. Cursor ist sicherlich so eine Sache. Clode ist sicherlich die bessere Sache

00:03:47: mittlerweile. Da hacke ich jetzt einen Prompt rein und kann dann im Prinzip weggehen vom Rechner und

00:03:54: nach einer halben Stunde wiederkommen und dann ist das Feature fertig. Das klingt natürlich

00:04:01: erstmal verlockend und wir sind sicherlich insgesamt einfach komplett am Anfang der

00:04:07: Entwicklung. Ich kann mir gut vorstellen, dass das Tooling drumherum deutlich komfortabler werden

00:04:13: kann und auch noch mehr können wird. Es ist die Frage, was das später alles mal wirklich kostet.

00:04:20: Also, heute ist es ja so, man kann sich so eine Flatrate holen für 100 oder für 200 Euro und hat

00:04:25: unbeliebig viele, auch wieder Gänsefüßchen, Token zur Verfügung, die man dann benutzen kann. Ich

00:04:33: könnte mir gut vorstellen, dass auch die Unternehmen, die solche Dienste anbieten,

00:04:39: Stück für Stück so die Preisschraube höher drehen. Aber es ist natürlich was anderes,

00:04:43: als ein Dev zu beschäftigen oder ein ganzes Team. Und jetzt gibt es tatsächlich ein paar Leute,

00:04:50: die sagen, naja, eigentlich ist das doch the way to go und das ist doch im Prinzip sogar ein

00:04:55: Geschäftsmodell. Ich brauche ein Dev-Team nicht mehr, sondern ich beschreibe, was ein Kunde sich

00:05:01: wünscht. Ich lasse mein Vibe-Coding laufen, auch im Zweifelsfall mehrere, wenn man an mehreren

00:05:08: Features arbeitet. Warum nicht? Und ich bin derjenige, der jetzt der Operator für die

00:05:15: Vibe-Coding-Maschinen ist und die liefern dann eben das, was der Kunde möchtet. Und das wäre

00:05:20: jetzt tatsächlich auch schon der erste Einhaker. Also das mag sein, dass die Technik dahinter jetzt

00:05:28: im nächsten halben Jahr oder so, wenn man sich die Geschwindigkeit dessen anguckt, wie gut die

00:05:34: werden, dass das einfach an einen sehr, sehr guten Punkt kommt. Das kann ich mir vorstellen. Ich bin

00:05:39: noch nicht ganz überzeugt davon, aber ich kann es mir vorstellen. Aber da ist ein ganz, ganz anderes

00:05:44: Problem drin. Natürlich ist da auch eine gewisse menschliche Komponente drin. Also schafft sich die

00:05:51: Branche der Devs selber ab? Das würde ich jetzt erstmal ausklammern. Heute hier in der Folge im

00:05:58: Fokus soll es jetzt darum gehen, was heißt das denn für agiles Arbeiten? Und dazu will ich ganz gerne

00:06:04: erstmal reinhüpfen und noch mal eine kurze Wiederholung machen. Ihr kennt das alle, trotzdem

00:06:10: wiederhole ich es gerne. Was bedeutet agiles Arbeiten und warum machen wir das seit über 20

00:06:17: Jahren? Also wenn wir in einem Umfeld sind, wo wir zwar wissen, was wir erreichen wollen, aber nicht

00:06:27: wie wir das erreichen, dann hat sich agiles Arbeiten bewährt. Wir wissen, wir wollen eine

00:06:35: gewisse Funktionalität haben und wir können auch ungefähr beschreiben, was der Business Case ist

00:06:42: und was wir da mit einem Projekt, sage ich mal, erreichen wollen. Wir wissen aber nicht, wie wir

00:06:50: das erreichen, weil das für uns Neuland ist. Und in dieser Welt hat es sich bewährt, in kleinen

00:06:57: Schritten vorzugehen und Feedback an vielen Stufen, so vielen Stufen wie möglich einzuholen, damit wir

00:07:07: mit dem Feedback unseren Pfad, wie machen wir was, besser und kontrollierter steuern können. Wir wollen

00:07:16: kleine Schritte gehen, damit wir immer kontrollieren können, sind wir noch auf dem richtigen Pfad und

00:07:21: richtiger Pfad heißt, wir wollen natürlich effektiv entwickeln. Was ist der Gegenansatz? Der

00:07:28: Gegenansatz ist das klassische Wasserfallmodell. Wir setzen uns hin, wir zermatern uns unseren Kopf und

00:07:36: spezifizieren so genau wie möglich, was wir ganz gerne hätten, damit jemand anders uns das so

00:07:45: entwickelt. Das ist der Wasserfall, da laufen wir dann durch die Phasen Spezifikation, Konzeption,

00:07:50: Design, Umsetzung, Testing, Dokumentation, Lieferung. Und wir haben doch gelernt, dass da zwar hinten

00:07:59: was rauskommt, was der Spezifikation entspricht, aber das Problem daran war doch, dass die

00:08:07: Spezifikation überhaupt nicht mehr gestimmt hat zu dem, was wir während des Projekts gelernt haben,

00:08:12: denn während des Projekts haben wir doch gelernt, wir hatten mal gedacht, wir brauchen das so, aber

00:08:18: in Wirklichkeit brauchen wir es so. Das Wie hat sich doch verändert und zu teilen auch das Was,

00:08:25: denn diese Erlebnis, wir haben eine erste Version, an der wir intern vielleicht was lernen, eine

00:08:32: zweite Version, wo wir schon mal User befragen, das ist doch fundamental. Dieses Postulat, wir setzen

00:08:39: uns am Anfang hin, zermatern uns den Kopf und beschreiben ganz genau, was wir wollen, das hat

00:08:45: sich doch mehrfach und mehrfach bewiesen, dass das eben so nicht funktioniert. Eine ganz andere

00:08:51: Komponente ist ja auch, dass der Markt sich permanent verändert. Und deswegen haben wir

00:08:57: damals gesagt, ich sag immer wir, ich war nicht dabei, aber trotzdem fühle ich mich da verbunden,

00:09:04: wir müssen einen anderen Weg finden und diesen Weg haben wir agiles Arbeiten genannt. Und wenn

00:09:09: wir uns jetzt mal angucken, wie Weibcoding funktioniert, da sitzt jemand oder von mir aus

00:09:12: auch mehrere, die zermatern sich den Kopf, was soll da hinten rauskommen und dann erklären sie

00:09:19: dies dem Team, in diesem Fall ist das Team eben eine Maschine und sagen dann, viel Spaß, wenn ich

00:09:27: wiederkomme, ist mein Projekt bitte fertig. Woran erinnert euch das? Also mich erinnert es ganz

00:09:33: stark an Wasserpfeil und es erinnert mich auch ganz stark daran, wir sind eine Agentur, die für

00:09:38: Kundensoftware entwickelt, wo Kunden mal gestanden haben, das hat sich glücklicherweise auch verändert.

00:09:45: Ich kenne das einfach so, dass Kunden oft genug das Gefühl hatten von, ich spezifiziere, was ich

00:09:50: möchte, das gebe ich jetzt der Agentur und dann habe ich mit dem Projekt erstmal nichts mehr zu

00:09:55: tun, bis die Agentur fertig ist und sagt, ich bin fertig, bitte guck sie an. Und genau so ist

00:10:01: Weibcoding und ich hatte ja meine Beispiele vorhin genannt und hatte dann gesagt, ja und dann gehe

00:10:08: ich eine halbe Stunde vom Laptop weg und wenn ich wiederkomme, dann ist mein Feature fertig. Es gibt

00:10:13: genug Leute mittlerweile, denen ich auch tatsächlich auf Mastodon so ein bisschen folge, weil es mich

00:10:18: einfach interessiert, bei denen ist es nicht eine halbe Stunde, sondern eine ganze Nacht, wo die

00:10:25: Maschine an den Features arbeitet und das Tooling ist vielleicht noch nicht ganz so weit, aber wie

00:10:31: gesagt, ich finde es ist absehbar, dass das Tooling irgendwann auch an so eine Stelle kommt, dass das

00:10:36: Tooling auch, ja, eine ganze Nacht durch mehrere Tage selbstständig an mehreren Features arbeitet,

00:10:44: ohne dass da jemand, ein Operator oder wie auch immer ihr das nennen wollt, intensiv drauf guckt

00:10:50: und intensiv benötigt wird. Und wenn wir uns jetzt vorstellen, dass wirklich eine Kiste, mehrere

00:10:57: Kisten einfach einen Tag oder zwei Tage Features umsetzt und ich dann erst gucke, okay, was hast

00:11:06: du jetzt schönes gebastelt? Ist es denn das geworden, was ich spezifiziert habe? Dann wird, wenn

00:11:11: alles gut läuft, das auch hinten rausgekommen sein. Was hat denn jetzt gefehlt? Naja, die Feedback

00:11:18: Schleife. Ich gehe wieder mal davon aus, dass das, was ich vorne definiere, das ist, was hinten raus

00:11:23: kommen soll. Oder was hinten raus kommt, das ist, was ich wirklich brauche. Und ich habe doch

00:11:29: eben gerade erklärt, warum agiles Arbeiten besser funktioniert als Wasserfall. Das ist ja das gleiche

00:11:35: Argument. Höchstwahrscheinlich kommt etwas funktionierendes, was ich spezifiziert habe, hinten

00:11:41: raus. Aber die Wahrscheinlichkeit ist auch sehr hoch, dass es nicht das ist, was ich will. Und jetzt

00:11:47: könnte man das Argument vorbringen und sagen, na gut, das hat mich ja so gut wie nichts gekostet.

00:11:54: Es ging deutlich schneller, als wenn ich da ein Team mit beschäftige. Ist doch egal. Das Learning

00:12:00: ist doch immer noch da. Und solche Argumente habe ich auch gesehen. Aber, also ich will jetzt gar

00:12:07: nicht zu tief in die versteckten Kosten. Also heute sind die Dienste sehr günstig, weil sie nicht ihre

00:12:14: echten Kosten berechnen müssen. Venture Capital, also Umweltkosten, auch ein Riesenthema Stromkosten,

00:12:22: Kosten des Betreibens dieses Modells. Wir reden eigentlich über deutlich höhere Kosten, als wir

00:12:28: heute bezahlen müssen. Darum geht es mir aber gar nicht. Es geht mir um den fundamentalen Gedanken

00:12:35: des Wastes und mir geht es um den fundamentalen Gedanken des iterativen Arbeitens. Wenn man

00:12:40: denn iterativ vorgehen würde, würde man vielleicht noch schneller sein. Man würde deutliche Kosten

00:12:47: sparen und damit meine ich nicht die Dollar oder Euro Kosten, sondern die anderen Kosten. Und man

00:12:54: würde das entwickeln, was man wirklich braucht. Und ich sehe die ganz große Gefahr, dass viele von

00:13:02: diesem Beispiel lernen wollen und das falsche lernen. Warum soll ich in den Dialog gehen mit

00:13:09: anderen, wenn ich doch alleine oder in einem viel kleineren Kreis das Gleiche und ich mache gerade

00:13:18: Gänsefüßchen in die Luft entwickeln kann? Da ist noch ein zweiter Punkt drin. Wie oft sitze ich in

00:13:26: Workshops oder Meetings mit dem Team oder mit dem Kunden oder mit beiden und wir stellen fest, okay,

00:13:33: ja, die Idee hier, die ist im Raum, aber wir alle haben drüber diskutiert und festgestellt, das ist

00:13:39: gar nicht das, was wir wirklich wollen, sondern wir wollen was ganz anderes. Wir bringen da unsere

00:13:43: Erfahrung ein, die wir durch andere Projekte haben. Wir bringen das ein, dass da fünf Leute intensiv

00:13:51: drüber nachdenken. Dies vorwärts, rückwärts in der Kommunikation, aber wer wäre das und hast du daran

00:13:57: gedacht, aber man könnte doch, aber eigentlich hat sich doch bewährt das. Das wird auch alles ignoriert

00:14:04: in diesem Weib-Coding-Prozess. Und wer jetzt denkt, naja, man könnte ja diese Spezifikation im

00:14:10: Dialog machen, also könnte ja mit den fünf Leuten spezifizieren und dann der Coding-AI das übergeben,

00:14:16: dann fehlt immer noch ein Teil. Ich erlebe es jeden Tag, dass ich mit meinem Team zusammensitze und

00:14:23: wir eine eigentlich Ready-for-Development-Story bearbeiten und die ersten Schritte da drin gegangen

00:14:29: sind und dann jemand sagt, Moment mal, mir ist da noch was eingefallen. Wie wollen wir das machen und

00:14:34: das machen? Und auch das würde bei diesem ganzen Weib-Coding wegfallen. Das sollte eigentlich der

00:14:40: Fokus von dieser Folge sein. Ich habe aber noch so ein paar Side-Quests, weil dieses Thema einfach so

00:14:46: groß ist. Ich will da zumindest darauf eingehen, indem ich es ganz kurz erwähne. Die Code-Qualität,

00:14:52: zumindest momentan, von dem, was im Weib-Coding entsteht, ist schlecht. Selbst mit sehr guten

00:15:01: Prompts ist es sehr schwer, einen später wartbaren Code zu erzeugen. Was wirklich gut funktioniert,

00:15:08: das muss ich einfach sagen und deswegen nutze ich es ja auch. Es wäre auch dumm, es nicht zu nutzen,

00:15:12: kann ich auch sagen, ist überschaubare Tools zu entwickeln, die im Prinzip ein One-Shot sind. Ich

00:15:19: kann auch Änderungen vornehmen, das klappt ganz gut, aber momentan, heutiger Stand der Technik,

00:15:26: ein komplettes, komplexes Projekt, so wie ich Projekt verstehe, ist mit Weib-Coding nicht

00:15:32: möglich. Wenn man das in einem Schuss hinkriegt, mag das funktionieren, aber sobald man daran

00:15:39: Anpassungen vornehmen muss, hat man ein riesen Problem. Das größte Grund dazu ist, dass die

00:15:45: Maschinen nicht in der Lage sind, den kompletten Kontext zu halten. Sprich, die tausende und über

00:15:51: tausende Zeilen von Code, die man wissen muss oder im Blick haben muss, wenn man Anpassungen macht,

00:15:57: dafür sind die Limits einfach zu klein momentan noch. Wenn dieser Rahmen steigt, deutlich steigt,

00:16:04: könnte sich das ändern. Heute ist es aber so, ich erachte es für unmöglich, ein ganzes,

00:16:10: komplexes Projekt mit Weib-Coding zu machen. Es gibt Ansätze dazu, Leute probieren da auch

00:16:16: dran rum, aber das wird nicht funktionieren. Und sobald ich keinen wagbaren Code habe,

00:16:22: technische Schulden sind für uns immer ein Riesenthema, wird es hinten raus einfach viel

00:16:27: zu teuer. Das zweite ist, dass immer wieder auch momentan so Forschungsergebnisse entstehen,

00:16:34: wo sich herausstellt, dass es tatsächlich keine Zeitersparnis ist an vielen Stellen,

00:16:38: sondern eher zehn Prozent mehr Zeit braucht. Auch das hat diverse Gründe. Auch das lässt

00:16:44: sich sicherlich heilen. Was ich auch immer sage ist, der Einsatz von AI, der wird nicht mehr

00:16:52: verschwinden. Das muss man ganz klar sagen. Da kann man jetzt Fan sein oder nicht Fan sein. Das

00:16:58: ist ein Fakt, den man akzeptieren muss, genauso wie der Fakt damals, das Internet ist jetzt da,

00:17:04: E-Mail ist jetzt da, das www ist jetzt da. Auch da konnte man dafür oder dagegen sein,

00:17:11: aber auch das ist nicht mehr weggegangen, offensichtlicherweise. Und das bedeutet,

00:17:17: man muss sich intensiv damit beschäftigen und für sich entscheiden, wo kann mir das Tool helfen. Und

00:17:23: ich sage, für die dummen Dinge ist AI spitze. Da kann man wirklich, meine Codebeispiele,

00:17:32: man kann damit eine Art von Per-Programming machen. Was ich bei uns immer sage, es ist wichtig,

00:17:38: AI müssen wir so einsetzen, und das ist unsere Prüfung, sage ich mal, unsere Prüfung,

00:17:47: dass wir jederzeit verstehen, was da hinten rauskommt. Wenn man das nicht mehr erklären kann,

00:17:54: den Code, die Funktion zum Beispiel, dann ist der Einsatz von AI schlecht gewesen. Wenn man es zum

00:18:01: Beispiel zum Sparring nutzt, ich habe hier drei Ansätze, fällt dir noch einer ein, fair enough,

00:18:07: oder siehst du hier in dem Code einen Fehler, oder siehst du ein Security-Problem, fair enough,

00:18:13: weil dann verstehe ich den Code auch. Das, was ich jetzt hier mit Weibcoding beschrieben habe,

00:18:18: halte ich für eine ganz große Gefahr, muss ich auch klar sagen. Man kann über das Thema,

00:18:24: oder ich zumindest, kann über das Thema ganz viel und ganz lange sprechen, aber bei

00:18:30: No-Bullshit-Agile ist es ja so, dass ich versuche, kurze, knappe Folgen zu machen, 15, 20 Minuten,

00:18:35: und es mir eben wichtig ist, dich ein bisschen so ins Denken zu bringen, und deswegen versuche

00:18:40: ich hier immer, Themen anzureißen und versuche auch immer, Themen, ja, eine Meinung ein bisschen

00:18:46: zuzugeben. Ich freue mich darüber, wenn du vielleicht eine andere Meinung bist, ich freue

00:18:49: mich darüber, wenn du der gleichen Meinung bist, und ich freue mich natürlich über Feedback.

00:18:53: Sprich, wenn du Feedback für mich hast, keine Scheu, du erreichst mich auf verschiedensten

00:18:59: Kanälen, du kannst mir zum Beispiel eine Mail schreiben, ich bin viel auf Mastodon,

00:19:01: aber auch auf LinkedIn oder BlueSky, alle Kanäle findest du in den Shownotes. Wie gesagt,

00:19:06: ich freue mich sehr über jedes Feedback. Ich habe zum Abschluss noch eine ganz große Bitte,

00:19:12: wenn dir die Folge hier gefallen hat, vielleicht hast du schon mehr gehört und dir gefällt der

00:19:16: ganze Podcast, kannst du mir einen ganz großen Gefallen tun, wenn du das mit anderen teilst,

00:19:21: mit deinen Kolleginnen und Kollegen und oder auf Social Media. Je mehr Leute hier von dem

00:19:26: Podcast erfahren, desto mehr Leute nehmen an der Diskussion teil, das kann ich hier aufnehmen,

00:19:31: darüber kann ich neue Folgen machen und ja, das kommt dir schlussendlich ja auch zugute. Ich sag

00:19:37: dafür ganz, ganz vielen Dank und ansonsten sage ich wie immer, habt noch eine ganz tolle Woche

00:19:41: und bis zur nächsten Folge bei No Bullshit Agile.