Vibe Coding im UX-Design – Warum Designer:innen und Researcher:innen trotzdem unverzichtbar bleiben

Entwicklungszyklen, die sich über Monate ziehen. Prototypen, die zu spät kommen, um wirklich nützlich zu sein. Budgets, die in endlosen Iterationsschleifen versickern. Viele Unternehmen kennen diese Probleme. Vibe Coding verspricht eine Lösung: AI-gestützte Prototypen, die in Stunden entstehen und direkt testbar sind. Der Begriff wurde 2025 von AI-Forscher Andrej Karpathy geprägt und beschreibt einen Workflow, bei dem Teams ihre Absicht in natürlicher Sprache formulieren die KI generiert daraus funktionsfähigen Code.

Für UX-Teams klingt das verlockend. Doch was bedeutet Vibe Coding konkret für den Design-Alltag? Wann ist es sinnvoll, wann nicht? Und vor allem: Ersetzt es Designer:innen und Researcher:innen oder macht es ihre Arbeit erst richtig wirksam?

‍

Was ist Vibe Coding und was nicht?

Vibe Coding ist kein Werkzeug, sondern ein Workflow. UX-Designer:innen beschreiben eine Interaktion in natürlicher Sprache. Ein AI-Tool generiert daraus funktionsfähigen Code. Dieser läuft direkt im Browser und kann in Usability Testing eingesetzt werden.

Der klassische UX-Prozess sieht so aus: Research → Wireframes → Mockups → Entwicklung → Testen.
Mit Vibe Coding verkürzt sich das: Research → Prompt → Prototyp → Testen.
Die Iteration findet im Browser statt, nicht in Figma. Nutzer:innen interagieren mit echten Flows, nicht mit statischen Screens.

Das ändert die Qualität der Erkenntnisse. Ein klickbarer Prototyp zeigt, ob eine Navigation intuitiv ist. Ein statischer Screen zeigt nur, ob ein Layout visuell funktioniert. Gerade bei komplexen Workflows ist dieser Unterschied entscheidend.

Wichtig: Vibe Coding ist kein Ersatz für strukturierte UX-Arbeit. Es beschleunigt die Phase zwischen Hypothese und Test. Wer nicht weiß, was getestet werden soll, gewinnt durch schnelle Prototypen nichts.

‍

Wie Vibe Coding unseren Design-Alltag verändert

Vibe Coding verändert konkret drei Bereiche im UX-Alltag: Geschwindigkeit, Testqualität und Stakeholder-Kommunikation.

Geschwindigkeit: Ein Prototyp, der klassisch zwei bis drei Entwickler:innen-Wochen benötigt, entsteht mit Vibe Coding in ein bis zwei Tagen. Das ermöglicht mehrere Iterationen pro Woche statt pro Monat. Teams können schneller auf Feedback reagieren und Hypothesen früher validieren.

Testqualität: Usability Testing mit Vibe Coding unterscheidet sich von klassischem Testing. Der Prototyp ist keine simulierte Interaktion in Figma, sondern eine echte Web-App. Nutzer:innen können Formulare ausfüllen, Daten eingeben, Fehler produzieren. Das erhöht die Validität der Test-Ergebnisse.
Ein Vibe-Coding-Workflow: Hypothese formulieren z.B.:„Nutzer:innen verstehen den neuen Filter-Flow nicht" → Prototyp mit AI generieren → fünf bis zehn Nutzer:innen testen lassen → Probleme identifizieren → Prototyp anpassen → erneut testen.
Dieser Zyklus kann mehrfach am Tag durchlaufen werden.

Stakeholder-Kommunikation: Funktionale Prototypen überzeugen besser als Mockups. Entscheider:innen können selbst durch einen Flow klicken, statt sich vorzustellen, wie er funktionieren könnte. Das reduziert späte Kurswechsel und erleichtert interne Abstimmungen.

Kritisch bleibt: Vibe Coding verführt dazu, zu schnell zu testen. Wenn die Hypothese unklar ist, bringt auch ein schneller Prototyp nichts. UX-Research braucht strategisches Denken. Vibe Coding beschleunigt die Umsetzung, ersetzt aber nicht die Analyse.

‍

Wann Vibe Coding sinnvoll ist und wann nicht

