Der Agent-Stack für Design Engineers

Design Engineers brauchen einen anderen Agent-Stack als reine Entwickler. Die Standard-Agent-Infrastruktur optimiert auf Korrektheit: Tests bestehen, Typen stimmen, Linting-Regeln halten. Niemand hat das Äquivalent für Designqualität gebaut — die Infrastruktur, die sicherstellt, dass Agents Ergebnisse liefern, die durchdacht wirken, nicht bloß funktional. Die sechs Komponenten des Agent-Stacks für Design Engineers sind Typografie-Hooks, Farbsystem-Hooks, Layout-Validierung, Lighthouse-Gates, Accessibility-Linting und visuelle Regressionstests. Zusammen codieren sie Handwerkskunst in die Pipeline.

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

Agent-Infrastruktur für Entwickler hat sich schnell weiterentwickelt. Hooks blockieren gefährliche Git-Befehle. Evidence Gates verlangen Beweise, bevor Arbeit als abgeschlossen markiert wird. Quality Loops schreiben vor, jede Zeile erneut zu lesen. Engineering-Qualität zerlegt sich in verifizierbare Eigenschaften (Korrektheit, Performance, Sicherheit, Typsicherheit), und jede Eigenschaft bildet sich auf ein Werkzeug ab, das binäre Ergebnisse liefert.

Designqualität lässt sich ebenfalls zerlegen. Geschmack ist ein technisches System mit vier codierbaren Komponenten: Einschränkungen, Bewertungskriterien, Mustererkennung und Kohärenz. Die ersten drei lassen sich direkt auf automatisierte Infrastruktur abbilden. Kohärenz erfordert menschliches Urteilsvermögen, doch die drei anderen decken genug ab, um die häufigsten Designfehler zu verhindern, die ein Agent produziert. Typografie-Verstöße, Farbdrift, Layout-Instabilität, Performance-Regressionen und Accessibility-Fehler — all das können Maschinen erkennen. Der Agent-Stack des Design Engineers erkennt sie.

Was Design Engineers von Agents brauchen

Ein reiner Entwickler 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. Ausrichtung respektiert den vertikalen Rhythmus. Proportionale Beziehungen zwischen Elementen bleiben über verschiedene Viewport-Größen 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 auffängt.

Typografische Disziplin. Jede Schriftgröße in der Codebasis bildet sich auf eine Stufe der Schriftskala ab. Keine abtrünnigen Größen. Keine Inline-Überschreibungen, die die Custom Properties umgehen. Die Verwendung der Schriftstärken 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 hardcodierten Hex-Werte außerhalb von :root. Kontrastverhältnisse erfüllen mindestens WCAG AA, wo möglich AAA. Das Zero-Color-System auf meiner Website verwendet vier Opazitätsstufen gegen absolutes Schwarz, und jede Stufe besteht AAA. Ein Agent, der color: #cccccc einführt, hat das Token-System umgangen und ein Kontrastverhältnis geschaffen, das 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 Layout-Neuberechnung auslöst, ist ein Performance-Bug — unabhängig davon, wie die Änderung aussieht.

Accessibility. Semantische HTML-Struktur. Korrekte Überschriften-Hierarchie. ARIA-Attribute wo nötig, abwesend wo nicht. Farbkontrast-Verifizierung. Fokus-Indikatoren. Screenreader-Kompatibilität. Das Lighthouse-Audit fängt die messbare Teilmenge ab, doch der Agent muss auch strukturelle Semantik pflegen, die automatisierte Werkzeuge ü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 Durchdachtheit fehlt.

Sechs Komponenten des Design-Engineer-Stacks

Jede Komponente bildet sich auf einen spezifischen Fehlermodus ab, den ich bei Agent-generiertem Output beobachtet habe. Die Komponenten sind nicht theoretisch. Jede einzelne existiert, weil etwas schiefgelaufen ist — dieselbe Entstehungsgeschichte wie hinter 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 Schriftskala referenziert. Der Hook durchsucht geänderte Dateien nach rohen Pixel- oder Rem-Werten, die sich keiner definierten Stufe zuordnen lassen.

#!/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. Der Punkt ist nicht Raffinesse. Der Punkt ist, dass der Agent keine abtrünnige Schriftgröße einführen kann, ohne dass die Infrastruktur sie markiert. Bringhursts Prinzip harmonischer Schriftbeziehungen gilt nicht, weil der Agent Harmonie versteht, sondern weil der Hook die Skala durchsetzt, die sie verkörpert.¹

Schriftstärken verdienen eine separate Validierung. Mein System verwendet drei Stärken: 700, 400 und 300. Ein Agent, der einen Kartentitel auf font-weight: 600 setzt, hat eine Stärke eingeführt, die der etablierten Hierarchie widerspricht. Ein Typografie-Hook fängt die Abweichung ab, bevor sie die Produktion erreicht.

2. Farbsystem-Hooks

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

