Designsysteme für AI Coding-Agents

Bitten Sie einen beliebigen Coding-Agenten, eine „Landingpage zu erstellen“, und Sie erhalten dasselbe: einen fast schwarzen Hero-Bereich, einen violetten Gradienten, Inter, drei Feature-Cards mit abgerundeten Ecken. Es ist kompetent und völlig generisch, da das Modell zwischen den Prompts kein Gedächtnis für Ihre Marke hat. Fügt man eine zweite Seite hinzu, tritt Drift im Styling auf: anderes Spacing, ein leicht anderes Blau, eine neue Button-Form. Es gibt keine „Source of Truth“ für das Design, daher gibt es keine Konsistenz.

Es lohnt sich, hier präzise zu sein, da die Ursache die Lösung bestimmt. Das Modell scheitert nicht am Design. Es tut genau das, was verlangt wurde: es produziert die wahrscheinlichste Benutzeroberfläche basierend auf der Anfrage. Ohne Einschränkungen ist die wahrscheinlichste Benutzeroberfläche der Durchschnitt von allem, was es gesehen hat – und jeder, der ohne Einschränkungen promptet, landet bei diesem selben Durchschnitt.

Das verändert die Herangehensweise an die Lösung. Es geht nicht darum, den Agenten kreativer zu machen. Es geht darum, ihn aus diesem Durchschnitt herauszuholen und an einem spezifischen Punkt zu fixieren. Das erfordert die Definition, wo dieser Punkt liegt und was außerhalb davon liegt.

Wir haben 299 DESIGN.md-Dateien aus öffentlichen Repositories und Verzeichnissen analysiert (echte Dateien, die von echten Teams geschrieben wurden, um Agents Design-Richtlinien zu geben) und gemessen, was sie tatsächlich enthalten, statt was sie zu enthalten beanspruchen. 72 davon waren spezifische Visual-Design-Dateien. Das Muster ist konsistent genug, um diagnostisch zu sein.

Die letzte Zeile ist der entscheidende Hinweis. Typografie wird in 83 % der Dateien erwähnt, und 44 % dieser Dateien enthalten keine konkreten Größenwerte. „Verwenden Sie eine klare typografische Hierarchie“ ist lediglich eine Erwähnung. Es ist keine Anweisung, und ein Modell bedient diese mit der Hierarchie, die in seinen Trainingsdaten am häufigsten vorkommt.

Die zwei wichtigsten Kennzahlen sind die Quote der Verbote und die Quote der semantischen Rollen, und beide fallen auf die gleiche Weise aus. Eine Datei, die #3b82f6 als „primary“ auflistet, ohne Verbote zu definieren, teilt dem Modell mit, dass ein spezifisches Blau existiert, lässt aber alle Entscheidungen über dessen Verwendung völlig offen. Der Agent verwendet es dann für Überschriften, Links, Icon-Fills, einen Rahmen und einen Farbverlauf, da all dies plausible Anwendungen für eine Primärfarbe sind.

Ein Designsystem, das überlebt, wenn es von einem Modell gelesen, über zwanzig Dateien angewendet und in der nächsten Sitzung wieder aufgenommen wird, benötigt sechs Teile. Jedes Teil schließt einen spezifischen Fehler aus.

Die Zeile zum Dark Mode ist diejenige, die Teams unterschätzen. Den Dark Mode durch Invertieren des Light Modes abzuleiten, ist das, was ein Modell tut, wenn ihm nichts anderes gesagt wird, und es geht auf vorhersehbare Weise schief: Schatten wirken nicht mehr auf dunklen Oberflächen, Mittelgrautöne verlieren den Kontrast zu Text und Hintergrund, und ein gesättigter Akzent, der auf Weiß souverän aussah, wirkt auf fast Schwarz grell. Die Definition kostet ein zweites Token-Set, erspart aber eine ganze Klasse von Nacharbeiten.

Ein Kit ist ein ganzes System, keine Palette. Unten finden Sie eine Live-Vorschau des kostenlosen ambient-sage Kits: dieselben Tokens, Schriftarten und Styles, die ein Agent erhält, wenn er es anwendet. Alles auf dieser Seite könnte durch einen Austausch des Kits neu gestaltet werden.

Egal wie Sie es installieren, die Nutzlast besteht aus denselben drei Dingen:

1. Eine DESIGN.md: das geschriebene Briefing: die Intention des Designs, das Typografie-System, Abstands- und Layoutregeln, Komponenteneigenschaften, markante Motive sowie Do's & Don'ts. Das ist es, was verhindert, dass der Agent standardmäßig generisch wird. Was eine DESIGN.md ist und wie man eine erstellt.
2. Semantische Farbtokens: 28 Rollen (background, foreground, primary, muted, card, border, chart-1…5 und mehr) sowohl im Light- als auch im Dark Mode. Der Agent stylt basierend auf Rollennamen, nicht auf rohen Hex-Werten, damit die Themes kohärent bleiben. Semantische Farbtokens erklärt.
3. Framework-Exporte: dasselbe System als CSS-Variablen, Tailwind v3/v4 @theme, ein shadcn-Registry-Item oder DTCG/W3C JSON. Der Agent verbindet das, was zu Ihrem Stack passt.

