GitHub Copilot har i 2026 fået et af sine mest brugte features gjort markant stærkere: automatisk kodegennemgang. Siden 2. oktober 2026 understøtter Copilot code review både API-adgang og nye “effort”-niveauer, så teams kan styre hvor dybt (og hvor dyrt) en gennemgang skal være. Denne guide viser dig, trin for trin, hvordan du sætter funktionen op i VS Code, JetBrains og via CLI, og hvordan du undgår de faldgruber de fleste udviklere rammer i de første uger.

Vi bygger et komplet eksempelprojekt undervejs, så du ikke bare læser teori, men ser code review-funktionen fange rigtige fejl i rigtig kode. Til sidst får du en liste med otte konkrete fejlfindingsscenarier, så du ikke sidder fast, når opsætningen driller.

Guiden er bygget til udviklere, der allerede kender til GitHub og pull requests, men som ikke har brugt Copilots gennemgangsfunktion i praksis endnu. Du behøver ikke være Copilot-ekspert for at følge med. Vi tager det fra bunden: konto og plan, installation i din foretrukne editor, selve aktiveringen, og til sidst et testprojekt, hvor du kan se funktionen fange reelle fejl med egne øjne.

Hvad er GitHub Copilot Code Review, og hvorfor er det relevant nu

GitHub Copilot code review er en AI-drevet gennemgangsfunktion, der automatisk vurderer pull requests og foreslår rettelser, inden et menneske overhovedet har åbnet diffen. Tanken er enkel: lad en model fange de kedelige, forudsigelige fejl først, så de menneskelige kolleger kan bruge deres tid på de spørgsmål, der faktisk kræver dømmekraft. Funktionen er tilgængelig på alle betalte Copilot-planer og virker i flere miljøer, deriblandt GitHub CLI, GitHub Mobile, Visual Studio og JetBrains-baserede IDE’er, ifølge GitHub’s officielle dokumentation.

Det nye i oktober 2026 er to ting. For det første har GitHub åbnet API-adgang til code review, så virksomheder kan trigge gennemgange programmatisk fra deres egne CI/CD-pipelines i stedet for kun manuelt via GitHub-grænsefladen. For det andet er der kommet et nyt standard effort-niveau, der balancerer grundighed mod forbrug af AI-credits. Det betyder konkret, at en “Lite”-gennemgang typisk koster mellem 0,05 og 1 dollar i AI-credits, mens en “Balanced”-gennemgang koster mellem 0,25 og 5 dollar, afhængigt af hvor stor pull requesten er.

Code review adskiller sig fra almindelig kodefuldførelse ved, at den ikke skriver kode for dig. Den læser din diff, sammenligner den med resten af repositoriet og kommenterer direkte i pull requesten, nogenlunde som en kollega ville gøre det. Det gør funktionen relevant for teams, der vil fange simple fejl (null-tjek, usikre SQL-forespørgsler, manglende fejlhåndtering) før en menneskelig reviewer bruger tid på dem.

Mange danske udviklingsteams, fra fintech-startups i København til større IT-afdelinger i den offentlige sektor, har allerede Copilot installeret til kodefuldførelse og chat, men har aldrig slået code review-funktionen til separat. Det er en pointe værd at understrege: aktivering af Copilot i din editor gør ikke automatisk, at pull requests bliver gennemgået. De to funktioner konfigureres hver for sig, og det er netop den adskillelse, der forvirrer mange ved første forsøg. Denne guide samler derfor både editor-opsætningen og repository-indstillingerne ét sted.

Forudsætninger: Dette skal du bruge, før du starter

Inden du går i gang, skal følgende være på plads. Denne liste dækker både software-versioner og kontoadgang, så du undgår at sidde fast halvvejs gennem opsætningen.

  • En GitHub-konto med en betalt Copilot-plan: Copilot Pro ($10/md), Copilot Business ($19/bruger/md) eller Copilot Enterprise ($39/bruger/md). Den gratis plan har for få premium-forespørgsler til regelmæssig code review.
  • Et GitHub-repository (code review virker kun på GitHub, ikke på GitLab eller Bitbucket).
  • Visual Studio Code version 1.104 eller nyere, hvis du vil bruge VS Code-integrationen.
  • GitHub Copilot Chat-extension version 0.41.0 eller nyere, hvis du arbejder i Xcode.
  • En JetBrains IDE (IntelliJ IDEA, PyCharm, WebStorm, Rider eller lignende) med GitHub Copilot-plugin’et installeret, hvis du vælger den vej.
  • Node.js 20 LTS eller nyere, hvis du følger eksempelprojektet i denne guide.
  • Git installeret lokalt og konfigureret med dit GitHub-brugernavn og din e-mail.
  • Administratorrettigheder til repositoriet, hvis du skal slå automatisk code review til for et helt team.

