Der Agent-Stack für Design Engineers

Design Engineers brauchen einen anderen Agent-Stack als reine Software-Ingenieure. Die gängige Agent-Infrastruktur optimiert auf Korrektheit: Tests bestehen, Typen stimmen, Linting-Regeln greifen. Niemand hat das Äquivalent für Designqualität gebaut — eine Infrastruktur, die sicherstellt, dass Agents Ergebnisse produzieren, die durchdacht wirken, nicht bloß funktional. Die sechs Komponenten des Design-Engineer-Agent-Stacks sind Typografie-Hooks, Farbsystem-Hooks, Layout-Validierung, Lighthouse-Gates, Accessibility-Linting und visuelles Regressionstesting. Gemeinsam codieren sie Handwerkskunst in die Pipeline.

Die Lücke zeigt sich in jeder KI-generierten Oberfläche. Die Abstände sind inkonsistent. Schriftgrößen driften außerhalb der Skala. Hartcodierte Hex-Werte umgehen das Token-System. Layout-Verschiebungen treten mobil auf, weil niemand CLS geprüft hat, nachdem der Agent das CSS modifiziert hat. Der Agent hat jeden Test bestanden, jeden Type-Check erfüllt und Output produziert, den ein Code-Reviewer freigeben würde — denn Code-Reviewer bewerten Logik, nicht visuelle Kohärenz. Dem Design Engineer fallen die Probleme sofort auf. Der Agent-Infrastruktur fällt nichts auf, weil niemand ihr gesagt hat, worauf sie achten soll.

Agent-Infrastruktur für Ingenieure hat sich rasant weiterentwickelt. Hooks blockieren gefährliche Git-Befehle. Evidence Gates verlangen Nachweise, bevor Arbeit als abgeschlossen markiert wird. Quality Loops schreiben vor, jede Zeile erneut zu lesen. Ingenieurqualität lässt sich in überprüfbare Eigenschaften zerlegen — Korrektheit, Performance, Sicherheit, Typsicherheit — und jede Eigenschaft wird von einem Tool abgebildet, das binäre Ergebnisse liefert.

Designqualität lässt sich ebenso zerlegen. Geschmack ist ein technisches System mit vier codierbaren Komponenten: Constraints, Bewertungskriterien, Mustererkennung und Kohärenz. Die ersten drei lassen sich direkt auf automatisierte Infrastruktur abbilden. Kohärenz erfordert menschliches Urteilsvermögen, doch die ersten drei decken genug ab, um die häufigsten Designfehler zu verhindern, die ein Agent produziert. Typografieverstöße, Farbdrift, Layout-Instabilität, Performance-Regressionen und Accessibility-Fehler sind allesamt maschinell erkennbar. Der Agent-Stack des Design Engineers erkennt sie.

Was Design Engineers von Agents brauchen

Ein reiner Ingenieur fragt: Funktioniert der Code? Ein Design Engineer stellt sechs zusätzliche Fragen, die jeweils eine andere Dimension visueller Qualität adressieren.

Visuelle Konsistenz. Abstandswerte folgen dem 8-Punkt-Raster oder der definierten Spacing-Skala. Die Ausrichtung respektiert den vertikalen Rhythmus. Proportionale Beziehungen zwischen Elementen bleiben über Viewport-Größen hinweg stabil. Ein Agent, der eine neue Kartenkomponente mit margin-top: 13px statt var(--space-md) einfügt, hat visuelles Rauschen eingeführt, das kein Test erfassen wird.

Typografische Disziplin. Jede Schriftgröße in der Codebasis entspricht einer Stufe der Typoskala. Keine abweichenden Größen. Keine Inline-Überschreibungen, die an den Custom Properties vorbei gehen. Die Schriftgewichtung folgt der etablierten Hierarchie: 700 für Überschriften, 400 für Fließtext, 300 für Metadaten. Ein Agent, der einen Untertitel auf font-size: 19px setzt, hat eine Stufe erfunden, die in der Skala nicht existiert — und die visuelle Hierarchie zerbricht.

