Copilot kodgranskar nu stora och botskapade pull requests: kontrollera kostnad och täckning

Börja med policy och betalningsägare

En bot har inget vanligt Copilot-licensierat konto som automatiskt kan bära granskningen. GitHubs ändringslogg kopplar därför automatisk granskning av bot-PR:er till policyn Allow members without a Copilot license to use Copilot code review in GitHub.com och anger att användningen då kan faktureras direkt till organisationen. Den aktuella dokumentationen kräver dessutom att AI credits paid usage är aktiverad först. Underpolicyn är avstängd som standard.

Gör inte policyknappen till första steget. Namnge först en ägare för AI-krediter, en gräns för provet och den organisation samt det repository som ska omfattas. GitHubs användningsdokumentation säger att bot- eller Actions-skapade PR:er kan hänföras till den användare som startade arbetsflödet om personen kan identifieras, annars till en utsedd betalningsägare. Kontrollera därför resultatet i användningsrapporten efter provet; här räcker inte en gissning utifrån botnamnet.

Bygg ett prov som visar vad som faktiskt kördes

Välj ett avgränsat repository och låt en känd bot skapa en pull request med en ofarlig ändring. Beskriv förväntad risk i PR-texten, till exempel en avsiktligt saknad null-kontroll i testkod, så att teamet kan bedöma om kommentaren är relevant utan att lägga produktionsdata eller hemligheter i försöket. Begär automatisk granskning med samma inställning som den planerade driften och spara PR-länk, commit-SHA, botidentitet, klockslag och vald effort-nivå.

GitHub beskriver Lite som standardläget och Balanced som en längre analys för bland annat komplex logik, säkerhetskänslig kod och ändringar över flera tjänster. Balanced använder fler AI-krediter och kan använda marginellt fler Actions-minuter. Det valda läget i konfigurationen är dock inte ensamt bevis: spara effort-läget från PR-översiktens kommentar för varje faktisk körning.

En synlig recension kan vara ett begränsat fallbackläge

Copilot cloud agent-PR:er kan nu få full agentisk automatisk granskning i stället för den tidigare begränsade upplevelsen. De agentiska funktionerna använder GitHub Actions för bland annat projektkontext. Om Actions är otillgängligt eller Copilots arbetsflöde fallerar skapas enligt dokumentationen ändå en recension, men utan dessa extrafunktioner. Om organisationen har stängt av GitHub-hosted runners faller granskningen också tillbaka, om du inte har konfigurerat self-hosted runners.

Kontrollera därför två bevis, inte bara den gröna bocken i PR:n: vilket effort-läge översiktskommentaren anger och om Actions-körningen som bar den agentiska delen lyckades. En kommentar från Copilot visar att någonting kördes. Den visar inte på egen hand vilken repositorykontext eller vilka verktyg som faktiskt fanns tillgängliga.

Borttagen storleksgräns betyder inte full filtäckning

Den tidigare gränsen på 300 filer eller 20 000 kodrader är borta, men GitHubs dokumentation undantar fortfarande vissa filtyper från code review. Den nämner dependency management-filer som package.json och Gemfile.lock, loggfiler och SVG-filer. En stor PR kan alltså accepteras som helhet samtidigt som säkerhets- eller driftkritiska delar av diffen inte granskas av Copilot.

Gör en enkel diffinventering efter varje prov. Lista alla ändrade filer, markera de dokumenterade undantagen och jämför sedan mot Copilots kommentarer. Om PR:n till exempel byter applikationskod, låsfil och en genererad SVG ska protokollet uttryckligen säga att låsfilen och SVG-filen behöver annan kontroll. Formulera inte resultatet som ”PR:n granskad” när beviset egentligen är ”Copilot kördes mot de filer tjänsten omfattar”.

Behåll en mänsklig merge-grind

GitHub säger uttryckligen att Copilot inte garanteras hitta alla problem, ibland gör fel och ska kompletteras med mänsklig granskning. Använd därför den automatiska recensionen som ett extra signalsteg, inte som godkännande. En människa ska fortfarande kontrollera krav, behörighetsgränser, testbevis, undantagna filer och om ändringen hör hemma i samma pull request.

För den bredare metoden kan du använda Monkeybases guide om sju frågor för granskning av AI-genererad kod. Om provet omfattar modell- och organisationsstyrning bör du också dokumentera ägarskapet tillsammans med kontrollen av GitHub Copilots globala modellpolicy. Nyhetens stoppregel är snävare: slå inte på automatisk granskning för fler repositoryn förrän ett botprov visar rätt policy, rätt betalningsägare, rätt granskningsläge, en synlig lista över undantagna filer och en namngiven mänsklig granskare.