De fleste softwareudviklere, tech leads og DevOps-ingeniører begynder deres karriere som bygmestre.

De bygger systemer, apps, komponenter, temaer, mønstre, moduler og pipelines. De optimerer layouts, løser grænsetilfælde, sikrer kompatibilitet og driver systemerne fremad, én commit ad gangen. Arbejdet er præcist, praktisk og dybt teknisk.

Men på et tidspunkt sker der noget.

De bedste udøvere holder ikke op med at bygge, men de begynder at tænke i systemer.

Fra bygmester til systemtænker

Skiftet: Fra resultat til regler

Som bygmester er fokus på resultatet: komponenter, skabeloner, sider, funktioner, biblioteker, applikationer.

Som systemtænker flytter fokus sig til reglerne: begrænsninger, samspil, feedback-loops.

I stedet for at spørge "Hvordan ser denne komponent ud?" stiller systemtænkere andre spørgsmål: Hvilke regler styrer komponenten? Hvad må interagere med den? Hvordan opfører den sig, når tingene ændrer sig? Hvordan overlever intentionen over tid?

Dette skift fører helt naturligt hen imod agentbaserede systemer.

Når design holder op med at være statisk

Moderne designsystemer rummer allerede logik: tokens definerer begrænsninger, komponenter definerer struktur, mønstre definerer adfærd.

Alligevel afhænger de fleste systemer stadig af omfattende menneskelig styring.

AI-agenter introducerer en anden model, hvor systemer kan håndhæve deres egne regler, validere beslutninger løbende, reagere på kontekst og koordinere internt.

Her udvikler design sig fra dokumentation til eksekverbar logik.

Hvor det er på vej hen

Fokus er nu at omsætte disse ideer til virkelige, fungerende systemer, ikke som eksperimenter, men som fundament.

1. Dybere integration af AI-agenter med designværktøjer (Figma)

Mod agentbaserede designsystemer

Designværktøjer bør ikke være passive lærreder.

Målet er at integrere AI-agenter med Figma, som forstår designtokens og komponentbegrænsninger, validerer beslutninger i realtid, oversætter designintention til regler på systemniveau og fungerer som samarbejdspartnere, ikke som eksportværktøjer.

Det flytter design opstrøms, hvor intentionen bevares i stedet for at blive gættet senere.

2. Skalerbar styring af AI-agenter

Mål: 150 agenter, én pr. komponent

I stedet for én universel AI går teams mod mange specialiserede agenter.

Hver komponent får sin egen agent med definerede ansvarsområder, klare grænser og kendskab til beslægtede komponenter.

Det afspejler, hvordan sunde systemer skalerer: gennem specialisering, koordinering og klare kontrakter.

3. Agenter med reelle færdigheder, værktøjer og plugins

Agenter skal kunne handle.

Det betyder, at de skal udstyres med færdigheder (tilgængelighedsvurdering, designvalidering, bevidsthed om ydeevne), værktøjer (linters, testkørere, design-API'er) og plugins (Storybook, Drupal, CI-pipelines, Figma-integrationer).

En agent uden værktøjer er teoretisk. En agent med værktøjer bliver en del af selve systemet.

4. Smartere automatiseret funktionel accepttest

AI-drevet og intentionsbevidst

Traditionel test kontrollerer resultatet. Agentdrevet test forstår adfærden.

Fokus er på AI-agenter, der kan ræsonnere om brugerrejser, funktionelle tests, der forstår intentionen frem for blot selektorer, systemer, der udvikler testene sammen med komponenterne, og på at reducere skrøbelige tests, samtidig med at den semantiske tillid øges.

Test bliver endnu et lag af systemets intelligens.

TDD og BDD i AI-æraen: Hvorfor AI-agenter kræver 100 % mere test-først-udvikling

Hvorfor det betyder noget

Teams bygger systemer, der overlever deres skabere, tilpasser sig løbende og bærer langsigtede designbeslutninger videre.

I en sådan verden skalerer manuel kontrol ikke. Men veldefinerede regler gør.

Designere, udviklere og AI-agenter må arbejde inden for den samme logiske ramme, ét fælles system af begrænsninger og intentioner.

Overgangen fra bygmester til systemtænker handler ikke om at opgive selve implementeringen. Den handler om at se systemer som mere end en samling dele.

Næste skridt er at udforme de regler, der gør det muligt for systemer at ræsonnere, tilpasse sig og udvikle sig.

Softwareudviklere, tech leads og DevOps-ingeniører, der tager dette skridt, bygger ikke bare, de bygger betingelserne for, at systemer kan bygge sig selv.