Beispiele für Vibe-Programmierung: 6 praktische Projekte zum Ausprobieren

Einleitung

Vibe-Coding ermöglicht es fast jedem, eine Idee in einfacher Sprache zu beschreiben und eine funktionierende erste Version zu erhalten, wobei Geschwindigkeit Vorrang vor dem aufwendigen Entwicklungsprozess hat, den ein herkömmlicher Build erfordern würde. Zu wissen, wo man tatsächlich anfangen soll, ist jedoch ein anderes Problem, insbesondere für Teams, die es gewohnt sind, ein Ticket einzureichen und auf einen Build zu warten.

Vibe-Coding kann je nachdem, was man herausfinden möchte, in Form eines schnellen visuellen Mockups, eines funktionierenden Prototyps oder eines kleinen Proof-of-Concepts Gestalt annehmen. Dieser Artikel stellt sechs Beispiele vor, die Fachleute ausprobieren können. Es handelt sich um anschauliche Projekte, die jeder umsetzen könnte, nicht um fertige oder kommerzielle Produkte.

6 praktische Beispiele für Vibe-Coding für Geschäftsteams

Der Einsatz von KI-Tools für Vibe-Coding kann auf der Grundlage einfacher Benutzerbeschreibungen schnell ausführbaren Code und App-Komponenten generieren, doch es ist wichtig, sich mit dem Prozess vertraut zu machen, bevor man etwas auf den Weg bringt. Diese sechs Beispiele – die Art von Projekten, auf die man im Arbeitsalltag trifft – reichen von einfachen und visuellen bis hin zu komplexeren, die näher an realen Daten und Workflow-Logik angelehnt sind. Jedes Beispiel beginnt mit dem geschäftlichen Bedarf, führt durch eine Beispielanweisung und eine mögliche erste Ausgabe und endet mit den Punkten, die vor dem weiteren Vorgehen überprüft werden sollten.

1. Eine Landingpage visualisieren, bevor man sie erstellt

Ein Seitenkonzept in etwas umzuwandeln, auf das ein Team reagieren kann, bedeutet in der Regel, auf Entwicklungszeit zu warten, die niemand hat. Vibe Coding umgeht diese Wartezeit. Eine einzige Eingabeaufforderung kann ein funktionsfähiges Layout mit echter Hierarchie und echtem Ablauf generieren und gibt dem Team so etwas Konkretes zur Diskussion, anstatt eines schriftlichen Briefings, das jeder anders interpretiert.

Beispiel-Eingabeaufforderung: „Erstelle eine Landingpage für Kleinunternehmer, die [Produkt] in Betracht ziehen. Füge einen Hero-Bereich mit einer Überschrift und einem CTA, drei Vorteilskarten, einen Bereich mit Kundenstimmen und eine Preisvergleichstabelle ein. Gestalten Sie den CTA-Button so, dass er beim Scrollen des Besuchers an der Seite fixiert bleibt.“

Mögliche erste Ausgabe: Eine einzige funktionsfähige Seite mit echtem Layout und Abständen – auch wenn Text und Bilder nur Platzhalter sind – reicht aus, um auf Hierarchie und Ablauf zu reagieren, noch bevor sie den ersten Nutzer erreicht.

Was als Nächstes zu prüfen ist: Freigegebener Text, Überprüfung der Barrierefreiheit, Markenrichtlinien und die eigentliche Umsetzung folgen noch. Ein anklickbares Mockup gibt Aufschluss darüber, ob die Struktur funktioniert – nicht darüber, ob sie bereits veröffentlichungsreif ist.

2. Testen Sie eine interaktive Produktauswahl

Komplexe Produktpaletten sind schwer zu durchstöbern. Kunden dabei zu helfen, die richtige Option zu finden, bedeutet in der Regel eine lange Liste von Filtern oder viel Rätselraten. Eine Eingabeaufforderung kann innerhalb weniger Minuten einen geführten Quiz-Ablauf erzeugen, der einige Fragen stellt und Kunden zu einer Empfehlung führt, bevor jemand den eigentlichen Katalog aufruft.

