De flesta mjukvaruutvecklare, tekniska ledare och DevOps-ingenjörer börjar sin karriär som byggare.

De bygger system, appar, komponenter, teman, mönster, moduler och pipelines. De optimerar layouter, löser udda specialfall, upprätthåller kompatibilitet och driver system framåt en commit i taget. Arbetet är precist, praktiskt och djupt tekniskt.

Men någon gång förskjuts något.

De bästa utövarna slutar inte bygga, men de börjar tänka i system.

Från byggare till systemtänkare

Skiftet: från resultat till regler

Som byggare ligger fokus på resultatet: komponenter, mallar, sidor, funktioner, bibliotek, applikationer.

Som systemtänkare flyttas fokus till reglerna: begränsningar, samspel, återkopplingsslingor.

I stället för att fråga "Hur ser den här komponenten ut?" ställer systemtänkare andra frågor: Vilka regler styr komponenten? Vad får samverka med den? Hur beter den sig när förutsättningarna ändras? Hur överlever intentionen över tid?

Det här skiftet leder naturligt mot agentbaserade system.

När design slutar vara statisk

Moderna designsystem rymmer redan logik: tokens definierar begränsningar, komponenter definierar struktur, mönster definierar beteende.

Ändå är de flesta system fortfarande beroende av omfattande mänsklig orkestrering.

AI-agenter introducerar en annan modell, där system kan upprätthålla sina egna regler, validera beslut löpande, reagera på sammanhang och samordna sig internt.

Här utvecklas design från dokumentation till körbar logik.

Vart det här är på väg

Fokus ligger nu på att förverkliga de här idéerna i verkliga, fungerande system, inte som experiment utan som grundstenar.

1. Djupare integration av AI-agenter med designverktyg (Figma)

Mot agentbaserade designsystem

Designverktyg ska inte vara passiva ritytor.

Målet är att integrera AI-agenter med Figma som förstår designtokens och komponentbegränsningar, validerar beslut i realtid, översätter designintention till regler på systemnivå och fungerar som medarbetare, inte som exportverktyg.

Det flyttar designen uppströms, dit intentionen bevaras i stället för att gissas i efterhand.

2. Skalbar hantering av AI-agenter

Mål: 150 agenter, en per komponent

I stället för en enda allmän AI går team mot många specialiserade agenter.

Varje komponent får sin egen agent med definierat ansvar, tydliga gränser och kännedom om närliggande komponenter.

Det speglar hur sunda system skalar: genom specialisering, samordning och tydliga kontrakt.

3. Agenter med verkliga färdigheter, verktyg och plugins

Agenter måste kunna agera.

Det innebär att utrusta dem med färdigheter (tillgänglighetsresonemang, designvalidering, prestandamedvetenhet), verktyg (linters, testkörare, design-API:er) och plugins (Storybook, Drupal, CI-pipelines, Figma-integrationer).

En agent utan verktyg är teoretisk. En agent med verktyg blir en del av själva systemet.

4. Smartare automatiserad funktionell acceptanstestning

AI-driven och medveten om intention

Traditionell testning kontrollerar resultatet. Agentdriven testning förstår beteendet.

Fokus ligger på AI-agenter som resonerar kring användarflöden, funktionella tester som förstår intention snarare än bara selektorer, system som utvecklar testerna i takt med komponenterna, och på att minska sköra tester samtidigt som den semantiska tilliten ökar.

Testning blir ännu ett lager av systemintelligens.

TDD och BDD i AI:ns tidsålder: varför AI-agenter kräver 100 % mer testdriven utveckling

Varför det här spelar roll

Team bygger system som överlever sina skapare, anpassar sig kontinuerligt och för långsiktiga designbeslut vidare.

I en sådan värld skalar inte manuell styrning. Men väldefinierade regler gör det.

Designers, utvecklare och AI-agenter måste verka inom samma logiska ramverk, ett gemensamt system av begränsningar och intention.

Övergången från byggare till systemtänkare handlar inte om att överge genomförandet. Det handlar om att se system som mer än samlingar av delar.

Nästa steg är att utforma de regler som gör att system kan resonera, anpassa sig och utvecklas.

Mjukvaruutvecklare, tekniska ledare och DevOps-ingenjörer som gör det här skiftet bygger inte bara, de bygger förutsättningarna för att system ska bygga sig själva.