Como fazer agentes de IA seguirem seu design system

Agentes de IA voltados à programação conseguem seguir seu design system quando, em vez de pedir que “deixem tudo com a cara da marca”, você fornece três elementos: um arquivo legível que concentre os critérios de design, um conjunto restrito de componentes ou estilos para operações repetíveis e avaliações fixas que revelem se as regras realmente funcionam.

Essa abordagem muda a conta. O objetivo não é baratear a geração de código, e sim reduzir as horas gastas corrigindo as mesmas decisões de tipografia, hierarquia, espaçamento e texto depois de cada primeira versão. O fluxo público da Vercel com o arquivo design.md é, até agora, o exemplo funcional mais claro — e os próprios resultados da empresa também mostram por que a revisão humana ainda precisa fazer parte do sistema.

O sistema para agentes de IA combina um arquivo, uma camada de restrições e um ciclo de validação

A grande ideia do fluxo design.md da Vercel não está no nome do arquivo, mas na separação de responsabilidades.

1. As diretrizes concentram o julgamento. Um único arquivo público informa ao agente para quem a página se destina, o que o leitor precisa decidir, como organizar as evidências, qual é a voz da marca e quais vícios comuns do design gerado devem ser evitados.
2. Os primitivos cuidam da execução. Uma folha de estilos publicada oferece ao agente um vocabulário delimitado de cabeçalhos, tabelas, faixas de indicadores, estilos de gráficos, classes e tokens. Em vez de inventar um novo sistema de tipografia ou espaçamento, o modelo escolhe um primitivo já aprovado.
3. As avaliações fornecem a comprovação. Cenários fixos, verificações determinísticas e revisão humana mostram se uma mudança melhorou as primeiras versões ou apenas transferiu o problema para outro ponto.

Pense em um restaurante. O arquivo de diretrizes representa o julgamento do chef sobre a refeição. Componentes e estilos equivalem à bancada abastecida e aos utensílios calibrados. As avaliações são a prova final do prato. Uma receita detalhada, sem uma bancada preparada, ainda produz pratos muito diferentes entre si.

A Vercel chegou a essa divisão depois que um prompt simples falhou. A primeira versão pública descrevia a linguagem visual, mas os modelos interpretavam expressões subjetivas de maneiras diferentes porque não tinham acesso aos componentes e exemplos já publicados nos repositórios da Vercel. A equipe então reescreveu o arquivo com base em resultados fixos, em vez de considerar o texto pronto apenas porque parecia convincente.

Essa diferença é decisiva. Um design system feito para pessoas pode se apoiar em repertório compartilhado, memória institucional e na capacidade de um designer perceber quando algo ficou quase certo. Um sistema preparado para agentes precisa tornar a decisão fácil de recuperar, deixar evidente qual implementação é permitida e fazer com que a falha seja observável.

O que incluir no arquivo de diretrizes

Seu primeiro arquivo deve ser mais curto do que o design system que representa. Ele é um mapa de decisões, não um museu com todos os componentes.

Organize-o em seis seções:

• Escopo: quais superfícies devem carregar o arquivo e quais tarefas devem ignorá-lo.
• Leitor e objetivo: quem abre cada artefato, o que essa pessoa precisa entender ou decidir e quais evidências sustentam a decisão.
• Decisões observáveis: regras como “tabelas de evidências podem ocupar toda a largura do conteúdo”, e não adjetivos como “limpo” ou “premium”.
• Primitivos disponíveis: os nomes exatos de componentes, classes ou tokens que o agente pode escolher, além da situação adequada para cada um.
• Padrões de falha nomeados: resultados ruins e recorrentes, cada um com um nome fácil de lembrar, um sintoma concreto e a correção recomendada.
• Limites: fatos que o agente deve preservar, estados que precisa contemplar, afirmações sem respaldo que deve omitir e decisões que ainda dependem de uma pessoa.

Quando o contexto fizer diferença, o arquivo deve explicar por que determinada escolha existe. Se a resposta já está no código, aponte para ele. Copiar todas as regras de CSS para o contexto do modelo desperdiça atenção e cria duas fontes da verdade. A folha de estilos pública da Vercel é carregada no navegador, enquanto o design.md documenta os nomes que o agente deve usar; assim, o código da própria folha de estilos não ocupa o contexto do modelo.

Há também um problema de recuperação. Em avaliações separadas com Next.js, a Vercel constatou que os agentes deixaram de acionar uma skill disponível em 56% dos casos. Registre o gatilho nas instruções persistentes do repositório, explicite o escopo, peça que o agente informe quais diretrizes carregou e teste o carregamento separadamente do cumprimento das regras. Um arquivo perfeito que nunca é aberto não passa de documentação.

