Verträge statt Aufsätze: Komponenten maschinenlesbar beschreiben

Storybook-Seiten und Markdown-Dokumente sind für Menschen geschrieben. Ein Sprachmodell muss die Regel erst aus umfangreichem Text herauslesen und stößt dabei auf Formulierungen, die Spielraum lassen.

„Der Button unterstützt Varianten wie primary, secondary und danger. Danger bitte sparsam einsetzen“ ist für einen Menschen eine klare Vorgabe. Ein Agent kann daraus jedoch ableiten, dass es vermutlich weitere Varianten gibt und „sparsam“ Auslegungssache ist.

Was in einen Komponentenvertrag gehört

1. Feste Wertelisten. Zulässig sind ausschließlich primary, secondary, ghost und danger. Ein erfundenes variant="warning" wird erkannt, sobald die Werteliste als TypeScript-Typ oder Schema hinterlegt ist und geprüft wird.
2. Der Zweck jedes Werts. danger: nur für Aktionen, die sich nicht rückgängig machen lassen.
3. Verbotene Kombinationen. Was nicht zusammen auftreten darf, ist ausdrücklich festgehalten.
4. Bindung an Tokens und Barrierefreiheit. Festgelegt ist, welche semantischen Variablen die Komponente nutzt und welche ARIA-Zustände sie setzt.

Ob das als JSON-Schema, als TypeScript-Typen oder als strukturierter Kopf einer Markdown-Datei vorliegt, ist zweitrangig. Maßgeblich ist, dass sich Werte und Kombinationen maschinell prüfen lassen und der Zweck eindeutig formuliert ist. Die Liste versteht sich als Empfehlung und ist kein Standard.

Gezielt nachschlagen

Die zweite Frage ist, wie der Agent an diese Beschreibung gelangt. Atlassian hat dazu einen direkten Vergleich veröffentlicht. Dasselbe Design System lag einmal als einzelne Datei im Kontext vor (DESIGN.md, ein offenes Format von Google), einmal über den eigenen MCP-Server und eigene Skills, bei denen der Agent nur abruft, was er gerade benötigt.

Im Ergebnis brauchte die Datei bei einer Aufgabe für den Produktivcode, einem Login-Screen, rund 92 Prozent mehr Tokens und mehr Durchläufe als der MCP-Server. Das Team nennt dafür drei Gründe. Erstens lädt die Datei alle Inhalte auf einmal. Zweitens musste beim Verdichten auf eine Datei ein Großteil der Nutzungsregeln zu über 50 Komponenten entfallen. Drittens bauten Agenten vorhandene Komponenten häufiger nach, wenn kein Hinweis auf die bestehenden Bausteine vorlag.

Für schnelle Prototypen bewertet dasselbe Team die Datei ausdrücklich als nützlich. Daraus folgt keine pauschale Wertung zugunsten des MCP-Servers. Je näher eine Aufgabe am Produktivcode liegt, desto mehr lohnt sich gezieltes Nachschlagen.

Auch hier handelt es sich um die Messung eines Teams an einem System, und das Team bezeichnet die Ergebnisse selbst ausdrücklich als nicht abschließend. Sie zeigen dennoch, worauf es zu achten gilt.

Aus der Reihe „Design Systems und KI“. Zurück: Drei Design Systeme, die sich für Agenten geöffnet haben. Weiter: Tokens statt geratener Farbwerte.