KI-Coding-Assistenten wie Claude, GitHub Copilot und Cursor verändern die Arbeit mit Design-Systemen fundamental. Entwickler generieren Komponenten, schreiben Styles und erstellen Varianten mithilfe von KI. Das Problem: Wenn das Design-System nicht maschinenlesbar strukturiert ist, generiert die KI Code, der nicht zum System passt – falsche Farben, inkonsistente Spacing-Werte, fehlende Token-Referenzen.
Was „AI-Ready” bedeutet
Ein AI-Ready Design System ist so strukturiert und dokumentiert, dass KI-Coding-Assistenten die Design-Entscheidungen verstehen und korrekt anwenden können. Das ist kein separates Feature, sondern eine Qualität der bestehenden Architektur.
Drei Eigenschaften machen ein Design-System AI-Ready:
Maschinenlesbare Token-Definitionen: Tokens in JSON (DTCG-Format) mit Typen, Beschreibungen und Aliasing-Ketten. Die KI kann das JSON parsen und versteht, welcher Token wofür verwendet wird. SCSS-Variablen oder CSS Custom Properties allein reichen nicht – sie enthalten keine Typ-Information und keine Beschreibungen.
Strukturierte Komponentendokumentation: Jede Komponente hat eine maschinenlesbare Beschreibung: Props mit Typen und Default-Werten, Usage Guidelines (wann verwenden, wann nicht), Code-Beispiele für alle Varianten. TypeScript-Interfaces sind die beste Komponentendokumentation für KI – sie sind gleichzeitig Dokumentation und Validierung.
Kontext-Dateien: Eine CLAUDE.md, COPILOT.md oder generische .ai-context-Datei im Repository-Root beschreibt die Projekt-Konventionen: Welches Framework wird verwendet, welche Tokens existieren, welche Naming-Conventions gelten, welche Komponenten verfügbar sind.
Die Kontext-Datei
Die wirksamste Maßnahme für AI-Readiness ist eine Kontext-Datei, die KI-Tools automatisch einlesen. Claude Code nutzt CLAUDE.md, Cursor nutzt .cursorrules. Der Inhalt sollte abdecken: Tech-Stack (Framework, Styling-Approach, Build-Tool), Token-Übersicht (verfügbare Farb-, Typo-, Spacing-Tokens mit Beispielen), Komponenten-Inventar (welche Komponenten existieren, wo finden sie sich), Naming-Conventions (CSS-Klassen, Token-Namen, Dateistruktur) und Do/Don’t-Regeln (z.B. „Verwende immer var(--color-action-primary) statt #2563EB”).
## Design Tokens
Alle Tokens in `src/tokens/tokens.json` (DTCG-Format).
Farben: var(--color-action-primary), var(--color-feedback-success), ...
Spacing: var(--spacing-4) = 16px, var(--spacing-8) = 32px, ...
## Komponenten
Alle UI-Primitives in `src/lib/components/ui/`.
Verfügbar: Badge, Card, SectionHeader, DataTable, Container.
Import: `import { Badge } from '$components/ui';`
## Regeln
- Keine hardcoded Farben – immer CSS Custom Properties.
- Keine inline-styles – UnoCSS-Klassen oder <style> mit Tokens.
- Svelte 5 Runes: $state(), $derived(), $props().AI-Ready vs. AI-Dependent
Ein wichtiger Unterschied: AI-Ready bedeutet, dass ein Design-System so strukturiert ist, dass KI-Tools es effektiv nutzen können. Es bedeutet nicht, dass KI für die Nutzung erforderlich ist. Die gleichen Eigenschaften, die ein System AI-Ready machen – klare Dokumentation, maschinenlesbare Tokens, konsistente APIs – machen es auch für menschliche Entwickler besser nutzbar.
Kernpunkte
- AI-Ready Design Systems sind maschinenlesbar strukturiert – Tokens in JSON mit Typen und Beschreibungen, Komponenten mit TypeScript-Interfaces.
- Eine Kontext-Datei (CLAUDE.md / .cursorrules) im Repository-Root ist die wirksamste Einzelmaßnahme.
- Die gleichen Eigenschaften, die ein System AI-Ready machen, machen es auch für menschliche Entwickler besser.
- DTCG-Format-Tokens sind die ideale Grundlage – sie enthalten Typ-Information und Beschreibungen, die KI-Tools parsen können.
- AI-Ready ≠ AI-Dependent – das System muss auch ohne KI-Tools funktionieren.
- Wer sein Design-System heute maschinenlesbar strukturiert, profitiert sofort und ist auf zukünftige KI-Entwicklungen vorbereitet.
