Metade das métricas de design system já não funciona, diz artigo

O artigo parte de uma revisão da lista de métricas de design system que o autor publicou há quatro anos. Segundo ele, muita coisa deixou de ser útil. Total de componentes, instalações e downloads do npm, número de chamadas de MCP e sucesso autorrelatado por agentes só sobem e não dizem se o sistema melhora o trabalho. Mais chamadas de MCP, por exemplo, podem significar apenas agentes confusos.

Entram no relatório conformidade por superfície, taxa de aprovação de agentes nas regras, custo por entrega pronta para produção, taxa de aprovação em acessibilidade e uma lista de fricção dos componentes. Também ganham novo sentido o detach rate, a paridade entre Figma e código, os overrides e valores hard-coded, e o tempo até o primeiro componente (humano versus agente). A segunda parte trata de evals: tarefas reais rodadas com ferramentas, modelos e componentes, pontuadas contra a intenção do sistema. O autor sugere começar com 10 a 15 tarefas, rodar cada uma ao menos 3 vezes, ler o código e avaliar o visual, e testar também modelos mais baratos.

A cobertura anterior já apontava essa direção. Em 17 de setembro de 2026, o CEVIU noticiou "Métricas de Engenharia Obsoletas? A IA Redefine a Avaliação de Produtividade no Desenvolvimento", sobre métricas tradicionais perdendo valor com código gerado por IA. Em 16 de junho de 2026, em "Design System e IA: por que regras em texto não funcionam, e o que fazer no lugar", o tema era agentes ignorarem diretrizes longas. Agora o foco passa de como orientar agentes para como medir se eles seguem as regras.

Para quem opera um design system, a leitura é que adoção deixou de bastar como argumento de orçamento. Mostrar conformidade, acessibilidade e custo por entrega tende a ser mais convincente para stakeholders. Para o usuário final, o ganho esperado é consistência: a mesma qualidade de interface, venha ela de uma pessoa ou de um agente.