Waarom raadt een AI je componenten mis?

Een AI-agent die Figma-designs omzet naar code heeft één groot probleem: hij ziet de componenten in je design, maar weet niet hoe ze in de echte codebase heten of werken. Dus gaat hij raden. Soms raadt hij goed. Vaker bouwt hij iets na van primitieven, terwijl je al een kant-en-klaar component had liggen.

Dit is iets waar ik eerlijk gezegd te lang mee heb rondgelopen. Ik werkte met Figma en Claude voor design-to-code werk, en de output was wisselend. Soms perfect, soms een handgemaakte versie van een component die we al hadden. Het probleem zat niet in het model. Het zat in de context die ik meegaf.

Code Connect is de oplossing die Figma biedt voor dit probleem. Het is een koppeling (mapping) tussen een component in Figma en zijn tegenhanger in de code. Vergelijk het met een woordenboek: de AI ziet ‘Stepper’ in het design en slaat op in het woordenboek op wat dat in jouw codebase betekent, inclusief alle properties en gebruik.

Zonder dat woordenboek gaat de agent gokken. En bij complexe componenten, zoals een Stepper met tientallen properties, levert dat bijna altijd rommel op. Met een goede design system opzetten-aanpak leg je in één tekstbestand vast hoe jouw merk eruitziet, dat is een laagdrempelig startpunt als je nog geen volledig design system hebt.

Wat leverde 22% tijdsbesparing op in de praktijk?

Coinbase testte Code Connect in een gecontroleerde opzet: hetzelfde design, dezelfde prompt, hetzelfde model, drie keer uitgevoerd. Met en zonder Code Connect. Het resultaat was consistent: elke run met Code Connect was goedkoper, sneller en nauwkeuriger dan zonder. Gemiddeld 22,5% lagere kosten en 22% kortere implementatietijd.

De testopzet was slim. Ze gebruikten een design dat niet te simpel en niet te complex was: een mix van componenten, inclusief een paar lastige gevallen zoals de Stepper (complex, veel properties) en icoon- en illustratienamen (die agents notoir slecht raden).

Dat laatste punt trof me. Agenten hallucineren icoon- en illustratienamen. Ze verzinnen namen die niet bestaan. Na het instellen van Code Connect verdween dat probleem volledig. Niet minder vaak. Verdwenen.

De verklaring is logisch: de agent hoeft niet meer te zoeken en te raden welk icoon er bedoeld wordt. De mapping vertelt het hem direct. Minder zoekwerk betekent minder tokens, en minder tokens betekent lagere kosten en kortere looptijd. Dit is precies waarom ik nu bij elk project als eerste check of het design system goed is opgezet voordat ik een AI-agent op een design loslaat. Een slordig design system is een dure agent.

Overigens controleerde de test ook voor prompt caching, een techniek waarbij eerder verwerkte context hergebruikt wordt. Dat kan resultaten vertekenen als je het niet uitschakelt. Ze deden dat wel, wat de uitkomsten betrouwbaarder maakt.

Agent skills vs. Code Connect: doen ze hetzelfde?

Nee, en dat onderscheid is belangrijk. Agent skills vertellen een AI hoe hij iets moet bouwen: welke patronen te kiezen, welke componenten te vermijden, hoe je design tokens gebruikt. Code Connect geeft de agent context over wat er beschikbaar is. De twee vullen elkaar aan, ze vervangen elkaar niet.

Dit is een inzicht dat ik zelf ook pas later begreep. Ik dacht dat goede instructies (agent skills of een systeem-prompt) genoeg waren om een AI goed te laten presteren op design-to-code taken. Dat klopt deels. Maar instructies over hoe je iets bouwt helpen niet als de agent niet weet wat er al gebouwd is.

De vergelijking die ik gebruik: agent skills zijn de werkwijze van een nieuwe collega, Code Connect is het onboarding-document met alle bestaande componenten. Je hebt beide nodig.

