AI-redo designsystem — design.md, AGENTS.md och kod som agenter kan läsa
Intunio bygger AI-redo designsystem för team som vill att Claude, Cursor och Copilot ska producera kod som ser ut som er produkt — inte som default-tailwind.
Intunio är en design- och utvecklingsstudio i Göteborg som bygger AI-redo designsystem för team där agenter (Claude Code, Cursor, Codex) skriver en stor del av gränssnittskoden. Vi levererar en `design.md`-spec, en `AGENTS.md`-instruktionsfil och en första uppsättning shadcn-baserade komponenter som ligger i ert repo, så att agenten har allt den behöver för att bygga enhetligt från första prompten.
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 enhetlighet
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 enhetlighet upprätthålls. En `design.md` ensam ger enhetlighet i färg och tokens, men inte i implementationen. 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 sin enhetlighet, ä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, ca 40 000–80 000 kr, 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, ca 80 000–160 000 kr, 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, ca 80 000–160 000 kr, 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, ca 40 000 kr/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 kostar ett AI-redo designsystem?
Ett AI-redo designsystem kostar från ca 40 000–80 000 kr för en produkt till ca 80 000–160 000 kr för en startup-stack eller konvertering; långsiktig förvaltning från ca 40 000 kr/månad. Allt räknas på timpriset 995 kr/h (vårt bästa pris, med Team retainer) — paketen ovan visar timmar och pris.
AI i vårt arbete
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å enhetligheten hålls även när tempot är högt och människor inte ser varje commit.
Relaterat innehåll
Tjänster
Insikter
Vanliga frågor
Intunio sitter i Göteborg, på Korsgatan 24 mitt i centrum. För kunder i Göteborg och Västsverige är närheten en viktig del av samarbetet. Workshops, avstämningar och informella möten sker ofta på plats hos er eller hos oss, vilket ger en kontinuitet som är svår att få till med rena remote-team. Det matchar också vår modell: vi blir en förlängning av ert team över längre tid, inte en extern leverantör.
Ja. Intunio har under hela vår tid haft löpande samarbeten med kunder i Sverige, Europa och Nordamerika. Vi har särskilt mycket erfarenhet av kunder i USA och Kanada, så arbete över tidszoner är en del av vardagen. För AI-redo designsystem fungerar remote-modellen särskilt bra eftersom hela leveransen är digital — vi behöver tillgång till ert repo och er Figma-fil om ni har en. Workshops och avstämningar görs på video, kompletterat med besök på plats där det är praktiskt och värdefullt.
Klassiskt designsystem är byggt för en värld där människor ritar i Figma och människor kodar mot ett npm-paket. AI-redo designsystem är packat så att en AI-agent kan läsa specen och agera direkt: tokens som YAML, komponenter som specifikationer, instruktioner i `AGENTS.md`. Båda bygger på samma grundprinciper (tokens, governance, enhetlighet), men paketformatet skiljer sig. Vi hjälper er välja vilken som passar baserat på er stack och hur stor del av koden som skrivs av agenter. Se vår klassiska designsystem-tjänst för den mer omfattande varianten.
`design.md` är en maskinläsbar specifikation av ett designsystem. Det innehåller typiskt ett YAML-block med tokens (färger, typografi, spacing) och komponentspecifikationer, plus prosatext med rationaler. Google Labs har publicerat en öppen specifikation och liknande ansatser dyker upp i verktyg som Claude och Google Stitch. Formatet är tidigt och kommer att utvecklas, men principen att en maskinläsbar spec ska kunna läsas direkt av en agent håller oavsett vilket exakt format som blir standard. Vi följer utvecklingen och migrerar er spec när det behövs.
`AGENTS.md` (eller `CLAUDE.md` för Claude Code) är en instruktionsfil som ligger i repot och som agenten läser i början av varje session. Den säger saker som "läs `design.md` först", "importera befintliga komponenter från `/components/ui`, skapa inte nya om de redan finns", "följ den här namngivningskonventionen". Utan den läser agenten visserligen `design.md` om den hittar den, men följer den inte konsekvent. Med den blir agenten en disciplinerad del av teamet i stället för ett verktyg som uppfinner saker varje gång.
Ja, vi använder shadcn/ui som utgångspunkt för React-baserade stackar. Anledningen är att shadcn-komponenter är källkod ni kopierar in i ert eget repo, inte ett installerat paket. Det betyder att ni äger koden, kan modifiera den efter era tokens, och att agenten har riktiga filer att referera till. För andra stackar (Vue, native iOS/Android, embedded) använder vi motsvarande mönster med era egna komponenter i repot. Vi är pragmatiska kring verktyg — vad som passar er stack väger tyngst.
Sannolikheten att det exakta `design.md`-formatet ändras är hög, eftersom det är tidigt och flera aktörer (Google Labs, Anthropic, andra) experimenterar med olika varianter. Det är därför vi alltid levererar med en tydlig token-pipeline (Figma → YAML) och inte hårdkodar er spec mot ett enda format. När formatet utvecklas migrerar vi specen, inte hela ert designsystem.
AI-redo för en produkt (40–80 timmar) kostar ca 40 000–80 000 kr, en startup-stack eller konvertering (80–160 timmar) ca 80 000–160 000 kr. Långsiktig förvaltning från 40 timmar/månad kostar ca 40 000 kr/månad. Allt räknat på timpriset 995 kr/h — vårt bästa pris, med Team retainer. Vi gör en exakt offert när scope är fastlagt.
Båda. Vi använder Claude, Cursor och Codex aktivt när vi skriver `design.md`, genererar komponentkod och iterar på `AGENTS.md`-instruktioner. Det innebär att vår leverans är snabbare och vi kan testa specen mot agenten i realtid medan vi bygger. det är vår expertkunskap som arbetar snabbare, inte AI som ersätter expertkunskapen.
Intunio Göteborg
Intunio är en design- och utvecklingsstudio baserad i Göteborg. Vi hjälper företag att skapa digitala produkter, appar och system som är enkla att använda och hållbara över tid.
Inom AI-redo designsystem packar vi tokens, komponenter och dokumentation så att AI-agenter kan agera direkt, alltid med fokus på vad ni har kontroll över i ert eget repo.
Vill ni ha ett designsystem som AI-agenter kan läsa?
Berätta vilket stack ni jobbar i och vad ni vill bygga, så föreslår vi ett upplägg.