Softwareudvikling med AI
Det er konteksten, der får din AI til at fejle
AI-værktøjer kan skrive kode hurtigt og overbevisende. Det gør dem nyttige i softwareudvikling. Men det gør dem også risikable.
For ofte arbejder agenten uden et klart billede af systemets lokale regler: rkitekturprincipper, godkendte dependencies, API-kontrakter, domænelogik, teststrategi og de kompromiser, der allerede er truffet i kodebasen.
Resultatet er kode, der ser rigtig ud, men som skaber problemer i review, vedligehold og drift.
Det er derfor en fejl at tro, at AI-assisteret udvikling først og fremmest handler om prompting. I praksis handler kvalitet i lige så høj grad om kontekst.
Problemet starter, når agenten må gætte
En coding agent kan godt skrive valid Python, TypeScript eller SQL. Den kan også foreslå tests, refaktoreringer og integrationer. Men den ved ikke automatisk:
- hvilke biblioteker teamet har fravalgt
- hvordan auth, logging og fejlhåndtering håndteres
- hvilke services der ejer hvilke data
- hvilke interfaces der ikke må ændres
- hvilke performance- eller sikkerhedshensyn der gælder
- hvilke løsninger der tidligere er fravalgt af gode grunde
Når den information ikke er tydelig, udfylder agenten hullerne med sandsynlige antagelser. Og i en produktionskodebase er sandsynlige antagelser sjældent gode nok.
Det er netop her, mange fejl opstår: ikke som rene hallucinationer, men som plausible løsninger bygget på for lidt lokalkendskab.
Kontekst er ikke dokumentation ved siden af arbejdet
I teams, hvor AI bruges aktivt, er kontekst ikke længere bare “noget, vi burde få skrevet ned”. Det er blevet en del af selve udviklingsarbejdet.
Hvis agenten ikke kender de lokale regler, optimerer den efter generelle mønstre fra sin træning i stedet for efter teamets faktiske standarder. Derfor bør konteksten være tydelig nok til, at agenten kan forstå ikke bare, hvad der skal bygges, men hvordan det skal bygges i netop denne kodebase.
Det kan for eksempel være:
- beskrivelser af systemarkitektur og ansvarsdeling
- beslutninger om frameworks, biblioteker og integrationsmønstre
- konventioner for struktur, navngivning, tests og fejlhåndtering
- krav til sikkerhed, logging, observability og compliance
- kendte begrænsninger og områder med teknisk gæld
- forklaringer på hvorfor eksisterende løsninger ser ud, som de gør
Jo mere eksplicit den kontekst er, desto mindre frihed har agenten til at gætte forkert.
Sådan spotter du, at konteksten er for svag
Det er sjældent modellen alene, der er problemet. Ofte kan du se det på outputtet:
- Agenten vælger et bibliotek eller framework, teamet normalt ikke bruger
- Den foreslår ændringer, der bryder med eksisterende arkitektur eller servicegrænser
- Den overser forretningsregler, som teamet tager for givet
- Den skriver tests, der kun dækker happy path, men ikke de reelle risici
- Den ændrer interfaces eller datamodeller uden at adressere bagudkompatibilitet
- Den producerer meget kode hurtigt, men med flere reviewbemærkninger end normalt
- Forskellige agenter eller prompts løser samme opgave på vidt forskellige måder
Ser du de mønstre gentage sig, er det ofte et tegn på, at problemet ikke er manglende eller uklar projektkontekst.
Små eksperimenter tåler improvisation. Produktionssystemer gør ikke
Det er en reel styrke ved AI-værktøjer, at de fungerer godt i små og afgrænsede opgaver. Scripts, prototyper og interne hjælpeværktøjer kan ofte bygges hurtigt med relativt lidt styring.
Men den arbejdsform skalerer dårligt.
I større systemer ligger kompleksiteten i samspillet mellem komponenter, afhængigheder, datamodeller, releaseprocesser, sikkerhedskrav og fremtidig vedligehold.
En løsning kan være teknisk korrekt isoleret set og stadig være dyr, hvis den flytter kompleksitet til drift, review eller næste team. Derfor er improvisation sjældent en holdbar strategi i software, der skal leve længe.
Den dyreste fejl er at implementere for tidligt
Coding agents gør det billigt at producere store mængder kode tidligt. Det føles effektivt, men kan hurtigt blive dyrt, hvis kravene stadig er uklare.
Hvis agenten går direkte fra en kort instruktion til implementering, må den selv tage stilling til en række spørgsmål:
- Skal løsningen være bagudkompatibel?
- Må der introduceres en ny dependency?
- Hvilke edge cases er forretningskritiske?
- Hvordan skal løsningen spille sammen med eksisterende interfaces?
- Hvilken teststrategi giver mening her?
Når de valg først bliver synlige i pull requesten, er fejlomkostningen allerede steget.
En bedre arbejdsgang er at bruge agenten til at afklare opgaven, før den skriver kode. Det vil sige til at stille afklarende spørgsmål, identificere tvetydigheder og skjulte antagelser, skitsere en implementeringsplan, pege på berørte komponenter og risici og foreslå teststrategi og reviewpunkter.
Det flytter kvalitetssikringen frem i processen, hvor ændringer er billigere.
Review bliver nemt en ny flaskehals
AI gør det muligt at producere kode hurtigere, end du kan validere den.
Det ændrer på, hvad review skal kunne: Den centrale opgave er ikke længere kun at kontrollere, om koden kompilerer eller ser fornuftig ud. Det er også at vurdere, om agenten har forstået problemet korrekt og respekteret systemets faktiske begrænsninger.
Det gør især disse 5 spørgsmål vigtige:
- Er problemet afgrænset rigtigt?
- Er løsningen i tråd med arkitekturen?
- Er drift, sikkerhed og vedligehold tænkt ind?
- Dækker testene de reelle risici?
- Er der indført skjult kompleksitet, som først viser sig senere?
Hvis svarene kommer for sent, bliver AI ikke en gevinst, men en hurtigere vej til flere reviewtimer og mere efterarbejde.
Præcis styring bliver det nye håndværk
AI reducerer ikke behovet for teknisk dømmekraft. Den flytter bare tyngdepunktet.
Den udvikler, der får mest ud af en coding agent, er den, der kan beskrive problemet præcist, gøre lokale regler eksplicitte, afgrænse løsningsrummet og opdage farlige antagelser tidligt.
Derfor er AI i softwareudvikling ikke et opgør med faglig disciplin, men snarere et krav om mere præcis disciplin.
Læs mere:
Kontakt
Få hjælp nu
Find relevante, kvalitetssikrede kurser og efteruddannelse.