Sæt cirka 45-60 minutter af til hele opsætningen, inklusive eksempelprojektet. De fleste trin tager 2-5 minutter, men den første autentificering og den første fulde gennemgang af et rigtigt repository kan tage lidt længere, fordi Copilot skal indeksere din kodebase.

Hvis du arbejder i et team med flere repositories, er det en god idé at teste hele flowet på ét enkelt, mindre repository først. Det giver dig mulighed for at se, hvor meget AI-credits en typisk pull request bruger, før du ruller funktionen ud bredt. Vælg gerne et repository med moderat aktivitet, 5-10 pull requests om ugen er nok til at give et retvisende billede uden at brænde et helt budget af på forsøg.

Sammenligning af Copilot-planer til code review

Før du vælger plan, er det værd at se forskellen på, hvad hver plan reelt giver dig adgang til, når det kommer til code review og AI-credits. Prisforskellen mellem Pro og Business kan virke lille på papiret, men den afgørende forskel ligger i, hvordan credits fordeles: individuelt pr. bruger på Pro, eller delt på tværs af hele organisationen på Business og Enterprise.

PlanPrisCode reviewPremium-forespørgsler/mdAPI-adgang
Copilot Free0 kr.Begrænset50Nej
Copilot Pro$10/mdJa300Ja
Copilot Business$19/bruger/mdJaPooled på org-niveauJa
Copilot Enterprise$39/bruger/mdJa, udvidetPooled, højere loftJa, fuld

For de fleste mindre teams i Danmark giver Copilot Business den bedste balance, fordi credits deles på tværs af organisationen i stedet for at være bundet til den enkelte udvikler. Enterprise-planen giver mening, hvis I har compliance-krav til audit-logs og vil bruge API’en til at integrere code review direkte i jeres eget CI-system.

Et konkret eksempel: et team på otte udviklere, der tilsammen opretter omkring 40 pull requests om ugen, vil typisk ligge et sted mellem 10 og 60 dollar om ugen i AI-credits til code review alene, afhængigt af om de kører Lite eller Balanced som standard. Tallet stiger naturligvis, hvis teamet også bruger de samme credits til almindelig chat og agent-opgaver i løbet af dagen, så det er værd at se code review som én blandt flere poster i det samlede forbrug, ikke en isoleret udgift.

Trin 1: Opret eller bekræft din GitHub-konto og Copilot-plan

Log ind på github.com, og tjek under Settings > Copilot at du har en aktiv betalt plan. Hvis du er på den gratis plan, skal du opgradere, før code review-funktionen bliver tilgængelig i praksis. Virksomhedskonti skal have en organisationsadministrator til at slå Copilot til for medlemmerne, inden den enkelte udvikler kan bruge funktionen.

Hvis du sidder i en større organisation, er det typisk IT-afdelingen eller en platform-ansvarlig, der styrer licenserne centralt. Tjek derfor internt, om jeres organisation allerede har en aftale, før du selv opretter en personlig Pro-licens, da det kan give overlap og unødige omkostninger, hvis begge dele aktiveres parallelt.

Tjek samtidig din fakturering. Copilot code review trækker på de samme AI-credits som chat og agent-funktionerne, så hvis dit team allerede bruger meget Copilot Chat, bør I holde øje med forbruget i den første måned efter I slår code review til.

Hvis din organisation bruger single sign-on (SSO) via et identitetsudbyder som Okta eller Azure AD, skal du desuden bekræfte, at Copilot-adgangen er korrekt mappet til din bruger. Det er en af de hyppigste årsager til, at nye medarbejdere oplever “Copilot not available”-fejl, selvom organisationen rent faktisk har en aktiv licens til dem.

Trin 2: Installer og konfigurer VS Code-integrationen

