Sådan bruger du AI-kodegennemgang før en pull request

En kommentar fra en AI-kodegennemgang er ikke et facit. Den er en påstand om, at en bestemt ændring kan give en bestemt fejl. Dit næste skridt er derfor ikke at acceptere eller afvise kommentaren på mavefornemmelsen. Gør påstanden til en lille test, kør testen, og træf først derefter beslutningen: flet, ret eller send videre til menneskelig vurdering.

Metoden virker, uanset om kommentaren kommer fra GitHub Copilot eller et andet værktøj. Men knapper, adgang og automatisk genkontrol varierer. GitHub oplyser eksempelvis, at Copilot code review afhænger af abonnement og organisationens indstillinger. GitHub understreger også, at værktøjet kan overse problemer eller tage fejl, og at kommentarerne skal valideres og suppleres med menneskelig gennemgang.

Start med én kommentar, der kan modbevises

Vælg en kommentar om konkret adfærd. Det kan være:

• en løkke, der springer et element over
• en dato, der behandles i den forkerte tidszone
• en tom værdi, der giver en fejl
• en adgangskontrol, der ikke dækker en bestemt rolle

Omskriv kommentaren til denne form:

Med input X forventer vi Y. Den aktuelle kode giver ifølge kommentaren Z.

Nu har du en påstand, som kan testes. En formulering som “denne kode kan måske være problematisk” er derimod for vag. Find den konkrete linje, det konkrete input og den synlige konsekvens, før du ændrer koden.

Et lukket eksempel: Løkken efterlader det tredje element

Forestil dig en funktion, der skal tømme en liste. AI-gennemgangen peger på en mulig indeksfejl i denne konstruerede JavaScript-kode. Gem hele eksemplet som empty-list-test.mjs:

import assert from "node:assert/strict";

function emptyListFaulty(items) {
  for (let i = items.length - 2; i >= 0; i--) {
    items.splice(i, 1);
  }
  return items;
}

function emptyList(items) {
  for (let i = items.length - 1; i >= 0; i--) {
    items.splice(i, 1);
  }
  return items;
}

if (process.argv[2] === "faulty") {
  assert.deepEqual(emptyListFaulty(["første", "andet", "tredje"]), []);
} else if (process.argv[2] === "corrected") {
  assert.deepEqual(emptyList([]), []);
  assert.deepEqual(emptyList(["første"]), []);
  assert.deepEqual(emptyList(["første", "andet", "tredje"]), []);
  console.log("Alle tre rettede tests bestod.");
} else {
  throw new Error("Brug argumentet faulty eller corrected.");
}

Kommentaren kan omskrives til en præcis påstand:

Når listen indeholder tre elementer, starter løkken ved indeks 1. Elementet ved indeks 2 bliver derfor ikke slettet.

Kør først tre-elementtesten af den fejlbehæftede funktion:

node empty-list-test.mjs faulty

Testen skal fejle, fordi den fejlbehæftede funktion returnerer:

["tredje"]

Det er nok til at afvise en fletning i denne tilstand. Den rettede emptyList starter ved items.length - 1, så det sidste element også bliver slettet. De tre sidste assertioner kontrollerer den rettede funktion med en tom liste, en liste med ét element og den samme tre-elementliste.

Kør derefter testene af den rettede funktion:

node empty-list-test.mjs corrected

Kommandoen skal afslutte uden en assertionfejl og skrive Alle tre rettede tests bestod. Hvis de tilsvarende tests og de relevante eksisterende tests også består i projektets rigtige testmiljø, er den konkrete fejl rettet. Bed så om en ny kodegennemgang af den ændrede pull request. Flet ikke alene på baggrund af den første AI-kommentar eller den foreslåede rettelse.

Eksemplet er konstrueret og illustrerer forventet JavaScript-adfærd. Det er ikke en udført test i dit projekt.

Brug testresultatet til at vælge næste skridt

Testen afgør ikke nødvendigvis hele pull requesten. Den afgør, hvad du gør med den konkrete kommentar.

Flet først, når påstanden er afkræftet eller fejlen er rettet

Hvis testen består med den oprindelige kode, så kontrollér først, at testen faktisk rammer den gren, AI’en beskrev. En grøn test med forkert input afkræfter ingenting. Når testen dækker påstanden, og de øvrige aftalte kontroller og menneskelige godkendelser er på plads, kan kommentaren markeres som behandlet.

Ret og kør igen, når testen viser fejlen

Hvis testen fejler på den beskrevne måde, har kommentaren ført til et reproducerbart problem. Ret den mindst mulige del af koden, behold testen som regressionsbeskyttelse, og kør både den nye test og de relevante eksisterende tests. Ved en væsentlig ændring bør pull requesten gennemgås igen. GitHub anbefaler manuel genkontrol før fletning, når ændringerne er omfattende, og dokumenterer, hvordan en ny Copilot-gennemgang kan anmodes efter nye commits.

Bed et menneske vurdere sagen, når testen ikke kan afgøre den

Nogle kommentarer handler ikke kun om observerbar programadfærd. Send sagen til en relevant kollega, hvis den afhænger af forretningsregler, sikkerhed, persondata, migrationsrisiko eller arkitektur, som ikke kan afgøres med den lille test. Gem AI-kommentaren, dit testinput, resultatet og det åbne spørgsmål. Så skal revieweren ikke begynde forfra.

Giv kun værktøjet den adgang, gennemgangen kræver

En kodegennemgang kræver adgang til kode og ofte kontekst fra resten af projektet. Det betyder ikke, at værktøjet automatisk skal have adgang til alle repositories, secrets eller produktionsmiljøer. Vælg det mindst mulige repository- og organisationsscope, og følg arbejdspladsens regler for fortrolig kode. Se også guiden om adgang og godkendelser til en AI-assistent, hvis du skal afgrænse adgang, før værktøjet kobles til projektet.

Gem fire ting i pull requesten

Når kommentaren er behandlet, bør en anden reviewer kunne følge beslutningen uden at gætte. Notér kort:

1. AI-kommentarens konkrete påstand.
2. Det input, der skulle udløse fejlen.
3. Det forventede og observerede resultat.
4. Beslutningen: flet, ret eller menneskelig vurdering.

I løkkeeksemplet er noten enkel: Tre elementer ind, tredje element blev stående, løkken blev rettet, testen blev kørt igen, og en ny gennemgang blev anmodet. Pull requesten skal ikke flettes, før den aftalte menneskelige review- og testproces også er afsluttet.

Kilder

• GitHub Docs: About GitHub Copilot code review, hentet 6. oktober 2026.
• GitHub Docs: Using GitHub Copilot code review on GitHub, hentet 6. oktober 2026.
• GitHub Docs: Use GitHub Copilot code review across the pull request lifecycle, hentet 6. oktober 2026.