Van Figma naar productiecode: hoe AI ontwerpkloof overbrugt

Waarom de kloof tussen ontwerp en code nog steeds voorkomt

“Figma naar productie” wordt vaak gezien als “exporteer wat CSS en ship.” In werkelijkheid omvat productieklare UI responsief gedrag, interactieve staten, echte data, toegankelijkheid, prestatiebeperkingen en integratie met een designsystem. Een ontwerp kan er perfect uitzien in een statisch frame en toch tientallen implementatiebeslissingen openlaten.

Wat “Figma naar productie” echt omvat

Een front-end build moet ontwerpinformatie vertalen naar herbruikbare componenten, tokens (kleuren, typografie, spacing), lay-outregels over breakpoints en randgevallen zoals lange tekst, lege staten, loading en fouten. Het heeft ook consistente interactiedetails nodig (hover, focus, pressed), toetsenbordondersteuning en voorspelbaar gedrag in verschillende browsers.

Waar het meestal misgaat

De kloof gaat niet alleen over tooling—het gaat om ontbrekende of vage informatie:

• Eenmalige styling vs. herbruikbare componenten: ontwerpers maken soms unieke varianten in Figma, terwijl ontwikkelaars een klein aantal schaalbare componenten nodig hebben.
• Auto Layout vs. echte lay-outbeperkingen: wat “lijkt uitgelijnd” kan falen wanneer content groeit of containers van grootte veranderen.
• Staten en flows niet volledig gespecificeerd: hover, focus, disabled, validatie en lege staten vallen makkelijk weg.
• Token-drift: een “goed genoeg” kleur- of spacingkeuze zorgt voor subtiele inconsistentie die zich verspreidt.

Waarom het tijd kost

Elke onopgeloste ontwerpbepaling wordt een gesprek, een PR-commentaarthread of—nog erger—herwerk na QA. Dat herwerk introduceert vaak bugs (lay-out regressies, ontbrekende focusranden) en laat de UI inconsistent aanvoelen over schermen.

Waar AI het meest helpt

AI vermindert de repetitieve onderdelen van het overbruggen van de kloof: frames aan bestaande UI-componenten koppelen, token-inconsistenties signaleren, spacing en typografie controleren tegen regels en duidelijkere handoff-documentatie genereren (props, staten, acceptatiecriteria). Het vervangt geen oordeel, maar kan mismatches vroeg opvangen en de implementatie dichter bij de ontwerpinzet houden.

In de praktijk zie je de grootste winst wanneer AI is verbonden met je echte productiebeperkingen—je component-API's, tokens en conventies—zodat het output genereert die compatibel is met hoe je team daadwerkelijk UI uitrolt.

Wat “productiecode” betekent (en wat niet)

“Productiecode” gaat minder over het perfect matchen van pixels en meer over het uitrollen van UI die je team veilig kan onderhouden. Wanneer AI helpt Figma naar code te converteren, voorkomt helderheid over het doel veel frustratie.

Het doel: herbruikbare componenten, geen eenmalige schermen

Een schermexport op zich kan er goed uitzien en toch een doodlopende weg zijn. Productiewerk streeft naar herbruikbare UI-componenten (buttons, inputs, cards, modals) die samengesteld kunnen worden tot veel schermen.

Als een gegenereerde lay-out niet te beschrijven is met bestaande componenten (of een klein aantal nieuwe), is het niet productieklare code—het is een prototype-snapshot.

Bepaal wat “productie-klaar” voor je team betekent

Definieer je norm in termen die iedereen kan verifiëren:

• Maakt gebruik van het designsystem: componenten, tokens, spacing-schaal, typografiestijlen.
• Voldoet aan basis toegankelijkheid: semantische elementen, focusstaten, contrast, labels.
• Past bij je codebase: naamgevingsconventies, mappenstructuur, linting, tests (waar van toepassing).
• Handelt echte staten af: loading, empty, error, lange tekst, verschillende apparaatgroottes.

AI kan implementatie versnellen, maar kan je teamconventies niet raden tenzij je ze opgeeft (of voorbeelden toevoegt).

Wat productiecode niet betekent

Het betekent niet:

• Pixel-perfect tegen elke prijs (overal hardcoded waarden, gedupliceerde CSS).
• Alle randgevallen worden automatisch opgelost.
• Geen menselijke review.

Een kleine, bewuste afwijking die consistentie en onderhoudbaarheid behoudt is vaak beter dan een perfecte replica die de langetermijnkosten verhoogt.

