Vibe Coding 101: Ein Praktischer Null-zu-Eins-Workshop

Lies das Transkript:

Wir probieren aus, unsere Podcasts mit einem Softwareprogramm zu transkribieren. Bitte verzeihen Sie etwaige Tippfehler, da der Bot nicht immer 100% korrekt ist.

Hannah Clark: Alles klar, Leute. Haftungsausschluss zur Episode – wenn ihr schon Expert:innen im Vibe Coding seid, ist diese Episode vermutlich nichts für euch. Aber falls ihr schon von Vibe Coding gehört habt und Fakten von Mythen unterscheiden wollt und neugierig seid, wie ihr die Technologie nutzen könnt, um eure eigenen Ziele voranzubringen, dann werdet ihr das hier lieben.

Falls ihr unseren Newslettern nicht gefolgt seid, zum Beispiel dem, den ihr unter theproductmanager.com/subscribe abonnieren könnt: Ich habe nicht aufgehört, von dem großartigen, praxisnahen Vibe Coding Workshop zu schwärmen, den wir vor ein paar Wochen mit Drew Falkman, Principal bei Moves The Needle, veranstaltet haben. Diese Episode des Product Manager Podcasts ist tatsächlich eine Aufnahme des 30-minütigen Seminars, das wir vor unserer Live-Prototyping-Session gemacht haben. Ihr hört eine Aufschlüsselung, was Vibe Coding ist und was nicht, inspirierende Anwendungsfälle für die Technologie und Tool-Empfehlungen, damit ihr eigene Use Cases entdecken und ausprobieren könnt. Legen wir los.

Ach ja, übrigens: Solche Gespräche führen wir jede Woche. Falls das also für euch spannend klingt – warum nicht abonnieren? Okay, los geht’s.

Ich bin Hannah Clark. Falls ihr mich nicht kennt: Ich bin Executive Editor beim The CPO Club und Gastgeberin des The CPO Club Podcasts. Und ich habe meine Co-Moderatorin Katie dabei.

Katie Sanders: Hallo zusammen, ich bin Katie Sanders. Ich bin Executive Editor beim CTO Club. Vielleicht kennt ihr mich auch schon von The QA Lead. Einige von uns haben diese Seiten zusammengelegt. Ich freue mich sehr, dies ist mein erster Workshop und ich bin echt begeistert, das zusammen mit Hannah zu machen, weil es viele Schnittmengen zwischen Produkt und CTOs gibt. Ich freue mich darauf, alle kennenzulernen. Willkommen!

Hannah Clark: Ich freue mich sehr, mit Katie zusammenzuarbeiten. Falls ihr ihr noch nicht auf LinkedIn folgt – Katie Sanders, sie ist wirklich großartig. Sie hat tollen Content, und ich freue mich, wenn ihr euch gegenseitig kennenlernt.

Ich möchte auch unseren Gastredner vorstellen. Wir haben Drew Falkman dabei. Drew ist Product Leader, Berater und Dozent – spezialisiert auf Strategie von Pre-Seed bis Seed Produkten. Er optimiert frühphasige Teams und sorgt für Product-Market-Fit.

Er hat schon alles gemacht. Er ist ein guter Freund der Publikation, hat schon oft mit uns zusammengearbeitet – vor allem auch mit mir, was beweist, wie geduldig er ist. Ihr seid heute also in guten Händen. Außerdem hat er viel Erfahrung mit Web, Mobile, Blockchain und KI-Produkten. Wir haben heute also einen echten Experten hier.

Drew, möchtest du Hallo sagen?

Drew Falkman: Hallo zusammen, ich freue mich sehr, hier zu sein. Das wird spaßig.

Hannah Clark: Wir starten mit ein paar Mythen und ich beginne mit der ersten Frage, dann gehen meine wunderbare Co-Moderatorin Katie und ich einige Mythen durch, die Drew für uns aufklären wird. Wir fangen also mit ein wenig Kontext an.

Es scheint, als würde jeder über Vibe Coding sprechen und in jedem LinkedIn-Post kommt es gerade vor, auch in vielen von meinen. Die Leute sind entweder begeistert, verängstigt oder verwirrt davon. Lasst uns also darüber reden, warum Vibe Coding so angesagt und wichtig ist. Zeit für die Mythen.

