Vibe-Coding für Anforderungen – geht das?

Wie Prototypen das Refinement retten, bevor es peinlich wird

Ich erinnere mich noch gut an mein erstes Sprint-Review:

Stolz präsentierte ich den Stakeholdern das neue Feature. Dann wurde ich gefragt: „Was passiert, wenn der Export nicht klappt?“

Peinlich. Ich hatte schlicht vergessen, mir über eine Abbruchlogik Gedanken zu machen. Wahrscheinlich wäre das einem erfahrenen Product-Owner nicht passiert – mich als Junior hat es kalt erwischt. Und eigentlich hätte es im Refinement auffallen müssen.

Aber Refinement kostet Zeit. Viel Zeit. Wenn ich einen Designer bitte, einen Wireframe zu erstellen, hat das Konsequenzen. Ihm steht dann weniger Zeit für die Feinabstimmung des Designs des Features zur Verfügung, das sich gerade in der Entwicklung befindet.

Was wäre also, wenn man die Anforderungen trotzdem verbessern könnte – ohne Designer, Entwickler oder Tester als Sparringspartner ins Boot holen zu müssen?

Der typische Ablauf der Entwicklung – und sein Problem

In den meisten Teams läuft die Feature-Entwicklung ungefähr so ab:

1. Anforderungen aufnehmen und beschreiben

2. Lösung entwerfen und dokumentieren

3. Design entwerfen und abstimmen

4. Anforderungsreview: Definition of Ready prüfen

5. Feature implementieren und im Sprint testen

6. Feature freigeben, wenn die Definition of Done erfüllt ist

7. Launch

Das Problem: Der Prozess verläuft schrittweise. Lücken in den Anforderungen fallen häufig erst beim Anforderungsreview auf.

Besser wäre ein schnellerer, iterativer Zyklus:

• Schritt 1: Anforderungen beschreiben

• Schritt 2: Prototyp erstellen

• Schritt 3: Ausprobieren und Anforderungen anpassen

Der entscheidende Unterschied: Eine funktionierende Version deckt Lücken in deinem Denken auf – die ein Dokument niemals finden wird.

Kennst du dieses Gefühl im Refinement, wenn die Fragen kommen?

• „Ich verstehe Anforderung 5 nicht.“

• „Sollten wir Screen X nicht ans Ende setzen?“

• „Habt ihr auch an den Fall gedacht, dass der Nutzer das ohne Berechtigung aufruft?“

Mit diesem Vorgehen ersparst du dir genau diese Momente – oder zumindest die meisten davon. Ich nenne es „Vibe-Coding von Anforderungen“.

Lass uns das jetzt Schritt für Schritt ansehen.

Schritt #1: Anforderungen beschreiben

Für die Dokumentation der Anforderungen haben sich für mich bisher zwei Formate bewährt:

• Ein „Product Requirements Document (PRD)“: Es definiert Zweck, Funktionen und das Verhalten eines neuen Produkts oder Features.

• Eine User-Story-Map ist eine visuelle, zweidimensionale Methode aus der agilen Produktentwicklung, die Anforderungen konsequent aus der Nutzerperspektive darstellt.

Als Beispiel habe ich sevdesk gewählt. Eine Software zur Buchhaltung, die ich in den letzten Jahren genutzt habe. Was mich stört: Ich kann den Versand von Rechnungen nicht terminieren. Deshalb fände ich eine Funktion zum terminierten Rechnungsversand hilfreich. Hier das PRD zum Feature.

Prd Sevdesk Terminisierter Versand

93.9KB ∙ PDF file

Download

Download

Egal, für welches Format du dich entscheidest: Schreib es selbst. Nicht generieren lassen. Selbst schreiben. Warum?

Sonst wirst du Opfer der „Illusion von Kompetenz“.

