Mit Vibecoding über Nacht ein Produkt gebaut. Dann kam die Wand.

Warum gerade so viele Teams an genau derselben Stelle ankommen und warum wir diese Entwicklung wahnsinnig spannend finden.

Portrait von Jan Auer

Jan Auer

Senior UX Writer

Inhaltsverzeichnis

Neuerdings fühlt sich Produktentwicklung mühelos an. Sie haben eine Idee für ein neues Feature oder ein ganzes neues Tool, Sie öffnen Ihr AI-Tool, beschreiben, was Sie sich vorstellen und ein paar Stunden später halten Sie einen klickbaren Prototyp in der Hand. Echte Screens, echte Buttons, alles lässt sich anklicken. Es funktioniert. Sie haben gerade etwas erschaffen, ohne ein einziges Mal auf das Design- oder Dev-Team zu warten.

Für uns als UX Agentur war der klickbare Prototyp vor gar nicht mal so langer Zeit ein Key Output.

Mittlerweile wird er immer häufiger zum Input unserer Arbeit.

Wir finden diese Entwicklung wahnsinnig spannend. Was vor ein paar Jahren noch undenkbar war, gehört heute zum Alltag: Menschen ohne Design- oder Coding-Hintergrund bringen ihre Ideen über Nacht auf den Bildschirm. Das verändert, wie Produkte entstehen, und es ist großartig zu sehen.

Dann kommt ein zweiter Moment, der mindestens genauso spannend ist. Sie klicken sich durch Ihr eigenes Werk und merken: Das ist ganz schön voll. Jeder Screen platzt vor Funktionen, und Sie sind sich selbst nicht mehr ganz sicher, was hier eigentlich wohin gehört. Sie schieben Features hin und her, fügen noch etwas hinzu, nehmen woanders etwas weg…

…aber besser wird es nicht so richtig, nur immer wieder anders. Und irgendwann stehen Sie an einer Stelle, an der die AI Ihnen nicht mehr weiterhilft.

Diese Stelle sehen wir gerade immer häufiger. Und sie hat erstaunlich wenig mit der jeweiligen Branche zu tun, denn wir erleben sie bei Startups in ganz unterschiedlichen Feldern. Was sich wiederholt, ist der Punkt im Prozess, an dem so viele gleichzeitig ankommen.

Das neue Muster: erst selbst bauen, dann an die Grenze stoßen

Das typische Bild sieht so aus: Ein Team, das bereits ein oder mehrere Produkte am Markt hat, mit Dev Team im Haus und einem funktionierenden Entwicklungsprozess. Was oft fehlt, ist die dedizierte UX-Kapazität.

Und dann hat jemand (häufig der Gründer und Visionär selbst) eine neue Idee. Statt sie ins Backlog zu legen und auf Designkapazität zu warten, baut er sie selbst. Mit einem AI-Tool, schnell, vielleicht abends am Wochenende auf der Couch, während im Hintergrund der Fernseher läuft. Nicht, weil das Team es nicht könnte, sondern weil es sich richtig gut anfühlt: keine Zeit verlieren, nicht auf andere warten, und dieses Gefühl haben:

„Ich kann das eigentlich selbst!"

Und genau diese Energie mögen wir. Wer früher Wochen gebraucht hätte, um eine Idee überhaupt sichtbar zu machen, hat heute über Nacht etwas Klickbares. Diese Geschwindigkeit ist ein echter Gewinn, und Vibecoding schafft ungeahnte Möglichkeiten.

Der Höhenflug endet nur eben nicht mit einem fertigen Produkt. Dabei handelt es sich jedoch um keine Sackgasse, sondern vielmehr um den Beginn genau der Phase, in der es eigentlich erst richtig interessant wird.

Warum die AI an dieser Stelle pausiert

Vorneweg: Die Grenze ist keine Frage von „besser prompten".

Eine AI ist hervorragend darin, etwas Neues aus dem Nichts zu erzeugen. Genau das macht sie für den ersten Wurf so wertvoll: schnell Ideen testen, schnell etwas Klickbares haben, schnell ein Gefühl für eine Richtung bekommen. Anspruchsvoller wird es, sobald das Neue sich in etwas Bestehendes einfügen soll. Denn diesen Kontext kennt die AI nicht. Sie kennt nicht den ganzen Business-Hintergrund, sie kennt nicht das gewachsene Ökosystem aus Apps, Rollen und Abhängigkeiten, die es im Unternehmen schon gibt. Sie baut isoliert, weil sie gar nicht anders kann.

