Design systems como catálogos de capacidades, não de componentes

Uma biblioteca de componentes diz ao desenvolvedor qual botão renderizar. Não diz a um agente de AI se aquele botão deveria existir em uma tela específica, que ação ele autoriza, que confirmação requer, ou o que acontece quando a ação falha. A lacuna entre "aqui está um componente estilizado" e "isso é o que esta interface tem permissão para fazer" é onde a maioria dos design systems para — e onde interfaces geradas por AI quebram. Um catálogo de capacidades no design system fecha essa lacuna codificando intenção, restrições e comportamento permitido junto às primitivas visuais.

AI quebra design systems que apenas definem componentes

Bibliotecas de componentes definem aparência: tokens de cor, escalas de espaçamento, rampas tipográficas, props de variante. Respondem a pergunta "como isso se parece?" com precisão. Não respondem "quando deveria aparecer?", "que dados requer?", "que permissões o usuário precisa ter?", nem "o que acontece se a operação falhar?"

Quando um desenvolvedor humano compõe uma tela, essas respostas vivem em conhecimento tribal, design reviews e convenções não escritas. Quando um agente de AI compõe uma tela, essas respostas não existem a menos que o sistema as codifique explicitamente. Um agente gerando um formulário não consegue inferir que a coleta de método de pagamento requer isolamento de campos PCI-compliant, copy de erro específico para cartões recusados, e um passo de confirmação — a menos que o design system declare que "coletar método de pagamento" é uma capacidade com essas restrições anexadas.

O modo de falha não é UI feia. É UI insegura, inacessível ou enganosa. Um AI que gera uma ação destrutiva sem diálogo de confirmação não violou um guia de estilo. Violou uma restrição comportamental que nunca foi formalizada.

Um catálogo de capacidades descreve intenção, não apenas aparência

Uma capacidade é uma unidade de comportamento de produto que a interface tem permissão para expressar. Fica acima dos componentes e abaixo das features. Onde um componente diz "renderize um modal com esses props," uma capacidade diz "solicite confirmação do usuário antes de uma ação irreversível, usando um modal com path de cancelamento explícito, focus trap acessível, e copy de ação com qualidade de auditoria."

A distinção importa porque uma capacidade codifica:

• Intenção — que objetivo de produto esta UI serve (coletar consentimento, confirmar deleção, solicitar escalação).
• Restrições — o que deve ser verdadeiro para esta UI aparecer (permissões do usuário, estado dos dados, feature flag).
• Regras de composição — quais componentes e padrões estão aprovados para esta intenção, e quais são proibidos.
• Contrato de acessibilidade — que roles ARIA, comportamento de foco, interações de teclado e anúncios de screen reader a capacidade requer independentemente da implementação visual.
• Estados de erro e recuperação — o que acontece quando o happy path falha, incluindo copy de fallback e comportamento de retry.

Um catálogo de capacidades torna essas declarações legíveis por máquina. Um agente de AI ou gerador de código consultando o catálogo recebe não apenas uma lista de componentes mas um contrato semântico descrevendo o que a interface pode fazer, sob quais condições, com quais salvaguardas.

Restrições são o verdadeiro produto do design system

A maioria dos times de design systems mede sucesso por taxa de adoção e cobertura de componentes. A média da indústria conta a história: apenas cerca de um em cada cinco design systems alcança 80% de cobertura de adoção, e por cinco anos consecutivos, impulsionar adoção se manteve como o principal desafio. A percepção ausente é que a adoção estagna não porque os componentes estão mal construídos, mas porque o sistema não codifica as restrições que tornam os componentes seguros de usar sem supervisão.

Um catálogo de restrições transforma o design system de uma camada de estilo em uma camada de governança:

A camada de capacidades é o que torna um design system útil para agentes de AI, geradores de código e desenvolvedores júnior que carecem do conhecimento tribal para compor interfaces com segurança. Sem ela, o sistema é uma paleta — esteticamente consistente mas semanticamente vazio.

Acessibilidade precisa ser codificada, não lembrada

A análise de 158 design systems públicos revela um padrão claro: 89% entregam exemplos de código, mas apenas 21% documentam requisitos de acessibilidade. Os 79% restantes dependem de desenvolvedores lembrarem de adicionar atributos ARIA, gerenciar foco, lidar com navegação por teclado e fornecer anúncios de screen reader — requisitos invisíveis em um preview de componente mas críticos em produção.

Um catálogo de capacidades muda isso anexando contratos de acessibilidade a cada declaração de capacidade:

const capability = {
  id: "confirm-destructive-action",
  intent: "Solicitar confirmação explícita do usuário antes de uma operação irreversível",
  components: ["ConfirmationDialog", "DestructiveButton"],
  accessibility: {
    focusTrap: true,
    initialFocus: "cancel-button",
    ariaLabelledBy: "dialog-title",
    keyboardDismiss: "Escape",
    screenReaderAnnouncement: "Confirmação necessária: {descrição da ação}",
  },
  constraints: {
    requiresPermission: "write",
    requiresExplicitCancel: true,
    destructiveActionCopy: "deve nomear o recurso sendo deletado",
  },
  errorStates: {
    networkFailure: "Mostrar retry inline com contexto original preservado",
    permissionRevoked: "Redirecionar para view de acesso negado",
  },
}

Quando um agente de AI compõe esta capacidade, não pode pular o focus trap. Não pode colocar foco padrão no botão destrutivo. Não pode omitir o path de dismiss por teclado. As restrições não são documentação — são o contrato da interface.