Vibe Coding ist kein Allheilmittel. Es eignet sich für bestimmte Phasen, nicht für alle. Die Stärken liegen in der frühen Konzeptphase und in schnellen Iterationen. Die Schwächen zeigen sich bei komplexen Systemen, hohen Security-Anforderungen und skalierbarer Architektur.

Wo Vibe Coding hilft

Frühe Validierung: Neue Features oder Flows können in Stunden getestet werden, bevor große Entwicklungsbudgets gebunden werden. Das reduziert das Risiko, Features zu bauen, die niemand braucht.

UX-Research Prototyping: Echte Interaktionen liefern bessere Insights als Klick-Dummies. Nutzer:innen können Formulare ausfüllen, Fehler produzieren, echte Aufgaben erledigen. Das zeigt, wo sie stocken und wo Probleme entstehen.

Stakeholder-Demos: Funktionale Prototypen überzeugen Entscheider:innen besser als statische Screens. Sie können selbst erleben, wie ein Feature funktioniert.

Paralleles Experimentieren: Mehrere Varianten eines Features können gleichzeitig getestet werden, ohne Entwickler:innen zu blockieren.

Interne Tools: Dashboards, Admin-Panels oder Konfiguratoren, die nur intern genutzt werden, können mit Vibe Coding schnell gebaut werden.

Wo Vibe Coding an Grenzen stößt

Produktions-Code: AI-generierter Code ist oft nicht skalierbar, nicht sicher und nicht wartbar. AI-generierter Code enthält noch häufig Security-Schwachstellen. Prototypen sollten daher nicht mit echten Nutzer:innendaten betrieben werden.

Barrierefreiheit: WCAG-Standards werden nicht automatisch eingehalten. Semantisches HTML fehlt oft. ARIA-Labels werden vergessen. Keyboard-Navigation funktioniert nicht. Das ist ein Problem für Unternehmen, die gesetzlich verpflichtet sind, barrierefreie Produkte zu liefern. In der EU gilt seit 2025 der European Accessibility Act. Wer Usability Testing ernst nimmt, braucht barrierefreie Prototypen. Aktuell liefert Vibe Coding das nicht automatisch.

Regulierte Systeme: In MedTech oder FinTech muss jede Zeile Code nachvollziehbar und validiert sein. Vibe Coding erschwert das.

Komplexe Architektur: Systeme mit vielen Abhängigkeiten, APIs und Datenmodellen überfordern AI-Tools.

Performance-kritische Anwendungen: AI-generierter Code ist selten optimiert.

‍

Warum Designer:innen und Researcher:innen trotzdem unverzichtbar bleiben

Vibe Coding beschleunigt Prototyping. Doch es ersetzt keine Design-Kompetenz. Die Vorstellung, Product Owner:innen könnten Prototypen selbst erstellen und Designer:innen würden überflüssig, greift zu kurz.

Research bleibt essenziell. Vibe Coding testet Hypothesen. Doch woher kommen diese Hypothesen? Aus strukturierter UX-Research. Wer nicht weiß, was getestet werden soll, gewinnt durch schnelle Prototypen nichts. UX-Researcher:innen erforschen Bedürfnisse und Nutzungskontexte, sowohl qualitativ als auch quantitativ. Sie liefern die Grundlage für alle Designentscheidungen.

Prompts schreiben erfordert Fachkompetenz. Ein schlechter Prompt führt zu schlechtem Code. Ein guter Prompt beschreibt das Ziel klar, gibt Kontext und definiert Randbedingungen. Das ist eine Fähigkeit, die trainiert werden muss. UX-Designer:innen, die Vibe Coding nutzen wollen, brauchen ein Grundverständnis von Code-Struktur. Nicht, um zu programmieren, sondern um zu verstehen, was AI generiert.

Code-Qualität muss bewertet werden. Ist der Prototyp barrierefrei? Sicher? Nutzbar? Diese Fragen können nur UX-Designer:innen und Usability Engineers beantworten. Vibe Coding produziert Code, der oft nicht production-ready ist. Security-Lücken, fehlende Barrierefreiheit, technische Schulden – all das muss später behoben werden.

Die Rolle verschiebt sich, verschwindet aber nicht. Designer:innen werden nicht zu Mockup-Ersteller:innen, sondern zu Prototyp-Dirigent:innen. Sie formulieren Anforderungen, bewerten Ergebnisse, iterieren. Das erfordert mehr Kompetenz, nicht weniger.

