AI-assisteret kodning: best practices, faldgruber og sådan bevarer du kvaliteten

Det korte svar: Sådan bruger du AI til kodning uden at miste kvaliteten

AI-assisteret kodning kan gøre dig markant hurtigere, men kun hvis du styrer den stramt: klare krav (spec), små ændringer, konsekvent tests, code review og tydelige “gates” før noget får lov at ramme main branch eller produktion. Tænk på AI som en hurtig, lidt uforsigtig junior – ikke en arkitekt eller tech lead.

I praksis betyder det her:

• Du ejer krav, arkitektur, sikkerhed og release.
• AI hjælper med udkast, variation, boilerplate, tests og dokumentation.
• Alt AI-output behandles som uverificeret kode: test, review og sikkerhedsscanning før merge.
• Jo mere kritisk koden er (auth, betaling, data), jo mindre autonomi må AI have.

Resten af artiklen går mere systematisk til værks: Hvad AI er god/dårlig til, værktøjsvalg, workflow fra prompt til produktion, typiske faldgruber, sikkerhed, compliance og hvordan du faktisk måler kvaliteten af AI-genereret kode.

Hvad er AI-assisteret kodning, og hvad kan den godt og dårligt?

AI-assisteret kodning er brug af AI som udviklingsassistent til at foreslå, forklare, teste og dokumentere kode. Den er stærk til tempo og rutine, men kvaliteten afhænger af menneskelig styring, review og test, fordi AI ikke forstår domæne, forretning og teamets konventioner på samme måde som dig og dit team.

AI-assisteret kodning spænder typisk over tre typer hjælp:

• Autocomplete-niveau: inline-forslag i editoren, mens du skriver.
• Chat-niveau: du beskriver et problem, AI svarer i et chatvindue og foreslår kode, forklaringer eller tests.
• Agentisk niveau: AI får en større opgave (fx “implementer feature X”), redigerer i flere filer og kan fx åbne en pull request.

Her er en praktisk beslutningsmodel:

En god grundregel er: jo mere forretningskritisk, sikkerhedskritisk eller kompleks en beslutning er, jo mere skal AI reduceres til en sparringspartner, mens mennesker tager den endelige beslutning.

Hvis du vil se, hvordan den her rollefordeling fungerer i praksis, er der konkrete eksempler i guiden om vibe coding og i artiklen om AI som medprogrammør.

Hvilke værktøjer og autonominiveauer findes der?

Værktøjerne til AI-assisteret kodning adskiller sig især på, hvor tæt de sidder på editoren, og hvor autonomt de må ændre kode. Copilot ligger tæt på editoren, Cursor er bygget omkring AI, mens Claude Code og Codex kan tage større opgaver og foreslå ændringer på tværs af filer, nogle gange som pull requests. Jo mere autonomt værktøjet arbejder, jo vigtigere er tydelige konventioner, tests og godkendelsesflows.

Typiske værktøjstyper

• Inline-assistenter (fx GitHub Copilot)
  Forslår kode, mens du skriver. God til:
  • Boilerplate
  • Gentagne mønstre i din kodebase
  • Små helper-funktioner
  Men kan nemt “gætte forkert” på arkitektur og sikkerhed, hvis du bare accepterer alt.
• Editor- og IDE-first værktøjer (fx Cursor)
  Hele editoren er designet omkring AI. God til at:
  • Forstå sammenhæng mellem filer
  • Refaktorere på tværs
  • Foreslå ændringer og tests i samme arbejdsgang
  Her er risikoen, at større ændringer glider igennem, hvis du ikke holder ændringerne små og overskuelige.
• Chat- og terminalværktøjer (fx Claude Code)
  Arbejder ofte på repo-niveau og kan køre tests, skrive scripts og foreslå patches. Kan være effektivt til:
  • Fejlsøgning med kontekst fra flere filer
  • Generering af migrations, scripts, dokumentation
  Men igen: output skal behandles som forslag, ikke som sandhed.
• Agentiske værktøjer (fx Codex-lignende systemer)