Download den nyeste stabile VS Code-build fra code.visualstudio.com. Copilot Chat-extensionen opdateres ofte i takt med VS Code, så en forældet version kan give mærkelige fejl under autentificering.

Åbn Extensions-panelet (Ctrl+Shift+X på Windows/Linux, Cmd+Shift+X på macOS), søg efter “GitHub Copilot” og installer både Copilot og Copilot Chat. Genstart VS Code bagefter.

# Tjek din VS Code-version fra terminalen
code --version

# Forventet output (eksempel):
# 1.104.2
# a1b2c3d4e5f67890
# x64

Når extensionerne er installeret, klikker du på Copilot-ikonet nederst i statuslinjen og vælger “Sign in to GitHub”. Et browservindue åbner, hvor du godkender adgangen. Vend tilbage til VS Code, og du skulle nu se en grøn markering ved Copilot-ikonet.

Du kan samtidig bruge dette trin til at tjekke, at du er logget ind med den rigtige GitHub-konto, især hvis du har både en privat og en arbejdsrelateret konto på samme maskine. Det er en overraskende almindelig kilde til forvirring, når Copilot-forslagene pludselig forsvinder efter en skift mellem projekter. Det er her, mange forveksler kodefuldførelse med code review. Når Copilot-ikonet er grønt, betyder det kun, at du kan bruge chat og inline-forslag i editoren. Det slår ikke automatisk gennemgang af pull requests til på GitHub. De to ting hænger sammen via din konto, men skal aktiveres hver for sig, som vi gør i næste trin.

Trin 3: Slå automatisk code review til for dit repository

Gå til dit repository på github.com, klik på Settings, og find sektionen “Copilot” i venstre menu. Her finder du indstillingen for automatisk code review. Ifølge GitHub’s egen dokumentation skal du “enable the Automatically request Copilot code review policy”, hvis du vil have, at hver nye pull request automatisk bliver tildelt Copilot som reviewer (GitHub Docs).

Du kan også vælge at lade Copilot gennemgå hver eneste push til en pull request, den allerede er i gang med at reviewe, i stedet for kun at kigge på det oprindelige diff. Det er nyttigt i teams, hvor pull requests lever i flere dage og får mange småcommits undervejs.

Som alternativ til at aktivere funktionen globalt kan du også bede om en manuel gennemgang på enkelte pull requests. Åbn PR’en på GitHub, klik på tandhjulet ud for “Reviewers”, og vælg Copilot fra listen. Det er en god metode at starte med, hvis du vil teste funktionen på et par udvalgte pull requests, før du slår den til automatisk for hele repositoriet.

  • Gå til Settings > Copilot > Code review i dit repository.
  • Slå “Automatically request Copilot code review” til.
  • Vælg om nye pushes til en åben PR skal udløse en ny gennemgang.
  • Gem ændringerne. Det træder i kraft fra næste pull request.

Trin 4: Konfigurer JetBrains-integrationen (IntelliJ, PyCharm, WebStorm, Rider)

Code review i JetBrains-produkter kom til i 2025 og er siden blevet udvidet med effort-niveauerne fra oktober 2026. Åbn din JetBrains IDE, gå til Settings > Plugins, søg efter “GitHub Copilot”, og installer plugin’et hvis det ikke allerede er der. Genstart IDE’en.

Log ind via Tools > GitHub Copilot > Login to GitHub. Når du har stagede ændringer klar til en commit, finder du en ny knap i Git-værktøjsvinduet, der hedder “Request Copilot Review”. Klik på den, og Copilot analyserer dine ændringer direkte i IDE’en, før du overhovedet har lavet pull requesten.

Fordelen ved at bruge JetBrains-integrationen frem for kun GitHub-siden er, at du får feedback, før koden overhovedet forlader din maskine. Det sparer en runde frem og tilbage, fordi du kan rette de oplagte fejl lokalt og først skubbe en renere version op som pull request. I praksis betyder det færre kommentarer at forholde sig til, når PR’en først er oprettet, og en hurtigere gennemgangsproces for resten af teamet.

// Eksempel: Copilot fanger denne type fejl i JetBrains
function getUserById(id) {
  const user = users.find(u => u.id === id);
  return user.name; // Copilot flager: user kan være undefined her
}

Trin 5: Opsæt Copilot CLI til kommandolinje-baseret review