Und deshalb passiert zweierlei. Erstens wird der Prototyp üppig: Die AI packt großzügig alles rein, was nach „könnte man brauchen" klingt, und zwischen all den Features fällt es schwer zu entscheiden, was wirklich in die erste Iteration gehört. Zweitens bleibt die Nutzerführung auf der Strecke. Ein klickbarer Prototyp ist eben noch keine durchdachte User Experience. Es braucht ein bestimmtes Gespür dafür, wie man Menschen sauber Schritt für Schritt durch eine Aufgabe führt, ohne dass jeder Screen sie erschlägt.

Wer dieses UX Know-How nicht im Haus hat, spürt das spätestens hier. Das ist kein Vorwurf an Vibecoder, sondern schlichtweg der Punkt, an dem AI-Builder an ihre Grenzen kommen und ein bisschen menschliche Erfahrung den Unterschied macht.

Der verständliche Wunsch nach Tempo

Was in dieser Situation fast immer dazukommt, ist der Drang nach Geschwindigkeit. Der Prototyp steht, er funktioniert, er fühlt sich eigentlich schon fast fertig an. Also liegt der nächste Gedanke nahe: In zwei Wochen sollen die Devs loslegen.

Diesen Reflex verstehen wir sehr gut, und wir finden ihn auch sympathisch. Er ist Startup-Energie in Reinform:

Bloß. Keine. Zeit. Verlieren.

Wir würden nur dazu einladen, an dieser einen Stelle kurz innezuhalten. Wenn ein üppiger, isoliert entstandener Prototyp direkt in die Entwicklung wandert, wandern die offenen Fragen gleich mit… und sie später wieder herauszuarbeiten, kostet meist mehr Zeit, als man am Anfang gespart hat.

Es geht überhaupt nicht darum, das Tempo zu drosseln. Es geht um den einen kurzen Moment, bevor man eine Richtung in Code gießt, damit die Geschwindigkeit am Ende auch wirklich etwas Tragfähiges hervorbringt.

Der Übergabe-Punkt, den man leicht übersieht

Es gibt noch eine zweite, sehr praktische Sache, die in der Begeisterung gern untergeht: die Übergabe an die Entwicklung.

Ein klickbarer Prototyp aus einem AI-Tool ist keine Grundlage, mit der ein Engineering-Team direkt arbeiten kann. Theoretisch ließe sich der generierte Code übernehmen, in der Praxis ist er dafür aber selten gemacht. Entwickler brauchen eine ordentliche Grundlage in Form von durchdachten Flows, definierten Komponenten und Edge Cases sowie sauberen Files. In der Regel sind es Figma-Screens, an denen sie sich orientieren können.

Genau dort, wohin der ganze Höhenflug geführt hat, entsteht so ein kleiner Spalt: Auf der einen Seite steht etwas Schnelles, Klickbares. Auf der anderen Seite stehen Entwickler, die etwas anderes brauchen, um sauber loslegen zu können. Die gute Nachricht: für ein erfahrenes UX-Team ist es kein großer Akt, den Spalt zu schließen.

Human in the Loop: wo wir am liebsten dazukommen

Die gute Nachricht ist: Der Prototyp ist alles andere als verschenkt, wenn man ihn als das behandelt, was er ist: ein erster, beeindruckender Entwurf, aber keineswegs das Endprodukt.

Wir setzen in diesen Situationen das Prinzip „Human in the Loop" um: Nachdem die AI Ihnen viel Zeit gespart hat, gehen wir jetzt gemeinsam eine Ebene tiefer und bringen genau das ein, was an dieser Stelle noch fehlt.

Konkret sind das ein paar Schritte. Zuerst schauen wir uns an, was die AI gebaut hat, und sehen uns das klickbare Ergebnis in Ruhe an. Dann nehmen wir nicht alles auf einmal auseinander, sondern suchen den einen Flow heraus, an dem es am meisten brennt. Diesen Flow nehmen wir uns vor:

  • Brauchen wir wirklich all diese Funktionen auf einem Screen?
  • Ist die visuelle Hierarchie verständlich genug und hilft sie den Nutzenden, sich direkt zurechtzufinden – oder braucht es noch eine Menge Gehirnpower, um das Interface zu verstehen?
  • Wo dürfen wir vereinfachen, weil die echte Nutzergruppe ganz andere Voraussetzungen mitbringt, als der Prototyp annimmt?