Ao escolher o agente ou a interface para esse sistema, as diferenças práticas entre Claude Design e v0 para geração de interfaces importam menos do que garantir que ambos recebam as mesmas restrições e avaliações.

Encaminhe cada correção ao responsável mais específico

A regra operacional mais forte é simples: não tente resolver toda falha de design adicionando mais texto.

É aqui que muitas equipes deixam o arquivo grande demais. Continuam acrescentando frases como “use o espaçamento correto” quando um token de espaçamento restrito resolveria a decisão todas as vezes. Ou transformam uma escolha de política de produto em uma regra de linter, embora o código não consiga avaliar as exceções. Mais instruções não significam necessariamente mais controle.

Faça avaliações equivalentes antes de adotar o sistema

Uma avaliação só é útil quando a comparação é justa. Escolha um artefato recorrente que tenha um leitor real, dados reais e uma rubrica curta. Gere uma referência inicial e depois execute o mesmo prompt, com os mesmos dados, modelo e viewport, desta vez carregando suas diretrizes. Preserve as primeiras tentativas. Embaralhe os resultados antes da análise para que o avaliador não saiba qual versão usou as novas regras.

A Vercel criou sete cenários a partir de trabalhos recorrentes, entre eles uma proposta de renovação, um relatório de benchmark, uma página de planejamento, um resumo de segurança e uma apresentação. As rodadas completas executaram os sete cenários no Claude Opus 4.8 e no Codex com GPT-5.5. Cada execução armazenada guardava prompt, dados de entrada, configuração do modelo, versão das diretrizes, capturas de tela e feedback dos avaliadores.

O resultado que vale guardar é específico, não universal. Em três cenários para desktop e seis páginas de primeira tentativa, a Vercel contabilizou 39 falhas conhecidas com o design.md e 91 sem ele — uma redução de 57% naquele teste. O teste foi pequeno, as verificações só conseguiam enxergar falhas previamente codificadas e todas as páginas ainda apresentavam pelo menos um problema grave o bastante para impedir a publicação. Não coloque 57% em uma projeção de negócios. Replique o método e meça a carga de revisão da sua própria equipe.

Comece com esta conta de negócio:

• Conte quantos minutos um designer ou engenheiro sênior gasta corrigindo cada primeira versão.
• Multiplique esse tempo pelo número de artefatos recorrentes publicados a cada mês.
• Some o tempo usado para explicar a mesma correção em conversas, pull requests e revisões de design.
• Depois de implantar o sistema, execute novamente o mesmo conjunto de artefatos e meça a diferença.

Por exemplo: quatro páginas recorrentes que exigem duas horas de correção cada consomem oito horas de revisão. Se o sistema restrito eliminar uma hora de ajustes repetidos em cada página, o ganho será de quatro horas. Isso é uma economia mensurável. “O resultado parece mais alinhado à marca” não é.

O mercado atual oferece outra referência útil. Os criadores de sites com IA custam aproximadamente de $0 a $160 por mês nos resultados de preços disponíveis, enquanto um guia de 2026 sobre sites personalizados estima valores de $1,500 a $5,000. Uma camada de controle de marca precisa justificar seu custo diante das duas alternativas. Seu valor não está em oferecer mais um botão de geração, mas em reduzir os custos de revisão, aprovação e risco para a marca em trabalhos recorrentes.

Sete casos de uso, em ordem de quem mais se beneficia

1. Agências com várias marcas que produzem sites de campanha repetidamente

Uma agência com dez clientes ativos pode manter um arquivo de diretrizes e um conjunto restrito de primitivos para cada cliente e, em seguida, rodar a mesma avaliação de página de lançamento sempre que trocar de agente, biblioteca de componentes ou modelo. O retorno vem da redução das horas de designers seniores gastas para recuperar a tipografia e a hierarquia depois que a página já está funcionando. Esse grupo é o maior beneficiado porque cada correção aceita pode melhorar todos os artefatos posteriores daquele cliente.

2. Equipes de produto que permitem a vários agentes mexer na mesma interface

Uma equipe de plataforma pode orientar todo o trabalho de interface com uma única instrução no repositório, carregar as diretrizes apenas em mudanças voltadas ao usuário e aplicar regras mecânicas por meio do lint. O agente pode mudar, mas as decisões aprovadas permanecem junto ao código. O ganho é manter a consistência entre diferentes colaboradores sem exigir que cada modelo deduza a intenção apenas a partir dos componentes já publicados.

3. Equipes de receita que geram propostas, benchmarks e relatórios

