Blog · Deutsch · 2026-05-28

KI-Coding Design — warum jede KI dasselbe Interface baut.

Jeder, der Claude Code, Cursor, Windsurf, GitHub Copilot, Cline oder Continue einmal um eine Landing-Page gebeten hat, kennt das Ergebnis: Inter in Display-Größen hochgezogen, ein Verlauf von Lila nach Blau, drei identische Karten nebeneinander, und unter dem Hero die Zeile „Build something amazing". Das Problem liegt nicht am Werkzeug. Das Problem ist, dass alle Werkzeuge aus demselben Topf an Templates gelernt haben. ux-skill blockiert genau diese Defaults in der CI — mit 145 deterministischen Regex-Regeln, ohne LLM.

By the ux-skill team · 9 min Lesezeit · MIT-lizenzierte Open Source

Die acht visuellen Defaults, die jede KI ausspuckt

Wir haben die ganze Sammlung in der Taxonomie der KI-Design-Fingerprints katalogisiert. Diese acht tauchen in nahezu jedem generierten Hero auf:

Inter als Display-Schrift — eine Schrift, die für kleine Bildschirmgrößen entworfen wurde, im Hero auf 90 px hochgedreht. Das Gegenteil ihres Anwendungsfalls.
Lila-zu-Blau-Verlauf — die Familie #7C3AED → #3B82F6, fast immer als Hintergrund der ersten Section.
Drei identische Karten in einer Reihe — Icon, einwortiger Titel, einsatziger Untertitel, dreimal wiederholt.
Universelles Fade-in-up — auf jedes direkte Kind jeder Section angewendet, ohne semantische Unterscheidung.
Alles zentriert — Hero, Karten, Formulare, alles säulengleich in der Bildmitte.
Generische Copy — „Build something amazing", „Beautiful experiences", „Revolutionizing X", keinerlei Produktnomen.
Stock-Bild-URLs — generische Platzhalter statt echter Produkt-Screenshots.
Schwere Schatten auf flachem Design — die Reflexe „muss auffallen" und „Flat ist Mode" treffen aufeinander, das Ergebnis ist visuell uneins.

Jeder einzelne Default ist für sich genommen kein Fehler. Erst die Kombination aus allen acht macht den Fingerprint erkennbar. Einer allein lässt einen die Schultern zucken; vier auf derselben Above-the-fold sagen einem genau, welches Tool das gebaut hat.

Warum Prompts nicht ausreichen

Die erste Reaktion in jedem Team ist, dem Prompt zusätzliche Anweisungen mitzugeben: „Nimm nicht den Default-Verlauf", „Wähl eine echte Display-Schrift", „Pack nicht drei gleiche Karten nebeneinander". Das hält für eine Nachricht. In der nächsten verdünnt sich die Leitlinie, das Kontextfenster wächst, der Fingerprint kommt zurück. Steuerung über Prompts ist probabilistisch und verliert mit der Länge an Wirkung.

Was es braucht, ist ein deterministischer Boden — eine Prüfung, die nach dem Modell läuft, ohne LLM in der Schleife. Diese Lücke füllt ux-skill. Der Empfehler engt die Auswahl des Modells im Vorfeld ein, der Linter ahndet Verstöße im Nachgang.

Auf Stochastik nicht mit Stochastik antworten

Der Gedanke, „dann lassen wir eben ein zweites LLM den Output bewerten", taucht immer wieder auf. Aber LLM-basierte Bewertung schwankt genauso wie LLM-basierte Generierung. Sie hängt vom Rating-Prompt, von Few-shot-Beispielen, von der heutigen Modellversion ab. In der CI brauchen wir eine Schicht, die jedes Mal dasselbe Urteil zurückgibt. Determinismus ist die einzige Stärke der Regex — und sie reicht.

145 Regex-Regeln, kein LLM, in der CI

Der Linter scannt jede Datei unter *.tsx, *.jsx, *.vue, *.svelte, *.astro, *.css, *.scss, *.html. Er wendet 145 Regex-Ausdrücke mit den Flags i und m an. Die Ausgabe ist JSON mit Regel-ID, Schweregrad, Datei, Zeile, Spalte, Auszug und Fix-Vorschlag.

# Lokales Lint, Gate bei high+critical per Default
$ uxskill lint
[OK] Scanned 142 files in 412ms · 0 findings at threshold high

# Unterverzeichnis + JSON-Output
$ uxskill lint apps/web/src --json | jq '.summary'
{
  "critical": 0,
  "high": 4,
  "medium": 11,
  "low": 3,
  "total": 18
}

Null LLM-Aufrufe. Die Durchlaufzeit auf einem Next.js-Repo mit 200 Dateien liegt bei 380 ms kalt und 90 ms warm. Die vollständige Regelbeschreibung steht im Regex-Linter-Guide.

Vorher und Nachher an einem echten Hero