Katie Sanders: Gut, der erste Mythos: Vibe Coding ersetzt Ingenieur:innen. Klar, generell wird bei KI schon behauptet, sie würde alle Jobs ersetzen. Ich sage, das ist ein Mythos. Vielleicht ändert sich die Arbeit von Ingenieur:innen, und es entsteht tatsächlich fertig einsetzbarer Code, aber der Beruf verschwindet sicher nicht komplett.

Wie immer bei KI ist wichtig, dass der Mensch eingebunden bleibt. Nichts wird ohne menschliches Prüfen ausgeliefert. Darum ist dieser Mythos widerlegt.

Hannah Clark: Drew, möchtest du noch etwas hinzufügen?

Drew Falkman: Ja, ich würde sagen, das ist etwas, dessen man sich als Ingenieur:in bewusst sein sollte.

Es kann den Prozess beschleunigen. Für Designer:innen, Produktmanager:innen oder Gründer:innen ohne Tech-Hintergrund bietet es jetzt die Möglichkeit, MVPs und Prototypen zu erstellen, zu validieren, und dann ans Entwicklerteam weiterzugeben. Sobald es um produktionsreifen Code geht – also nach dem MVP – sollte das entwickelt werden.

Gerade heutzutage ist Code-Review und Qualitätssicherung wichtiger denn je, vor allem bei Compliance-Themen.

Hannah Clark: Kommen wir zu Mythos Nummer zwei: Manche sagen, Vibe Coding steht außerhalb des klassischen Entwicklungszyklus.

Das heißt also, wenn du etwas in einer Vibe Coding App baust, ist es nicht wirklich nutzbar und muss komplett von Grund auf neu geschrieben werden. Drew, ist das wirklich so?

Drew Falkman: Die Tools haben sich immens weiterentwickelt und ändern sich quasi täglich.

Claude z.B. hat vor kurzem eine neue Version seines Code-Generators rausgebracht, die um Längen besser ist als zuvor. Es verbessert sich ständig. Natürlich können generative KI-Tools “halluzinieren” oder Unsinn produzieren, aber als Teil des Entwicklungszyklus kannst du solche Code-Schnipsel erzeugen.

Diese können den Entwickler:innen übergeben werden, wobei bewusst sein sollte, dass oft Nacharbeit nötig ist und Komponenten wiederverwendet werden müssen. Manche Entwickler:innen werden überrascht sein, wie gut der Code tatsächlich ist.

Hannah Clark: Ein weiterer Mythos: Man braucht keinen PRD oder Produktstrategie zum Vibe Coding eines Tools.

Drew, Katie, was meint ihr dazu?

Drew Falkman: Man sollte auf jeden Fall nachdenken. Manche denken, sie könnten einfach mit Vibe Coding starten, alles öffnen und hätten morgen eine App. Aber ohne Vorüberlegung wird es nicht das, was ihr wollt. Denkt über Zielgruppe, Zweck und Kernfunktionalitäten nach.

Ihr braucht nicht ein langes 5-10-seitiges PRD, das jede technische Einzelheit definiert und Prozesse grafisch aufbereitet, sondern ein kurzes Dokument – vielleicht 1-2 Seiten – das eure Vision zusammenfasst und mit euren Kollaborateur:innen geteilt werden kann. So seid ihr alle auf einer Linie und euer Ansatz ist organisiert.

Am Ende wird auch der Code sauberer sein.

Hannah Clark: Gut zu wissen. Kommen wir zum nächsten Mythos: Hochregulierte Branchen. Katie repräsentiert den CTO Club, willst du das übernehmen, Katie?

Katie Sanders: Ja, ich wollte noch erwähnen: Das ist alles gar nicht neu. Wir machen in Wahrheit schon seit Jahren Vibe Coding.

Wir haben es nur erst jetzt so genannt. Früher hat man aus GitHub, Reddit oder Hacker News Code kopiert. Gute Entwickler:innen lösen Probleme, suchen Lösungen, adaptieren und bauen weiter. Prompt-Engineering ist nur die nächste Stufe. Was war dein zweiter Mythos, Hannah?

Hannah Clark: Dass man in hochregulierten Branchen kein Vibe Coding machen kann – z.B. wegen fehlender Sicherheit.

Katie Sanders: Genau. Gerade im Gesundheits- oder Finanzbereich sind strenge Vorgaben wichtig. Es gilt immer: Auf Compliance achten, z.B. bei HIPAA. LLMs können manchmal Daten ziehen, wo sie nicht sollen – das muss man bedenken. Aber grundsätzlich gelten hier dieselben Vorsichtsmaßnahmen mit vielleicht zusätzlichen Schranken.