Hvis dit team foretrækker terminalen frem for en grafisk editor, kan GitHub CLI bruges til at trigge og læse code review-resultater. Installer GitHub CLI, og tilføj derefter Copilot-extensionen til den.

# Installer GitHub CLI (macOS via Homebrew)
brew install gh

# Log ind
gh auth login

# Installer Copilot CLI-extensionen
gh extension install github/gh-copilot

# Bed om en code review af den aktuelle pull request
gh copilot review --pr 42

Output fra kommandoen ligner dette i praksis:

Reviewing PR #42: "Add user authentication endpoint"
Effort level: Balanced
Files analyzed: 4
Comments posted: 6

src/auth/login.js:23 - Manglende rate limiting på login-endpoint
src/auth/login.js:41 - Password sammenlignes uden konstant tid (timing attack-risiko)
src/db/queries.js:12 - Rå SQL-streng bør erstattes med parameteriseret forespørgsel
Estimated cost: $0.38 in AI credits

CLI-tilgangen passer godt ind i teams, der allerede har automatiseret store dele af deres Git-arbejdsgang med scripts. Du kan for eksempel lave et alias, så gh copilot review --pr $(gh pr view --json number -q .number) altid rammer den PR, du står på i din nuværende branch, uden at du selv skal huske PR-nummeret hver gang.

Trin 6: Forstå og vælg effort-niveauer (Lite vs. Balanced)

Effort-niveauerne er den vigtigste nye kontrolknap siden API-opdateringen 2. oktober 2026. Lite-niveauet er hurtigere og billigere, men fanger primært åbenlyse fejl som manglende null-tjek og ubrugte variabler. Balanced-niveauet graver dybere og sammenligner ændringer mod resten af kodebasen, hvilket gør det bedre til at fange arkitektoniske problemer, men det koster mere i AI-credits og tager længere tid.

Effort-niveauTypisk pris pr. reviewBedst tilGennemsnitlig svartid
Lite$0,05 – $1,00Små PR’er, hurtige rettelserUnder 1 minut
Balanced (standard)$0,25 – $5,00Normale featurebranches1-3 minutter

Du vælger niveau enten globalt i organisationens Copilot-indstillinger eller pr. repository. For et team, der merger 20-30 pull requests om ugen, kan forskellen mellem Lite og Balanced hurtigt løbe op i flere hundrede dollar om måneden, så det er værd at teste begge dele på et par uger med rigtig trafik, før I låser valget fast.

En praktisk tommelfingerregel, flere teams er landet på: brug Lite som standard på alle repositories, og lad kun kritiske repositories (betalingsflows, autentificering, adgangsstyring) køre på Balanced. Det giver det bedste forhold mellem dækning og pris, fordi de fleste fejl Copilot fanger, uanset niveau, er simple logikfejl, ikke dybe arkitektoniske problemer, som kræver den dyrere analyse.

Husk også, at effort-niveauet kan justeres løbende. Hvis I opdager efter en måned, at Lite overser for meget i et bestemt repository, er det en simpel indstillingsændring at skifte til Balanced for netop det repository, uden at det påvirker resten af organisationens opsætning.

Trin 7: Byg et komplet eksempelprojekt til at teste reviewet

For at se code review i aktion bygger vi en lille Node.js-API til en opgaveliste (task tracker). Opret en ny mappe og initialiser projektet.

Vi har bevidst valgt et lille, overskueligt projekt frem for noget mere komplekst. Formålet er ikke at vise, hvor avanceret Copilot kan være, men at give dig et sted at se præcis, hvilken type fejl der bliver fanget, og hvordan selve arbejdsgangen med at acceptere eller afvise forslag føles i praksis. Du kan efterfølgende genbruge samme fremgangsmåde på et rigtigt projekt i dit eget team.

mkdir copilot-review-demo && cd copilot-review-demo
npm init -y
npm install express

# Opret filstruktur
mkdir src
touch src/server.js src/tasks.js

Indsæt følgende i src/tasks.js. Koden indeholder bevidst et par svagheder, så du kan se, hvad Copilot fanger:

let tasks = [];
let nextId = 1;

function addTask(title) {
  const task = { id: nextId++, title: title, done: false };
  tasks.push(task);
  return task;
}

function getTask(id) {
  return tasks.find(t => t.id == id); // bemærk: løs sammenligning
}

