Carbon: das Open-Source-Designsystem, das einen MCP-Server bereitstellt

Carbon wird von IBM als sein Open-Source-Designsystem für Produkte und digitale Erlebnisse beschrieben, mit der IBM Design Language als Fundament, bestehend aus ausführbarem Code, Design-Tools und Ressourcen, Human Interface Guidelines und einer Community von Mitwirkenden. Es wird von IBM für die geschäftlichen Bedürfnisse von IBM finanziert und entwickelt und ist offen für jeden zur Nutzung und zur Rückmeldung freigegeben.

Dieses Finanzierungsmodell ist es wert, kurz innezuhalten, da es bestimmt, was man eigentlich übernimmt. Carbon ist kein Community-Projekt, das zufällig Unternehmenskunden hat; es ist ein Unternehmenssystem, das zufällig Open Source ist. Roadmap-Entscheidungen dienen IBM-Produkten. In der Praxis ist das meistens gut (es bedeutet, dass das System tatsächlich gepflegt wird, anstatt aufgegeben zu werden, wenn ein Maintainer den Job wechselt), aber es bedeutet auch, dass ein Feature, das Ihr Produkt benötigt, aber IBM nicht, unwahrscheinlich erscheinen wird.

Die strukturelle Entscheidung, die Carbon studierenswert macht, ist, dass es nicht ein einzelnes System ist. IBM veröffentlicht einen Stack, und die Trennung zwischen den Ebenen ist in der Navigation der Website selbst explizit.

Dies ist die gleiche Form die Spotify mit Encore erreicht hat, die aus einer anderen Richtung erreicht wurde und dasselbe Problem löst: Wohin kommt eine Komponente, wenn nur ein Produkt sie benötigt? Ohne eine Domänenebene lautet die Antwort entweder „in den Kern, was ihn für alle schwerfälliger macht“ oder „außerhalb des Systems, wo sie driftet“. Mit einer Ebene hat spezialisierte Arbeit ein Zuhause, das nicht auslaufen kann.

Wenn Sie ein System für mehr als ein Produkt bauen, ist dies das am besten übertragbare Element in Carbon. Sie benötigen nicht drei veröffentlichte Websites. Sie benötigen eine Regel darüber, zu welcher Ihrer drei Ebenen eine bestimmte Entscheidung gehört, und die Disziplin, nicht zuzulassen, dass ein produktspezifisches Bedürfnis aus Gründen der einfacheren Handhabung in das Fundament aufsteigt.

Carbon unterstützt mehrere Code-Implementierungen, und die Dokumentation listet jede einzelne mit ihrem Maintainer auf. Diese Liste ist das praktisch wichtigste Element auf der Website, wenn Sie die Einführung evaluieren:

Diese Offenheit ist als Dokumentationspraxis an sich bemerkenswert. Viele Designsysteme listen Framework-Pakete auf, ohne anzugeben, wer für diese verantwortlich ist, sodass Anwender den Unterschied erst während eines Vorfalls entdecken.

Carbon MCP ist als Public Preview verfügbar. Es handelt sich um einen Model Context Protocol Server, der AI-Agenten und AI-Anwendungen direkten Zugriff auf die Carbon-Wissensbasis gewährt: Core-Elemente, Ikonografie, Piktogramme, Richtlinien, Nutzungsdokumentation und Komponentenbibliotheken für React und Web Components sowie die Carbon for IBM Products Bibliothek.

Die dokumentierten Tools sind spezifisch, und ihre Beschreibung zeigt genau, welches Problem IBM damit lösen möchte:

Die von IBM genannten Gründe sind der sofortige AI-Zugriff auf Carbon-Standards, eine präzisere Code-Generierung basierend auf realen Beispielen und eine verbesserte Konsistenz durch eine gemeinsame Source of Truth, die Drift und Nacharbeit reduziert. Der Zugriff während der Preview ist für IBM-Mitarbeiter sofort möglich; andere können ihn über ein Early-Access-Formular beantragen.

Die Bedeutung liegt nicht darin, dass IBM eine Integration gebaut hat. Es ist das, was die Existenz des Servers eingesteht: Die Trainingsdaten eines Modells sind keine zuverlässige Quelle für die aktuelle API eines Designsystems, und die Aufforderung, Carbon-Code aus dem Gedächtnis zu schreiben, erzeugt Komponenten, die plausibel, aber falsch sind. Der Server existiert, weil Retrieval besser ist als Recall.

