Knappen findes allerede. Alligevel opretter en AI-agent en ny med sin egen farve, en anden afstand og en ekstra variant. På skærmbilledet ligner kopien originalen. I projektet er der dog opstået en anden komponent, som fremover skulle vedligeholdes separat. Problemet er ikke blot billedforståelse, men manglende komponentidentitet.
Figma Code Connect forbinder designkomponenter med deres modstykker i koden og gør disse relationer anvendelige for Dev Mode og MCP. Den aktuelle dokumentation beskriver dermed en bestemt vej for kontekst. Den påviser ikke nogen generel forbedring af kvalitet eller omkostninger. Vores spørgsmål er: Hvilke oplysninger har en agent brug for for faktisk at genbruge den eksisterende knap?
Varianten er en kontrakt
Vores egen eksempelkomponent hedder QuietButton. Den har et primært og et sekundært udseende samt en deaktiveret tilstand. Instruksen er ikke „Byg noget lignende“, men „Brug denne komponent i en tilladt konfiguration“. Det lyder indlysende, men det kræver en præcis relation mellem design og kode.
Design: understated action button
Code: QuietButton
Allowed variant: secondary
Label: View details
State: enabledDette kort er vores eget mapping-skema, ikke en Code Connect-konfigurationsfil. Det synliggør, hvor en agent ellers ville være nødt til at gætte. En værdi, der lyder lignende, som „quiet“, er ikke automatisk en gyldig parameter, hvis den faktiske komponent forventer „secondary“.
Det samme gælder indhold og tilstand. En knap, der er nedtonet som dekoration, kan være implementeret anderledes end et betjeningselement, der faktisk er deaktiveret. Det visuelle indtryk alene er derfor ikke nok til den tekniske mapping.
Ét lille, virkeligt eksempel er bedre end en lang stilbeskrivelse
Ud over mappingen bør du give agenten en eksisterende anvendelse. For en simpel HTML-komponent kunne det se sådan ud:
<button class="action action--secondary" type="button">
View details
</button>Klasserne hører til vores eksempel. Hvilke CSS-regler de bærer, må dit eget projekt afgøre. Merværdien er, at agenten ikke forventes først at opfinde en ny struktur. Den får et konkret udgangspunkt med begrænsede ændringer.
En nyttig tilføjelse nævner, hvad der skal bevares: den samme komponent, gyldige varianter, eksisterende tastaturbetjening og handlingens egentlige formål. En omfattende materialesamling med modstridende eksempler kunne hjælpe mindre end et kort, aktuelt uddrag.
Forældede mappings kan virke meget overbevisende
Antag, at projektet omdøber en egenskab. Den gamle mapping forbliver forståelig og pænt formateret. For agenten er den plausibel kontekst, men teknisk forkert. Forbindelsen til den aktuelle kode skal derfor også vedligeholdes.
Til en praktisk gennemgang af det, du allerede har, kan du vælge tre ofte brugte komponenter. Notér én reel anvendelse af hver og dens tilladte varianter. Sammenlign disse detaljer med den aktuelle kode, før du udgiver en ny mapping. Denne foreslåede øvelse påstår ikke, at en gennemgang af et repository allerede er udført, eller at en AI-kørsel er bestået.
Et modeksempel skærper mappingen: Hvad skal der ske, hvis designet kræver en variant, som komponenten slet ikke har? I stedet for i stilhed at opfinde en ny knap bør implementeringen navngive dette hul. Manglende kontekst bliver så en bevidst designbeslutning, der kan træffes i det faktiske projekt.
Brandværdier supplerer komponenten, men erstatter den ikke
Hvis du genbruger din egen sidekomponent i KENJTEC, kan brandarket fra KENJTEC BrandStudio ai levere konkrete farver, skrifttyper og former. Anvend disse værdier bevidst på det eksisterende HTML/CSS-eksempel i stedet for at lade komponenten genopfinde ud fra et billede alene.
Din egen HTML, CSS og JavaScript kan derefter forberedes manuelt i udviklertilstanden i KENJTEC WebSiteBuilder ai, ses separat i forhåndsvisningen og udgives som brugerdefineret kode. Det betyder ikke en automatisk Code Connect-import eller hosting af React-apps. Mappingen forbliver i dit eksterne udviklingsworkflow.
Den tekniske lære kan overføres: Et designsystem består ikke kun af lignende former. Det kræver verificerbare relationer mellem synlige varianter og faktiske komponenter. Jo mere konkrete disse relationer er, desto mindre skal en agent gætte, og desto lettere er det at vurdere dens resultat i forhold til det eksisterende projekt.
Kilder og status
Research og dokumentation pr. 25. oktober 2026. Code Connect: Introduktion.
