Stos agentowy inżyniera designu

Inżynierowie designu potrzebują innego stosu agentowego niż programiści. Standardowa infrastruktura agentowa optymalizuje pod kątem poprawności: testy przechodzą, typy się zgadzają, reguły lintera są spełnione. Nikt nie zbudował odpowiednika dla jakości designu — infrastruktury zapewniającej, że agenty tworzą pracę wyglądającą na przemyślaną, a nie jedynie funkcjonalną. Sześć komponentów stosu agentowego inżyniera designu to hooki typograficzne, hooki systemu kolorów, walidacja layoutu, bramki Lighthouse, linting dostępności oraz wizualne testy regresji. Razem kodują rzemiosło w pipeline.

Lukę tę widać w każdym interfejsie wygenerowanym przez AI. Odstępy są niespójne. Rozmiary czcionek wykraczają poza skalę. Zakodowane na sztywno wartości hex omijają system tokenów. Na urządzeniach mobilnych pojawiają się przesunięcia layoutu, bo nikt nie sprawdził CLS po tym, jak agent zmodyfikował CSS. Agent przeszedł każdy test, spełnił każde sprawdzenie typów i wyprodukował kod, który recenzent by zaakceptował — ponieważ recenzenci kodu oceniają logikę, nie spójność wizualną. Inżynier designu natychmiast zauważa problemy. Infrastruktura agentowa nie zauważa niczego, bo nikt jej nie powiedział, czego szukać.

Infrastruktura agentowa dla programistów dojrzała szybko. Hooki blokują niebezpieczne polecenia git. Bramki dowodowe wymagają potwierdzenia przed oznaczeniem pracy jako ukończonej. Pętle jakości nakazują ponowne przeczytanie każdej linii. Jakość inżynierska rozkłada się na weryfikowalne właściwości (poprawność, wydajność, bezpieczeństwo, bezpieczeństwo typów), a każda właściwość mapuje się na narzędzie dające binarne wyniki.

Jakość designu również da się rozłożyć. Gust to system techniczny z czterema kodowalnymi komponentami: ograniczeniami, kryteriami oceny, rozpoznawaniem wzorców i spójnością. Trzy pierwsze mapują się bezpośrednio na zautomatyzowaną infrastrukturę. Spójność wymaga ludzkiego osądu, ale te trzy pokrywają wystarczająco dużo terenu, by zapobiec najczęstszym błędom designu generowanym przez agenta. Naruszenia typografii, dryfowanie kolorów, niestabilność layoutu, regresje wydajności i błędy dostępności — wszystko to jest wykrywalne maszynowo. Stos agentowy inżyniera designu je wykrywa.

Czego inżynierowie designu potrzebują od agentów

Programista pyta: czy kod działa? Inżynier designu zadaje sześć dodatkowych pytań, z których każde dotyczy innego wymiaru jakości wizualnej.

Spójność wizualna. Wartości odstępów podążają za siatką 8-punktową lub zdefiniowaną skalą odstępów. Wyrównanie respektuje rytm pionowy. Proporcjonalne relacje między elementami pozostają stabilne w różnych rozmiarach okna przeglądarki. Agent, który dodaje nowy komponent karty z margin-top: 13px zamiast var(--space-md), wprowadza szum wizualny, którego żaden test nie wykryje.

Dyscyplina typograficzna. Każdy rozmiar czcionki w kodzie odpowiada krokowi w skali typograficznej. Żadnych niekontrolowanych rozmiarów. Żadnych nadpisań inline omijających właściwości niestandardowe. Użycie grubości czcionki podąża za ustaloną hierarchią: 700 dla nagłówków, 400 dla treści, 300 dla metadanych. Agent, który ustawia podtytuł na font-size: 19px, wymyślił krok nieistniejący w skali — a hierarchia wizualna się rozpada.

Zgodność systemu kolorów. Każda wartość koloru odwołuje się do tokena designu. Żadnych zakodowanych wartości hex poza :root. Współczynniki kontrastu spełniają minimum WCAG AA, a najlepiej AAA. System zero kolorów na mojej stronie używa czterech poziomów przezroczystości na tle absolutnej czerni, a każdy poziom spełnia AAA. Agent, który wprowadza color: #cccccc, omija system tokenów i tworzy relację kontrastową, której nikt nie zweryfikował.