function deleteTask(id) {
  tasks = tasks.filter(t => t.id !== id);
}

module.exports = { addTask, getTask, deleteTask, tasks };

Opret derefter src/server.js med et simpelt Express-endpoint, commit ændringerne, push til en ny branch, og opret en pull request på GitHub. Et minimalt endpoint, der kalder funktionerne fra tasks.js, er nok til formålet: du behøver ikke bygge en fuld REST-API med alle HTTP-metoder for at se, hvordan gennemgangen fungerer.

git checkout -b feature/task-api
git add .
git commit -m "Add basic task tracker API"
git push -u origin feature/task-api
gh pr create --title "Add task tracker API" --body "Første version af task-API'et"

Trin 8: Læs og reager på Copilots kommentarer

Når pull requesten er oprettet med automatisk review slået til, dukker Copilots kommentarer op direkte i PR’ens “Files changed”-fane efter typisk 1-3 minutter, afhængigt af effort-niveauet. I vores eksempel vil Copilot med stor sandsynlighed pege på den løse sammenligning (== i stedet for ===) i getTask, samt manglende inputvalidering i addTask, hvor en tom eller manglende titel ikke bliver afvist.

Hver kommentar har en “Commit suggestion”-knap, så du kan acceptere rettelsen direkte, uden selv at skrive koden om. Det er her funktionen virkelig sparer tid i hverdagen, fordi de små, kedelige rettelser kan klares med ét klik i stedet for en frem-og-tilbage-diskussion med en menneskelig reviewer.

Ikke alle forslag bør accepteres blindt. Hvis Copilot foreslår en ændring, der rører ved forretningslogik, et beregnet beløb, en tidszone-håndtering eller lignende, bør du altid læse forslaget grundigt, før du klikker “Commit suggestion”. AI-modellen kender ikke jeres interne regler for, hvordan for eksempel moms eller leveringsfrister skal beregnes, og den kan foreslå en teknisk set “renere” løsning, der reelt ændrer den tiltænkte opførsel.

Trin 9: Tilpas reviewet med en custom instructions-fil

Opret en fil med navnet .github/copilot-instructions.md i roden af dit repository. Her kan du beskrive projektets konventioner, så Copilot retter sig efter dem under gennemgangen, i stedet for at bruge generiske regler.

# .github/copilot-instructions.md

## Kodestandarder for dette projekt
- Brug altid strict equality (===) i stedet for ==
- Alle API-endpoints skal validere input med Zod eller tilsvarende
- Undgå console.log i produktionskode; brug den delte logger
- Nye endpoints skal have mindst én tilhørende test

Når filen er på plads, bruger både chat, agent-tilstand og code review den samme kontekst, så anbefalingerne bliver konsistente på tværs af værktøjerne. Det er især nyttigt i større teams, hvor forskellige udviklere ellers ville få forskellige typer kommentarer alt efter, hvilken editor de bruger.

Det er desuden en god idé at lade en erfaren udvikler i teamet eje filen, i stedet for at alle redigerer den løbende. Det holder reglerne konsistente og undgår, at filen vokser sig til en lang liste af modstridende ønsker fra forskellige udviklere. Det er en god vane at genbesøge filen hver anden eller tredje måned. Et projekt der starter som et simpelt REST-API, ender ofte med nye mønstre: GraphQL-endpoints, baggrundsjobs, eventbaseret arkitektur. Hvis instruktionerne ikke følger med, risikerer du, at Copilot fortsætter med at give råd, der passede til projektets tidlige fase, men ikke dens nuværende struktur.

Trin 10: Brug API’en til at trigge review fra jeres egen CI/CD-pipeline

Den nye API-adgang fra oktober 2026 betyder, at I kan kalde code review programmatisk, for eksempel fra en GitHub Actions-workflow, i stedet for udelukkende at stole på den automatiske trigger. Det giver mening, hvis I vil kombinere Copilots review med jeres egne lint- og testtrin i én samlet pipeline-rapport.

# .github/workflows/copilot-review.yml
name: Copilot Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  copilot-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Request Copilot review
        run: gh copilot review --pr ${{ github.event.pull_request.number }} --effort balanced
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Tilføj denne workflow-fil til dit repository, commit den, og den vil køre automatisk ved hver ny eller opdateret pull request. Husk at din repository-token skal have de rette tilladelser til at kalde Copilot-API’et, ellers fejler jobbet med en 403-fejl i loggen.

