Ein Breaking Change im Design System, mehr als 50 Komponenten und zahlreiche Consumer-Teams: Statt einen Migrations-Guide zu verschicken und auf die Umsetzung zu warten, haben wir das Migrationswissen in einen Prompt gepackt und alle Teams gemeinsam mit AI Coding Agents migrieren lassen. Der aufwendigste Teil war nach einer Stunde erledigt – inklusive der Fälle, bei denen einfaches Suchen-und-Ersetzen nicht ausgereicht hätte.

In einem Kundenprojekt verantworten wir die technische Entwicklung der Design-System-Komponenten – die Bausteine, mit denen die Teams ihre Nutzeroberflächen zusammenbauen: Buttons, Formularfelder und vieles mehr. Wir liefern diese Bausteine als Software-Paket an zahlreiche Teams, die im Scaled Agile Framework (SAFe) gemeinsam am digitalen Auftritt des Kunden arbeiten. Das Design System umfasst über 50 Komponenten.

Kurz zum Vokabular, weil es gleich wichtig wird: Design-Tokens sind so etwas wie der „Vertrag“ für das Aussehen einer App, also Farben, Abstände, Schriftgrößen und so weiter. Wir sind die Quelle dieser Tokens, die Teams sind die Consumer. Die Entscheidung für die Umstellung, um die es hier geht, hat der Kunde selbst getroffen. Wir haben sie technisch umgesetzt und begleitet.

Im Zuge eines größeren Umbaus ging es von Token Studio auf native Figma Variables, mit einer neuen, automatisierten Pipeline: von der Figma Variables API über das W3C Design Token Format bis zu SCSS via Style Dictionary.

Bei der Gelegenheit haben wir die über Jahre gewachsene Token-Struktur aufgeräumt, und das ging über reines Umbenennen hinaus. Gemischte Konventionen und zu generische Bezeichnungen wurden vereinheitlicht. Betroffen war dabei nicht nur eine einzelne Token-Kategorie, sondern praktisch der gesamte Katalog: Farben, Typografie, Abstände, Größen, Rahmen und Schatten wurden alle nach demselben Schema neu strukturiert. Tokens, die mehrere Zwecke gleichzeitig erfüllten, haben wir aufgesplittet: Wo es früher etwa eine gemeinsame Farbe für Text und Icons gab, gibt es heute zwei getrennte Tokens für Textfarbe und Icon-Farbe. Und überflüssige oder doppelte Tokens sind ganz verschwunden.

Das Ergebnis ist damit deutlich wartbarer, bedeutet aber für jedes Consumer-Team einen Breaking Change, den es umzusetzen gilt. Genau hier wird es interessant. Während Umbenennungen durch Eins-zu-eins-Zuordnungen reine Fleißarbeit sind, wird es bei Aufsplittungen komplizierter: Wenn aus einem Token zwei werden, lässt sich nicht pauschal ersetzen, sondern es muss an jeder einzelnen Stelle entschieden werden, ob hier die Text- oder die Icon-Farbe gemeint ist. Gelöschte Tokens sind noch einmal ein eigener Fall: Für sie gab es von vornherein keinen vorgegebenen Ersatz, hier musste jedes Team im Einzelfall entscheiden, wie es weitergeht.

Damit der Unterschied klar wird, lohnt der Blick auf den klassischen Weg. Üblicherweise schickt man bei so einer Umstellung einen Migrations-Guide mit einer großen Mapping-Tabelle an alle Teams, „alter Token → neuer Token“, Zeile für Zeile. Dann beginnt das Warten.

Das Tagesgeschäft der Teams besteht darin, Features zu liefern und Roadmaps einzuhalten. Ein Breaking Change am Design System, der erst mal kein neues Feature bringt, bedeutet hier reine Zusatzarbeit. Völlig nachvollziehbar, dass solche Aufgaben weit unten im Backlog landen.

Realistisch zieht sich so eine Migration damit über mehrere Wochen, verteilt über die Teams, begleitet von Tickets, Remindern und Nachfass-Runden. Hinzu kommt: Bei den kniffligen Aufsplittungen würde jedes Team dieselben Kontextfragen für sich neu beantworten. Dieselbe Denkarbeit, x-fach parallel. Genau dieser Prozess ist es, der besser geht.

