Når AI bliver en del af software­udviklingen

Siden Google introducerede Transformer-arkitekturen i 2017, og OpenAI satte gang i den brede anvendelse af LLM’er med lanceringen af ChatGPT i 2022, har virksomheder på tværs af brancher haft travlt med at finde ud af, hvordan teknologien bedst kan skabe værdi. Softwareudvikling er ingen undtagelse. Large Language Models (LLM’er) har allerede vist deres potentiale gennem utallige eksempler, hvor de har forbedret både produkter, processer og måden, udviklingsteams arbejder på.

Den største gevinst ved AI i softwareudvikling er ikke, at teknologien udfører arbejdet, men at den udvider, hvad en udvikler kan få adgang til: viden, kodebaser og rutineopgaver, som tidligere kunne optage en hel arbejdsdag.

Kodeassistenter udvider udviklerens viden og handlekraft. Teknikker inden for bestemte domæner udvider modellens viden med den specifikke kontekst i din organisation. Agenter udvider denne rækkevidde yderligere til selvstændige handlinger. Men på hvert trin skabes værdien kun, hvis den ledsages af kontrol.

I denne artikel ser vi nærmere på denne udvikling: fra kodeassistenter og de grundlæggende principper, der gør dem effektive, til domænespecifikke systemer og i sidste ende agentiske arbejdsgange, der kan handle mere selvstændigt.

Den mest direkte måde, AI kan styrke softwareudvikling på, er gennem kodeassistenter. Udviklere bruger dem typisk på to niveauer:

1. På det mest grundlæggende niveau fungerer en LLM som en genvej til viden.
   Spørg den om et programmeringssprog, du ikke kender, særlige egenskaber ved et framework eller den bedste måde at strukturere en løsning på, og på få sekunder får du den viden, som tidligere krævede en søgemaskine og flere åbne faner at stykke sammen.
2. Det større spring kommer med integrerede kodeassistenter.
   Det kan være IDE-værktøjer (Integrated Development Environment) som Cursor og Copilot eller CLI-baserede (Command Line Interface) agenter som Gemini CLI og Claude Code. Her får LLM’en direkte adgang til at læse og ændre kode i dit faktiske projekt i stedet for blot at beskrive ændringer, som du selv skal implementere. Skiftet fra rådgiver til aktiv deltager er dét, der gør en chatbot til et værktøj, der for alvor kan løfte produktiviteten. Den samme model, der kan forklare et koncept, kan nu også implementere det, refaktorere koden og opdage de edge cases, du ellers kunne have overset.

Uanset hvilket niveau du arbejder på, afhænger den reelle værdi af de samme tre ting: at kunne kommunikere effektivt med modellen, bevare kontrollen over, hvilke data den får adgang til, og tilpasse den til dit teams specifikke domæne.

De fleste udviklere vælger som udgangspunkt en af de store AI-udbydere, såsom Anthropic’s Claude, Google’s Gemini eller OpenAI’s ChatGPT, fordi de tilbyder nogle af de mest avancerede modeller til daglig softwareudvikling.

Men den bekvemmelighed har en pris: Hver eneste prompt, der sendes til disse tjenester, herunder proprietær kode, som deles gennem kontekstvinduet, behandles på infrastruktur, der ejes af andre. For organisationer, der håndterer følsom IP, regulerede data eller klienters kodebaser under fortrolighedsaftaler, er det ofte ikke acceptabelt.

Alternativet er at bringe modellen ind i organisationen. Det betyder, at man må undvære de nyeste frontier-modeller, men til de fleste daglige udviklingsopgaver er open-weight-modeller som Gemma, Qwen eller Llama mere end tilstrækkelige.

Det betyder også, at man selv skal håndtere den drift og den infrastrukturkompetence, der følger med at drive AI-systemer internt. Det er ikke et gratis kompromis. Men for den rette organisation er den kontrol, det giver, investeringen værd.