Inputs die AI nodig heeft: schone lagen, naamgeving, stijlen, tokens

AI werkt het beste wanneer Figma is gestructureerd als een systeem:

• Consistent componentgebruik (vermijd detached instances).
• Duidelijke laagnamen (bijv. Button/Primary, Icon/Close).
• Tekststijlen en kleurstijlen toegepast (geen eenmalige hexwaarden).
• Auto Layout en constraints doelbewust gebruikt.

Snelle pre-handoff checklist voor ontwerpers

Voordat je overdraagt voor AI-ondersteunde frontend-implementatie:

• Vervang “fake” UI door echte componenten uit de bibliotheek.
• Normaliseer spacing naar je schaal (geen willekeurige 13px gaps).
• Bevestig dat varianten en staten bestaan (hover, disabled, error).
• Zorg dat tokens/stijlen overal zijn toegepast.
• Voeg notities toe alleen waar intentie niet zichtbaar is (bijv. animatietiming).

Hoe AI Figma-ontwerpen interpreteert

AI “ziet” een Figma-bestand niet zoals een mens. Het leest structuur: frames, groups, layers, constraints, tekststijlen en de relaties daartussen. Het doel is die signalen te vertalen naar iets waar een ontwikkelaar betrouwbaar mee kan bouwen—vaak als herbruikbare componenten plus duidelijke lay-outregels.

Componenten en patronen detecteren

Een goede AI-pipeline begint met het vinden van herhaling en intentie. Als meerdere frames dezelfde hiërarchie delen (icoon + label, dezelfde padding, dezelfde corner radius), kan AI ze markeren als hetzelfde patroon—ook als namen inconsistent zijn.

Het zoekt ook naar veelvoorkomende UI-signaturen:

• Buttons: een tekstlaag gecentreerd in een gevuld rechthoek met consistente padding
• Inputs: een container met border/fill plus placeholdertekst en optioneel icoon
• Cards: een achtergrondcontainer met elevation/radius en gestapelde inhoud

Hoe beter de uitlijning met je designsystem, hoe zekerder AI deze elementen kan classificeren.

Lagen naar je componentbibliotheek mappen

Het herkennen van een “button” is nuttig; het mappen naar jouw Button-component is waar de echte tijdwinst zit. AI matcht meestal door eigenschappen te vergelijken (grootte, typografie, kleur token gebruik, state varianten) en suggereert dan een componentnaam en props.

Bijvoorbeeld kan een primaire knop worden:

• Component: Button
• Props: variant="primary", size="md", iconLeft, disabled

Wanneer AI kan mappen naar bestaande componenten, voorkom je eenmalige UI-code en blijft het product consistent.

Lay-outregels en responsiviteit afleiden

Figma bevat al lay-outintentie via Auto Layout, constraints en spacing. AI gebruikt dat om af te leiden:

• Stackrichting (row/column), gap en uitlijning
• Container padding en min/max afmetingen
• “Hug” versus “fill” gedrag voor responsieve schaling

Als constraints ontbreken, kan AI raden op basis van visuele nabijheid—handig, maar minder voorspelbaar.

Specificaties en implementatienotities genereren

Naast codevoorstellen kan AI ontwikkelaarsvriendelijke output produceren: afmetingen, typografiedetails, kleurreferenties, componentgebruiknotities en randgevallen (lege staten, lange tekst wrapping). Beschouw het als het omzetten van een frame naar een checklist waar een ontwikkelaar daadwerkelijk tegen kan bouwen—zonder dat je voor elk scherm handmatig specs hoeft te schrijven.

Figma-bestanden klaarmaken voor AI-ondersteunde implementatie

AI kan UI-code sneller genereren wanneer je Figma-bestand voorspelbaar is. Het doel is niet “ontwerpen voor de machine” ten koste van creativiteit—maar ambiguïteit wegnemen zodat automatisering veilige aannames kan doen.

Waarom naamgeving en structuur belangrijk zijn

De meeste AI-tools leiden intentie af uit laagnamen, hiërarchie en herhaalde patronen. Als een knop Rectangle 12 heet binnen Frame 8, moet het tool raden of het een knop, kaart of decoratieve vorm is. Duidelijke structuur verandert raden in matchen.

Een goede regel: als een ontwikkelaar zou vragen “wat is dit?” zal AI dat ook doen.

Praktische conventies die helpen

Gebruik een consistente indeling:

