Designwissen, auf das Agenten bauen können

Ein Designsystem ist meist für Menschen geschrieben: eine Doku-Website, eine Figma-Bibliothek, ein paar Konventionen, die jeder im Team einmal gelesen hat. Ein Agent hat davon nichts gelesen. Er greift zum naheliegenden Muster: dem, das in seinen Trainingsdaten am häufigsten vorkam, nicht dem, worauf sich dieses Team geeinigt hat.

Der Fehler fällt nicht auf. Der Code kompiliert, das Interface rendert und ein Review fängt nur einen Teil davon ab. Was durchrutscht, ist ein zweites Designsystem, das im ersten wächst.

Schwierig wird es, weil zwei Anforderungen zugleich gelten: Agenten müssen zuverlässig bauen, und das Team muss den Überblick behalten. Wer nur die erste erfüllt, bekommt eine Codebasis, die niemand mehr prüfen kann.

Ein Agent braucht die Regeln in einer Form, mit der er arbeiten kann: welche Komponenten es gibt, welche Varianten, welche Tokens. Der erste Ansatz war ein eigener Lookup-Layer für Agenten: ein MCP-Server und ein CLI-Tool. Statt zu lesen, sollte der Agent fragen.

Fragen allein reicht nicht, denn ein Agent, der fragen kann, kann es auch lassen. Deshalb greifen dieselben Regeln dort, wo der Code entsteht: Eine Lint-Regel weist einen Verstoß noch im selben Schritt zurück, Typen lassen nur die vereinbarten Varianten zu und eine hartcodierte Farbe wird gar nicht erst gerendert. Ein Verstoß fällt durch, statt diskutiert zu werden.

Interessant ist nicht die Architektur, sondern ob sie trägt. Also wurde gemessen: 29 realistische Tasks wie „Füg dieses Panel hinzu“ oder „Bau diesen Screen“. Jeder Task lief in drei Setups: Der Agent konnte das Repository lesen, nur den Lookup-Layer fragen oder keins von beidem.

Jede Antwort wurde gleich bewertet: Verwendet sie die Bausteine, die der Task fordert? Besteht sie den Lint- und den Type-Check? Gewertet wurde nur die erste Antwort. Ein früherer Durchlauf hatte eine deutlich schönere Zahl ergeben und wurde zurückgezogen: Er wiederholte einen Task so lange, bis der Agent ein Tool nutzte. Gemessen hat er damit den besten von mehreren Versuchen, nicht das, was ein Agent von sich aus tut.

Mit Zugriff auf das Repository verwendete der Agent 76 Prozent der geforderten Bausteine, nur mit dem Lookup-Layer 46 Prozent, ganz ohne Zugriff 11 Prozent. Lesen schlug die Lookups bei 15 Tasks und verlor bei keinem.

Zu den meisten Lookups kam es nie: Der Agent hätte fragen können, tat es aber bei 25 von 29 Tasks kein einziges Mal. Pro Frage war ein Lookup um ein Vielfaches günstiger als Lesen. Pro Antwort sparte das nichts, weil die Frage nie gestellt wurde.

Nach dem Type-Check allein sähe die Reihenfolge anders aus: Ganz ohne Zugriff bestand der Agent ihn öfter als mit dem Lookup-Layer. Deshalb zählt keine Kennzahl für sich allein.

Der Lookup-Layer wurde entfernt. Er war eine zweite Kopie der Regeln, und zwei Kopien laufen auseinander. Agenten, die den Quellcode öffneten, bekamen dieselbe Antwort direkt aus dem Code. Der kann nicht veralten, denn er ist das, was läuft.

Heute stehen die Regeln dort, wo Menschen und Agenten ohnehin nachsehen: in den Typen, in Doku-Kommentaren an den Komponenten und in der Storybook-Dokumentation, die aus dem Quellcode erzeugt wird. Die Checks sind geblieben. Sie fangen einen Verstoß im selben Schritt ab, in dem er entsteht.

Auffindbar ist nicht gleich genutzt. Eine Regel besser zu beschreiben hat nichts geändert. Gewirkt hat nur der Check, der den Verstoß im selben Schritt zurückweist.

Wer nichts tut, kann besser abschneiden als jemand, der den Task löst. Ein Verbot zählt nur, wenn das Richtige überhaupt möglich war. Sonst kommt auch ein leerer Screen durch.

Eine einzelne Kennzahl kann lügen. Eine Datei, die nichts tut, kompiliert fehlerfrei.