Design system fraco travará times que usam IA, argumenta guia

A tese: fundações antes de máquina legível

Romina Kavcic argumenta que times estão se concentrando demais em tornar seus design systems "machine-readable" e pulando o trabalho de base - o que ela chama de "foundations maxxing". Para ela, gastar muitos tokens (créditos) de IA não gera produto escalável: sem fundação sólida, não há escala, mesmo com o fluxo de trabalho perfeito.

Design system como infraestrutura

O argumento central é que um design system é infraestrutura - a "API" que permite à IA construir produtos com segurança, assim como o pipeline de CI/CD ou o banco de dados. Quando qualquer pessoa pode gerar uma tela ou app, o diferencial competitivo é o sistema por trás: marca, consistência e unicidade. Para vender a ideia à liderança, ela sugere enquadrá-lo como infraestrutura, citando que desenvolver uma página ou tela com design system fica pelo menos 50% mais rápido que codar do zero.

Como auditar

Antes de conectar qualquer agente, Kavcic recomenda uma auditoria: revisar tokens e variáveis no Figma (camadas escondidas, cores hex cruas, escopos), componentes e variantes, código com linters, documentação e arquivos .md, compartilhamento entre times, acessibilidade e fluxos de design-desenvolvimento. Também sugere apontar um agente para os arquivos da Figma, docs ou código para comparar, contar o drift e achar componentes desanexados, além de uma pesquisa interna com desenvolvedores, design e o time do design system. O relatório deve caber em uma página.

Ferramentas que ela usa: Playwright (capturas de tela em todos os estados), Figma MCP, Tidy Core (plugin dela própria, que encontra instâncias desanexadas e variáveis fantasmas), Claude Code, Cursor, GitHub MCP, Storybook, Style Dictionary e PostHog MCP.

Sete passos para preparar as fundações

1. Estruturar a nomenclatura de design tokens;
2. Adicionar descrições aos componentes (manualmente ou com IA);
3. Criar arquivos .md descrevendo componentes, variantes, uso e relações;
4. Aplicar regra de binding semântico, com tokens como color.action.primary, definindo escopos para evitar aplicações erradas (tokens de borda em fundo, por exemplo);
5. Manter um decision log - documento curto e datado com as decisões e seus motivos, compartilhado com os agentes;
6. Conectar Figma ao código, transformando variáveis em CSS variables via Style Dictionary ou script próprio;
7. Configurar MCPs (Figma MCP, Tidy Core, GitHub, PostHog etc.), alimentar os arquivos .md e o CLAUDE.md com as regras - o "harness" do agente - sem compartilhar informações não permitidas na organização.

Respeito aos devs e colaboração

Kavcic cita um caso recente: um product manager abriu 114 pull requests, e times de desenvolvimento receberam cerca de 60% mais PRs do que em um mês recorde do ano anterior. Como as pessoas que geram esses PRs não têm formação em UX, nem experiência em design ou testes, elas pulam componentes existentes e transferem aos desenvolvedores o papel de "faxineiros", revisando código de baixa qualidade em vez de melhorá-lo.

Ela também critica o fim das reuniões: pular discussões é um atalho para usar só a IA. "Produto é gente": a IA não conhece nem consegue prever o que os usuários e o time vivenciam. Pular as conversas significa pular as necessidades das pessoas.

UX primeiro, UI depois

Pessoas sem experiência podem agora criar apps e telas e decidir sobre conteúdo - e o tempo ganho com IA acaba perdido explicando princípios de design e UX 101. Sobre a tendência de dizer que "dá para reverter rápido", ela alerta que usuários não estão dispostos a brincar de experimentos de UI todos os dias; consistência existe por um motivo.

Ao mesmo tempo, ela reconhece que a IA é útil para UX: conectar ferramentas de analytics e suporte via MCP ou API para obter métricas em tempo real facilita priorizar e melhorar problemas de usuários.

Conclusão

O fio condutor das histórias do artigo é gente que pula etapas. A recomendação final é engajar o time em discussões construtivas - e, diante de um PR cheio de estilos ruins de algum entusiasta de no-code, mandar o artigo.