„Across Vercel, we use coding agents to design and build pages that have to look and feel like Vercel.“ Mit diesem Satz beschreibt das Vercel-Team ein Problem, das viele Unternehmen kennen: KI-Agenten sollen Seiten bauen, die zur Marke passen. Aber Marke lässt sich schwer in Worte fassen. Vercel hat eine pragmatische Antwort gefunden: ein einzelnes öffentliches File namens design.md, das jeder Agent über eine URL laden kann. Dazu kommen ein öffentliches Stylesheet und ein Evaluationsprozess, der Regeln nachweisbar macht. Wer mit Coding Agents arbeitet, findet hier eine konkrete Anleitung, um KI-generierte Seiten konsistent im eigenen Look zu halten.
Warum ein einzelnes öffentliches File nötig ist
Der Ausgangspunkt war ein internes Skill namens product-design. Es liegt in jedem Vercel-Repository neben dem Code, den es steuert. Das Skill erklärt Agenten, wie sie das Designsystem finden, welche Produktrichtlinien gelten und wie die Gestaltung aussehen soll. Das funktioniert, solange Agenten in den Vercel-Codebasen arbeiten, wo Referenzen greifbar sind.
Es gibt Seiten, die außerhalb dieser Umgebung entstehen: Berichte, Proposal-PDFs, Landingpages oder Präsentationsdecks. Diese müssen wie Vercel aussehen, obwohl der Agent keinen Zugriff auf die Repositorys hat. Dafür wurde design.md gebaut. Es ist ein öffentlicher Text, der die wichtigsten Design-Guidelines bündelt und über eine URL abrufbar ist. Beliebige Agenten in beliebigen Umgebungen nutzen dieselbe Grundlage.
Wer versucht hat, Markenidentität in einem Prompt zu beschreiben, ahnt, warum das nicht trivial ist. Design ist subjektiv. Formulierungen wie „halte das Layout sauber“ sagen einem Modell wenig, weil jede KI etwas anderes darunter versteht. Vercels Ansatz ersetzt diese Vagheit durch konkrete Regeln, Beispiele und benannte Fehlerbilder.
Vom Prompt-Fiasko zum getesteten Regelwerk
Der erste Versuch war eine einfache Portierung: Das gesamte product-design-Skill wurde in einen öffentlichen Prompt gepackt. Das Ergebnis war ernüchternd. Jedes Modell interpretierte dieselbe Beschreibung anders und erzeugte unterschiedliche Seiten. In der Codebasis sieht ein Agent echte Komponenten und veröffentlichte Beispiele. Ein statischer Prompt enthält nur Wörter.
Also setzte das Team das File neu auf, mit einer Änderung: Jede Änderung wurde gegen feste Evaluations-Prompts getestet. Sieben Szenarien entstanden, abgeleitet aus realen Anwendungsfällen: ein Nutzungsreport, ein Verlängerungsangebot, ein Benchmark-Report, eine interaktive Planungsseite, ein Build-vs-Buy-Brief, ein Security-Governance-Brief und ein Präsentationsdeck. Die Prompts blieben stabil, während das File sich änderte. So ließ sich jede Verbesserung den Regeln zuordnen.
Der Test kam beim ersten Vergleich. Dieselbe Aufgabe, dasselbe Modell, einmal ohne und einmal mit design.md. Ohne das File erzeugte das Modell ein generisches SaaS-Dashboard. Mit dem File führte die Seite mit der Empfehlung zur Vertragsverlängerung, bündelte die kommerziellen Kennzahlen in einem Raster und stellte Peer-Vergleiche auf eine gemeinsame Skala. Es veränderte also nicht nur Styling, sondern auch Struktur und Hierarchie. Das war das Signal, weiterzumachen.
Drei Ebenen: Anleitung, Stylesheet, Auswertung
Das finale System besteht aus drei Teilen. Der erste Teil ist design.md selbst. Dieses File enthält Regeln, wie eine Seite aufgebaut sein sollte: Sie muss sowohl einen schnellen Executive-Read als auch eine detaillierte Prüfung unterstützen. Es beschreibt, wie man Behauptungen formuliert, wie Hierarchie, Typografie und Farbe zusammenspielen und wie die Wortmarke verwendet werden darf. Das File benennt auch unerwünschte Muster. Wiederkehrende generierte Design-Klischees bekommen Namen. Das hilft Agenten, sie zu erkennen und zu vermeiden.
Der zweite Teil ist ein öffentliches Stylesheet. Agenten hatten zuvor eigene Typografie, Abstände und Layouts erfunden. Vercel hat diese Entscheidung dem Modell entzogen. Das Stylesheet definiert eine dokumentierte Sammlung von Klassen und Tokens für Header, Tabellen, Statistik-Blöcke und Diagrammstile. design.md verweist auf diese Klassen, sodass der Agent sie direkt im HTML verwenden kann. Der Agent muss das Stylesheet nicht lesen, es wird im Browser geladen. So bleibt der Kontext des Modells frei für die Design-Regeln.
Der dritte Teil ist eine Auswertungsschleife. Deterministische Checks fangen mechanische Fehler ab, etwa eine Tabelle, die die verfügbare Breite ignoriert. Menschliche Reviewer beurteilen subjektive Aspekte: Hierarchie, Komposition und die Frage, ob die Seite liefert, was der Leser braucht. Alle drei Ebenen zusammen bilden ein System, das besser wird.
Wie Regeln entstehen: Szenarien, Runden, Korrekturen
Jede Regel in design.md hat ihren Platz über die Evaluationsschleife verdient. Dafür werden die sieben Szenarien mit festen Eingaben und gleichen Viewport-Einstellungen ausgeführt. Eine Runde besteht daraus, für jedes Szenario eine frische Seite gegen die aktuelle Version des Files zu generieren. Volle Runden laufen mit zwei Modellen: Claude Opus 4.8 und Codex mit GPT-5.5. Wenn nur ein bestimmtes Verhalten untersucht werden soll, reichen die betroffenen Szenarien erneut.
Die Ergebnisse werden in einer lokalen App angezeigt. Jede gespeicherte Ausführung enthält Prompt, Eingaben, Modellkonfiguration, die Version von design.md, Screenshots und das Feedback der Reviewenden. Dieses Feedback wird gegen die exakte Ausführung protokolliert. Daraus entstehen die Regeln: Urteilsfragen landen als Prosa in design.md, wiederverwendbare Mechanismen im Stylesheet, und prüfbare Aspekte werden deterministische Checks.
Ein Beispiel zeigt, wie konkret das wird. In einem frühen Verlängerungsangebot war die Tabelle mit den Vertragskonditionen auf die Breite des Fließtexts zusammengequetscht, obwohl doppelt so viel Platz zur Verfügung stand. Das gleiche Muster tauchte in anderen Ausgaben auf. Die Korrektur kam in zwei Formen: als Regel im File und als Check im Code. Spätere Läufe erzeugten vollbreite Tabellen. Um solche Änderungen abzusichern, wiederholte das Team die betroffenen Szenarien. Bei Meilensteinen gab es blinde A/B-Vergleiche zwischen alter und neuer Version.
Was die Messung zeigt
Bis das File fertig war, liefen über 200 Generierungen, volle Runden, gezielte Tests, Sackgassen inklusive. Am Ende wollte das Team wissen, ob die eingebauten Korrekturen verhindern, wofür sie gedacht sind. Dazu wurden drei Desktop-Szenarien ausgewählt. Für jedes Szenario erzeugte ein Modell die Seite zweimal: einmal mit und einmal ohne design.md. Die allererste Generation wurde verwendet, ohne Neustart. Danach liefen alle sechs Seiten durch die deterministischen Checks.
Das Ergebnis: Mit design.md traten 39 bekannte Fehler auf, ohne das File 91. Das sind 57 Prozent weniger in diesem Test. Die Zahlen haben zwei Einschränkungen. Die Checks können nur Fehler finden, die bereits entdeckt und dokumentiert wurden. Sechs Seiten sind eine kleine Stichprobe. Jede einzelne Seite hatte mindestens einen Fehler, der ein Shipping verhindert hätte.
Was der Test zeigt, ist der Wert der Methode: Wenn man einen Fehler benannt und als Regel codiert hat, bleibt dieser Fehler in der Regel aus. Das klingt bescheiden, ist aber in der Arbeit mit KI-Agenten der Unterschied zwischen zufälligen Ergebnissen und kontrollierter Qualität. Es ist ein Fortschritt, der sich messen lässt, ohne dass man behaupten müsste, die KI sei jetzt „gut“.
Was du daraus mitnehmen kannst
Der Weg von Vercel lässt sich auf andere Teams übertragen, auch wenn das Designsystem kleiner ist. Der Kern ist die Kombination aus einer schriftlichen Design-Referenz, einem begrenzten Satz wiederverwendbarer Bausteine und einem Feedback-Loop, der aus Ausgaben lernt. Wer versucht hat, einem Agenten per Chat beizubringen, wie die eigene Marke aussieht, weiß, wie frustrierend das sein kann. Mit einer öffentlichen URL, die alle relevanten Regeln enthält, wird daraus ein kontrollierbarer Prozess.
Der aufwendigste Teil ist die Evaluationsschleife, aber sie ist auch der wichtigste. Ohne feste Szenarien und ohne die Bereitschaft, jede Regel durch die Brille der Ergebnisse zu prüfen, bleibt design.md nur ein weiterer Prompt. Mit dieser Schleife wird aus dem Dokument ein lebendes Regelwerk, das sich an Fehlern orientiert. Das unterscheidet Vercels Ansatz von üblichen Quick-Fixes: Es geht nicht um magische Prompts, sondern um Engineering.
Für alle, die mit Coding Agents arbeiten, ist das eine beruhigende Nachricht. Markenqualität muss nicht dem Zufall überlassen werden. Sie lässt sich in Dateien packen, in Checks gießen und durch Wiederholung verbessern, vorausgesetzt, man nimmt sich die Zeit, die Ausgaben systematisch zu bewerten. Auch in Zeiten generativer Modelle bleibt guter Geschmack eine Frage von klaren Regeln, ehrlichem Feedback und der Disziplin, beide gegeneinander zu testen.
Quelle: vercel.com