• Pages per feature of platform (bijv. Web, iOS, Marketing)
• Sections voor flows (bijv. Checkout, Onboarding)
• Frames benoemd naar schermdoel (bijv. Checkout — Payment)

Voor herbruikbare UI, vertrouw op componenten + varianten:

• Benoem componenten naar rol: Button, Input, Card
• Benoem varianten naar eigenschappen: size=md, state=hover, tone=primary
• Vermijd styling in de naam zoals Blue Button 2

Verminder “mystery layers” en one-off overrides

Flattening en masking zijn prima—maar “mystery layers” niet. Verwijder verborgen restanten, ongebruikte groepen en gedupliceerde shapes. Geef de voorkeur aan Auto Layout boven handmatige spacing en vermijd per-instance overrides die padding, corner radius of fontstijlen stil wijzigen.

Als iets uniek moet zijn, label het duidelijk (bijv. Promo banner (one-off)), zodat het niet voor een systeemcomponent wordt aangezien.

Iconen, afbeeldingen en complexe illustraties

Voor iconen, gebruik één bronformaat (bij voorkeur SVG) en consistente naamgeving (icon/chevron-right). Zet tekst in iconen niet om naar outlines.

Voor afbeeldingen, geef intentie aan: Hero image (cropped), Avatar (circle mask). Geef aspects en safe-crop richtlijnen wanneer nodig.

Voor complexe illustraties behandel ze als assets: exporteer eenmaal, bewaar versies en verwijs er consistent naar zodat AI niet probeert ingewikkerde vectorart als UI-shapes te herbouwen.

Design tokens: de gedeelde taal tussen teams

Design tokens zijn de benoemde, herbruikbare beslissingen achter een UI—zodat ontwerpers en ontwikkelaars over hetzelfde praten zonder te discussiëren over pixels.

Wat design tokens zijn (in eenvoudige termen)

Een token is een label plus een waarde. In plaats van “gebruik #0B5FFF” gebruik je color.primary. In plaats van “14px met 20px line-height” gebruik je font.body.sm. Veelvoorkomende tokenfamilies zijn:

• Kleur: merk, semantische staten (success/warning), tekst, oppervlakken
• Typografie: lettertypes, groottes, gewichten, line-heights
• Spacing: een schaal (bijv. 4, 8, 12, 16…) voor padding en gaps
• Radii: hoekafronding voor buttons, cards, inputs

De winst is niet alleen consistentie—het is snelheid. Als een token verandert, werkt het systeem overal bij.

Hoe AI helpt tokens te extraheren en normaliseren

Figma-bestanden bevatten vaak een mix van bedoelde stijlen en eenmalige waarden die tijdens iteratie zijn ontstaan. AI-tools kunnen frames en componenten scannen en token-candidates voorstellen door vergelijkbare waarden te clusteren. Bijvoorbeeld, het kan detecteren dat #0B5FFF, #0C5EFF en #0B60FF waarschijnlijk dezelfde “primary blue” zijn en één canonieke waarde aanbevelen.

Het kan ook betekenis afleiden uit gebruik: de kleur die voor links op meerdere schermen wordt gebruikt is waarschijnlijk “link”, terwijl de kleur die alleen in error-banners voorkomt waarschijnlijk “danger” is. Jij keurt de naamgeving goed, maar AI vermindert het saaie controlewerk.

Duplicaten en bijna-gelijke waarden vermijden

Kleine inconsistenties zijn de snelste manier om een designsystem te breken. Een praktische regel: als twee waarden visueel niet te onderscheiden zijn bij normale zoom, zouden ze waarschijnlijk niet beide moeten bestaan. AI kan bijna-duplicates signaleren en tonen waar ze verschijnen, zodat teams kunnen consolideren zonder giswerk.

Tokens synchroon houden in de tijd

Tokens helpen alleen als ze in lijn blijven. Behandel ze als één bron van waarheid: update tokens doelbewust (met een korte changelog) en propageren naar zowel Figma als code. Sommige teams reviewen token-wijzigingen op dezelfde manier als component-updates—lichtgewicht, maar consistent.

Als je al een systeem hebt, koppel token-updates aan dezelfde workflow als component-updates (zie /blog/component-mapping-and-reuse-at-scale).

Component-mapping en hergebruik op schaal

