Context engineering og coding agents: sådan får udviklingsteams reel værdi af AI

Overblik: Hvad skal dit udviklingsteam bruge AI-agenter til – og hvordan uden at miste kontrol?

Context engineering og coding agents kan forkorte udviklingscykler, lette trivielt arbejde og forbedre kvaliteten af kode – hvis de indføres med styr på kontekst, sikkerhed og måling. Nøglen er at se AI-agenter som kontrollerede teammedlemmer, ikke magiske assistenter.

For et udviklingsteam handler det om tre ting:

• At forstå forskellen på context engineering, coding agents og bredere agentic AI.
• At designe et konkret, sikkert workflow fra opgave til merge og rollback.
• At måle effekt på cycle time, fejlrate og leveringshastighed – ikke på hype.

Nedenfor folder vi det ud i en samlet model: begrebsafklaring, sikkerhedslag, praktisk workflow, KPI-ramme, beslutningskriterier og de første pilotprojekter.

Begreberne: context engineering, coding agents og agentic AI

Context engineering er disciplinen at strukturere, filtrere og prioritere den kontekst, en AI-model får, så output bliver mere relevant, stabilt og sikkert. En coding agent er en AI, der udfører kodningsopgaver nogenlunde selvstændigt inden for klare rammer. Agentic AI er den bredere idé om AI-systemer, der selv planlægger og udfører flere trin i et workflow.

Det er nyttigt at skille de tre ting ad, fordi de løser forskellige problemer:

• Context engineering forbedrer kvaliteten af alt AI-arbejde på kode, dokumentation og analyse.
• Coding agents automatiserer konkrete udvikleropgaver som generering, refaktorisering og tests.
• Agentic AI binder flere trin sammen til et mere autonomt flow, fx opgave → kode → test → deployment-forslag.

Enkle definitioner til teamet

Hvis du skal forklare forskellen til et team på fem minutter, kan du bruge denne korte model:

• Context engineering: At vælge og pakke den rigtige viden til modellen: relevant kode, arkitekturbeskrivelser, API-kontrakter, domænespecifikke regler, og at definere system-prompter og begrænsninger.
• Coding agent: En AI med adgang til repo, værktøjer (tool calling) og test, som kan foreslå eller udføre konkrete ændringer, fx oprette en feature-branch, lave en pull request eller skrive unit tests.
• Agentic AI: Et setup, hvor AI’en ikke bare skriver kode, men også foreslår plan, opdeler opgaven i delopgaver, kalder værktøjer og itererer, mens mennesker sætter mål og godkender milepæle.

Raw prompting vs. context engineering vs. coding agent

Pointen er, at du kan have stor gevinst alene ved bedre context engineering, selv før du åbner for mere autonome coding agents.

Sikker brug af coding agents i udviklingsteams

Coding agents bør kun bruges i udviklingsteams, når adgang, data, godkendelser og logging er designet ind fra start. Hvis agenten får for brede rettigheder, ufiltreret adgang til secrets eller kan skrive direkte til produktion, skaber den mere risiko end værdi.

Et sikkert setup handler om kendte sikkerhedsprincipper, oversat til AI-agenter og kodeflows:

• Begræns agentens rettigheder til det nødvendige repo, branch og miljø.
• Beskyt følsomme data og secrets, fx via separate vaults og masking.
• Kræv human in the loop ved ændringer, der går videre end testmiljø.
• Log altid agentens handlinger, så I kan revidere og rulle tilbage.

Typiske AI-specifikke risici i kodearbejde

Ud over klassiske sikkerhedsrisici møder udviklingsteams nye AI-specifikke trusler:

• Prompt injection: Eksterne eller interne kilder (fx README, logs) kan indeholde tekst, der forsøger at få agenten til at ignorere policies.
• Memory poisoning: Løbende “læring” eller cache af tidligere svar kan forurene agentens beslutningsgrundlag over tid.
• Goal manipulation: Agenten optimerer mod en for simpel målsætning (fx at få tests til at passere) og begynder at skrive tests, der gør koden “grøn” uden reel dækning.

Sikkerhed handler derfor ikke kun om netværk og kode, men også om, hvilke tekster agenten må stole på, og hvad den tror, at målet er.

En simpel model for sikker agent-drift

Et praktisk sikkerhedslag kan beskrives i seks trin:

1. Isolér: Kør agenten i et afgrænset miljø (sandbox) med begrænset adgang til repos, databaser og eksterne kilder.
2. Begræns: Brug IAM til at give snævre rettigheder: læseadgang bredt, skriveadgang til bestemte branches eller mapper.
3. Test: Kræv automatiske tests (unit, integration, sikkerhedstjek) for alle ændringer, agenten foreslår.
4. Overvåg: Log prompts, værktøjsopkald, filændringer og testresultater til et centralt audit trail.
5. Godkend: Brug pull requests som gate med menneskelig review, før noget merges til main eller deployes.
6. Deploy: Rul først ud til produktion, når ændringen både er testet, godkendt og kan rulles tilbage med en klar plan.