A arquitetura frontend se torna uma camada de governança de design

A mudança de biblioteca de componentes para catálogo de capacidades tem consequências arquiteturais. O design system não é mais uma dependência que entrega componentes React estilizados. Torna-se um registry que expõe metadados legíveis por máquina junto à implementação.

Uma arquitetura registry-first separa três concerns:

1. O registry — um catálogo estruturado de capacidades, suas restrições, componentes aprovados e contratos de acessibilidade. Consultável por agentes de AI, geradores de código, linters e ferramentas de documentação.
2. A implementação — os componentes React (ou específicos do framework) que satisfazem os contratos do registry. Estes continuam vivendo em um package, continuam usando tokens, continuam renderizando no DOM.
3. A camada de validação — regras de lint, checks de CI e assertions de runtime que verificam que interfaces compostas cumprem as restrições do registry. Um formulário que coleta informação de pagamento mas omite o isolamento de campos PCI-required falha a validação antes de chegar à produção.

Esta arquitetura torna design systems úteis para AI da mesma forma que sistemas de tipos tornam código útil para compiladores. O registry descreve o que é válido. A implementação fornece o que é possível. A camada de validação enforça a fronteira entre ambos.

A abordagem se alinha com como times já gerenciam a calibração de confiança em interfaces geradas por AI: o sistema define guardrails que previnem que o output de AI exceda seu escopo autorizado, e então deixa o agente compor livremente dentro desses limites.

Perguntas frequentes sobre design system como catálogo de capacidades?

Distinções práticas emergem quando times avaliam se seu sistema atual está pronto para interfaces compostas por AI.

Um catálogo de capacidades substitui componentes?

Um catálogo de capacidades não substitui componentes — se posiciona como camada acima deles. Componentes continuam sendo as primitivas de renderização. Capacidades descrevem quando e como esses componentes podem ser compostos, sob quais restrições, e com qual comportamento obrigatório. Um time pode adotar descrições de capacidades incrementalmente, começando com as intenções de produto de maior risco (pagamento, deleção, mudanças de permissão) e expandindo conforme a cobertura amadurece.

O que torna uma capacidade legível por máquina para agentes de AI?

Uma capacidade deve declarar sua intenção em linguagem natural, listar componentes aprovados, especificar requisitos de acessibilidade como contratos estruturados (não documentação em prosa), definir estados de erro e recuperação, e expor predicados de restrição que um agente possa avaliar antes de compor. JSON Schema, interfaces TypeScript, ou APIs de registry funcionam — o formato importa menos que a completude do contrato.

Como restrições previnem que AI gere UI insegura?

Restrições atuam como regras de validação pré-composição. Antes de um agente de AI renderizar uma capacidade "coletar método de pagamento", ele verifica se o isolamento de campos PCI-compliant está presente, se existe copy de erro para cartões recusados, e se o passo de confirmação está incluído. Restrições faltantes bloqueiam a geração da mesma forma que um type check falhando bloqueia compilação — a interface não pode ser composta até que o contrato seja satisfeito.

Um ponto de vista oposto

Um argumento recorrente sustenta que design systems já lutam com adoção no nível de componentes — adicionar uma camada de capacidades introduz abstração que times não vão usar. Se apenas 22% dos sistemas alcançam alta cobertura com componentes sozinhos, o argumento diz, adicionar declarações de intenção e contratos legíveis por máquina tornará o sistema mais pesado, mais lento de manter, e mais difícil de justificar para liderança.

O argumento identifica um risco real: abstração prematura. Um time com dez componentes e sem interfaces compostas por AI não precisa de um catálogo de capacidades. Mas o argumento não enxerga por que a adoção estagna em primeiro lugar. Sistemas falham não porque são complexos demais, mas porque fornecem componentes sem contexto — o desenvolvedor ainda precisa descobrir quando, por quê e como usá-los. Um catálogo de capacidades é a camada de contexto. Responde as perguntas que documentação ausente nunca respondeu, em um formato que tanto humanos quanto máquinas podem consumir.

O que vale a pena lembrar

• Uma biblioteca de componentes define aparência; um catálogo de capacidades define comportamento permitido, intenção e restrições.
• Agentes de AI não conseguem inferir acessibilidade, permissões ou tratamento de erros apenas dos props de componentes — devem ser declarados como contratos legíveis por máquina.
• Declarações de capacidades se posicionam acima dos componentes, não os substituem — começar com as intenções de produto de maior risco e expandir incrementalmente.
• Apenas 21% dos design systems analisados documentam acessibilidade — codificá-la como contrato na camada de capacidades fecha a lacuna para humanos e máquinas.
• Arquitetura frontend precisa se dividir em registry (o que é válido), implementação (o que é possível) e validação (o que é enforçado).
• O catálogo de restrições é o que torna um design system pronto para interfaces compostas por AI — sem ele, o sistema só governa estética.

Conclusão

O design system que apenas descreve como as coisas se parecem já está atrasado. Agentes de AI compõem UI hoje — gerando formulários, sugerindo workflows, adaptando layouts. Cada interface composta sem restrições explícitas é um passivo esperando que um usuário encontre um diálogo de confirmação ausente, um modal inacessível, ou uma ação destrutiva sem path de recuperação. O próximo investimento em design systems não é mais componentes. É a camada semântica que diz a qualquer compositor — humano ou máquina — o que a interface tem permissão para fazer, sob quais condições, e o que nunca deve ser pulado.