Het schalen van UI-levering is niet primair een “zet Figma om naar code”-probleem—het is een “zet de juiste componenten elke keer op dezelfde manier om”-probleem. AI helpt het meest wanneer het betrouwbaar kan mappen wat in het ontwerpbestand staat naar wat al in je codebase bestaat, inclusief namen, varianten en gedrag.

Figma-componenten naar code-componenten (en varianten) mappen

Begin met het geven van AI stabiele ankerpunten: consistente componentnamen, duidelijke variant-eigenschappen en een voorspelbare bibliotheekstructuur. Als die ankers bestaan, kan AI een mapping voorstellen zoals:

• Figma: Button met eigenschappen size, intent, state
• Code: <Button size="sm" variant="primary" disabled />

Hier ontmoeten design tokens en component-API's elkaar. Als je code-component variant="danger" verwacht maar Figma intent="error" gebruikt, kan AI de mismatch signaleren en een vertaallaag voorstellen (of een naamgevingsupdate) zodat mapping geen giswerk wordt.

Ontbrekende varianten detecteren voordat ze live gaan

Op schaal zijn de kostbaarste bugs “bijna juiste” componenten: de standaardstaat ziet er goed uit, maar randstaten ontbreken of zijn inconsistent. AI kan je bibliotheek scannen en gaten markeren zoals:

• Hover/focus/active staten niet gedefinieerd
• Disabled stijlen ontbreken voor bepaalde intenties
• Loading state bestaat in code maar niet in Figma (of andersom)
• Error state gedefinieerd in designs maar niet ondersteund door de component-API

De nuttige output is niet alleen een waarschuwing—het is een concreet takenpunt: “Voeg state=loading toe aan Button-varianten en documenteer spacing + spinner-uitlijning.”

Hergebruik stimuleren in plaats van lookalikes dupliceren

AI kan bijna-duplicates detecteren door structuur te vergelijken (padding, typografie, border-radius) en hergebruiksvoorstellen doen: “Deze ‘Primary CTA’ is 95% identiek aan Button/primary/lg—gebruik de bestaande component en override alleen de icoonplaatsing.” Dat houdt je UI consistent en voorkomt drift naar one-off stijlen.

Een nieuwe component maken vs een bestaande uitbreiden

Een praktische regel die AI kan helpen handhaven:

• Uitbreiden wanneer verschillen parameters zijn (size, icoon, intent, state) en als props/tokens uit te drukken zijn.
• Nieuwe maken wanneer gedrag, lay-outstructuur of toegankelijkheidssemantiek verandert (bijv. een knop wordt een split-button, of een “card” wordt een interactieve lijstitem met andere focusregels).

Als je deze regels één keer documenteert, kan AI ze herhaaldelijk toepassen—en componentbeslissingen veranderen van discussies in consistente, reviewbare aanbevelingen.

Van specificaties naar taken: handoff-documentatie automatiseren

Goede handoff-documentatie gaat niet om meer schrijven—maar om het juiste schrijven in een formaat waar ontwikkelaars snel mee kunnen werken. AI helpt door ontwerpinzicht om te zetten in duidelijke taken, acceptatiecriteria en implementatienotities die natuurlijk in je bestaande workflow passen.

Ontwerp-specs naar tickets en acceptatiecriteria omzetten

In plaats van metingen en gedragsnotities handmatig te kopiëren, gebruik AI om taakklare tekst te genereren vanuit een geselecteerd frame/component:

• Taaktitel + scope (wat gebouwd wordt en wat expliciet buiten scope valt)
• Acceptatiecriteria in eenvoudige taal (wat “klaar” betekent)
• Edge-cases die vaak worden gemist (lege staten, loading, error, lange tekst)

Voorbeelduitgewerkte acceptatiecriteria die AI kan opstellen (die je vervolgens verfijnt):

• Button heeft default / hover / pressed / disabled staten die bij het ontwerp passen.
• Op mobiel schakelt de lay-out naar de gestapelde variant bij het gedefinieerde breakpoint.
• Tekst trunkateert na 2 regels met ellipsis; volledige tekst zichtbaar via tooltip op desktop.

Details vastleggen die herwerk voorkomen

AI is het meest nuttig wanneer het consequent de “kleine” regels extraheert die de grootste mismatches veroorzaken:

• Spacingregels: padding, gaps, uitlijning en wanneer spacing verandert tussen varianten.
• Breakpoints: wat reflowt, wat wrapt en wat vast blijft.
• Componentstaten: interactiestaten, focusstijlen, validatieboodschappen en loading-gedrag.

