Was Drift tatsächlich ist
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 zum exakt gleichen Hex-Code führen.
Jeder Screen ist in Ordnung. Das Produkt hingegen nicht. Diese Lücke ist der Kern des Design Drifts.
Warum es etwa ab Screen fünf beginnt
Die Zahl fünf ist nicht magisch; 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 folgte.
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.
- Abstände und Radien driften zuerst. Niemand benennt sie explizit im Briefing, daher werden sie jedes Mal komplett neu abgeleitet.
- Die Typografie-Skala folgt als Nächstes. Die Basisschriftgröße überlebt meist; das Verhältnis zwischen den Stufen hingegen nicht.
- Die Akzentfarbe driftet zuletzt. Sie wird meist im Briefing erwähnt, was sie verankert – deshalb unterschätzen viele den Drift, wenn sie nur die Farben prüfen.
- Layout-Konventionen driften kaum, weshalb die App immer noch kohärent wirkt, während die Details bereits divergieren.
Ein Tool-Wechsel überspringt die graduelle Phase
Wer mitten im Projekt von Cursor zu Claude Code wechselt, stellt fest, dass jeder Wert, der nicht in einer Datei steht, sofort zurückgesetzt wird. Das zweite Tool hat keinen Zugriff auf die Konversation des ersten, sodass es mit Standardwerten beginnt – deshalb äußert sich Drift beim Tool-Wechsel oft als plötzlicher Bruch statt als schleichender Prozess.
Die Messung
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 letzten Screen und zählen Sie die Abweichungen.
- 1
Invarianten festlegen
Sechs Werte genügen: Primärfarbe, Seitenhintergrund, Basisschriftgröße, Verhältnis der Typografie-Skala, Kartenradius und der Standardabstand zwischen einem Label und seinem Steuerelement.
- 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.
getComputedStyle(document.querySelector('[data-primary-action]')).backgroundColor - 3
Aktuellsten Screen prüfen
Die gleichen sechs Werte, auf die gleiche Weise.
- 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
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.
| Design-Drift | Nie spezifiziert | |
|---|---|---|
| Ein beliebiger einzelner Screen | Intern konsistent | Intern inkonsistent |
| Erster vs. letzter Screen | Weichen ab | Beide weichen von sich selbst ab |
| Ursache | Werte sind aus dem Kontext verloren gegangen | Es existierten nie Werte |
| Lösung | Werte in Dateien auslagern | Zuerst das System festlegen |
Warum die üblichen Workarounds enttäuschen
- 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, einen bestehenden Screen zu kopieren. 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.
Die Lösung und warum sie funktioniert
Verschieben Sie die Invarianten aus der Konversation in das Repository: semantische Tokens plus eine DESIGN.md. Der Agent liest diese zu Beginn jeder Session, sodass Screen zwanzig dasselbe --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 erinnert *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
Contract installieren
npx --yes identityforge@latest install --client claude-code - 2
Kit anwenden
Schreibt die DESIGN.md sowie Light- und Dark-Tokens in das Repo.
identityforge apply quiet-matter - 3
Die Regel als Verbot formulieren
Verbote werden zuverlässiger befolgt als Präferenzen.
Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md. - 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. Ist dies nicht der Fall, wird immer noch etwas außerhalb der Token-Ebene entschieden.
Löst ein Designsystem den Drift von alleine?
Teilweise, und 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, tritt dieses Problem noch deutlicher auf. Die häufigste Frage zu Design-Skills und Agent-Tooling ist, ob ein Agent ein bestehendes Theme *respektiert* oder stillschweigend ein eigenes erfindet. Die Antwort hängt vollständig davon ab, ob das Theme als Werte existiert, die der Agent lesen kann, oder nur als Figma-Library und gemeinsames Verständnis.
| Durch Komponentenbibliothek gelöst | Driftet weiterhin | |
|---|---|---|
| Komponenten-Internals | Ja – ein Button ist ein Button | — |
| Theme-Werte, die die Komponenten auslesen | Nein | Primary, Background, Radius, Spacing |
| Komposition zwischen Komponenten | Nein | Sektionsrhythmus, Hierarchie, Grid-Entscheidungen |
| Alles, was die Library nicht abdeckt | Nein | Pro Screen neu erfunden, jedes Mal anders |
Das Versagen, das eine Figma-Library nicht verhindern kann
Wenn Ihr System nur in Figma und in den Köpfen der Beteiligten existiert, kann ein Coding-Agent es nicht lesen. Er wird Komponenten erstellen, die plausibel aussehen, aber Werte verwenden, die niemand festgelegt hat. Ein Designsystem stoppt Drift nur in dem Maße, in dem es als Text im Repository existiert.
Unterscheidet sich Drift zwischen Cursor, Claude Code, v0 und Lovable?
Der Mechanismus ist überall derselbe, da es sich um Context Decay und nicht um einen Defekt eines einzelnen Tools handelt. Unterschiedlich ist, wie viel dauerhaften Zustand jedes Tool lesen kann – und genau das bestimmt, an welchem Punkt Drift auftritt.
- Repo-basierte Agenten (Claude Code, Cursor). Diese können Dateien lesen, daher beheben eine
DESIGN.mdplus Design-Tokens das Problem tatsächlich. Ihre Schwäche ist, dass sie nicht gezwungen werden, danach zu schauen. Deshalb gehört die entsprechende Anweisung als Verbot in dieAGENTS.md. - Prompt-basierte Builder (v0, Lovable, Bolt). Hier gibt es weniger Repository-Daten zum Auslesen, daher muss die Identität häufiger neu definiert werden. Fügen Sie den Token-Block direkt ein, anstatt ihn zu beschreiben.
- Wechsel zwischen zwei Tools. Der schärfste Bruch, da das zweite Tool keinen Zugriff auf die Konversation des ersten hat und mit den Library-Defaults startet.
Deshalb ist die Lösung eine Datei und keine Tool-Wahl. Eine Datei ist das einzige Element, das alle Tools konsumieren können und das überlebt, wenn Sie sich für ein anderes Tool entscheiden.
Wo Drift den größten Schaden anrichtet: Dark Mode
Wir haben 299 öffentliche DESIGN.md-Dateien von GitHub analysiert. Von den 72, die ein visuelles Designsystem beschreiben, enthalten 69 % überhaupt keinen Dark Mode – keine zweiten Wertesätze, kein prefers-color-scheme, gar nichts.
Das ist hier besonders relevant. Wo ein Wert im dauerhaften Zustand fehlt, 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.
Wenn Sie den Six-Value-Diff durchführen, tun Sie dies zweimal – einmal pro Theme. Im Dark Mode driften die Zahlen meist auseinander, und genau diese Messung wird oft übersprungen, weil die Light-Screens gut aussehen.
Bemerkenswert ist, wie *plausibel* die driftende Seite isoliert betrachtet aussieht. Drift ist auf Komponentenebene nie offensichtlich falsch; er wird erst sichtbar, wenn zwei Screens nebeneinandergelegt werden – genau der Vergleich, den niemand während eines Builds durchführt.
Hören Sie auf, doppelt für Drift zu bezahlen
Installieren Sie ein Kit vor dem nächsten Screen, anstatt nach dem zwanzigsten zu refactoren. Design-Tokens, DESIGN.md und ein shadcn-Registry-Item in einem Befehl. Kostenlose Kits benötigen kein Konto.
Ist Drift ein Zeichen dafür, dass ich das falsche Modell gewählt habe?
Nein. Drift tritt bei jedem Agenten auf, da die Ursache Context Decay und nicht mangelnde Fähigkeit ist. Ein stärkeres Modell behält Werte geringfügig länger, driftet dann aber auf die gleiche Weise.
Kann ich dies vermeiden, indem ich die Sessions kurz halte?
Innerhalb einer Session hilft dies, verschlimmert jedoch das Problem über mehrere Sessions hinweg. Jede neue Session beginnt mit Standardwerten; kurze Sessions ohne dauerhafte Werte führen daher häufiger zu abrupten Inkonsistenzen.
Löst eine Komponenten-Bibliothek dieses Problem?
Teilweise. Sie stellt die Konsistenz auf Komponentenebene sicher, da ein Button immer ein Button bleibt. Sie behebt jedoch nicht die Theme-Werte, die diese Komponenten auslesen – und genau dort entsteht der Drift.
Mein Drift-Score ist Null, aber die App sieht trotzdem inkonsistent aus. Was nun?
In diesem Fall liegt ein anderes Problem vor: Die Werte sind stabil, aber das System ist zu oberflächlich. Prüfen Sie die Hierarchie, den Spacing-Rhythmus innerhalb eines Screens und ob eine einzige Schriftfamilie für alle Aufgaben genutzt wird.
Wie oft sollte ich erneut messen?
Nach jedem Tool-Wechsel, nach einer Pause von mehr als wenigen Tagen und vor dem Release. An diesen drei Punkten ist die Wahrscheinlichkeit am höchsten, dass nicht fixierte Werte zurückgesetzt wurden.