Wenn die Spezifikationen von Komponenten hinter der Implementierung zurückbleiben, beginnt das Team, das System auf Annahmen aufzubauen. Bei Uber entwickelte sich dies zu einem systemischen Problem im großen Maßstab – und wurde durch agentenbasierte Automatisierung gelöst.
Das Problem tritt nicht beim Schreiben der Spezifikationen auf, sondern später – wenn sich das System schneller weiterentwickelt als die Dokumentation. Das Uber Base Design-System bedient Hunderte von Komponenten, von denen jede in sieben Stacks implementiert wird: von UIKit und SwiftUI bis hin zu React und SDUI. Jede Komponente weist unterschiedliche Dichten, plattformspezifische Besonderheiten und strenge Anforderungen an die Barrierefreiheit auf. Die Spezifikation wird zur einzigen Quelle der Wahrheit, aber der manuelle Prozess ihrer Erstellung ist nicht skalierbar: Er ist langsam, abhängig vom Autor und beginnt sofort nach der ersten Änderung einer Komponente zu veralten. Infolgedessen verlassen sich Ingenieure auf Interpretationen statt auf einen Vertrag – daraus resultieren Abweichungen und die Ansammlung von technischem Schulden.
Die Lösung, zu der das Team kam, war nicht die Optimierung des Prozesses, sondern seine Eliminierung als Aufgabenklasse. Uber führte uSpec ein – ein agentenbasiertes System, das Spezifikationen direkt aus Figma generiert. Die entscheidende Wahl hierbei ist, den KI-Agenten mit der tatsächlichen Datenquelle (Design-Datei) zu verbinden, nicht mit deren Projektion in Form von Screenshots oder Exporten. Dies reduziert die Wahrscheinlichkeit von Interpretationsfehlern. Der zweite grundlegende Trade-off ist die lokale Ausführung der Pipeline über die Figma Console MCP: Kein Design-Artefakt verlässt die Infrastruktur des Unternehmens. Das schränkt die Flexibilität der Integrationen ein, ist aber für Sicherheit und Einhaltung interner Anforderungen entscheidend.
Die Architektur der Lösung besteht aus zwei Schichten. Die erste ist der KI-Agent (in Cursor), der für die Interpretation zuständig ist: Er versteht die Struktur der Komponente, klassifiziert Zustände, wählt Accessibility-Semantik aus und ordnet Tokens zu. Die zweite ist die MCP (Model Context Protocol) Brücke zu Figma Desktop, die dem Agenten Lese- und Schreibzugriff auf die Daten gibt: Komponentenbaum, Variablen, Stile und Beziehungen zwischen Ebenen. Der Agent durchläuft die Hierarchie, extrahiert die tatsächlichen Token-Werte, bestimmt die Komposition über Slots und Varianten und füllt anschließend die Spezifikationsvorlage direkt in Figma aus. Jeder Abschnitt der Spezifikation ist in einen eigenen „Skill“ mit strikten Schemata und Validierung gekapselt. Zum Beispiel lädt der Agent für den Screenreader-Teil die Nachschlagewerke von VoiceOver, TalkBack und ARIA und wählt Werte aus dem API, anstatt sie heuristisch zu generieren – das ist entscheidend, da ein Fehler in einer Eigenschaft die Barrierefreiheit zerstört.
Die zentrale technische Entscheidung ist die Trennung der Verantwortlichkeiten: KI wird dort eingesetzt, wo Interpretation erforderlich ist, während deterministische Operationen (Rendering, Einfügen, Klonen von Strukturen) über MCP ausgeführt werden. Figma-Plugins können Daten extrahieren, aber nicht erklären, was sie bedeuten. Reine KI hingegen neigt ohne strikte Anbindung an die Quelle zu Halluzinationen. uSpec kombiniert beide Ansätze, was das System skalierbar und robust macht.
Das Ergebnis ist eine Verkürzung des Spezifikationszyklus von Wochen auf Minuten und die Möglichkeit, die Dokumentation bei jeder Änderung einer Komponente neu zu generieren. Das ist nicht nur eine Beschleunigung, sondern die Beseitigung des Drifts: Die Spezifikation wird jetzt aus dem aktuellen Systemzustand generiert. Uber nennt keine formalen Qualitätsmetriken, aber ein indirekter Effekt ist die Verringerung der Abweichungen zwischen Design und Implementierung sowie die Entlastung der Designer von Routine-Dokumentationsaufgaben. Besonders hervorzuheben ist die Rolle der Open-Source-Schicht: Die Figma Console MCP wurde zu einem infrastrukturellen Element, ohne das dieser Ansatz nicht möglich gewesen wäre. Es ist ein seltener Fall, in dem die Standardisierung des Zugriffs auf ein Tool die Prozessarchitektur direkt beeinflusst.