Świadomość wydajności. Brak Cumulative Layout Shift. First Contentful Paint mieści się w budżecie. Total Blocking Time nie rośnie. Agent musi rozumieć, że zmiany wizualne mają konsekwencje wydajnościowe. Zmiana CSS, która wywołuje przeliczenie layoutu przy każdym przewijaniu, to błąd wydajności — niezależnie od tego, jak zmiana wygląda.

Dostępność. Semantyczna struktura HTML. Prawidłowa hierarchia nagłówków. Atrybuty ARIA tam, gdzie potrzeba, nieobecne tam, gdzie nie. Weryfikacja kontrastu kolorów. Wskaźniki fokusu. Kompatybilność z czytnikami ekranowymi. Audyt Lighthouse wychwytuje mierzalny podzbiór, ale agent musi również utrzymywać semantykę strukturalną, której zautomatyzowane narzędzia nie dostrzegają.

Gust. Najtrudniejszy do zakodowania. Spójność między elementami. Powściągliwość w dekoracji. Zamierzona biała przestrzeń zamiast przypadkowej pustki. Gust to cecha odróżniająca layout, który spełnia każdą regułę, ale wydaje się niewłaściwy, od layoutu, który spełnia każdą regułę i wydaje się właściwy. Automatyczne sprawdzenia wychwytują naruszenia. Warstwa gustu wychwytuje to, co naruszeniem nie jest, a mimo to brakuje mu przemyślenia.

Sześć komponentów stosu inżyniera designu

Każdy komponent odpowiada konkretnemu trybowi awarii, który zaobserwowałem w kodzie generowanym przez agenty. Komponenty nie są teoretyczne. Każdy istnieje, bo coś poszło nie tak — ta sama geneza, która stoi za każdym hookiem w mojej infrastrukturze 95 hooków.

1. Hooki typograficzne

Hook typograficzny sprawdza, czy każda deklaracja font-size w commicie odwołuje się do właściwości niestandardowej CSS ze skali typograficznej. Hook skanuje zmienione pliki w poszukiwaniu surowych wartości pikselowych lub rem, które nie mapują się na zdefiniowany krok.

#!/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

Hook jest prosty. Bardziej wyrafinowana wersja parsuje wartość i sprawdza, czy odpowiednik w pikselach pasuje do któregokolwiek kroku w 13-stopniowej skali. Nie chodzi o wyrafinowanie. Chodzi o to, że agent nie może wprowadzić niekontrolowanego rozmiaru czcionki, jeśli infrastruktura to flaguje. Zasada Bringhursta dotycząca harmonijnych relacji typograficznych działa nie dlatego, że agent rozumie harmonię, lecz dlatego, że hook wymusza skalę, która ją ucieleśnia.¹

Grubość czcionki zasługuje na osobną walidację. Mój system używa trzech grubości: 700, 400 i 300. Agent, który ustawia tytuł karty na font-weight: 600, wprowadza grubość sprzeczną z ustaloną hierarchią. Hook typograficzny wychwytuje odchylenie, zanim trafi do produkcji.

2. Hooki systemu kolorów

Dryfowanie kolorów to najczęstszy błąd designu w CSS generowanym przez agenty. Agent wie, że tekst powinien być biały na ciemnym tle. Agent nie wie, że #ffffff powinno być var(--color-text-primary) ani że tekst drugorzędny przy 65% przezroczystości to var(--color-text-secondary), a nie rgba(255,255,255,0.60).

Hook kolorów skanuje w poszukiwaniu zakodowanych wartości kolorów poza :root i definicjami tokenów designu:

# 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

System designu zero kolorów, to samo brutalistyczne ograniczenie, które napędza całą tożsamość wizualną strony, sprawia, że egzekwowanie jest proste — paleta ma dokładnie dziesięć tokenów. Każda wartość koloru, która nie pasuje do jednego z tych tokenów, jest z definicji błędna. Szersza paleta wymagałaby bardziej zniuansowanej walidacji. Podejście oparte na ograniczeniach upraszcza hook, ponieważ ograniczenie upraszcza design.

3. Walidacja layoutu

Walidacja layoutu wychwytuje dwie kategorie błędów: Cumulative Layout Shift wprowadzony przez zmiany CSS oraz regresje na breakpointach responsywnych.

Wykrywanie CLS wymaga pomiaru strony przed i po zmianie. Hook pre-commit nie jest w stanie uruchomić przeglądarki, ale pipeline CI już tak. Infrastruktura uruchamia Lighthouse w headless Chrome na wdrożeniu stagingowym, porównuje wartości CLS z poprzednim buildem i blokuje merge, jeśli delta przekracza 0,01. Google uznaje CLS poniżej 0,1 za „dobry”. Mój próg jest 10 razy surowszy, bo widziałem, jak wygląda CLS 0,493 i nie zamierzam regresować.

