In den letzten Wochen habe ich zusammen mit befreundeten Nicht-Entwicklern (Juristen, Marketern, PMs usw.) mit Vibe Coding fünf bis sechs einfache Apps gebaut.
- WoW-Gilden-Raid-Dashboard (Web)
- Rennsimulator für Gewinnspiel-Verlosungen (Web + Three.js)
- Ein Tool zur Kommunikation zwischen Videoeditoren und Auftraggebern (Chrome-Erweiterung)
- Ein automatischer Timer, der die Anzahl der Iterationen festlegt, für eine bestimmte Zeit beim Fokussieren hilft und danach zur Reflexion anregt (Electron-Desktop-App)
Ich habe diesen Prozess zusammengefasst und einen „Einstiegsguide ins Vibe Coding für Nicht-Entwickler“ in 5 Schritten erstellt.
- Ein Gefühl dafür bekommen, was heutige AI inzwischen alles kann
- Das Problem, das man lösen will, und das Produkt, das man bauen möchte, klar definieren
- Schnell und häufig mit eigenen Augen prüfen, wie das Ergebnis tatsächlich funktioniert
- Mit AI so interagieren und prompten, dass sie gut coden kann
- Fehlverhalten und Verbesserungsmöglichkeiten erkennen, verbessern und sauber abschließen
1) Ein Gefühl dafür bekommen, was heutige AI inzwischen alles kann
Nicht-Entwicklern, die Vibe Coding zum ersten Mal ausprobieren, würde ich empfehlen, mit etwa solchen Aktivitäten zu starten:
- Direkt selbst erleben, dass man in einem LLM oder in einem AI-Prototyping-Service allein mit einem kurzen Prompt etwas Funktionsfähiges bauen kann, um das eigene Zutrauen zu stärken
- Einige SNS-Kanäle und Newsletter abonnieren, die aktuelle AI-Infos aufbereiten
- Den Ehrgeiz aufgeben, alle AI-Infos und Tools komplett erfassen zu wollen, und stattdessen nur Tools zu Themen ausprobieren, die einen selbst wirklich interessieren
2) Das Problem, das man lösen will, und das Produkt, das man bauen möchte, klar definieren
- Selbst wenn man die Fähigkeiten von AI grundsätzlich verstanden hat, lässt sich ohne klare Problemdefinition kein Produkt bauen
- Deshalb muss man zuerst durch Fragen zur Metakognition selbst klarer denken.
- Dafür habe ich die mit Vibe Coding gebaute Metakognitions-App genutzt
- Was möchte ich bauen?
- Warum möchte ich das bauen? Welches Problem will ich lösen?
- Wer erlebt dieses Problem?
- In welchen Situationen erleben diese Personen das Problem?
- Welche Behelfslösungen oder Alternativen nutzen sie in dieser Situation derzeit?
- Wie lässt sich überprüfen, dass 1 das Problem besser löst als 5?
- Wie bringt man sie dazu, lieber 1 statt 5 zu verwenden?
- Wenn klar war, was gebaut werden soll, habe ich den in dieser App erzeugten „PRD-Erstellungs-Prompt“ in ein LLM eingegeben, damit es ein PRD erstellt
3) Schnell und häufig mit eigenen Augen prüfen, wie das Ergebnis tatsächlich funktioniert
- Eine „funktionierende App“ sehr früh zu sehen, ist der größte Vorteil von Vibe Coding. Für die Motivation von Nicht-Entwicklern ist das ebenfalls extrem wichtig
- In diesem Sinne empfehle ich Nicht-Entwicklern nicht besonders, mit Cursor ins Vibe Coding einzusteigen. Ich denke, bis zum Start einer laufenden App gibt es dort viele kleine und große Hürden
- Stattdessen halte ich Services wie Lovable, die aus einem PRD direkt einen funktionierenden Prototypen erzeugen, für den besseren Einstieg. Man bekommt sofort einen öffentlichen Link und kann das Ergebnis dadurch leicht Bekannten zeigen und Feedback einholen
- Wenn die App allerdings nicht webbasiert sein soll, wird es etwas komplizierter, weil Prototyping-Tools Web-Apps erzeugen
- Dann braucht man technische Entscheidungen und ein eingerichtetes Laufzeitumfeld, und dafür müssen sowohl ich als auch die AI klüger werden
4) Mit AI so interagieren und prompten, dass sie gut coden kann
- Ich und die AI werden klüger <-> ich schreibe bessere Prompts <-> das Ergebnis kommt schneller und besser heraus
- Je besser die Prompts, desto weniger Pingpong-Runden (= Zeit und Geld) braucht es bis zum Ziel
- In verschiedenen Prompt-Engineering-Guides wird immer wieder betont, dass man im Prompt Rolle (Role), Kontext (Context) und Aufgabe (Task) sauber definieren soll
Rolle, Kontext, Aufgabe
- Im Vibe Coding ist die „Rolle“ nicht übermäßig wichtig
- In Coding-Agenten sind passende Rollen oft bereits definiert, sodass zusätzliche Vorgaben eher Verwirrung stiften können
- Vielleicht auch deshalb, weil Coding ein wichtiger Benchmark ist, coden LLMs selbst ohne Rollenzuweisung gut
- Wenn die App, die ich bauen möchte, besonders speziell ist, kann eine passende Rolle natürlich trotzdem sinnvoll sein
- Beim „Kontext“ reicht ein gut erstelltes PRD im Grunde aus
- Bei der „Aufgabe“ geht es darum, Ziel und Definition of Done sauber festzulegen. Die Definition of Done kann
- direkt im Prompt stehen (few-shot prompting)
- in externen Dateien oder im Code definiert sein (
TODOs.mdoder Testcode) - nur im eigenen Kopf existieren (dieser Stil ist nicht besonders gut)
- Das ultimative Ziel von Vibe Coding ist, die AI so anzuleiten, dass sie gut codet und schnell eine App baut, die gemäß PRD funktioniert. Dafür ist es sinnvoll, drei Zwischenziele zu setzen
- Ich werde klüger
- Die AI wird klüger
- Die Funktion arbeitet gemäß Spezifikation
Ich werde klüger?
- Wenn man Nicht-Entwickler ist, die Domäne neu ist oder der Tech-Stack ungewohnt ist, fällt es schwer, mit präziser Terminologie Anweisungen zu geben
- In solchen Fällen kann man dem LLM einfach sagen, dass einem Wissen fehlt, und dabei lernen
- „(Mit Screenshot) Womit werden solche Spiele normalerweise gebaut?“
- „Ich will so etwas bauen – wie würdest du an die Datenbeschaffung herangehen?“
- „Welche Technologie sollte ich verwenden, wenn ich das zentrale Verhalten einer nativen App so schnell wie möglich überprüfen will?“
- Dabei sollte man beobachten, ob man sich in diese Richtung entwickelt
- Technische Keywords: Ich benutze korrekte Fach- und Domänenbegriffe
- Datenfluss: Ich kann erklären, wie die Daten für die Kernfunktion meiner App beschafft, verarbeitet und dargestellt werden
- Laufzeitumgebung: Ich habe eine Umgebung vorbereitet, in der ich den von der AI geschriebenen Code ausführen und das Verhalten mit eigenen Augen prüfen kann
- Ideal wäre es, alle unknown unknowns aufzulösen, dann das PRD zu schreiben und erst danach mit dem Coding zu beginnen – zwingend nötig ist das aber nicht
- Man lernt auch viel erst beim Coden, und im Zweifel kann man einfach noch einmal von vorn anfangen. (Das kann sogar schneller sein, als Bestehendes zu reparieren.)
Die AI wird klüger?
- Die ermittelten technischen Keywords oder Datenflüsse der AI über System-Prompts mitteilen (z. B. Cursor Rules)
- Um meine Eingriffe zu reduzieren und Code zu bekommen, der eher meinen Vorstellungen entspricht, braucht es im Wesentlichen zwei Dinge: Vorgaben zu Constraints und Richtlinien zur Dokumentation
- Constraint-Richtlinien helfen der AI, konsistenteren Code zu schreiben. Zum Beispiel:
- Tech-Stack: Verwende NextJS App Router, style mit Tailwind und ShadCN, nutze für Icons nur Lucid, für Payments Stripe usw.
- Struktur und Muster: Ordner so aufbauen, Dateinamen so vergeben, UI im Stil von Material gestalten usw.
- (Abhängig von der Laufzeitumgebung) Ausgabeformat: Ich nutze Electron Fiddle, also gib mir vier passende Dateien; ich nutze CodePen, also gib mir jeweils HTML, CSS und JS usw.
- Dokumentationsrichtlinien helfen, Fokus und Gedächtnis der AI zu verbessern. Zwei Ideen fand ich besonders nützlich
- Cline’s Memory Bank: ein Workflow, bei dem erledigte und anstehende Aufgaben in Dateien festgehalten werden
- Kang Dongyuns Prompt Context: Statt lange projektweite Vorgaben nur im Root-Verzeichnis zu hinterlegen, werden pro Ordner eigene Hinweise erstellt
- Die Memory Bank ist besonders für Nicht-Entwickler empfehlenswert, weil sich dadurch leichter beobachten und lernen lässt, was gerade passiert
Die Funktion arbeitet gemäß Spezifikation?
- Das ist eine Prompting-Strategie für Chats auf Ebene des Coding-Agenten, nicht auf Projektebene
- Die beste Strategie, um Funktionen spezifikationsgetreu arbeiten zu lassen, ist meiner Meinung nach: Wenn die Tests bestehen, wird committed
- „Implementiere X. Schreibe zuerst Tests, code dann die Funktion, führe die Tests aus und passe den Code so lange an, bis alle Tests bestehen.“
- Das ist möglich, weil Coding-Agenten die Berechtigung und Fähigkeit haben, Testcode zu schreiben, ihn im Terminal auszuführen und die Ergebnisse zu lesen
- Wenn die Tests bestehen, kann man sich eine Commit-Message vorschlagen lassen und dann Testcode und Feature-Code gemeinsam committen. Ich committe selbst, aber der Agent kann das auch automatisch tun
- Nicht nur Unit-Tests, sondern auch Integrationstests und E2E-Tests kann die AI schreiben, ausführen und eigenständig korrigieren (siehe: Cursor + Playwright automatisierte Tests)
- All das ist eine Strategie, die es sowohl dem Vibe Coder als auch der AI leichter macht zu prüfen, ob einzelne Funktionen gemäß Spezifikation implementiert sind und die gesamte App gemäß PRD funktioniert
5) Fehlverhalten und Verbesserungsmöglichkeiten erkennen, verbessern und sauber abschließen
- So wie ich Vibe Coding verstehe, ist es weit von einem simplen „Klick und fertig“ entfernt und bringt viel Lernstoff mit sich
- Gerade wenn man über den „eigenen kleinen Prototypen“ hinaus als Solo-Gründer eine App auf kommerziellem Produktniveau bauen will, halte ich drei Fähigkeiten für unverzichtbar: Wahrnehmungsfähigkeit, Coding-Fähigkeit und Product-Engineering-Fähigkeit
Wahrnehmungsfähigkeit
- Bildschirme oder Funktionen sensibel als solche zu erkennen, die anders arbeiten als im PRD (oder anders als ursprünglich beabsichtigt)
- Fehlt diese Fähigkeit, ist es extrem schwer, Fehler der AI überhaupt zu finden und gezielt Korrekturen einzufordern
- Die „Tests“ aus Schritt 4 reduzieren von vornherein Fehler der AI und helfen zugleich, die eigenen Fähigkeiten zu schärfen.
- Denn beim Lesen, wie die AI Spezifikationen in Testcode übersetzt, lernt man nicht nur „Diese Funktion wird gebraucht“, sondern „Diese Bedingungen müssen erfüllt sein, damit die Implementierung dieser Funktion abgeschlossen ist“
- Allerdings ist „Die App wurde gemäß Spezifikation umgesetzt“ nicht dasselbe wie „Die App ist gut“. Deshalb ist „Product Sense“ wichtig, also das Gespür für Verbesserungen (Details dazu im verlinkten Newsletter von Lenny)
Coding-Fähigkeit
- Zumindest bisher gilt: Egal, wie gut man die Arbeit zerlegt und der AI übergibt, ungefähr 5 % muss man zum Abschluss doch selbst im Code anfassen.
- Weil das nicht gelingt, bleiben auf SNS massenhaft Apps bei etwa 80 % stehen und werden nie veröffentlicht
- Natürlich kann sich dieser Anteil je nach App unterscheiden, und es ist vielleicht nicht unmöglich, bis zum Ende alles nur mit AI umzusetzen – effizient ist das aber nicht
- Statt sich dem Vibe komplett hinzugeben, würde ich empfehlen, beim Blick in die von der AI erzeugten Dokumente (Memory Bank, Testcode usw.) auch das Coding selbst mitzulernen. Und sich ruhig auch Coaching von Entwicklern zu holen
- Besonders lohnend ist es, über den vergleichsweise weniger sichtbaren Backend-Bereich zu lernen (Nutzerauthentifizierung, externe API-Anbindung, Daten-Ein- und -Ausgabe, Payments usw.) sowie über Deployment-Strategien (Main Branch und Feature Branches, Verwaltung von Umgebungsvariablen usw.)
Product-Engineering-Fähigkeit
- Der Launch einer App ist nicht das Ende, sondern der Anfang. Wenn man es richtig machen will, muss man den gesamten Produktentwicklungs-Lifecycle verstehen
- Problemwahrnehmung, Entwicklung von Lösungsansätzen, Planung, Design, Implementierung, Testing, Deployment, Marketing, Error-Monitoring, Feedback-Sammlung, Betrieb ...
- Man muss nicht jeden einzelnen Schritt in aller Tiefe beherrschen, aber zumindest sollte man wissen, welche Arbeiten in der jeweiligen Phase anfallen und welche Keywords dort verwendet werden
- Nur dann kann man Unbekanntes gezielt lernen und einschätzen, welche Fähigkeiten potenzielle Mitstreiter mitbringen, wenn man es allein nicht stemmen kann
Zum Schluss
- Mit Vibe Coding eine App auf kommerziellem Produktniveau zu bauen, ist keineswegs einfach. Aber dass der Einstieg heute so leicht ist wie nie zuvor, lässt sich kaum bestreiten
- Zu sehen, wie Bekannte begeistert reagieren, wenn ihre kleine Idee lebendig wird („Wow, ich programmiere ja wirklich!“), hat auch mich sehr glücklich gemacht
- Ich würde anderen Nicht-Entwicklern, die das hier lesen, empfehlen, diese Gelegenheit zu nutzen und mit Freude selbst zu „Makern“ zu werden
- Wenn man mit der eigenen Domänenexpertise kleine, schnelle und nützliche Tools baut, die ein konkretes Problem hervorragend lösen – mit Vibe Coding –, dann kann man meiner Meinung nach auch im AI-Zeitalter absolut wettbewerbsfähig sein
7 Kommentare
Wow – ich dachte, Vibe Coding sei nur eine Illusion,
aber einen so fachkundig geschriebenen Artikel habe ich seit Langem nicht mehr gesehen.
Ich habe ihn mit viel Spaß gelesen.
Vielen Dank! Ich sehe darin großes Potenzial, haha.
Ah;; jetzt, wo ich es mir noch einmal ansehe, wirkt mein Kommentar etwas seltsam.
Eher als ein Trugbild würde ich sagen: Wir sind einfach noch nicht so weit.
Letztlich hat Vibe Coding seine Grenzen, und ich habe das Gefühl, dass es ohne Entwicklungswissen schwierig ist.
Natürlich denke ich, dass es mit der Weiterentwicklung von AI später sehr viel besser werden wird.
Ich hatte den Eindruck, mein Kommentar könnte so rüberkommen, als würde ich sagen, dass Vibe Coding keinen Sinn hat, deshalb schreibe ich jetzt noch einmal etwas ausführlicher als Antwort.
Ich nutze Vibe Coding selbst auch sehr oft, haha
Ah, nein. Haha, ich habe die von Ihnen angesprochene Nuance auch verstanden.
Deshalb denke ich, wie ich auch im Haupttext geschrieben habe, dass das, was ich unter Vibe Coding verstehe, mit einem bloßen „Klick“ weit entfernt ist und dass Engineers viel Einsatz bringen müssen, wenn man das Niveau erhöhen will.
Ich lese Ihre Beiträge immer sehr gern.
Vielen Dank!
Ich habe auch ein YouTube-Video dazu gemacht, haha https://www.youtube.com/watch?v=ecY5VBpruOA