In der Studie „How AI Impacts Skill Formation“ aus dem Januar 2026 wurden 52 hauptsächlich Junior-Entwickler, die mindestens ein Jahr mit Python gearbeitet hatten, zufällig in zwei Gruppen aufgeteilt: Eine hatte Zugang zu einem KI-Assistenten, die andere arbeitete nur mit Dokumentation und Websuche. Beide Gruppen lösten zwei Programmieraufgaben mit der Trio-Bibliothek so schnell wie möglich. Die Gruppe ohne KI schnitt im Abschlusstest 17 % besser ab. Die Entwickler verstanden die Konzepte besser, weil sie sich durch die Arbeit durchgekämpft hatten und die Inhalte wirklich verinnerlichen mussten.

Und hier eine interessante Nuance:

Diejenigen, die die KI nicht für sich die Arbeit erledigen ließen, sondern sie fragend und erkundend nutzten, schnitten im Abschlusstest gut ab. Der Schlüssel war das aktive Auseinandersetzen mit dem Stoff. Fehler zu machen und sich damit auseinanderzusetzen, zwingt dazu, über Code nachzudenken. Dieses „schmerzhafte Feststecken“ ist offenbar entscheidend für echten Kompetenzaufbau.

Also: selbst schreiben, nicht generieren.

Schritt #2: Prototyp erstellen

Du hast deine Anforderungen als Dokument.

Jetzt kommt der spannende Teil: Wir bauen einen Prototyp, um die Anforderungen auf Fehler und Lücken zu prüfen.

Dafür eignet sich Google AI Studio hervorragend – eine browserbasierte Prototyping-Plattform von Google mit kostenlosem Zugang zu den neuesten Gemini-Modellen. Das Beste: Programmierkenntnisse sind nicht nötig.

Nach dem Login sieht es so aus:

Du könntest unterschiedliche Anwendungsfälle ergründen oder ein Modell wählen. Wir wollen direkt etwas bauen.

Was du hierzu brauchst:

• Dein PRD oder deine User-Story-Map

• Einen Screenshot oder ein Bild deines bestehenden Produkts

• Einen Prompt

Das Bild ist dabei die entscheidende Zutat.

Es macht den Prototyp realistisch und hilft dir, dich wirklich in die Nutzung des neuen Features hineinzuversetzen – statt sie nur abstrakt zu beschreiben.

Hier mein Prompt:

# Aufgabe

Ich habe dir eine User-Story-Map für das sevdesk-Feature **„Terminierter Rechnungsversand“** beigefügt.

Außerdem hänge ich zwei Screenshots an:

- die aktuelle **Rechnungsübersicht**
- den Dialog **„Dokument versenden“**

Ich möchte **UJ-1: Versand terminieren** aus dem PRD prototypisch umsetzen.

# Ziel

Erstelle einen **klickbaren Prototyp** für diesen Flow.
Nutze den visuellen Stil der beigefügten Screenshots als Grundlage, insbesondere:

- Farben
- Typografie
- Sidebar-Layout
- Abstände
- allgemeine UI-Struktur

Der Prototyp soll sich visuell eng an sevdesk orientieren.

# Umfang

Baue **vorerst nur den Flow für UJ-1**.
Berücksichtige **noch nicht**:

- UJ-3: Bearbeitung eines terminierten Versands
- UJ-4: Fehlerszenarien

## Gewünschter Flow

1. Starte im Dialog **„Dokument versenden“**.
2. Füge in der Versand-Sidebar unter den bestehenden E-Mail-Optionen die neue Schaltfläche **„Versand terminieren“** ein.
3. Beim Klick auf **„Versand terminieren“** öffnet sich eine Eingabe für **Datum und Uhrzeit**.
4. Nach Auswahl von Datum und Uhrzeit und Klick auf **„Versand planen“** erscheint eine Toastmeldung mit dem Text:
**„Rechnung wird am [Datum] um [Uhrzeit] versendet.“**
5. Anschließend erfolgt die Rückleitung zur **Rechnungsübersicht**.
6. Dort trägt die entsprechende Rechnung den neuen **blauen Status-Badge „Geplant“**.

## Einschränkungen
- Baue nur den Happy Path für **UJ-1**.
- Berücksichtige **nicht**:
- UJ-3 Bearbeitung
- UJ-4 Fehlerszenarien

## Erwartung

