NBA86: Warum die Prinzipien des agile Arbeiten bei Vibe Coding Pflicht sind

00:00:00: Hallo und herzlich willkommen bei No-Bullshit-Agile. Mein Name ist Thomas. In der letzten Folge habe

00:00:07: ich über Giles Arbeiten vs. klassischem Projektmanagement gesprochen. Dabei bin ich

00:00:12: ein bisschen auf die Stacy Matrix und das magische Drake eingegangen. Wenn dich das

00:00:17: interessiert, hör da gerne rein. Den Link zu dieser Folge sowie alle weiteren Links,

00:00:21: die ich hier erwähne, findest du natürlich in den Shownotes. Das hier ist Folge 86 und

00:00:26: ich muss tatsächlich dieses Thema KI nochmal aufmachen. In dem Fall hier, in dieser Folge,

00:00:32: soll es vor allen Dingen um Weibcoding gehen. Allerdings will ich das Ganze tatsächlich mit

00:00:38: einem anderen Blickwinkel aufnehmen. Bevor wir da in die Details einsteigen, fange ich tatsächlich

00:00:44: einfach mal mit dem Fazit an, weil ich weiß, dass viele von euch von AI so genervt sind. Hear

00:00:49: me out. Also worum soll es hier gehen? Ich bin weiterhin der festen Überzeugung und das hat sich

00:00:56: jetzt auch nochmal gefestigt. Es gibt zuallererst mal einen ganz großen Unterschied, den man mental

00:01:02: machen muss, zwischen Weibcoding, also ich kann nicht entwickeln und ich möchte mit AI-Tools

00:01:11: trotzdem etwas entwickeln, vs. AI-supported Engineering, also ich kann entwickeln und

00:01:19: nutze AI in meinem täglichen Prozess. Weibcoding und das ist die Geschichte, die ich euch gleich

00:01:25: erzähle, ist meiner Meinung nach überhaupt nichts für Unternehmen. Im Hobby oder so und es mag auch

00:01:31: Grenzfälle geben, da geht das vielleicht, aber ganz grundsätzlich geht es in meinen Augen nicht.

00:01:36: AI-supported Engineering hingegen geht. Das ist ein Tool wie jedes andere, das sage ich ja auch

00:01:42: immer. Da komme ich dann im echten Fazit der Folge auch nochmal drauf und ich denke, das kann so zehn

00:01:48: Prozent Effektivitätsgewinn sicherlich bringen. Gut, wo wir das Fazit haben, würde ich sagen,

00:01:54: können wir die Folge beenden? Nein, natürlich nicht. Was für ein Setting habe ich denn überhaupt?

00:01:59: Fangen wir damit mal an. Also, ich kann nicht entwickeln, ich habe das nie gelernt und wenn ich

00:02:07: entwickeln könnte, würde ich tatsächlich nicht Weibcoding machen. Warum? Komme ich später drauf.

00:02:12: Mein Leben, habe ich mir hier so in meinen Schuhen notiert, wäre deutlich einfacher, wenn ich den

00:02:17: entwickeln könnte. Zumindest für das, was ich davor habe. Weibcoding gibt nämlich die Möglichkeit,

00:02:22: Ideen umzusetzen. Natürlich ist es so, dass man immer mal wieder Ideen hat für ein kleines Tool

00:02:27: oder für irgendwas, für irgendwelche Hobbyprojekte, wo es natürlich gut ist, wenn man entwickeln kann,

00:02:32: um diese Entwicklungshobbyprojekte auch zum Leben zu erwecken. Und das ist ein bisschen meine

00:02:39: Situation. Ich habe da immer mal wieder Ideen und jetzt gerade wieder eine und versuche da

00:02:44: intensiv irgendwie weiterzukommen. Und dann gibt mir Weibcoding die Möglichkeit tatsächlich zu

00:02:51: entwickeln. Und ja, da möchte ich jetzt ganz gerne mal den Vergleich ziehen. Fangen wir mal an

00:02:57: folgender Stelle an. AI, wenn man sie jetzt in diesem Weibcoding-Setting benutzt, ist von den

00:03:04: Fähigkeiten her ein Fachinformatiker Azubi im ersten Jahr. So stelle ich mir das vor und ich

00:03:12: glaube, das ist gar nicht so unrealistisch, sich das so zu überlegen. Und das sollte man wirklich

