O Stack de Agentes do Design Engineer

Design engineers precisam de um stack de agentes diferente do de engenheiros puros. A infraestrutura padrão de agentes otimiza para correção: testes passam, tipos conferem, regras de linting se mantêm. Ninguém construiu o equivalente para qualidade de design — infraestrutura que garanta que agentes produzam trabalho que pareça pensado, não meramente funcional. Os seis componentes do stack de agentes do design engineer são hooks de tipografia, hooks de sistema de cores, validação de layout, gates de Lighthouse, linting de acessibilidade e testes de regressão visual. Juntos, eles codificam o cuidado no pipeline.

A lacuna é visível em toda interface gerada por IA. O espaçamento é inconsistente. Os tamanhos de fonte fogem da escala. Valores hex hardcoded contornam o sistema de tokens. Mudanças de layout aparecem no mobile porque ninguém verificou o CLS depois que o agente modificou o CSS. O agente passou em todos os testes, satisfez todas as verificações de tipo e produziu output que um revisor de código aprovaria — porque revisores de código avaliam lógica, não coerência visual. O design engineer percebe os problemas imediatamente. A infraestrutura do agente não percebe nada, porque ninguém disse a ela o que procurar.

A infraestrutura de agentes para engenheiros amadureceu rapidamente. Hooks bloqueiam comandos git perigosos. Gates de evidência exigem provas antes de marcar o trabalho como concluído. Loops de qualidade obrigam a releitura de cada linha. Qualidade de engenharia se decompõe em propriedades verificáveis — correção, performance, segurança, segurança de tipos — e cada propriedade mapeia para uma ferramenta que produz resultados binários.

Qualidade de design também se decompõe. Bom gosto é um sistema técnico com quatro componentes codificáveis: restrições, critérios de avaliação, reconhecimento de padrões e coerência. Os três primeiros mapeiam diretamente para infraestrutura automatizada. Coerência requer julgamento humano, mas os três primeiros cobrem terreno suficiente para prevenir as falhas de design mais comuns que um agente produz. Violações tipográficas, desvios de cor, instabilidade de layout, regressões de performance e falhas de acessibilidade são todos detectáveis por máquinas. O stack de agentes do design engineer os detecta.

O que Design Engineers Precisam dos Agentes

Um engenheiro puro pergunta: o código funciona? Um design engineer faz seis perguntas adicionais, cada uma mirando uma dimensão diferente de qualidade visual.

Consistência visual. Valores de espaçamento seguem o grid de 8 pontos ou a escala de espaçamento definida. O alinhamento respeita o ritmo vertical. Relações proporcionais entre elementos permanecem estáveis em diferentes tamanhos de viewport. Um agente que adiciona um novo componente de card usando margin-top: 13px em vez de var(--space-md) introduziu ruído visual que nenhum teste vai capturar.

Disciplina tipográfica. Todo tamanho de fonte no codebase mapeia para um passo na escala tipográfica. Sem tamanhos soltos. Sem overrides inline que contornam as custom properties. O uso de peso segue a hierarquia estabelecida: 700 para títulos, 400 para corpo, 300 para metadados. Um agente que define um subtítulo com font-size: 19px inventou um passo que não existe na escala, e a hierarquia visual se fratura.

Conformidade do sistema de cores. Todo valor de cor referencia um design token. Sem valores hex hardcoded fora do :root. Razões de contraste atendem WCAG AA no mínimo, AAA quando possível. O sistema zero-cor no meu site usa quatro faixas de opacidade contra preto absoluto, e cada faixa passa AAA. Um agente que introduz color: #cccccc contornou o sistema de tokens e criou uma relação de contraste que ninguém validou.

Consciência de performance. Sem Cumulative Layout Shift. First Contentful Paint dentro do orçamento. Total Blocking Time sem regressão. O agente precisa entender que mudanças visuais têm consequências de performance — uma alteração de CSS que dispara recálculo de layout em cada evento de scroll é um bug de performance, independentemente de como a mudança aparenta.

Acessibilidade. Estrutura semântica de HTML. Hierarquia adequada de headings. Atributos ARIA onde necessário, ausentes onde não. Verificação de contraste de cores. Indicadores de foco. Compatibilidade com leitores de tela. A auditoria Lighthouse captura o subconjunto mensurável, mas o agente também precisa manter a semântica estrutural que ferramentas automatizadas não detectam.