Der Farb-Hook durchsucht hardcodierte 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 — dieselbe brutalistische Einschränkung, die die gesamte visuelle Identität der Website bestimmt — macht die Durchsetzung unkompliziert, weil die Palette genau zehn Token umfasst. Jeder Farbwert, der keinem dieser Token entspricht, ist per Definition falsch. Eine breitere Palette würde differenziertere Validierung erfordern. Der einschränkungsbasierte Ansatz vereinfacht den Hook, weil die Einschränkung das Design vereinfacht.

3. Layout-Validierung

Layout-Validierung fängt zwei Fehlerkategorien ab: Cumulative Layout Shift, der durch CSS-Änderungen eingeführt wird, und Regressionen an responsiven Breakpoints.

CLS-Erkennung erfordert die Messung der Seite vor und nach der Änderung. Ein Pre-Commit-Hook kann keinen Browser starten, aber eine CI-Pipeline 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 10x strenger, weil ich gesehen habe, wie ein CLS von 0,493 aussieht und nicht regressieren werde.

Responsive Validierung erfordert die Prüfung des Layouts an definierten Breakpoints. Ein visuelles Regressionswerkzeug erfasst Screenshots bei 375px (Mobil), 768px (Tablet) und 1440px (Desktop) und vergleicht sie mit Baseline-Bildern. Eine Verschiebung von fünf Pixeln im Header bei 375px, die bei 1440px in Ordnung aussieht, taucht im Mobilvergleich auf. Der Agent, der eine max-width-Eigenschaft modifiziert hat, ohne responsives Verhalten zu testen, wird von der Infrastruktur erwischt, die responsives Verhalten automatisch testet.

4. Lighthouse-Gates

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

Die Schwellenwerte sind nicht ambitioniert. Sie spiegeln die aktuellen Produktions-Scores wider. Jeder Commit, der irgendeinen Score unter 100 senkt, wird blockiert. Das Gate läuft in CI mit lighthouse-ci, und die Ergebnisse fließen als Status-Check 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 fängt Performance-Regressionen ab, die kein menschlicher Reviewer bemerken würde. Ein Agent, der ein nicht optimiertes Bild einfügt, ein render-blockierendes Skript oder eine CSS-Datei, die einen Flash of Unstyled Content auslöst, scheitert am Gate, bevor die Änderung die 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 in seinem Kontext für den nächsten Versuch.

5. Accessibility-Linting

Accessibility-Validierung teilt sich in zwei Ebenen: statische Analyse und Laufzeit-Evaluation.

Die statische Analyse führt axe-core gegen das gerenderte HTML aus. Das WCAG 2.1 AA-Regelset fängt fehlenden Alt-Text, fehlerhafte Überschriften-Hierarchie, unzureichenden Farbkontrast, fehlende Formularlabels und ARIA-Missbrauch ab. 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 Laufzeit-Ebene fängt Probleme ab, die die statische Analyse übersieht: Fokus-Management nach HTMX-Swaps, Tastaturnavigation durch dynamische Inhalte, Screenreader-Ankündigungen bei Zustandsänderungen. Diese Prüfungen erfordern skriptgesteuerte Interaktion, nicht bloß DOM-Inspektion. Der No-Build-Ansatz hält die Seite einfach genug, dass die Accessibility-Angriffsfläche überschaubar bleibt.

Accessibility-Linting ist die Komponente, die die meisten Entwickler bereits verstehen. Der Beitrag des Design Engineers ist nicht das Tooling, sondern der Schwellenwert: null Verstöße, nicht „akzeptable” Verstöße. Dieselbe Philosophie treibt die 100/100/100/100 Lighthouse-Scores an: Perfektion als Ausgangslage, nicht als Ziel.

6. Visuelle Regressionstests

Visuelle Regressionstests vergleichen Screenshots des aktuellen Builds mit genehmigten Baselines. Der Vergleich verwendet 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).

Werkzeuge wie Percy, Chromatic und BackstopJS automatisieren den Vergleich. Die Pipeline erfasst 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 in einem Footer ist Rauschen. Eine 2 %-Verschiebung im Hero-Bereich ist eine Regression.

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

Wie sich der Stack auf meine Infrastruktur abbildet

Die sechs Komponenten knüpfen an Entscheidungen an, die bereits in den Inhalten zum Thema Design Engineering auf dieser Website dokumentiert sind.

Die Typografie-Hooks setzen die 13-stufige Schriftskala durch — eine inhaltsgetriebene 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 Token, vier Opazitätsstufen, keine Markenfarben, nicht optional. Die Lighthouse-Gates halten den 100/100/100/100-Score aufrecht und verhindern, dass ein Commit die CSS-Extraktion und die Eliminierung von Render-Blocking rückgängig macht, die diese Zahlen erreicht haben.

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 — das bedeutet, was die Hooks validieren, sieht der Benutzer.