Rækkevidde uden kontrol er blot eksponering, og her bliver princippet for første gang til en infrastrukturbeslutning frem for en abstrakt bekymring.

Opbygning af stacken

En enkel og skalerbar on-premises-løsning består af tre komponenter: hardware, en inferensmotor og en brugergrænseflade (UI).

• Hardware: Nvidia med CUDA eller AMD med ROCm.
• Inferens: vLLM, en meget effektiv motor udviklet til produktionsmiljøer.
• Brugergrænseflade: Open WebUI, som fungerer både som chatgrænseflade og som OpenAI-kompatibel API-proxy, hvilket gør det nemt at integrere i eksisterende udviklerarbejdsgange.

Dette er ikke kun en beslutning om omkostninger eller performance. Det er også et spørgsmål om governance. Når organisationen ejer infrastrukturen, ejer den også politikkerne for, hvordan AI anvendes, hvilke data den må tilgå, og hvem der har ansvaret. Samlet giver denne stack organisationer med behov for et højt niveau af kontrol et troværdigt og produktionsklart alternativ til de store teknologileverandører.

Det er her, AI’s rækkevidde udvides fra information til handling. Indtil nu har LLM’en fungeret som en intelligent assistent: den besvarer spørgsmål, forklarer ukendte begreber og hjælper udviklere med at skrive kode. En agent tager de næste skridt ved at give den samme model adgang til værktøjer og mulighed for at udføre opgaver på vegne af en udvikler.

En agent kan bedst beskrives som et ræsonnementslag oven på software. I stedet for at følge en fastlagt sekvens af handlinger modtager den et mål, vurderer hvilke værktøjer der er nødvendige, udfører handlingerne, evaluerer resultaterne og fortsætter, indtil opgaven er løst eller en stopbetingelse er nået.

Modellen erstatter ikke traditionel softwareudvikling, men orkestrerer eksisterende systemer. Versionsstyring, issue trackere, dokumentation, CI/CD-pipelines, databaser, API’er og overvågningsplatforme forbliver byggestenene, mens LLM’en afgør, hvordan de bedst kombineres.

Det ændrer karakteren af softwareautomatisering. Traditionel automatisering følger foruddefinerede arbejdsgange, hvor alle mulige scenarier er forudset af en udvikler. Agentiske arbejdsgange erstatter nogle af disse hårdkodede beslutninger med ræsonnement. I stedet for at skrive et script til enhver tænkelig situation, definerer udviklere målene, stiller værktøjerne til rådighed og fastsætter de rammer, agenten må operere inden for.

For softwareudvikling skaber dette muligheder, der rækker langt ud over kodegenerering.

• Onboarding: En agent med adgang til intern dokumentation, repositories og arkitekturdiagrammer kan besvare spørgsmål i den rette kontekst, generere læringsøvelser og guide nye udviklere gennem ukendte systemer.
• Dokumentation: I stedet for at vente på, at dokumentationen bliver forældet, kan en agent løbende sammenligne kildekode med eksisterende dokumentation, identificere uoverensstemmelser og udarbejde forslag til opdateringer.
• Håndtering af hændelser: Når alarmer udløses, kan en agent indsamle logdata, sammenholde telemetry-data på tværs af tjenester, identificere sandsynlige årsager og præsentere en kort hændelsesrapport, før en ingeniør overhovedet har åbnet dashboardet.
• Udviklingsarbejdsgange: En agent kan undersøge et fejlslagent build, genskabe problemet, identificere de berørte kildefiler, implementere et forslag til løsning, køre testpakken og oprette en pull request med både kodeændringerne og en forklaring af sin ræsonnering. Ingeniøren gennemgår og godkender resultatet, men en stor del af det gentagne arbejde er allerede udført.
• Vidensstyring: Designbeslutninger, mødenoter, hændelsesrapporter og Slack-samtaler indeholder ofte værdifuld arkitekturviden, som kan være svær at finde frem til igen. Agenter kan løbende organisere denne information i søgbar dokumentation og dermed reducere den mængde viden, som kun eksisterer i medarbejdernes hukommelse.