Agentiske værktøjer kan på sigt åbne pull requests selv, køre pipelines eller udføre opgaver uden direkte input for hver lille ændring. Det er her, du for alvor skal have styr på guardrails, branch protection og review-regler.

Autonominiveau og risiko

Værktøjsvalget er mindre vigtigt end processen. Uanset om du bruger Copilot eller Claude Code, har du brug for et workflow med klare gates, som beskrevet længere nede.

Hvis du vil dykke mere ned i konkrete forskelle mellem værktøjer, kan du fx læse om Codex vs. Claude Code eller udviklerguiden til Microsoft Copilot.

Hvordan bevarer du kodekvaliteten, når du bruger AI?

Kodekvaliteten bevares ved at styre AI’en med klare krav, små ændringer, automatiske checks og menneskelig review. AI må gerne skrive udkast og hjælpe med tests, men den skal aldrig være sidste instans på arkitektur, sikkerhed eller release.

Det mest robuste er at se kvalitet som en proces med faste “gates”. Her er en model i fire lag, som du kan implementere direkte.

1. Før AI får lov: krav og kontekst (pre-generation)

• Spec-first: Skriv kort, hvad funktionen skal gøre, hvilke inputs den får, hvad den returnerer, og hvilke edge cases, du forventer.
  Fx:
  // Funktion: beregnTotal(priser: number[], momsPct: number) // - Summerer priser // - Lægger moms oveni // - Fejl hvis priser er tom eller momsPct < 0
• Kontekst: Fortæl AI, hvilke patterns og konventioner du bruger (fx error handling, logging, navngivning). Det er essensen af “context engineering”.
• Rule of 3 references: Henvis i prompten til 2-3 eksisterende filer eller funktioner, der viser den stil, du vil have AI til at efterligne.

Til selve formuleringen af prompts kan du hente konkrete skabeloner i guiden om AI-prompts til kodning.

2. Mens AI skriver: små ændringer og tests (generation)

• Små commits: Bed AI om at løse én ting ad gangen. Undgå “skriv hele modulet om”.
• Test-first eller samtidig: Få AI til at foreslå tests ud fra din spec, før eller samtidigt med implementeringen.
• Ingen blind copy-paste: Sæt dig ind i koden, før du accepterer den. Artiklen “Stop med bare at copy-paste AI-kode” går mere i dybden med hvorfor.

3. Efter AI: automatiske checks og review (quality gates)

Behandl AI som en ekstern bidragyder. Når du har fået et forslag:

• Kør linters og type checkers.
• Kør enhedstests og integrationstests.
• Kør gerne static application security testing (SAST) og dependency scanning (SCA) i CI.
• Få en kollega til at lave et rigtigt pull request review, hvor der aktivt stilles spørgsmål: “Hvad sker der, hvis input er tomt?”, “Hvor håndteres auth?”, “Hvilke edge cases dækker vi ikke?”.

Hvis du ikke allerede har en CI-pipeline, der håndterer de her checks, er det værd at kigge på principperne i “Lille CI, stor forskel”.

4. Efter deploy: monitorering og løbende kvalitet

Selv med gode tests kan AI-genereret kode slippe igennem med fejl. Derfor bør du:

• Logge fejl og nøglehændelser tydeligt.
• Overvåge fejlrate, latency og usædvanlige mønstre.
• Have en klar rollback-plan, hvis en release skaber problemer.

Hvis du er i tvivl om, hvordan du får styr på logging og observability, er guiden om logs vs. mavefornemmelse og artiklen om systemdrift gode steder at starte.

Hvilke best practices bør et udviklingsteam følge?

Et udviklingsteam bør bruge AI som en styret medhjælper: giv den kontekst, arbejd i små ændringer, kræv tests og review, og lad aldrig AI hoppe direkte fra prompt til merge. Standardiseret praksis gør forskellen mellem “sjovt eksperiment” og “reel produktionskapacitet”.

Teamregler, der gør AI-brug robust