Uma equipe de operações de vendas pode fixar um cenário de proposta de renovação com dados fictícios de clientes, uma rubrica para leitura executiva e outra para auditoria detalhada. Cada nova versão das diretrizes precisa manter a recomendação em destaque, preservar os números fornecidos e dar espaço suficiente às evidências. O ganho está em acelerar as primeiras versões sem deixar que um layout genérico de dashboard esconda a decisão comercial.

4. Equipes de design system que se preparam para adotar agentes

Uma equipe de design system pode documentar os tokens e componentes exatos que os agentes têm permissão para usar, dar nomes aos padrões de falha mais comuns e adicionar verificações determinísticas quando a regra for mecânica. O ganho está em transformar uma biblioteca de componentes em um sistema operacional de decisões, e não apenas em um catálogo que os agentes imitam de forma inconsistente.

5. Startups sem uma fila dedicada à revisão de design

Uma equipe pequena pode começar por um único artefato, como sua página semanal de métricas, e pelas dez correções recorrentes mais recentes. Ela não precisa do aplicativo completo de avaliações da Vercel. Uma referência inicial, uma execução equivalente e uma ficha de avaliação humana bastam para revelar os principais erros. O ganho está em concentrar o escasso julgamento de design em um recurso reutilizável, mantendo a aprovação final com um fundador ou designer.

6. Equipes de ferramentas internas que atendem áreas diferentes

Uma equipe de plataforma interna pode compartilhar mecanismos aprovados de acessibilidade, estados e layout, mantendo uma pequena camada de diretrizes para cada tarefa — como conciliação financeira ou operações de suporte. O ganho é assegurar uma implementação de qualidade comum sem forçar fluxos de trabalho muito diferentes a caber no mesmo template visual.

7. Equipes de setores regulados que precisam de uma trilha de auditoria

Uma equipe de saúde, finanças ou segurança poderia armazenar o prompt, os dados de entrada, a versão do modelo, a versão das diretrizes, a renderização, as verificações e a decisão do avaliador em cada execução. O ganho é a rastreabilidade: quem revisa consegue identificar qual regra orientou o resultado e qual pessoa aprovou a exceção. Esse padrão, por si só, não torna o resultado compatível com as normas, mas facilita a reconstrução das evidências da revisão.

Se sua organização ainda está decidindo se o fluxo com agentes deve virar um produto ou permanecer como capacidade interna, este framework para decidir entre criar ou comprar agentes de programação é o próximo passo útil.

Três produtos que vale a pena criar

1. Compilador de design systems para agentes, a oportunidade mais forte

Crie um workspace que transforme tokens, documentação de componentes e correções recorrentes de revisão já existentes em uma empresa em um arquivo de diretrizes versionado, um mapa de implementação restrito e um pacote inicial de avaliações. Equipes de operações de design e de plataforma pagariam por isso porque o produto se posiciona diretamente entre o sistema atual e cada agente de programação que elas adotarem.

A demanda é menor do que a do mercado genérico de geração de sites, mas está muito mais próxima de quem compra. Cerca de 260 buscas mensais nos EUA têm como alvo design system software, com intenção comercial, dificuldade de palavra-chave 14 e CPC de $12.33. Esse CPC importa porque sinaliza que fornecedores já atribuem valor a essa atenção, mesmo com um volume modesto de consultas.

A menor versão comercializável precisa de um caminho de entrada — por exemplo, um repositório acompanhado de um formulário estruturado para correções de revisão — e um caminho de saída: design.md, um mapa de primitivos aprovados, três cenários fixos e um relatório mostrando quais regras cada execução cumpriu. Comece com um framework e uma categoria de artefato.

O obstáculo é a configuração inicial. Raramente os critérios de design mais valiosos de uma empresa estão organizados o suficiente para uma importação automática. No começo, o produto funcionará em parte como software e em parte como serviço; sua vantagem competitiva virá da capacidade de transformar um histórico confuso de revisões em decisões confiáveis e testáveis.

2. Fábrica de microsites fiéis à marca

Crie um gerador para agências e equipes de receita capaz de produzir uma categoria bem delimitada de página alinhada à marca — como propostas ou microsites de campanha — a partir de dados aprovados e de um pacote de restrições específico para cada cliente. O comprador paga pela iteração controlada e pelas evidências de aprovação, não pela geração bruta de páginas.

A demanda ampla é grande: ai website builder recebe cerca de 40,500 buscas mensais nos EUA, com alta de 49% na tendência anual, intenção comercial e CPC de $31.41. As ofertas existentes vão de planos gratuitos a aproximadamente $160 por mês, portanto um novo concorrente não vencerá com a promessa “digite um prompt e receba um site”. É preciso oferecer algo mais específico: as mesmas regras de marca, os mesmos primitivos aprovados e as mesmas evidências de revisão em todas as execuções.