00:03:18: im Blick haben, wenn man jetzt über Weibcoding spricht. Seitennotiz vielleicht. Ich glaube auch,

00:03:26: mit dieser Methodik, Large Language Model, LLM, geht es auch nicht viel weiter. Die werden nicht

00:03:32: viel besser werden. Es müsste meiner Meinung nach jetzt irgendwas ganz anderes erfunden werden,

00:03:38: um einen großen Schritt weiterzukommen. Ich habe den Eindruck, dass eine große Sättigung erreicht

00:03:43: ist. Wenn ich das jetzt vergleiche, keine Ahnung 2022, 23, wie stark die Kurve gestiegen ist,

00:03:51: wie schnell die besser geworden sind, diese Dinger. Und das jetzt einfach mal mit 25 vergleichen muss

00:03:57: ich feststellen, ja, hier und da gibt es eine Verbesserung. Aber ehrlich gesagt, dass die

00:04:01: Steigung der Kurve, wenn ihr euch das so vorstellen wollt, die ist extrem abgeflacht. Und das bringt

00:04:07: mich eben dazu, dass ich der Meinung bin, viel besser wird es jetzt nicht. Es findet irgendwo

00:04:12: nochmal so eine Revolution in dieser Art statt. Aber gut, das ist jetzt erst mal nur meine Meinung.

00:04:18: Zurück zu diesem Bild. Wir wollen etwas entwickeln und wir tun das jetzt tatsächlich Weibcoding Modus

00:04:25: mit AI. Und wir haben festgestellt, die AI kann jetzt so viel und manchmal kann sie selbst das

00:04:31: nicht, muss man auch sagen, keine Abwertung von Fachinformatiker Azubis, wie ein Azubi im ersten

00:04:37: Ausbildungsjahr. Und jetzt müsst ihr euch Folgendes vorstellen. Ihr habt ein größeres,

00:04:42: komplexeres Projekt vor Augen und ihr macht das jetzt mit einem Fachinformatiker Azubi im ersten

00:04:48: Ausbildungsjahr. Und die Frage hier ist, wie geht ihr vor? Und wenn ihr dieses Bild mal mitnehmt und

00:04:55: euch das mal überlegt und überlegt, wie wäre das wirklich ein größeres, komplexeres Projekt

00:04:59: vom Jahres auch mit mehreren Fachinformatiker Azubis zu machen, dann habt ihr eigentlich schon

00:05:05: das erste gute Gefühl, was das jetzt bedeutet. Das bringt uns dann tatsächlich zu dem Punkt,

00:05:11: dass ich euch mein Team dann mal vorstellen kann. Was nutze ich denn? Und was ich nutze,

00:05:19: ist von Entropiq Cloud Code, Cloud Code CLI in diesem Fall. Das ist so mein Daily Driver. Damit

00:05:26: mache ich alles, was jetzt mit Coding zu tun hat. Dann habe ich im Team noch wen anders,

00:05:32: nämlich Codex, also von oben AI, CLI. Mit dem knacke ich die harten Nüsse. Da gibt es die

00:05:40: Möglichkeit, ich sage mal, ein sehr teures Modell zu wählen. Und wenn ich in der Situation bin,

00:05:45: wo Cloud nicht mehr weiterkommt, nutze ich tatsächlich Codex. Und mein drittes Teammitglied,

00:05:50: ich hoffe, ihr seht immer, dass ich Gänsefüße in die Luft mache, wenn ich Teammitglied sage,

00:05:54: ist Google AI Studio. Das hat den großen Vorteil, AI Studio hat einen sehr großen Kontext. Sprich,

00:06:01: ihr könnt da sehr große Dokumente reinhauen. Das geht bei anderen Modellen eben nicht. Okay,

00:06:07: ich nutze also vor allen Dingen CLI basierte AI Assistenten, Cloud Code vor allen Dingen. Und das

00:06:16: Setting ist jetzt wie folgt. Ich habe so ein großes Projekt, ich habe eine Idee dazu und das

00:06:22: möchte ich jetzt umsetzen. AI grundsätzlich benötigt, ja manchmal wie diese Azubis,

00:06:28: möglichst präzise und spezifische Anweisungen oder Prompts. Und das bedeutet im Umkehrschluss,

00:06:36: wenn ich was Größeres machen will und das präzise formulieren muss, muss ich alles vorplanen. Und

