Design Drift: Warum Ihre Vibe-coded App ab dem fünften Screen auseinanderfällt

Drift bedeutet nicht, dass der Agent Anweisungen ignoriert, und es ist auch kein Qualitätsproblem eines einzelnen Screens. Jeder Screen ist für sich genommen meist in Ordnung. Das Versagen ist *relational*: Screen acht widerspricht Screen eins bei Werten, die eigentlich konstant sein müssten.

Diese Unterscheidung ist entscheidend für die Lösung. Ein Qualitätsproblem wird durch bessere Anleitung behoben. Ein Konsistenzproblem wird durch dauerhafte Werte gelöst: Kein noch so ausgeprägtes Gespür führt dazu, dass zwei unabhängige Entscheidungen beim exakt gleichen Hex-Code landen.

An der Zahl Fünf ist nichts Magisches; die eigentliche Variable ist die Länge der Konversation, nicht die Anzahl der Screens. Lange Sessions erzeugen einen langen Kontext, und der Styling-Absatz vom Anfang muss mit allem konkurrieren, was seitdem gefolgt ist.

Was degradiert, ist spezifisch und vorhersehbar. Präzise Werte verschwinden zuerst, da sie willkürliche Zeichenfolgen ohne semantischen Anker sind: oklch(0.55 0.19 45) ist weitaus schwerer zu behalten als *warmes Orange*. Der Agent behält also das Adjektiv, verwirft den Wert und leitet ein „warmes Orange“ neu ab, wenn er es das nächste Mal benötigt. Dieser neue Wert wird dann zur Referenz für den folgenden Screen.

1. Abstände und Radien driften zuerst. Niemand benennt sie explizit im Briefing, daher werden sie jedes Mal komplett neu abgeleitet.
2. Die Typografie-Skala folgt als Nächstes. Die Basisgröße überlebt meist; das Verhältnis zwischen den Stufen hingegen nicht.
3. Die Akzentfarbe driftet zuletzt. Sie wird normalerweise im Briefing erwähnt, was sie verankert. Deshalb unterschätzen viele den Drift, wenn sie nur die Farben prüfen.
4. Layout-Konventionen driften kaum, weshalb die App immer noch kohärent wirkt, während die Details bereits divergieren.

Drift ist unter den UI-Beschwerden ungewöhnlich, da er simpel zählbar ist. Wählen Sie Werte aus, die invariant sein sollten, prüfen Sie diese auf dem ersten und dem neuesten Screen und zählen Sie die Abweichungen.

1. 1

   Invarianten festlegen

   Sechs Werte genügen: Primärfarbe, Seitenhintergrund, Basis-Schriftgröße, Verhältnis der Typografie-Skala, Kartenradius und der Standardabstand zwischen einem Label und seinem Steuerelement.

2. 2

   Ersten Screen prüfen

   Verwenden Sie berechnete Styles (computed styles) statt des Quellcodes, um zu erfassen, was nach der Kaskade tatsächlich gerendert wird.

   Copy

   getComputedStyle(document.querySelector('[data-primary-action]')).backgroundColor

3. 3

   Neuesten Screen prüfen

   Die gleichen sechs Werte, auf die gleiche Weise.

4. 4

   Abweichungen zählen

   Diese Anzahl von sechs ist Ihr Drift-Score. Null bedeutet, dass die Werte aus einer dauerhaften Quelle stammen; vier oder mehr bedeuten, dass sie pro Screen neu entschieden werden.

5. 5

   Wiederholung auf einem mittleren Screen

   Dies gibt Aufschluss darüber, ob der Drift graduell erfolgt oder an einem bestimmten Punkt auftrat – meist durch einen Tool-Wechsel oder eine lange Pause zwischen den Sessions.

• Die Palette alle paar Prompts neu definieren. Funktioniert, aber man wird selbst zum Speicher – und man vergisst Dinge schneller als der Agent.
• Ein einziger, sehr langer System-Prompt. Hilft anfangs, trägt dann aber zum Kontextdruck bei, der das Problem überhaupt erst verursacht.
• Den Agenten bitten, sich an einem bestehenden Screen zu orientieren. Der Agent muss Werte aus einem Markup ableiten, das möglicherweise nicht im Kontext liegt; diese Ableitung führt zu eigenen Fehlern.
• Refactoring am Ende. Die teuerste Option: Man bezahlt erst für den Aufbau von Inkonsistenzen und dann erneut für deren Beseitigung.

Alle vier Ansätze folgen demselben Muster. Sie versuchen, Werte innerhalb der Konversation aufrechtzuerhalten – doch Konversationen sind genau das, was zerfällt.