Beispiel-Prompt: „Entwickeln Sie eine Web-App zur Produktauswahl, die drei Fragen zu Anwendungsfall, Budget und verfügbarem Platz stellt und anschließend einen von fünf Produkttypen mit einer kurzen Erklärung für jede Empfehlung vorschlägt.“

Mögliche erste Ausgabe: Ein funktionierender Quiz-Ablauf mit vorläufiger Empfehlungslogik – ausreichend, um jeden Pfad durchzuklicken und zu sehen, wohin eine Antwort führt.

Was als Nächstes zu prüfen ist: Hier wird die Interaktion getestet, nicht die Genauigkeit der Empfehlungen. Verwirrende Fragen oder Sackgassen werden schnell sichtbar. Die tatsächlichen Produktdaten, die Empfehlungslogik und die Verfügbarkeit im Bestand müssen noch separat überprüft werden, bevor das Tool auf den Live-Katalog zugreift.

3. Erkunden Sie ein Dashboard mit Beispieldaten

Nicht jede Idee für ein Reporting erfordert eine vollständige Datenpipeline, bevor man weiß, ob das Layout tatsächlich hilfreich ist. Eine Eingabeaufforderung kann ein Dashboard zusammenstellen, das vollständig aus fiktiven Datensätzen besteht – eines, durch das sich die Beteiligten anklicken und auf das sie sofort reagieren können.

Beispiel-Befehl: „Erstelle ein Dashboard mit Beispieldaten für 50 Supportanfragen. Füge Übersichtskarten für die Anzahl offener, in Bearbeitung befindlicher und gelöster Fälle hinzu, einen Filter nach Priorität und zugewiesenem Team sowie eine Tabelle, die die durchschnittliche Bearbeitungszeit nach Kategorie anzeigt.“

Mögliche erste Ausgabe. Ein funktionsfähiges Dashboard, das die Beteiligten sofort filtern und auf das sie reagieren können, wobei fiktive Datensätze anstelle von Daten aus einem Live-System verwendet werden.

Was als Nächstes zu prüfen ist. Ein überzeugendes, auf Beispieldaten basierendes Dashboard lässt noch offen, woher die Live-Daten stammen, ob sie aus einer echten Datenbank gespeist werden, wie oft sie aktualisiert werden oder ob die Zahlen tatsächlich das bedeuten, was die Nutzer annehmen.

4. Prototyp eines Workflows zur Lieferanten-Onboarding

Die Lieferantenanmeldung findet oft über E-Mail-Verläufe, Tabellenkalkulationen und die Erinnerung derjenigen statt, die sich an den letzten Schritt erinnern. Niemand erkennt so recht, wie chaotisch das Ganze ist, bis jemand den Ablauf grafisch darstellt. Eine Eingabeaufforderung kann anklickbare Bildschirme für die Erfassung, die Statusverfolgung und die Genehmigung generieren, sodass Beschaffung und Betrieb den gesamten Prozess zum ersten Mal gemeinsam durchgehen können.

Beispiel für eine Prompt-Anfrage: „Erstellen Sie einen Onboarding-Ablauf für Lieferanten mit einem Einreichungsformular für Unternehmensdaten und erforderliche Dokumente, einer Statusübersicht, die den aktuellen Stand jeder Einreichung anzeigt, sowie einem Genehmigungsbildschirm, auf dem Prüfer einen Antrag mit Kommentaren annehmen oder ablehnen können.“

Mögliche erste Ausgabe. Bildschirme, die Beschaffung und Betrieb gemeinsam durchgehen können, um fehlende Schritte oder unklare Übergaben zu erkennen, bevor sie sich auf etwas Konkretes festlegen.

Was als Nächstes zu prüfen ist. Eine dauerhafte Version erfordert vereinbarte Datenstrukturen, echte Zugriffsregeln für jede Rolle, eine Dokumentenverwaltung, die alle geltenden Compliance-Anforderungen erfüllt, sowie Anbindungen an die Systeme, die bereits Lieferanten und Zahlungen verfolgen.

5. Entwerfen Sie ein Self-Service-Kundenerlebnis

