Designsysteme für KI-Agenten: So funktioniert Vercels design.md

KI-Agenten können einem Designsystem zuverlässig folgen – wenn die Anweisung nicht bloß „Mach das markenkonform“ lautet. Entscheidend sind drei Dinge: eine gut lesbare Datei für gestalterische Entscheidungen, ein begrenzter Satz an Komponenten oder Styles für wiederkehrende Umsetzungsschritte und feste Evaluationen, die zeigen, ob die Regeln tatsächlich greifen.

Damit verschiebt sich die Kostenrechnung. Es geht nicht darum, Code billiger zu erzeugen. Es geht um weniger Stunden für dieselben Korrekturen an Typografie, Hierarchie, Abständen und Texten nach jedem ersten Entwurf. Vercels öffentlicher design.md-Workflow ist bislang das anschaulichste Praxisbeispiel. Seine Ergebnisse zeigen zugleich, warum die Prüfung durch Menschen weiterhin zum System gehören muss.

Ein System für KI-Agenten: eine Datei, feste Bausteine, eine Prüfschleife

Die entscheidende Idee in Vercels design.md-Workflow ist nicht der Dateiname, sondern die klare Aufteilung der Zuständigkeiten.

1. Leitlinien transportieren Urteilsvermögen. Eine öffentliche Datei erklärt dem Agenten, für wen die Seite gedacht ist, welche Entscheidung Leser treffen sollen, wie Belege aufgebaut werden, wie die Marke formuliert und welche typischen Muster generierter Designs zu vermeiden sind.
2. Bausteine regeln die Umsetzung. Ein veröffentlichtes Stylesheet stellt ein begrenztes Vokabular aus Überschriften, Tabellen, Kennzahlenleisten, Diagrammstilen, Klassen und Tokens bereit. Das Modell benennt einen freigegebenen Baustein, statt für Abstände oder Typografie jedes Mal ein neues System zu erfinden.
3. Evaluationen liefern den Nachweis. Feste Szenarien, deterministische Prüfungen und menschliches Review zeigen, ob eine Änderung den ersten Entwurf verbessert oder das Problem nur an eine andere Stelle verschiebt.

Das lässt sich mit einem Restaurant vergleichen: Die Leitliniendatei entspricht dem Urteilsvermögen des Küchenchefs über das Gericht. Komponenten und Styles sind die vorbereitete Station und die abgemessenen Werkzeuge. Die Evaluation ist die Verkostung. Selbst ein detailliertes Rezept führt ohne bestückte Station zu höchst unterschiedlichen Tellern.

Vercel entwickelte diese Aufteilung, nachdem ein einfacher Prompt gescheitert war. Die erste öffentliche Fassung beschrieb zwar die visuelle Sprache, doch Modelle legten subjektive Formulierungen unterschiedlich aus. Ihnen fehlten die Komponenten und ausgelieferten Beispiele aus Vercels Repositories. Daraufhin überarbeitete das Team die Datei anhand fest definierter Ergebnisse, statt den Text schon dann für fertig zu halten, wenn er überzeugend klang.

Genau dieser Unterschied ist wichtig. Ein Designsystem für Menschen kann sich auf gemeinsamen Geschmack, institutionelles Wissen und Designer verlassen, die eine beinahe richtige Umsetzung erkennen. Für Agenten müssen die Entscheidung auffindbar, die zulässige Umsetzung offensichtlich und ein Fehler beobachtbar sein.

Was in die Leitliniendatei gehört

Die erste Datei sollte kürzer sein als das Designsystem, das sie abbildet. Sie ist eine Entscheidungskarte, kein Museum sämtlicher Komponenten.

Sie braucht sechs Abschnitte:

• Geltungsbereich: auf welchen Oberflächen die Datei geladen werden soll und bei welchen Aufgaben sie außen vor bleibt.
• Leser und Aufgabe: wer das jeweilige Artefakt öffnet, was diese Person verstehen oder entscheiden muss und welche Belege diese Entscheidung ermöglichen.
• Beobachtbare Entscheidungen: Regeln wie „Belegtabellen dürfen die gesamte Inhaltsbreite nutzen“ statt Adjektive wie „aufgeräumt“ oder „hochwertig“.
• Verfügbare Bausteine: die exakten Namen der Komponenten, Klassen oder Tokens, die der Agent wählen darf, einschließlich ihres jeweiligen Einsatzzwecks.
• Benannte Fehlermuster: wiederkehrende schlechte Ergebnisse mit einprägsamen Namen, einem konkreten Symptom und der bevorzugten Korrektur.
• Grenzen: Fakten, die der Agent bewahren muss, abzudeckende Zustände, auszulassende unbelegte Aussagen und Entscheidungen, die weiterhin einen Menschen erfordern.

Wo Kontext wichtig ist, sollte die Datei auch den Grund einer Entscheidung erklären. Liegt die Antwort bereits im Code, sollte sie dorthin verweisen. Jede CSS-Regel zusätzlich in den Modellkontext zu kopieren verschwendet Aufmerksamkeit und schafft zwei Wahrheitsquellen. Vercels öffentliches Stylesheet wird im Browser geladen, während design.md lediglich die Namen dokumentiert, die ein Agent verwenden soll. Der Stylesheet-Code selbst belegt deshalb keinen Platz im Modellkontext.

Hinzu kommt ein Problem beim Abruf der Regeln. In separaten Next.js-Evaluationen stellte Vercel fest, dass Agenten einen vorhandenen Skill in 56% der Fälle nicht aufriefen. Deshalb gehört der Auslöser in dauerhafte Repository-Anweisungen, der Geltungsbereich muss eindeutig sein und der Agent sollte angeben, welche Leitlinien er geladen hat. Ob die Datei geladen wird und ob ihre Regeln befolgt werden, sind getrennt zu testen. Eine perfekte, aber nie geöffnete Datei bleibt bloße Dokumentation.

Bei der Wahl des Agenten oder der Oberfläche rund um dieses System sind die praktischen Unterschiede zwischen Claude Design und v0 bei der UI-Generierung weniger wichtig als die Frage, ob beide dieselben Vorgaben und Evaluationen erhalten.

Jede Korrektur gehört zur engsten zuständigen Ebene

Die wichtigste Betriebsregel ist einfach: Nicht jedes Designproblem lässt sich mit mehr Prosa lösen.

An dieser Stelle lassen viele Teams die Datei zu groß werden. Sie ergänzen Sätze wie „Verwende die richtigen Abstände“, obwohl ein begrenztes Spacing-Token die Frage jedes Mal eindeutig klären würde. Oder sie machen aus einer produktpolitischen Entscheidung eine Linter-Regel, obwohl Code deren Ausnahmen nicht beurteilen kann. Mehr Anweisungen bedeuten nicht automatisch mehr Kontrolle.

Vor dem Rollout vergleichbare Evaluationen durchführen

Eine Evaluation ist nur aussagekräftig, wenn der Vergleich fair ist. Wählen Sie ein wiederkehrendes Artefakt mit echten Lesern, realistischen Eingaben und einer kurzen Bewertungsmatrix. Erzeugen Sie eine Ausgangsversion und führen Sie anschließend denselben Prompt mit identischen Daten, demselben Modell und demselben Viewport aus – diesmal mit geladenen Leitlinien. Bewahren Sie jeweils den ersten Entwurf auf. Mischen Sie die Ergebnisse vor dem Review, damit die prüfende Person nicht weiß, welche Variante die neuen Regeln verwendet hat.

Vercel entwickelte sieben Szenarien aus wiederkehrenden Aufgaben, darunter ein Verlängerungsangebot, ein Benchmark-Bericht, eine Planungsseite, ein Sicherheitsbriefing und ein Präsentationsdeck. Vollständige Durchläufe testeten alle sieben mit Claude Opus 4.8 sowie Codex mit GPT-5.5. Für jeden gespeicherten Lauf wurden Prompt, Eingaben, Modellkonfiguration, Version der Leitlinien, Screenshots und Reviewer-Feedback festgehalten.