For mange virksomheder vil det give mening at koble dette til eksisterende sikkerhedspraksis og risikoniveau. Her kan det være nyttigt at genbesøge jeres overordnede sikkerhedsniveau, fx med principperne i it-sikkerhed i praksis og jeres AI-governance-setup.

Et konkret workflow: fra opgave til merge og rollback

Et sikkert workflow for coding agents i udvikling bør altid følge en fast kæde: opgavebeskrivelse, context pack, generering, review, test, merge og en klar rollback-plan. Det gør ændringerne sporbare og kontrollerbare, også når agenten udfører en stor del af arbejdet.

Nedenfor er et eksempel på et realistisk flow, som kan tilpasses jeres stack.

1. Task specification: Hvad er det egentlig, vi beder agenten om?

Start med en kort, præcis beskrivelse af opgaven, som både menneske og agent kan forstå:

• Hvilket system og modul?
• Hvilken funktionalitet skal laves, ændres eller fjernes?
• Hvilke ikke-funktionelle krav gælder (performance, sikkerhed, kompatibilitet)?
• Hvordan vurderes, at opgaven er løst (acceptkriterier, tests)?

Det kan være fristende at “snakke med agenten” i stedet, men en enkel task-spec skaber bedre output og lettere audit.

2. Context pack: Hvilken viden får agenten med?

Derefter samler I en context pack til opgaven. Det kan fx være:

• Relevante filer og mapper fra repoet.
• Arkitektur- og sekvensdiagrammer.
• API- og data contracts.
• Domænespecifikke regler og forretningslogik.
• Relaterede tickets eller tidligere implementeringer.

Her er det værd at genbruge principper fra god data-styring. En enkel praksis som data contracts, beskrevet i aftaler mellem teams om data, gør det lettere at udvælge sikre og korrekte kilder til context packs.

3. Permissions og tool calling

Inden agenten sættes i gang, skal dens rettigheder være eksplicitte:

• Hvilke repos og branches må den læse og skrive til?
• Må den oprette branches, commits og pull requests?
• Hvilke eksterne værktøjer (build, test, linters, sikkerhedsscannere) må den kalde?
• Har den nogen adgang til secrets, og hvis ja, hvordan er det kontrolleret?

Her er “mindste nødvendige rettighed” en god tommelfingerregel. Det er også her, at compliance-krav som NIS2 og EU AI Act i praksis skal oversættes til konkrete begrænsninger. Hvis jeres organisation er ved at operationalisere AI-lovgivning, kan en tilgang som i guiden til EU AI Act være et nyttigt supplement.

4. Generering og forslag fra agenten

Nu kan agenten:

• Foreslå en overordnet løsningsplan (arkitektur, ændringssteder, testplan).
• Generere eller ændre kode i en feature-branch.
• Oprette eller opdatere tests.
• Køre relevante automatiske checks.

Det er en god praksis, at agenten altid returnerer både en forklaring og konkrete ændringer, så reviewer kan forstå rationalet – ikke kun diffen.

5. Human review og merge gate

Alle ændringer, der går ud over trivielt arbejde, bør igennem normal review:

• Pull request med beskrivelse, link til task spec og oversigt over ændringer.
• Menneskelig review af arkitektur, kvalitet, sikkerhed og testdækning.
• Krav om, at tests er grønne, før merge til main.

Her er det vigtigt, at review ikke bliver en ren formalitet. Hvis teamet reelt ikke læser koden, fordi “agenten nok har styr på det”, forsvinder den sidste kontrol.

6. CI/CD, deploy og rollback-plan

Når koden er godkendt, kører den igennem CI/CD-pipelinen:

• Byg, tests og sikkerhedsscans kører som normalt.
• Deploy til staging, evt. med canary- eller blue/green-setup.
• Overvågning for fejl og performance-afvigelser.
• Klar rollback-plan (tag, ændrings-ID, automatiseret rollback-script).

Hvis noget går galt, skal I hurtigt kunne rulle ændringen tilbage uden at gætte jer frem til, hvad agenten har gjort. Derfor er traceability og versionsstyring afgørende.

Opsummering: Workflow, kontrol og risiko

Hvordan måler man værdien af coding agents i udvikling?

Værdien af coding agents måles bedst på cycle time, reviewtid, fejlrate og leveringshastighed – ikke på antal genererede linjer kode. Hvis I kun kigger på output-volumen, risikerer I at belønne mere, men dårligere kode.