Walidacja responsywna wymaga sprawdzenia layoutu na zdefiniowanych breakpointach. Narzędzie do wizualnych testów regresji wykonuje zrzuty ekranu przy 375px (mobile), 768px (tablet) i 1440px (desktop), a następnie porównuje je z obrazami bazowymi. Pięciopikselowe przesunięcie w nagłówku przy 375px, które wygląda dobrze przy 1440px, ujawnia się w porównaniu mobilnym. Agent, który zmodyfikował właściwość max-width bez testowania zachowania responsywnego, zostaje złapany przez infrastrukturę, która testuje zachowanie responsywne automatycznie.

4. Bramki Lighthouse

Bramka Lighthouse uruchamia pełny audyt przed każdym merge do głównej gałęzi. Bramka wymusza cztery progi:

Progi nie są aspiracyjne. Odzwierciedlają aktualne wyniki produkcyjne. Każdy commit obniżający jakikolwiek wynik poniżej 100 zostaje zablokowany. Bramka działa w CI za pomocą lighthouse-ci, a wyniki trafiają z powrotem do pull requesta jako sprawdzenie statusu.

# 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 }]

Bramka Lighthouse wychwytuje regresje wydajności, których żaden recenzent nie zauważyłby. Agent, który dodaje niezoptymalizowany obraz, skrypt blokujący renderowanie lub plik CSS wywołujący błysk niestylizowanej treści, nie przechodzi bramki, zanim zmiana trafi do produkcji. Bramka nie rozumie, dlaczego zmiana spowodowała regresję. Bramka nie musi rozumieć. Blokuje regresję, a agent otrzymuje przyczynę niepowodzenia w swoim kontekście przy następnej próbie.

5. Linting dostępności

Walidacja dostępności dzieli się na dwie warstwy: analizę statyczną i ewaluację w czasie wykonania.

Analiza statyczna uruchamia axe-core na wyrenderowanym HTML. Zestaw reguł WCAG 2.1 AA wychwytuje brakujący tekst alternatywny, niewłaściwą hierarchię nagłówków, niewystarczający kontrast kolorów, brakujące etykiety formularzy oraz błędne użycie ARIA. Sprawdzenie działa w tej samej instancji headless Chrome co bramka Lighthouse i dodaje znikomy narzut.

// 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
}

Warstwa wykonawcza wychwytuje problemy, których analiza statyczna nie dostrzega: zarządzanie fokusem po swapach HTMX, nawigacja klawiaturą przez dynamiczną treść, komunikaty czytnika ekranowego o zmianach stanu. Te sprawdzenia wymagają skryptowanej interakcji, a nie samej inspekcji DOM. Podejście bez etapu budowania utrzymuje stronę na tyle prostą, że powierzchnia dostępności pozostaje zarządzalna.

Linting dostępności to komponent, który większość programistów już rozumie. Wkład inżyniera designu to nie narzędzia, lecz próg: zero naruszeń, a nie „akceptowalne” naruszenia. Ta sama filozofia napędza wyniki 100/100/100/100 w Lighthouse: perfekcja jako punkt wyjścia, nie aspiracja.

6. Wizualne testy regresji

Wizualne testy regresji porównują zrzuty ekranu aktualnego buildu z zatwierdzonymi obrazami bazowymi. Porównanie wykorzystuje algorytmy percepcyjnego diffowania, które wykrywają zmiany zauważalne dla człowieka, ignorując te niezauważalne (różnice w renderowaniu subpikselowym, warianty antyaliasingu).

Narzędzia takie jak Percy, Chromatic i BackstopJS automatyzują porównanie. Pipeline wykonuje zrzuty ekranu na każdym zdefiniowanym breakpoincie, uruchamia percepcyjne diffowanie względem obrazu bazowego i flaguje każdą stronę, gdzie diff przekracza próg. 0,1% różnicy pikseli w stopce to szum. 2% przesunięcia w sekcji hero to regresja.