Das relevante Ergebnis ist spezifisch und nicht allgemeingültig. Über drei Desktop-Szenarien und sechs Seiten im ersten Entwurf hinweg zählte Vercel mit design.md 39 bekannte Fehler, ohne die Datei dagegen 91 – in diesem Test waren es 57% weniger. Der Test war klein, die Prüfungen konnten nur bereits codierte Fehler erkennen und jede Seite hatte weiterhin mindestens ein Problem, das eine Veröffentlichung verhinderte. Übernehmen Sie die 57% daher nicht in eine Geschäftsprognose. Übernehmen Sie die Methode und messen Sie den eigenen Review-Aufwand.

Beginnen Sie mit dieser Kostenrechnung:

• Erfassen Sie, wie viele Minuten Designer oder erfahrene Entwickler für die Korrektur jedes ersten Entwurfs benötigen.
• Multiplizieren Sie diesen Wert mit der Zahl der wiederkehrenden Artefakte, die pro Monat veröffentlicht werden.
• Addieren Sie die Zeit, die für dieselbe Erklärung in Chats, Pull Requests und Design-Reviews anfällt.
• Führen Sie nach Einführung des Systems dieselbe Gruppe von Artefakten erneut aus und messen Sie den Unterschied.

Ein Beispiel: Vier wiederkehrende Seiten, die jeweils zwei Stunden Korrektur benötigen, beanspruchen acht Review-Stunden. Spart das begrenzte System bei jeder Seite eine Stunde wiederholter Korrekturen, ergibt sich ein Gewinn von vier Stunden. Das ist eine gemessene Einsparung. „Das Ergebnis wirkt markenkonformer“ ist keine.

Der aktuelle Markt liefert einen weiteren hilfreichen Bezugspunkt. KI-Website-Builder kosten laut den vorliegenden Live-Preisen ungefähr $0 bis $160 pro Monat, während ein Leitfaden für individuelle Websites aus dem Jahr 2026 Kosten von $1,500 bis $5,000 nennt. Eine Kontrollschicht für die Marke muss sich gegenüber beiden Optionen rechtfertigen. Ihr Wert liegt nicht in einer weiteren Generierungsschaltfläche, sondern in geringeren Kosten für Überarbeitung, Freigabe und Markenrisiken bei wiederkehrender Arbeit.

Sieben Einsatzfelder für KI-Agenten – geordnet nach größtem Nutzen

1. Multi-Brand-Agenturen mit wiederkehrenden Kampagnenseiten

Eine Agentur mit zehn aktiven Kunden kann pro Kunde eine Leitliniendatei und einen begrenzten Satz an Bausteinen pflegen. Dieselbe Evaluation für Landingpages läuft erneut, sobald sich Agent, Komponentenbibliothek oder Modell ändern. Der Nutzen: Erfahrene Designer verbringen weniger Stunden damit, Typografie und Hierarchie wiederherzustellen, nachdem die Seite technisch längst funktioniert. Diese Gruppe profitiert am stärksten, weil jede akzeptierte Korrektur alle späteren Artefakte desselben Kunden verbessern kann.

2. Produktteams, in denen mehrere Agenten dieselbe Oberfläche bearbeiten

Ein Plattformteam kann sämtliche UI-Arbeit über eine gemeinsame Repository-Anweisung steuern, Leitlinien nur bei Änderungen an sichtbaren Oberflächen laden und mechanische Regeln per Linting durchsetzen. Der konkrete Agent darf wechseln; die akzeptierten Entscheidungen bleiben beim Code. So entsteht Konsistenz über verschiedene Mitwirkende hinweg, ohne dass jedes Modell die Absicht allein aus ausgelieferten Komponenten ableiten muss.

3. Revenue-Teams, die Angebote, Benchmarks und Berichte erstellen