Farbsystem-Compliance. Jeder Farbwert referenziert ein Design-Token. Keine hartcodierten Hex-Werte außerhalb von :root. Kontrastwerte erfüllen mindestens WCAG AA, wo möglich AAA. Das Zero-Color-System auf meiner Site nutzt vier Opazitätsstufen gegen absolutes Schwarz, und jede Stufe besteht AAA. Ein Agent, der color: #cccccc einführt, hat das Token-System umgangen und eine Kontrastbeziehung geschaffen, die niemand validiert hat.

Performance-Bewusstsein. Kein Cumulative Layout Shift. First Contentful Paint bleibt im Budget. Total Blocking Time verschlechtert sich nicht. Der Agent muss verstehen, dass visuelle Änderungen Performance-Konsequenzen haben — eine CSS-Änderung, die bei jedem Scroll-Event eine Layoutneuberechnung auslöst, ist ein Performance-Bug, unabhängig davon, wie die Änderung aussieht.

Accessibility. Semantische HTML-Struktur. Korrekte Überschriftenhierarchie. ARIA-Attribute dort, wo sie nötig sind, fehlend, wo nicht. Farbkontrastprüfung. Fokusindikatoren. Screenreader-Kompatibilität. Das Lighthouse-Audit erfasst die messbare Teilmenge, doch der Agent muss auch strukturelle Semantik aufrechterhalten, die automatisierte Tools übersehen.

Geschmack. Am schwierigsten zu codieren. Kohärenz zwischen Elementen. Zurückhaltung bei Dekoration. Bewusster Weißraum statt zufälliger Leere. Geschmack ist die Qualität, die ein Layout, das jede Regel befolgt, aber sich falsch anfühlt, von einem Layout unterscheidet, das jede Regel befolgt und sich richtig anfühlt. Automatisierte Prüfungen fangen Verstöße ab. Die Geschmacksschicht fängt Nicht-Verstöße ab, denen dennoch Überlegung fehlt.

Sechs Komponenten des Design-Engineer-Stacks

Jede Komponente adressiert einen spezifischen Fehlermodus, den ich in agent-generiertem Output beobachtet habe. Die Komponenten sind nicht theoretisch. Jede einzelne existiert, weil etwas schiefgelaufen ist — dieselbe Entstehungsgeschichte wie bei jedem Hook in meiner 95-Hook-Infrastruktur.

1. Typografie-Hooks

Ein Typografie-Hook validiert, dass jede font-size-Deklaration in einem Commit eine CSS Custom Property aus der Typoskala referenziert. Der Hook durchsucht geänderte Dateien nach rohen Pixel- oder Rem-Werten, die keiner definierten Stufe zugeordnet sind.

#!/bin/bash
INPUT=$(cat)
DIFF=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Catch font-size declarations that bypass the type scale
if echo "$DIFF" | grep -qE 'font-size:\s*[0-9]+(px|rem|em)'; then
  cat << EOF
{"decision": "block", "reason": "Font size must use a --font-size-* token"}
EOF
fi

Der Hook ist grob. Eine verfeinerte Version parst den Wert und prüft, ob das Pixeläquivalent einer Stufe in der 13-stufigen Skala entspricht. Entscheidend ist nicht die Raffinesse. Entscheidend ist, dass der Agent keine abweichende Schriftgröße einführen kann, ohne dass die Infrastruktur sie markiert. Bringhursts Prinzip harmonischer Schriftbeziehungen hält nicht, weil der Agent Harmonie versteht, sondern weil der Hook die Skala durchsetzt, die sie verkörpert.¹

Schriftgewichte verdienen eine separate Validierung. Mein System verwendet drei Gewichte: 700, 400 und 300. Ein Agent, der einen Kartentitel auf font-weight: 600 setzt, hat ein Gewicht eingeführt, das der etablierten Hierarchie widerspricht. Ein Typografie-Hook erkennt die Abweichung, bevor sie in Produktion gelangt.

2. Farbsystem-Hooks

