Hvordan AI ændrer software arkitektur (ikke som du tror)

Alle taler om hvordan AI kan skrive kode. Færre taler om hvordan AI fundamentalt ændrer måden vi designer software på.

Det handler ikke om at generere boilerplate hurtigere. Det handler om at opdage problemer, før de rammer produktion.

Den klassiske software-fælde

Traditionelt så processen sådan ud:

1. Du starter med at bygge det du tror du har brug for
2. Du rammer et edge case i produktion
3. Du fikser det med en hotfix
4. Repeat 50 gange
5. Nu har du technical debt

Det er sådan de fleste systemer bliver til. Ikke fordi udviklere er dårlige, men fordi det er umuligt at forudse alle edge cases alene.

AI som arkitektur-sparringspartner

Et konkret eksempel: Vi designede for nylig et billing-system. Udgangspunktet var simpelt - multi-tenant med seat-baseret fakturering.

Men vi ved af erfaring at simpelt hurtigt bliver komplekst. Så vi brugte AI til at stress-teste designet:

• "Hvad sker der hvis to brugere accepterer den sidste invitation samtidigt?" → FOR UPDATE locking
• "Hvordan sikrer vi at files slettes før user ved GDPR erasure?" → Køsystem med rækkefølge-garanti
• "Hvad hvis Stripe sender samme webhook to gange?" → Idempotency keys og claim-baseret processing

Resultat: En arkitektur-spec vi normalt ville have brugt uger på at modne - klar på timer.

Det er ikke fordi vi ikke kunne designe det selv. Det er fordi AI accelererer den kritiske tænkning der normalt kræver at ramme problemerne først.

Hvad AI faktisk gør

AI skriver ikke din kode for dig. Den:

1. Stiller de rigtige spørgsmål - "Hvad sker der hvis to brugere gør X samtidigt?"
2. Husker patterns du har glemt - "Du bør nok bruge SECURITY DEFINER her"
3. Tvinger dig til at tænke edge cases igennem - Før de koster dig kunder

Det er en accelerator for den kritiske tænkning vi alligevel ville have gjort - bare hurtigere og med færre blinde vinkler.

Toyota vs Rolls Royce

Med AI har du nu et valg:

Før AI:

• Du byggede hvad du kunne nå
• Edge cases opdagedes i produktion
• Technical debt var uundgåelig

Med AI:

• Du kan designe enterprise-grade arkitektur på timer
• Du ved hvordan en Rolls Royce ser ud
• Du vælger om du vil bygge en Toyota (og det er okay!)

Det vigtige er at valget er bevidst. Du kan sige "jeg ved godt at jeg ikke håndterer race conditions på seats - det fikser jeg når jeg har 100+ kunder". Før vidste du ikke engang at problemet eksisterede.

Praktisk eksempel: RPC vs REST

En klassisk arkitektur-diskussion. Med AI kan du nu:

Prompt: "Jeg overvejer RPC vs REST for mit billing-system. 
Hvad er trade-offs for sikkerhed og race conditions?"

AI vil forklare:

• Hvorfor REVOKE INSERT, UPDATE, DELETE FROM authenticated er smart
• Hvordan FOR UPDATE locking forhindrer seat-overselling
• Hvornår REST stadig er det rigtige valg

Det erstatter ikke erfaring - men det komprimerer den research og diskussion der normalt tager dage.

Begrænsninger

AI er ikke perfekt til arkitektur:

• Den hallucinerer - Verificer altid kritiske mønstre
• Den mangler kontekst - Den ved ikke hvordan din organisation fungerer
• Den kan overkill'e - Ikke alle systemer behøver enterprise-grade sikkerhed

Brug AI som sparringspartner, ikke som sandhed.

Konkret workflow

Her er hvordan vi bruger AI til arkitektur:

1. Start med problemet - "Jeg skal have multi-tenant billing"
2. Spørg om edge cases - "Hvad kan gå galt?"
3. Diskuter trade-offs - "Hvad er forskellen mellem Toyota og Rolls Royce versionen?"
4. Generer spec - Lad AI skrive den detaljerede plan
5. Review kritisk - Du træffer beslutningerne, ikke AI

Resultatet er arkitektur der ville have taget måneder at designe - på timer.

Konklusion

AI ændrer ikke software ved at skrive kode hurtigere. Den ændrer software ved at komprimere den modningsproces der normalt tager måneder.

Vi bruger AI til at stress-teste vores designs før de rammer produktion. Det er ikke en krykke - det er et professionelt værktøj, på linje med linters, type systems, og code review.

Forskellen er at nu kan vi levere arkitektur der er battle-tested fra dag ét.