Vår utgångspunkt är många års erfarenhet av token-baserade designsystem hos Emerson, Electrolux och andra industrikunder, omformulerat för en värld där koden inte längre nödvändigtvis skrivs av en människa. Tokens är fortfarande source of truth. Komponenter finns fortfarande. Skillnaden ligger i hur designsystemet packas så att en agent kan läsa och agera på det utan plugin, export eller överlämning.

> Läs vår artikel som ligger till grund för det här arbetet: .md – en ny standard för designsystem?

När behöver ert team ett AI-redo designsystem?

För team där det mesta byggdes av människor som hade systemet i Figma räcker en klassisk uppsättning. Men när agenter börjar skriva koden ändras spelplanen. Tre situationer där det här är akut:

När en stor del av gränssnittskoden skrivs av Claude Code, Cursor eller Codex. Agenten har inget minne mellan sessioner. Utan ett designsystem som ligger som fil i repot uppfinner den lösningar på nytt varje gång — samma färg används i tre nyanser, samma dropdown implementeras tre gånger med olika ARIA-attribut, samma typografi inkonsekvent.

När ni bygger en ny produkt med agent-driven utveckling från start. En tidig MVP byggd med Lovable eller Cursor saknar typiskt struktur runt design. Att lägga in ett AI-redo designsystem tidigt är billigt. Att städa upp efteråt är dyrt.

När ert befintliga designsystem inte är agent-läsbart. Tokens ligger i Figma-variabler bakom en plugin, dokumentationen i Supernova, komponenterna i ett npm-paket. Allt fungerar för människor men inget är direkt läsbart för agenten. Resultatet: agenten ignorerar systemet och bygger eget.

I alla tre fallen är problemet samma: ett designsystem som inte går att läsa av en agent kommer kännas lika begränsat som ett designsystem som inte går att läsa av en utvecklare.

Vad vi gör

• `design.md`-spec: tokens (färg, typografi, radius, spacing, motion) som YAML, plus komponentspecifikationer (en primär knapp har en bestämd bakgrundsfärg, hörnradie och padding) och prosatext med rationaler

• `AGENTS.md` / `CLAUDE.md`-instruktioner: filen som säger till agenten "läs design.md först, importera befintliga komponenter, skapa inte nya om de redan finns, följ namngivningskonventioner"

• Första uppsättningen shadcn-baserade komponenter: vi sätter upp grunduppsättningen (knappar, formulärfält, dropdown, modal, navigation) i er stack med rätt tokens, rätt accessibility och rätt prop-modell, så att agenten har riktiga referenser att importera från

• Token-pipeline från Figma till `design.md`: när designern ändrar en färg i Figma kan vi exportera till YAML automatiskt, så grunden hålls i synk

• Konsistensmodell över sessioner: tre lager som hänger ihop. Tokens som source of truth, fil i repot (inte i agentens minne), och en instruktionsfil som leder agenten till befintliga komponenter

• Iteration när formatet utvecklas: Google Labs design.md är tidig, konkurrerande format kommer. Vi följer skiftet och migrerar er spec när det behövs

Vanliga målgrupper är startups, AI-tunga produktteam, och team som migrerar från Lovable/Cursor-MVP till en mer strukturerad utvecklingsfas.

Inte bara ett nytt format — ett annat sätt att tänka konsistens

På Intunio ser vi `design.md` som en naturlig förlängning av token-arbete vi gjort i flera år. Det är inte ett brott mot hur designsystem byggs; det är samma principer packade så att en agent kan agera direkt.

Det som verkligen ändras är hur konsistens upprätthålls. En `design.md` ensam ger färg- och token-konsistens, men inte implementationskonsistens. Utan rätt struktur runt den får ni samma tertiära färg på knappar i hela produkten, men tio olika dropdown-implementationer. Det är därför vi alltid levererar tre lager tillsammans: spec, AGENTS-fil och en första uppsättning komponenter i ert repo. Utan det andra lagret tappar designsystemet konsistens, även om färgerna stämmer.

Är det här rätt tjänst för oss?

Den här tjänsten passar när agenter skriver en stor del av koden, när tempot är högt, och när ni vill ha en lättviktig modell utan tunga governance-processer.

För industriella produktfamiljer, flera produkter och team, långa livscykler eller tunga compliance-krav är vår klassiska designsystem-tjänst bättre lämpad. Den ger en mogen plattform med Figma + kodbas + Supernova-dokumentation, governance och versioning, byggd för att överleva ett byte av designteam eller en organisationsförändring.

De två tjänsterna utesluter inte varandra. Många kunder börjar AI-redo och växer in i en klassisk modell när organisationen och produktportföljen kräver det.