En enkel fremgangsmåde er:

1. Vælg 3-6 KPI’er, der allerede giver mening for jeres udvikling (fx lead time for changes, change failure rate).
2. Mål baseline, før I indfører agenter.
3. Kør et afgrænset pilotprojekt med coding agents.
4. Mål de samme KPI’er igen og sammenlign – inklusiv kvalitets- og driftsmål.

Forslag til KPI-ramme

Nedenfor er et generisk KPI-framework, som kan tilpasses jeres kontekst:

De konkrete tal vil afhænge af jeres udgangspunkt, kodebase og hvor meget ansvar, I lægger over til agenterne. Pointen er ikke at ramme et “rigtigt” niveau, men at have en disciplineret før/efter-sammenligning.

Erfaringsmæssigt kan gevinster være betydelige. I praksiscases ses fx månedlige besparelser i størrelsesordenen sekscifrede beløb, dramatisk lavere pris per ticket og svartider, der går fra minutter til sekunder. Det er ikke garantier, men eksempler på, hvad et modent setup kan opnå. Vil du arbejde mere systematisk med KPI-logik, er det værd at se på, hvordan KPI’er kæder sig til forretning i fx artiklen om KPI-afhængigheder.

Output vs. outcome

Det er fristende at måle på det, der er nemt at trække ud af værktøjet. Men forretningsværdi ligger typisk i:

• Mere tid til komplekse opgaver og teknisk gæld.
• Hurtigere levering af features, som skaber omsætning.
• Lavere risiko ved releases gennem bedre tests.

Derfor bør jeres dashboard ikke bare vise “AI-aktivitet”, men bundte AI-initiativerne ind i de samme styringsrammer, I bruger til øvrige projekter. Her kan principperne i dashboards der ikke spilder nogens tid overføres direkte.

Hvornår giver coding agents mening – og hvornår skal mennesker eller klassisk automation tage over?

Coding agents er stærkest på afgrænsede, testbare og relativt lavrisiko-opgaver, mens mennesker bør tage over ved høj kompleksitet, store konsekvenser ved fejl eller svag mulighed for rollback. Enkel, deterministisk logik kan ofte løses bedre med klassisk automation end med AI.

Praktisk triage-model

Du kan bruge følgende tommelfingerregler, når opgaver fordeles:

• Brug coding agent til:
  • Gentagne ændringer på tværs af mange filer (fx API-versionering, logging-standardisering).
  • Generering af boilerplate-kode og tests, hvor kvalitet kan tjekkes automatisk.
  • Refaktoreringer, hvor før/efter-adfærd er veldokumenteret.
  • Migrationer, hvor datamønstre er konsistente og lette at validere.
• Brug menneskelig udvikler til:
  • Arkitekturændringer og valg af nye teknologier.
  • Komplekse domænebeslutninger, hvor krav er uklare eller foranderlige.
  • Sikkerhedsrelateret kode, kryptografi og adgangskontrol.
  • Opgaver med høj konsekvens ved fejl og lav reversibilitet.
• Brug klassisk automation til:
  • Simple, gentagne processer med klare regler (build-scripts, formattering, statisk analyse).
  • Integrationer, hvor input og output kan beskrives deterministisk.

Hvis en opgave ikke kan formuleres klart, testes automatisk eller rulles tilbage uden større skade, er det sjældent et godt sted at starte med agenter.

Værktøjer, platforme og arkitekturmønstre

Den bedste platform til coding agents afhænger af jeres datakrav, governance, eksisterende stack og ønskede kontrolniveau. Der findes ikke ét rigtigt valg – men der er klare trade-offs mellem enterprise-økosystemer, egen cloud og hybride setups.

Tre typiske tilgange

• Managed enterprise-stack (fx Microsoft 365, Azure AI, Copilot Studio, Power Platform, Dynamics 365)
  • Fordele: Tæt integration med eksisterende værktøjer, indbyggede governance- og compliance-funktioner, hurtigere time-to-value.
  • Ulemper: Vendor lock-in, begrænset fleksibilitet i arkitekturen, afhængighed af udbyderens roadmap.
  • Egnet til: Organisationer, der i forvejen er tungt på Microsoft og vil accelerere inden for en kendt ramme.
• Egen cloud-stack (fx egen Azure-, AWS- eller GCP-opsætning med valgfri LLM)

• Fordele: Høj kontrol over data, mulighed for at skifte eller kombinere LLM’er, fleksibel integration med eksisterende systemer.
• Ulemper: Større ansvar for sikkerhed, drift og modelvalg; kræver stærkere in-house-kompetencer.
• Egnet til: Virksomheder med høje sikkerhedskrav, særligt regulatorisk pres eller behov for specialtilpassede løsninger.