Kunden sollten nicht erst jemanden anrufen müssen, nur um eine Bestellung einzusehen oder eine Kontoeinstellung zu aktualisieren. Der Aufbau einer echten Kontoinfrastruktur, um diese Annahme zu testen, ist im Vorfeld ein großer Aufwand. Eine navigierbare Reihe von Bildschirmen, die auf Beispieldaten basiert, kann die Frage beantworten, ob Nutzer tatsächlich das finden, was sie brauchen – lange bevor diese Infrastruktur existiert.

Beispielaufgabe: „Entwickeln Sie ein Kundenkonto-Erlebnis mit einem Dashboard, das die letzten Bestellungen anzeigt, einer Seite zur Aktualisierung von Kontakt- und Zahlungspräferenzen sowie einem Support-Anfrageformular mit Statusverfolgung, unter Verwendung von fünf Beispielkundenkonten.“

Mögliche erste Ergebnisse: Bildschirme, durch die ein echter Nutzer anhand fiktiver Kontodaten navigieren kann – ausreichend, um zu testen, ob Layout und Beschriftungen tatsächlich sinnvoll sind.

Was als Nächstes zu prüfen ist. Hier wird getestet, ob Kunden Informationen finden und eine Aufgabe ohne Hilfe erledigen können. Die echte Identitätsprüfung, Berechtigungen und Verbindungen zum tatsächlichen Kontosystem sowie alles, was sensible Daten betrifft, sind ein separater Arbeitsbereich, den der Prototyp nicht abdeckt.

6. Eine Integrationsidee mit einem kleinen Proof of Concept prüfen

Selten stimmen zwei Systeme darin überein, wie Daten strukturiert sein sollten. Dies erst mitten in der Integration festzustellen, ist kostspielig. Mit einem Proof of Concept mit engem Umfang kann ein Entwickler eine kleine Funktion erstellen, die Beispieldaten aus einem System in das von einem anderen System erwartete Format umwandelt und so die Frage an einem Nachmittag statt in einer Woche beantwortet.

Beispielaufgabe: „Schreibe anhand dieser Beispiel-JSON-Antwort von [System A] eine Funktion, die diese in die von [System B] erwartete Feldstruktur umwandelt. Behandle fehlende Felder, indem du sie leer lässt, und markiere jedes Feld, das nicht dem erwarteten Typ entspricht.“

Mögliche erste Ausgabe: Eine funktionierende, clientseitige Transformationslogik, die die Beispiel-Eingabe korrekt verarbeitet und anhand einer Handvoll Beispieldatensätze statt über eine Live-Verbindung getestet wurde.

Was als Nächstes zu prüfen ist. Ein erfolgreiches Beispiel sagt nichts darüber aus, wie sich die Live-APIs tatsächlich verhalten, wie Anmeldedaten wie API-Schlüssel gespeichert und rotiert werden, was passiert, wenn eine Anfrage fehlschlägt, oder wer die Zuordnung pflegt, sobald sich die Quellsysteme ändern.

Was können Sie aus dem Ausprobieren von Vibe-Coding-Beispielen lernen?

Jedes dieser Beispiele vermittelt Ihnen etwas anderes, doch die zugrunde liegende Erkenntnis ist dieselbe. Sie finden heraus, ob eine Idee Bestand hat, sobald sie als etwas Reales existiert – und nicht nur als Beschreibung in einer Besprechung. Indem Sie einem KI-Agenten in natürlicher Sprache beschreiben, was Sie wollen, die Rückmeldung überprüfen und weitere Eingaben vornehmen, bis es funktioniert, kommen Sie ans Ziel.

Der wahre Wert geht über die erste Eingabe hinaus. Man sieht die tatsächliche Oberfläche oder das Verhalten, das dabei entsteht. Man lernt auch, was geändert werden muss, sobald jemand darauf reagiert. Manchmal weist diese Reaktion auf das Tool selbst hin. Oft beginnt man mit einem Tool für einen schnellen visuellen Durchlauf und wechselt dann zu etwas wie Cursor oder Claude Code, sobald der zugrunde liegende Code echte Aufmerksamkeit erfordert. Vibe-Coding-Tools und Low-Code-Plattformen verfolgen hier wirklich unterschiedliche Ansätze: Der eine basiert auf Eingabeaufforderungen und Code, der andere auf visueller Konfiguration.

