NBA75: Verändert Vibe Coding agiles Arbeiten?

Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Jede Woche spreche ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge habe ich ein bisschen was zu Value-Based Pricing erzählt, also eine andere Art der Preisgestaltung, wenn man für Kunden Projekte macht. Wenn dich das interessiert, hör da gerne rein. Den Link, wie alle Links, die ich hier erwähne, findest du in den Shownotes. Heute in Folge 75 möchte ich ganz gerne über Vibe-Coding sprechen und die Auswirkungen auf agiles Arbeiten. Vibe-Coding ist ein großes Ding mittlerweile, das muss man ganz klar sagen. Und was bedeutet das und wie verhält sich das, wenn man das jetzt noch mal skaliert, auf unsere Arbeitsmethoden, die sich über 20 Jahre im Prinzip bewährt haben.

Okay, vielleicht zur Einführung. Was ist überhaupt jetzt wirklich Vibe-Coding? Den Begriff gibt es noch nicht lange. Ich glaube, der ist Anfang 25 entstanden und der ist deswegen entstanden, weil es mittlerweile genug Tools gibt, in denen ich im Prinzip eine oder mehrere Features beschreibe. Klar, gehört ein bisschen Skill dazu, diese Features gut genug für eine AI zu beschreiben. Und die AI ist dann in der Lage, mehr oder weniger unbeaufsichtigt, so ein Feature komplett zu entwickeln. Für diejenigen, die das noch nicht gesehen oder erlebt haben, ihr müsst euch das so vorstellen, dass ihr eine Story habt oder mehrere Storys, die ein ganzes Feature ausmachen, und ihr beschreibt das in einem Prompt. Wie gesagt, man muss schon ein bisschen Ahnung davon haben, wie schreibe ich so einen Prompt, und drückt Enter und dann läuft die Maschine los und entwickelt den Code. Diese Agenten, diese Umgebungen sind mittlerweile so gut, dass sie sich selber auch To-Do-Listen schreiben, sie selber im Prinzip so ein großes Feature in kleine Aufgaben zerteilen und dann, ja, 20 Minuten, 30 Minuten, teilweise auch deutlich länger – komme ich nachher auch noch drauf – vor sich hin arbeiten, bis sie denn der Meinung sind, sie sind fertig, und dann habe ich ein fertig entwickeltes Feature. Zumindest ist das das Versprechen.

Ich selber habe mich da ja auch immer und immer wieder und teilweise auch intensiv mit beschäftigt. Ich nutze das tatsächlich auch, um mir kleinere Tools zu schreiben. Ich habe mir letztens zwei Bookmarklets geschrieben, weil ich aus Microsoft DevOps Tasts und Task-Informationen in unser Jira übernehmen muss und ich da bestimmte Dinge hin und her kopieren muss und dann immer zwischen zwei Browsern wechseln, copy, woanders einfügen, paste und so weiter und so fort. Ich kann nicht programmieren, aber es war ziemlich easy. 15 Minuten hatte ich zwei Bookmarklets. Das ist dann ja im Prinzip JavaScript, fertig. Das eine Bookmarklet, was die Information aus Microsoft DevOps aus einem Task rauskopiert und ein anderes Bookmarklet, das dann die Information an die richtigen Stellen in einen neuen Jira-Task einfügt. Ein zweites Ding, was ich gemacht habe, ist das Agile Echo, das Umfragetool, was ich für No-Bullshit-Agile geschrieben habe. Ein drittes Tool wäre die A-Z-Liste, die ich da mitgeschrieben habe. Also, ich will sagen, ich benutze das, komme ich nachher auch noch mal drauf und ja, ich kenne das ganz gut. Bin bestimmt jetzt nicht der allergeilste Prompter, aber verfolge das zumindest intensiv.