Bom gosto. O mais difícil de codificar. Coerência entre elementos. Contenção na decoração. Espaço em branco intencional em vez de vazio acidental. Bom gosto é a qualidade que distingue um layout que segue todas as regras mas parece errado de um layout que segue todas as regras e parece certo. Verificações automatizadas capturam violações. A camada de bom gosto captura não-violações que ainda carecem de consideração.

Seis Componentes do Stack do Design Engineer

Cada componente mapeia para um modo de falha específico que observei em output gerado por agentes. Os componentes não são teóricos. Cada um existe porque algo deu errado — a mesma história de origem por trás de cada hook na minha infraestrutura de 95 hooks.

1. Hooks de Tipografia

Um hook de tipografia valida que toda declaração font-size em um commit referencia uma custom property de CSS da escala tipográfica. O hook escaneia arquivos alterados em busca de valores brutos em pixels ou rem que não mapeiam para um passo definido.

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

O hook é direto. Uma versão mais refinada analisa o valor e verifica se o equivalente em pixels corresponde a algum passo na escala de 13 passos. O ponto não é sofisticação. O ponto é que o agente não consegue introduzir um tamanho de fonte irregular sem que a infraestrutura sinalize. O princípio de Bringhurst sobre relações tipográficas harmoniosas se mantém não porque o agente entende harmonia, mas porque o hook impõe a escala que a incorpora.¹

O peso da fonte merece validação separada. Meu sistema usa três pesos: 700, 400 e 300. Um agente que define o título de um card com font-weight: 600 introduziu um peso que contradiz a hierarquia estabelecida. Um hook de tipografia captura o desvio antes que chegue à produção.

2. Hooks de Sistema de Cores

Desvio de cor é a falha de design mais comum em CSS gerado por agentes. O agente sabe que o texto deve ser branco em um fundo escuro. O agente não sabe que #ffffff deveria ser var(--color-text-primary), ou que texto secundário a 65% de opacidade é var(--color-text-secondary) e não rgba(255,255,255,0.60).

O hook de cor escaneia valores de cor hardcoded fora do :root e das definições de design tokens:

# 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

O sistema de design zero-cor — a mesma restrição brutalista que guia toda a identidade visual do site — torna a aplicação simples porque a paleta tem exatamente dez tokens. Qualquer valor de cor que não corresponda a um desses tokens é errado por definição. Uma paleta mais ampla exigiria validação mais nuançada. A abordagem baseada em restrições simplifica o hook porque a restrição simplifica o design.

3. Validação de Layout

A validação de layout captura duas categorias de falha: Cumulative Layout Shift introduzido por mudanças de CSS, e regressões de breakpoints responsivos.

A detecção de CLS requer medir a página antes e depois da mudança. Um hook de pre-commit não consegue rodar um navegador, mas um pipeline de CI consegue. A infraestrutura roda Lighthouse em Chrome headless contra o deploy de staging, compara valores de CLS com o build anterior e bloqueia o merge se o delta exceder 0,01. O Google considera CLS abaixo de 0,1 como “bom”. Meu limite é 10x mais rigoroso porque eu vi como um CLS de 0,493 se parece e me recuso a regredir.

A validação responsiva requer verificar o layout em breakpoints definidos. Uma ferramenta de regressão visual captura screenshots a 375px (mobile), 768px (tablet) e 1440px (desktop), depois os compara com imagens de referência. Um deslocamento de cinco pixels no header a 375px que parece bom a 1440px vai aparecer na comparação mobile. O agente que modificou uma propriedade max-width sem testar o comportamento responsivo é pego pela infraestrutura que testa o comportamento responsivo automaticamente.

4. Gates de Lighthouse

Um gate de Lighthouse roda uma auditoria completa antes de cada merge na branch principal. O gate impõe quatro limites:

Os limites não são aspiracionais. Eles refletem as pontuações atuais de produção. Qualquer commit que diminua qualquer pontuação abaixo de 100 é bloqueado. O gate roda no CI usando lighthouse-ci, e os resultados retornam ao pull request como um status check.

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

O gate de Lighthouse captura regressões de performance que nenhum revisor humano notaria. Um agente que adiciona uma imagem não otimizada, um script que bloqueia renderização ou um arquivo CSS que dispara um flash de conteúdo sem estilo vai falhar no gate antes que a mudança chegue à produção. O gate não entende por que a mudança causou uma regressão. O gate não precisa entender. O gate bloqueia a regressão, e o agente recebe o motivo da falha em seu contexto para a próxima tentativa.

5. Linting de Acessibilidade

A validação de acessibilidade se divide em duas camadas: análise estática e avaliação em runtime.