Hannah Clark: Letztlich ähneln sich viele Entwicklungsprozesse, egal ob mit oder ohne Vibe Coding. Die Tools ersetzen keine Menschen, sondern beschleunigen nur. Ein strenges Code-Review ist heute wichtiger denn je, da wir Aufgaben auch auslagern. Sprechen wir jetzt über Anwendungsbeispiele. Katie übernimmt hier.

Katie Sanders: Viele habe ich aus Reddit. Als Vibe Coding aufkam, wollte ich echte Beispiele sehen. Alle redeten, aber Erfolge waren schwer zu finden.

Ich schrieb dazu einen Artikel. Zum Beispiel gab es jemanden, der eine Nischen-Fußballspiel-Organisator-App baute. Keine:r Entwickler:in, aber er verstand Full-Stack-Prinzipien, musste jedoch bisher immer externe Entwickler:innen engagieren. Mit Tools wie Lovable und Cursor baute er dann seine App für das wöchentliche Spiel – erfolgreich, rein KI-generierter Code, profitabel mit 100 Zeilen Code. Ich glaube, das brachte ihm etwa – wie viel, Michael? – vielleicht 700 USD pro Woche ein.

Ein anderes Beispiel: “Work Aid” – ein gamifiziertes Aufgabenmanagement per KI: ToDo-Listen werden spielerisch gemacht. Das sind echte Beispiele, zu denen wir auch den Reddit-Post verlinken können.

Weitere gibt es dort. Viele experimentieren noch, aber einige werden damit wirklich erfolgreich. Coole Sache!

Hannah Clark: Super Beispiel. Kurze Unterbrechung wegen einer guten Frage von Katya:

Katya fragt: Muss man als Product Manager:in noch Wireframes und Mockups für das Frontend machen? Oder kann man direkt mit Vibe Coding das Frontend erstellen und die Entwickler:innen nutzen es als Grundlage?

Drew Falkman: Ja, absolut. Tatsächlich ist es mit den meisten Vibe Coding Tools schwieriger, ein bestehendes Design zu implementieren als Neues zu erstellen. Der Import von Screens ist aufwendig. Definiert lieber das Design und arbeitet mit der KI an Look & Feel. Dann können es die Entwickler:innen so anpassen, dass es Design-Guidelines entspricht.

Hannah Clark: Danke, Drew. Sorry für die Unterbrechung, Katie. Du hast noch ein paar Use Cases?

Katie Sanders: Michael, willst du unser Anwendungsbeispiel aus dem Unternehmen vorstellen, den Layoff Impact Analyzer?

Michael Mordak: Gerne. Ein:e Kolleg:in entwickelte für eine HR-Publikation ein Tool, mit dem man die Auswirkungen von Entlassungen analysieren kann. Dazu muss ein Fragebogen ausgefüllt werden, sodass Nutzerdaten vorliegen. Danach gelangt man zum Rechner, gibt z.B. an, wenn ein:e Arbeitgeber:in in der Fertigung 200 Personen entlässt, wählt dieses Beispiel und trägt Details ein (z.B. Fachwissen der Mitarbeitenden, Zeit für Einarbeitung neuer Leute usw.). Dann wird der Layoff-Impact berechnet.

Ein wertvolles Tool für HR-Abteilungen, kostenlos als Demo. Ein weiteres Beispiel: Unser internes Umfrage-Tool, das ich selbst gebaut habe. Ich habe kaum Programmiererfahrung, dennoch konnte ich diese App für Umfragen im Live-Event bauen – inklusive Namensvergabe, Optionen, Vorschaufunktion, Start/Stopp, Anzeige der Ergebnisse. Es werden keine Teilnehmerdaten gespeichert.

Das alles dauerte 1-2 Stunden – inklusive einfacher Markenanpassung. Ich bin kein Designer, also lasst euch nicht von mir inspirieren.

Katie Sanders: Wir haben also viele Vorteile besprochen. Manche denken, sie bräuchten nie mehr Technik-Expert:innen. Es gab z.B. Leo Junior, Gründer von Enrich Lead. Er baute mit Cursor eine ganze App – ohne eine Zeile selbst zu schreiben, ganz stolz. Aber schon nach 48 Stunden übernahmen Hacker seine App, Umgehungen liefen, Kosten explodierten, die KI halluzinierte Leads. Leo musste ein SOS auf Twitter posten: Er kämpfte mit den Problemen, lernte jetzt klassisch Programmieren.