Unten steht ein vereinfachter Hero-Block aus einem Next.js-Starter, der drei Regeln verletzt, und die umgeschriebene Variante, die mit Exit-Code 0 durchläuft. Gleiche Konversionsabsicht, anderer Fingerprint.

// Vorher — 3 High-Findings
<section className="bg-gradient-to-br
  from-purple-500 via-violet-500
  to-blue-500 py-32">
  <h1 className="font-['Inter']
    text-7xl leading-none">
    Build something amazing.
  </h1>
  <div className="grid grid-cols-3 gap-6">
    <Card icon="Zap" title="Fast" />
    <Card icon="Shield" title="Safe" />
    <Card icon="Heart" title="Loved" />
  </div>
</section>

// Nachher — 0 Findings
<section className="bg-stone-50 py-28">
  <h1 className="font-['Fraunces']
    text-6xl leading-[1.04]
    tracking-tight">
    Die Frachtrouting-Schicht,
    die dein TMS nie ausgeliefert hat.
  </h1>
  <div className="grid grid-cols-12 gap-6 mt-16">
    <Card className="col-span-7"
      title="Frachtkonsolidierung" />
    <Card className="col-span-5"
      title="Carrier-Ranking" />
  </div>
</section>

Im Vorher schlagen drei Regeln an: Inter bei text-7xl, der kanonische KI-Verlauf und das Dreierraster identischer Karten. Im Nachher paart die Vorlage Fraunces (Display) mit Inter (Body), nutzt eine flache Oberfläche und tauscht in ein asymmetrisches 7-zu-5-Raster. Gleiche Absicht, kein Fingerprint mehr.

Der Empfehler hebt den Boden. Der Linter setzt die Decke. Beides ist nötig.

Cursor AI mit einem echten Designsystem ausstatten

Cursor bringt das beliebteste Composer-Erlebnis im KI-Coding-Stack mit, hat aber kein eingebautes Verständnis von Designsystemen. Cascade übernimmt schlicht die Defaults des Modells. ux-skill setzt sich auf zwei Ebenen drauf: einer .cursorrules-Datei für In-Editor-Anweisungen und einem MCP-Server für strukturierte Tool-Aufrufe.

# Setup für Cursor
$ pip install uxskill
$ uxskill init --target cursor
$ uxskill mcp-config --target cursor

# Erzeugt:
# .cursorrules           ← 51 Regel-Snippets, In-Editor
# ~/.cursor/mcp.json     ← 14 MCP-Tools registriert
# tokens.css             ← OKLCH-Palette, Typo-Skala
# MASTER.md              ← Designsystem-Single-Source

Nach dem Setup kann Composer im Editor auf 14 ux-skill-Tools zugreifen: discover_brief, recommend_design, lint_codebase, get_brand_spec, und so weiter. Die Designentscheidungen landen direkt im Repo, nicht im Chatverlauf — und damit auch in jeder zukünftigen Cursor-Session.

Drei Installationspfade, eine Engine

Dasselbe Python-Paket erreicht alle 17 IDEs aus der Kompatibilitätsmatrix. Nimm die Route, die deinem Editor am nächsten ist:

Editor	Pfad	Befehl
Claude Code	Marketplace	`/plugin install ux@ux-skill`
Cursor	`.cursorrules` + MCP	`uxskill init --target cursor`
Windsurf	`.windsurfrules` + MCP	`uxskill init --target windsurf`
GitHub Copilot	`copilot-instructions.md`	`uxskill init --target copilot`
Cline / Continue	MCP-Server	`uxskill mcp-config --target cline`
JetBrains AI Assistant	`.junie/guidelines.md`	`uxskill init --target jetbrains`
Zed	MCP stdio	`uxskill init --target zed`
Codex CLI / Aider	Direkte CLI	`pip install uxskill`

Unter allen Pfaden steckt dasselbe: 1.182 Katalogeinträge, 145 Regeln, 131 Markenspezifikationen, 22 Befehle, 75 grüne Tests bei jedem Release.

Ehrlicher Scope

Die Regeln fangen Struktur. Sie fangen keinen Geschmack.

Der Linter wird nie melden „dieser Abschnitt hat den falschen Rhythmus" oder „diese Copy klingt kalt". Das ist die Aufgabe eines Menschen oder eines Review-LLM. Was die Regex dagegen zuverlässig einfängt, ist jeder Fingerprint, der sich als literaler Token, Muster oder Form ausdrücken lässt — also der Großteil aller KI-Defaults, weil das Modell immer wieder zum selben Artefakt zurückkehrt.

Wir lassen bewusst keinen LLM-Judge in der CI laufen. Wenn dein Maßstab „sieht aus wie von einem Designer gemacht" ist, dann ist das Code-Review, kein Lint. ux-skill stellt ux critique für diesen Durchlauf bereit — aber im Editor auf Abruf, nicht in der CI.