Stack agentowy inżyniera designu

Inżynierowie designu potrzebują innego stacku 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, która zapewnia, że agenty tworzą efekty wyglądające na przemyślane, a nie jedynie funkcjonalne. Sześć komponentów stacku agentowego inżyniera designu to hooki typograficzne, hooki systemu kolorów, walidacja layoutu, bramki Lighthouse, linting dostępności oraz testy regresji wizualnej. Razem kodują rzemiosło w pipeline.

Tę lukę widać w każdym interfejsie generowanym 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 zaliczył każdy test, spełnił każde sprawdzenie typów i wyprodukował wynik, który recenzent kodu by zaakceptował — ponieważ recenzenci kodu oceniają logikę, nie spójność wizualną. Inżynier designu zauważa problemy natychmiast. 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ą dowodów 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 też da się rozłożyć. Gust to system techniczny z czterema kodowalnymi komponentami: ograniczeniami, kryteriami ewaluacji, rozpoznawaniem wzorców i spójnością. Pierwsze trzy mapują się bezpośrednio na zautomatyzowaną infrastrukturę. Spójność wymaga ludzkiego osądu, ale pierwsze trzy pokrywają wystarczająco dużo obszaru, by zapobiec najczęstszym błędom designu generowanym przez agenta. Naruszenia typografii, dryf kolorystyczny, niestabilność layoutu, regresje wydajności i błędy dostępności — wszystko to jest wykrywalne maszynowo. Stack 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 celuje w inny wymiar 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 niezależnie od rozmiaru 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 nieautoryzowanych rozmiarów. Żadnych nadpisań inline, które omijają właściwości niestandardowe. Użycie grubości czcionki podąża za ustaloną hierarchią: 700 dla nagłówków, 400 dla tekstu głównego, 300 dla metadanych. Agent, który ustawia podtytuł na font-size: 19px, wymyślił krok, który nie istnieje w skali, a hierarchia wizualna pęka.

Zgodność systemu kolorów. Każda wartość koloru odwołuje się do tokenu designu. Żadnych zakodowanych na sztywno wartości hex poza :root. Współczynniki kontrastu spełniają WCAG AA jako minimum, AAA tam, gdzie to możliwe. System zero-color na mojej stronie wykorzystuje cztery warstwy przezroczystości na tle absolutnej czerni i każda warstwa spełnia AAA. Agent, który wprowadza color: #cccccc, ominął system tokenów i stworzył relację kontrastu, której nikt nie zwalidował.

Ś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 przeliczanie layoutu przy każdym przewijaniu, to błąd wydajnościowy, niezależnie od tego, jak zmiana wygląda.

Dostępność. Semantyczna struktura HTML. Prawidłowa hierarchia nagłówków. Atrybuty ARIA tam, gdzie potrzebne, nieobecne tam, gdzie nie. Weryfikacja kontrastu kolorów. Wskaźniki focusa. Kompatybilność z czytnikami ekranu. Audyt Lighthouse wyłapuje mierzalny podzbiór, ale agent musi również utrzymywać semantykę strukturalną, którą narzędzia automatyczne pomijają.

Gust. Najtrudniejszy do zakodowania. Spójność między elementami. Powściągliwość w dekoracji. Celowa biała przestrzeń zamiast przypadkowej pustki. Gust to cecha, która odróżnia layout podążający za każdą regułą, ale wyglądający źle, od layoutu podążającego za każdą regułą i wyglądającego dobrze. Automatyczne sprawdzenia wyłapują naruszenia. Warstwa gustu wyłapuje to, co nie jest naruszeniem, ale wciąż brakuje mu przemyślenia.

Sześć komponentów stacku inżyniera designu

Każdy komponent mapuje się na konkretny tryb awarii, który zaobserwowałem w wynikach generowanych przez agenta. Komponenty nie są teoretyczne. Każdy istnieje, bo coś poszło nie tak — ta sama geneza co za każdym hookiem w mojej infrastrukturze 95 hooków.

1. Hooki typograficzne

Hook typograficzny waliduje, 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 w pikselach 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 ekwiwalent w pikselach odpowiada jakiemukolwiek krokowi w 13-stopniowej skali. Nie chodzi o wyrafinowanie. Chodzi o to, że agent nie może wprowadzić nieautoryzowanego rozmiaru czcionki bez zasygnalizowania tego przez infrastrukturę. Zasada Bringhursta dotycząca harmonijnych relacji typograficznych jest przestrzegana nie dlatego, że agent rozumie harmonię, lecz dlatego, że hook wymusza skalę, która ją ucieleśnia.¹

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

2. Hooki systemu kolorów

Dryf kolorystyczny to najczęstsza awaria designu w CSS generowanym przez agenta. 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 kolorystyczny skanuje w poszukiwaniu zakodowanych na sztywno 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 zero-color design — to samo brutalistyczne ograniczenie, które napędza całą tożsamość wizualną strony — sprawia, że egzekwowanie jest proste, ponieważ paleta ma dokładnie dziesięć tokenów. Każda wartość koloru, która nie odpowiada jednemu z tych tokenów, jest z definicji błędna. Szersza paleta wymagałaby bardziej niuansowej walidacji. Podejście oparte na ograniczeniach upraszcza hook, ponieważ ograniczenie upraszcza design.