Lesson learned: Mensch bleibt unverzichtbar fürs Review – gerade für Nicht-Techniker:innen ist das Experimentieren spannend, aber professionelle Prüfung bleibt essenziell.

Hannah Clark: Michael, magst du schildern, wie die Lernkurve für dich war, als du zum ersten Mal mit den Tools experimentiert hast?

Michael Mordak: Klar! Ich habe kaum Kenntnisse im Coding. Oft bin ich nur der Ideenmensch, der neue Ansätze findet, aber nichts selbst baut. Das Tool, das wir heute nutzen – Lovable – ist aber wirklich einsteigerfreundlich. Die Lernkurve ist sanft. Eigentlich ist es nur Text-Prompting.

Man beschreibt, was man möchte: Was soll die App können, was ist das Ziel? Es gibt Vorschläge, und man kann Details nachreichen. Zum Beispiel wollte ich, dass es aussieht wie slido.com (ein Umfragetool). Die KI orientiert sich daran, Branding und weitere Vorgaben kann man einfach eingeben.

Nach dem ersten Entwurf ist nicht Schluss, sondern man kann chatten, Fragen stellen, bevor etwas gebaut wird. Wenn ich etwas nicht verstand, kopierte ich Lovable-Antworten in ChatGPT und bat um eine Erklärung für Anfänger:innen – das hat bestens funktioniert. Insgesamt ein sehr angenehmer Prozess.

Hannah Clark: Super spannend! Hoffentlich motivierend für alle, die wie ich von Null starten.

Jetzt eine Frage von Tal an Drew: Was würdest du als guten Workflow für bestehende Produktfirmen empfehlen? Ich bin PM bei einem Startup, wir haben ein Design System und ein Produkt mit Nutzern. Wann kann ich mit Vibe Coding für Features/Ideen starten, und wann geht es zurück zum Design oder direkt zu Dev?

Drew Falkman: Der Workflow ist aktuell noch absolut im Entstehen. Es gibt noch keine Best Practices, alles ist etwas “Wildwest”. Würde ich es machen: Ich würde das Design nicht überspringen, sondern eng mit Designer:innen zusammenarbeiten. Im (meinem) Vibe PRD skizziere ich die Seiten und Elemente, stimme mich aber eng mit Design ab, alle können mitarbeiten.

Anschließend baue ich die Lösung. Bei Lovable gibt es keine Standard-Integration für Design-Systeme. Cursor ist etwas technischer, da es auch Kommandozeile und tiefergehende Codeintegration erlaubt. Das könnte in solchen Fällen geeigneter sein. Lovable kann aber mit GitHub synchronisieren. So kann ein Entwurf zu GitHub gepusht, von Devs angepasst und wieder zurückgespielt werden – und idealerweise sieht man alles synchronisiert.

Hannah Clark: Großartig. Frage von Donald an Drew: Wie lief das Vibe Coding bei etwas, das sehr “Cloney” ist (z.B. ein weiteres Task Management Tool), im Vergleich zu etwas ganz Eigenständigem, z.B. eine Sonifikation von Google Trends Daten? Also: Copy eines existierenden Produkts vs. etwas ganz Neues?

Drew Falkman: Sehr gute Frage. Aus Erfahrung mit Prototyping- und Vibe Coding-Tools klappt es bei etablierten Produkten recht einfach, weil die KI solche Themen versteht. Ein Travel-App-Beispiel kann sie problemlos erstellen. Innovationsprojekte wie “Google Trends sonifizieren” sind viel komplexer. Sobald es speziell um Visualisierungen außerhalb gängiger Interface-Elemente geht, werden Tools wie Lovable schnell an ihre Grenzen stoßen. Hier braucht es dann doch Entwickler:innen für Sonderlösungen.

Hannah Clark: Das war unsere Zeit! Vielen Dank an Katie, dass sie dabei war, und natürlich Drew für seine grandiose Expertise.

Danke fürs Zuhören! Für weitere Einblicke, How-Tos und Tool-Reviews abonniert unseren Newsletter auf theproductmanager.com/subscribe. Weitere spannende Diskussionen findet ihr im The CPO Club Podcast auf allen Podcast-Plattformen.