Laat AI deze samenvatten als conciise implementatienotities gekoppeld aan het component of frame—kort genoeg om snel te scannen, specifiek genoeg om te coderen.

Documentatie vindbaar houden waar gewerkt wordt

Documentatie werkt alleen als mensen het kunnen vinden.

• Voeg AI-gegenereerde notities direct toe aan de ticketbeschrijving (Jira/Linear/etc.).
• Spiegel de belangrijkste beslissingen in een PR-template checklist zodat reviewers dezelfde dingen verifiëren.
• Verwijs terug naar één bron van waarheid (bijv. een handoff-pagina zoals /docs/handoff) in plaats van specs te dupliceren over tools.

Het doel: minder verduidelijkingsdraden, snellere inschattingen en minder “komt niet helemaal overeen met het ontwerp” UI.

Toegankelijkheid en UX-guardrails met AI

Toegankelijkheid zou geen aparte “compliance sprint” moeten zijn nadat UI gebouwd is. Wanneer je AI gebruikt naast Figma en je componentbibliotheek, kun je toegankelijkheids- en kern-UX-regels omzetten in guardrails die continu draaien—terwijl ontwerpen nog veranderen en vóórdat code wordt uitgerold.

Wat AI betrouwbaar uit ontwerpen kan halen

AI werkt goed als een snelle reviewer die vergelijkt wat in Figma staat met bekende standaarden (WCAG basics, platformconventies, jullie teampatronen). Praktische checks omvatten:

• Automatische contrastchecks, tekstgrootte en focusstaten
• Ontbrekende labels, foutmeldingen en toetsenbordstroom signaleren
• Issues terugkoppelen naar specifieke componenten in het ontwerp
• Toegankelijkheid onderdeel maken van de definitie-van-klaar, niet een late fix

Deze checks werken het beste wanneer AI je designsystem kent. Als een “TextField” component gemapt is naar een echte input-component in code, kan AI kijken naar vereiste staten (label, helptekst, error state, disabled, focus) en waarschuwen wanneer een ontwerp een “custom input look” gebruikt zonder ondersteunende semantiek.

Bevindingen omzetten in uitvoerbare fixes

Het doel is geen lange rapportage—maar een korte lijst met wijzigingen die ontwerpers en ontwikkelaars kunnen uitvoeren. Goede AI-toolkits koppelen elk issue aan een concreet knooppunt in Figma (frame, componentinstantie of variant) en suggereren de kleinste haalbare fix, zoals:

• “Gebruik de TextField/Error variant en voeg een placeholder voor het foutbericht toe.”
• “Verhoog knoptekst naar 14px of schakel naar de high-contrast token.”
• “Zorg dat de focusring zichtbaar is op het primaire knopstijl.”

Maak het onderdeel van jullie done-criteria

Voeg een lichtgewichte poort toe: ontwerpen mogen niet als “klaar voor implementatie” worden gemarkeerd voordat sleutel toegankelijkheids-/UX-checks slagen, en PRs mogen niet gemerged worden als de geïmplementeerde UI regressies introduceert. Wanneer guardrails vroeg en vaak draaien, wordt toegankelijkheid een routine kwaliteitsindicator—niet een last-minute scramble.

Kwaliteitschecks: design en UI consistent houden

AI kan implementatie versnellen, maar maakt het ook gemakkelijker om snel kleine inconsistenties te verzenden. De oplossing is om “design-fideliteit” te behandelen als elk ander kwaliteitsdoel: meetbaar, geautomatiseerd en beoordeeld op het juiste niveau.

Vergelijk de gebouwde UI met ontwerpinzet (visuele diffs)

Visuele diffing is de meest directe manier om drift te spotten. Nadat een component of pagina is geïmplementeerd, genereer screenshots in een gecontroleerde omgeving (zelfde viewportgroottes, geladen lettertypen, deterministische data) en vergelijk ze met een baseline.

AI kan helpen door:

• de juiste breakpoints en staten te suggereren om vast te leggen (hover, error, empty, loading)
• diffs te groeperen op waarschijnlijke oorzaak (lay-out vs typografie vs kleur)
• “wat is veranderd” in gewone taal samen te vatten voor snellere review

Ruimte, typografie en kleurmismatches vroeg vangen

De meeste “ziet er net niet goed uit” bugs komen van een paar terugkerende bronnen: spacing-schalen, fontstijlen en kleurwaarden. In plaats van te wachten op een volledige paginareview, valideer deze op het kleinste niveau:

