Er I klar til AI-drevet softwareudvikling?

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. 

Modellen er selve LLM’en – sprogmodellen. Den læser og forstår opgaven og har også en stor del forståelse for kode. For at kunne give de helt rigtige svar bruger modellen en hel del værktøjer, der f.eks. kan læse git historik, søge på internettet efter svar, lede igennem store kodebaser m.m. Så de nye, gode AI udviklingsværktøjer kan meget mere nu, fordi de benytter “tool calling”, MCP m.m.

Vi tester mange forskellige ting for tiden, så vi har forskellige værktøjer i gang. Vores standard valg lige nu er dog Claude Code, da den i vores erfaring giver den bedste “out of the box” funktionalitet. Vi holder løbende øje med, hvordan feltet bevæger sig, og arbejder også meget med f.eks. OpenCode, lokale sprogmodeller m.m. Vores håb er nok, at en god OpenCode konfiguration med brug af danske/europæiske modeller kommer til at indhente Claude Code snart.