Keines der oben genannten Beispiele ist fertiggestellt oder produktionsreif. Sie sind ein Ausgangspunkt. Was man aus der ersten Version lernt, entscheidet darüber, ob es sich lohnt, sie weiterzuentwickeln.

Wie wählt man ein Vibe-Coding-Projekt zum Ausprobieren aus?

Sechs verschiedene Richtungen bieten eine große Auswahl. Das richtige Projekt hängt davon ab, was du tatsächlich lernen möchtest. Ein paar Fragen helfen dabei, die Auswahl einzugrenzen:

• Was möchtest du lernen? Ein Seitenlayout, ein Benutzerablauf, eine Berichtsansicht, ein Workflow oder eine technische Anbindung erfordern jeweils eine andere Art von Prototyp, da unterschiedliche Aufgaben unterschiedliche Arten von Nachweisen erfordern.
• Kannst du mit Beispieldaten beginnen? Verwende Informationen, anhand derer die Beteiligten die Idee bewerten können, ohne auf echte Geschäftsdaten zugreifen zu müssen, damit das Experiment risikoarm bleibt.
• Wer muss auf das Ergebnis reagieren? Je nachdem, ob das Beispiel für Kunden, Geschäftsakteure, Designer oder Entwickler bestimmt ist, ändert sich, wie „nützlich“ konkret aussieht.
• Was würde das Experiment sinnvoll machen? Identifizieren Sie eine konkrete Entscheidung, zu der es Aufschluss geben soll, beispielsweise ob es sich überhaupt lohnt, einen Workflow weiterzuentwickeln.

Dies soll keine vollständige Sicherheitsüberprüfung sein. Es lohnt sich jedoch, die Sache ernst zu nehmen. Untersuchungen von Veracode haben ergeben, dass 45 % der von KI generierten Code-Beispiele Sicherheitslücken enthalten. Eine schnelle Überprüfung jetzt ist besser als eine kostspielige später.

Was passiert, wenn aus einem Beispiel eine dauerhafte Anwendung wird?

Die Wahl des richtigen Prototyps ist nur die erste Entscheidung. Was danach geschieht, ist genauso wichtig. Manche Prototypen beantworten ihre Fragestellung und können direkt ausgemustert werden. Andere offenbaren einen Workflow, den das Unternehmen tatsächlich weiterhin nutzen möchte.

Nehmen wir das zuvor genannte Beispiel zur Einbindung von Lieferanten. Sobald die Mitarbeiter beginnen, sich regelmäßig darauf zu verlassen, benötigt das Team zuverlässige Aufzeichnungen, klar definierte Berechtigungen, einen echten Genehmigungsprozess, funktionierende Integrationen und jemanden, der künftig die Verantwortung dafür übernimmt. Das sind dieselben Anforderungen, die jeder operative Arbeitsablauf benötigt – unabhängig davon, ob die erste Version von einem der heutigen KI-Modelle geschrieben wurde oder nicht.

Die Low-Code-Funktionen von Liferay DXP können dabei einen Großteil unterstützen. Objekte verarbeiten strukturierte Daten, Formulare übernehmen die Datenerfassung, Workflows regeln die Genehmigungsschritte, und Berechtigungen sowie Integrationen verbinden das Ganze mit den bereits vorhandenen Systemen – praktisch eine Governance-Ebene um das herum, was als schneller Prototyp begann. Spezialisierte Funktionen erfordern möglicherweise weiterhin eine maßgeschneiderte Entwicklung und eine eigene Überprüfung, insbesondere wenn ein Team Funktionen hinzufügen muss, die keine Standardfunktion abdeckt, oder mehr Kontrolle darüber haben möchte, wie sich etwas genau verhält. Es geht nicht darum, dass Liferay DXP den ursprünglichen Prototyp erstellt hat. Es geht darum, die richtige Grundlage zu wählen, sobald ein Prototyp zu etwas wird, auf das sich das Unternehmen tatsächlich stützt.

Beginnen Sie mit der Idee, die Sie testen möchten

