AI har ændret måden, vi bygger software på. Ikke ved at erstatte udviklere og arkitekter, men ved at ændre, hvad de bruger deres tid på.
Fra vores perspektiv hos Immeo er det et af de mest grundlæggende skift, vi har set i softwareudvikling i mange år.
Det er også et skift, der er let at misforstå. For når AI kan skrive kode hurtigere, kan det ligne en historie om automatisering. I praksis er det mindst lige så meget en historie om styring. Værdien ligger ikke i, at der bliver produceret mere kode. Værdien ligger i, at de rigtige mennesker kan bruge mere tid på de beslutninger, der former løsningens kvalitet, levetid og forretningsværdi.
Den traditionelle rolle som softwareudvikler har i årtier handlet om at oversætte krav til kode. Forstå problemet, designe løsningen, skrive implementeringen, teste og levere. Det er stadig en krævende disciplin. Men opgavefordelingen er under forandring.
Mange af de opgaver, der tidligere fyldte en stor del af en udviklers dag, som rutinepræget implementering og debugging af kendte mønstre, kan AI i dag håndtere, hvis den får de rette rammer. Det frigiver tid til det, der fortsat kræver erfaring, kontekst og dømmekraft: arkitektur, prioritering, review, afvejninger og forståelse for den forretning, løsningen skal understøtte.
Det betyder ikke, at udvikleren bliver mindre vigtig. Det betyder, at rollen bliver skarpere. Når AI løfter mere af implementeringen, bliver kvaliteten af retningen mere afgørende.
Vibe coding er en tilgang, hvor man beder AI om at bygge software ved at beskrive, hvad man gerne vil have - og så accepterer output uden systematisk at forstå, reviewe eller styre, hvad AI'en faktisk producerer. Det kan give hurtige resultater i prototype-fasen, men fører typisk til kode, der er svær at vedligeholde, teste og bygge videre på. Betegnelsen bruges i branchen om AI-assisteret udvikling, der prioriterer hastighed over faglig kontrol.
Der er stor forskel på at bruge AI som et avanceret autocomplete-værktøj og at bruge den som en udviklingsagent, der arbejder selvstændigt med konkrete opgaver. Det første gør den enkelte udvikler hurtigere. Det andet ændrer selve arbejdsprocessen.
Hos Immeo bruger vi AI-agenter som en fast del af vores udviklingspraksis. I et givent projekt holder vi os typisk til én primær kodeagent for at sikre konsistens i arbejdsmetoden, men vi vælger ikke værktøj dogmatisk. Det afgørende er ikke, hvilken agent vi vælger. Det afgørende er de rammer, den arbejder indenfor.
Agenten arbejder direkte i de systemer, teamet allerede bruger, som projektboard, repository og dokumentation. Den læser opgaver, implementerer, tester og rapporterer fremdrift. I praksis betyder det, at agenten arbejder i de samme arbejdsgange, som teamet allerede bruger, hvad enten det er Azure DevOps, Jira eller GitHub-baserede setup. Vores udviklere og arkitekter styrer retningen og reviewer leverancerne, men bruger mindre tid på at skrive koden linje for linje.
Det flytter indsatsen fra mekanisk produktion til faglig styring. Vi bruger mere tid på arkitekturens retning, integrationsmønstre, kvalitetssikring og de beslutninger, der har konsekvenser længe efter den første release.
Samtidig giver det en mere transparent arbejdsform. Når agenten arbejder i de samme systemer som resten af teamet, bliver fremdrift og beslutninger mere synlige. Det er ikke en black box. Det er en arbejdsproces, der kan følges, vurderes og styres.
Det vigtigste, vi har lært om AI i softwareudvikling, er dette: AI uden kompas producerer kode, men ikke nødvendigvis den rigtige kode, på den rigtige måde, med den rette kvalitet. AI er kun så god som de rammer, den får.
Det har en praktisk konsekvens. Uden eksplicitte rammer tager AI'en sine egne arkitekturelle beslutninger undervejs. Hvert svar kan virke fornuftigt isoleret set, men over tid opstår der arkitektonisk drift: en kodebase, der langsomt fragmenterer, fordi lokale valg ikke samler sig til en helhed.
Derfor arbejder vi bevidst med skills: strukturerede acceleratorer, der gør vores best practices, arkitekturprincipper og kodestandarder eksplicitte i en form, agenten kan arbejde direkte ud fra. Det er ikke proces for processens skyld. Det er en måde at sætte erfaring i system på, så AI'en arbejder ud fra det samme faglige fundament som teamet.
Principper, mønstre og afhængighedsretninger
Standarder, konventioner, teststruktur og fejlhåndtering
Krav til validering, adgang, hemmeligheder og sporbarhed
Mønstre for API-design, events, idempotens (at gentagne kald altid giver samme resultat) og fejlisolering
Det gør en reel forskel. Output bliver mere ensartet. Nye opgaver starter ikke fra nul. Og implicit viden bliver gjort eksplicit og genanvendelig på tværs af projekter, udviklere og værktøjer.
Vi lægger os bevidst op ad etablerede standarder og genbruger eksisterende skills og integrationsmønstre, når det giver mening. Vi bygger kun vores egne, når der er en reel Immeo-specifik grund til det. Den disciplin er vigtig, fordi AI-assisteret udvikling hurtigt bliver svær at styre, hvis hvert projekt opfinder sin egen metode undervejs.
At reviewe AI-genereret kode er ikke det samme som at reviewe kode skrevet af en kollega. Mængden er større, hastigheden højere og fejlmønstrene anderledes.
AI-genereret kode fejler sjældent syntaktisk. Den fejler oftere på semantisk korrekthed, på arkitektonisk konsistens og på edge cases, der ikke er beskrevet tydeligt i opgaven. Den kan levere noget, der ser plausibelt ud, og som måske endda virker lokalt, uden at passe ordentligt ind i løsningen som helhed.
Derfor arbejder vi i praksis med to reviewlag. Det funktionelle review handler om, om løsningen faktisk gør det, den skal, og om tests og kantsager er dækket. Det arkitektoniske review handler om, om implementeringen følger de mønstre og principper, vi har valgt, og om den understøtter den langsigtede struktur frem for at udhule den.
Det andet lag kan ikke delegeres til AI. Det kræver teknisk dømmekraft og arkitektonisk sans. Netop derfor bliver senioritet og faglig disciplin vigtigere, ikke mindre, i en AI-assisteret udviklingsproces.
Det udelukker ikke, at selve reviewprocessen kan assisteres af AI. Man kan bruge AI til at fremhæve afvigelser fra etablerede mønstre, pege på ubehandlede fejlscenarier eller sammenligne en implementering med eksisterende konventioner i kodebasen. Men det er stadig udvikleren eller arkitekten, der læser, vurderer og tager stilling. AI kan understøtte blikket – den kan ikke erstatte det.
Ikke alle AI-agenter er bygget til det samme. Vores primære kodeagenter, som Claude Code, Codex, Cursor og GitHub Copilot, er stærke til at arbejde bredt og vedvarende i en kodebase. Men til mere afgrænsede opgaver kan en specialiseret agent give bedre resultater. Til hurtig UI-generering er v0 fra Vercel eller Lovable.ai eksempler på agenter, der er bygget præcis til det formål, og som kan supplere i de faser af projektet, hvor det giver mening.
Det vigtige er ikke, at alt skal gennem ét værktøj. Det vigtige er, at valget er bevidst. Den agent, vi bruger til opgaven, skal passe til formålet og kunne arbejde inden for de rammer, vi har etableret. Ellers får man hastighed uden styrbarhed.
En AI-assisteret udviklingsproces fungerer ikke af sig selv. På flere punkter stiller den faktisk højere krav til teamet end en traditionel tilgang.
For det første kræver det stærkere arkitektonisk sans. Gode beslutninger om struktur, mønstre og afhængigheder skalerer hurtigt, når AI implementerer inden for dem. Det gør dårlige beslutninger også.
For det andet kræver det skarpere opgavedefinition. AI tager ikke fat i telefonen, når en task er uklar. Den udfylder hullerne med sine egne antagelser. Derfor skal krav, opgavenedbrydning og acceptkriterier være tydeligere end før.
For det tredje kræver det løbende vedligehold af de rammer, man arbejder med. Skills er ikke noget, man sætter op én gang. Teknologier, standarder og teams udvikler sig. Hvis rammerne ikke følger med, begynder AI'en at arbejde ud fra forældede antagelser.
For det fjerde kræver det eksplicit vidensforvaltning. Best practices, principper og beslutninger skal gøres tydelige og delbare, så både mennesker og agenter kan bruge dem konsekvent. Det er en investering, men det er også dér, en stor del af skalaeffekten kommer fra.
For kunderne er det centrale spørgsmål ikke, om vi skriver mere eller mindre kode. Det centrale spørgsmål er, om vi leverer mere værdi og mere robusthed for den samme investering.
Det korte svar er ja. I får mere for den samme investering, fordi vi flytter vores indsats fra rutinepræget implementering til arkitektur, integrationer, kvalitetssikring og tekniske valg med lang levetid. Det giver jer mere af den faglighed, der faktisk reducerer risiko og øger løsningens holdbarhed.
I får også højere transparens. Tæt integration med projektboard og repository har allerede længe været en vigtig del af vores arbejdsform. Når agenten arbejder i de samme systemer, som teamet og kunden allerede følger, bliver fremdrift, opgaver og leverancer synlige som en naturlig del af arbejdet og kræver ikke særskilte statusmøder at afdække.
Og I får mulighed for at afprøve idéer tidligere i forløbet, mens det stadig er billigt at justere retning. Det gør det lettere at lære hurtigt uden at sætte kvaliteten over styr.
