Vibe Coding für Designer: Der entscheidende Faktor für den Erfolg

Die häufige Erfahrung ist, dass die ersten zwei Screens verblüffend sind und der zehnte ein Chaos. Das liegt nicht daran, dass das Modell schlechter wird. Es liegt daran, dass im Projekt nichts fixiert wurde, wie das Ergebnis aussehen soll. So wird bei jedem Durchgang neu entschieden – hier ein leicht anderer Abstand, dort ein neues Grau, ein neuer Akzent, weil der letzte „etwas flach aussah“.

Praktiker, die konsistent liefern, beschreiben dieselbe Gewohnheit: Zuerst das Scaffolding skizzieren – Theme, Grid, Typografie, Farben – und erst dann nach Features fragen. Diese Reihenfolge macht den gesamten Unterschied aus, wird aber oft übersprungen, weil Prompting mehr Spaß macht.

1. 1

   Ein Token-Set in das Projekt integrieren

   Benannte Farbrollen für Light- und Dark-Mode, eine Type-Scale, Abstände, Radien. Keine Palette – sondern Rollen, damit die Antwort auf die Frage „Welche Farbe hat ein deaktivierter Button“ existiert, bevor überhaupt eine Komponente eine benötigt. Ein einziger Befehl installiert ein komplettes Set, falls Sie es nicht selbst zusammenstellen möchten: npx shadcn add https://identityforge.io/r/ambient-sage.json.

2. 2

   Eine Regeldatei schreiben, die Dinge verbietet

   Egal, was Ihr Tool liest – .cursor/rules/design.mdc, .devin/rules/design.md oder eine Zeile in CLAUDE.md. Definieren Sie Richtlinien, keinen Geschmack: nur semantische Tokens verwenden, niemals Raw-Hex-Werte, kein zweiter Akzent pro Screen, niemals eine Änderung im Light-Mode ohne das Dark-Mode-Gegenstück veröffentlichen und im Zweifel nachfragen, statt zu erfinden, wenn das System keine Vorgabe macht.

3. 3

   Eine Preview starten, bevor etwas gebaut wird

   Sie sind Designer; Sie prüfen durch Hinsehen. Wenn Sie die Änderung nicht visuell sehen können, prüfen Sie Code – und genau das ist die eine Sache, für die Sie nicht aufgesetzt sind.

4. 4

   Den ersten Commit erstellen

   Vor dem ersten Feature. Dies ist Ihre Baseline, und von hier an ist jeder Prompt rückgängig zu machen. git ist der Undo-Button – der Chat ist es nicht.

Die Regeldatei ist wichtiger, als es scheint, insbesondere die Verbote. Eine Präferenz fügt eine Option hinzu; ein Verbot entfernt alle anderen. „Nutzen Sie unser Grün“ lässt jeden generischen Standard weiterhin zu. „Führen Sie niemals eine Farbe ein, die kein Token ist“ tut dies nicht. Wir haben 299 öffentliche Design-Dokumente analysiert, die genau für diesen Zweck geschrieben wurden: 76 % listeten nur Präferenzen auf – eine präzise Erklärung dafür, warum diese Dokumente ab dem fünften Screen nicht mehr funktionieren.

Das häufigste selbst verursachte Problem ist, zu viel auf einmal zu verlangen. Ein Prompt, der einen Diff von vierzig Dateien erzeugt, ist ein Diff, den niemand liest. Das bedeutet, dass der Drift ungeprüft übernommen wurde und Sie später feststellen: „Warum sieht diese Seite anders aus?“.

• Ein Screen oder eine Komponente pro Durchgang. Prüfen, committen, weitermachen.
• Vor jedem Prompt committen, nicht danach. So ist der letzte gute Zustand immer nur einen Befehl entfernt und Sie müssen nicht entscheiden, ob die letzte Änderung es wert war, behalten zu werden, während Sie gleichzeitig versuchen, sie zu korrigieren.
• Geben Sie an, was nicht verändert werden soll. "Ändern Sie nur diese Komponente" verhindert das vermeintlich hilfreiche Refactoring von drei Dateien, die Sie bereits freigegeben hatten.
• Wenn es schiefläuft: Revert statt Verhandeln. Drei Runden von "Nein, nicht so" führen zu einem geflickten Ergebnis, das zwar die Konversation, aber nicht das Design zufriedenstellt. Kehren Sie zum letzten funktionierenden Commit zurück und fragen Sie mit einem besseren Prompt erneut.