Ein Sales-Operations-Team kann ein Szenario für Verlängerungsangebote mit beispielhaften Kundendaten sowie je einer Bewertungsmatrix für Führungskräfte und Detailprüfer festschreiben. Jede neue Version der Leitlinien muss die Empfehlung in den Vordergrund stellen, gelieferte Zahlen bewahren und Belegen ausreichend Raum geben. Der Nutzen sind schnellere erste Entwürfe, ohne dass ein beliebiges Dashboard-Layout die wirtschaftliche Entscheidung verdeckt.

4. Designsystem-Teams vor der Einführung von Agenten

Ein Designsystem-Team kann die exakten Tokens und Komponenten dokumentieren, die Agenten verwenden dürfen, häufige Fehlermuster benennen und deterministische Prüfungen für mechanische Regeln ergänzen. Damit wird aus einer Komponentenbibliothek ein Betriebssystem für Entscheidungen – und nicht bloß ein Katalog, den Agenten uneinheitlich nachahmen.

5. Start-ups ohne eigene Warteschlange für Design-Reviews

Ein kleines Team kann mit einem einzigen Artefakt beginnen, etwa seiner wöchentlichen Kennzahlenseite, und die letzten zehn wiederkehrenden Korrekturen zusammentragen. Vercels vollständige Evaluations-App ist dafür nicht nötig. Eine Ausgangsversion, ein vergleichbarer Durchlauf und eine menschliche Scorecard reichen aus, um die größten Abweichungen sichtbar zu machen. So wird knappes gestalterisches Urteilsvermögen an einer wiederverwendbaren Stelle gebündelt, während die endgültige Freigabe bei Gründer oder Designer bleibt.

6. Teams für interne Tools mit unterschiedlichen Fachbereichen

Ein internes Plattformteam kann freigegebene Mechanismen für Barrierefreiheit, Zustände und Layout gemeinsam nutzen und zugleich eine kleine Leitlinienschicht pro Aufgabe pflegen, etwa für den Finanzabgleich oder den Supportbetrieb. Das schafft eine gemeinsame Umsetzungsqualität, ohne grundverschiedene Arbeitsabläufe in eine einzige visuelle Vorlage zu zwingen.

7. Regulierte Teams mit Bedarf an einem Prüfpfad

Ein Team aus Gesundheitswesen, Finanzbranche oder IT-Sicherheit könnte für jeden Lauf Prompt, Eingaben, Modellversion, Version der Leitlinien, Rendering, Prüfergebnisse und Reviewer-Entscheidung speichern. Der Nutzen ist Nachvollziehbarkeit: Es wird sichtbar, welche Regel ein Ergebnis geprägt und welche Person eine Ausnahme genehmigt hat. Dieses Muster macht ein Ergebnis nicht automatisch regelkonform, erleichtert aber die Rekonstruktion der Prüfbelege.

Falls noch offen ist, ob der Agenten-Workflow selbst als Produkt oder als interne Fähigkeit entstehen soll, bietet dieses Build-or-Buy-Framework für Coding-Agenten die nächste Entscheidungshilfe.

Drei Produkte, deren Entwicklung sich lohnt

1. Compiler für agententaugliche Designsysteme – die stärkste Chance

Entwickeln Sie einen Workspace, der vorhandene Tokens, Komponentendokumentation und wiederholte Review-Korrekturen eines Unternehmens in eine versionierte Leitliniendatei, eine begrenzte Implementierungsübersicht und ein erstes Evaluationspaket überführt. Teams für Design Operations und Plattformen würden dafür bezahlen, weil das Produkt direkt zwischen ihrem bestehenden System und jedem neu eingeführten Coding-Agenten sitzt.

Die Nachfrage ist kleiner als bei allgemeiner Website-Generierung, liegt aber deutlich näher am Käufer. Rund 260 Suchanfragen pro Monat in den USA zielen auf design system software – mit kommerzieller Suchabsicht, Keyword Difficulty 14 und einem CPC von $12.33. Der CPC ist relevant, weil er zeigt, dass Anbieter dieser Aufmerksamkeit trotz des überschaubaren Suchvolumens bereits einen hohen Wert beimessen.

