
Dansk hostet AI-platform
9. JUNI 2026 · ONLINE
Mange danske organisationer vil gerne i gang med at bruge AI. Men hvordan gør man det uden at sende følsomme data til udenlandske tech-giganter? Prøv vores AI-platform.
Få indblik i, hvordan du klæder dine udviklere på og tilpasser udviklingsprocesser
Vores eksperter har gennem længere tid arbejdet intensivt med området og giver i dette webinar et aktuelt indblik i, hvordan du klæder dine udviklere på til AI-drevet udvikling, samt hvilke forandringer det medfører for udviklingsprocessen.
Webinaret henvender sig til beslutningstagere, der ønsker at forstå, hvordan AI konkret ændrer udviklingsprocesser og værktøjer – og hvad man bør prioritere lige nu.
Vi bruger mange forskellige værktøjer. Claude Code er vores standardvalg lige nu, men vi benytter også OpenCode, lokale modeller m.m.
Vi bruger mange forskellige værktøjer. Claude Code er vores standardvalg lige nu, men vi benytter også OpenCode, lokale modeller m.m. – og en del andet.
Vi bruger flere værktøjer, men vores standardvalg lige nu er Claude Code.
Som vi ser det lige nu, tror vi stadig på, at kode skal skrives af folk, der kan skrive kode. Hvis man ved, hvad man bygger, og hvilke værktøjer man bør bruge osv., får man også en langt bedre kvalitet.
Lige nu er vores udgangspunkt, at den, der laver koden ved hjælp af AI, også ejer koden. Så vi kvalitetssikrer gennem grundige reviews og den sædvanlige stolthed, vores udviklere har i deres arbejde. Man sender ikke noget videre til review, før man selv synes, koden er god nok. AI hjælper os også meget med at skrive unit tests, integrationstests, test pipelines m.m. Men testkode skal selvfølgelig også reviewes.
Derudover har vi fokus på CRA og er med i standardiseringsprocessen omkring CRA-standarderne. Vi har processer omkring sikkerhed og kodekvalitet, og vi er ved at opdatere dem både i forhold til CRA og brugen af AI.
Vi bruger GitHub Copilot, Claude Code og OpenCode. Lige nu er Claude vores standardvalg, men alle er frie til at vælge det værktøj, de helst vil bruge. Vi håber, at OpenCode på sigt kan indhente Claude, så vi i højere grad selv kan styre stakken, men lige nu bruger vi dem alle. Vi eksperimenterer også med lokale modeller gennem OpenCode osv.
Med vores nuværende setup løber vi meget sjældent tør. Men vi er også indstillet på, at man gerne må gå over lige nu, og så betaler vi bare for det “overflow”.
Særligt når en PR vokser, kan den være svær at overskue, og man bliver hurtigt fartblind. Derfor er vi også ved at finde ud af, hvad der faktisk er vigtigst at fokusere på i reviews. Vi bruger også AI til at forbedre koden før, under og efter PR. Men vi har stadig stort fokus på, at vi som udviklere skal forstå, hvad der sker i koden.
Hvis du kan leve med software, hvor du kun ved, at det virker udadtil, så kan du godt udvikle på den måde. Man kan begynde at se noget software som “brug og smid væk”, og for nogle små værktøjer kan det sikkert være fint. Men hvis du vil kunne stå inde for korrekthed, sikkerhed osv., så bør der stadig være mennesker inde over.
Det er stadig meget svært at vurdere speed-up-faktoren, så det er noget, vi er ved at finde ud af. Vores mavefornemmelse er, at et almindeligt workflow går 2–3 gange hurtigere, og at prototyper går markant hurtigere. Vi oplever også nogle gange, at scope bliver lidt større, og at vi kan levere ekstra ting som højere test coverage og bedre tilgængelighed inden for de samme rammer.
Det rykker sig hele tiden, hvordan vi fastholder specifikationer over for AI-agenterne. I starten skrev vi sammen med AI lange kravspecifikationer i .md-dokumenter, som vi gemte sammen med koden. Det er vi gået væk fra, fordi for meget information nogle gange bare “forstyrrer” billedet, når kontekstvinduet bliver fyldt op. Værktøjerne er i dag virkelig gode til selv at søge rundt i og forstå koden, så det læner vi os gerne op ad frem for at have lange specifikationsdokumenter liggende i kodebasen.
Det afhænger lidt af projektet. I mindre projekter kan man godt køre det som en række Markdown-filer i repoet, mens vi i større projekter arbejder med user stories i fx Jira. Generelt er det en god idé at holde issues afgrænsede for at bevare overblikket – også i forhold til reviews.
For os var det lidt en øvelse i at se, hvor langt vi kunne nå med ren AI-dreven udvikling. Derfor satte vi kun ganske få timer af til det og var klar til at skifte til et købesystem, hvis vi ikke kunne nå at få et fungerende system op at køre. Men vi fandt hurtigt ud af, at vi sagtens kunne nå i mål inden for de rammer, vi havde sat.
Vi bruger som udgangspunkt vores standardprocesser med Jira-boards og issues. Vi er blevet bedre til at udvide beskrivelserne med acceptkriterier, så det er nemmere for en AI at arbejde med.
Det korte svar er, at det er en stor udgift, som det ser ud lige nu, men også at vi vurderer, at det giver et godt speed-up.
Mads Darø Kristensen
Principal Application Architect, PhD Assistant Head of Lab
Måske kunne disse events også have din interesse:

9. JUNI 2026 · ONLINE
Mange danske organisationer vil gerne i gang med at bruge AI. Men hvordan gør man det uden at sende følsomme data til udenlandske tech-giganter? Prøv vores AI-platform.

3. JUNI 2026 · ONLINE
Få indblik i, hvordan du klæder dine udviklere på, tilpasser udviklingsprocesser og anvender de nyeste værktøjer.

20. JUNI 2026
Pitch din idé til fremtidens sundhedsvæsen og vind et udviklingsforløb hos Alexandra Instituttet til en værdi af 300.000 kr.