Wizualne testy regresji to najbliższe automatyczne przybliżenie pytania „czy strona wygląda dobrze?”. Percepcyjne diffowanie nie jest w stanie ocenić, czy zmiana layoutu jest ulepszeniem czy pogorszeniem — jedynie to, że zmiana nastąpiła. Człowiek przegląda oznaczone diffy i zatwierdza je lub odrzuca. Wartość automatyzacji to pokrycie: testowanie każdej strony na każdym breakpoincie przy każdym commicie — zadanie, którego żaden człowiek nie wykonuje ręcznie.

Jak stos mapuje się na moją infrastrukturę

Sześć komponentów łączy się z decyzjami już udokumentowanymi w treściach dotyczących inżynierii designu na tej stronie.

Hooki typograficzne wymuszają 13-stopniową skalę typograficzną — progresję opartą na treści, gdzie skala istnieje jako właściwości niestandardowe CSS, a hooki zapewniają, że te właściwości to jedyne rozmiary czcionek w kodzie. Hooki systemu kolorów wymuszają system designu zero kolorów: dziesięć tokenów, cztery poziomy przezroczystości, brak kolorów marki, bez wyjątków. Bramki Lighthouse utrzymują wynik 100/100/100/100 i zapobiegają temu, by jakikolwiek commit cofnął ekstrakcję CSS i eliminację blokowania renderowania, które przyniosły te wyniki.

Podejście bez etapu budowania upraszcza cały stos. Brak map źródłowych do uzgadniania. Brak niejednoznaczności tree-shakingu. Brak warstwy transpilacji między kodem napisanym a dostarczonym. To, co agent pisze, jest tym, co trafia na produkcję — co oznacza, że to, co hooki walidują, jest tym, co widzi użytkownik.

Bramka dowodowa stosuje się do przeglądów designu tak samo jak do przeglądów inżynierskich. „Typografia wygląda dobrze” to nie dowód. „Każda deklaracja font-size w diffie mapuje się na token --font-size-*, zweryfikowane przez hook typograficzny” — to dowód. System designu dostarcza tokeny, które hooki wymuszają. Bez tokenów nie ma czego walidować. Bez hooków tokeny to jedynie sugestie. Nathan Curtis zidentyfikował tę dynamikę: system bez zarządzania degeneruje się w dokumentację, której nikt nie czyta.²

Warstwa gustu

Sześć komponentów wychwytuje naruszenia. Hooki typograficzne wychwytują błędne rozmiary czcionek. Hooki kolorów wychwytują zakodowane wartości. Walidacja layoutu wychwytuje CLS. Bramki Lighthouse wychwytują regresje wydajności. Linting dostępności wychwytuje błędy WCAG. Wizualne testy regresji wychwytują niezamierzone zmiany.

Żaden z nich nie wychwytuje kodu, który spełnia każdą regułę, ale wciąż wydaje się niewłaściwy.

Komponent karty z prawidłowymi rozmiarami czcionek, właściwymi tokenami, zerowym CLS, idealnymi wynikami Lighthouse, pełną zgodnością z WCAG i brakiem wizualnej regresji — ale z odstępami sprawiającymi, że tytuł stłoczy się z obrazem, długością linii obciążającą czytelność i efektem hover, który wydaje się nagły, a nie przemyślany. Każde automatyczne sprawdzenie przechodzi. Karta jest poprawna. Karta nie jest dobra.

Gust działa ponad warstwą reguł. Ograniczenia wychwytują to, co narusza reguły. Kryteria oceny wychwytują to, co nie spełnia metryk. Rozpoznawanie wzorców wychwytuje to, co ujawnia drugie spojrzenie. Spójność wychwytuje to, co odsłania dopiero perspektywa całego systemu. Sześć automatycznych komponentów obsługuje ograniczenia i kryteria oceny. Rozpoznawanie wzorców i spójność wymagają pętli jakości: obowiązkowego drugiego (i trzeciego, i czwartego) przejścia przez pracę, za każdym razem sprawdzając nie to, czy reguły się trzymają, ale czy rezultat zasługuje na wdrożenie.

Pętla jakości to miejsce, w którym inżynier designu zasługuje na drugą połowę tytułu. Programista, który dostarcza kod przechodzący testy, robi minimum. Inżynier designu, który dostarcza interfejsy przechodzące automatyczne sprawdzenia i przetrwające pętlę jakości, utrzymuje standard, którego maszyny nie są jeszcze w stanie ocenić. Test dumy zadaje pięć pytań, a ostatnie („czy zostawiłem to w lepszym stanie?”) nie ma automatycznego odpowiednika. Podobnie kryterium Steve’a: czy Blake podpisałby się pod tym swoim nazwiskiem?

