O stack de agentes do design engineer

Design engineers precisam de um stack de agentes diferente do que engenheiros puros. A infraestrutura padrão de agentes otimiza para corretude: testes passam, tipos conferem, regras de linting se mantêm. Ninguém construiu o equivalente para qualidade de design — a infraestrutura que garante 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 craft no pipeline.

A lacuna é visível em toda interface gerada por IA. O espaçamento é inconsistente. Os tamanhos de fonte escapam da escala. Valores hexadecimais 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 toda verificação de tipo e produziu um resultado 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. Evidence gates exigem provas antes de marcar trabalho como concluído. Quality loops exigem releitura de cada linha. Qualidade de engenharia se decompõe em propriedades verificáveis (corretude, 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 esses três cobrem terreno suficiente para prevenir as falhas de design mais comuns que um agente produz. Violações tipográficas, desvio de cores, 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 da qualidade visual.

Consistência visual. Valores de espaçamento seguem a grade 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 pegar.

Disciplina tipográfica. Cada tamanho de fonte no codebase mapeia para um passo na escala tipográfica. Nenhum tamanho fora do padrão. Nenhuma sobreposição inline que contorne 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 como font-size: 19px inventou um passo que não existe na escala, e a hierarquia visual se fratura.

Conformidade com o sistema de cores. Cada valor de cor referencia um design token. Nenhum valor hexadecimal hardcoded fora de :root. Razões de contraste atendem WCAG AA no mínimo, AAA quando possível. O sistema zero-color no meu site usa quatro níveis de opacidade contra preto absoluto, e cada nível 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. Nenhum Cumulative Layout Shift. First Contentful Paint permanece dentro do orçamento. Total Blocking Time não regride. O agente deve entender que mudanças visuais têm consequências de performance. Uma mudança 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 deve manter a semântica estrutural que ferramentas automatizadas não detectam.

Bom gosto. O mais difícil de codificar. Coerência entre elementos. Moderaçã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 pegam violações. A camada de bom gosto pega 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 resultados gerados 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 cada 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 fora do padrão sem que a infraestrutura sinalize. O princípio de Bringhurst de 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 como 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 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 de :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-color — a mesma restrição brutalista que impulsiona toda a identidade visual do site — torna a imposição simples porque a paleta tem exatamente dez tokens. Qualquer valor de cor que não corresponda a um desses tokens está errado por definição. Uma paleta mais ampla exigiria validação mais sutil. 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 0,493 de CLS se parece e não vou 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 baseline. Uma mudança de cinco pixels no header a 375px que parece bem a 1440px aparece 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 baixe qualquer pontuação abaixo de 100 é bloqueado. O gate roda em CI usando lighthouse-ci, e os resultados alimentam o 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 falha 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. Ele 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 tempo de execução.

A análise estática roda axe-core contra o HTML renderizado. O conjunto de regras WCAG 2.1 AA captura alt text ausente, hierarquia imprópria 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 do gate de Lighthouse e adiciona overhead negligenciá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 tempo de execução captura problemas que a análise estática não detecta: gerenciamento de foco após trocas de HTMX, navegação por teclado em conteúdo dinâmico, anúncios do leitor de tela para mudanças de estado. Essas verificações requerem interação roteirizada, não apenas inspeção do DOM. A abordagem no-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á entende. 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 impulsiona pontuações 100/100/100/100 no Lighthouse: perfeição como baseline, não como aspiração.

6. Testes de regressão visual

Testes de regressão visual comparam screenshots do build atual contra baselines aprovados. A comparação usa algoritmos de diffing 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 diffing perceptual contra o baseline e sinaliza qualquer página onde o diff excede o limite. Uma diferença de 0,1% de pixels em um footer é ruído. Uma mudança 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?” Diffing 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 é a 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 neste 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 do sistema de cores impõem o sistema de design zero-color: dez tokens, quatro níveis de opacidade, sem cores de marca, não opcional. Os gates de Lighthouse mantêm a pontuação 100/100/100/100 e previnem que qualquer commit desfaça a extração de CSS e a eliminação de bloqueio de renderização que alcançaram esses números.

A abordagem no-build simplifica todo o stack. Nenhum source map para reconciliar. Nenhuma ambiguidade de tree-shaking. Nenhuma camada de transpilação entre o CSS escrito e o enviado. O que o agente escreve é o que vai para produção, o que significa que o que os hooks validam é o que o usuário vê.

O evidence gate 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. “Cada 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 a 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 resultado 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, conformidade total com WCAG e nenhuma regressão visual — mas com espaçamento que faz o título se amontoar sobre a imagem, um comprimento de linha que força a legibilidade e um estado de hover que parece abrupto em vez de pensado. Toda verificação automatizada passa. O card está correto. O card não está 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 só 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 requerem o quality loop: 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 enviado.

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

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 resultados que derivam. 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. Os hooks bloqueiam cada desvio da escala tipográfica. O sistema de cores rejeita cada valor hardcoded. O gate de Lighthouse captura cada regressão de performance. 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 são fixados 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 faz mais do que manter 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 quality loop, ainda pergunta se o resultado merece ser enviado. Porém, o humano não captura mais violações de tamanho de fonte, cores hardcoded ou regressões de CLS. O stack capturou essas primeiro. A atenção do humano vai inteiramente para as perguntas que máquinas não conseguem responder.

FAQ

Preciso de todos os seis componentes para começar?

Não. Comece com o componente que resolve 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 mais frequentes gerados por agentes. Adicione gates de Lighthouse e linting de acessibilidade depois. Regressão visual e validação de layout são os componentes mais pesados em infraestrutura e pertencem a uma fase posterior na sequência de adoção.

O stack funciona com ferramentas de build?

O stack funciona com qualquer arquitetura frontend. A abordagem no-build simplifica a implementação porque não existe camada de transformação entre o código escrito e o enviado. Com ferramentas de build, os hooks devem validar os arquivos-fonte enquanto Lighthouse e regressão visual validam o resultado construído. 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 resultados estatisticamente prováveis, e resultados estatisticamente prováveis tendem à mediana dos dados de treinamento. O stack não ensina bom gosto aos agentes. O stack restringe os agentes para que o pipeline rejeite resultados sem gosto antes que sejam enviados. A distinção importa: codificar bom gosto como infraestrutura se mostra 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 os aprova, atualizando o baseline. 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