3. Walidacja layoutu

Walidacja layoutu wyłapuje dwie kategorie awarii: Cumulative Layout Shift wprowadzony przez zmiany CSS oraz regresje w punktach przełamania responsywności.

Wykrywanie CLS wymaga pomiaru strony przed i po zmianie. Hook pre-commit nie może uruchomić przeglądarki, ale pipeline CI może. Infrastruktura uruchamia Lighthouse w bezgłowym 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 „dobre”. Mój próg jest 10 razy ostrzejszy, bo widziałem, jak wygląda CLS 0,493 i odmawiam regresji.

Walidacja responsywności wymaga sprawdzenia layoutu w zdefiniowanych punktach przełamania. Narzędzie do regresji wizualnej przechwytuje 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, ujawni 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 automatycznie testuje zachowanie responsywne.

4. Bramki Lighthouse

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

Progi nie są aspiracyjne. Odzwierciedlają aktualne wyniki produkcyjne. Każdy commit, który obniża jakikolwiek wynik poniżej 100, jest blokowany. 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 wyłapuje regresje wydajności, których żaden ludzki recenzent nie zauważyłby. Agent, który dodaje niezoptymalizowany obraz, skrypt blokujący renderowanie lub plik CSS wywołujący migotanie niestylizowanej treści, nie przejdzie bramki, zanim zmiana dotrze do produkcji. Bramka nie rozumie, dlaczego zmiana spowodowała regresję. Bramka nie musi rozumieć. Bramka blokuje regresję, a agent otrzymuje powód odrzucenia 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 wyłapuje brakujący tekst alternatywny, nieprawidłową hierarchię nagłówków, niewystarczający kontrast kolorów, brakujące etykiety formularzy i niewłaściwe użycie ARIA. Sprawdzenie działa w tej samej instancji bezgłowego Chrome co bramka Lighthouse, dodając 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 uruchomieniowa wyłapuje problemy, których analiza statyczna nie wykrywa: zarządzanie focusem po zamianach HTMX, nawigacja klawiaturą w treści dynamicznej, komunikaty czytnika ekranu przy zmianach stanu. Sprawdzenia te wymagają skryptowanej interakcji, nie tylko inspekcji DOM. Podejście no-build utrzymuje stronę na tyle prostą, że powierzchnia dostępności pozostaje do opanowania.

Linting dostępności to komponent, który większość programistów już rozumie. Wartość dodana inżyniera designu to nie narzędzia, lecz próg: zero naruszeń, nie „akceptowalny” poziom naruszeń. Ta sama filozofia co za wynikami 100/100/100/100 w Lighthouse — perfekcja jako punkt wyjścia, nie aspiracja.

6. Testy regresji wizualnej

Testy regresji wizualnej porównują zrzuty ekranu aktualnego buildu z zatwierdzonymi bazami odniesienia. Porównanie wykorzystuje algorytmy percepcyjnego porównywania, które wykrywają zmiany zauważalne dla człowieka, ignorując te, których człowiek nie zauważyłby (różnice w renderowaniu subpikselowym, warianty wygładzania).

Narzędzia takie jak Percy, Chromatic i BackstopJS automatyzują porównanie. Pipeline przechwytuje zrzuty ekranu przy każdym zdefiniowanym punkcie przełamania, uruchamia percepcyjne porównywanie z bazą odniesienia i oznacza każdą stronę, gdzie różnica przekracza próg. Różnica 0,1% pikseli w stopce to szum. Przesunięcie 2% w sekcji hero to regresja.

Regresja wizualna to najbliższe zautomatyzowane przybliżenie pytania „czy strona wygląda dobrze?”. Percepcyjne porównywanie nie potrafi ocenić, czy zmiana layoutu jest ulepszeniem czy degradacją — tylko to, że zmiana nastąpiła. Człowiek przegląda oznaczone różnice i je akceptuje lub odrzuca. Wartość automatyzacji leży w pokryciu: testowanie każdej strony przy każdym punkcie przełamania przy każdym commicie — zadanie, którego żaden człowiek nie wykonuje ręcznie.

Jak stack mapuje się na moją infrastrukturę

Sześć komponentów łączy się z decyzjami już udokumentowanymi w treściach o 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 są jedynymi rozmiarami czcionek w kodzie. Hooki systemu kolorów wymuszają system zero-color design: dziesięć tokenów, cztery warstwy przezroczystości, brak kolorów marki, obowiązkowy. Bramki Lighthouse utrzymują wynik 100/100/100/100 i zapobiegają cofnięciu przez jakikolwiek commit ekstrakcji CSS i eliminacji blokowania renderowania, które te wyniki osiągnęły.

Podejście no-build upraszcza cały stack. Żadnych map źródłowych do uzgadniania. Żadnej dwuznaczności tree-shakingu. Żadnej warstwy transpilacji między kodem autorskim a dostarczanym CSS. To, co agent pisze, jest tym, co trafia do użytkownika, co oznacza, że to, co hooki walidują, jest tym, co użytkownik widzi.