Also, ich habe ein Feature und ich habe jetzt ein Tool, so würde ich es jetzt einfach mal nennen, AI-Coding-Tool. Cursor ist sicherlich so eine Sache. Clode ist sicherlich die bessere Sache mittlerweile. Da hacke ich jetzt einen Prompt rein und kann dann im Prinzip weggehen vom Rechner und nach einer halben Stunde wiederkommen und dann ist das Feature fertig. Das klingt natürlich erstmal verlockend und wir sind sicherlich insgesamt einfach komplett am Anfang der Entwicklung. Ich kann mir gut vorstellen, dass das Tooling drumherum deutlich komfortabler werden kann und auch noch mehr können wird. Es ist die Frage, was das später alles mal wirklich kostet. Also, heute ist es ja so, man kann sich so eine Flatrate holen für 100 oder für 200 Euro und hat unbeliebig viele, auch wieder Gänsefüßchen, Token zur Verfügung, die man dann benutzen kann. Ich könnte mir gut vorstellen, dass auch die Unternehmen, die solche Dienste anbieten, Stück für Stück so die Preisschraube höher drehen. Aber es ist natürlich was anderes, als ein Dev zu beschäftigen oder ein ganzes Team.

Und jetzt gibt es tatsächlich ein paar Leute, die sagen, naja, eigentlich ist das doch the way to go und das ist doch im Prinzip sogar ein Geschäftsmodell. Ich brauche ein Dev-Team nicht mehr, sondern ich beschreibe, was ein Kunde sich wünscht. Ich lasse mein Vibe-Coding laufen, auch im Zweifelsfall mehrere, wenn man an mehreren Features arbeitet. Warum nicht? Und ich bin derjenige, der jetzt der Operator für die Vibe-Coding-Maschinen ist und die liefern dann eben das, was der Kunde möchtet. Und das wäre jetzt tatsächlich auch schon der erste Einhaker. Also das mag sein, dass die Technik dahinter jetzt im nächsten halben Jahr oder so, wenn man sich die Geschwindigkeit dessen anguckt, wie gut die werden, dass das einfach an einen sehr, sehr guten Punkt kommt. Das kann ich mir vorstellen. Ich bin noch nicht ganz überzeugt davon, aber ich kann es mir vorstellen. Aber da ist ein ganz, ganz anderes Problem drin. Natürlich ist da auch eine gewisse menschliche Komponente drin. Also schafft sich die Branche der Devs selber ab? Das würde ich jetzt erstmal ausklammern. Heute hier in der Folge im Fokus soll es jetzt darum gehen, was heißt das denn für agiles Arbeiten?

Und dazu will ich ganz gerne erstmal reinhüpfen und noch mal eine kurze Wiederholung machen. Ihr kennt das alle, trotzdem wiederhole ich es gerne. Was bedeutet agiles Arbeiten und warum machen wir das seit über 20 Jahren? Also wenn wir in einem Umfeld sind, wo wir zwar wissen, was wir erreichen wollen, aber nicht wie wir das erreichen, dann hat sich agiles Arbeiten bewährt. Wir wissen, wir wollen eine gewisse Funktionalität haben und wir können auch ungefähr beschreiben, was der Business Case ist und was wir da mit einem Projekt, sage ich mal, erreichen wollen. Wir wissen aber nicht, wie wir das erreichen, weil das für uns Neuland ist. Und in dieser Welt hat es sich bewährt, in kleinen Schritten vorzugehen und Feedback an vielen Stufen, so vielen Stufen wie möglich, einzuholen, damit wir mit dem Feedback unseren Pfad, wie machen wir was, besser und kontrollierter steuern können. Wir wollen kleine Schritte gehen, damit wir immer kontrollieren können, sind wir noch auf dem richtigen Pfad, und richtiger Pfad heißt, wir wollen natürlich effektiv entwickeln.