• 1. Definér, hvor AI må bruges
  Lav en enkel politik: Hvilke projekter? Hvilke miljøer (aldrig direkte i produktion)? Hvilke domæner (fx aldrig auth og betaling)?
• 2. Fast prompt-struktur
  En god prompt til kodning indeholder typisk:
  • Rolle: “Du er en hjælper i vores TypeScript-frontend.”
  • Mål: “Implementer en funktion, der gør X.”
  • Kontekst: henvisning til eksisterende filer/patterns.
  • Begrænsninger: “Brug kun eksisterende dependencies, ingen nye.”
  • Testkrav: “Foreslå 5 unit tests inkl. edge cases.”
  Hvis I vil bygge en fælles praksis op, kan I tage udgangspunkt i guiden om prompts til kodning.
• 3. Branch small
  En AI-PR bør være lige så lille og fokuseret som en menneskeskrevet: én feature, én bugfix, én refaktorering. Det gør review og rollback realistisk.
• 4. Kræv tests
  Lav en tommelfingerregel: ingen AI-genereret kode uden tests. Det kan godt være AI selv foreslår dem, men en menneskelig udvikler skal godkende, at de faktisk tester noget meningsfuldt.
• 5. Code ownership
  Klar ejer for hvert modul. Ejerens navn står på hooken til review og har ret (og pligt) til at sige nej, hvis koden ikke er forståelig eller vedligeholdelig.
• 6. Dokumentér væsentlige AI-bidrag
  Når AI har haft en central rolle i en større ændring, kan det stå kort i PR-beskrivelsen: “Implementering genereret med hjælp fra AI, manuelt gennemgået og tilpasset.”
• 7. Træning af udviklere
  AI-færdigheder er nu en del af håndværket: at skrive gode prompts, læse AI-kode kritisk, og kende typiske fejl. Det er på linje med at lære Git og testværktøjer.

Hvis I vil bygge et mere formelt rammeværk, er artiklen om IT- og cybersikkerhed governance et godt fundament at koble AI-politikken på.

Hvad er de mest almindelige faldgruber?

De største faldgruber er, at AI-koden ser rigtig ud, men mangler kontekst, sikkerhed, tests og dependency-kontrol. Den farligste fejl er ofte falsk tryghed: at udvikleren stoler for hurtigt på outputtet, fordi det “ser pænt ud”.

Her er en oversigt over typiske fejltyper, hvad du kan se efter, og hvordan du modvirker dem.

Mange af de her faldgruber forværres, hvis du bare copy-paster AI-kode. Hvis du kan genkende den fristelse, er det værd at tage en runde med artiklen om blind copy-paste.

Hvilke sikkerhedsrisici skal du især passe på?

AI-genereret kode er ikke sikker som udgangspunkt. De største risici er SQL-injektion, usikker inputhåndtering, secrets-læk og svag adgangskontrol. Derfor skal AI-kode altid gennem sikkerhedsrevision og automatiske scans, især hvis den kører tæt på data eller brugere.

Typiske sårbarheder i AI-kode

• SQL-injektion
  AI kan finde på at bygge SQL-queries ved at concatenere strings, hvis du ikke specifikt beder om parameteriserede queries.
• XSS (cross-site scripting)
  Output af user input til DOM uden escaping eller sanitizing.
• Broken access control
  Funktioner der antager, at “hvis brugeren kan se knappen, må de også udføre handlingen”.
• Secrets i kode
  API-nøgler, tokens eller passwords direkte i koden eller konfigurationsfiler. AI kan både foreslå og uforvarende videreføre dårlige patterns.
• Svag eller hjemmelavet kryptografi
  AI foreslår “simple” krypteringsløsninger uden at forstå trusselsbilledet.

Praktiske sikkerhedsguardrails

• Ingen følsomme data i prompts
  Send ikke persondata, hemmelige nøgler eller intern forretningslogik til åbne AI-tjenester uden en klar aftale og vurdering.
• Standardiser mønstre
  En fast måde at lave auth, validering, logging osv. AI skal følge jeres mønstre, ikke omvendt.