Bramka dowodowa ma zastosowanie 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 egzekwują. Bez tokenów nie ma czego walidować. Bez hooków tokeny są jedynie sugestiami. Nathan Curtis zidentyfikował tę dynamikę — system bez nadzoru degraduje się do dokumentacji, której nikt nie czyta.²

Warstwa gustu

Sześć komponentów wyłapuje naruszenia. Hooki typograficzne wyłapują złe rozmiary czcionek. Hooki kolorystyczne wyłapują zakodowane na sztywno wartości. Walidacja layoutu wyłapuje CLS. Bramki Lighthouse wyłapują regresje wydajności. Linting dostępności wyłapuje awarie WCAG. Regresja wizualna wyłapuje niezamierzone zmiany.

Żaden z nich nie wyłapuje wyniku, który podąża za każdą regułą, ale wciąż wygląda źle.

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

Gust działa ponad warstwą reguł. Ograniczenia wyłapują to, co narusza reguły. Kryteria ewaluacji wyłapują to, co nie spełnia metryk. Rozpoznawanie wzorców wyłapuje to, co ujawnia drugie spojrzenie. Spójność wyłapuje to, co odsłania dopiero perspektywa całego systemu. Sześć zautomatyzowanych komponentów obsługuje ograniczenia i kryteria ewaluacji. Rozpoznawanie wzorców i spójność wymagają pętli jakości — nakazanego drugiego (i trzeciego, i czwartego) przejścia przez pracę, za każdym razem sprawdzającego nie to, czy reguły są spełnione, lecz to, czy wynik zasługuje na wysłanie.

Pętla jakości to miejsce, gdzie inżynier designu zdobywa „inżynierską” 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 przeżywające pętlę jakości, utrzymuje standard, którego maszyny nie potrafią jeszcze ocenić. Kontrola dumy zadaje pięć pytań, a ostatnie — „czy zostawiłem to lepszym?” — nie ma automatycznego odpowiednika. Podobnie kryterium Steve’a: czy Blake podpisałby się pod tym?

Efekt złożony

Każdy komponent zapobiega konkretnej kategorii awarii designu. Razem komponenty wytwarzają efekt złożony, który przekracza sumę indywidualnych sprawdzeń.

Sesja agenta bez stacku generuje wyniki, które dryfują. Rozmiary czcionek kumulują się poza skalą. Wartości kolorów kodują się na sztywno zamiast tokenizować. Wydajność spada w małych krokach, których żaden pojedynczy commit nie wywołuje, ale które narastają przez tygodnie. Dryf jest niewidoczny w każdym pojedynczym diffie i oczywisty w agregacie.

Sesja agenta ze stackiem nie może dryfować. Każde odchylenie od skali typograficznej jest blokowane. Każdy zakodowany na sztywno kolor jest odrzucany. Każda regresja wydajności jest wyłapywana. Agent dziedziczy standardy inżyniera designu nie dlatego, że rozumie te standardy, lecz dlatego, że infrastruktura je egzekwuje. Agent nie potrzebuje gustu. Agent potrzebuje ograniczeń, a ograniczenia ucieleśniają gust.

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

Inżynier designu, który koduje standardy w stacku agentowym, nie tylko 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 wynik zasługuje na wysłanie. Ale człowiek nie wyłapuje już naruszeń rozmiaru czcionek, zakodowanych na sztywno kolorów ani regresji CLS. Stack złapał je pierwszy. Uwaga człowieka kieruje się całkowicie 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 dają najwyższy zwrot, ponieważ wyłapują najczęstsze defekty designu generowane przez agenta. Następnie należy dodać bramki Lighthouse i linting dostępności. Regresja wizualna i walidacja layoutu to komponenty wymagające najwięcej infrastruktury i powinny pojawić się później w sekwencji adopcji.

Czy stack działa z narzędziami budowania?

Stack działa z dowolną architekturą frontendową. Podejście no-build upraszcza implementację, ponieważ nie ma warstwy transformacji między kodem autorskim a dostarczanym. W przypadku narzędzi budowania hooki muszą walidować pliki źródłowe, podczas gdy Lighthouse i regresja wizualna walidują zbudowany wynik. Komponenty pozostają te same. Zmieniają się punkty integracji.

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

Obecne modele językowe nie mają gustu. Modele generują statystycznie prawdopodobny wynik, a statystycznie prawdopodobny wynik zmierza ku medianie danych treningowych. Stack nie uczy agentów gustu. Stack ogranicza agenty tak, aby wynik pozbawiony gustu był odrzucany, zanim trafi do produkcji. To rozróżnienie ma znaczenie: kodowanie gustu jako infrastruktury jest bardziej niezawodne niż nadzieja, że model zinternalizuje go z prompta.

Jak testy regresji wizualnej obsługują celowe zmiany?

Celowe zmiany generują oczekiwane różnice wizualne. Przepływ pracy oznacza różnice, a człowiek je przegląda i akceptuje, aktualizując bazę odniesienia. Wartość regresji wizualnej 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 celowa, przesunięcie layoutu nie, a test regresji wizualnej wyłapuje efekt uboczny.

Źródła