Farbdrift ist der häufigste Designfehler in agent-generiertem CSS. Der Agent weiß, dass Text auf dunklem Hintergrund weiß sein sollte. Er weiß allerdings nicht, dass #ffffff eigentlich var(--color-text-primary) sein sollte, oder dass Sekundärtext bei 65 % Opazität var(--color-text-secondary) ist und nicht rgba(255,255,255,0.60).

Der Farb-Hook durchsucht hartcodierte Farbwerte außerhalb von :root und den Design-Token-Definitionen:

# Block hardcoded colors outside token definitions
if echo "$DIFF" | grep -vE '^\+.*:root' | \
   grep -qE '#[0-9a-fA-F]{3,8}|rgba?\('; then
  cat << EOF
{"decision": "block", "reason": "Use color tokens, not hardcoded values"}
EOF
fi

Das Zero-Color-Designsystem — derselbe brutalistische Constraint, der die gesamte visuelle Identität der Site bestimmt — macht die Durchsetzung unkompliziert, weil die Palette genau zehn Tokens umfasst. Jeder Farbwert, der nicht einem dieser Tokens entspricht, ist per Definition falsch. Eine breitere Palette würde differenziertere Validierung erfordern. Der Constraint-basierte Ansatz vereinfacht den Hook, weil der Constraint das Design vereinfacht.

3. Layout-Validierung

Layout-Validierung erkennt zwei Fehlerkategorien: Cumulative Layout Shift durch CSS-Änderungen und Responsive-Breakpoint-Regressionen.

CLS-Erkennung erfordert die Messung der Seite vor und nach der Änderung. Ein Pre-Commit-Hook kann keinen Browser starten, eine CI-Pipeline hingegen schon. Die Infrastruktur führt Lighthouse in Headless Chrome gegen das Staging-Deployment aus, vergleicht CLS-Werte mit dem vorherigen Build und blockiert den Merge, wenn das Delta 0,01 überschreitet. Google betrachtet CLS unter 0,1 als „gut”. Mein Schwellenwert ist zehnmal strenger, weil ich gesehen habe, wie CLS von 0,493 aussieht, und eine Regression ablehne.

Responsive-Validierung erfordert die Prüfung des Layouts an definierten Breakpoints. Ein visuelles Regressionstool erstellt Screenshots bei 375px (Mobil), 768px (Tablet) und 1440px (Desktop) und vergleicht sie mit Baseline-Bildern. Eine Fünf-Pixel-Verschiebung im Header bei 375px, die bei 1440px normal aussieht, wird im mobilen Vergleich sichtbar. Der Agent, der eine max-width-Eigenschaft ohne Test des responsiven Verhaltens geändert hat, wird von der Infrastruktur erwischt, die responsives Verhalten automatisch prüft.

4. Lighthouse-Gates

Ein Lighthouse-Gate führt vor jedem Merge in den Hauptbranch ein vollständiges Audit durch. Das Gate erzwingt vier Schwellenwerte:

Die Schwellenwerte sind keine Wunschvorstellung. Sie spiegeln die aktuellen Produktionswerte wider. Jeder Commit, der einen Wert unter 100 senkt, wird blockiert. Das Gate läuft in CI mit lighthouse-ci, und die Ergebnisse fließen als Statusprüfung in den Pull Request zurück.

# lighthouse-ci configuration
assertions:
  performance: ["error", { minScore: 1 }]
  accessibility: ["error", { minScore: 1 }]
  best-practices: ["error", { minScore: 1 }]
  seo: ["error", { minScore: 1 }]
  cumulative-layout-shift: ["error", { maxNumericValue: 0.01 }]

Das Lighthouse-Gate erkennt Performance-Regressionen, die kein menschlicher Reviewer bemerken würde. Ein Agent, der ein nicht optimiertes Bild, ein Render-blockierendes Skript oder eine CSS-Datei einfügt, die einen Flash of Unstyled Content auslöst, scheitert am Gate, bevor die Änderung Produktion erreicht. Das Gate versteht nicht, warum die Änderung eine Regression verursacht hat. Das Gate muss es nicht verstehen. Es blockiert die Regression, und der Agent erhält den Fehlergrund für den nächsten Versuch in seinem Kontext.

5. Accessibility-Linting

