Lär dig hur AI härleder layout, hierarki och användaravsikt från design, genererar UI-kod—plus begränsningar, bästa praxis och genomgångstips.

”Design to code” AI översätter en visuell designidé—vanligtvis en Figma-ram eller en skärmbild—till körbar UI-kod. Poängen är inte ”perfekt kod”; det är ett användbart första utkast som fångar struktur, stil och grundläggande beteende så att en människa kan förfina det.
I grunden kartlägger systemet vad det kan observera till hur UI vanligtvis byggs.
AI kan härleda vanliga mönster: en rad ikoner är troligen en verktygsrad; en staplad etikett + input är sannolikt ett formulärfält; konsekvent styling antyder en återanvändbar komponent. Den kan också gissa responsivt beteende baserat på constraints och avstånd.
Men du måste oftast specificera vad pixlar inte kan garantera: riktiga komponentnamn, designtokens (färger/typskalor), states (hover/disabled/error), brytpunkter, dataregler och faktiska interaktioner (validering, navigationsmål, analys).
Behandla output som en startpunkt. Förvänta dig att granska struktur, ersätta ad-hoc-stilar med tokens, anpassa till ditt komponentbibliotek och iterera. “Design to code” är acceleration—inte automation som tar bort behovet av design- och utvecklingsbedömning.
AI kan inte härleda produktregler från en “vacker skärm.” Den arbetar utifrån bevisen du ger—vissa inputs beskriver pixlar, andra beskriver struktur. Den skillnaden avgör ofta om du får ren UI-kod eller bräcklig absolut positionering.
En skärmbild är det tunnaste inputet: den innehåller färger och former, men inga explicita fakta om vad som är en knapp vs en etikett, vad som är återanvändbart eller hur layouten ska anpassa sig.
Utifrån pixlar måste AI gissa gränser (var ett element slutar och ett annat börjar), textstilar, avståndsregler och till och med om ett “kort” är en komponent eller flera separata bitar. Den kan inte heller härleda constraints—så responsivt beteende blir mest spekulation.
När AI kan komma åt designfilen (eller en export som bevarar struktur) får den viktig metadata: frames, grupper, lagernamn, Auto Layout-inställningar, constraints och text-/stildefinitioner.
Där blir layout mer än geometri. En Figma-ram med Auto Layout kommunicerar till exempel intentionen “stapla dessa objekt vertikalt med 16px gap” mycket tydligare än en skärmbild. Konsekvent lagernamngivning hjälper också att mappa element till UI-roller (t.ex. “Primary Button,” “Nav Item,” “Input/Error”).
Ett sammankopplat designsystem minskar gissningarna. Tokens (färg, spacing, typografi) låter AI generera kod som refererar en gemensam sanningskälla istället för hårdkodade värden. Publicerade komponenter (knappar, fält, modaler) erbjuder färdiga byggstenar och tydligare gränser för återanvändning.
Även små konventioner—som att namnge varianter (Button/Primary, Button/Secondary) och använda semantiska tokens (text/primary) istället för #111111—förbättrar komponentmappningen.
Specs lägger till “varför” bakom UI:t: hoverbeteende, loading- och tomtillstånd, valideringsregler, tangentbordsbeteende och felmeddelanden.
Utan detta tenderar AI att generera en statisk snapshot. Med det kan output inkludera interaktionshooks, state-hantering och mer realistiska komponent-API:er—närmare något ett team kan leverera och underhålla.
Design-to-code-verktyg uppfattar inte en skärm som en människa; de försöker förklara varje lager som layoutregler: rader, kolumner, containrar och avstånd. Ju tydligare de reglerna är, desto mindre förlitar sig resultatet på bräcklig positionering.
De flesta modeller börjar med att leta efter upprepad justering och lika gap. Om flera element delar samma vänsterkant, baslinje eller mittlinje behandlar AI dem ofta som en kolumn eller rutnätsspår. Konsekvent avstånd (t.ex. 8/16/24px-mönster) antyder att layout kan uttryckas med stack gaps, grid gutters eller tokeniserat spacing.
När avstånden varierar lite (15px här, 17px där) kan AI dra slutsatsen att layouten är “manuell” och falla tillbaka på absoluta koordinater för att bevara pixelperfekta avstånd.
AI söker också visuella “omslutningar”: bakgrunder, ramar, skuggor och padding-liknande mellanrum som antyder en container. Ett kort med bakgrund och intern padding är en stark signal för ett föräldra-element med barn.
Därifrån mappar den ofta struktur till primitiv som:
Ren gruppering i designfilen hjälper att skilja föräldrar från syskon.
Om designen inkluderar constraints (pinning, hugging, fill) använder AI dem för att bestämma vad som sträcker sig och vad som förblir fast. “Fill”-element blir typiskt flexibla bredder (t.ex. flex: 1), medan “hug” mappas till innehålls-storleksanpassade element.
Absolut positionering visar sig ofta när modellen inte säkert kan uttrycka relationer med flödeslayouter—ofta på grund av inkonsekvent spacing, överlappande lager eller feljusterade element. Det kan se korrekt ut i en skärmstorlek men bryta responsivitet och textstorleksändringar.
Att använda en liten spacing-skala och anpassa till ett tydligt rutnät ökar dramatiskt chansen att AI producerar ren flex/grid-kod istället för koordinater. Konsekvens är inte bara estetik—det är ett maskinläsbart mönster.
AI “förstår” inte hierarki; den härleder vikt från mönster som vanligen signalerar det. Ju tydligare din design kommunicerar dessa signaler, desto mer sannolikt matchar den genererade UI:n din avsikt.
Typografi är en av de starkaste ledtrådarna. Större teckenstorlek, tyngre vikt, högre kontrastfärg och generösare radavstånd indikerar vanligtvis högre prioritet.
Till exempel är en 32px fet titel ovanför ett 16px vanligt stycke ett tydligt “rubrik + body”-mönster. Där det blir knepigt är när stilar blandas—t.ex. två textblock som skiljer sig med bara 1–2px eller använder samma vikt med olika färger. Då kan AI märka båda som vanlig text eller välja fel rubriknivå.
Hierarki härleds också från rumsliga relationer. Element som ligger nära varandra, är justerade och skiljs från annat innehåll med vitt utrymme behandlas som en grupp.
Vanliga bakgrunder (kort, paneler, tonade sektioner) fungerar som visuella parenteser: AI tolkar dem ofta som containrar som section, aside eller en komponent-wrapper. Ojämn padding eller inkonsekvent spacing kan orsaka oavsiktlig omgruppering—t.ex. att en knapp kopplas till fel kort.
Upprepade mönster—identiska kort, listobjekt, rader eller formulärfält—är starkt bevis för en återanvändbar komponent. Även små skillnader (ikonstorlek, hörnradie, textstil) kan få AI att generera flera engångsvarianter istället för en komponent med varianter.
Knappar signalerar avsikt genom storlek, fyllning, kontrast och position. En fylld knapp med stark kontrast behandlas vanligtvis som primär åtgärd; outline- eller text-knappar blir sekundära. Om två åtgärder ser lika betonade ut kan AI gissa fel om vilken som är “primär”.
Slutligen försöker AI mappa hierarki till semantik: rubriker (h1–h6), grupperade regioner (section) och meningsfulla kluster (som “produktdetaljer” vs “köp-åtgärder”). Tydliga typografiska steg och konsekvent gruppering gör den här översättningen mycket mer pålitlig.
Modeller förutspår avsikt genom att matcha det de ser med mönster lärda från många UI:er: vanliga former, etiketter, ikonografi och placeringskonventioner.
Vissa arrangemang antyder starkt specifika komponenter. En horisontell remsa högst upp med en logotyp till vänster och textobjekt till höger är sannolikt en navigationsbar. En rad lika breda objekt med ett markerat blir ofta flikar. Upprepade rutor med bild, titel och kort text läses som kort. Täta rutnät med justerade rubriker och rader blir ofta tabeller.
Dessa gissningar påverkar struktur: en “flik” implicerar valt state och tangentbordsnavigering, medan en “rad med knappar” kanske inte gör det.
AI letar efter cues som vanligtvis indikerar interaktion:
Därifrån tilldelar den beteenden: klicka, öppna meny, navigera, skicka, expandera/komprimera. Ju mer designen skiljer interaktiva från statiska element, desto mer träffsäker blir output.
Om designen visar flera varianter—hover, aktiv/vald, disabled, error, loading—kan AI mappa dem till stateful-komponenter (t.ex. disabled-knappar, valideringsmeddelanden, skeleton loaders). När states inte är explicita kan AI utelämna dem.
Otydlighet är vanlig: är ett kort klickbart eller informativt? Är en chevron dekorativ eller en disclosure-kontroll? I de fallen, förtydliga genom namngivning, annoteringar eller separata ramar som demonstrerar interaktionen.
När AI har en rimlig tolkning av layout är nästa steg att översätta “vad det ser ut som” till “vad det är”: semantisk HTML, återanvändbara komponenter och konsekvent styling.
De flesta verktyg mappar designlager och grupper till ett DOM-träd: frames blir containrar, textlager blir rubriker/paragrafer och upprepade objekt blir listor eller rutnät.
När avsikten är tydlig kan AI fästa bättre semantik—t.ex. blir en topbar ett \u003cheader\u003e, en logotyp och länkar blir ett \u003cnav\u003e, och ett klickbart kort blir en \u003ca\u003e eller \u003cbutton\u003e. ARIA-roller kan ibland härledas (som role="dialog" för en modal), men bara när mönstret är entydigt; annars blir säkrare output vanlig HTML plus TODOs för tillgänglighetsgranskning.
För att undvika att generera en jättelik fil försöker AI dela upp UI i primitiv:
Vanliga signaler för en “komponent” är upprepning, konsekvent padding/typografi och ett grupperat klickbart område. Vanliga fel är överfragmentering (för många pyttesmå komponenter) eller underfragmentering (allt hårdkodat en gång).
Generatorn väljer oftast en strategi baserat på målstack eller sina standarder:
Högkvalitativ output lutar mot design-tokens—färger, spacing, radius, skuggor—så att koden förblir konsekvent när designen utvecklas. En strikt pixelmatch ger ofta engångsvärden (t.ex. 13px gaps, nästan identiska gråtoner) som ser rätt ut men är svåra att underhålla.
En praktisk balans är: bevara hierarki och spacing-rytm, normalisera sedan till tokens och komponenter som du kan återanvända (och refaktorera vidare i granskningssteget—se /blog/how-to-review-and-refactor-generated-ui-code).
Designfiler ser ofta “färdiga” ut eftersom de ritas i ett par fasta ramstorlekar (som 1440 och 375). Kod kan inte anta det. Ett design-to-code-verktyg måste bestämma hur UI:t beter sig över mellanliggande bredder, med hjälp av ledtrådar och standardval.
Om din design inkluderar flera versioner av samma skärm (desktop/tablet/mobile) och strukturen är konsekvent kan AI aligna dem och härleda var layoutregler ändras. Utan varianter faller den oftast tillbaka på vanliga brytpunkter och behandlar ramstorleken som “bas”, vilket kan ge klumpiga hopp.
AI letar efter mönster: upprepade kort i ett rutnät, lika avstånd och justering. Utifrån det kan den besluta att ett 3-kolumnsrutnät blir 2 kolumner, sedan 1. Den har svårt när designen förlitar sig på manuella nudges—element som ser ut att vara justerade men inte är konsekventa—eftersom den inte kan avgöra om det var avsiktligt.
De flesta designer använder kort, prydlig copy. Riktiga produkter gör inte det. AI-genererad UI-kod sätter ofta fasta bredd-/höjdmått eller trunkerar för aggressivt.
En snabb sanity-check är att testa:
AI kan bevara pixel-perfekt crop från designen, men responsiva UI behöver regler: behåll aspect ratio, välj hur man crop:ar och när bilder ska skala ner vs byta placering. Om designen inte specificerar detta, förvänta dig “fill”-beteende som kan croppa viktiga delar.
Innan du litar på output, förhandsgranska i mycket små bredder, mycket stora skärmar och mellanliggande storlekar. Om något överlappar, klipps eller blir oläsbart beror det oftast på saknad layout-intent—inte “dålig kod”—och det är en signal att lägga till tydligare constraints i designen.
AI kan konvertera pixlar till UI-kod förvånansvärt bra, men tillgänglighet är där “ser rätt ut” ofta skiljer sig från “fungerar för alla”. Eftersom många krav inte syns i en statisk ram behöver modellen explicita signaler.
Vissa tillgänglighetsvänliga val syns visuellt och AI kan ofta mappa dem till bättre HTML:
Andra krav syns inte tillförlitligt:
Räkna med luckor som saknade label/for-kopplingar, fel rubriknivå, klickbara div utan tangentbordssupport, svaga fokusstilar och ikoner utan textalternativ.
h1 → h2 → h3).header, nav, main, footer) och är inte duplicerade.alt (eller alt="" när dekorativt).Lägg till en kort spec när du har modaler, drawers, komplexa formulär, custom selects, drag-and-drop eller något med icke-triviala states. Även några få rader som “trap focus i modal”, “Esc stänger” och “annonserar inline-fel” kan dramatiskt förbättra genererad UI-kod.
AI kan producera UI-kod som vid första anblick ser nära rätt ut, men små tolkningsfel samlas snabbt. De flesta problem kommer från “rimliga gissningar” när designen inte tydligt kodar regler.
Ett vanligt klagomål är avstånd som inte stämmer: knappar som känns lite fel, sektioner som andas för mycket eller kort som blir trångt. Detta händer när padding över liknande element är inkonsekvent eller när auto-layout/constraints blandas med manuella justeringar. Modellen kan tvinga fram ett mönster (t.ex. “16px överallt”) och skriva över undantag—or bevara undantag som var oavsiktliga.
Genererad markup har ofta för många wrapper-element. Varje visuellt gruppantagande blir en extra \u003cdiv\u003e. Resultatet är svårare att styla, felsöka och ibland långsammare att rendera. Du märker det när ett enkelt kort blir fem nivåer av containrar bara för att aligna en ikon och en titel.
AI kan dela upp komponenter för granularitet (varje etikett blir sin egen komponent) eller vara för monolitisk (hela skärmen blir en komponent). Rotorsaken är oklara gränser: om upprepade mönster inte är identiska kan modellen inte säkert extrahera en delad komponent.
Typografi “driftar” ofta eftersom designtextstilar inte alltid mappar rent till kod. Subtila skillnader i radhöjd, bokstavsavstånd eller vikt kan gå förlorade, och font-fallbacks kan ändra metrik mellan miljöer. Därför kan en rubrik som passade i Figma plötsligt brytas i koden.
Om hover, focus, error, loading eller tomma states inte representeras i designen uppfinner AI dem sällan. UI:t kan se rätt ut i en statisk skärmbild men misslyckas så fort användare interagerar.
AI-kodgeneratorer “ser” inte din design som en människa—de läser en strukturerad fil fylld av lager, constraints, stilar och komponentinstanser. Ju renare den strukturen är, desto mindre behöver modellen gissa (och desto färre konstiga div-soppor behöver du reda ut senare).
Lagernamn är en av de starkaste signalerna för avsikt och komponentmappning. Föredra konsekventa, beskrivande mönster som matchar hur du bygger UI:
Button/Primary, Button/SecondaryCard/Product, Card/ArticleForm/Input/Text, Form/CheckboxUndvik att lämna allt som “Rectangle 12” eller “Group 5”—det gör att AI tenderar mot generiska wrappers istället för återanvändbara komponenter.
Manuell positionering blir ofta absoluta koordinater i kod. Vill du ha flex/grid-output bör designen bete sig som flex/grid:
När designen reagerar väl inne i designverktyget är den genererade UI:n mycket mer sannolikt responsiv som standard.
Enstaka färger, typsnittsstorlekar och spacing-värden uppmuntrar engångs-CSS. Istället:
Detta förbättrar konsistens och gör det lättare att refaktorera mot ett designsystem senare.
AI kan inte härleda det den inte hittar. Lägg till nyckelvarianter som hover/pressed/disabled, felstater för inputs, loading-stater och tomma tillstånd.
När beteende spelar roll, annotera kort: “öppnar modal”, “server-validerad”, “visar toast vid lyckat resultat”. En enda rad nära en komponent kan förhindra felaktig interaktionskod.
Om du standardiserar ett teamflöde, fånga dessa konventioner i en lättviktig checklista och hänvisa internt (t.ex. blogginlägget design-to-code-checklist).
AI-genererad UI-kod är bäst att betrakta som ett första utkast: det kan spara timmar, men behöver ändå en manuell genomgång för att säkerställa att UI:t beter sig korrekt, är underhållsbart och matchar produktstandarder.
Börja med att läsa markup som om du var en skärmläsare.
\u003ch1\u003e, sedan logiska \u003ch2\u003e/\u003ch3\u003e).\u003cul\u003e/\u003col\u003e) och inte staplade \u003cdiv\u003es.Om semantiken är fel räddar inte CSS tillgängligheten eller användbarheten.
Många generatorer förlitar sig på absolut positionering eller djupt nestade wrappers för att “matcha skärmbilden.” Det tenderar att bryta när innehållet ändras.
Föredra flex/grid-regler framför koordinater, och minska nesting tills varje wrapper har en tydlig anledning att existera (layoutgruppering, spacing eller komponentgräns). Om du ser upprepade style={{ left, top, width, height }}-mönster, skriv om det området först.
Sök efter upprepade UI-mönster (kort, inputrader, nav-items) och gör dem till återanvändbara komponenter. Ersätt sedan hårdkodade värden med tokens: spacing, radius, typografi och färger. Om ditt team redan har token-riktlinjer, anpassa till dem; annars börja med en minimal uppsättning och utöka avsiktligt.
Du behöver inte ett tungt testsystem för att få värde.
Generatorer gissar avsikt. Fånga alla ändringar du gjort (interaktionsregler, brytpunkter, komponentmappningar) så att nästa generation eller nästa utvecklare inte ångrar dem.
AI “design to code” fungerar bäst när du behandlar det som en accelerator, inte autopilot. De snabbaste teamen väljer ett arbetsflöde som matchar mognaden i deras designsystem och risknivån för skärmen de bygger.
1) AI-assist inne i designverktyg (t.ex. Figma-plugins): Utmärkt för att hålla sig nära källfilen. Du får snabb scaffolding medan designers itererar, och det är enklare att behålla namn, komponenter och tokens i filen.
2) Externa konverterare (export → kod): Bra när du behöver en upprepbar pipeline över många filer eller team. Det kan gå snabbare för bulkkonvertering, men du lägger ofta mer tid på att städa struktur och koppla interaktioner.
I praktiken kombinerar många team design-to-code med ett bredare “spec till levererad app”-flöde. Till exempel tar plattformar som Koder.ai samma princip—att förvandla avsikt till implementation—och går längre än UI-scaffolding: du kan beskriva funktioner i chatten, generera React-frontends med Go/PostgreSQL-backends (och Flutter för mobil), sedan iterera med planning mode, snapshots, rollback och export av källkod när det är dags att integrera med ett befintligt repo.
AI utmärker sig för:
Var försiktig med:
Behandla varje generation som ett utkast: granska output, notera återkommande problem (namngivning, saknade states, fel semantik), uppdatera din prompt/spec och designkonventioner. Efter några rundor förbättras kvaliteten mer än du skulle tro.
Innan du förpliktar dig, kör en liten pilot och poängsätt resultat på: trohet till layout, komponentåteranvändning, responsivitet, grundläggande tillgänglighet och tid för refaktorering. Om du jämför verktyg och planer, kontrollera /pricing.
Det är en AI-assisterad översättning från en visuell UI (Figma-ram, designexport eller skärmbild) till körbar UI-kod. Målet är ett stabilt första utkast—layout, stilrytm och grundstruktur—så att en utvecklare kan refaktorera det till tokens, komponenter och produktionsfärdig semantik.
Det översätter vanligtvis:
Pixlar kodar inte allt. Du måste oftast specificera eller tillhandahålla:
En skärmbild är det tunnaste ingångsvärdet: den innehåller färg och geometri men ingen explicit struktur (lager, constraints, komponenter). Förvänta dig mer gissningar, mer absolut positionering och mindre återanvändbar kod.
En Figma/Sketch-fil eller strukturerad export ger ramar, lagernamn, Auto Layout, constraints och stilar—signaler som hjälper verktyget att producera renare flex/grid-layouts och mer korrekta komponentgränser.
AI letar efter upprepad justering och konsekventa mellanrum för att uttrycka UI:t som flex/grid-regler. Om den hittar en tydlig spacing-rytm (t.ex. 8/16/24) kan den generera stabila staplar och rutnät.
Om avstånden är inkonsekventa eller element är något feljusterade faller modellen ofta tillbaka på absoluta koordinater för att bevara exakt utseende—på bekostnad av responsivitet.
Den söker visuella “omslutnings”-signaler:
Ren gruppering och konsekvent struktur i designverktyget (frames, Auto Layout) gör förälder-/barn-relationer mycket lättare att reproducera i kod.
Absolut positionering uppstår när relationer är otydliga—överlappningar, inkonsekventa avstånd, manuella justeringar eller oklara grupperingar. Det kan passa en skärmstorlek men bryter ofta vid:
Om du vill ha flexibelt output, låt designen bete sig som flex/grid via Auto Layout och constraints.
Den härleder hierarki från visuella ledtrådar:
När stilar skiljer sig med bara 1–2px eller hierarkin är otydlig kan modellen välja fel rubriknivå eller behandla rubriker som vanlig text.
AI gissar interaktivitet från UI-affordanser:
Om ett “kort” kan vara klickbart eller informativt, annotera eller visa en variant; annars kan modellen koppla fel beteende eller utelämna det.
Gör en snabb, strukturerad genomgång:
Behandla output som scaffolding, dokumentera antaganden så framtida generationer inte suddar ut dina beslut.