Interessant is ook de langetermijnvisie hierachter. Naarmate AI-modellen beter worden, hebben ze minder expliciete instructies (skills) nodig om goede keuzes te maken. Maar de kwaliteit van de context, weten welke componenten er zijn en hoe ze werken, blijft altijd relevant. Dat maakt Code Connect eigenlijk toekomstvaster dan agent skills.

Wil je begrijpen hoe Figma Skills werken als herbruikbare AI-instructies? Lees dan hoe Figma Skills designers helpen met AI-workflows als goed startpunt om het verschil voelbaar te maken.

Wat moet je nu doen als je een design system hebt?

Check of je componenten in Figma gekoppeld zijn aan de code via Code Connect. Zijn ze dat niet, of zijn de mappings verouderd? Dan geef je elke AI-agent die je gebruikt een slechte startpositie. Updaten hoeft niet per hand: je kunt een agent de mappings laten schrijven op basis van een lijst componenten.

Het Coinbase-team had hetzelfde probleem: bestaande mappings waren verouderd en nieuwe componenten hadden helemaal geen template. Ze losten dat op door een agent in te zetten die de mappings parallel bijwerkte. In vier uur hadden ze volledige dekking voor hun design system.

Dat is de aanpak die ik zou volgen. Niet handmatig elke component doorlopen, maar een gestructureerde lijst maken en een agent het werk laten doen. Let op: de output moet je nog wel controleren. Een agent die mappings schrijft kan fouten maken, zeker bij complexe componenten.

Heb je nog geen design system? Dan is dit een goed moment om na te denken over hoe je dat opzet. Niet als luxe voor grote teams, maar als fundament voor alles wat je met AI bouwt. Met een DESIGN.md leg je in één tekstbestand vast hoe jouw merk eruitziet, dat is een laagdrempelig startpunt als je geen volledig design system hebt.

Voor wie WordPress gebruikt en wil weten hoe AI past in het bredere plaatje van webdesign en development: AI inzetten voor WordPress-code begrijpen en verbeteren laat zien hoe je AI als sparringpartner gebruikt in plaats van als schrijfmachine.

Wat zijn Figma Skills precies?

Figma Skills zijn markdown-bestanden met instructies die de ingebouwde AI-agent van Figma uitvoert. Je roept ze aan met een slash-commando, zoals /component-handoff of /ui-state-expander. Ze werken als persoonlijke sneltoetsen voor taken die je anders steeds opnieuw handmatig zou doen. Je schrijft ze zelf, of je gebruikt er een van de Figma Community.

Een Skill is eigenlijk een gestructureerde prompt die je één keer schrijft en daarna eindeloos hergebruikt. Het klinkt technisch, maar het zijn gewoon tekstbestanden in markdown-formaat, dezelfde opmaaktaal als in veel notitie-apps. Je hoeft geen developer te zijn om ze te begrijpen of te schrijven.

Wat me opvalt aan dit systeem: het legt voor het eerst de designkennis van een individuele ontwerper vast in een deelbare vorm. Normaal zit die kennis in iemands hoofd. Nu zit het in een bestand dat iedereen in het team kan gebruiken. Dat is een fundamenteel ander idee dan een template of een component library.

Je maakt een Skill door de agent te vragen er een te schrijven op basis van een frame in je design of via specifieke stappen die je opgeeft. Daarna kun je hem direct testen, bijsturen en aanpassen. Als je de manier waarop Figma Weave merkstijlen vastlegt al interessant vond, dan is dit de volgende stap in diezelfde richting.

Welke 10 Skills zijn het meest nuttig voor een designer?

De Figma Community heeft tientallen Skills gepubliceerd. Tien daarvan springen eruit omdat ze concrete tijdwinst opleveren: van automatische componentdocumentatie tot een volledige UI-state-checker en een ingebouwde design review op basis van UX-heuristieken.

Hieronder de tien Skills die de meeste designpijn wegnemen, met wat ze concreet doen:

• /component-handoff: genereert automatisch een documentatieframe met naam, versie, variant-grid, do’s en don’ts en anatomie van een component. Wat eerder een uur kostte, duurt nu een klik.
• /ui-state-expander: pakt een scherm en vult alle ontbrekende states in, zoals loading, empty, error, disabled en edge cases. Inclusief copy, transitions en implementatienotes voor de developer.
• /analyze-components: crawlt een pagina, vindt orphans, duplicaten en naamfouten, repareert ze automatisch en schrijft een auditrapport op het canvas.
• /superfuture-design-review: beoordeelt een bestand op UX-heuristieken, toegankelijkheid en visuele hiërarchie, met een stoplicht-systeem: rood voor blockers, geel voor aanbevelingen, groen voor wat al werkt.
• /create-color: mapt alle fills, strokes en shadows in een component naar design tokens of styles, en markeert hard-gecodeerde kleuren die nog vervangen moeten worden.
• /find-animation-opportunities: scant designs op plekken die wel of niet zouden moeten animeren, met exacte waarden en concrete aanbevelingen.
• /camera-pan-and-zoom: bouwt een camera-rig, een geneste laagstructuur die echte camerabeweging nabootst, om geselecteerde content en animeert die als een motion director.
• /better-interface: geeft de agent een persoonlijk regelboek voor interface-craft, met standaarden voor typografie, layout, toegankelijkheid en productteksten.
• /usability-test-guide: genereert een discussiegids voor usability-tests op basis van een designflow, met open vragen direct op het canvas naast elk frame.
• /xray-scan: zet een foto of tekstbeschrijving om naar een radiografisch beeld in twee afwerkingen, handig voor creatieve collages en moodboards.

Naar mijn idee zijn /component-handoff en /ui-state-expander de twee die direct rendement opleveren voor iedereen die regelmatig designs overdraagt aan developers. De rest is waardevol, maar afhankelijk van je specifieke workflow. Bekijk ook hoe AI Figma-designs omzet naar werkende code voor een aansluitende aanpak.

Hoeveel tijd bespaar je er écht mee?

Componentdocumentatie die handmatig een uur kost, doet /component-handoff in één klik. Een volledige UI-state-check die je normaal vergeet tot de developer erom vraagt, doet /ui-state-expander in enkele minuten. De tijdwinst zit niet in spectaculaire taken, maar in de dingen die je anders uitstelt.

Eerlijk gezegd was ik sceptisch toen ik voor het eerst hoorde over ‘AI die je designtaken overneemt’. Mijn eerste reactie: dat klinkt als een belofte die in de praktijk tegenvalt. Maar de Skills-aanpak werkt anders dan een generieke AI-chat, en dat maakt het verschil.

Het verschil is specificiteit. Een generieke AI weet niet hoe jouw team componenten documenteert, welke states jij altijd vergeet of welke kleuren hard-gecodeerd zijn in je design system. Een Skill wél, omdat jij die kennis er zelf in hebt gestopt. Of iemand anders dat voor je heeft gedaan en het gedeeld heeft in de Community.

De concrete tijdwinst per Skill is moeilijk te generaliseren, want die hangt af van hoe ingewikkeld je design system is. Maar de /analyze-components-skill pakt het soort werk aan dat je normaal uitstelt tot het echt niet meer kan. Dat soort uitgesteld werk kost uiteindelijk meer tijd dan de taak zelf.

Voor wie website-toegankelijkheid serieus neemt, is /superfuture-design-review interessant: die checkt ook op toegankelijkheidsstandaarden als onderdeel van de review.

Zelf een Skill schrijven: zo werkt dat in de praktijk

Je vraagt de Figma-agent een Skill te maken op basis van een frame of een beschrijving van je werkwijze. De agent schrijft een eerste versie, jij test die, past aan en slaat op. Je kunt de markdown ook direct bewerken als je precies weet wat je wilt.