Accessibility-Validierung teilt sich in zwei Schichten: statische Analyse und Laufzeitbewertung.

Die statische Analyse führt axe-core gegen das gerenderte HTML aus. Das WCAG 2.1 AA-Regelwerk erkennt fehlende Alt-Texte, fehlerhafte Überschriftenhierarchie, unzureichende Farbkontraste, fehlende Formularbeschriftungen und ARIA-Missbrauch. Die Prüfung läuft in derselben Headless-Chrome-Instanz wie das Lighthouse-Gate und verursacht vernachlässigbaren Overhead.

// axe-core integration in CI
const { AxeBuilder } = require('@axe-core/playwright');
const results = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
  .analyze();

if (results.violations.length > 0) {
  process.exit(1); // Block the merge
}

Die Laufzeitschicht erkennt Probleme, die der statischen Analyse entgehen: Fokusverwaltung nach HTMX-Swaps, Tastaturnavigation durch dynamische Inhalte, Screenreader-Ansagen bei Zustandsänderungen. Diese Prüfungen erfordern skriptgesteuerte Interaktion, nicht nur DOM-Inspektion. Der No-Build-Ansatz hält die Seite einfach genug, damit die Accessibility-Oberfläche überschaubar bleibt.

Accessibility-Linting ist die Komponente, die die meisten Ingenieure bereits verstehen. Der Beitrag des Design Engineers liegt nicht im Tooling, sondern im Schwellenwert: null Verstöße, nicht „akzeptable” Verstöße. Dieselbe Philosophie hinter 100/100/100/100 Lighthouse-Scores — Perfektion als Grundlinie, nicht als Ambition.

6. Visuelles Regressionstesting

Visuelles Regressionstesting vergleicht Screenshots des aktuellen Builds mit genehmigten Baselines. Der Vergleich nutzt perzeptuelle Diffing-Algorithmen, die Änderungen erkennen, die ein Mensch bemerken würde, während sie Änderungen ignorieren, die ein Mensch nicht bemerken würde (Sub-Pixel-Rendering-Unterschiede, Anti-Aliasing-Variationen).

Tools wie Percy, Chromatic und BackstopJS automatisieren den Vergleich. Die Pipeline erstellt Screenshots an jedem definierten Breakpoint, führt perzeptuelles Diffing gegen die Baseline durch und markiert jede Seite, bei der der Diff den Schwellenwert überschreitet. Ein 0,1 % Pixelunterschied im Footer ist Rauschen. Eine 2 %-Verschiebung im Hero-Bereich ist eine Regression.

Visuelles Regressionstesting ist die genaueste automatisierte Annäherung an „Sieht die Seite richtig aus?” Perzeptuelles Diffing kann nicht bewerten, ob eine Layoutänderung eine Verbesserung oder eine Verschlechterung darstellt, sondern nur, dass eine Änderung stattgefunden hat. Der Mensch überprüft markierte Diffs und genehmigt oder verwirft sie. Der Wert der Automatisierung liegt in der Abdeckung: jede Seite an jedem Breakpoint bei jedem Commit zu testen — eine Aufgabe, die kein Mensch manuell durchführt.

Wie der Stack auf meine Infrastruktur abbildet

Die sechs Komponenten knüpfen an Entscheidungen an, die bereits im Design-Engineering-Content auf dieser Site dokumentiert sind.

Die Typografie-Hooks setzen die 13-stufige Typoskala durch — eine inhaltsorientierte Progression, bei der die Skala als CSS Custom Properties existiert und die Hooks sicherstellen, dass diese Properties die einzigen Schriftgrößen in der Codebasis sind. Die Farbsystem-Hooks setzen das Zero-Color-Designsystem durch: zehn Tokens, vier Opazitätsstufen, keine Markenfarben, nicht verhandelbar. Die Lighthouse-Gates halten den 100/100/100/100-Score aufrecht und verhindern, dass ein Commit die CSS-Extraktion und Render-Blocking-Elimination rückgängig macht, die diese Werte erzielt hat.