• spacing: check padding/marges tegen je token-schaal (bijv. 4/8/12/16)
• typografie: valideer lettertype, grootte, gewicht, line-height en letter-spacing
• kleur: zorg dat gebruik gemapt is naar semantische tokens (bijv. text/default, bg/surface) in plaats van hard-coded hex

Wanneer AI gekoppeld is aan je design tokens, kan het mismatches signaleren terwijl de code geschreven wordt, niet pas nadat QA ze vindt.

Geef de voorkeur aan component-level QA boven page-level QA

Page-level QA is traag en luidruchtig: één kleine componentafwijking kan door meerdere schermen golven. Component-level checks maken fideliteit schaalbaar—fix één keer, profiteer overal.

Een nuttig patroon is “component snapshots + contracttests”: snapshots vangen visuele drift, terwijl kleine checks bevestigen dat props, staten en tokengebruik consistent blijven.

Definieer acceptabele verschillen (en documenteer ze)

Niet elke mismatch is een bug. Platformbeperkingen (font-rendering, native controls, responsive reflow, prestatieafwegingen) kunnen legitieme verschillen veroorzaken. Spreek vooraf toleranties af—zoals sub-pixel afronding of font anti-aliasing—en leg uitzonderingen vast in een korte beslissingslog gekoppeld aan je handoff-docs (bijv. /docs/ui-qa). Hierdoor blijven reviews gericht op echte regressies in plaats van eindeloze pixel-discussies.

Workflow-patronen die echt werken

AI is het meest nuttig als het wordt behandeld als een teamgenoot met een nauw afgebakende taak, niet als vervanging voor ontwerpbesluitvorming of engineering-eigenaarschap. De patronen hieronder helpen teams snelheid te krijgen zonder consistentie op te geven.

Waar AI thuishoort: vóór, tijdens en na ontwikkeling

Voor dev, gebruik AI om het bestand voor te vliegen: identificeer ontbrekende staten, inconsistent spacing, onbedoelde componenten en token-violaties. Dit is de snelste winst omdat het herwerk voorkomt.

Tijdens dev, gebruik AI als implementatieassistent: genereer eerste versie UI-code van geselecteerde frames, stel componentmatches voor uit je bibliotheek en draft CSS/token-mapping. Developers moeten nog steeds echte data, routing en state aansluiten.

Na dev, gebruik AI om te valideren: vergelijk screenshots met Figma, signaleer visuele diffs, controleer toegankelijke namen/contrast en bevestig tokengebruik. Behandel dit als een geautomatiseerde reviewer die “papierwondjes” vroeg vindt.

Het 3-persoons samenwerkingsmodel

De meest betrouwbare opzet is ontwerper + ontwikkelaar + reviewer:

• Ontwerper zorgt dat de Figma bron van waarheid schoon is (componenten, varianten, tokens) en beantwoordt intentievragen (“Is deze hover-state vereist?”).
• Ontwikkelaar is eigenaar van productiebeslissingen (componenthergebruik, performance, responsief gedrag).
• Reviewer (vaak een design system lead of senior engineer) bevestigt dat de output bij jullie systeem past en keurt uitzonderingen goed.

AI ondersteunt elke rol, maar vervangt de uiteindelijke beslissingsverantwoordelijkheid niet.

Governance zonder vertraging

Definieer lichtgewicht goedkeuringsregels:

• Tokens: design system eigenaar keurt nieuwe tokens goed; iedereen kan voorstellen.
• Componenten: library maintainers keuren nieuwe componenten/varianten; feature teams hergebruiken eerst.
• Wijzigingen: productteams mogen lay-out binnen toegestane grenzen aanpassen; alles wat een nieuw patroon creëert vereist review.

Schrijf deze regels één keer op en verwijs ernaar in je teamdocs (bijv. /design-system/governance).

Voorkom “AI-generated drift”

Drift ontstaat wanneer het model spacing, kleuren of componenten verzint die “goed genoeg” zijn. Verminder dit door:

• Generatie te beperken tot bestaande componenten en tokens (geen raw hexwaarden, geen ad-hoc padding).
• Een component mapping tabel in PRs te verplichten (“Figma Card → DS Card v3”).
• Geautomatiseerde checks te draaien die builds falen wanneer niet-token stijlen verschijnen.

Wanneer AI alleen kan bouwen met de Lego-blokken van je systeem, blijft output consistent—zelfs snel.