Kante: ein Designsystem, das eine KI lesen kann

Der Durchlauf ohne System bekam nur zwei Screenshots der Referenz. Das Ergebnis sieht auf den ersten Blick richtig aus. Das ist die eigentliche Gefahr: Niemand würde es im Review zurückweisen.

Darunter stehen 116 Farbwerte direkt im Code, 28 verschiedene. Kante hat 15. Die Tinte hat das Modell aus dem Bild geschätzt, als #141414 statt #111111, und für fast dieselbe graue Fläche gibt es zwei Werte, die sich um eine Stufe unterscheiden. Ändere ich im System eine Farbe, kommt davon nichts an.

Alle Werte stehen als JSON im W3C-Format für Design-Tokens. Daraus erzeugt Style Dictionary CSS-Variablen, Tailwind-Klassen und eine lesbare Doku. Es gibt genau eine Quelle.

Die Basis-Ebene enthält rohe Werte wie ink.900. Die Bedeutungs-Ebene sagt, wofür ein Wert da ist: color.text.default. Die Komponenten-Ebene gibt es nur dort, wo eine Komponente wirklich abweicht. Die KI darf ausschließlich Bedeutungs- und Komponenten-Tokens verwenden. So sucht sie nach Zweck und nicht nach Aussehen.

1. Eine Quelle, viele Ausgaben. Tokens stehen einmal als JSON. CSS, Tailwind-Klassen, Typen und Doku werden daraus erzeugt. Eine KI kann nichts lesen, was an zwei Stellen unterschiedlich steht.
2. Namen nach Zweck, nicht nach Aussehen. color.text.muted statt grey-500. Wer nach dem Zweck sucht, findet den richtigen Token auch dann, wenn zwei Farben gleich aussehen.
3. Grenzen in die Beschreibung. Jeder Token sagt, wo er nicht hingehört, etwa „nie auf eingesenkten Flächen“. Genau diese Sätze verhindern die typischen Fehlgriffe.
4. Kontrast als Daten, nicht als Hoffnung. Erlaubte Text- und Flächenpaare stehen am Token. Liegt ein Paar unter WCAG AA, scheitert der Build.
5. Fertige Textstile. type-heading-m statt Größe, Gewicht und Zeilenhöhe einzeln. Weniger Freiheitsgrade heißen weniger falsche Kombinationen.
6. Regeln, die ein Skript prüfen kann. Jede harte Regel in AGENTS.md hat eine Prüfung. Was sich nicht prüfen lässt, steht in den Spezifikationen und nicht in der Anweisungsdatei.
7. Fehler im System beheben, nie im Ergebnis. Wenn eine KI etwas falsch baut, ändere ich das System und lasse sie neu bauen. So wird jede Lücke einmal geschlossen und nicht bei jedem Prompt wieder.

Jeder Durchlauf ist eine frische KI-Sitzung ohne Vorwissen, in einem eigenen Ordner. Die Aufgabe ist für alle gleich: acht Komponenten in allen Zuständen und ein Einstellungs-Screen daraus. Der Durchlauf mit System bekommt Tokens, Spezifikationen, Prüfskripte und AGENTS.md, aber nie die Referenz.

Gezählt wird per Skript: Werte, die an keinem Token hängen, Kontrastverstöße im gerenderten Ergebnis, fehlende Zustände und fehlende Pflicht-Attribute für Barrierefreiheit. Die Optik beurteile ich selbst.

In der ersten Runde blieben mit System 11 (Opus) und 4 (Haiku) Befunde. Ihre Ursachen lagen im System, nicht in den Modellen.

1. 01

   Befund: Alle Durchläufe, und auch meine Referenz, setzten Checkbox, Switch und Icons mit Zahlen-Klassen wie size-5 oder h-6.

   Änderung am System: Komponenten-Tokens für diese Größen und eine neue Prüfregel. Alle Durchläufe der ersten Runde habe ich mit der strengeren Regel neu bewertet.

   Grund: Größen waren der einzige Bereich ohne Tokens. Die Spezifikation nannte Pixel als Text, also hat jedes Modell sie selbst übersetzt.

2. 02

   Befund: Opus legte den Seitenabstand außerhalb der maximalen Spaltenbreite an. Der Inhalt wurde 64 px breiter.

   Änderung am System: Die Screen-Spezifikation sagt jetzt, dass die Spalte zentriert ist und den Abstand einschließt.

   Grund: Die Spezifikation ließ beide Lesarten zu.

3. 03

   Befund: Die Beschreibung eines Textstils nannte h3, die Karten-Spezifikation verlangte die Ebene nach Gliederung. Beide Modelle lösten den Widerspruch unterschiedlich.

   Änderung am System: Eine Regel an einer Stelle: Die Ebene folgt der Gliederung.

   Grund: Zwei Quellen im System widersprachen sich.

4. 04

   Befund: Haiku mischte im Dialog ein gesteuertes Radix-Element mit einer statischen Vorschau. Die Seite warf einen Fehler beim Laden.

   Änderung am System: Die Dialog-Spezifikation legt den Aufbau jetzt verbindlich fest.

   Grund: Sie verlangte nur „Radix Dialog“. Das Muster meiner Referenz stand nirgends.

Diese Komponenten sind die Referenz, gebaut nur aus Bedeutungs-Tokens. Sie lassen sich bedienen, auch per Tastatur.

• Die KI findet die Lücken. Jede Abweichung in der ersten Runde zeigte auf eine Stelle, an der das System mehrdeutig war oder schwieg. Die Durchläufe sind damit der beste Test für das System selbst.
• Ein kleines Modell reicht, wenn das System trägt. Haiku mit System erreicht dasselbe Ergebnis wie Opus mit System. Das spart in der Praxis Zeit und Geld.
• Der Unterschied ist nicht im Screenshot. Ohne System sieht das Ergebnis fast richtig aus. Wer nur auf Bilder schaut, merkt nicht, dass jeder Wert kopiert statt verknüpft ist.

Grenzen

• Pro Variante gab es einen Durchlauf je Runde. Das zeigt eine Richtung, ist aber keine Statistik.
• Die Prüfregel für Größen habe ich nach der ersten Runde verschärft. Damit die Zahlen vergleichbar bleiben, sind alle Durchläufe mit derselben Regel bewertet.
• Fehler beim Laden der Seite zählt die Prüfung nicht. Ich habe sie für jeden Durchlauf einzeln geprüft und festgehalten.
• Ein Agent hat kurz eine Hilfsdatei im gemeinsamen Elternordner der Durchläufe abgelegt. Er gibt an, dort nichts gelesen zu haben. Überprüfen lässt sich das nicht.

Ein Designsystem für KI ist kein Styleguide mit mehr Text. Es ist eine Sammlung von Entscheidungen, die als Daten vorliegen und sich prüfen lassen. Dann baut auch ein kleines Modell, was ich meine.