Vibe Design vs. Vibe Coding: Wo sie sich trennen und warum es zählt
Vibe design und vibe coding sind keine Rivalen — sie sind zwei Hälften einer Bewegung, und in der Lücke dazwischen bluten Teams. Hier kommt der echte Unterschied, die beiden Fehlerarten, vor denen dich niemand warnt (die Mockup-Klippe und der Design-Drift), und ein Rahmen dafür, wann du zu welchem greifst.
Die meisten Erklärungen von vibe design vs vibe coding hören bei einer Definition auf: Das eine erzeugt Designs, das andere erzeugt Code, Ende. Das stimmt und ist trotzdem nutzlos. Ich arbeite bei Open Design an der Nahtstelle zwischen beiden — an der Stelle, an der aus einem generierten Design eine laufende Oberfläche werden soll — und ich kann dir sagen: Bei der Definition liegt nicht das Geld. Das Geld liegt in der Lücke dazwischen: dort, wo ein schönes Mockup nie ausgeliefert wird und generierter Code leise von jedem kohärenten Design wegdriftet. Triff die Trennung falsch, und du zahlst jedes Mal in einer dieser beiden Währungen.
Das hier ist also kein weiteres Glossar. Es geht um das, was tatsächlich anders ist, um die beiden Fehlerarten, die niemand auf die Feature-Seite schreibt, und um einen Rahmen dafür, wann du zu welchem greifst. Wenn du zuerst die Definition von ganz unten willst, liefert sie die [what is vibe design](/blog/what-is-vibe-design/)-Einführung.
Der eigentliche Unterschied: gleicher Instinkt, anderes Artefakt
Beide starten aus demselben Instinkt — beschreibe den Vibe (ein Gefühl, eine Richtung, eine Referenz) und lass die KI etwas produzieren, statt jedes Rechteck von Hand zu platzieren oder jedes div von Hand zu tippen. Sie trennen sich an der Frage, was am Ende in deiner Hand liegt:
- Vibe design produziert ein Design — einen Screen, ein Layout, ein Mockup, das du ansiehst und auf das du reagierst. Das Artefakt ist eine Entscheidung: „Ja, diese Richtung."
- Vibe coding produziert Code — ein laufendes Frontend, das du anklicken kannst. Das Artefakt ist ein Lieferergebnis: „Das funktioniert."
Alles andere folgt aus dieser einen Weggabelung. Ein Design ist billig zu ändern und unmöglich auszuliefern. Code wird ausgeliefert und ist teuer umzustylen. Das heißt: Die beiden Werkzeuge scheitern auf exakt entgegengesetzte Weise — und genau das, nicht die Definition, sollte deine Wahl bestimmen.
| Vibe design | Vibe coding | |
|---|---|---|
| Du bekommst | Ein editierbares Design / Mockup | Laufenden Frontend-Code |
| Optimiert für | Richtungen erkunden | Etwas zu produzieren, das läuft |
| Änderungen sind | Billig — es ist ein Bild | Teuer — es ist ein Build |
| So wie es ist auslieferbar? | Nein — muss erst gebaut werden | Ja — aber gestylt, wie das Modell geraten hat |
| Typisches Werkzeug | Visily, Uizard, Figma AI | v0, Lovable, Bolt |
| Scheitert durch | Die Mockup-Klippe | Design-Drift |
Die beiden Fehlerarten, vor denen dich niemand warnt
Die Mockup-Klippe (das Versagen von vibe design). Du generierst in 30 Sekunden etwas Wunderschönes, der Raum nickt, und dann liegt es einfach da — denn ein Mockup ist die Beschreibung einer App, nicht die App. Irgendjemand muss es trotzdem bauen, und je hübscher das Mockup, desto höher die versunkenen Kosten, wenn der Build anders ausfällt. Ich habe denselben „fertigen" Screen öfter in Code neu gebaut, als ich zugeben möchte. Das Mockup fühlte sich wie Fortschritt an; es war ein Schuldschein.
Design-Drift (das Versagen von vibe coding). Das ist der, der Teams überrascht. Bitte ein Code-Generierungs-Tool um Screen nach Screen, und jeder einzelne ist plausibel, aber subtil daneben — hier ein anderer Button-Radius, da ein Grau außerhalb der Palette, Abstände, die fast passen. Es gibt einen Reddit-Thread, der einfach nur sagt „der Design-Drift, den vibe coding erzeugt, ist der Wahnsinn", und das ist das ganze Problem in einer Zeile. Der Code läuft, also sieht es aus, als wäre er ausgeliefert — aber du hast ein Dutzend Beinahe-Treffer angehäuft, die sich nicht zu einem System zusammenfügen. Niemand hat das Design entschieden; das Modell hat es zwölfmal geraten.
Hier kommt der Teil, auf den es ankommt: Diese beiden Fehler haben dieselbe Wurzel. Die Mockup-Klippe und der Design-Drift passieren beide, weil Design und Code keine gemeinsame Quelle der Wahrheit teilen. Das Mockup weiß nicht, wie es gebaut wird; der Code weiß nicht, was das Designsystem sagt. Behebe diese eine Sache, und beide Fehlerarten verschwinden weitgehend.
Wann du zu welchem greifst
Spar dir das „kommt drauf an". Hier ist die Entscheidung, die ich treffen würde:
Greif zu vibe design, wenn das Artefakt eine Entscheidung ist. Du erkundest eine Richtung, du brauchst die Zustimmung der Stakeholder, bevor jemand Code schreibt, es ist noch kein Entwickler im Raum, oder du steckst im chaotischen Zero-to-One, wo es gerade der Sinn der Sache ist, zehn Richtungen wegzuwerfen. Du willst den billigstmöglichen Weg, um Optionen zu sehen und abzulehnen. Liefere es nicht aus — entscheide damit.
Greif zu vibe coding, wenn das Artefakt laufen muss. Der Prototyp braucht echte Interaktion, du bist über die Richtung hinaus und mitten im „bring es zum Laufen", oder der schnellste Weg zum Lernen ist, eine lebende Sache anzuklicken. Geh nur in dem Wissen hinein, dass du dich verpflichtet hast, den Drift zu managen — was heißt, du brauchst ein Designsystem, dem die Generierung tatsächlich folgen kann, nicht bloß Vibes.
Der Test, in welchem du gerade steckst: Frag „lautet die nächste Entscheidung was soll das sein oder funktioniert das?" Das Erste ist vibe design. Das Zweite ist vibe coding. Die meisten Teams greifen zum Werkzeug, das sie mögen, statt zu der Frage, die sie eigentlich beantworten — das ist der Fehler.
Die echte Antwort: mach sie zu einer Schleife
Der Rahmen „design vs coding" ist selbst die Falle. Behandelt man sie als getrennte Schritte, bekommt man eine Übergabe — und Übergaben sind genau dort, wo beide Fehlerarten leben. Die Teams, die nicht bluten, behandeln sie als eine Schleife, und das, was die Schleife schließt, ist langweilig: ein Designsystem, das ein echtes, gemeinsames Artefakt ist, dem beide Hälften gehorchen.
Auf diese Wette ist [Open Design](/) gebaut. Das Designsystem ist keine Figma-Bibliothek, die der Code nicht lesen kann, und kein Styleguide, den das Modell ignoriert — es ist eine portable DESIGN.md-Datei, die sowohl der Design-Schritt als auch der Code-Generierungs-Schritt konsumieren. Generiere ein Design daraus, generiere Code dagegen, und das Mockup kann nicht abstürzen (es zeigt schon auf echten Code) und der Code kann nicht driften (er ist ans System gepinnt). Vibe design und vibe coding hören auf, ein Versus zu sein, und werden [eine einzige Bewegung von der Absicht zum Ausgelieferten](/blog/what-is-vibe-design/). Für die Werkzeuge, die heute auf jeder Seite der Linie leben, habe ich das Feld in [vibe design tools](/blog/vibe-design-tools/) durchgegangen.
FAQ
Was ist der Unterschied zwischen vibe design und vibe coding? Vibe design generiert ein Design, auf das du reagierst; vibe coding generiert laufenden Code, den du benutzen kannst. Derselbe intent-first-Instinkt, anderes Artefakt — eine Entscheidung gegenüber einem Lieferergebnis.
Ist vibe design einfach vibe coding für Designer? Nein. Vibe coding produziert Code (und das Design driftet, sofern kein System es einschränkt); vibe design produziert ein Design (das nie ausgeliefert wird, sofern es niemand baut). Sie sind komplementäre Hälften, nicht dasselbe für unterschiedliche Zielgruppen.
Was sollte ich zuerst lernen? Was auch immer zu deiner nächsten Entscheidung passt: was soll das sein (vibe design) oder funktioniert das (vibe coding). Langfristig liegt der Hebel darin, sie zu verbinden, damit keines allein scheitert.
Ersetzt vibe coding Designer? Es ersetzt das händische Platzieren von Rechtecken, nicht die Entscheidung, was richtig ist. Das Urteil darüber, was existieren soll — und das System, das es kohärent hält — ist genau der Teil, der sich nicht automatisieren lässt. Der Drift ist der Beweis.
Das Fazit
Vibe design und vibe coding sind keine Konkurrenten; sie sind die beiden Enden einer Bewegung, und jedes Team, das sie als getrennte Schritte behandelt, zahlt den Tribut in der Mitte — ein Mockup, das nie ausgeliefert wird, oder eine UI, die driftet. Wähle nach der Frage, die vor dir liegt: entscheiden, was es sein soll, oder es zum Laufen bringen. Und dann tu das, was fast niemand tut — gib beiden Hälften dasselbe Designsystem, dem sie gehorchen, damit der Vibe den ganzen Weg überlebt: von der Absicht bis zum ausgelieferten Code, der dir gehört.