Was ist der Gegenansatz? Der Gegenansatz ist das klassische Wasserfallmodell. Wir setzen uns hin, wir zermatern uns unseren Kopf und spezifizieren so genau wie möglich, was wir ganz gerne hätten, damit jemand anders uns das so entwickelt. Das ist der Wasserfall, da laufen wir dann durch die Phasen Spezifikation, Konzeption, Design, Umsetzung, Testing, Dokumentation, Lieferung. Und wir haben doch gelernt, dass da zwar hinten was rauskommt, was der Spezifikation entspricht, aber das Problem daran war doch, dass die Spezifikation überhaupt nicht mehr gestimmt hat zu dem, was wir während des Projekts gelernt haben, denn während des Projekts haben wir doch gelernt, wir hatten mal gedacht, wir brauchen das so, aber in Wirklichkeit brauchen wir es so. Das Wie hat sich doch verändert und zu teilen auch das Was, denn diese Erlebnis, wir haben eine erste Version, an der wir intern vielleicht was lernen, eine zweite Version, wo wir schon mal User befragen, das ist doch fundamental. Dieses Postulat, wir setzen uns am Anfang hin, zermatern uns den Kopf und beschreiben ganz genau, was wir wollen, das hat sich doch mehrfach und mehrfach bewiesen, dass das eben so nicht funktioniert. Eine ganz andere Komponente ist ja auch, dass der Markt sich permanent verändert. Und deswegen haben wir damals gesagt, ich sag immer wir, ich war nicht dabei, aber trotzdem fühle ich mich da verbunden, wir müssen einen anderen Weg finden und diesen Weg haben wir agiles Arbeiten genannt.

Und wenn wir uns jetzt mal angucken, wie Vibe-Coding funktioniert, da sitzt jemand oder von mir aus auch mehrere, die zermatern sich den Kopf, was soll da hinten rauskommen, und dann erklären sie dies dem Team, in diesem Fall ist das Team eben eine Maschine, und sagen dann, viel Spaß, wenn ich wiederkomme, ist mein Projekt bitte fertig. Woran erinnert euch das? Also mich erinnert es ganz stark an Wasserpfeil und es erinnert mich auch ganz stark daran, wir sind eine Agentur, die für Kundensoftware entwickelt, wo Kunden mal gestanden haben, das hat sich glücklicherweise auch verändert. Ich kenne das einfach so, dass Kunden oft genug das Gefühl hatten von, ich spezifiziere, was ich möchte, das gebe ich jetzt der Agentur und dann habe ich mit dem Projekt erstmal nichts mehr zu tun, bis die Agentur fertig ist und sagt, ich bin fertig, bitte guck sie an. Und genau so ist Vibe-Coding und ich hatte ja meine Beispiele vorhin genannt und hatte dann gesagt, ja und dann gehe ich eine halbe Stunde vom Laptop weg und wenn ich wiederkomme, dann ist mein Feature fertig. Es gibt genug Leute mittlerweile, denen ich auch tatsächlich auf Mastodon so ein bisschen folge, weil es mich einfach interessiert, bei denen ist es nicht eine halbe Stunde, sondern eine ganze Nacht, wo die Maschine an den Features arbeitet, und das Tooling ist vielleicht noch nicht ganz so weit, aber wie gesagt, ich finde es ist absehbar, dass das Tooling irgendwann auch an so eine Stelle kommt, dass das Tooling auch, ja, eine ganze Nacht durch mehrere Tage selbstständig an mehreren Features arbeitet, ohne dass da jemand, ein Operator oder wie auch immer ihr das nennen wollt, intensiv drauf guckt und intensiv benötigt wird.

Und wenn wir uns jetzt vorstellen, dass wirklich eine Kiste, mehrere Kisten einfach einen Tag oder zwei Tage Features umsetzt und ich dann erst gucke, okay, was hast du jetzt schönes gebastelt? Ist es denn das geworden, was ich spezifiziert habe? Dann wird, wenn alles gut läuft, das auch hinten rausgekommen sein. Was hat denn jetzt gefehlt? Naja, die Feedback-Schleife. Ich gehe wieder mal davon aus, dass das, was ich vorne definiere, das ist, was hinten raus kommen soll. Oder was hinten raus kommt, das ist, was ich wirklich brauche. Und ich habe doch eben gerade erklärt, warum agiles Arbeiten besser funktioniert als Wasserfall. Das ist ja das gleiche Argument. Höchstwahrscheinlich kommt etwas Funktionierendes, was ich spezifiziert habe, hinten raus. Aber die Wahrscheinlichkeit ist auch sehr hoch, dass es nicht das ist, was ich will. Und jetzt könnte man das Argument vorbringen und sagen, na gut, das hat mich ja so gut wie nichts gekostet. Es ging deutlich schneller, als wenn ich da ein Team mit beschäftige. Ist doch egal. Das Learning ist doch immer noch da. Und solche Argumente habe ich auch gesehen. Aber, also ich will jetzt gar nicht zu tief in die versteckten Kosten. Also heute sind die Dienste sehr günstig, weil sie nicht ihre echten Kosten berechnen müssen. Venture Capital, also Umweltkosten, auch ein Riesenthema Stromkosten, Kosten des Betreibens dieses Modells. Wir reden eigentlich über deutlich höhere Kosten, als wir heute bezahlen müssen. Darum geht es mir aber gar nicht. Es geht mir um den fundamentalen Gedanken des Wastes und mir geht es um den fundamentalen Gedanken des iterativen Arbeitens.

