Ein Design System, das nur Menschen lesen können, ist im KI-Workflow eine Schwachstelle. Keine theoretische, sondern eine praktische. Sie zeigt sich dann, wenn Cursor oder Copilot Code generieren – und der Output nichts mit deinem System zu tun hat.
Das passiert nicht, weil KI-Tools schlecht sind. Es passiert, weil sie nichts Verwertbares bekommen haben.
#Warum der Status quo nicht funktioniert
Die meisten Design Systems sind für Menschen gebaut. Tokens in Figma, Komponenten in Storybook, Dokumentation irgendwo in Notion. Jeder dieser Orte hat eine eigene Logik, eine eigene Benennung, manchmal eine eigene Wahrheit.
Ein erfahrener Entwickler navigiert das. Er kennt das System, er weiß, wo er suchen muss. Ein LLM nicht. Es greift auf das zurück, was strukturiert und maschinenlesbar vorliegt – meistens also auf generischen Code aus dem Training.
Das Ergebnis: Buttons ohne deinen Border-Radius. Abstände, die nicht aus deiner Skala kommen. Farben, die irgendwo zwischen deinen Tokens und dem Modell-Default liegen.
#Das eigentliche Problem ist die Trennung
Figma kennt deine Tokens. Storybook kennt deine Komponenten. Notion kennt deine Entscheidungen. Aber diese drei Systeme sprechen nicht miteinander – und sie sprechen schon gar nicht mit einem LLM.
Was ein Sprachmodell braucht, ist Kontext. Und zwar strukturierten Kontext, der direkt im Code liegt. Kein PDF, das irgendwann veraltet. Keine Figma-Kommentare, die niemand pflegt. Sondern eine Single Source of Truth, die maschinenlesbar ist.
Das klingt technischer als es ist. Im Kern geht es darum: Wenn dein Design System als Code definiert ist – als Tokens in einem Format wie JSON oder YAML, als typisierte Komponenten-API, als dokumentierter Style Dictionary – dann kann ein LLM damit arbeiten. Es versteht, welcher Wert zu welchem Kontext gehört.
#Was "Design System as Code" konkret bedeutet
Der Ansatz, der gerade Fahrt aufnimmt, ist nicht neu. Er ist eigentlich die konsequente Weiterentwicklung von dem, was gute Teams schon immer gemacht haben: Tokens nicht nur benennen, sondern maschinenlesbar exportieren.
Konkret heißt das zum Beispiel:
Statt einer Figma-Seite mit Farbpalette gibst du dem LLM eine tokens.json mit semantischen Namen. Statt einer Notion-Seite mit "Button-Varianten" gibst du ihm eine typisierte Komponenten-API mit klaren Props und Defaults. Statt Storybook-Dokumentation, die niemand im Code-Editor öffnet, gibst du ihm Inline-Kommentare, die das Modell beim Autocomplete lesen kann.
Das Ziel ist nicht, Dokumentation abzuschaffen. Das Ziel ist, sie nicht als einzige Quelle zu haben.
#Warum das überfällig ist
Design Systems waren immer für Konsistenz gebaut. Aber die Zielgruppe war der Mensch. Der Entwickler, der einen neuen Button bauen will. Die Designerin, die nachschaut, welcher Abstand wohin gehört.
Jetzt kommen Werkzeuge dazu, die anders funktionieren. Sie lesen keine Figma-Kommentare. Sie öffnen keine Notion-Seiten. Sie schauen in den Code – und wenn dort nichts Verwertbares steht, erfinden sie etwas.
Das ist keine Kritik an den Tools. Das ist eine Beschreibung, wie sie funktionieren.
Wer sein System jetzt nicht für Maschinen aufbereitet, wird in zwei Jahren feststellen, dass KI-generierter Code am System vorbeibaut. Nicht böswillig, nicht aus Inkompetenz. Sondern weil das Modell keine andere Wahl hatte.
#Gegenargument: "Unsere Entwickler kennen das System"
Das stimmt – heute. Aber der Punkt ist nicht, ob deine aktuellen Entwickler das System kennen. Der Punkt ist, was passiert, wenn KI-Tools Teil des Workflows werden.
Und das sind sie bereits. Cursor, Copilot, Claude mit Codebase-Kontext – diese Tools sind kein Experiment mehr. Teams nutzen sie täglich für echten Produktionscode. Wenn dein Design System für diese Tools unsichtbar ist, verlierst du Konsistenz. Nicht irgendwann, sondern bei jedem generierten Snippet.
#Was du konkret tun kannst
Fang mit dem an, was du schon hast. Wenn du Style Dictionary oder Token Studio nutzt, prüf, ob deine Tokens sauber exportiert werden. JSON ist gut. Gut benannte, semantische JSON ist besser.
Schreib Komponenten-APIs explizit. Typen, Defaults, erlaubte Werte. Das hilft nicht nur dem LLM – es hilft auch neuen Entwicklern.
Leg eine llm-context.md oder ähnliches in dein Repository. Eine Datei, die erklärt, wie das System aufgebaut ist, welche Konventionen gelten, welche Tokens wofür gedacht sind. Viele Teams machen das bereits für Onboarding – der Schritt zum maschinenlesbaren Format ist kleiner, als er wirkt.
Und dann: Teste es. Öffne Cursor, stell eine konkrete Frage zu deinem System, schau, was zurückkommt. Der Output zeigt dir sofort, wie gut dein System als Kontext funktioniert.
#Der Shift, der gerade passiert
Design Systems werden gerade neu bewertet – nicht weil sie schlecht waren, sondern weil die Zielgruppe gewachsen ist. Menschen und Maschinen brauchen dasselbe System. Nur in unterschiedlichen Formaten.
Wer das früh versteht, baut ein System, das beide bedient. Wer wartet, baut zwei parallele Welten: das offizielle System für Menschen und den KI-generierten Wildwuchs für alle anderen.
Ausgeloest durch: Making your design system LLM-readable