• Brug OWASP Top 10 som checkliste
  Ved web- og API-udvikling er OWASP Top 10 stadig et godt udgangspunkt for review.
• Automatiske sikkerhedsscans
  Brug SAST, SCA og gerne DAST i CI, så sårbarheder ikke er afhængige af manuel opdagelse.
• Secret management i orden
  API-nøgler skal i sikre vaults, ikke i koden. Se fx “Secrets skal være kedelige”, om API-nøgler og tokens i webapps.

Sikkerhedsrisikoen handler lige så meget om mennesker som om AI: nye udviklere kan blive vildledt af kode, der ser rigtig ud. Gør det legitimt at være skeptisk og stille “dumme” spørgsmål i review.

Hvordan tester og reviewer du AI-genereret kode?

AI-kode skal testes og reviewes som kode fra en ekstern bidragyder: kontroller krav, edge cases, sikkerhed, dependencies og drift, før ændringen må merges. Ellers risikerer du at introducere fejl hurtigere, end AI kan hjælpe dig.

Teststrategi for AI-kode

• Unit tests: Dækker små funktioner og metoder. Sørg for både happy path og negative tests.
• Integrationstests: Tjekker samspil mellem moduler, databaser, eksterne systemer.
• Regressionstests: Sikrer, at eksisterende funktionalitet stadig virker, især ved refaktoreringer foreslået af AI.
• Negative og fuzz tests: Ondsindet input, uventede typer, ekstremt store datasæt.

AI kan hjælpe med at foreslå tests, men du skal sikre, at de ikke bare spejler implementeringen. Tests bør beskrive ønsket adfærd, ikke bare bekræfte en tilfældig løsning.

Hvis du arbejder med moderne frontend, er der konkrete testeksempler i guiden om tests i Vite-projekter. De samme principper gælder for AI-genereret kode.

Code review som kvalitetssikring, ikke formalitet

En god reviewer gør mere end at kigge efter stavefejl i variabelnavne. For AI-kode bør review mindst dække:

• Krav: Matcher koden den oprindelige spec?
• Forståelighed: Kan revieweren forklare, hvad koden gør, uden at spørge AI?
• Edge cases: Hvad sker der ved tomme lister, null, timeouts, fejlsvar fra API’er?
• Sikkerhed: Hvor tjekkes auth, inputvalidering, rate limiting osv.?
• Dependencies: Er der kommet nye pakker eller services ind? Er det nødvendigt?
• Drift: Er der tilstrækkelig logging og error handling til at kunne fejlfinde i produktion?

Branch protection-regler kan hjælpe dig med at håndhæve, at alle AI-relaterede PRs skal igennem review og CI-checks, før de kan merges.

Vil du bygge en mere generel test- og kvalitetspraksis op omkring det her, er kategori-siden om test og kvalitet et godt overblik.

Hvordan dokumenterer du ansvar og compliance i Danmark?

I Danmark bør AI-assisteret kodning styres med dokumentation, ansvar og databevidsthed: beskriv menneskeligt bidrag, undgå fortrolige data i åbne værktøjer, og afklar altid, hvilke regler og roller der gælder i teamet. AI er et værktøj, ikke en juridisk person, så ansvaret ligger stadig hos mennesker og organisation.

AI-forordningen og dansk praksis i korte træk

• EU’s AI-forordning trådte i kraft 1. august 2024.
• Reglerne indfases trinvist frem mod 2027, med forskellige datoer for forskellige dele.
• Der skelnes mellem AI-modeller og AI-systemer og mellem forskellige risikoniveauer.

De fleste udviklingsteams, der “bare” bruger en ekstern AI-tjeneste til kodning, vil typisk ikke havne i højrisiko-kategorien. Men der gælder stadig almindelige regler om bl.a. persondata, ophavsret og informationssikkerhed.

Praktiske teamregler for compliance

• Data i prompts
  Lav en klar regel for, hvilke datatyper der aldrig må sendes til eksterne AI-tjenester (fx CPR-numre, sundhedsdata, interne nøgler, forretningshemmeligheder).