Die kleinste verkaufbare Version benötigt einen Eingangsweg, etwa ein Repository samt strukturiertem Formular für Review-Korrekturen, und einen Ausgangsweg: design.md, eine Übersicht freigegebener Bausteine, drei feste Szenarien sowie einen Bericht darüber, welche Regeln jeder Lauf bestanden hat. Starten Sie mit einem Framework und einer Artefaktklasse.

Die Schwierigkeit liegt im Onboarding. Das wertvollste gestalterische Urteilsvermögen eines Unternehmens ist selten so sauber dokumentiert, dass es sich automatisch importieren lässt. Das frühe Produkt wird teils Software, teils Dienstleistung sein. Sein Schutzwall entsteht daraus, unübersichtliche Review-Historien in verlässliche, prüfbare Entscheidungen zu verwandeln.

2. Markengebundene Microsite-Fabrik

Entwickeln Sie für Agenturen und Revenue-Teams einen Generator für eine eng begrenzte Klasse markenkonformer Seiten, etwa Angebote oder Kampagnen-Microsites, gespeist aus freigegebenen Daten und einem kundenspezifischen Vorgabenpaket. Käufer zahlen für kontrollierte Iteration und nachvollziehbare Freigaben, nicht für die reine Seitengenerierung.

Die allgemeine Nachfrage ist groß: ai website builder erreicht in den USA rund 40,500 Suchanfragen pro Monat, mit einem Wachstum von 49% im Jahresverlauf, kommerzieller Suchabsicht und einem CPC von $31.41. Bestehende Angebote reichen von kostenlosen Tarifen bis ungefähr $160 pro Monat. Ein neuer Anbieter kann deshalb nicht mit „Prompt eingeben, Website erhalten“ gewinnen. Das Versprechen muss präziser sein: bei jedem Lauf dieselben Markenregeln, dieselben freigegebenen Bausteine und dieselben Prüfbelege.

Das MVP sollte einen Seitentyp, ein Importformat, einen festen Komponentensatz, drei Evaluationsszenarien und eine Freigabeansicht für den direkten Vergleich unterstützen. Die Schwierigkeit ist ein dicht besetzter Markt mit starken etablierten Anbietern. Governance und Wiederholbarkeit müssen das Produkt ausmachen, sonst bleibt nur eine dünne Oberfläche über einem Modell.

3. Design-QA-Service für Agenten

Entwickeln Sie einen Pull-Request-Service, der von Agenten erstellte Seiten in festen Viewports rendert, mechanische Designprüfungen ausführt, Modell- und Leitlinienversionen speichert und subjektive Unterschiede an eine blinde menschliche Review-Warteschlange weitergibt. Teams, die bereits Coding-Agenten einsetzen, würden dafür bezahlen, wiederkehrende Fehler abzufangen, bevor sie einen erfahrenen Reviewer erreichen.

Rund 320 Suchanfragen pro Monat in den USA zielen auf visual regression testing, bei einer Keyword Difficulty von 8 und einem CPC von $20.56. Das ist kein Massenmarkt, aber ein direkter Beleg dafür, dass Teams nach automatisierter visueller Prüfung suchen. Die geringe Schwierigkeit lässt Raum für einen agentenspezifischen Ansatz, bei dem die Einhaltung von Regeln statt bloßer Pixelunterschiede im Mittelpunkt steht.

Das MVP kann mit einem GitHub-Check, zwei Viewports, einem Dutzend deterministischer Regeln, Screenshot-Speicherung und einem Reviewer-Urteil beginnen. Die Einschränkung: Ein visueller Unterschied sagt noch nichts über Designqualität aus. Ein Pixel-Diff erkennt Abweichungen, und ein Modell als Bewerter kann eine erste Kritik formulieren. Hierarchie, Produktbedeutung und neue Richtlinien brauchen jedoch weiterhin Menschen.