00:06:43: habe dann eine lange Planungsphase, um dann etwas umzusetzen, um dann ins Feedback zu kommen,

00:06:50: um zu schauen, hat das funktioniert. Und einige von euch werden jetzt sagen, ah Moment mal,

00:06:56: das klingt ein bisschen wie Wasserfall. Und genau das ist es auch. Dadurch, dass wir gezwungen sind,

00:07:03: grundsätzlich erstmal mit AI, wenn wir mit AI arbeiten, sehr präzise zu formulieren,

00:07:10: müssen wir lange vorplanen. Wir wissen aber auch, wenn wir lange vorplanen, dass egal wie gut wir

00:07:15: drüber nachdenken, wir diesen Plan nicht so bauen können, dass er in der Lage ist, all das zu

00:07:23: beschreiben, was wir wirklich haben wollen. Denn zum Teil wissen wir noch gar nicht, was wir wirklich

00:07:27: haben wollen. Das ist ja eben der Hack am agilen Arbeiten, dass wir eben in so Feedbackzyklen

00:07:33: kommen wollen und die klein halten wollen. Im agilen Arbeiten gehen wir eigentlich immer in

00:07:38: kleinen Schritten vor. Wir machen kleine Iterationen. Wir haben einen großen Plan, den zerteilen wir in

00:07:44: möglichst viele kleine Pläne. Wir überlegen, was bringt erstmal am meisten Wert oder Erkenntnis.

00:07:49: Dann lassen wir das entwickeln oder wir entwickeln es und es sind kleine Inkremente, die wir da

00:07:55: entwickeln. Und dann schauen wir uns das an und suchen nach Feedback, um den großen Plan und die

00:08:02: nächsten kleinen Pläne anzupassen. Inspect and adopt. Wir wollen schnell in diese kleinen Feedbackzyklen.

00:08:08: Was bedeutet das für Vibecoding? Naja, gehen wir mal in die Praxis. Wie gehe ich denn vor? Möchte

00:08:17: eben nicht in den Wasserfall, was wir in Projekten aber trotzdem immer machen, auch im agilen Arbeiten.

00:08:23: Wir gehen ja immer planvoll vor. Wir erstellen uns erstmal einen Gesamtplan. Dazu gehe ich dann zu

00:08:28: Claude. Und in Claude gibt es die Möglichkeit von so einem Planungsmodus. Dann entwickelt er nicht,

00:08:33: sondern er erstellt eben einen Plan. Und dann gibt es noch so einen Spezialmodus, den man anmachen

00:08:40: kann. Der heißt tatsächlich Ultra-Think. Und ja, dann kommt so ein Reasoning dazu. Und in diesem Modus

00:08:49: erarbeite ich mit meinen Ideen und mit Claude, der weiß, wie man Code schreibt oder auch nicht, eben

00:08:57: einen großen Plan auf einer abstrakteren Ebene. Das geht vor und zurück, vor und zurück, immer weiter

00:09:03: diskutiert, bis so ein Plan dann entsteht. Manchmal nehme ich mir diesen großen Plan und

00:09:11: gebe den dann tatsächlich Google AI Studio und sage hier, guck du auch noch mal drauf. Und dann

00:09:18: entsteht noch zwischen mir und meinen Teamkollegen Claude und AI Studio, ja, ein Dialog auf wieder

00:09:27: Gänsefüßchen. Auf jeden Fall haben wir so einen großen Plan. Daraus lasse ich ein GitHub-Issue

00:09:32: erstellen, damit wir den großen Plan erst mal überhaupt haben. Wichtig ist, ich muss den Plan

00:09:39: verstehen. Nicht die Codezeile, aber der Plan. Entspricht das überhaupt noch meinem Plan? Weil

00:09:47: das kann einem auch super schnell passieren und dann hat man schon wieder verloren. Wenn man sich

00:09:52: einfach so denkt, trololololo wird schon, dann geht es oft in die Hose. Also ihr müsst da einfach

00:09:58: hart mitdenken oder ich muss in meinem Fall da hart mitdenken, immer wieder lesen, immer wieder

00:10:03: überlegen, Moment einmal, ist es überhaupt noch das Richtige? Und dann gehen wir, genau wie am

00:10:09: agilen Arbeiten, in eine Phase 2 des Refinements. Wir haben jetzt diesen großen Plan und wir