• Leverandørforhold
  Afklar med leverandøren, hvordan data bruges, gemmes og evt. indgår i træning. Det er især relevant under GDPR og AI-forordningen.
• Menneskeligt bidrag
  Ophavsret forudsætter typisk et menneskeligt, kreativt bidrag. Sørg for, at AI-kode bliver vurderet, tilpasset og integreret af mennesker, ikke bare kopieret direkte.
• Logging og sporbarhed
  Gem relevante beslutninger: hvornår AI blev brugt, hvilke områder af systemet, og hvem der godkendte ændringerne.
• Intern AI-politik
  Samle ovenstående i en kort politik for AI-brug i udvikling. Den behøver ikke være juridisk tung, men skal være klar nok til, at nye udviklere forstår rammerne.

Juridiske detaljer og fortolkninger ændrer sig over tid. For dybere dækning af AI-forordningen og databeskyttelse giver det mening at kombinere tekniske guides som denne med mere rene jura-artikler og rådgivning. Artiklen om sikker anvendelse af AI i udviklingsarbejde går et spadestik dybere i det organisatoriske lag.

Hvordan måler man kvaliteten af AI-genereret kode?

Kvaliteten måles bedst med få, stabile indikatorer som bug density, rework rate, security findings, testkvalitet og dependency additions. Hvis tallene bevæger sig i den forkerte retning, skal teamets AI-brug justeres, uanset hvor begejstrede I ellers er for værktøjet.

Enkel kvalitetsmodel til AI-kode

Start med et simpelt “scorecard” for pull requests, hvor AI har været involveret:

Du behøver ikke præcise industristandarder for at komme i gang. Det vigtige er at vælge nogle få målepunkter, følge dem stabilt og justere jeres AI-brug ud fra, hvad I ser i praksis.

På sigt kan du koble det her sammen med mere generelle DevOps- og observability-metrics. Artiklerne om systemdrift og observability viser, hvordan du spotter problemer tidligt i produktion.

Hvornår bør AI bruges, og hvornår bør den holdes tilbage?

AI bør bruges til rutine, udkast og variation, men ikke autonomt til kritiske områder som auth, betaling, kryptografi og direkte produktionsændringer. Jo større konsekvens en fejl har, desto mere menneskelig kontrol kræves der.

En enkel risikomodel

Hvis du er i tvivl, så regn funktionen som en klasse højere risiko, end du umiddelbart føler. Det er sjældent de ufarlige helper-funktioner, der skaber de store problemer – det er gråzonen omkring auth, data og drift.

Et samlet workflow: fra prompt til produktion

For at binde det hele sammen kan du bruge denne praktiske “fra prompt til produktion”-arbejdsgang som udgangspunkt for dit team.

1. Afgræns opgaven
   Beskriv kort hvad der skal laves, risikoniveau (lav/mellem/høj/kritisk) og hvilke filer/områder der er berørt.
2. Lav spec og prompt
   Skriv en lille spec og en prompt med kontekst, begrænsninger og testkrav.
3. Lad AI skrive udkastet
   Hold ændringen lille. Få gerne AI til både at foreslå kode og tests.
4. Lokal gennemgang
   Læs koden selv. Forstår du den? Matcher den spec’en? Er der tydelige sikkerheds- eller designfejl?
5. Automatiske checks
   Kør linters, tests, type checks, sikkerhedsscanning og dependency checks via CI.
6. Code review
   Kollega med relevant kontekst gennemgår PR, med fokus på krav, edge cases, sikkerhed og vedligeholdelse.
7. Merge og deploy via CI/CD
   Ingen direkte push til produktion. Brug etablerede pipelines og eventuelt feature flags.
8. Monitorering og læring
   Overvåg fejl, performance og brugsmønstre. Justér prompts, policies og teststrategi ud fra erfaringerne.

Når workflowet først sidder på rygmarven, føles AI-assisteret kodning mindre som et eksperiment og mere som endnu et værktøj i værktøjskassen. Det er sådan, du både får tempoet og bevarer kvaliteten.