Wenn ein neues Feature diskutiert wird, endet die Debatte häufig an derselben Stelle: Niemand weiß sicher, ob Nutzerinnen und Nutzer die Idee verstehen und annehmen. Entschieden wird dann auf Basis von Annahmen, Bauchgefühl oder der lautesten Stimme im Raum. Die Rechnung kommt später, wenn Entwicklungszeit in etwas geflossen ist, das im Alltag kaum verwendet wird.

Unter dem Stichwort Vibe Coding hat sich ein Arbeitsmodus etabliert, der an dieser Stelle ansetzt: Software wird nicht Zeile für Zeile geschrieben, sondern in natürlicher Sprache beschrieben, ein KI-Modell erzeugt daraus lauffähigen Code. Für Produktteams ist daran weniger die Technik interessant als die Konsequenz – ein testbarer Prototyp entsteht in einem Zeitrahmen, in dem bisher Wireframes und Präsentationen entstanden sind.

Vom Klickdummy zum funktionierenden Prototyp

Der Unterschied zu klassischen Mockups liegt im Realitätsgrad. Ein Klickdummy zeigt Bildschirme in einer festgelegten Reihenfolge; alles außerhalb dieses Pfads existiert nicht. Ein prompt-generierter Prototyp kann dagegen tatsächlich auf Eingaben reagieren, Zustände halten und Abzweigungen zulassen, die im Skript nicht vorgesehen waren.

Hinzu kommt die optische Nähe zum bestehenden Produkt. Wenn der Prototyp Farben, Typografie und Komponenten der eigenen Anwendung übernimmt, testen Sie nicht die Fremdheit einer generischen Oberfläche mit, sondern die eigentliche Funktion. Rückmeldungen wie „das sieht noch unfertig aus“ verschwinden – und damit ein Störgeräusch, das qualitative Tests regelmäßig verwässert.

Kundenstimmen zuerst ordnen

Vor dem Bauen steht das Sortieren. Support-Tickets, Vertriebsnotizen, Interviewprotokolle und Bewertungen liegen in den meisten Unternehmen bereits vor, nur eben verteilt und unstrukturiert. Sprachmodelle eignen sich gut dafür, solche Textmengen zu bündeln, wiederkehrende Muster sichtbar zu machen und Themencluster vorzuschlagen.

Wichtig ist dabei die Rollenverteilung: Die Maschine liefert einen Vorschlag zur Gliederung, die Bewertung bleibt beim Team. Ein Modell erkennt Häufungen, aber es weiß nicht, welcher Kundenwunsch zur Strategie passt und welcher eine teure Sackgasse wäre. Wer diese Grenze verwischt, tauscht nur eine Annahme gegen eine andere – mit dem Nachteil, dass die neue plausibler klingt.

Ein Ablauf, der sich im Projektalltag hält

  1. Sammeln und verdichten: vorhandene Rückmeldungen zusammenführen und zu wenigen klar formulierten Hypothesen verdichten.
  2. Hypothese zuspitzen: festlegen, welche konkrete Annahme der Prototyp prüfen soll – und welche ausdrücklich nicht.
  3. Prototyp bauen: den relevanten Ausschnitt der Anwendung erzeugen, im eigenen Look, ohne Backend-Vollausbau.
  4. Testen: mit echten Nutzerinnen und Nutzern arbeiten, beobachten statt fragen, ob es gefällt.
  5. Entscheiden: umsetzen, überarbeiten oder verwerfen – und die Entscheidung samt Begründung dokumentieren.

Der fünfte Schritt wird am häufigsten übersprungen. Ein Prototyp, der niemanden zu einer Entscheidung zwingt, ist nur eine aufwendigere Form der Diskussion.

Wo die Methode an Grenzen stößt

Generierter Code aus einem Prompt ist Testmaterial, kein Produktionsstand. Er trifft keine belastbaren Aussagen über Lastverhalten, Datenschutz, Barrierefreiheit oder Wartbarkeit über Jahre hinweg. Wer solche Artefakte unverändert in die Produktivumgebung schiebt, verlagert Aufwand nur nach hinten – in Form von technischer Schuld, die später jemand abtragen muss.

Ebenso heikel ist der Umgang mit Daten. Kundenfeedback enthält regelmäßig personenbezogene Angaben. Bevor solche Texte in ein externes Modell fließen, braucht es eine klare Regelung dazu, welche Dienste eingesetzt werden dürfen, was anonymisiert wird und wo verarbeitet wird.

Und schließlich: Geschwindigkeit verführt. Wenn Prototypen in Stunden entstehen, sinkt die Hemmschwelle, immer neue Varianten zu bauen, statt sich auf eine Frage festzulegen. Der Engpass verschiebt sich vom Bauen zum Auswerten – und wer diesen Teil nicht mitplant, produziert schnell viel Material und wenig Erkenntnis.

Was Entscheiderinnen und Entscheider konkret gewinnen

Der eigentliche Hebel ist nicht das schnellere Bauen, sondern das frühere Verwerfen. Jede Idee, die nach einem halbtägigen Test begründet abgelehnt wird, spart die vollständige Umsetzung, die Abnahme, die Dokumentation und die spätere Pflege. Diese Ersparnis taucht in keinem Reporting auf, weil sie aus nicht entstandenen Kosten besteht – sie ist dennoch real.

Zusätzlich verändert sich die Gesprächsgrundlage zwischen Fachbereich, Management und Entwicklung. Über einen bedienbaren Prototyp lässt sich präziser sprechen als über eine Anforderungsliste, und Missverständnisse fallen auf, solange ihre Korrektur noch billig ist.

Einordnung für Web- und Softwareprojekte

Für laufende Projekte lohnt es sich, prompt-generierte Prototypen als eigene Phase vor der Budgetfreigabe zu verankern, statt sie als Spielerei einzelner Teammitglieder zu behandeln. Dafür braucht es zwei Festlegungen: ein bestehendes Designsystem, damit Prototypen ohne Zusatzaufwand im eigenen Look entstehen, und eine verbindliche Trennlinie zwischen Wegwerf-Code und produktiver Codebasis. Wer beides sauber definiert, beschleunigt Entscheidungen und schützt gleichzeitig die Qualität dessen, was am Ende tatsächlich in Betrieb geht.

Quellen