Wer Tools wie Vibe Coding richtig einsetzt, kombiniert sie mit strukturierter Research-Methodik: Jobs-to-be-Done, User Story Mapping, Contextual Inquiry. Der Prototyp ist das Mittel, nicht das Ziel.

‍

Was Unternehmen beachten sollten, bevor sie Vibe Coding einsetzen

Für Entscheider:innen stellt sich die Frage: Sollen wir Vibe Coding einsetzen? Die Antwort hängt von drei Faktoren ab: Ziel, Reifegrad und Governance.

Ziel: Wenn das Ziel ist, schneller zu validieren und früher Feedback zu bekommen, ist Vibe Coding sinnvoll. Wenn das Ziel ist, Entwicklungskosten zu sparen, indem AI-Code direkt in Produktion geht, ist es riskant.

Reifegrad: Teams, die bereits strukturierte UX-Prozesse haben, profitieren am meisten. Wer keine klare Research-Strategie hat, wird auch mit schnellen Prototypen keine besseren Produkte bauen. Vibe Coding ist ein Beschleuniger, kein Ersatz für Kompetenz.

Governance: Unternehmen müssen klären, wie mit AI-generiertem Code umgegangen wird. Wird er nur für Tests genutzt? Oder fließt er in Produktion? Wenn ja, wer haftet für Security-Lücken? Wer dokumentiert den Code? Ohne klare Governance entsteht Shadow IT 2.0: Viele kleine, unkontrollierte Tools, die langfristig mehr Probleme schaffen als lösen.

‍

Best Practices für den Einsatz

Klare Rollenverteilung: Designer:innen erstellen Prototypen, Entwickler:innen schreiben Produktions-Code. Keine Vermischung.

Prototyp = Wegwerf-Code: Jeder Prototyp hat ein Ablaufdatum. Nach dem Test wird er archiviert, nicht weiterentwickelt.

Strukturierte Prompts: Teams nutzen Templates für Prompts. Beispiel: „Erstelle einen Filter-Flow für B2B-Kund:innen. Nutzer:innen können nach Branche, Region und Unternehmensgröße filtern. Ergebnisse werden als Tabelle angezeigt. Mobile-first, Tailwind CSS."

Testing mit echten Nutzer:innen: Prototypen werden nicht intern bewertet, sondern mit fünf bis zehn echten Nutzer:innen getestet. Interne Meinungen zählen nicht.

Dokumentation: Jeder Prototyp wird dokumentiert: Was wurde getestet? Welche Hypothese? Welche Ergebnisse? Diese Dokumentation fließt in die finale Entwicklung ein.

Security-Check: Auch wenn Prototypen nicht in Produktion gehen, ein grundlegender Security-Check sollte stattfinden. Keine Passwörter im Code, keine offenen APIs.

Iteration: Prototypen werden mehrfach iteriert. Der erste Wurf ist selten gut. Zwei bis drei Iterationen sind normal.

Diese Praktiken stellen sicher, dass Vibe Coding Mehrwert bringt, ohne langfristige Risiken zu schaffen.

‍

Fazit

Vibe Coding verändert, wie UX-Teams Prototypen erstellen und validieren. Die Geschwindigkeit, mit der funktionale Prototypen entstehen, ermöglicht frühere, häufigere Tests. Das reduziert das Risiko, Features zu bauen, die niemand braucht.

Gleichzeitig ist Vibe Coding kein Ersatz für strukturierte UX-Arbeit. Es beschleunigt Prototyping, ersetzt aber nicht Research, Analyse oder strategisches Denken. Teams, die Vibe Coding richtig einsetzen, trennen klar zwischen Validierungs-Prototypen und Produktions-Code. Prototypen werden weggeworfen, nachdem sie ihren Zweck erfüllt haben.

Für Entscheider:innen bedeutet das: Vibe Coding ist ein Werkzeug, kein Wundermittel. Es funktioniert, wenn klare Governance existiert, Teams geschult sind und der Einsatzzweck definiert ist. Wer diese Bedingungen erfüllt, kann Time-to-Market verkürzen und Produktqualität erhöhen. Wer blind auf AI-generierte Prototypen setzt, riskiert langfristig höhere Kosten durch technische Schulden und Security-Probleme.

Designer:innen und Researcher:innen bleiben unverzichtbar. Ihre Rolle verschiebt sich von Mockup-Ersteller:innen zu Prototyp-Dirigent:innen. Das erfordert mehr Kompetenz, nicht weniger.

‍