Beginnen Sie mit einer eng definierten Fragestellung, nicht mit einer vagen Anfrage, eine App zu entwickeln. KI-Tools bearbeiten Standardcode schnell – was mit ein Grund dafür ist, dass Ihnen das erste Ergebnis, so grob es auch sein mag, sofort eine Grundlage bietet, auf die Sie reagieren und die Sie verfeinern können. Diese Reaktion ist in der Regel nützlicher als der Prototyp selbst. Teilen Sie ihn als kurzen Beitrag, um Feedback zu erhalten, oder behalten Sie ihn für sich – was auch immer Ihnen am schnellsten eine ehrliche Reaktion einbringt.

Der wahre Wert eines Beispiels liegt darin, eine Idee testbar zu machen – unabhängig davon, ob daraus jemals eine dauerhafte Anwendung wird oder nicht. Sollte eines dieser Experimente zu einem Workflow werden, den Ihr Unternehmen betreiben und pflegen muss, erkunden Sie die Low-Code-Funktionen von Liferay DXP, um zu sehen, wie eine geregelte Grundlage aussehen könnte.

Häufig gestellte Fragen zu Beispielen für „Vibe Coding“

Woher stammt der Begriff „Vibe-Coding“?

Der KI-Forscher Andrej Karpathy machte den Begriff im Jahr 2025 bekannt und beschrieb damit eine Methode zur Softwareentwicklung, bei der man von dem ausgeht, was man erreichen möchte, anstatt Code Zeile für Zeile zu schreiben. Der Name hat sich durchgesetzt, weil er treffend beschreibt, wie schnell aus einer Idee eine funktionierende erste Version werden kann.

Was sind einige einfache Beispiele für „Vibe Coding“ für Anfänger?

Ein Mockup einer Landingpage, ein einfacher Taschenrechner, einfache Browsergames oder ein Dashboard mit Beispieldaten sind allesamt gute Ausgangspunkte. Für keines davon sind Programmierkenntnisse erforderlich. Jedes hat ein klar umrissenes Ziel und liefert dir etwas Konkretes, das du überprüfen und verfeinern kannst, anstatt nur einer abstrakten Idee nachzugehen. Beginne mit einer einzelnen Funktion, anstatt gleich eine komplette Anwendung erstellen zu wollen.

Kann man ein internes Business-Tool per „Vibe-Coding“ entwickeln?

Ja, und oft ist es besser, damit anzufangen, da interne Tools eine höhere Toleranz für Ecken und Kanten haben. Ein interner Request-Tracker oder ein Berichts-Dashboard könnten problemlos als Nebenprojekt oder als „Vibe-Coding“-Prototyp beginnen. „Intern“ bedeutet jedoch nicht automatisch ein geringes Risiko, sobald das Tool Unternehmensdaten berührt oder Teil eines regulären Arbeitsablaufs wird. Das Team muss dennoch Zugriffsrechte, Zuverlässigkeit und Zuständigkeiten prüfen, bevor es sich im Tagesgeschäft darauf verlässt. Alle bei der Überprüfung festgestellten Mängel müssen noch behoben werden.

Was sollte eine Vibe-Coding-Anleitung enthalten?

Geben Sie an, wer das Projekt nutzen wird, welche Aufgabe es unterstützen soll, welche Informationen oder Beispieldaten es benötigt und was passieren soll, wenn Nutzer damit interagieren – alles in einfacher Sprache statt in technischen Details. Fügen Sie gegebenenfalls wichtige Regeln oder Randfälle hinzu. Sie können das Ergebnis nach dem Testen der ersten Version jederzeit durch weitere Vorgaben verfeinern.

Sind mit „Vibe“ codierte Beispiele bereit für den Einsatz mit echten Kundendaten?

Nein. Von KI generierter Code erfordert vor der Einführung oft eine professionelle Überprüfung. Ein funktionierender Prototyp bedeutet noch nicht, dass Authentifizierung, Berechtigungen, Datenverarbeitung oder Integrationen für den Kundeneinsatz bereit sind. Beginnen Sie mit synthetischen Daten und führen Sie anschließend eine ordnungsgemäße technische und sicherheitstechnische Überprüfung durch, bevor Sie eine Verbindung zu Live-Datensätzen herstellen.