Carbon: das Open-Source-Designsystem, das einen MCP-Server veröffentlicht hat

IBM beschreibt Carbon als sein Open-Source-Designsystem für Produkte und digitale Erlebnisse, basierend auf der IBM Design Language. Es besteht aus produktivem Code, Design-Tools und Ressourcen, Human Interface Guidelines sowie einer Community von Mitwirkenden. Es wird von IBM für die geschäftlichen Anforderungen von IBM finanziert und entwickelt und offen für die Nutzung und Mitarbeit freigegeben.

Dieses Finanzierungsmodell ist einen Moment des Innehaltens wert, da es bestimmt, was man hier übernimmt. Carbon ist kein Community-Projekt, das zufällig Unternehmensnutzer hat; es ist ein Unternehmenssystem, das zufällig offen ist. Roadmap-Entscheidungen dienen IBM-Produkten. In der Praxis ist das meist positiv – es bedeutet, dass das System wirklich gewartet wird, anstatt aufgegeben zu werden, wenn ein Maintainer den Job wechselt –, aber es bedeutet auch, dass ein Feature, das Ihr Produkt benötigt, IBM jedoch nicht, wahrscheinlich nicht implementiert 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 dargestellt.

Dies ist dieselbe Struktur, die Spotify mit Encore erreicht hat, jedoch aus einer anderen Richtung. Sie löst dasselbe Problem: Wo landet eine Komponente, wenn nur ein einziges Produkt sie benötigt? Ohne eine Domain-Schicht ist die Antwort entweder „im Core, was ihn für alle schwerfälliger macht“ oder „außerhalb des Systems, wo Drift entsteht“. Mit einer Domain-Schicht hat spezialisierte Arbeit ein Zuhause, ohne in andere Bereiche überzulaufen.

Wenn Sie ein System für mehr als ein Produkt aufbauen, ist dies der am besten übertragbare Aspekt von Carbon. Sie benötigen keine drei veröffentlichten Websites. Sie benötigen eine Regel darüber, welcher Ihrer drei Ebenen eine bestimmte Entscheidung zugeordnet wird, und die Disziplin, einen produktspezifischen Bedarf nicht in das Fundament zu heben, nur weil es einfacher war.

Carbon unterstützt mehrere Code-Implementierungen, und die Dokumentation listet jede einzelne mit ihrem Maintainer auf. Diese Liste ist der praktisch wichtigste Teil 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 dafür 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 KI-Agenten und KI-Anwendungen direkten Zugriff auf die Carbon-Wissensdatenbank gewährt – Kern-Elemente, Ikonografie, Piktogramme, Richtlinien, Nutzungsdokumentationen 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 KI-Zugriff auf Carbon-Standards, eine präzisere Code-Generierung basierend auf echten 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 Konsument eines Designsystems ist nicht mehr nur ein menschlicher Entwickler, der eine 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 Fachliteratur zu Designsystemen noch nicht ausreichend reflektiert.

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 gestalterische Linie 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, und es ist dennoch häufig die falsche Entscheidung, es zu übernehmen. Der entscheidende Faktor ist, ob Sie eine vorgegebene Design-Meinung übernehmen möchten.

Das Argument der Barrierefreiheit verdient eine eigene Betrachtung. In die Komponenten von Carbon wurde über Jahre hinweg echte Accessibility-Arbeit investiert, gestützt durch die Accessibility-Praxis von IBM. Dies in einer eigenen Komponentenbibliothek zu reproduzieren, ist eine mehrjährige Verpflichtung, die die meisten Teams beginnen und dann wieder aufgeben. Wenn Ihr Produkt ein internes Tool ist, ist die Übernahme von Carbon fast schon ein kostenloser Gewinn.

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

1. Markensprache von der Implementierung trennen. Die IBM Design Language und Carbon sind unterschiedliche Dokumente mit verschiedenen Verantwortlichen und unterschiedlichen Änderungsraten. Eine Zusammenführung würde bedeuten, dass jede kleine Anpassung an einer Komponente zu einer Diskussion über die Marke wird.
2. Domänenspezifische Arbeit in einer Domänen-Layer organisieren. Eine Komponente, die nur ein einziges Produkt benötigt, gehört über den Core, nicht hinein und nicht außerhalb des Systems.
3. Offenlegen, wer jede Implementierung wartet. Anwender treffen eine Risikoentscheidung. Lassen Sie sie diese auf Basis von Fakten treffen.
4. Das System bewusst für Agenten öffnen. 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 auf Basis Ihrer Dokumentation oder seiner Trainingsdaten tut.