Carbon: o design system open source que lançou um servidor MCP

O Carbon é descrito pela IBM como seu design system open source para produtos e experiências digitais, tendo o IBM Design Language como sua fundação, consistindo em código funcional, ferramentas e recursos de design, diretrizes de interface humana e uma comunidade de colaboradores. Ele é financiado e construído pela IBM para as necessidades de negócio da IBM, e lançado abertamente para que qualquer pessoa possa usar e contribuir.

Vale a pena pausar para analisar esse modelo de financiamento, pois ele determina o que você está adotando. O Carbon não é um projeto comunitário que por acaso tem usuários corporativos; é um sistema corporativo que por acaso é aberto. As decisões do roadmap servem aos produtos da IBM. Na prática, isso é majoritariamente positivo — significa que o sistema é genuinamente mantido em vez de ser abandonado quando um mantenedor muda de emprego — mas também significa que é improvável que uma funcionalidade que seu produto precisa, mas que os da IBM não precisam, venha a existir.

A decisão estrutural que faz o Carbon valer a pena ser estudado é que ele não é um sistema único. A IBM publica uma stack, e a separação entre os níveis é explícita na navegação do próprio site.

Este é o mesmo formato que o Spotify alcançou com o Encore, alcançado por uma direção diferente, e resolve o mesmo problema: para onde vai um componente quando apenas um produto precisa dele? Sem uma camada de domínio, a resposta é ou "para dentro do core, tornando-o mais pesado para todos" ou "fora do sistema, onde ele fica à deriva". Com uma, o trabalho especializado tem um lugar que não vaza.

Se você está construindo um sistema para mais de um produto, este é o elemento mais transferível do Carbon. Você não precisa de três sites publicados. Você precisa de uma regra sobre a qual dos seus três níveis uma determinada decisão pertence, e da disciplina de não permitir que uma necessidade específica de um produto seja promovida para a fundação apenas porque era mais fácil.

O Carbon suporta múltiplas implementações de código, e a documentação lista cada uma com seu mantenedor. Essa lista é a coisa mais importante na prática se você estiver avaliando a adoção:

A honestidade aqui merece destaque como uma prática de documentação por si só. Muitos design systems listam pacotes de frameworks sem dizer quem é o responsável por eles, o que deixa para que os adotantes descubram a diferença durante um incidente.

O Carbon MCP está disponível em preview público. É um servidor Model Context Protocol que concede a agentes de IA e aplicações de IA acesso direto à base de conhecimento do Carbon — elementos core, iconografia, pictogramas, diretrizes, documentação de uso e bibliotecas de componentes para React e Web Components, além da biblioteca Carbon for IBM Products.

As ferramentas documentadas são específicas, e lê-las revela exatamente qual problema a IBM acredita estar resolvendo:

As razões declaradas pela IBM são o acesso instantâneo da IA aos padrões do Carbon, a geração de código de maior fidelidade a partir de exemplos reais e a melhoria da consistência por meio de uma fonte única de verdade que reduz divergências e retrabalho. O acesso durante o preview é imediato para funcionários da IBM; outros podem solicitá-lo por meio de um formulário de acesso antecipado.

A importância não reside no fato de a IBM ter construído uma integração. Reside no que a existência do servidor admite: os dados de treinamento de um modelo não são uma fonte confiável para a API atual de um design system, e pedir que ele escreva código Carbon de memória produz componentes que parecem plausíveis, mas estão errados. O servidor existe porque a recuperação (retrieval) vence a recordação (recall).

Ao analisar os três maiores design systems corporativos publicados abertamente, o mesmo movimento aparece três vezes em dezoito meses, executado de formas diferentes:

Três apostas diferentes, uma premissa compartilhada: o consumidor de um design system não é mais apenas um desenvolvedor humano lendo a documentação. Essa premissa já não é controversa, mas o fato de que todos os três agiram com base nela em um ano e meio é algo que a literatura de design systems ainda não acompanhou.

É tentador interpretar o Carbon MCP como algo que torna obsoletas as orientações de design baseadas em arquivos. Não torna, pois os dois respondem a perguntas diferentes.

Um agente com Carbon MCP e sem orientações de design produz componentes Carbon tecnicamente corretos, organizados em uma interface sem ponto de vista. Um agente com orientações de design fortes e sem MCP produz um layout bem julgado, mas chamando props que foram renomeadas na v11. Você precisa de ambos, e eles não se sobrepõem.

Amostramos 299 arquivos DESIGN.md publicados para leitura de agentes, e os números mostram qual metade está sendo negligenciada: 86% especificam cores como hex puro sem papel semântico, 76% não declaram nenhuma proibição, 57% não definem motivos distintos e 69% não mencionam nada sobre o modo escuro. Tudo isso pertence à segunda coluna — as perguntas que um servidor MCP jamais responderia.

O Carbon é um sistema genuinamente bom, mas adotá-lo frequentemente é a decisão errada. O fator decisivo é se você deseja que uma opinião de design seja fornecida a você.

O argumento da acessibilidade merece peso próprio. Os componentes do Carbon receberam investimentos reais em acessibilidade ao longo de anos, respaldados pelas práticas de acessibilidade da IBM. Reproduzir isso em sua própria biblioteca de componentes é um compromisso de vários anos que a maioria das equipes inicia e abandona. Se o seu produto é uma ferramenta interna, adotar o Carbon é quase uma vitória gratuita.

O contra-argumento é que um design system carrega uma identidade, e a do Carbon é a da IBM. Ser customizável não significa ser neutro: a densidade, a linguagem de formas, o tratamento tipográfico e os idiomatismos de interação codificam decisões tomadas para produtos IBM. Se o seu produto compete, em parte, pela sensação que transmite, você gastará mais energia lutando contra esses pontos do que gastaria definindo seu próprio sistema.

1. Separe a linguagem da marca da implementação. O IBM Design Language e o Carbon são documentos diferentes, com proprietários e ritmos de mudança distintos. Fundi-los significa que cada ajuste de componente se torna uma conversa sobre a marca.
2. Dê ao trabalho específico de domínio uma camada de domínio. Um componente que apenas um produto necessita pertence acima do core, não dentro dele e nem fora do sistema.
3. Publique quem mantém cada implementação. Quem adota o sistema está tomando uma decisão de risco. Permita que tomem essa decisão com base em fatos.
4. Exponha o sistema a agentes deliberadamente. Seja via MCP, uma exportação de tokens legível por máquina ou um arquivo bem estruturado no repositório, o agente escreverá com base no seu sistema de qualquer maneira. A única questão é se ele fará isso a partir da sua documentação ou de seus dados de treinamento.