Dokumentation scheitert nicht, weil Designer faul sind. Sie scheitert, weil sie immer als letztes drankommt – und das ist ein Strukturproblem, kein Disziplinproblem.
Ubers Team hat das jetzt mit einem KI-Agenten angegangen. Das Ergebnis ist kein glänzendes KI-Showcase. Es ist die Lösung für genau das Problem, das in jedem Projekt still und leise Schaden anrichtet.
#Warum Specs immer hinterherhinken
Ein Projekt läuft. Die Komponenten werden gebaut, iteriert, verfeinert. Irgendwo auf der Strecke sollte eigentlich jemand die Specs aktualisieren. Aber der Launch ist näher als die Doku, der nächste Sprint startet, und die Specs warten.
Das ist kein Versagen einzelner Personen. Es ist die natürliche Konsequenz davon, wie Prioritäten in der Realität gesetzt werden. Specs bringen kein Feature raus. Sie sind Infrastruktur – unsichtbar, solange sie funktionieren, schmerzhaft, wenn sie fehlen.
Bei Uber potenziert sich dieses Problem auf eine Ebene, die kaum vorstellbar ist: 7 verschiedene Implementierungs-Stacks, Density-Varianten für jeden davon, strikte Accessibility-Anforderungen. Jede Komponente braucht eine Spec-Seite, die all das abdeckt. Manuell bedeutet das: Ein Designer sitzt Seite für Seite in Figma und dokumentiert, was andere längst schon gebaut haben.
Engineering baut derweil auf Annahmen. Nicht aus Nachlässigkeit, sondern weil die aktuellen Definitionen schlicht nicht verfügbar sind.
#Was Uber gebaut hat – und warum es funktioniert
uSpec verbindet einen KI-Agenten in Cursor mit Figma über das Figma Console MCP. Der Agent crawlt die tatsächliche Komponentenstruktur, zieht alle relevanten Daten und generiert fertige Spec-Seiten direkt im Figma-File. Was früher Wochen dauerte, läuft in Minuten.
Der entscheidende Punkt: Das gesamte System läuft lokal. Keine proprietären Designdaten verlassen das Netzwerk. Für ein Unternehmen wie Uber ist das keine optionale Komfortfunktion – es ist eine harte Anforderung.
Was mich an diesem Ansatz überzeugt, ist nicht die Geschwindigkeit. Geschwindigkeit ist das Nebenprodukt. Der eigentliche Gewinn ist, dass Specs jetzt zum ersten Mal mit dem tatsächlichen Stand der Komponenten mithalten können. Kein Lag mehr zwischen dem, was gebaut wurde, und dem, was dokumentiert ist.
#Das Grundproblem ist nicht skalierbar
Ian Guisard, der das System bei Uber entwickelt hat, beschreibt es direkt: Er hat jahrelang manuell Specs erstellt und anderen beigebracht, wie es geht. Die Methodik war gut. Der Prozess war wiederholbar. Aber er skaliert nicht, wenn die Komplexität wächst.
Das ist der Kern. Manuelle Dokumentation ist kein schlechter Ansatz – sie ist ein Ansatz, der unter Druck zusammenbricht. Und Druck ist in jedem Projekt der Normalzustand.
Ich kenne das aus kleineren Projekten. Die Komplexität ist nicht vergleichbar mit Ubers 7 Stacks und hunderten Komponenten. Aber das Muster ist identisch: Specs werden angelegt, wenn die Energie hoch ist. Sie werden nicht aktualisiert, wenn der Alltag zurückkommt.
#Das Gegenargument, das nicht zieht
"Bei uns ist das anders. Wir haben klare Prozesse."
Vielleicht. Aber ich habe noch kein Projekt gesehen, in dem die Specs am Ende des Projekts genauso aktuell waren wie zu Beginn. Nicht weil die Prozesse schlecht waren, sondern weil Menschen unter Zeitdruck immer die sichtbare Arbeit priorisieren.
Automatisierung löst dieses Problem nicht durch Disziplin. Sie löst es durch Struktur. Der Agent dokumentiert, weil er dafür gebaut wurde – nicht weil er gerade Zeit hat.
#Was du konkret daraus mitnehmen kannst
Du brauchst keine Uber-Infrastruktur, um aus diesem Ansatz zu lernen. Ein paar Prinzipien lassen sich direkt übertragen:
Dokumentation muss in den Build-Prozess integriert sein, nicht danach kommen. Wenn Specs als separater Schritt nach dem Bauen geplant sind, werden sie nicht gemacht. Oder sie hinken hinterher. Der Trigger für Dokumentation muss dieselbe Aktion sein wie der Trigger für die Komponente selbst.
Manuelle Prozesse brauchen Grenzen. Wenn du manuell dokumentierst, definiere von Anfang an, was dokumentiert wird und was nicht. Eine vollständige Spec für zehn Komponenten schlägt eine halbfertige Spec für dreißig.
Lokal und sicher ist kein Nice-to-have. Sobald Designdaten das Netzwerk verlassen, ist Kontrolle weg. Für Freelancer mag das abstrakt klingen – für Agenturen mit NDA-Pflichten ist es relevant.
KI-Tools sind am nützlichsten dort, wo Arbeit repetitiv und fehleranfällig ist. Specs schreiben ist genau das. Es gibt keine kreative Entscheidung beim Ausfüllen einer Density-Tabelle. Genau dort macht Automatisierung Sinn.
#Was sich wirklich verändert
Specs schreiben ist Handwerk. Niemand zeigt es im Portfolio. Es bringt kein Like auf LinkedIn. Aber wenn es fehlt, bauen Engineers auf Annahmen – und Annahmen kosten Zeit, Geld und Konsistenz.
Ein System, das diesen Teil übernimmt, gibt Designern Kapazität für die Arbeit, die tatsächlich Entscheidungen braucht. Nicht weil Specs unwichtig sind, sondern weil sie zu wichtig sind, um immer aufgeschoben zu werden.
Uber hat das Problem nicht gelöst, indem sie Designer disziplinierter gemacht haben. Sie haben es gelöst, indem sie den Prozess so gestaltet haben, dass er ohne menschliche Willenskraft funktioniert.
Das ist der Ansatz, der hält.