Das Evidence Gate gilt für Design-Reviews genauso wie für Engineering-Reviews. „Die Typografie sieht richtig aus” ist kein Beweis. „Jede font-size-Deklaration im Diff bildet sich auf ein --font-size-*-Token ab, verifiziert durch den Typografie-Hook” ist ein Beweis. Das Designsystem liefert die Token, die die Hooks durchsetzen. Ohne Token gibt es nichts, wogegen validiert werden kann. Ohne Hooks sind die Token Vorschläge. Nathan Curtis identifizierte die Dynamik: Ein System ohne Governance degradiert zu Dokumentation, die niemand liest.²

Die Geschmacksschicht

Die sechs Komponenten fangen Verstöße ab. Typografie-Hooks fangen falsche Schriftgrößen ab. Farb-Hooks fangen hardcodierte Werte ab. Layout-Validierung fängt CLS ab. Lighthouse-Gates fangen Performance-Regressionen ab. Accessibility-Linting fängt WCAG-Fehler ab. Visuelle Regression fängt unbeabsichtigte Änderungen ab.

Nichts davon fängt Output ab, der jede Regel befolgt, sich aber dennoch falsch anfühlt.

Eine Kartenkomponente mit korrekten Schriftgrößen, ordnungsgemäßen Token, null CLS, perfekten Lighthouse-Scores, vollständiger WCAG-Compliance und keiner visuellen 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 sich abrupt anfühlt statt durchdacht. Jede automatisierte Prüfung besteht. Die Karte ist korrekt. Die Karte ist nicht gut.

Geschmack operiert oberhalb der Regelschicht. Einschränkungen fangen ab, was die Regeln verletzt. Bewertungskriterien fangen ab, was die Metriken verfehlt. Mustererkennung fängt ab, was der zweite Blick enthüllt. Kohärenz fängt ab, was nur die Gesamtsicht offenlegt. Die sechs automatisierten Komponenten behandeln Einschränkungen und Bewertungskriterien. Mustererkennung und Kohärenz erfordern den Quality Loop: den vorgeschriebenen 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 Punkt, an dem der Design Engineer die „Engineer”-Hälfte des Titels verdient. Ein Entwickler, der Code ausliefert, der Tests besteht, erfüllt das Minimum. Ein Design Engineer, der Interfaces 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 daruntersetzen?

Der Compound-Effekt

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

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

Eine Agent-Session mit dem Stack kann nicht driften. Die Hooks blockieren jede Abweichung von der Schriftskala. Das Farbsystem weist jeden hardcodierten Wert zurück. Das Lighthouse-Gate fängt jede Performance-Regression ab. 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 Einschränkungen, und die Einschränkungen verkörpern Geschmack.

Jony Ive beschrieb Apples Designprozess als „unermüdliche Verfeinerung”: Qualität durch Iteration auf einer festen Menge von Prinzipien, nicht Innovation durch Neuartigkeit.³ Der Agent-Stack des Design Engineers operationalisiert dieselbe Idee. Die Prinzipien sind in Token, 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, tut mehr als Qualität während autonomer Generierung aufrechtzuerhalten. Dieser Engineer skaliert Qualität. Jede Session, jeder Agent, jeder Commit erbt dieselben Einschränkungen. Der Mensch bewertet weiterhin Kohärenz, durchläuft weiterhin den Quality Loop, fragt weiterhin, ob der Output es verdient, ausgeliefert zu werden. Aber der Mensch fängt nicht mehr Schriftgrößen-Verstöße, hardcodierte Farben oder CLS-Regressionen ab. Der Stack hat sie zuerst gefangen. Die Aufmerksamkeit des Menschen geht vollständig an die Fragen, die Maschinen nicht beantworten können.

FAQ

Brauche ich alle sechs Komponenten, um zu starten?

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. Visuelle Regression und Layout-Validierung sind die infrastrukturintensivsten Komponenten und gehören später in die Einführungsreihenfolge.

Funktioniert der Stack mit Build-Werkzeugen?

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-Werkzeugen müssen Hooks die Quelldateien validieren, während Lighthouse und visuelle Regression den gebauten Output validieren. Die Komponenten bleiben dieselben. Die Integrationspunkte ändern sich.

Können Agents Geschmack ohne den Stack lernen?

Aktuelle Sprachmodelle haben keinen Geschmack. Modelle produzieren statistisch wahrscheinlichen Output, und statistisch wahrscheinlicher Output tendiert zum Median der Trainingsdaten. Der Stack lehrt Agents keinen Geschmack. Der Stack schränkt Agents ein, sodass die Pipeline geschmacklosen Output zurückweist, bevor er ausgeliefert wird. Die Unterscheidung ist wichtig: Geschmack als Infrastruktur zu codieren erweist sich als 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 prüft und genehmigt sie, wodurch die Baseline aktualisiert wird. Der Wert visueller Regression liegt nicht darin, Änderungen zu verhindern, sondern unbeabsichtigte Änderungen aufzudecken. Ein Agent, der eine Button-Farbe ändert, verschiebt auch das Kartenlayout um drei Pixel. Die Farbänderung ist beabsichtigt, die Layoutverschiebung nicht — und der visuelle Regressionstest fängt den Nebeneffekt ab.

Quellen