Der No-Build-Ansatz vereinfacht den gesamten Stack. Keine Source Maps zum Abgleichen. Keine Tree-Shaking-Ambiguität. Keine Transpilationsschicht zwischen verfasstem und ausgeliefertem CSS. Was der Agent schreibt, wird ausgeliefert — was bedeutet, dass das, was die Hooks validieren, auch das ist, was der Benutzer sieht.

Das Evidence Gate gilt für Design-Reviews genauso wie für Engineering-Reviews. „Die Typografie sieht richtig aus” ist kein Beleg. „Jede font-size-Deklaration im Diff ist einem --font-size-*-Token zugeordnet, verifiziert durch den Typografie-Hook” ist ein Beleg. Das Designsystem stellt die Tokens bereit, die die Hooks durchsetzen. Ohne Tokens gibt es nichts, wogegen validiert werden kann. Ohne Hooks sind die Tokens bloße Empfehlungen. Nathan Curtis hat diese Dynamik identifiziert — ein System ohne Governance degeneriert zu Dokumentation, die niemand liest.²

Die Geschmacksschicht

Die sechs Komponenten erkennen Verstöße. Typografie-Hooks erkennen falsche Schriftgrößen. Farb-Hooks erkennen hartcodierte Werte. Layout-Validierung erkennt CLS. Lighthouse-Gates erkennen Performance-Regressionen. Accessibility-Linting erkennt WCAG-Fehler. Visuelles Regressionstesting erkennt unbeabsichtigte Änderungen.

Keine davon erkennt den Output, der jede Regel befolgt, sich aber trotzdem falsch anfühlt.

Eine Kartenkomponente mit korrekten Schriftgrößen, richtigen Tokens, null CLS, perfekten Lighthouse-Scores, voller WCAG-Compliance und ohne visuelle Regression — aber mit Abständen, die den Titel an das Bild drängen, einer Zeilenlänge, die die Lesbarkeit strapaziert, und einem Hover-Zustand, der abrupt statt durchdacht wirkt. Jede automatisierte Prüfung besteht. Die Karte ist korrekt. Die Karte ist nicht gut.

Geschmack operiert über der Regelschicht. Constraints erkennen, was die Regeln verletzt. Bewertungskriterien erkennen, was die Metriken verfehlt. Mustererkennung erkennt, was der zweite Blick offenbart. Kohärenz erkennt, was nur die Gesamtsystemsicht enthüllt. Die sechs automatisierten Komponenten decken Constraints und Bewertungskriterien ab. Mustererkennung und Kohärenz erfordern den Quality Loop — den verpflichtenden zweiten (und dritten und vierten) Durchgang durch die Arbeit, bei dem nicht geprüft wird, ob die Regeln halten, sondern ob das Ergebnis es verdient, ausgeliefert zu werden.

Der Quality Loop ist der Moment, in dem der Design Engineer den „Engineer”-Teil seines Titels verdient. Ein Ingenieur, der Code ausliefert, der Tests besteht, leistet das Minimum. Ein Design Engineer, der Oberflächen ausliefert, die automatisierte Prüfungen bestehen und den Quality Loop überstehen, hält einen Standard aufrecht, den Maschinen noch nicht bewerten können. Der Pride Check stellt fünf Fragen, und die letzte — „Habe ich es besser hinterlassen?” — hat kein automatisiertes Äquivalent. Ebenso wenig das Steve-Kriterium: Würde Blake seinen Namen darunter setzen?

Der Verbundeffekt

Jede Komponente verhindert eine spezifische Kategorie von Designfehlern. Zusammen erzeugen die Komponenten einen Verbundeffekt, der die Summe der einzelnen Prüfungen übersteigt.

Eine Agent-Sitzung ohne den Stack produziert Output, der driftet. Schriftgrößen sammeln sich außerhalb der Skala an. Farbwerte werden hartcodiert statt tokenisiert. Performance verschlechtert sich in kleinen Schritten, die kein einzelner Commit auslöst, die sich aber über Wochen akkumulieren. Der Drift ist in jedem einzelnen Diff unsichtbar und im Aggregat offensichtlich.