A análise estática roda axe-core contra o HTML renderizado. O conjunto de regras WCAG 2.1 AA captura texto alt ausente, hierarquia inadequada de headings, contraste de cor insuficiente, labels de formulário ausentes e uso incorreto de ARIA. A verificação roda na mesma instância de Chrome headless que o gate de Lighthouse, adicionando overhead desprezível.

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

A camada de runtime captura problemas que a análise estática não detecta: gerenciamento de foco após swaps de HTMX, navegação por teclado através de conteúdo dinâmico, anúncios de leitores de tela para mudanças de estado. Essas verificações exigem interação por script, não apenas inspeção do DOM. A abordagem sem build mantém a página simples o suficiente para que a superfície de acessibilidade permaneça gerenciável.

Linting de acessibilidade é o componente que a maioria dos engenheiros já compreende. A adição do design engineer não é a ferramenta, mas o limite: zero violações, não violações “aceitáveis”. A mesma filosofia por trás das pontuações 100/100/100/100 no Lighthouse — perfeição como linha de base, não como aspiração.

6. Testes de Regressão Visual

Testes de regressão visual comparam screenshots do build atual com referências aprovadas. A comparação usa algoritmos de diff perceptual que detectam mudanças que um humano notaria enquanto ignoram mudanças que um humano não notaria (diferenças de renderização sub-pixel, variações de anti-aliasing).

Ferramentas como Percy, Chromatic e BackstopJS automatizam a comparação. O pipeline captura screenshots em cada breakpoint definido, roda diff perceptual contra a referência e sinaliza qualquer página onde o diff excede o limite. Uma diferença de 0,1% de pixels em um footer é ruído. Um deslocamento de 2% na seção hero é uma regressão.

Regressão visual é a aproximação automatizada mais próxima de “a página parece certa?” O diff perceptual não consegue avaliar se uma mudança de layout é uma melhoria ou uma degradação, apenas que uma mudança ocorreu. O humano revisa os diffs sinalizados e os aprova ou rejeita. O valor da automação é cobertura: testar cada página em cada breakpoint em cada commit, uma tarefa que nenhum humano realiza manualmente.

Como o Stack se Conecta à Minha Infraestrutura

Os seis componentes se conectam a decisões já documentadas no conteúdo de design engineering deste site.

Os hooks de tipografia impõem a escala tipográfica de 13 passos — uma progressão orientada por conteúdo onde a escala existe como custom properties de CSS e os hooks garantem que essas propriedades sejam os únicos tamanhos de fonte no codebase. Os hooks de sistema de cores impõem o sistema de design zero-cor: dez tokens, quatro faixas de opacidade, sem cores de marca, não opcional. Os gates de Lighthouse mantêm a pontuação 100/100/100/100 e impedem que qualquer commit desfaça a extração de CSS e eliminação de bloqueio de renderização que alcançaram esses números.

A abordagem sem build simplifica todo o stack. Sem source maps para reconciliar. Sem ambiguidade de tree-shaking. Sem camada de transpilação entre o CSS escrito e o entregue. O que o agente escreve é o que é entregue, o que significa que o que os hooks validam é o que o usuário vê.

O gate de evidência se aplica a revisões de design da mesma forma que se aplica a revisões de engenharia. “A tipografia parece certa” não é evidência. “Toda declaração font-size no diff mapeia para um token --font-size-*, verificado pelo hook de tipografia” é evidência. O design system fornece os tokens que os hooks impõem. Sem tokens, não há nada contra o que validar. Sem hooks, os tokens são sugestões. Nathan Curtis identificou essa dinâmica — um sistema sem governança degrada em documentação que ninguém lê.²

A Camada de Bom Gosto

Os seis componentes capturam violações. Hooks de tipografia capturam tamanhos de fonte errados. Hooks de cor capturam valores hardcoded. Validação de layout captura CLS. Gates de Lighthouse capturam regressões de performance. Linting de acessibilidade captura falhas de WCAG. Regressão visual captura mudanças não intencionais.

Nenhum deles captura o output que segue todas as regras mas ainda parece errado.

Um componente de card com tamanhos de fonte corretos, tokens adequados, zero CLS, pontuações perfeitas no Lighthouse, total conformidade com WCAG e sem regressão visual — mas com espaçamento que faz o título sufocar a imagem, um comprimento de linha que compromete a legibilidade e um estado hover que parece abrupto em vez de pensado. Toda verificação automatizada passa. O card está correto. O card não é bom.