Und dann machen wir genau das besser, mit dem UX-Wissen, das eine AI nicht hat, und mit dem Blick auf den Kontext, den sie nicht kennen kann.

Das Ergebnis ist ein besserer Flow: eine Nutzerführung, die für die Menschen funktioniert, die das Tool später wirklich benutzen, und die reibungslos von A nach B trägt. Manchmal geht das erstaunlich schnell: mit den vorhandenen Screenshots arbeiten, Dinge weglassen, rasch durchgehen, ob der Flow stimmt. Es muss kein wochenlanges Projekt sein. Aber dieser eine Schritt, einmal mit dem nötigen Know-how und dem vollen Kontext draufzuschauen, ist oft der, der alles zusammenfügt.

Konsistenz entsteht nicht von allein

Ein Punkt, der eng damit zusammenhängt: Wenn ein Unternehmen bereits ein Design-System und etablierte Patterns hat, dann sollte Neues darauf aufbauen. Auch das ist eine kleine Schwäche heutiger AI-Tools. Für etwas komplett Neues sind sie fantastisch. Sobald aber etwas in ein bestehendes Ökosystem passen soll, erfinden sie gern ihr eigenes Zeug und bringen damit Inkonsistenzen mit, die man später wieder einfangen muss.

Inkonsistenz hat fast immer dieselbe Ursache, und sie ist erstaunlich menschlich: Im UX-Fundament ist zu wenig definiert. Sobald Grundlagen fehlen (wie sehen Edge Cases aus? Wie verhält sich diese eine Komponente? Wo steht der Button?), fängt jeder an, eigene Entscheidungen zu treffen: Gründer, Product Manager, Entwickler. Jeder passt hier ein bisschen an, fügt dort ein bisschen hinzu. Und am Ende läuft es zwischen Design und fertigem Produkt auseinander, ohne dass jemand „schuld" wäre. Vorhandenes wiederzuverwenden statt ständig Neues zu erzeugen klingt banal, ist aber einer der unterschätztesten Hebel für Qualität.

Und: ruhig einmal testen

Eine letzte Anregung, die fast zu naheliegend klingt, um sie auszusprechen: Bevor die Entwicklung loslegt, lohnt es sich, das Ganze einmal mit echten Nutzern zu testen. Das muss nicht groß und aufwendig sein. Das Praktische daran liegt sogar auf der Hand, denn der klickbare Prototyp existiert ja schon. Man kann ihn nehmen, eine kleine Schleife drehen und herausfinden, ob die Nutzerführung trägt, bevor sie in Code gegossen wird.

Worum es eigentlich geht

Worum es hier geht, ist nicht eine bestimmte Branche und auch nicht ein bestimmtes Tool. Es geht um eine Stelle im Prozess, an der gerade auffällig viele Teams gleichzeitig ankommen. Sie bauen mit AI etwas, das sich grandios anfühlt – schnell, klickbar, ganz aus eigener Kraft. Und dann stoßen sie an die Grenze dessen, was eine AI ohne Kontext, ohne UX-Tiefe und ohne Blick fürs gewachsene Ökosystem leisten kann.

Das ist kein Rückschlag und die Antwort darauf ist nicht, alles wegzuwerfen und bei null anzufangen. Sie ist aber auch nicht, das Tempo um jeden Preis durchzuziehen. Sie ist, an genau der richtigen Stelle einen Menschen mit dem passenden Know-how dazuzuholen: gemeinsam anschauen, den entscheidenden Flow vereinfachen und das Ergebnis so übergeben, dass die Entwicklung sauber damit weiterarbeiten kann.

Wenn Sie gerade an dieser Wand stehen: Schreiben Sie uns, damit wir sie gemeinsam durchbrechen können.

Fallstudie

Globale Bildung mit dem Design für DAAD's My GUIDE Plattform

Wie wir eine intuitive Plattform geschaffen haben, die internationalen Studenten hilft, sich in deutschen Studiengängen zurechtzufinden.

Mehr lesen

Blogbeiträge

Mehr lesen über UX & Barrierefreiheit

UX Audit vs. Usability Test: Welche Methode löst welches Problem?

Usability KPIs richtig berechnen, benchmarken und interpretieren

Reichen 5 Nutzer? Wie viele Testpersonen ein Usability-Test braucht

Mit Vibecoding über Nacht ein Produkt gebaut. Dann kam die Wand.

UX Audit vs. Usability Test: Welche Methode löst welches Problem?

Usability KPIs richtig berechnen, benchmarken und interpretieren

Mehr Beiträge sehen