• Hybrid-setup (enterprise-værktøjer + egen backend)

• Fordele: Kan kombinere hurtig adgang til brugerflader med mere kontrolleret databehandling og modelkald i egen infrastruktur.
• Ulemper: Mere kompleks arkitektur og governance; kræver klare snitflader og ansvar.
• Egnet til: Organisationer, der vil starte i et kendt økosystem, men gradvist flytte kernefunktioner over i egen stack.

Uanset valg bør I være mere skeptiske over for demoer end forretningscases. Mange platforme ser imponerende ud i et kontrolleret miljø, men falder igennem på drift, sporbarhed eller kontrakter. Erfaringer som dem i artiklen om ikke at stole på AI-demos er værd at have i baghovedet under leverandørvalg.

Typiske fejl, risici og governance-huller i AI til udvikling

De største risici ved coding agents i udvikling er for brede rettigheder, manglende kontrol af data og secrets, uklar ansvarskæde og output, der ikke kan auditeres. De fleste problemer opstår ikke i modellen, men i den måde, organisationen har sat rammen op.

Tekniske fejl

• Ingen grænser for adgang: Agenten har skriveadgang til hele repoet eller flere tjenester, den ikke burde røre ved.
• Secrets i prompt eller context: API-nøgler, adgangskoder og andre følsomme oplysninger indgår utilsigtet i input.
• Manglende eval-harness: Der findes ingen automatiseret test- eller evalueringsramme, der kan afsløre, når agenten begynder at præstere dårligere.

Organisatoriske huller

• Uklar ownership: Ingen ejer den overordnede agent-arkitektur, og ingen har ansvar for at reagere, når noget går galt.
• Ingen tydelig policy: Teams ved ikke, hvilke opgaver agenter må og ikke må bruges til.
• Mangel på incident-procedurer: Hvis agenten ruller fejlagtig kode ud, er der ingen klar proces for håndtering og læring.

Det meste kan afhjælpes med et pragmatisk governance-setup, hvor I kun bygger den styring, I faktisk har brug for. Til inspiration kan du se, hvordan det kan gribes an i artiklen om AI-styringsniveauer.

Fra pilot til produktion: sådan kommer I i gang uden at drukne i eksperimenter

Et godt pilotprojekt med coding agents er smalt, målbart, reversibelt og designet til at bevise både sikkerhed og effekt, før I skalerer. Bredt definerede “AI-satsninger” ender ofte som spredte eksperimenter uden varig værdi.

Sådan kan et pilotforløb se ud

1. Vælg en velegnet use case
   • Gentagelig opgave med moderat kompleksitet, fx generering af tests til et velafgrænset service-lag.
   • Lav til middel risiko, hvor rollback er relativt enkel.
   • Tilstedeværelse af gode data og klare acceptkriterier.
2. Sæt baseline og mål
   • Mål nuværende cycle time, reviewtid og fejlrate for de valgte opgaver.
   • Definér, hvad der skal til, for at piloten er en succes (fx 20-30 % hurtigere uden flere fejl).
3. Definér sikkerhedsrammer
   • Hvilke repos og miljøer må agenten arbejde i?
   • Hvilke data må bruges i context packs?
   • Hvem godkender, før noget merges eller deployes?
4. Kør piloten i en afgrænset periode
   • Hold fokus på få teams og en eller to use cases.
   • Justér løbende prompts, context packs og værktøjskald.
5. Evaluer og beslut skalering
   • Sammenlign KPI’er før/efter, både for hastighed og kvalitet.
   • Identificér nye risici eller governance-behov, som dukkede op.
   • Beslut om use casen skal skaleres, justeres eller lukkes.

Det kan være nyttigt at tænke pilotforløbet ind i jeres eksisterende roadmap- og innovationsproces, så AI-agenter ikke bliver et sideløbende eksperiment, men en del af den samlede eksekvering. Her kan metoderne i artiklen om roadmapping ofte genbruges direkte.

Konklusion: AI-agenter som kontrollerede teammedlemmer – ikke magiske genveje

Coding agents og god context engineering kan løfte et udviklingsteams kapacitet markant, men kun hvis tre ting er på plads:

• Klare begreber og roller: Hvad skal agenten, og hvad skal menneskene?
• Et konkret workflow med kontrolpunkter: task spec, context pack, review, test og rollback.
• Systematisk måling: realistiske KPI’er, baseline og ansvar for at følge op.

Ser du AI-agenter som ekstra hænder, der skal styres ligeså disciplineret som resten af jeres udviklingsproces, er sandsynligheden for reel værdi langt større – og risikoen tilsvarende lavere.