Naheliegender erster Reflex: ein Skript. Für die reinen Umbenennungen, und das betraf den Großteil der Tokens über Typografie, Abstände, Größen, Rahmen und Schatten hinweg, hätte ein einfaches Find-and-Replace tatsächlich genügt. Spannend wurde es erst bei den mehrdeutigen Fällen der Farb-Tokens, in denen ein Skript nur raten könnte. Hier braucht es ein Verständnis des umgebenden Codes: Steht dieser Token in einer Text- oder in einer Icon-Komponente? Und bei gelöschten Tokens, für die es keinen vorgegebenen Ersatz gibt: Welche Lösung ergibt an dieser Stelle im Code überhaupt Sinn?

Ehrlicherweise: Mit genug Regelaufwand bekäme man auch die Farbfälle in ein Codemod gegossen, aber der Aufwand stünde in keinem Verhältnis, weil praktisch jeder mehrdeutige Fall seine eigene Kontextregel bräuchte. Und das ist der Punkt, an dem KI wirklich glänzte. Hätte die Migration nur aus stumpfem Ersetzen bestanden, wäre KI überflüssig gewesen. Erst die Fälle mit echtem Entscheidungsbedarf machen ihren Einsatz sinnvoll: Der Agent hat anhand von CSS-Eigenschaften und Selektoren die meisten mehrdeutigen Stellen korrekt aufgelöst und dort, wo es wirklich unklar war oder wo gar kein Ersatz vorgesehen war, den Code zum Review markiert, statt blind einer starren Regel zu folgen.

Statt einen Guide zu verschicken und auf eine wochenlange Umsetzung zu warten, haben wir alle Teams zu einem einstündigen Remote-Workshop eingeladen, in dem sie, unterstützt durch AI Coding Agents, gleichzeitig migrieren sollten.

Im Vorfeld haben wir einen maßgeschneiderten Prompt vorbereitet, der das gesamte Migrations-Wissen enthielt: die Mapping-Tabelle für die Umbenennungen über alle Token-Kategorien hinweg, die Regel fürs Aufsplitten von Farb-Tokens in Text- und Icon-Varianten sowie die Liste der gelöschten Tokens.

So konnte der Agent in jeder Codebase die einfachen Umbenennungen automatisch erledigen, bei den Farb-Tokens anhand des umgebenden Codes meist selbstständig die richtige Wahl treffen und überall dort, wo es keinen vorgegebenen Ersatz gab oder die Zuordnung unklar blieb, den Code mit einem Kommentar zum manuellen Review markieren. Die Teams mussten die Tabelle nicht mehr manuell abarbeiten, sondern reviewten die Änderungen und kümmerten sich um genau diese markierten Stellen.

Damit das im Workshop so glatt lief, steckte einiges an Vorarbeit drin. Ausgangspunkt war eine Excel-Tabelle mit allen alten und neuen Token-Namen. Aus dieser Tabelle haben wir mit Hilfe der KI einen Migrations-Prompt erstellt, der die Migration zuverlässig durchführt. Das war kein Einzeiler:

Es hat mehrere Tage gedauert, in denen wir viel ausprobiert, verworfen und nachgeschärft haben, bis die mehrdeutigen Fälle verlässlich saßen. Wir sind zunächst im Plan-Modus gestartet und haben anschließend im Agent-Modus lokal „gevibed“, immer wieder an einer Codebase getestet und nachgeschärft.

Neben dem Zeitaufwand wurden natürlich auch jede Menge Tokens „verbrannt“. Diese Investition, also Vorbereitungszeit plus Tokens, stand aber in einem sehr guten Verhältnis zum Gegenwert: Der Aufwand fiel einmalig auf unserer Seite an, während er sich über alle Teams hinweg mehrfach einsparen ließ. Denn sobald der Prompt stand, waren die Teams selbst sehr schnell: Die eigentliche Migration im Code war eine Sache von Minuten statt Wochen.

Der folgende Abschnitt ist etwas technischer und richtet sich vor allem an Entwickler:innen, die selbst mit AI Coding Agents arbeiten.

Damit ihr eine Idee bekommt, wie so ein Prompt aufgebaut sein kann, hier eine anonymisierte, stark vereinfachte und gekürzte Version unseres Produktions-Prompts, aber mit denselben Grundprinzipien: klare Regeln, eine Mapping-Tabelle und ein expliziter Umgang mit Unsicherheit statt Raten.

