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

Thomas
Thomas
Vibe Coding und agiles Arbeiten

Eine wichtige Einordnung von Vibe Coding und agilem Arbeiten

KI ist immer noch in aller Munde. In dieser Folge erzähle ich von meinen persönlichen Erfahrungen und stelle eine Verbindung her, warum meine Kenntnisse rund um agiles Arbeiten eine große Hilfe sind, damit ich überhaupt sinnvoll Vibe Coding machen kann.

Shownotes

Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile

—

NBA85: Agilität vs. Gantt-Chart: Ein unlösbarer Konflikt?

User Story Mapping und Dimensional Planning: NBA13 – Agile Projektplanung

Antrophic Claude Code CLI

OpenAI Codex CLI

Google AI Studio

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. In der letzten Folge habe ich über agiles Arbeiten versus klassischem Projektmanagement gesprochen. Dabei bin ich ein bisschen auf die Stacy Matrix und das magische Dreieck eingegangen. Wenn dich das interessiert, hör da gerne rein. Den Link zu dieser Folge sowie alle weiteren Links, die ich hier erwähne, findest du natürlich in den Shownotes. Das hier ist Folge 86 und ich muss tatsächlich dieses Thema KI nochmal aufmachen. In dem Fall hier, in dieser Folge soll es vor allen Dingen um Vibe-Coding gehen. Allerdings will ich das Ganze tatsächlich mit einem anderen Blickwinkel aufnehmen. Bevor wir da in die Details einsteigen, fange ich tatsächlich einfach mal mit dem Fazit an, weil ich weiß, dass viele von euch von AI so genervt sind. Hear me out. Also worum soll es hier gehen? Ich bin weiterhin der festen Überzeugung und es hat sich jetzt auch nochmal gefestigt. Es gibt zuallererst mal einen ganz großen Unterschied, den man mental machen muss. Zwischen Vibe-Coding, also ich kann nicht entwickeln und ich möchte mit AI-Tools trotzdem etwas entwickeln. Versus AI-Supported Engineering. Also ich kann entwickeln und nutze AI in meinem täglichen Prozess. Vibe-Coding und das ist die Geschichte, die ich euch gleich erzähle, ist meiner Meinung nach überhaupt nichts für Unternehmen. Im Hobby oder so und es mag auch Grenzfälle geben, da geht das vielleicht, aber ganz grundsätzlich geht es in meinen Augen nicht. AI-Supported Engineering hingegen geht. Das ist ein Tool wie jedes andere, das sage ich ja auch immer. Da komme ich dann im echten Fazit der Folge auch nochmal drauf. Und ich denke, das kann so 10% Effektivitätsgewinn sicherlich bringen. Gut, wo wir das Fazit haben, würde ich sagen, können wir die Folge beenden? Nee, natürlich nicht. Was für ein Setting habe ich denn überhaupt? Fangen wir damit mal an. Also, ich kann nicht entwickeln, ich habe das nie gelernt und wenn ich entwickeln könnte, würde ich tatsächlich nicht Vibe-Coding machen. Warum komme ich später drauf? Mein Leben, habe ich mir hier so in meinen Schulnutz notiert, wäre deutlich einfacher, wenn ich denn entwickeln könnte. Zumindest für das, was ich da vorhabe. Vibe-Coding gibt mir nämlich die Möglichkeit, Ideen umzusetzen. Natürlich ist es so, dass man immer mal wieder Ideen hat für ein kleines Tool oder für irgendwas, für irgendwelche Hobbyprojekte, wo es natürlich gut ist, wenn man entwickeln kann, um diese Entwicklungshobbyprojekte auch zum Leben zu erwecken. Und das ist ein bisschen meine Situation. Ich habe da immer mal wieder Ideen und jetzt gerade wieder eine und versuche da intensiv irgendwie weiterzukommen. Und dann gibt mir Vibe-Coding die Möglichkeit, tatsächlich zu entwickeln. Und ja, da möchte ich jetzt ganz gerne mal den Vergleich ziehen. Fangen wir mal an folgender Stelle an. AI, wenn man sie jetzt in diesem Vibe-Coding-Setting benutzt, ist von den Fähigkeiten her ein Fachinformatiker, Azubi, im ersten Jahr. So stelle ich mir das vor und ich glaube, das ist gar nicht so unrealistisch, sich das so zu überlegen. Und das sollte man wirklich im Blick haben, wenn man jetzt, ja, ich sag mal über Vibe-Coding spricht. Notiz vielleicht, ich glaube auch mit dieser Methodik, Large Language Model, LLM, geht es auch nicht viel weiter. Die werden nicht viel besser werden. Es müsste meiner Meinung nach jetzt irgendwas ganz anderes erfunden werden, um einen großen Schritt weiter zu kommen. Ich habe den Eindruck, dass eine große Sättigung erreicht ist, wenn ich das jetzt vergleiche. Keine Ahnung, 2022, 2023, wie stark die Kurve gestiegen ist, wie schnell die besser geworden sind, diese Dinger. Und das jetzt einfach mal mit 25 vergleichen muss. Ich feststellen, ja, hier und da gibt es eine Verbesserung. Aber ehrlich gesagt, die Steigung der Kurve, wenn ihr euch das so vorstellen wollt, die ist extrem abgeflacht. Und das bringt mich eben dazu, dass ich der Meinung bin, viel besser wird es jetzt nicht, es findet irgendwo nochmal so eine Revolution in dieser Art statt. Aber gut, das ist jetzt erstmal nur meine Meinung. Zurück zu diesem Bild. Wir wollen etwas entwickeln und wir tun das jetzt tatsächlich Vibe-Coding-Modus mit AI. Und wir haben festgestellt, die AI kann jetzt so viel und manchmal kann sich selbst das nicht, muss man auch sagen, keine Abwertung von Fachinformatiker-Azubis wie ein Azubi im ersten Ausbildungsjahr. Und jetzt müsst ihr euch Folgendes vorstellen. Ihr habt ein größeres, komplexeres Projekt vor Augen und ihr macht das jetzt mit einem Fachinformatiker-Azubi im ersten Ausbildungsjahr. Und die Frage hier ist, wie geht ihr vor? Und wenn ihr dieses Bild mal mitnehmt und euch das mal überlegt und überlegt, wie wäre das wirklich ein größeres, komplexes Projekt, von mir aus auch mit mehreren Fachinformatiker-Azubis zu machen, dann habt ihr eigentlich schon das erste gute Gefühl, was das jetzt bedeutet. Das bringt uns dann tatsächlich zu dem Punkt, dass ich euch mein Team da mal vorstellen kann. Haha, was nutze ich denn? Und was ich nutze, ist von Entropic Cloud Code, Cloud Code CLI in diesem Fall. Das ist so mein Daily Driver. Damit mache ich alles, was jetzt mit Coding zu tun hat. Dann habe ich im Team noch wen anders, nämlich Codex. Also von OpenAID, CLI. Mit dem knacke ich die harten Nüsse. Da gibt es die Möglichkeit, ich sage mal ein sehr teures Modell zu wählen. Und wenn ich in der Situation bin, wo Cloud nicht mehr weiterkommt, nutze ich tatsächlich Codex. Und mein drittes Teammitglied, ich hoffe ihr seht immer, dass ich Gänsefüße in die Luft mache, wenn ich Teammitglied sage, ist Google AI Studio. Das hat den großen Vorteil, AI Studio hat einen sehr großen Kontext, sprich ihr könnt da sehr große Dokumente reinhauen. Das geht bei anderen Modellen eben nicht. Okay. Ich nutze also vor allen Dingen CLI-basierte AI-Assistenten. Cloud Code vor allen Dingen. Und das Setting ist jetzt wie folgt. Ich habe so ein großes Projekt, ich habe eine Idee dazu und das möchte ich jetzt umsetzen. AI grundsätzlich benötigt, ja manchmal wie diese Azubis, möglichst präzise und spezifische Anweisungen oder Prompts. Und das bedeutet im Umkehrschluss, wenn ich was Größeres machen will und das präzise formulieren muss, muss ich alles vorplanen. Und habe dann eine lange Planungsphase, um dann etwas umzusetzen, um dann ins Feedback zu kommen, um zu schauen, hat das funktioniert. Und einige von euch werden jetzt sagen, ah, Moment mal, das klingt ein bisschen wie Wasserfall. Und genau das ist es auch. Dadurch, dass wir gezwungen sind, grundsätzlich erstmal mit AI, wenn wir mit AI arbeiten, sehr präzise zu formulieren, müssen wir lange vorplanen. Wir wissen aber auch, wenn wir lange vorplanen, dass egal wie gut wir drüber nachdenken, wir diesen Plan nicht so bauen können, dass er in der Lage ist, all das zu beschreiben, was wir wirklich haben wollen. Denn zum Teil wissen wir noch gar nicht, was wir wirklich haben wollen. Das ist ja eben der Hack am agilen Arbeiten, dass wir eben in so Feedbackzyklen kommen wollen und die klein halten wollen. Im agilen Arbeiten gehen wir eigentlich immer in kleinen Schritten vor. Wir machen kleine Iterationen. Wir haben einen großen Plan, den zerteilen wir in möglichst viele kleine Pläne. Wir überlegen, was bringt erstmal am meisten Wert oder Erkenntnis. Dann lassen wir das entwickeln oder wir entwickeln es. Und das sind kleine Inkremente, die wir da entwickeln. Und dann schauen wir uns das an und suchen nach Feedback, um den großen Plan und die nächsten kleinen Pläne anzupassen. Inspect and Adopt. Wir wollen schnell in diese kleinen Feedbackzyklen. Was bedeutet das für Vibe-Coding? Naja, gehen wir mal in die Praxis. Wie gehe ich denn vor? Ich möchte eben nicht in den Wasserfall, was wir in Projekten aber trotzdem immer machen, auch im agilen Arbeiten. Wir gehen ja immer planvoll vor. Wir erstellen uns erstmal einen Gesamtplan. Dazu gehe ich dann zu Claude. Und in Claude gibt es die Möglichkeit von so einem Planungsmodus. Dann entwickelt der nicht. Sondern, ja, er stellt eben einen Plan. Und dann gibt es noch so einen Spezialmodus, den man anmachen kann. Der heißt tatsächlich Ultra Think. Und, ja, dann kommt so ein Reasoning dazu. Und in diesem Modus erarbeite ich mit meinen Ideen und mit Claude, der weiß, wie man Code schreibt oder auch nicht, eben einen großen Plan auf einer abstrakteren Ebene. Das geht vor und zurück, vor und zurück, immer weiter diskutiert, bis so ein Plan dann entsteht. Manchmal nehme ich mir diesen großen Plan und gebe denen dann tatsächlich Google AI Studio und sage hier, guck du auch nochmal drauf. Und dann entsteht noch zwischen mir und meinen Teamkollegen Claude und AI Studio, ja, ein Dialog. Auch wieder Gänsefüßchen, ne? Auf jeden Fall haben wir so einen großen Plan. Daraus lasse ich ein GitHub-Issue erstellen, damit wir den großen Plan erstmal überhaupt haben. Wichtig ist, ich muss den Plan verstehen. Nicht die Codezeile, aber der Plan entspricht das überhaupt noch meinem Plan. Weil das kann einem auch super schnell passieren. Und dann hat man schon wieder verloren. Wenn man sich einfach so denkt, trolululululul, wird schon, dann geht das oft in die Hose. Also ihr müsst da einfach hart mitdenken oder ich muss in meinem Fall da hart mitdenken. Immer wieder lesen, immer wieder überlegen. Moment einmal, ist das überhaupt noch das Richtige? Und dann gehen wir, genau wie im agilen Arbeiten, in eine Phase 2 des Refinements. Wir haben jetzt diesen großen Plan und wir zerteilen ihn jetzt in ganz kleine Pläne. Eine schöne Methodik an der Stelle, die ich dann benutze, ist tatsächlich User Story Mapping und Dimensional Planning. Habe ich mal eine Folge drüber gemacht. Den Link dazu findest du in den Show Notes. Ich nutze einfach wirklich meine Erfahrungen aus dem agilen Arbeiten und meine Methodiken, damit es überhaupt irgendeine Chance hat zu funktionieren. Mein Ziel ist es, die wichtigen Dinge zu identifizieren, die ich als erstes umsetzen will. Und das mache ich eben mit so einer Methodik. Es gibt andere Methodiken, die ihr verwenden könnt. Und nehme den großen Plan und lasse ihn dann mit Hilfe von AI in eine Phase zerlegen, in einem Refinement, in kleine Teile zerlegen. Und daraus mache ich wieder GitHub-Issues. Wir haben also dann Refined. Jetzt kommen wir in die dritte Phase. Die kennen wir auch aus dem agilen Arbeiten, nämlich die Umsetzung. Wir schnappen uns eins, das Wichtigste hoffentlich, von diesen kleinen Teilen und zerlegen das in super kleine Teile. Wir machen jetzt Task-Splitting. Wir sitzen zusammen und überlegen uns, was ist denn alles wirklich zu tun? Das Was haben wir? Und jetzt geht es darum, das Wie. Das heißt, ich habe dann aus einem ganz großen Plan drei kleinere Elemente identifiziert. Und das erste kleinere Element zerteile ich jetzt nochmal in ganz kleine Elemente. Und in dem Moment kann ich dann sagen, setze den ersten ganz kleinen Teil um. Der ist super präzise. Da kann ich den Prompt sehr scharf formulieren. Und er ist so klein, dass ich keine großen Überraschungen erleben werde. Soweit kann ich vorplanen. Beziehungsweise, wenn ich eine Überraschung erlebe, kann ich schnell gegensteuern. Und dann kommt die vierte Phase. Auch die kennen wir aus dem agilen Arbeiten. Wir sind im Feedback. Ich gucke mir das Ergebnis an. Ich vergleiche das mit dem großen Plan. Ich diskutiere das. Codemäßig mit den AIs im Zweifelsfall. Auch hier benutze ich dann wieder AI Studio und sage hier, soweit sind wir. Was denkst du? Gebe das wieder an Claude, um zu arbeiten. Aber wir sind halt hier im ganz kleinen Inkrement an dieser Stelle. Und ich selber kontrolliere natürlich auch. Entspricht das Ergebnis meiner Erwartung? Sind wir noch auf dem richtigen Weg? Und diesen ganzen Input nehme ich dann, um zu entscheiden, wie der nächste Zyklus startet. Sind wir im großen Plan noch auf dem Weg? Sind wir im kleinen Plan noch auf dem Weg? Oder muss ich neu planen? Inspect and adopt. Und das ist tatsächlich ein Zyklus, in dem mir meine Erfahrung im agilen Arbeiten und das grundsätzliche Mindset des agilen Arbeitens hilft, um mit Vibe Coding überhaupt klar zu kommen. Ihr seht an dieser Stelle vielleicht, und deswegen habe ich unter anderem diese Folge halt auch gemacht, wie super anstrengend das ist. Also ich sitze da und muss mich da permanent drauf konzentrieren und permanent darauf achten, dass diese Maschine wirklich das Richtige tut. Das ist was ganz anderes, als ob ich mit meinem wirklichen Team entwickle. Die bringen so viel Erfahrung mit, so viel Wissen mit, so viel Domänenwissen, dass das eine ganz andere Rolle dann auf einmal bei mir ist. Das ist viel, viel einfacher auf dieser Ebene. Und deswegen bin ich der festen Überzeugung, dass diese Art einfach überhaupt nichts für Unternehmen ist. Es dauert auch viel zu lange. Also unabhängig davon, dass es super anstrengend ist, dauert es auch viel, viel länger. Ihr seht ja, dass ich so komplexes Verfahren anwenden muss, immer wieder mich rückversichern muss, mehrere Tools benutze, um sicher zu gehen, dass das, was da entsteht, auch wirklich, ich sag mal, eine saubere Architektur ist, verlässlich ist. Und wenn ich entwickeln könnte, deswegen habe ich das am Anfang auch gesagt, würde ich mir den ganzen Quatsch auch sparen wollen und einfach entwickeln. Weil wenn ich die Idee eh schon habe und ich in der Lage bin, mir das zerteilen, warum soll ich das noch mit wem anders machen? Und deswegen ist mein Fazit, für diese Art Vibe Coding ist das im Hobby oder irgendwas auszuprobieren, natürlich interessant, das zu machen, sonst würde ich es ja auch nicht machen. Aber in großen Unternehmen, je mehr es in Richtung Vibe Coding geht, desto ineffektiver wird es einfach auch, weil viel zu viel Reibungsverlust dazwischen ist, um der Maschine zu erklären, was man selber denn eigentlich auch machen könnte. Ganz anders, um das an der Stelle auch nochmal zu wiederholen, aus dem oberen Einleitungsteil, ist AI unterstütztes Engineering. Das könnt ihr vergleichen mit einem sehr, sehr guten Code Completion, was ihr in der IDE habt. Also deutlich mehr als das klassische Code Completion, kann natürlich AI an der Stelle viel, viel, viel mehr. Und das, finde ich, ist auch das größte Potenzial, wenn wir alle darüber diskutieren, wie setzt man AI sinnvoll im Entwicklungsprozess ein. Ich rede hier in der Folge natürlich nur über den Entwicklungsprozess, AI-Einsatz für andere Berufe, will ich mir gar kein Urteil erlauben. Im Entwicklungsprozess. Und da bin ich der Überzeugung, da stecken vielleicht 10% Potenzial drin, dass Menschen eine Chance haben, schneller zu werden. Und ich finde dieses Bild von Code Completion halt wirklich ganz gut. Und ich denke, das ist auch das Richtige. Code schreiben lassen von der AI, Vibes, Vibes, Vibes, halte ich für super ineffektiv. Rein aus Unternehmenssicht. Code Completion, andere Unterstützung, keine Ahnung, Code Review. Das würde ich alles unter AI-unterstütztes Engineering fassen. Und da steckt ein gewisses Potenzial drin. Ja. Ja. Und das soll mein Einblick tatsächlich sein. Mir geht es gar nicht darum, dass ich jetzt hier in einem Hobbyprojekt was mit AR mache. Mir ging es vor allem um den Vergleich und diese Erkenntnis nochmal, um das rauszuarbeiten, dass einem natürlich agiles Arbeiten hier super viel hilft. Oder die Methodiken des agilen Arbeitens. Und das soll es dann tatsächlich für heute auch schon gewesen sein. Wenn dir das hier gefallen hat, habe ich noch eine ganz große Bitte. Erzählt über den Podcast oder die Folge. Sprich mit deinen Kolleginnen und Kollegen. Teilt es gern auf Social Media. Je mehr Leute den Podcast finden, je mehr Leute nehmen an Diskussionen teil. Ich kann dann mehr Themen aufnehmen, kann auf Dinge eingehen. Und wenn es gut läuft, kommt dir das ja tatsächlich selber auch zugute. Ja. Ansonsten sage ich vielen Dank fürs Zuhören. Ich freue mich schon auf die nächste Folge. Ich wünsche dir noch eine ganz tolle Woche. Bis dann. Tschüss. 

Mastodon Diskussionen

Auch interessant