Betrachtet man die drei großen, öffentlich verfügbaren Enterprise-Designsysteme, so zeigt sich derselbe Trend dreimal innerhalb von achtzehn Monaten, wenn auch unterschiedlich umgesetzt:

Drei verschiedene Strategien, eine gemeinsame Prämisse: Der Nutzer eines Designsystems ist nicht mehr nur ein menschlicher Entwickler, der die Dokumentation liest. Diese Prämisse ist nicht mehr umstritten, aber die Tatsache, dass alle drei innerhalb von anderthalb Jahren darauf reagiert haben, ist in der Literatur zu Designsystemen noch nicht ausreichend reflektiert worden.

Es ist verlockend, Carbon MCP so zu interpretieren, dass dateibasierte Design-Richtlinien obsolet werden. Das ist nicht der Fall, da beide unterschiedliche Fragen beantworten.

Ein Agent mit Carbon MCP, aber ohne Design-Richtlinien, erzeugt technisch korrekte Carbon-Komponenten, die in einem Interface ohne klare Design-Vision angeordnet sind. Ein Agent mit starken Design-Richtlinien, aber ohne MCP, erzeugt ein gut durchdachtes Layout, ruft jedoch Props auf, die in v11 umbenannt wurden. Man benötigt beides, und sie überschneiden sich nicht.

Wir haben 299 DESIGN.md-Dateien analysiert, die für Agents veröffentlicht wurden. Die Zahlen zeigen, welcher Teil derzeit vernachlässigt wird: 86 % geben Farben als reine Hex-Werte ohne semantische Rolle an, 76 % nennen keinerlei Verbote, 57 % definieren keine markanten Motive und 69 % sagen nichts zum Dark Mode. All dies betrifft die zweite Spalte: die Fragen, die ein MCP-Server niemals beantworten sollte.

Carbon ist ein wirklich gutes System, doch die Entscheidung für den Einsatz ist häufig die falsche. Der entscheidende Faktor ist, ob Sie eine vorgegebene Design-Meinung übernehmen möchten.

Das Argument der Barrierefreiheit verdient ein eigenes Gewicht. In die Carbon-Komponenten wurde über Jahre hinweg echte Arbeit zur Barrierefreiheit investiert, gestützt durch die Accessibility-Praxis von IBM. Dies in der eigenen Komponentenbibliothek nachzubilden, ist ein mehrjähriges Vorhaben, das die meisten Teams beginnen und dann wieder aufgeben. Wenn Ihr Produkt ein internes Tool ist, ist die Nutzung von Carbon ein fast kostenloser Erfolg.

Das Gegenargument ist, dass ein Designsystem eine Identität trägt, und die von Carbon ist die von IBM. „Themable“ bedeutet nicht neutral: Die Dichte, die Formensprache, die Typografie und die Interaktionsmuster kodieren alle Entscheidungen, die für IBM-Produkte getroffen wurden. Wenn Ihr Produkt teilweise über das Look-and-Feel konkurriert, werden Sie mehr Energie darauf verwenden müssen, diese zu bekämpfen, als Sie für die Definition Ihres eigenen Systems aufgewendet hätten.

1. Trennen Sie Markensprache von der Implementierung. Die IBM Design Language und Carbon sind unterschiedliche Dokumente mit unterschiedlichen Verantwortlichen und unterschiedlichen Änderungsraten. Sie zusammenzuführen bedeutet, dass jede kleine Anpassung an einer Komponente zu einer Marken-Diskussion wird.
2. Geben Sie domänenspezifischer Arbeit eine Domänenebene. Eine Komponente, die nur ein Produkt benötigt, gehört oberhalb des Kerns, nicht darin und nicht außerhalb des Systems.
3. Veröffentlichen Sie, wer welche Implementierung wartet. Nutzer treffen eine Risikoentscheidung. Lassen Sie sie diese Entscheidung auf Basis von Fakten treffen.
4. Stellen Sie das System gezielt Agenten zur Verfügung. Ob über MCP, einen maschinenlesbaren Token-Export oder eine gut strukturierte Datei im Repository – der Agent wird ohnehin gegen Ihr System schreiben. Die einzige Frage ist, ob er dies anhand Ihrer Dokumentation oder anhand seiner Trainingsdaten tut.