Wenn man denn iterativ vorgehen würde, würde man vielleicht noch schneller sein. Man würde deutliche Kosten sparen und damit meine ich nicht die Dollar- oder Euro-Kosten, sondern die anderen Kosten. Und man würde das entwickeln, was man wirklich braucht. Und ich sehe die ganz große Gefahr, dass viele von diesem Beispiel lernen wollen und das falsche lernen. Warum soll ich in den Dialog gehen mit anderen, wenn ich doch alleine oder in einem viel kleineren Kreis das Gleiche – und ich mache gerade Gänsefüßchen in die Luft – entwickeln kann? Da ist noch ein zweiter Punkt drin. Wie oft sitze ich in Workshops oder Meetings mit dem Team oder mit dem Kunden oder mit beiden und wir stellen fest, okay, ja, die Idee hier, die ist im Raum, aber wir alle haben drüber diskutiert und festgestellt, das ist gar nicht das, was wir wirklich wollen, sondern wir wollen was ganz anderes. Wir bringen da unsere Erfahrung ein, die wir durch andere Projekte haben. Wir bringen das ein, dass da fünf Leute intensiv drüber nachdenken. Dies vorwärts, rückwärts in der Kommunikation, aber wer wäre das und hast du daran gedacht, aber man könnte doch, aber eigentlich hat sich doch bewährt das. Das wird auch alles ignoriert in diesem Vibe-Coding-Prozess.

Und wer jetzt denkt, naja, man könnte ja diese Spezifikation im Dialog machen, also könnte ja mit den fünf Leuten spezifizieren und dann der Coding-AI das übergeben, dann fehlt immer noch ein Teil. Ich erlebe es jeden Tag, dass ich mit meinem Team zusammensitze und wir eine eigentlich Ready-for-Development-Story bearbeiten und die ersten Schritte da drin gegangen sind und dann jemand sagt, Moment mal, mir ist da noch was eingefallen. Wie wollen wir das machen und das machen? Und auch das würde bei diesem ganzen Vibe-Coding wegfallen. Das sollte eigentlich der Fokus von dieser Folge sein. Ich habe aber noch so ein paar Side-Quests, weil dieses Thema einfach so groß ist. Ich will da zumindest darauf eingehen, indem ich es ganz kurz erwähne.

Die Code-Qualität, zumindest momentan, von dem, was im Vibe-Coding entsteht, ist schlecht. Selbst mit sehr guten Prompts ist es sehr schwer, einen später wartbaren Code zu erzeugen. Was wirklich gut funktioniert, das muss ich einfach sagen und deswegen nutze ich es ja auch. Es wäre auch dumm, es nicht zu nutzen, kann ich auch sagen, ist, überschaubare Tools zu entwickeln, die im Prinzip ein One-Shot sind. Ich kann auch Änderungen vornehmen, das klappt ganz gut, aber momentan, heutiger Stand der Technik, ein komplettes, komplexes Projekt, so wie ich Projekt verstehe, ist mit Vibe-Coding nicht möglich. Wenn man das in einem Schuss hinkriegt, mag das funktionieren, aber sobald man daran Anpassungen vornehmen muss, hat man ein riesen Problem. Das größte Grund dazu ist, dass die Maschinen nicht in der Lage sind, den kompletten Kontext zu halten. Sprich, die tausende und über tausende Zeilen von Code, die man wissen muss oder im Blick haben muss, wenn man Anpassungen macht, dafür sind die Limits einfach zu klein momentan noch. Wenn dieser Rahmen steigt, deutlich steigt, könnte sich das ändern. Heute ist es aber so, ich erachte es für unmöglich, ein ganzes, komplexes Projekt mit Vibe-Coding zu machen. Es gibt Ansätze dazu, Leute probieren da auch dran rum, aber das wird nicht funktionieren. Und sobald ich keinen wagbaren Code habe, technische Schulden sind für uns immer ein Riesenthema, wird es hinten raus einfach viel zu teuer.