Eine Agent-Sitzung mit dem Stack kann nicht driften. Jede Abweichung von der Typoskala wird blockiert. Jede hartcodierte Farbe wird abgelehnt. Jede Performance-Regression wird erkannt. Der Agent erbt die Standards des Design Engineers nicht, weil der Agent diese Standards versteht, sondern weil die Infrastruktur sie durchsetzt. Der Agent braucht keinen Geschmack. Der Agent braucht Constraints, und die Constraints verkörpern Geschmack.

Jony Ive beschrieb Apples Designprozess als „unermüdliche Verfeinerung” — Qualität durch Iteration auf einem festen Satz von Prinzipien, nicht Innovation durch Neuartigkeit.³ Der Agent-Stack des Design Engineers operationalisiert dieselbe Idee. Die Prinzipien sind in Tokens, Skalen und Schwellenwerten fixiert. Die Verfeinerung ist unermüdlich, weil die Automatisierung bei jedem Commit läuft.

Der Design Engineer, der Standards in den Agent-Stack codiert, erhält nicht nur die Qualität während autonomer Generierung aufrecht. Dieser Engineer skaliert Qualität. Jede Sitzung, jeder Agent, jeder Commit erbt dieselben Constraints. Der Mensch bewertet weiterhin Kohärenz, durchläuft weiterhin den Quality Loop, fragt sich weiterhin, ob der Output es verdient, ausgeliefert zu werden. Doch der Mensch fängt keine Schriftgrößenverstöße, hartcodierten Farben oder CLS-Regressionen mehr ab. Der Stack hat sie zuerst erkannt. Die Aufmerksamkeit des Menschen fließt ausschließlich in die Fragen, die Maschinen nicht beantworten können.

FAQ

Brauche ich alle sechs Komponenten zum Start?

Nein. Beginnen Sie mit der Komponente, die Ihren häufigsten Fehlermodus adressiert. Typografie-Hooks und Farbsystem-Hooks bieten den höchsten Ertrag, weil sie die häufigsten agent-generierten Designfehler abfangen. Fügen Sie als Nächstes Lighthouse-Gates und Accessibility-Linting hinzu. Visuelles Regressionstesting und Layout-Validierung sind die infrastrukturintensivsten Komponenten und gehören an das Ende der Einführungssequenz.

Funktioniert der Stack mit Build-Tools?

Der Stack funktioniert mit jeder Frontend-Architektur. Der No-Build-Ansatz vereinfacht die Implementierung, weil es keine Transformationsschicht zwischen verfasstem und ausgeliefertem Code gibt. Mit Build-Tools müssen Hooks die Quelldateien validieren, während Lighthouse und visuelles Regressionstesting den gebauten Output validieren. Die Komponenten bleiben dieselben. Die Integrationspunkte ändern sich.

Können Agents ohne den Stack Geschmack lernen?

Aktuelle Sprachmodelle besitzen keinen Geschmack. Modelle produzieren statistisch wahrscheinlichen Output, und statistisch wahrscheinlicher Output tendiert zum Median der Trainingsdaten. Der Stack lehrt Agents keinen Geschmack. Der Stack beschränkt Agents so, dass geschmackloser Output abgelehnt wird, bevor er ausgeliefert wird. Der Unterschied ist wesentlich: Geschmack als Infrastruktur zu codieren, ist zuverlässiger als darauf zu hoffen, dass das Modell ihn aus dem Prompt internalisiert.

Wie gehen visuelle Regressionstests mit beabsichtigten Änderungen um?

Beabsichtigte Änderungen erzeugen erwartete visuelle Diffs. Der Workflow markiert die Diffs, und der Mensch überprüft und genehmigt sie, wobei die Baseline aktualisiert wird. Der Wert von visuellem Regressionstesting liegt nicht darin, Änderungen zu verhindern, sondern unbeabsichtigte Änderungen aufzudecken. Ein Agent, der eine Buttonfarbe ändert, verschiebt zugleich das Kartenlayout um drei Pixel — die Farbänderung ist beabsichtigt, die Layoutverschiebung nicht, und der visuelle Regressionstest erkennt den Seiteneffekt.

Quellen