API-tilgangen giver også mulighed for at kombinere resultatet med jeres egne kvalitetsporte. I kan for eksempel lade pipelinen fejle, hvis Copilot finder mere end et bestemt antal “high severity”-kommentarer, eller I kan nøjes med at logge resultatet og lade mennesker træffe den endelige beslutning. Mange teams starter med den rene logning i et par uger, for at se hvor meget støj funktionen reelt genererer, før de gør den til en hård blokering i pipelinen.

Trin 11: Konfigurer code review for hele organisationen

Som organisationsadministrator kan du håndhæve code review på tværs af alle repositories i stedet for at lade hver enkelt udvikler slå det til manuelt. Gå til organisationens indstillinger, find Copilot-sektionen, og aktiver policyen “Automatically request Copilot code review” på organisationsniveau.

Hvis organisationen har flere teams med forskellige behov, kan du i stedet vælge at håndhæve policyen pr. repository-gruppe frem for globalt. Det giver et produktteam, der arbejder med kundevendte betalingsflows, mulighed for at køre strammere regler end et internt værktøjsteam, uden at den ene gruppes indstillinger spænder ben for den anden.

  • Beslut om effort-niveauet skal være ens for alle teams, eller om hvert team selv vælger.
  • Sæt et budgetloft for AI-credits pr. måned, så en travl sprint ikke giver en overraskende regning.
  • Gennemgå audit-logs månedligt for at se, hvilke repositories der bruger flest credits.
  • Informer teamet om, at Copilot-kommentarer er forslag, ikke krav. Et menneske skal stadig godkende pull requesten.

Sæt desuden en fast rutine for, hvem der ejer indstillingerne fremadrettet. Uden en tydelig ejer ender Copilot-konfigurationen ofte som noget, ingen rører ved igen, selvom både priser, effort-niveauer og tilgængelige modeller ændrer sig løbende. En kvartalsvis gennemgang af indstillingerne tager typisk under en time og sikrer, at teamet rent faktisk bruger den opsætning, der passer bedst til, hvordan de arbejder nu.

Trin 12: Optimer arbejdsgangen med avancerede tips

Når grundopsætningen kører, er der en række mindre justeringer, der gør oplevelsen markant bedre i hverdagen. De fleste af dem koster kun få minutter at sætte op, men sparer timer over en typisk sprint, fordi de fjerner gentagne, kedelige justeringer fra den daglige arbejdsgang.

  • Brug Lite-niveauet på draft pull requests og skift til Balanced, når PR’en er klar til “rigtig” gennemgang, for at spare credits undervejs i udviklingen.
  • Kombiner Copilots review med et dedikeret statisk analyseværktøj som Semgrep eller Snyk Code til sikkerhedsspecifikke fund. Copilot er godt til generelle mønstre, men er ikke en erstatning for et sikkerhedsscanning-værktøj.
  • Sæt “Review new pushes” fra i meget aktive PR’er med mange småcommits, og bed i stedet om en samlet gennemgang, når branchen er stabil, for at undgå gentagne credit-forbrug.
  • Brug .github/copilot-instructions.md til at liste kendte false positives, så Copilot ikke bliver ved med at flage samme ikke-problem igen og igen.
  • Eksporter audit-logs til jeres BI-værktøj, hvis I har mere end 50 udviklere, så I kan se forbrugsmønstre pr. team over tid.

5 almindelige faldgruber, du skal undgå

De fleste problemer med Copilot code review handler ikke om selve AI-modellen, men om opsætningen omkring den. Her er de fem mest almindelige fejl, samlet fra teams der har kørt funktionen i produktion i flere måneder.

  • At bruge Balanced-niveau på alle PR’er fra dag ét. Det driver credit-forbruget unødigt højt, især i teams der merger mange små PR’er dagligt. Start med Lite, og eskaler kun hvor det giver værdi.
  • At glemme at opdatere Copilot Chat-extensionen i Xcode. Uden version 0.41.0 eller nyere fejler code review helt uden en tydelig fejlbesked, hvilket får mange til at tro, at funktionen ikke er understøttet.
  • At stole blindt på Copilots kommentarer. Funktionen fanger mønstre, den har set før, men overser ofte domænespecifik forretningslogik. Et menneske skal stadig læse diffen.
  • At aktivere automatisk review på et repository med meget store, sjældne commits. Store diffs (flere tusinde linjer) giver ofte overfladiske eller generiske kommentarer, fordi modellen skal dække for meget på én gang.
  • At ikke sætte et budgetloft. Uden et loft på organisationsniveau kan et enkelt team med mange PR’er bruge en uventet stor andel af den samlede AI-credit-pulje.