Die Grundidee lässt sich auf jede Token-Migration übertragen: Regeln für die eindeutigen Fälle, eine klare Heuristik für die mehrdeutigen Fälle inklusive Standardverhalten und eine explizite Markierung für alles, wo es wirklich keine automatische Lösung gibt.

Der Workshop war auf 60 Minuten getaktet:

• Intro (20 Min): Was hat sich geändert, und warum?
• Setup (20 Min): Alle richten ihren AI-Agent ein und laden den vorbereiteten Prompt.
• Migration (15 Min): Jedes Team lässt den Agent über seine Codebase laufen, reviewt die Änderungen, fixt Edge Cases.
• Q&A (5 Min): Erfahrungen teilen, offene Fragen klären.

Wichtig für die Einordnung: Innerhalb dieser Stunde stand die inhaltliche Migration, also der Code, mit den passenden neuen Tokens an jeder Stelle. Der übliche Weg danach, also Pull Request, Code-Review, Design-Review und Merge im jeweiligen Team, lief wie gewohnt im Anschluss weiter. Der Workshop hat natürlich nicht den gesamten Software Development Life Cycle (SDLC) ersetzt, sondern das eigentliche Übertragen der Änderungen in den Code übernommen.

Interessant war die Stimmung im Call. Zu Beginn lag eine gewisse Skepsis in der Luft, dieser leise Respekt vor den „vielen Änderungen“, die angeblich auf alle zukamen. Als die Agents dann liefen und die ersten Diffs auf den Bildschirmen erschienen, kippte das schnell. Es wurde lockerer, hier und da fiel ein „Ach, das war es schon?“. Und genau das war der eigentliche Gewinn: Selbst wer nicht aktiv mitcodete, ging mit dem Eindruck raus, dass dieses Upgrade eigentlich ganz simpel ist. Die mentale Hürde, die vorher so groß wirkte, war nach einer Stunde verschwunden.

Der entscheidende Faktor war der minimale Aufwand für die Teams. Aus einer unklar großen Aufgabe wurde ein fester Ein-Stunden-Slot für den aufwendigsten Teil, die eigentliche Code-Migration. Der Agent übernahm dabei auch die kniffligen Teile, etwa das Aufsplitten eines Farb-Tokens in Text- und Icon-Variante, die sich mit einem einfachen Suchen-und-Ersetzen nicht zuverlässig hätten auflösen lassen. Er markierte die wirklich offenen Fälle, also insbesondere die gelöschten Tokens ohne Ersatz, klar für die Teams. Weil alle gleichzeitig online waren, konnten wir bei Fragen sofort helfen, und der fixe Termin sorgte dafür, dass das Update nicht im Backlog versank. Alle Teams hatten die Migration im Code innerhalb der Stunde durchgeführt, der reguläre Review- und Merge-Prozess lief danach wie gewohnt weiter.

Wer das selbst ausprobieren will: Das Rezept ist übertragbar. Packt das gesamte Migrations-Wissen in einen vorbereiteten Prompt, setzt einen gemeinsamen Slot an, in dem alle gleichzeitig migrieren, und seid live ansprechbar. Den teuren Teil, also das Tüfteln am Prompt, macht ihr einmal; alle anderen profitieren davon.

Was nehmen wir aus der Stunde mit? KI bringt vor allem dort etwas, wo einfache Automatisierung nicht mehr reicht. Ein simples Mapping hätten wir auch mit einem Skript lösen können. Spannend wurde es bei den Stellen, an denen Kontext nötig war – und genau dort konnte der Coding Agent einen großen Teil der Arbeit übernehmen, ohne offene Fälle einfach wegzuautomatisieren.

Für uns steckt darin auch ein Muster, das sich auf andere Projekte übertragen lässt: Kontext einmal sauber bündeln, KI gezielt damit ausstatten und die eigentliche Umsetzung so einfach wie möglich für alle Beteiligten machen. Das braucht Vorbereitung, eine Menge Tokens und funktioniert nicht mit einem spontanen Einzeiler. Wenn der Use Case passt, kann sich diese Investition aber sehr schnell auszahlen.

Und vielleicht war deshalb das schönste Feedback im Workshop tatsächlich das vermeintlich unspektakuläre: „Ach, das war es schon?“ Genau so sollte sich gute Automatisierung am Ende anfühlen.