Hur vi jobbar i ett AI-redo uppdrag

Tre faser som vi typiskt levererar på två till fyra veckor:

Inventering. Vi tittar på er stack (Next.js, Vue, native, embedded), er nuvarande design (Figma-fil eller produktscreenshots) och vilka agenter ni använder. Resultatet är ett scope för vad spec och första komponenter ska täcka.

Spec och första komponenter. Vi skriver `design.md` med tokens och komponentspecifikationer, sätter upp shadcn-style komponenter i er stack och skapar `AGENTS.md` som leder agenten rätt. Vi kopplar in er Figma-fil om ni har en, så att designerna kan fortsätta jobba visuellt i Figma medan agenten arbetar mot specen.

Validering med agent. Vi kör några riktiga prompts mot er stack och justerar spec, instruktionsfil och komponenter där agenten missförstår. Resultatet är ett designsystem som faktiskt fungerar i ert flöde, inte bara på papper.

För kunder som vill fortsätta efter första leveransen går vi över i löpande månadssamarbete för att underhålla spec, lägga till komponenter när nya behov dyker upp, och migrera till nya format när Google Labs eller andra publicerar uppdateringar.

Vad vi erbjuder

AI-redo designsystem är en mycket lättare tjänst än ett klassiskt designsystem. Fyra vanliga upplägg:

• AI-redo för en produkt (40–80 timmar, leveranstid 1–2 veckor): `design.md`-spec, `AGENTS.md` och 8–12 grundkomponenter i er stack. Bra för en startup med en produkt som vill ha struktur från start.

• AI-redo för en startup-stack (80–160 timmar, leveranstid 2–4 veckor): full `design.md` med fler komponentspecifikationer, integration mot er Figma-fil om ni har en, fördjupad `AGENTS.md` med regler per mapp i repot, och 15–25 komponenter. Bra för team med flera produkter eller en mer komplex stack.

• Konvertering: klassiskt → AI-redo (80–160 timmar, leveranstid 2–4 veckor): ni har ett klassiskt designsystem som inte är agent-läsbart. Vi extraherar tokens till YAML, översätter komponentbiblioteket till spec-form, och kompletterar med `AGENTS.md`. Bra när ni vill att agenter ska kunna arbeta mot ett befintligt system.

• Långsiktig förvaltning (rullande månadssamarbete, från 40 timmar/månad): nya komponenter, justeringar i specen, migration till nya format när de mognar, support till team som använder systemet. Lättare förvaltning än klassiska designsystem eftersom det mesta arbetet görs av agenten. Vi sätter och justerar grunden.

För team som ska bygga eller bygga om en produkt parallellt med systemet bygger vi in det direkt i apputveckling eller produktvalidering-uppdraget. Ofta är det här naturligt steg två efter en validering av en Lovable/Cursor-byggd MVP.

Vad det kostar

995 kr/timme (rabatterat pris vid månadsavtal).

Vi tillämpar ett rabatterat timpris för månadsavtal: ni betalar månadens estimerade kostnad i förväg, och får ett pris ni kan räkna med. Ingen bindningstid, det löper månad för månad. För AI-redo designsystem är antalet timmar lägre än för klassiska designsystem, så månadskostnaden landar typiskt under 50 000 kr även för de större paketen.

AI-verktyg ingår i taxan. Vi använder Claude, Cursor och Codex för att skriva och iterera på spec, generera komponentkod och testa AGENTS-instruktioner. Det är vår expertkunskap som arbetar snabbare.

Vanliga startpunkter

Tre typiska tillfällen då en konversation med Intunio blir relevant:

När en Lovable- eller Cursor-byggd MVP behöver struktur. Produkten finns men koden är spretig, samma komponenter implementeras olika på olika ställen, och nya features bara ökar inkonsekvensen. AI-redo designsystem ger agenten en gemensam grund att arbeta mot framåt.

När ert team börjar använda Claude Code eller Cursor på allvar. Ni märker att utan struktur uppfinner agenten samma sak om och om igen. Vi sätter en första `design.md` och `AGENTS.md` så att nästa session börjar i rätt läge.

När ert befintliga designsystem inte är agent-läsbart. Tokens i Figma-variabler, dokumentation i Supernova, komponenter i npm-paket. Allt funkar för människor men inget för agenten. Vi konverterar till AI-redo format utan att kasta något av det ni byggt.

I alla tre fallen är resultatet detsamma: ett designsystem som agenten faktiskt läser och följer, så konsistens hålls även när tempot är högt och människor inte ser varje commit.