Die Rollennamen im zweiten Punkt leisten mehr Arbeit, als es scheint. --color-muted-foreground teilt einem Modell sowohl mit, welcher Wert es ist, als auch wo er hingehört; --gray-400 teilt ihm nur den Wert mit, und der Agent entscheidet dann selbst, welches Grau eine Bildunterschrift haben sollte. Diese Entscheidung ist der Punkt, an dem die Konsistenz verloren geht – Datei für Datei.

Die Mechanik unterscheidet sich je nach Tool: Coding-Agenten laufen über einen lokalen MCP-Server, Web-Builder nutzen die shadcn-Registry oder die exportierte DESIGN.md. Wählen Sie Ihr Tool:

• Geben Sie Claude Code ein Designsystem: MCP via .mcp.json oder identityforge apply.
• Geben Sie Cursor ein Designsystem: MCP via .cursor/mcp.json, plus Anleitung zur Strukturierung der Rules-Dateien.
• Geben Sie Windsurf ein Designsystem: manuelle MCP-Konfiguration für Cascade, plus der CLI-Pfad.
• Geben Sie v0 ein Designsystem: die shadcn-Registry + DESIGN.md als Briefing.
• Geben Sie Lovable ein Designsystem: Project Knowledge + shadcn add im Repo.
• Geben Sie Bolt ein Designsystem: führen Sie shadcn add direkt im Terminal von Bolt aus.

Beides, und aus unterschiedlichen Gründen. Die Unterscheidung ist wichtig, da die Installation eines MCP-Servers in der Erwartung, eine bessere visuelle Ausgabe zu erhalten, oft zu Enttäuschungen führt.

Verbote sind der klarste Fall für eine Datei. Ein Agent, der gerade einen Schlagschatten hinzufügen möchte, hat keinen Grund, die Frage „Sind Schlagschatten erlaubt?“ zu stellen; eine Einschränkung, die hinter einem Tool-Aufruf liegt, wird also nie ausgelöst. Constraints müssen vor der Entscheidung vorhanden sein. Mehr darüber, wo was hingehört.

Durchsuchen Sie Kits nach visuellem Stil, um vollständige Systeme im Kontext zu sehen: Typografie, Farbe, Oberflächen und Build-Regeln. Jedes Kit hat eine permanente ID und einen lesbaren Slug; sobald Sie eines von beiden kennen, kann der Agent die Suche überspringen und es direkt anwenden. Slugs können umbenannt werden, aber der alte funktioniert weiterhin, sodass ein gespeicherter Handle nicht veraltet. Wenn Sie bereits Markenfarben haben, findet das match_palette MCP-Tool die visuell am besten passenden Kits.

Ein Designsystem zu installieren und davon auszugehen, dass es funktioniert, führt dazu, dass Teams drei Wochen später überrascht werden. Vier Prüfungen, in steigender Reihenfolge des Aufwands:

1. 1

   Grep nach konkreten Farbwerten

   Das schnellstmögliche Signal. Wenn der Agent semantische Design-Tokens verwendet, sollten keine Hex-Werte außerhalb Ihrer Token-Datei vorkommen.

   Copy

   # any hex outside the token definitions
   grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \
     | grep -v 'tokens\|globals.css'

2. 2

   Prüfen Sie die Schriftstärken

   Die Schriftstärke ist der Punkt, an dem die Hierarchie stillschweigend auf den Standard zurückfällt. Wenn Ihr System nur 400 und 600 vorsieht, ist alles andere Drift.

   Copy

   grep -rn --include='*.tsx' -E 'font-(bold|extrabold|black|semibold)' src | head -30

3. 3

   Fragen Sie zweimal nach demselben Screen in separaten Sessions

   Konsistenz zwischen den Sessions ist der eigentliche Test. Wenn zwei Durchläufe signifikant unterschiedliche Abstände, Radien oder Hierarchien erzeugen, beschränkt das System nicht das, was es sollte.

4. 4

   Erstellen Sie zuerst einen Screen im Dark Mode

   Wenn der Dark Mode eher abgeleitet als definiert wurde, zeigt sich das hier: tote Schatten, schlammige Grautöne, ein greller Akzent. Es ist günstiger, dies jetzt zu finden als nach zwanzig Screens.

Die ersten beiden Prüfungen sollten in der CI laufen. Eine Regel, die einen rohen Hex-Wert in einem Pull Request abfängt, bewirkt mehr für die langfristige Konsistenz als jede Menge Dokumentation – dieselbe Schlussfolgerung, die Salesforce mit dem SLDS-Linter gezogen hat.