00:10:16: zerteilen ihn jetzt in ganz kleine Pläne. Die schöne Methodik an der Stelle, die ich dann

00:10:21: benutze, ist tatsächlich User-Story-Mapping und Dimensional Planning. Habe ich mal eine

00:10:25: Folge drüber gemacht, den Link dazu findest du in den Shownotes. Ich nutze einfach wirklich meine

00:10:29: Erfahrung aus dem agilen Arbeiten und meine Methodiken, damit es überhaupt irgendeine Chance

00:10:35: hat zu funktionieren. Mein Ziel ist es, die wichtigen Dinge zu identifizieren, die ich als

00:10:41: erstes umsetzen will. Und das mache ich eben mit so einer Methodik. Es gibt andere Methodiken,

00:10:47: die ihr verwenden könnt. Und nehme den großen Plan und lasse den dann mit Hilfe von AI in eine

00:10:55: Phase zerlegen, in einem Refinement, in kleine Teile zerlegen. Und daraus mache ich wieder GitHub-Issues.

00:11:02: Wir haben also dann Refined. Jetzt kommen wir in die dritte Phase, die kennen wir auch aus dem agilen

00:11:07: Arbeiten, nämlich die Umsetzung. Wir schnappen uns eins, das Wichtigste hoffentlich, von diesen

00:11:14: kleinen Teilen und zerlegen das in super kleine Teile. Wir machen jetzt Tarsplitting. Wir sitzen

00:11:19: zusammen und überlegen uns, was ist denn alles wirklich zu tun? Das Was haben wir? Und jetzt

00:11:24: geht es darum, das Wie. Das heißt, ich habe dann aus einem ganz großen Plan drei kleinere Elemente

00:11:31: identifiziert und das erste kleinere Element zerteile ich jetzt nochmal in ganz kleine Elemente.

00:11:36: Und in dem Moment kann ich dann sagen, setze den ersten ganz kleinen Teil um. Der ist super

00:11:43: präzise. Da kann ich den Prompt sehr scharf formulieren. Und er ist so klein, dass ich keine

00:11:52: großen Überraschungen erleben werde. Soweit kann ich vorplanen, beziehungsweise wenn ich eine

00:11:57: Überraschung erlebe, kann ich schnell gegensteuern. Und dann kommt die vierte Phase. Auch die kennen

00:12:02: wir aus dem agilen Arbeiten. Wir sind im Feedback. Ich gucke mir das Ergebnis an. Ich vergleiche das

00:12:08: mit dem großen Plan. Ich diskutiere das codemäßig mit den AIs im Zweifelsfall. Auch hier benutze ich

00:12:16: dann wieder AI Studio und sage hier, soweit sind wir. Was denkst du? Gebe das wieder an Claude, um

00:12:24: zu arbeiten. Aber wir sind halt hier im ganz kleinen Inkrement an dieser Stelle. Und ich selber

00:12:29: kontrolliere natürlich auch. Entspricht das Ergebnis meiner Erwartung? Sind wir noch auf dem

00:12:36: richtigen Weg? Und diesen ganzen Input nehme ich dann, um zu entscheiden, wie der nächste Zyklus

00:12:42: startet. Sind wir im großen Plan noch auf dem Weg? Sind wir im kleinen Plan noch auf dem Weg? Oder muss

00:12:47: ich neu planen? Inspect and adopt. Und das ist tatsächlich ein Zyklus, in dem mir meine Erfahrung

00:12:57: im agilen Arbeiten und das grundsätzliche Mindset des agilen Arbeitens hilft, um mit

00:13:05: Web Coding überhaupt klar zu kommen. Ihr seht an dieser Stelle vielleicht, und deswegen habe ich

00:13:10: unter anderem diese Folge halt auch gemacht, wie super anstrengend das ist. Also ich sitze da und

00:13:17: muss mich da permanent darauf konzentrieren und permanent darauf achten, dass diese Maschine

00:13:22: wirklich das Richtige tut. Das ist was ganz anderes, als ob ich mit meinem wirklichen Team

00:13:27: entwickle. Die bringen so viel Erfahrung mit, so viel Wissen mit, so viel Domänwissen, dass das eine

00:13:35: ganz andere Rolle dann auf einmal bei mir ist. Es ist viel, viel einfacher auf dieser Ebene. Und