Dies ist die Fähigkeit, die es wert ist, erlernt zu werden – es ist im Grunde eine Design-Review-Kompetenz mit einem git-Hut. Es geht nicht darum, ob der Code gut ist. Es geht darum, vier Dinge zu prüfen, die alle sichtbar sind, ohne eine einzige Zeile Logik verstehen zu müssen.

Diese vier Prüfungen dauern etwa eine Minute pro Diff und fangen die meisten Ursachen für Drift ab. Alles andere – ob das State-Management sinnvoll oder die Query effizient ist – ist in dieser Phase tatsächlich nicht Ihre Aufgabe. Wer so tut, als sei es doch so, führt dazu, dass Designer das Review komplett vermeiden.

• Gefällige Zustimmung. Wenn Sie fragen: "Folgt dies dem Designsystem?", wird Ihnen meistens mit Ja geantwortet. Fragen Sie stattdessen: "Listen Sie jeden Farbwert in dieser Datei auf, der kein Token ist" – eine Frage mit einer überprüfbaren Antwort.
• Hardcoding, um es zum Laufen zu bringen. Ein fest eingetragener Wert anstelle eines Lookups macht den Screen korrekt, aber das System falsch. Das fällt zum ersten Mal auf, wenn Sie ein Token ändern und eine Komponente sich nicht mitbewegt.
• Output flicken statt Ursache beheben. Ein Margin, der hinzugefügt wurde, um ein Layout zu kompensieren, das zwei Komponenten weiter oben falsch war. Jeder Flicken ist klein; der zehnte ist der Grund, warum nichts mehr sicher geändert werden kann.
• Das System während der Aufgabe verbessern. Eine neue Farbe, die "für den Kontrast" eingeführt wurde. Das ist Drift mit einer Rechtfertigung – die am schwersten zu ertappende Art, da die Argumentation schlüssig klingt.
• Den falschen Test bestehen. Es rendert, also funktioniert es. Prüfen Sie den Dark Mode, einen Empty State und einen langen String in einer schmalen Spalte, bevor Sie es glauben.

Weniger als Kurse suggerieren, aber mehr als null. Erfreulicherweise ist die benötigte Menge spezifisch und nicht allgemein.

• Einen Diff lesen. Grün hinzugefügt, Rot entfernt und die vier oben genannten Prüfungen. Ein Nachmittag.
• Basis-git. Commit, Log einsehen, zu einem Commit zurückkehren. Eine halbe Stunde – und es ist die rentabelste halbe Stunde, die Sie investieren können.
• Struktur verstehen. Welche Datei ist das Theme, welche eine Komponente, welche eine Seite. Bitten Sie den Agenten einmal, die Struktur zu erklären – darin ist er gut.
• Einen Fehler lesen. Nicht ihn beheben. Die Fähigkeit, den relevanten Teil zu kopieren, anstatt einen Screenshot des gesamten Terminals zu senden.

Was Sie nicht benötigen, ist das Schreiben von React, das Verständnis von Build-Tooling oder das Management von Dependencies. Genau dafür ist der Agent da. Zeit, die Sie mit dem Erlernen dieser Dinge verbringen, fehlt Ihnen bei der Review-Kompetenz, die Ihnen nichts anderes abnehmen kann.

Vibe Coding ist hervorragend für Prototypen, interne Tools, Marketing-Seiten und den Nachweis, dass eine Interaktion es wert ist, gebaut zu werden. Es ist jedoch riskant an den Grenzen, an denen Fehler nicht visuell sind: Authentifizierung, Zahlungen, alles, was Kundendaten berührt, oder alles mit einer Migration. Diese Fehler erscheinen nicht in der Preview – dem einzigen Review-Kanal, den Sie haben.

Eine nützliche Faustregel: Wenn das schlimmste Ergebnis eines Fehlers ist, dass es schlecht aussieht, dann shippen Sie es und iterieren Sie. Wenn das schlimmste Ergebnis ist, dass die Daten oder das Geld anderer betroffen sind, dann ist es ein Handoff, kein Prompt.