Bom gosto opera acima da camada de regras. Restrições capturam o que viola as regras. Critérios de avaliação capturam o que falha nas métricas. Reconhecimento de padrões captura o que o segundo olhar revela. Coerência captura o que apenas a visão do sistema inteiro expõe. Os seis componentes automatizados lidam com restrições e critérios de avaliação. Reconhecimento de padrões e coerência exigem o loop de qualidade — a segunda (e terceira, e quarta) passagem obrigatória pelo trabalho, cada vez verificando não se as regras se mantêm, mas se o resultado merece ser entregue.

O loop de qualidade é onde o design engineer conquista a metade “engineer” do título. Um engenheiro que entrega código que passa nos testes está fazendo o mínimo. Um design engineer que entrega interfaces que passam nas verificações automatizadas e sobrevivem ao loop de qualidade está mantendo um padrão que máquinas ainda não conseguem avaliar. O pride check faz cinco perguntas, e a última — “deixei isso melhor?” — não tem equivalente automatizado. Tampouco o critério Steve: Blake assinaria seu nome nisto?

O Efeito Composto

Cada componente previne uma categoria específica de falha de design. Juntos, os componentes produzem um efeito composto que excede a soma das verificações individuais.

Uma sessão de agente sem o stack produz output que deriva. Tamanhos de fonte se acumulam fora da escala. Valores de cor são hardcoded em vez de tokenizados. Performance regride em pequenos incrementos que nenhum commit individual dispara, mas que se acumulam ao longo de semanas. A deriva é invisível em qualquer diff individual e óbvia no agregado.

Uma sessão de agente com o stack não consegue derivar. Todo desvio da escala tipográfica é bloqueado. Toda cor hardcoded é rejeitada. Toda regressão de performance é capturada. O agente herda os padrões do design engineer não porque o agente entende esses padrões, mas porque a infraestrutura os impõe. O agente não precisa de bom gosto. O agente precisa de restrições, e as restrições incorporam bom gosto.

Jony Ive descreveu o processo de design da Apple como “refinamento implacável” — qualidade através de iteração sobre um conjunto fixo de princípios, não inovação através de novidade.³ O stack de agentes do design engineer operacionaliza a mesma ideia. Os princípios estão fixos em tokens, escalas e limites. O refinamento é implacável porque a automação roda em cada commit.

O design engineer que codifica padrões no stack de agentes não apenas mantém qualidade durante geração autônoma. Esse engenheiro escala qualidade. Cada sessão, cada agente, cada commit herda as mesmas restrições. O humano ainda avalia coerência, ainda roda o loop de qualidade, ainda pergunta se o output merece ser entregue. Porém, o humano não captura mais violações de tamanho de fonte, cores hardcoded ou regressões de CLS. O stack capturou esses primeiro. A atenção do humano vai inteiramente para as questões que máquinas não conseguem responder.

FAQ

Preciso de todos os seis componentes para começar?

Não. Comece com o componente que endereça seu modo de falha mais comum. Hooks de tipografia e hooks de sistema de cores oferecem o maior retorno porque capturam os defeitos de design gerados por agentes mais frequentes. Adicione gates de Lighthouse e linting de acessibilidade em seguida. Regressão visual e validação de layout são os componentes mais pesados em infraestrutura e pertencem ao final da sequência de adoção.

O stack funciona com ferramentas de build?

O stack funciona com qualquer arquitetura frontend. A abordagem sem build simplifica a implementação porque não há camada de transformação entre o código escrito e o entregue. Com ferramentas de build, hooks devem validar os arquivos fonte enquanto Lighthouse e regressão visual validam o output compilado. Os componentes permanecem os mesmos. Os pontos de integração mudam.

Agentes conseguem aprender bom gosto sem o stack?

Modelos de linguagem atuais não têm bom gosto. Modelos produzem output estatisticamente provável, e output estatisticamente provável tende à mediana dos dados de treinamento. O stack não ensina bom gosto aos agentes. O stack restringe agentes para que output sem bom gosto seja rejeitado antes de ser entregue. A distinção importa: codificar bom gosto como infraestrutura é mais confiável do que esperar que o modelo o internalize a partir do prompt.

Como testes de regressão visual lidam com mudanças intencionais?

Mudanças intencionais produzem diffs visuais esperados. O fluxo sinaliza os diffs, e o humano revisa e aprova, atualizando a referência. O valor da regressão visual não é prevenir mudanças, mas revelar mudanças não intencionais. Um agente que modifica a cor de um botão também desloca o layout do card em três pixels — a mudança de cor é intencional, o deslocamento de layout não é, e o teste de regressão visual captura o efeito colateral.

Fontes