Fejlfinding: 8 almindelige problemer og løsninger

Her er de problemer, der oftest dukker op i de første uger efter opsætning, og hvordan du løser dem. Listen er samlet ud fra de mest typiske spørgsmål, der går igen i supportfora og interne Slack-kanaler, når et team først er begyndt at bruge funktionen i stor skala.

  • Copilot reviewer ikke automatisk nye PR’er. Tjek at policyen “Automatically request Copilot code review” faktisk er slået til under repository-indstillinger, ikke kun under din personlige profil.
  • Fejlen “403 Forbidden” i CI-workflowet. Din GitHub Actions-token mangler rettigheder til Copilot-API’et. Tilføj de nødvendige scopes til din PAT, eller brug en GitHub App med korrekt tilladelse.
  • Xcode viser ingen review-knap. Opdater GitHub Copilot Chat-extensionen til version 0.41.0 eller nyere via Xcode’s extension-manager.
  • JetBrains-plugin’et logger ikke ind. Slet den cachede token under Settings > Tools > GitHub Copilot > Sign out, og log ind igen fra bunden.
  • Reviewet tager over 10 minutter. Det sker typisk ved meget store PR’er. Del commitet op i mindre, logiske pull requests i stedet.
  • Credits forbruges hurtigere end forventet. Skift effort-niveau fra Balanced til Lite for rutinemæssige ændringer, og gem Balanced til større features.
  • Copilot-kommentarer dukker op flere gange på samme linje. Dette sker, når “Review new pushes” er slået til sammen med meget hyppige småcommits. Slå indstillingen fra, eller squash dine commits før push.
  • VS Code viser Copilot-ikonet som gråt/inaktivt. Log ud og ind igen via statuslinjen, og tjek at din internetforbindelse ikke blokerer github.com via en firewall eller VPN.

Copilot code review sammenlignet med dedikerede reviewværktøjer

Copilot er ikke det eneste AI-drevne reviewværktøj på markedet, og det er værd at kende forskellen, før du vælger retning for hele teamet. Mange teams ender med at bruge flere værktøjer parallelt frem for at vælge ét frem for alle andre, fordi de dækker forskellige dele af kvalitetsprocessen.

VærktøjIntegreret i GitHubKræver separat kontoPrimær styrke
GitHub Copilot Code ReviewJa, nativtNej (del af Copilot)Tæt integration, lav friktion
CodeRabbitVia appJaDybere PR-opsummeringer
SemgrepVia app/CIJaRegelbaseret sikkerhedsscanning
Snyk CodeVia app/CIJaSårbarhedsdatabase og licenstjek

Konklusionen fra de fleste teams, der har testet begge dele, er at Copilot code review er stærkest som første filter, det hurtige og billige sikkerhedsnet der fanger de oplagte fejl, mens et dedikeret sikkerhedsværktøj som Semgrep eller Snyk Code tager sig af de mere specialiserede sårbarhedstjek.

Hvad Copilot Code Review fanger, og hvad den overser

Det er værd at have et realistisk billede af, hvad funktionen rent faktisk er god til, før du bygger jeres kvalitetsproces op omkring den. Copilot er generelt stærk til at opdage mønstre, den har set tusindvis af gange før i offentlig kode: manglende null-tjek, ubrugte variabler, inkonsekvent fejlhåndtering, simple logikfejl som løse sammenligninger, og oplagte sikkerhedsproblemer som rå SQL-strenge eller manglende input-sanitisering.

Til gengæld overser funktionen ofte det, der kræver forretningsmæssig kontekst, erfaring fra tidligere incidents i netop jeres system, eller viden om hvordan en bestemt kunde bruger produktet på en uventet måde. Den ved for eksempel ikke, hvordan jeres specifikke momsberegning skal se ud, hvilke kunder der må se hvilke data, eller hvorfor en bestemt timing-forsinkelse er indsat med vilje for at undgå rate-limiting hos en ekstern leverandør. Den fanger heller ikke altid race conditions, der kun opstår under høj belastning, fordi den analyserer koden statisk og ikke kører den.