- Der Prototyp soll nur diesen einen Happy Path abbilden.
- Es reicht, wenn nur die für diesen Flow relevanten Interaktionen klickbar sind.
- Bitte fokussiere dich auf eine realistische, produktnahe Darstellung.
- Verwende die bestehenden Screenshots und das PRD als maßgebliche Referenz für Inhalte.

Schritt #3: Ausprobieren und Anforderungen anpassen

Hast du etwas Klickbares erstellt?

Dann gehe jeden Flow durch. Irgendetwas wird sich seltsam anfühlen – garantiert.

Bei meinem Prototyp fiel mir als Erstes auf, dass ich zwar geschrieben hatte: „Nach Klick öffnet sich ein Date-&-Time-Picker“, das Interaktionsmuster dabei aber komplett offengelassen hatte. Öffnet er sich als Modal? Als Dropdown? Inline?

Eine präzisere Formulierung wäre:

„Der Picker öffnet sich inline innerhalb der Versand-Sidebar (kein separates Modal), direkt unterhalb der Schaltfläche ‚Versand terminieren‘.“

Das klingt nach einem kleinen Detail – aber genau solche Details führen später zu langen Diskussionen im Refinement oder zu Nacharbeiten in der Entwicklung.

Natürlich ist das nur ein Detail.

Aber es gibt auch echte Lücken: Ein fehlgeschlagener Versand wurde laut meinem PRD nur als In-App-Benachrichtigung angezeigt. Doch sollte der Nutzer nicht eher eine E-Mail erhalten, da er ja wahrscheinlich nicht in der App ist?

Ein klassischer Fall, der im Dokument vielleicht unsichtbar bleibt – im Prototyp aber sofort auffällt.

Und jetzt sind wir im Kreislauf angekommen:

• zurück zum PRD oder User Story Map und überarbeiten,

• dann den Prototyp updaten und

• noch mal ausprobieren.

Vibe-Coding von Anforderungen ermöglicht genau diesen schnelleren, iterativen Zyklus. Noch bevor Entwickler, Tester oder Designer die Anforderungen zum ersten Mal zu sehen bekommen, sind bereits viele kleine Fehler oder Ungenauigkeiten behoben.

Vor zwei Jahren wäre das noch undenkbar gewesen.

Häufige Fragen zum Vorgehen

Wenn ich mein Vorgehen bisher vorgestellt habe, wurde ich immer gefragt:

• Welches Tool? Bisher habe ich fürs Vibe-Coding meist Lovable oder Bolt.new verwendet. Allerdings bin ich dort schnell ans Tokenlimit gestoßen, deshalb nutze ich Google AI Studio.

• Funktioneller Prototyp oder Design-Prototyp? Es geht mir darum, die Funktion auszuprobieren, nicht das Design zu gestalten. Hierfür würden sich Figma AI oder Google Stitch eher anbieten.

• PRD oder User-Story-Map? Das hat mich selbst überrascht. Ich dachte, die KI braucht viel Kontext in Form von Text, um brauchbare Resultate zu erzielen. Aber ich konnte keinen Unterschied feststellen, ob ich ein PRD oder eine User-Story-Map als Input genutzt habe.

• Warum sevdesk? Die Idee mit dem Vibe-Coding von Anforderungen habe ich letzten Herbst bei einem Kunden im Coaching entwickelt – und seitdem für meinem PSPO-AI-Training verfeinert. Hier wollte ich nur ein einfaches Beispiel nutzen, um mein Vorgehen von damals zu zeigen.

Mein Appell

Wir bauen hier nichts, das direkt an Nutzer ausgeliefert wird. Oder was einem Prototyp für Product-Discovery entspricht.

Wir vibe-coden einen Prototyp, der uns hilft, besser zu denken – bevor wir unsere Idee im Refinement vorstellen.

Eine funktionierende Version deckt Lücken in deinem Denken auf, die ein Dokument niemals finden wird.

Bis zum nächsten Mal!

Scrum on (mit KI)

Simon

P.S. War der Artikel hilfreich? Dann unterstütze meine Arbeit und teile ihn mit jedem, der Hilfe beim Refinement sucht.