00:13:40: deswegen bin ich der festen Überzeugung, dass diese Art einfach überhaupt nichts für Unternehmen ist.

00:13:49: Es dauert auch viel zu lange. Also unabhängig davon, dass es super anstrengend ist, dauert es auch viel,

00:13:56: viel länger. Ihr seht ja, dass ich so komplexes Verfahren anwenden muss, immer wieder mich

00:14:02: rückversichern muss, mehrere Tools benutze, um sicherzugehen, dass das, was da entsteht, auch

00:14:08: wirklich, ich sag mal, eine saubere Architektur ist, verlässlich ist. Und wenn ich entwickeln

00:14:13: könnte, deswegen habe ich das am Anfang auch gesagt, würde ich mir den ganzen Quatsch auch

00:14:18: sparen wollen und einfach entwickeln. Weil wenn ich die Idee schon habe und ich in der Lage bin,

00:14:23: mir das zu zerteilen, warum soll ich das noch mit wem anders machen? Und deswegen ist mein Fazit für

00:14:30: diese Art Weibcoding, ist das im Hobby oder um etwas auszuprobieren, natürlich interessant,

00:14:36: das zu machen. Sonst würde ich es ja auch nicht machen. Aber in großen Unternehmen, je mehr es in

00:14:42: Richtung Weibcoding geht, desto ineffektiver wird es einfach auch, weil viel zu viel Reibungsverlust

00:14:48: dazwischen ist, um der Maschine zu erklären, was man selber denn eigentlich auch machen könnte.

00:14:53: Ganz anders, um das an der Stelle auch noch mal zu wiederholen, aus dem oberen Einleitungsteil,

00:14:59: ist AI unterstütztes Engineering. Das könnt ihr vergleichen mit einem sehr, sehr guten Code

00:15:08: Completion, was ihr in der IDE habt. Also deutlich mehr als das klassische Code Completion kann

00:15:15: natürlich AI an der Stelle viel, viel, viel mehr. Und das, finde ich, ist auch das größte Potenzial,

00:15:23: wenn wir alle darüber diskutieren, wie setzt man AI sinnvoll im Entwicklungsprozess ein. Ich

00:15:30: rede hier in der Folge natürlich nur über den Entwicklungsprozess, AI-Einsatz. Für andere

00:15:34: Berufe will ich mir gar kein Urteil erlauben, im Entwicklungsprozess. Und da bin ich der

00:15:42: Überzeugung, da stecken vielleicht zehn Prozent Potenzial drin, dass Menschen eine Chance haben,

00:15:48: schneller zu werden. Und ich finde dieses Bild von Code Completion halt wirklich ganz gut. Und ich

00:15:53: denke, das ist auch das Richtige. Code schreiben lassen von der AI, Webcoding halte ich für super

00:16:00: ineffektiv, rein aus Unternehmenssicht. Code Completion, andere Unterstützung, keine Ahnung,

00:16:08: Code Review, das würde ich alles unter AI unterstütztes Engineering fassen. Und da steckt

00:16:14: ein gewisses Potenzial drin. Ja. Und das soll mein Einblick tatsächlich sein. Mir geht es gar

00:16:20: nicht darum, dass ich jetzt hier in einem Hobbyprojekt was mit AI mache. Mir ging es vor

00:16:26: allen Dingen um den Vergleich und diese Erkenntnis nochmal, um das rauszuarbeiten, dass einem natürlich

00:16:31: agiles Arbeiten hier super viel hilft oder die Methodiken des agilen Arbeitens. Und das soll es

00:16:37: dann tatsächlich heute auch schon gewesen sein. Wenn dir das hier gefallen hat, habe ich noch eine

00:16:41: ganz große Bitte. Erzähl über den Podcast oder die Folge. Sprich mit deinen Kolleginnen und

00:16:47: Kollegen. Teile es gern auf Social Media. Je mehr Leute den Podcast finden, je mehr Leute nehmen an

00:16:55: Diskussionen teil. Ich kann dann mehr Themen aufnehmen, kann auf Dinge eingehen. Und wenn es

00:17:00: gut läuft, kommt dir das ja tatsächlich selber auch zugute. Ja, ansonsten sage ich vielen Dank

00:17:05: fürs Zuhören. Ich freue mich schon auf die nächste Folge. Ich wünsche dir noch eine ganz tolle Woche.

00:17:11: Bis dann. Tschüss.