Softwarearkitektur i den agentiske tidsalder: Hvorfor struktur betyder alt nu

Vi befinder os midt i et skift, der ændrer fundamentalt på, hvordan vi bygger software. For bare et år siden var "agent-venlig arkitektur" et nichebegreb, de færreste bekymrede sig om. I dag? Det er ved at blive obligatorisk viden.

AI-assistenter til kodning har bevæget sig fra sjov nyhed til uundværligt værktøj. Og her opdager vi noget vigtigt: Disse agenter er kun så effektive, som den kodebase de arbejder med tillader det. Giv en AI et rodet kaos af spredte services, cirkulære afhængigheder og kryptiske navnekonventioner, og du bruger halvdelen af dagen på at rode rundt i fortidens fejl. Men giv den samme AI – eller en udvikler – en velorganiseret kodebase, hvor konteksten flyder naturligt? Det er, når magien opstår.

Her kommer vi til en arkitektur, der har vundet stille momentum: Polylith. Og ærligt talt er det et af de koncepter, der føles oplagte, så snart man forstår dem.

Hvad er Polylith egentlig?

Den korte version: Polylith handler om at få microservices-fordele med monorepo-simplicitet. Du får modularitet og isolation fra microservices, men holder alt i ét overskueligt repository.

Den grundlæggende idé er, at din kode består af byggeblokke – lidt som LEGO. Nogle er små og fokuserede, andre er større samlinger, men alle er designet til at klikke sammen problemfrit. I Polylith-terminologi kaldes disse blokke for bricks, og der findes to typer:

• Components: Kødet i din applikation. Forretningslogik, features, den egentlige funktionalitet bor her.
• Bases: Indgangspunkter til dine apps og services. Helst tynde – de delegerer til components i stedet for selv at indeholde logik.

Denne opdeling betyder noget, fordi den tvinger dig til at tænke over grænser tidligt. En base behøver ikke kende en components indre mekanismer; den ved bare, hvordan den skal kalde den. Rent, forudsigeligt og – vigtigt – let at navigere for både mennesker og AI-agenter.

Hvorfor agenter bekymrer sig om arkitektur

Her bliver det interessant fra et AI-udviklingsperspektiv.

Traditionelle microservices-arkitekturer introducerer kompleksitet, der kan stoppe selv de klogeste agenter:

• Kode spredt over flere repositories
• Duplikeret logik i forskellige services
• Delt kode udtrukket til biblioteker (som så skaber endnu flere repositories)
• Versionsuoverensstemmelser mellem afhængigheder

En agent, der prøver at forstå eller ændre sådan et system, må hoppe mellem repositories, finde ud af hvor funktionalitet bor, og udrede afhængigheder – alt sammen før den overhovedet har skrevet én linje brugbar kode. Det er kognitiv belastning, du ikke har brug for.

Polylith løser dette ved at holde alt ét sted. Konteksten er altid lige ved hånden. Agenter slipper for at navigere i et labyrint af forbundne repositories; hele billedet er tilgængeligt i én workspace. Det er ikke bare bekvemt for agenter – det er transformativt for deres effektivitet.

Værktøjerne der gør forskellen

Det, der gør Polylith særligt tiltalende, er dets værktøjsøkosystem. Gennemtænkt tooling håndhæver arkitekturens regler automatisk. Den advarer dig, når grænser krydses, markerer cirkulære afhængigheder og holder generelt din kodebase ærlig.

For Python-udviklere specifikt findes der tooling, der integrerer med de mest populære package managers – uv, poetry, pdm, pixi, hvad du end bruger. Der er endda indbygget support til agent skills, som i bund og grund lærer AI-assistenter at arbejde inden for Polylith-rammerne.

Det er en reel gevinst for prompt-effektiviteten. Når en AI-agent forstår arkitekturens konventioner gennem tooling, bruger du færre tokens på at forklare kontekst og flere tokens på at skabe værdi.

Hvad der ikke ændrer sig

Her er den beroligende del: Mange principper for god softwarearkitektur forbliver konstante, uanset om et menneske eller en AI læser koden.

Simpelt er bedre end komplekst. Klare grænser slår rodede afhængigheder. Kontekst betyder noget. Disse sandheder gjaldt før den agentiske æra, og de vil fortsætte med at gælde bagefter. Forskellen nu er, at vi er mere motiverede til faktisk at praktisere dem – fordi fordelene også gælder vores AI-assistenter.

Det store billede

Vi bevæger os ind i en era, hvor udvikling sker i samarbejde med AI. Det ændrer ligningen for arkitekturbeslutninger. Det handler ikke længere kun om developer experience – det handler også om agent experience.

Polylith er ikke det eneste svar på denne udfordring, men det er et interessant et, der adresserer begge sider elegant. Ved at prioritere simplicitet og kontekst skaber det en kodebase, der er en fornøjelse for mennesker at navigere og – i stigende grad – for agenter at arbejde i.

Hvis du bygger nye projekter eller overvejer at restrukturere eksisterende, er det værd at have denne samtale i tankerne. De værktøjer vi vælger – og de arkitekturbeslutninger vi træffer – vil forme, hvor effektivt vores AI-assistenter kan hjælpe os med at bygge.

Den agentiske era er ikke på vej; den er allerede her. Spørgsmålet er, om vores arkitekturer er klar til at møde den.

Har du fundet arkitekturmønstre, der fungerer særligt godt med AI-kodningsassistenter? Skriv gerne en kommentar – jeg er altid nysgerrig efter at høre, hvordan andre navigerer i dette skift.