Den praktiske konsekvens er, at code review bør ses som et filter, der fjerner den nemme, lavthængende frugt, så jeres menneskelige reviewere kan bruge deres tid på de spørgsmål, der faktisk kræver domæneviden: er denne ændring den rigtige løsning på problemet, passer den ind i den samlede arkitektur, og har vi tænkt på de brugere, der rammer edge cases?

Databehandling og compliance: hvad sker der med jeres kode

For danske virksomheder, især i regulerede brancher som finans og sundhed, er det naturligt at spørge, hvor koden rent faktisk bliver behandlet, når Copilot laver en gennemgang. Koden i din pull request sendes til GitHub og Copilots underliggende model-infrastruktur for at blive analyseret, og resultatet (kommentarerne) gemmes sammen med selve pull requesten i jeres repository.

Hvis I arbejder med persondata eller forretningshemmeligheder direkte i kildekoden (hvilket generelt er dårlig praksis uanset AI-værktøjer), bør I overveje, om Copilot Enterprise’s udvidede databehandlingsvilkår og audit-logging giver jer den kontrol, compliance-afdelingen kræver. Business- og Pro-planerne har ikke samme niveau af detaljeret logning som Enterprise-planen.

Tal med jeres data protection officer eller IT-sikkerhedsansvarlige, før I ruller code review ud bredt i en organisation med følsomme systemer. De fleste danske virksomheder har allerede en proces for at godkende nye SaaS-værktøjer, og Copilot code review bør gå gennem den samme vurdering som ethvert andet værktøj, der får adgang til jeres kildekode.

En god tommelfingerregel, uanset plan: hold hemmeligheder, adgangskoder og personfølsomme testdata ude af kildekoden og brug i stedet miljøvariabler, secrets managers og anonymiserede testdatasæt. Det beskytter jer ikke kun mod risici relateret til AI-værktøjer, men er god praksis uanset hvilken reviewer, menneskelig eller AI-baseret, der kigger på koden.

Ofte stillede spørgsmål

Virker GitHub Copilot code review på GitLab eller Bitbucket?
Nej, funktionen er bundet til GitHub og virker kun på pull requests i GitHub-repositories. Hvis dit team bruger GitLab eller Bitbucket, skal I se mod andre AI-reviewværktøjer, der er bygget til de platforme specifikt.

Koster code review ekstra oven i min Copilot-plan?
Nej, men hver gennemgang trækker på din plans delte pulje af AI-credits, ligesom chat og agent-funktionerne gør.

Kan jeg bruge code review uden at have Copilot slået til i min editor?
Ja. Automatisk review kører på GitHub-siden, uanset om du selv har Copilot installeret lokalt i VS Code eller en JetBrains-IDE. Det betyder, at selv teammedlemmer, der foretrækker en helt anden editor, stadig får gavn af funktionen, så længe deres pull requests havner på GitHub.

Hvilket effort-niveau bør jeg vælge som standard?
Start med Lite til almindelige ændringer, og brug Balanced på pull requests, der rører ved sikkerhed, autentificering eller betalingslogik.

Kan Copilot code review erstatte en menneskelig reviewer helt?
Nej. Funktionen er designet som et supplement, der fanger oplagte fejl hurtigt, men den forstår ikke altid forretningslogik eller produktkrav på samme måde som en kollega. De fleste teams, der bruger funktionen godt, holder fast i, at mindst én menneskelig godkendelse stadig er påkrævet, før en pull request kan merges.

Hvordan slår jeg code review fra igen, hvis det ikke passer vores team?
Gå til repository- eller organisationsindstillingerne under Copilot, og deaktiver policyen “Automatically request Copilot code review”.

Virker custom instructions-filen også for code review, eller kun for chat?
Filen .github/copilot-instructions.md bruges af både chat, agent-tilstand og code review, så den samme kontekst gælder på tværs.

Er API-adgangen til code review tilgængelig på alle planer?
Ja, API-adgangen blev åbnet for alle betalte planer fra oktober 2026, men forbruget trækker stadig på den enkelte plans credit-pulje.