Der Button existiert bereits. Trotzdem erzeugt ein KI-Agent einen neuen mit eigener Farbe, anderen Abständen und einer zusätzlichen Variante. Auf dem Screenshot wirkt der Nachbau ähnlich. Im Projekt ist aber ein zweiter Baustein entstanden, der künftig getrennt gepflegt werden müsste. Das Problem ist nicht bloß Bildverständnis, sondern fehlende Komponentenidentität.
Figma Code Connect verknüpft Designkomponenten mit ihren Code-Gegenstücken und macht diese Beziehungen für Dev Mode beziehungsweise MCP nutzbar. Die laufende Dokumentation beschreibt damit einen konkreten Kontextweg. Sie belegt keine pauschale Qualitäts- oder Kostenverbesserung. Unsere Frage lautet: Welche Information braucht ein Agent, um den vorhandenen Button tatsächlich wiederzuverwenden?
Die Variante ist ein Vertrag
Unser eigener Beispielbaustein heißt QuietButton. Er kennt eine primäre und eine sekundäre Darstellung sowie einen deaktivierten Zustand. Der Auftrag ist nicht „Baue etwas Ähnliches“, sondern „Verwende diesen Baustein in einer erlaubten Konfiguration“. Das klingt selbstverständlich, verlangt aber eine genaue Beziehung zwischen Design und Code.
Design: zurückhaltender Aktionsknopf
Code: QuietButton
Erlaubte Variante: secondary
Beschriftung: Details ansehen
Zustand: enabledDiese Karte ist ein eigenes Mapping-Schema, keine Code-Connect-Konfigurationsdatei. Sie macht sichtbar, wo ein Agent sonst raten müsste. Ein ähnlich klingender Wert wie „quiet“ ist nicht automatisch ein gültiger Parameter, wenn die tatsächliche Komponente „secondary“ erwartet.
Dasselbe gilt für Inhalt und Zustand. Ein dekorativ gedimmter Button kann anders implementiert sein als ein tatsächlich deaktiviertes Bedienelement. Der sichtbare Eindruck allein reicht deshalb nicht für die technische Zuordnung.
Ein kleines echtes Beispiel ist besser als eine lange Stilbeschreibung
Gib dem Agenten neben der Zuordnung eine vorhandene Verwendung. Bei einem einfachen HTML-Baustein könnte sie so aussehen:
<button class="action action--secondary" type="button">
Details ansehen
</button>Die Klassen gehören zu unserem Beispiel. Welche CSS-Regeln sie tragen, muss das eigene Projekt bestimmen. Der Mehrwert liegt darin, dass der Agent nicht erst eine neue Struktur erfinden soll. Er bekommt einen konkreten Ausgangspunkt mit begrenzten Änderungen.
Eine brauchbare Ergänzung benennt, was erhalten bleiben soll: dieselbe Komponente, gültige Varianten, vorhandene Tastaturbedienung und der tatsächliche Aktionszweck. Eine umfangreiche Materialsammlung mit widersprüchlichen Beispielen könnte dabei schlechter helfen als ein kurzer aktueller Ausschnitt.
Veraltete Mappings können sehr überzeugend aussehen
Angenommen, das Projekt benennt eine Eigenschaft um. Das alte Mapping bleibt verständlich und sauber formatiert. Für den Agenten ist es plausibler Kontext, technisch aber falsch. Die Verbindung zum aktuellen Code muss deshalb mitgepflegt werden.
Für eine praktische Bestandsaufnahme wähle drei häufig verwendete Komponenten. Notiere je eine echte Verwendung und ihre erlaubten Varianten. Vergleiche diese Angaben mit dem aktuellen Code, bevor du eine neue Zuordnung veröffentlichst. Diese vorgeschlagene Übung behauptet keine bereits durchgeführte Repositoryprüfung oder einen bestandenen KI-Lauf.
Ein Gegenfall schärft die Zuordnung: Was soll geschehen, wenn der Entwurf eine Variante verlangt, die der Baustein gar nicht besitzt? Statt still einen neuen Button zu erfinden, sollte die Umsetzung diese Lücke benennen. Dann wird aus fehlendem Kontext eine bewusste Designentscheidung, die am tatsächlichen Projekt getroffen werden kann.
Markenwerte ergänzen den Baustein, ersetzen ihn aber nicht
Wenn du einen eigenen Seitenbaustein in KENJTEC weiterverwendest, kann das Markenblatt aus dem KENJTEC BrandStudio ai konkrete Farben, Schriften und Formen liefern. Übertrage diese Werte bewusst auf das vorhandene HTML-/CSS-Beispiel, statt die Komponente nur nach einem Bild neu erfinden zu lassen.
Eigenes HTML, CSS und JavaScript lässt sich anschließend manuell im Entwicklermodus des KENJTEC WebSiteBuilder ai vorbereiten, separat in der Vorschau betrachten und als eigenen Code veröffentlichen. Damit ist kein automatischer Code-Connect-Import und kein React-Apphosting gemeint. Das Mapping bleibt in deinem externen Entwicklungsworkflow.
Die technische Lehre ist übertragbar: Ein Designsystem besteht nicht nur aus ähnlichen Formen. Es braucht überprüfbare Beziehungen zwischen sichtbaren Varianten und tatsächlichen Bausteinen. Je konkreter diese Beziehungen sind, desto weniger muss ein Agent erraten und desto leichter lässt sich sein Ergebnis am vorhandenen Projekt beurteilen.
Quellen und Stand
Recherche- und Dokumentationsstand: 25. Oktober 2026. Code Connect: Introduction.