Das zweite ist, dass immer wieder auch momentan so Forschungsergebnisse entstehen, wo sich herausstellt, dass es tatsächlich keine Zeitersparnis ist an vielen Stellen, sondern eher zehn Prozent mehr Zeit braucht. Auch das hat diverse Gründe. Auch das lässt sich sicherlich heilen. Was ich auch immer sage ist, der Einsatz von AI, der wird nicht mehr verschwinden. Das muss man ganz klar sagen. Da kann man jetzt Fan sein oder nicht Fan sein. Das ist ein Fakt, den man akzeptieren muss, genauso wie der Fakt damals, das Internet ist jetzt da, E-Mail ist jetzt da, das www ist jetzt da. Auch da konnte man dafür oder dagegen sein, aber auch das ist nicht mehr weggegangen, offensichtlicherweise. Und das bedeutet, man muss sich intensiv damit beschäftigen und für sich entscheiden, wo kann mir das Tool helfen. Und ich sage, für die dummen Dinge ist AI spitze. Da kann man wirklich, meine Codebeispiele, man kann damit eine Art von Per-Programming machen. Was ich bei uns immer sage, es ist wichtig, AI müssen wir so einsetzen, und das ist unsere Prüfung, sage ich mal, unsere Prüfung, dass wir jederzeit verstehen, was da hinten rauskommt. Wenn man das nicht mehr erklären kann, den Code, die Funktion zum Beispiel, dann ist der Einsatz von AI schlecht gewesen. Wenn man es zum Sparring nutzt, ich habe hier drei Ansätze, fällt dir noch einer ein, fair enough, oder siehst du hier in dem Code einen Fehler, oder siehst du ein Security-Problem, fair enough, weil dann verstehe ich den Code auch. Das, was ich jetzt hier mit Vibe-Coding beschrieben habe, halte ich für eine ganz große Gefahr, muss ich auch klar sagen.

Man kann über das Thema, oder ich zumindest, kann über das Thema ganz viel und ganz lange sprechen, aber bei No-Bullshit-Agile ist es ja so, dass ich versuche, kurze, knappe Folgen zu machen, 15, 20 Minuten, und es mir eben wichtig ist, dich ein bisschen so ins Denken zu bringen, und deswegen versuche ich hier immer, Themen anzureißen und versuche auch immer, Themen, ja, eine Meinung ein bisschen zuzugeben. Ich freue mich darüber, wenn du vielleicht eine andere Meinung bist, ich freue mich darüber, wenn du der gleichen Meinung bist, und ich freue mich natürlich über Feedback. Sprich, wenn du Feedback für mich hast, keine Scheu, du erreichst mich auf verschiedensten Kanälen, du kannst mir zum Beispiel eine Mail schreiben, ich bin viel auf Mastodon, aber auch auf LinkedIn oder BlueSky, alle Kanäle findest du in den Shownotes. Wie gesagt, ich freue mich sehr über jedes Feedback.

Ich habe zum Abschluss noch eine ganz große Bitte: Wenn dir die Folge hier gefallen hat, vielleicht hast du schon mehr gehört und dir gefällt der ganze Podcast, kannst du mir einen ganz großen Gefallen tun, wenn du das mit anderen teilst, mit deinen Kolleginnen und Kollegen und oder auf Social Media. Je mehr Leute hier von dem Podcast erfahren, desto mehr Leute nehmen an der Diskussion teil, das kann ich hier aufnehmen, darüber kann ich neue Folgen machen und ja, das kommt dir schlussendlich ja auch zugute. Ich sag dafür ganz, ganz vielen Dank und ansonsten sage ich wie immer, habt noch eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.