Efekt złożony

Każdy komponent zapobiega konkretnej kategorii błędów designu. Razem komponenty wytwarzają efekt złożony przewyższający sumę poszczególnych sprawdzeń.

Sesja agenta bez stosu generuje kod, który dryfuje. Rozmiary czcionek kumulują się poza skalą. Wartości kolorów kodują się na sztywno zamiast tokenizować. Wydajność regresuje drobnymi przyrostami, których żaden pojedynczy commit nie wyzwala, ale które kumulują się w ciągu tygodni. Dryf jest niewidoczny w jakimkolwiek pojedynczym diffie, a oczywisty w agregacie.

Sesja agenta ze stosem nie może dryfować. Hooki blokują każde odchylenie od skali typograficznej. System kolorów odrzuca każdą zakodowaną wartość. Bramka Lighthouse wychwytuje każdą regresję wydajności. Agent dziedziczy standardy inżyniera designu nie dlatego, że je rozumie, lecz dlatego, że infrastruktura je wymusza. Agent nie potrzebuje gustu. Agent potrzebuje ograniczeń, a ograniczenia ucieleśniają gust.

Jony Ive opisał proces projektowy Apple jako „nieustanne udoskonalanie”: jakość przez iterację na ustalonym zbiorze zasad, nie innowację przez nowość.³ Stos agentowy inżyniera designu operacjonalizuje tę samą ideę. Zasady są utrwalone w tokenach, skalach i progach. Udoskonalanie jest nieustanne, ponieważ automatyzacja działa przy każdym commicie.

Inżynier designu, który koduje standardy w stosie agentowym, robi więcej niż utrzymuje jakość podczas autonomicznego generowania. Ten inżynier skaluje jakość. Każda sesja, każdy agent, każdy commit dziedziczy te same ograniczenia. Człowiek nadal ocenia spójność, nadal uruchamia pętlę jakości, nadal pyta, czy rezultat zasługuje na wdrożenie. Ale człowiek nie wychwytuje już naruszeń rozmiaru czcionki, zakodowanych kolorów ani regresji CLS. Stos wychwycił je pierwszy. Uwaga człowieka kieruje się w całości na pytania, na które maszyny nie potrafią odpowiedzieć.

FAQ

Czy potrzebuję wszystkich sześciu komponentów na start?

Nie. Warto zacząć od komponentu, który adresuje najczęstszy tryb awarii. Hooki typograficzne i hooki systemu kolorów zapewniają najwyższy zwrot, ponieważ wychwytują najczęstsze defekty designu generowane przez agenty. Następnie należy dodać bramki Lighthouse i linting dostępności. Wizualne testy regresji i walidacja layoutu to komponenty wymagające największej infrastruktury i powinny pojawić się później w sekwencji adopcji.

Czy stos działa z narzędziami budowania?

Stos działa z dowolną architekturą frontendową. Podejście bez etapu budowania upraszcza implementację, ponieważ nie ma warstwy transformacji między kodem napisanym a dostarczonym. Z narzędziami budowania hooki muszą walidować pliki źródłowe, podczas gdy Lighthouse i wizualne testy regresji walidują zbudowany wynik. Komponenty pozostają te same. Zmieniają się punkty integracji.

Czy agenty mogą nauczyć się gustu bez stosu?

Obecne modele językowe nie mają gustu. Modele generują statystycznie prawdopodobny wynik, a statystycznie prawdopodobny wynik ciąży ku medianie danych treningowych. Stos nie uczy agentów gustu. Stos ogranicza agenty tak, by pipeline odrzucał pozbawiony gustu wynik, zanim trafi na produkcję. Rozróżnienie ma znaczenie: kodowanie gustu jako infrastruktury okazuje się bardziej niezawodne niż nadzieja, że model zinternalizuje go z promptu.

Jak wizualne testy regresji obsługują zamierzone zmiany?

Zamierzone zmiany generują oczekiwane diffy wizualne. Workflow flaguje diffy, a człowiek je przegląda i zatwierdza, aktualizując obraz bazowy. Wartość wizualnych testów regresji nie polega na zapobieganiu zmianom, lecz na ujawnianiu zmian niezamierzonych. Agent, który modyfikuje kolor przycisku, przesuwa jednocześnie layout karty o trzy piksele. Zmiana koloru jest zamierzona, przesunięcie layoutu nie — a wizualny test regresji wychwytuje ten efekt uboczny.

Źródła