Invarianten aus der Konversation in das Repository auslagern: semantische Tokens plus eine DESIGN.md. Der Agent liest diese zu Beginn jeder Session, sodass Screen zwanzig denselben Wert für --primary auflöst wie Screen eins, anstatt nur einen ähnlichen Farbton zu wählen.

Semantische Benennung leistet hier echte Arbeit, die über reine Ordnung hinausgeht. --primary und --muted-foreground beschreiben Rollen, sodass der Agent sie auch in unvorhergesehenen Situationen korrekt anwenden kann. Ein roher Hex-Wert muss sich gemerkt *und* korrekt platziert werden; eine Rolle muss nur nachgeschlagen werden. Das ist das Argument für eine semantische Token-Ebene anstelle einer bloßen Palette.

1. 1

   Contract installieren

   Copy

   npx --yes identityforge@latest install --client claude-code

2. 2

   Kit anwenden

   Schreibt die DESIGN.md sowie Light- und Dark-Tokens in das Repo.

   Copy

   identityforge apply quiet-matter

3. 3

   Die Regel als Verbot formulieren

   Verbote werden zuverlässiger befolgt als Präferenzen.

   Copy

   Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md.

4. 4

   Neu messen

   Führen Sie den Six-Value-Diff nach den nächsten zwei Screens erneut aus. Ein Drift-Score von Null ist das erwartete Ergebnis. Falls nicht, wird immer noch etwas außerhalb der Token-Ebene entschieden.

Teilweise, aber genau der Teil, der fehlt, ist der problematische. Eine Komponentenbibliothek löst die Konsistenz auf Komponentenebene: Ein Button ist auf jedem Screen ein Button. Sie bewirkt jedoch nichts bei den Theme-Werten, die diese Komponenten auslesen – und genau dort entsteht der Drift.

Für Teams, die bereits ein System haben, ist dieses Problem noch ausgeprägter. Die häufigste Frage zu Design-Skills und Agent-Tooling ist, ob ein Agent ein bestehendes Theme *respektiert* oder stillschweigend ein eigenes daneben erfindet. Die Antwort hängt vollständig davon ab, ob das Theme als vom Agenten lesbare Werte existiert oder nur als Figma-Library und gemeinsames Verständnis.

Der Mechanismus ist überall gleich, da es sich um einen Kontextverlust (Context Decay) und nicht um einen Defekt eines einzelnen Tools handelt. Unterschiedlich ist, wie viel dauerhaften Status das jeweilige Tool lesen kann – und genau das bestimmt, an welchem Punkt der Drift einsetzt.

• Repo-basierte Agenten (Claude Code, Cursor). Diese können Dateien lesen; eine DESIGN.md plus Design-Tokens behebt das Problem also effektiv. Ihre Schwäche liegt darin, dass sie nicht gezwungen werden, danach zu suchen. Deshalb gehört die entsprechende Anweisung als Verbot in die AGENTS.md.
• Prompt-basierte Builder (v0, Lovable, Bolt). Hier gibt es weniger Repository-Daten zum Auslesen, weshalb die Identität häufiger neu definiert werden muss. Fügen Sie den Token-Block direkt ein, anstatt ihn zu beschreiben.
• Wechsel zwischen zwei Tools. Hier ist der Bruch am deutlichsten, da das zweite Tool keinen Zugriff auf die Konversation des ersten hat und mit den Standardwerten der Library beginnt.

Deshalb ist die Lösung eine Datei und keine Tool-Wahl. Eine Datei ist das einzige Element, das von allen Tools konsumiert werden kann und das überlebt, wenn Sie sich für ein anderes Tool entscheiden.

Wir haben 299 öffentliche DESIGN.md-Dateien von GitHub analysiert. Von den 72 Dateien, die ein visuelles Designsystem beschreiben, enthalten 69 % überhaupt keinen Dark Mode. Kein zweiter Wertesatz, kein prefers-color-scheme, nichts.

Das ist hier besonders kritisch. Fehlt ein Wert im dauerhaften Status, erfindet der Agent ihn – und genau aus diesen erfundenen Werten besteht Drift. Eine Datei, die den Light Mode vollständig abdeckt, aber den Dark Mode auslässt, ist nicht „halb geschützt“; sie ist in einem Theme voll geschützt und im anderen völlig schutzlos. Ihr Drift-Score kann im Light Mode Null und im Dark Mode Vier betragen.

Bemerkenswert ist, wie *plausibel* die driftende Seite isoliert betrachtet aussieht. Drift ist auf der Ebene einer einzelnen Komponente nie offensichtlich falsch; er wird erst sichtbar, wenn zwei Screens nebeneinander liegen – ein Vergleich, den während eines Builds kaum jemand zieht.