Het proces is minder technisch dan het klinkt. Je hoeft geen code te schrijven. Je beschrijft in gewone taal wat je wilt dat de Skill doet, de agent vertaalt dat naar gestructureerde instructies, en jij controleert of het klopt. Klopt het niet helemaal? Dan zeg je wat er anders moet, net als in een gewone chatconversatie.

Wat ik een slim detail vind: je kunt een bestaand designframe gebruiken als referentie. Je wijst de agent op een component die je altijd op een bepaalde manier documenteert, en vraagt hem daar een Skill van te maken. Zo leg je werkwijzen vast die anders alleen in je hoofd zitten.

Let op: Skills zijn momenteel beschikbaar voor Full seat-gebruikers op Professional, Organization en Enterprise plannen. Collab-, Dev- en View-seats kunnen de agent gebruiken in hun drafts. Tijdens de open beta is het gratis. Wat het na de beta kost, is nog niet bekendgemaakt.

Als je al werkt met AI-tools die Figma-designs omzetten naar code, dan past dit systeem goed in diezelfde workflow. Je legt je designkennis vast in Skills, en je legt je code-kennis vast in de tools die de output verwerken.

Hoe ik dit voor het eerst gebruikte

Een klant stuurde me een Figma-link met een dashboard-design dat ik in React moest bouwen. In plaats van handmatig elke component over te tikken, plakte ik de link in Claude met de instructie om het op te bouwen volgens mijn vaste stack. Tien minuten later had ik 80 procent werkende code.

De setup is simpel als je het eenmaal hebt gedaan. Je gebruikt de Figma MCP-server (open-source, een halve dag installatie) of je exporteert het frame als afbeelding plus design-tokens. Claude heeft dan toegang tot de structuur van het design en de specifieke kleuren, fonts en spacing.

De winst van die eerste ervaring: een dashboard waar ik normaal een halve werkdag mee bezig was, was binnen anderhalf uur live. Niet pixel-perfect, niet helemaal volgens mijn smaak, maar werkend en op klanten-stijl. De rest was handmatig finetunen.

Wanneer dit echt goed werkt

Bij design systemen met duidelijke components, herhaalbare patterns en consistente naamgeving. Een Figma-bestand met losse "schermen" zonder component-structuur geeft veel slechtere code. Hoe schoner de Figma, hoe beter de output.

Wat de output kwalitatief onderscheidt: of de designer in Figma met components heeft gewerkt of met losse rechthoeken en tekstvelden. Een Figma-bestand met “Button/Primary”, “Card/Default” en “Input/WithLabel” als components geeft Claude direct herhaalbare React-componenten terug. Een bestand met 20 versies van een knop die elk net iets anders zijn, geeft 20 versies van dezelfde knop in code.

Mijn tip aan klanten en designers: investeer in de Figma-setup vóór de developer eraan komt. Een halve dag componenten netjes inrichten in Figma scheelt later twee dagen handmatige React-arbeid. Dat is een hele goede ROI.

Wat Claude nog niet goed doet

Animaties, complexe state-handling, en alles wat dynamisch reageert op data. Een Figma toont meestal een statische staat. Claude raadt redelijk goed wat dynamisch zou moeten zijn, maar voor productie-kwaliteit is dat altijd handmatig nawerk. Plus: design-tokens vertaalt hij niet altijd naar jouw setup.

Concreet bij een laatste project: Claude zette de visuele kant van een filters-paneel goed neer, maar de logica voor het opslaan van de filterstatus, het synchroniseren met URL-params en het handelen van loading-states moest ik zelf bouwen. Dat is werk dat in geen enkele Figma staat, dus dat is logisch.

Wat ik er bij klanten over zeg: gebruik dit voor de eerste 80 procent van het visuele werk. De laatste 20 procent (interactie, edge-cases, prestatie-optimalisatie) blijft mensenwerk. Wie deze grens niet trekt, levert demo-kwaliteit op aan klanten en raakt klant en project allebei kwijt.