O MVP deve aceitar um tipo de página, um formato de importação, um conjunto fixo de componentes, três cenários de avaliação e uma tela de aprovação lado a lado. O obstáculo é competir em uma categoria lotada e com concorrentes consolidados. Governança e repetibilidade precisam ser o produto; caso contrário, a solução vira apenas mais uma interface superficial sobre um modelo.

3. Serviço de QA de design para agentes

Crie um serviço para pull requests que renderize páginas produzidas por agentes em viewports fixos, execute verificações mecânicas de design, armazene as versões do modelo e das diretrizes e encaminhe diferenças subjetivas a uma fila de revisão humana às cegas. Equipes que já usam agentes de programação pagariam para detectar falhas recorrentes antes que elas chegassem a um avaliador sênior.

Cerca de 320 buscas mensais nos EUA têm como alvo visual regression testing, com dificuldade de palavra-chave 8 e CPC de $20.56. Não é um volume de mercado de massa, mas comprova diretamente que há equipes em busca de verificação visual automatizada. A baixa dificuldade abre espaço para uma abordagem específica para agentes, centrada no cumprimento de regras em vez de apenas na diferença entre pixels.

O MVP pode começar com uma verificação no GitHub, dois viewports, uma dúzia de regras determinísticas, armazenamento de capturas de tela e um veredito do avaliador. O obstáculo é que diferença visual não é sinônimo de qualidade de design. Uma comparação de pixels pode detectar desvios, e um modelo avaliador pode esboçar uma crítica, mas hierarquia, significado do produto e novas políticas continuam exigindo pessoas.

O que esse padrão não resolve

Um único arquivo não transforma um design system fraco em um sistema forte. Ele não fornece decisões que sua equipe nunca tomou, não corrige componentes inacessíveis, não comprova a exatidão dos fatos nem decide uma nova política de produto. Também não faz todos os modelos se comportarem da mesma maneira.

As restrições podem conter variações repetitivas, mas também podem perpetuar um elemento ruim. As avaliações podem impedir falhas conhecidas, mas também podem favorecer uma rubrica estreita e deixar passar um problema novo. A revisão humana pode detectar erros de julgamento, desde que os avaliadores registrem as correções em um formato que o sistema consiga reutilizar.

O resultado da Vercel é um sinal útil justamente porque a empresa declara suas limitações. Seis páginas não constituem um estudo de confiabilidade. Verificações de falhas conhecidas não medem a qualidade geral do design. Todas as páginas testadas ainda tinham um impeditivo para publicação. A meta realista da primeira adoção é reduzir correções repetidas, e não automatizar a aprovação de design.

A ação concreta para segunda-feira é esta: escolha uma página recorrente, salve a primeira versão produzida sem assistência, reúna as dez últimas correções feitas pela equipe nesse tipo de página, encaminhe cada uma para diretrizes, primitivos, código ou decisão humana e então faça uma comparação equivalente às cegas. Só amplie o sistema quando esse ciclo reduzir o tempo de revisão medido.

A IA realmente consegue criar um site para mim?

Sim. Agentes de programação e criadores de sites com IA conseguem produzir páginas funcionais a partir de um prompt. A questão mais difícil é saber se a primeira versão segue sua marca, preserva os fatos fornecidos, contempla os estados corretos e passa pela revisão. Diretrizes, primitivos restritos e avaliações equivalentes atacam essas lacunas.

Os criadores de sites com IA são bons?

Eles são úteis para ganhar velocidade, principalmente quando a tarefa é bem delimitada e as escolhas de implementação são restritas. São menos confiáveis quando a definição de “bom” depende de julgamento de produto não documentado, de uma linguagem visual proprietária ou de novas decisões de política. Avalie-os pelo tempo de correção da primeira tentativa, e não pela demonstração mais bonita depois de gerar novas versões.

Quanto custam os criadores de sites com IA?

Os preços disponíveis de criadores de sites com IA vão de aproximadamente $0 a $160 por mês. Esse valor não inclui os custos da sua equipe com revisão, correção, aprovação e risco para a marca. Meça essas horas separadamente antes de decidir se um sistema interno mais controlado compensa.

É melhor criar seu próprio site ou usar um criador de sites?

Use um criador de sites quando a página for padronizada, os riscos forem baixos e as restrições da ferramenta forem compatíveis com sua marca. Crie um fluxo controlado com agentes quando você repete o mesmo artefato, precisa de componentes aprovados e evidências ou gasta um volume relevante de horas de profissionais seniores corrigindo resultados. O número decisivo é o custo recorrente de revisão.

Se você quer implementar na sua empresa um fluxo de agentes de programação atento ao design, conheça o serviço de desenvolvimento de agentes de IA.