Bemærk, at ingen af disse eksempler afhænger af, at agenten er usædvanligt intelligent. Værdien ligger i dens evne til at udvide rækkevidden.

En udvikler behøver ikke længere manuelt at indsamle information fra en række forskellige systemer, før arbejdet kan begynde. Agenten kan samle denne kontekst automatisk.

I stedet for at erstatte tekniske vurderinger fjerner den en stor del af det mekaniske arbejde, der omgiver dem.

Jo længere AI’s rækkevidde strækker sig, desto vigtigere bliver governance.

En agent, der kun kan besvare spørgsmål, udgør en relativt begrænset risiko. En agent, der kan ændre kildekode, implementere infrastruktur eller interagere med produktionssystemer, kræver derimod nøje definerede rammer.

Disse rammer bør eksistere på flere niveauer. Agenter bør kun have adgang til de værktøjer, de reelt har brug for, operere efter princippet om mindst mulige rettigheder og kræve eksplicit menneskelig godkendelse, før irreversible handlinger som sammenfletning af kode eller softwareimplementering gennemføres. Alle handlinger bør kunne overvåges, være reproducerbare, hvor det er muligt, og logges med henblik på revision. Målet er ikke fuld autonomi, men ansvarlig automatisering.

Det afspejler det samme princip, som går igen gennem hele denne artikel. Hvert lag, fra kodeassistenter over domænebevidste systemer til autonome arbejdsgange, udvider, hvad en udvikler kan opnå. Men hver udvidelse af rækkevidden skal ledsages af en tilsvarende bevidst udvidelse af kontrollen. Teknologien skaber først reel værdi, når begge dele udvikler sig i takt.

Integrationen af AI i softwareudvikling giver et reelt produktivitetsløft, ikke fordi teknologien erstatter udviklere, men fordi den udvider deres rækkevidde: til viden, de ellers selv skulle opsøge, til kodebaser, de ellers skulle gennemgå linje for linje, og til gentagne opgaver, som tidligere stjal tid fra de mere komplekse udfordringer.

Det er den gennemgående tråd i alt, hvad vi har beskrevet, fra en kodeassistent, der besvarer et spørgsmål om syntaks, til en agent, der selv opretter en pull request.

Men rækkevidde uden kontrol forbliver ikke en fordel ret længe. Jo mere ingeniører bliver afhængige af AI, desto større er risikoen for, at deres fortrolighed med de værktøjer, de bruger, og den kode, de skriver, gradvist svækkes, ligesom en muskel, der bliver svagere, når den ikke længere trænes. Vi skal passe på ikke at bruge AI til alt eller stole blindt på dens svar og samtidig bevare tilstrækkelig praktisk erfaring med det egentlige arbejde til at kunne opdage, når noget er galt.

Der er en reel risiko for softwarevirksomheder, som overlader det meste af det tekniske arbejde til AI og lader udviklerne glide over i en rolle som rene arkitekter, der gennemgår kode og beskriver krav, men sjældent selv skriver eller debugger. Kompetencer forvitrer på den måde, og det samme gør den dømmekraft, der er nødvendig for at opdage fejl i AI’ens arbejde.

De værktøjer og arbejdsgange, der er beskrevet gennem denne artikel, er kun så gode som den disciplin, der ligger bag brugen af dem. Målet er ikke at lade AI erstatte teknisk dømmekraft, men at finde den rette balance, hvor teknologien overtager de gentagne og rutineprægede opgaver, så mennesker kan bruge mere tid på det arbejde, der kræver kreativitet, arkitekturforståelse og erfaring. Det er denne balance, hvor rækkevidde følges af kontrol, og ikke teknologien i sig selv, der afgør, om AI gør et team stærkere eller blot mere afhængigt.