Equipes usam agentes de IA para criar componentes de design system

O experimento

Kaelig Deloumeau-Prigent construiu um componente Menu de design system React (Intuit Design System) a partir de um arquivo Figma sem escrever código manualmente. Primeiro levou ~2 dias em pair-programming com Claude para criar um componente com qualidade de produção; depois gastou semanas montando um pipeline com 8 agentes que reproduz o mesmo resultado em ~1 hora. Ele escolheu o Menu por ser um dos componentes mais difíceis: submenus aninhados fora da árvore DOM via portal, cinco modelos de seleção com diferentes papéis ARIA e contratos de teclado, e navegação por setas com comportamento distinto conforme a posição na árvore.

A motivação foi que figma-to-code em um único prompt serve para protótipos, mas componentes de produção exigem um nível de qualidade que só prompting não atinge de forma consistente: design tokens, semântica ARIA, temas e experiência com leitores de tela. Modelos tendem a adivinhar requisitos não funcionais e preencher lacunas. A tentativa inicial foi autonomia total, mas encontrou um teto: o pipeline seguia regras, porém não questionava. A solução foi redesenhar o sistema como um "thought partner", com espaço estruturado para julgamento humano onde ele importa.

Arquitetura do pipeline

O pipeline tem três fases - Understand, Build e Verify - e oito agentes, cada um com papel, artefato produzido, critério de saída e orçamento de iteração. Nenhum agente enxerga o todo; cada um recebe apenas os artefatos necessários em janelas de contexto separadas.

• Understand: Design Analyst extrai a especificação do Figma e gera brief.md e figma-raw.json, com checklist de completude de 12 pontos; Library Researcher audita as dependências do projeto e gera component-rules.md com regras obrigatórias (CR-) e aconselháveis (AR-); Component Architect desenha API, composição e estrutura de arquivos em architecture.md, com notas de handoff específicas para agentes seguintes.
• Build: Code Writer gera TypeScript, CSS Modules e barrel exports, obrigado por contrato a ler component-rules.md antes de codar; Accessibility Auditor roda uma pilha de 8 camadas de testes de acessibilidade, com achados P1/P2/P3 e até 3 tentativas de correção; Story Author escreve stories no Storybook com interaction tests cobrindo variantes, estados e casos de borda.
• Verify: Visual Reviewer compara screenshots do Storybook com o Figma em 9 dimensões, com até 5 iterações e parada por retornos decrescentes; Quality Gate roda compilação, lint e formatação, com 1 retry e bail se o erro persistir.

O Design Analyst conecta ao Figma via Figma Console MCP (plugin com WebSocket que expande filhos de instâncias e resolve variáveis para nomes de tokens) com fallback para a REST API. Quando disponível, usa Specs (dados estruturados em YAML dentro de frames do Figma, de Nathan Curtis) como fonte primária de tokens, com referências explícitas como $space.component.stack.padding.xx-small. Se as fontes discordam, ele marca conflito em vez de adivinhar.

Três padrões atravessam o sistema: handoffs baseados em artefatos (documentos estruturados como contratos, não mensagens), validação com contexto fresco (validadores recebem só o necessário, como revisor de PR) e orçamentos de iteração para evitar perseguir perfeição em detalhes mínimos.

Baseline "vibe-coded"

Antes do pipeline, ele construiu o componente manualmente com Claude em ~15–20 horas e 40 commits. O resultado funcionava, mas havia custos escondidos: o agente escreveu ~300 linhas de navegação por teclado customizada quando @floating-ui/react já oferecia hooks como useListNavigation, useTypeahead, useDismiss, useRole e FloatingFocusManager. Uma análise posterior indicou que ~300 linhas poderiam virar ~50 linhas de composição de hooks, mas a reescrita foi abandonada pelo custo de reteste. O episódio ilustrou o problema do vibe coding: o agente compartilha as mesmas lacunas de conhecimento do humano, e elas se compõem; a conversa "verifique o que a biblioteca já faz" não acontece porque não há espaço estrutural para ela.

Outros exemplos: o atributo disabled nativo impede foco, enquanto o padrão WAI-ARIA recomenda aria-disabled="true" sem disabled; e o problema do "safe triangle" em submenus hover foi resolvido com safePolygon do floating-ui após tentativa e erro.

Três níveis de falhas

Ele classificou 34 problemas encontrados em três tiers: Tier 1 (18) - regras que, uma vez escritas, nunca recorrem, resolvidas com skill files e memória; Tier 2 (9) - gaps de infraestrutura e ferramentas (MCPs, plugin do Figma, APIs do design system); Tier 3 (6) - julgamento humano necessário, resolvidos com gates explícitos.

Exemplos de Tier 1: prefixos de tokens (o IDS usa --color-*, --space-* etc., não --ids-*), evitar garimpar node_modules, não usar fallbacks em CSS custom properties, não usar title case (a marca exige sentence case) e stories que testem múltiplos passos.

Os 27 tokens fabricados

Na v0.2, o pipeline completou com sucesso: 8 agentes, 34 stories, 17 interaction tests passando. Mas o componente estava completamente sem estilo: todos os 27 tokens CSS usavam um prefixo plausível --ids-* que não existia, então tudo resolvia para nada. Os testes passaram porque verificam comportamento, não aparência. A correção levou três regras: documentar o prefixo correto, obrigar o Design Analyst a chamar o MCP de tokens do IDS e fazer o Quality Gate falhar ao encontrar --ids-. Na v0.3, a fabricação caiu para zero e permaneceu assim em 13 releases seguintes.

Esse processo é chamado de "vibe RLHF": reforço por feedback humano aplicado às regras e contexto ao redor do modelo, não aos pesos. O fluxo é observar falha, escrever regra, reexecutar e validar. As regras vivem em três camadas: workarounds.md (observações brutas), memória (instruções amplamente aplicáveis) e skill files (regras rígidas nos system prompts dos agentes).

Contratos entre agentes

Os agentes não conversam entre si; trocam documentos com campos obrigatórios. Dados ausentes são marcados como [PENDING] ou [UNRESOLVED], nunca omitidos em silêncio. O Component Architect pode escrever notas direcionadas, como "For Code Writer: use var(--radius-action) para focus rings dos itens".

A interação mais importante é entre Library Researcher e Code Writer: o pesquisador audita dependências antes de qualquer código, especificando hooks e composições em vez de instruções vagas, e avalia alternativas open source (Radix UI, React Aria, Headless UI, AriaKit). O Code Writer é obrigado a ler component-rules.md antes de escrever. Há também um protocolo de push-back com severidades como [BLOCKING] (pipeline para e pede input humano) e [CONCERN] (segue com ressalvas).