Carbon: el sistema de diseño open-source que lanzó un servidor MCP

IBM describe Carbon como su sistema de diseño open-source para productos y experiencias digitales, con el IBM Design Language como base, compuesto por código funcional, herramientas y recursos de diseño, guías de interfaz humana y una comunidad de colaboradores. Está financiado y construido por IBM para las necesidades comerciales de IBM, y se publica abiertamente para que cualquiera pueda usarlo y contribuir.

Vale la pena detenerse en ese modelo de financiación, porque determina qué es lo que se está adoptando. Carbon no es un proyecto comunitario que casualmente tiene usuarios corporativos; es un sistema corporativo que resulta ser abierto. Las decisiones de la hoja de ruta sirven a los productos de IBM. En la práctica, esto es mayormente positivo —significa que el sistema se mantiene genuinamente en lugar de quedar abandonado cuando un mantenedor cambia de trabajo—, pero también significa que es poco probable que llegue una funcionalidad que su producto necesite y los de IBM no.

La decisión estructural que hace que Carbon merezca ser estudiado es que no es un solo sistema. IBM publica un stack, y la separación entre los niveles es explícita en la propia navegación del sitio.

Esta es la misma estructura a la que Spotify llegó con Encore, alcanzada desde una dirección diferente, y resuelve el mismo problema: ¿dónde va un componente cuando solo un producto lo necesita? Sin una capa de dominio, la respuesta es o bien "al núcleo, haciéndolo más pesado para todos" o "fuera del sistema, donde se desvirtúa". Con ella, el trabajo especializado tiene un hogar que no puede filtrarse.

Si está construyendo un sistema para más de un producto, esto es lo más transferible de Carbon. No necesita tres sitios publicados. Necesita una regla sobre a cuál de sus tres niveles pertenece una decisión determinada, y la disciplina de no permitir que una necesidad específica de un producto sea promovida a la base solo porque resultaba más fácil.

Carbon soporta múltiples implementaciones de código y la documentación enumera cada una con su mantenedor. Esa lista es lo más importante desde el punto de vista práctico en el sitio si está evaluando su adopción:

Esta honestidad es digna de mención como una práctica de documentación por derecho propio. Muchos sistemas de diseño enumeran paquetes de frameworks sin decir quién es responsable de ellos, lo que deja que los adoptantes descubran la diferencia durante un incidente.

Carbon MCP está disponible como vista previa pública. Es un servidor de Model Context Protocol que otorga a los agentes de IA y a las aplicaciones de IA acceso directo a la base de conocimientos de Carbon: elementos principales, iconografía, pictogramas, directrices, documentación de uso y librerías de componentes para React y Web Components, además de la librería Carbon for IBM Products.

Las herramientas documentadas son específicas, y leerlas indica exactamente qué problema cree IBM que está resolviendo:

Las razones declaradas por IBM son el acceso instantáneo de la IA a los estándares de Carbon, una generación de código de mayor fidelidad a partir de ejemplos reales y una consistencia mejorada gracias a una fuente de verdad compartida que reduce la divergencia y el retrabajo. El acceso durante la vista previa es inmediato para los empleados de IBM; los demás pueden solicitarlo a través de un formulario de acceso anticipado.

La importancia no radica en que IBM haya creado una integración. Radica en lo que la existencia del servidor admite: los datos de entrenamiento de un modelo no son una fuente fiable para la API actual de un sistema de diseño, y pedirle que escriba código de Carbon de memoria produce componentes que parecen plausibles pero son incorrectos. El servidor existe porque la recuperación de datos (retrieval) es superior al recuerdo (recall).

Al leer los tres grandes sistemas de diseño empresariales publicados de forma abierta, se observa que la misma estrategia se repite tres veces en dieciocho meses, ejecutada de formas distintas:

Tres apuestas diferentes, una premisa compartida: el consumidor de un sistema de diseño ya no es solo un desarrollador humano que lee documentación. Esa premisa ya no es controvertida, pero el hecho de que los tres actuaran en consecuencia en un año y medio es algo que la literatura sobre sistemas de diseño aún no ha asimilado.

Resulta tentador interpretar que Carbon MCP hace que la guía de diseño basada en archivos quede obsoleta. No es así, porque ambos responden a preguntas diferentes.

Un agente con Carbon MCP y sin guía de diseño produce componentes de Carbon técnicamente correctos, dispuestos en una interfaz sin un punto de vista definido. Un agente con una guía de diseño sólida pero sin MCP produce un diseño bien juzgado que llama a props que fueron renombradas en v11. Usted necesita ambos, y no se solapan.

Analizamos 299 archivos DESIGN.md publicados para que los agentes los lean, y las cifras muestran qué mitad se está descuidando actualmente: el 86% especifica los colores como hex puro sin un rol semántico, el 76% no establece ninguna prohibición, el 57% no define motivos distintivos y el 69% no dice nada sobre el modo oscuro. Todo eso pertenece a la segunda columna: las preguntas que un servidor MCP nunca iba a responder.

Carbon es un sistema genuinamente bueno, pero adoptarlo suele ser una decisión errónea. El factor determinante es si usted desea que se le proporcione una opinión de diseño.

El argumento de la accesibilidad merece su propio peso. En los componentes de Carbon se ha invertido un trabajo real de accesibilidad durante años, respaldado por la práctica de accesibilidad de IBM. Reproducir eso en su propia librería de componentes es un compromiso de varios años que la mayoría de los equipos inician y abandonan. Si su producto es una herramienta interna, adoptar Carbon es prácticamente una victoria gratuita.

El contraargumento es que un sistema de diseño conlleva una identidad, y la de Carbon es la de IBM. Que sea tematizable no significa que sea neutral: la densidad, el lenguaje de formas, el tratamiento tipográfico y los modismos de interacción codifican decisiones tomadas para los productos de IBM. Si su producto compite en parte por cómo se siente, gastará más energía luchando contra esos elementos de la que habría gastado definiendo su propio sistema.

1. Separe el lenguaje de marca de la implementación. El IBM Design Language y Carbon son documentos diferentes con distintos responsables y ritmos de cambio. Fusionarlos implica que cada ajuste de un componente se convierta en una conversación sobre la marca.
2. Asigne una capa de dominio al trabajo específico de un dominio. Un componente que solo necesita un producto pertenece a una capa superior al núcleo, no dentro de él ni fuera del sistema.
3. Publique quién mantiene cada implementación. Quienes adoptan el sistema toman una decisión de riesgo. Permítales hacerlo basándose en los hechos.
4. Exponga el sistema a los agentes deliberadamente. Ya sea mediante MCP, una exportación de tokens legible por máquina o un archivo bien estructurado en el repositorio, el agente escribirá basándose en su sistema de cualquier manera. La única pregunta es si lo hará a partir de su documentación o de sus datos de entrenamiento.