Diretrizes de interface que um agente de IA realmente consegue seguir

O padrão que está surgindo nos catálogos de habilidades de agentes é pegar o Apple's Human Interface Guidelines — ou o Material, ou a orientação de acessibilidade de uma plataforma — e republicá-lo como algo que um agente carrega antes de construir a UI. Um conjunto publicado divide o HIG em quatorze habilidades que cobrem plataformas, fundamentos e componentes: layout, controles, diálogos, menus, busca. Outros o entregam como uma única habilidade de design que promete componentes nativos, tipografia adequada e cores semânticas.

Este é um bom instinto. Um agente de código solicitado para criar uma tela de configurações do iOS sem orientação produzirá algo que funciona, mas que parece sutilmente errado: um modal onde um push seria o convencional, um controle que existe na web e não na plataforma, alvos de toque dimensionados para um mouse. Carregar as regras da plataforma resolve uma classe real de erros, e resolve de forma barata.

Isso também faz algo que as pessoas não esperam, o que merece precisão.

Essa segunda linha é o problema central, e não é algo específico da Apple. Uma instrução infalsificável não pode mudar o comportamento, porque o modelo pode satisfazê-la com qualquer coisa que ele já acredite que a palavra significa. Peça clareza e você obterá a ideia mediana de clareza do modelo, que é a mesma de todos os outros modelos, e é por isso que tantas UIs construídas por agentes convergem para as mesmas superfícies quase pretas, a mesma paleta de uma única cor de destaque e cinza, os mesmos cards com cantos uniformemente arredondados.

Medimos a mesma falha na prática. Em 299 arquivos DESIGN.md públicos — os documentos que desenvolvedores escrevem especificamente para que um agente os siga — 54% contêm pelo menos um adjetivo não mensurável, mais frequentemente "clean" (39%) ou "modern" (36%), e 44% nunca declaram um único valor de tamanho concreto. Esses arquivos parecem direcionamento de design e funcionam como um acordo.

Aqui está a parte que surpreende as pessoas que instalam uma habilidade de HIG esperando que seu app comece a ficar bonito: as diretrizes de plataforma são deliberadamente compartilhadas. Todos os apps da plataforma as seguem. Esse é o ponto principal — um usuário deve ser capaz de abrir um app que nunca viu e saber como ele funciona. A conformidade é o objetivo, e a identidade não é explicitamente.

Portanto, uma skill de HIG pode tornar sua interface *correta* — componentes certos, navegação certa, tamanhos de alvo certos, contraste certo — e ser correto não é o mesmo que ser distintivo. Se duas equipes carregarem a mesma diretriz e nenhum outro contexto de design, elas deverão produzir interfaces intercambiáveis. E geralmente produzem.

Uma vez que você enxerga isso como dois trabalhos distintos, a solução torna-se óbvia e as camadas param de conflitar entre si.

Mantenha-as em arquivos separados. É tentador fundir sua marca na skill de HIG para ter apenas um item para carregar, mas isso dará errado na primeira atualização da plataforma ou no primeiro rebranding, porque você terá que desvendar quais frases pertenciam a quem.

O teste é simples: alguém poderia olhar para o resultado e dizer, sem discussão, se a regra foi seguida? Se duas pessoas razoáveis pudessem discordar, o agente também discordará, e resolverá a divergência a favor de seus padrões (defaults).

Observe que muitas das entradas à direita são proibições. Isso não é uma escolha estilística: uma preferência adiciona uma opção, enquanto uma proibição remove todas as outras. "Use nosso verde" mantém todos os padrões genéricos como válidos; "nunca introduza uma cor que não seja um token" não permite isso. Em nosso corpus, 76% dos arquivos listavam apenas preferências, o que é a descrição exata do porquê de eles pararem de funcionar.

Isso acontece com menos frequência do que as pessoas temem, pois as duas camadas geralmente abordam questões diferentes. Quando ocorre, costuma ser um de três casos, e apenas um deles é um conflito real.

1. Mínimos de acessibilidade versus cor da marca. Não é um conflito. O mínimo prevalece, e a sua cor de destaque precisa de ajuste para aquela superfície. Um agente instruído explicitamente sobre isso o fará; um agente deixado à própria escolha geralmente manterá a cor da marca, pois essa instrução pareceu mais específica.
2. Convenção de plataforma versus padrão interno. Um trade-off real. Decida uma vez, escreva qual prevalece e por quê, e coloque isso na camada de identidade para que não seja rediscutido a cada tela.
3. Estilização padrão da plataforma versus seus tokens. Não é um conflito, embora pareça. As diretrizes especificam qual controle usar; raramente especificam a cor exata. Use o componente da plataforma, estilizado com os seus tokens.

1. 1

   Carregue a camada da plataforma como uma skill ou arquivo de regras

   Seja o que o seu agente suportar — uma skill, .cursor/rules, .devin/rules, uma seção no CLAUDE.md. Mantenha o mais próximo possível da diretriz original, para que possa ser substituído integralmente quando a plataforma for atualizada.

2. 2

   Coloque a camada de identidade no repo

   Um arquivo de tokens mais um DESIGN.md com suas regras e proibições. Ele deve estar no repositório em vez de em um prompt, porque o agente precisa relê-lo a cada tarefa, assim como a próxima pessoa que assumir o projeto.

3. 3

   Declare a precedência uma única vez

   Uma frase no topo do arquivo de identidade nomeando o que prevalece em caso de conflito.

4. 4

   Teste na tela que ninguém desenhou

   Peça algo plausível que nenhuma das camadas previu — um estado vazio, um erro de permissão, um controle de paginação. O que o agente inventar é como será cada caso não mapeado, e essa é a sua real medida de cobertura.

O último passo é o que vale a pena repetir. Ambas as camadas cobrem os casos em que alguém pensou. Em um produto construído por agente, a maioria das telas são casos em que ninguém pensou, e é por isso que a camada de identidade deve declarar regras gerais e proibições, em vez de enumerar componentes. Mais sobre o que pertence a esse arquivo: o que é um DESIGN.md.