Impeccable: Designsprache und deterministische Regeln für KI-Coding-Agenten

Hintergrund und Problemstellung

Nahezu alle großen Sprachmodelle, die zum Programmieren eingesetzt werden, sind auf ungefähr demselben Korpus öffentlichen Webcodes trainiert: dieselben Komponentenbibliotheken, dieselben SaaS-Marketingseiten, dieselben Tailwind-Vorlagen im Dribbble-Stil. Das vorhersehbare Ergebnis ist, dass von KI generierte Frontends unabhängig vom verwendeten Modell auf eine schmale Auswahl visueller Gewohnheiten konvergieren — Inter als Standardschrift, ein Hero-Bereich mit Verlauf von Violett zu Blau, Karten, die in anderen Karten verschachtelt sind, blassgrauer Text auf farbigem Hintergrund und eine abgerundete quadratische Icon-Kachel, die über jeder Abschnittsüberschrift schwebt.

Das sind keine Fehler eines einzelnen Modells, sondern statistische Artefakte der Trainingsdaten, die sich durch Prompt-Engineering nicht zuverlässig beseitigen lassen, weil das Modell weder ein dauerhaftes Gedächtnis dafür hat, was es gestern ausgeliefert hat, noch einen Mechanismus besitzt, um seine eigene Ausgabe mit einem Regelwerk abzugleichen. Anthropics frontend-design-Skill war der erste breit übernommene Versuch, einem Coding-Agenten explizite Designvorgaben zu geben, anstatt das ästhetische Urteil dem Zufall zu überlassen. Impeccable, erstellt von Paul Bakaus, baut auf dieser Grundlage auf, behandelt das zugrunde liegende Problem jedoch als Lücke im Workflow und im Werkzeugkasten statt als Frage einer einzelnen Skill-Datei: Agenten brauchen dauerhaften Produktkontext, der über Sitzungen hinweg bestehen bleibt, ein gemeinsames Vokabular für angeforderte Änderungen und eine Möglichkeit, das Ergebnis zu überprüfen, ohne sich auf die Selbsteinschätzung desselben Modells zu verlassen.

Architektonischer Kern und technische Prinzipien

Impeccable installiert sich als einzelner Skill, der über `/impeccable` aufgerufen wird, doch die eigentliche Architektur liegt in der Trennung zweier Dokumente und zweier Prüfebenen. `PRODUCT.md`, einmalig von `/impeccable init` geschrieben, erfasst dauerhafte Produktwahrheit — Zielgruppe, Zweck, Einsatzkontext, Einschränkungen, Tonalität und Belege — bewusst getrennt von der oberflächlichen visuellen Ausrichtung, die für jede Oberfläche einzeln gewählt und separat in `DESIGN.md` festgehalten wird, sobald ein visuelles System besteht oder aufgebaut wird.

Darauf setzen 24 Befehle auf, die unterschiedlichen Phasen eines Design-Workflows entsprechen: `shape` und `craft` für Planung und Aufbau, `critique` und `audit` für die Überprüfung, `polish`, `harden` und `onboard` für die Produktionsreife sowie ausdrucksstarke Regler-Befehle — `bolder`, `quieter`, `distill`, `animate`, `colorize`, `overdrive` — zum Nachjustieren der Intensität, ohne das gesamte Design erneut zu verhandeln. Die zweite Ebene besteht aus 61 deterministischen Erkennungsregeln, die ohne LLM und ohne API-Schlüssel auskommen, sowohl in der CLI als auch in einer begleitenden Browser-Erweiterung, sodass eine Prüfung von Kontrastverhältnissen, Abstandsrhythmus oder Schriftkombinationsverstößen stets dasselbe Ergebnis liefert, statt eines probabilistischen Urteils, das zwischen Durchläufen oder Modellen schwanken kann.

Praktische Bewertung und Anwendungen

In der Praxis übernimmt ein Projekt Impeccable, indem es einmal `npx impeccable install` ausführt und zu Beginn jedes neuen Vorhabens `/impeccable init`; der Einrichtungsschritt fragt nur nach Lücken im dauerhaften Produktkontext, anstatt das Team erneut zu bereits dokumentierten Fakten zu befragen.

Von dort aus führt `/impeccable craft` einen vollständigen Ablauf aus Konzeption und anschließendem Bau mit Live-Browser-Iteration aus, sodass der Agent seine eigene gerenderte Ausgabe sehen und korrigieren kann, bevor er die Kontrolle zurückgibt. Bei den Überprüfungsbefehlen zählen die deterministischen Regeln am meisten: `/impeccable audit` führt den technischen Durchlauf der 61 Regeln aus — Barrierefreiheit, Leistung, Responsivität —, während `/impeccable critique` qualitativ bleibt und Hierarchie, Klarheit und emotionale Resonanz so beurteilt, wie es eine Design-Leitung in einer Kritiksitzung täte. `/impeccable document` und `/impeccable extract` schließen den Kreis, indem sie `DESIGN.md` aus vorhandenem Code generieren und wiederverwendbare Komponenten und Tokens in ein gemeinsames System überführen — wichtig für Teams, die Impeccable auf einer Codebasis einführen, die bereits eine etablierte, wenn auch undokumentierte, visuelle Sprache besitzt.

Branchenwirkung und Ausblick

Die mehr als 74.000 Sterne, die Impeccable in kurzer Zeit gesammelt hat, zeigen, wie akut Teams das Problem der Gleichförmigkeit empfinden, sobald agentische Coding-Werkzeuge den Großteil des Frontend-Codes selbst schreiben. Der eigentliche Beitrag liegt weniger in den einzelnen Befehlen als in der Forderung, dass die Qualitätsprüfung von KI-generiertem Design dieselbe Strenge verdient wie Testsuiten: deterministisch, wiederholbar und für die Teile, die kein Urteilsvermögen erfordern, ohne Modell in der Schleife ausführbar.

Diese Aufteilung — LLM-Kritik für die subjektive Hälfte, deterministische Regeln für die prüfbare Hälfte — ist das Muster, das die meisten Folgewerkzeuge in diesem Bereich wahrscheinlich übernehmen werden, weil es der einzige Ansatz ist, der die Inkonsistenz vermeidet, dasselbe Modell, das den Code geschrieben hat, auch über dessen Bewertung entscheiden zu lassen. Offen bleibt, wie weit 61 Regeln tragen, während sich Designtrends verschieben; ein Regelwerk, das auf die heutigen „KI-Marker" abgestimmt ist, braucht dieselbe Wartungsdisziplin wie jede Linter-Konfiguration — sonst jagt es nur dem Verlauf von gestern hinterher, während Agenten bereits zum Standard von morgen übergehen.