Was dieses Muster nicht löst

Eine Datei macht aus einem schwachen Designsystem kein starkes. Sie kann weder Entscheidungen liefern, die das Team nie getroffen hat, noch unzugängliche Komponenten reparieren, faktische Richtigkeit belegen oder neue Produktregeln beschließen. Außerdem sorgt sie nicht dafür, dass sich jedes Modell gleich verhält.

Vorgaben können wiederkehrende Abweichungen unterdrücken, aber auch einen schlechten Baustein festschreiben. Evaluationen können bekannte Fehler verhindern, zugleich jedoch eine enge Bewertungsmatrix belohnen und neue Probleme übersehen. Menschliches Review kann Fehlentscheidungen erkennen – allerdings nur, wenn Korrekturen so erfasst werden, dass das System sie wiederverwenden kann.

Gerade weil Vercel die Grenzen offen benennt, ist das Ergebnis ein hilfreiches Signal. Sechs Seiten sind keine Zuverlässigkeitsstudie. Prüfungen auf bekannte Fehler messen nicht die gesamte Designqualität. Jede getestete Seite hatte weiterhin ein Problem, das die Veröffentlichung blockierte. Das ehrliche Ziel des ersten Rollouts sind weniger wiederholte Korrekturen, nicht eine autonome Designfreigabe.

Der konkrete Schritt für Montag: Wählen Sie eine wiederkehrende Seite, speichern Sie den ersten Entwurf ohne Unterstützung und sammeln Sie die letzten zehn Korrekturen, die das Team an diesem Seitentyp vorgenommen hat. Ordnen Sie jede Korrektur Leitlinien, Bausteinen, Code oder einer menschlichen Entscheidung zu und führen Sie anschließend einen vergleichbaren Blindtest durch. Erweitert wird erst, wenn diese Schleife die gemessene Review-Zeit senkt.

Kann KI wirklich eine Website für mich erstellen?

Ja. Coding-Agenten und KI-Website-Builder können aus einem Prompt funktionsfähige Seiten erzeugen. Schwieriger ist die Frage, ob der erste Entwurf zur Marke passt, die gelieferten Fakten bewahrt, die richtigen Zustände abdeckt und das Review besteht. Leitlinien, begrenzte Bausteine und vergleichbare Evaluationen schließen genau diese Lücken.

Wie gut sind KI-Website-Builder?

Sie liefern vor allem bei klar abgegrenzten Aufgaben und begrenzten Umsetzungsoptionen schnell Ergebnisse. Weniger verlässlich sind sie, wenn „gut“ von unausgesprochenem Produkturteil, einer proprietären Designsprache oder neuen Richtlinienentscheidungen abhängt. Entscheidend ist die Korrekturzeit des ersten Entwurfs, nicht die schönste mehrfach neu generierte Demo.

Was kosten KI-Website-Builder?

Die vorliegenden Live-Preise für KI-Website-Builder reichen von ungefähr $0 bis $160 pro Monat. Nicht enthalten sind die Kosten für Review, Korrektur, Freigabe und Markenrisiken im eigenen Team. Diese Stunden sollten separat erfasst werden, bevor über die Amortisation eines stärker kontrollierten internen Systems entschieden wird.

Ist eine selbst entwickelte Website besser als ein Website-Builder?

Ein Builder passt, wenn die Seite standardisiert ist, wenig auf dem Spiel steht und seine Grenzen zur Marke passen. Ein kontrollierter Agenten-Workflow lohnt sich, wenn derselbe Artefakttyp wiederkehrt, freigegebene Komponenten und Belege nötig sind oder erfahrene Mitarbeiter viel Zeit mit Korrekturen verbringen. Ausschlaggebend sind die wiederkehrenden Review-Kosten.

Wenn ein solcher designsensibler Coding-Agenten-Workflow für Ihr Unternehmen entstehen soll, finden Sie weitere Informationen unter Entwicklung von KI-Agenten.