Automatiserad kodgranskning 2026: Få den att köras på varje PR utan att köpa en plats.

Automatisk kodgranskning är ett CI-jobb som skickar din diff till en språkmodell, publicerar fynd på de berörda raderna och får en statuskontroll att misslyckas när det hittar något allvarligt. För att få igång det vid varje pull request utan en prenumeration per användare kan du själv-host:a en öppen källkods-harness: kopiera ett workflow på ungefär femton rader till ditt repository, lägg till en API-nyckel och betala bara för de tokens varje granskning förbrukar. Det finns inget platsantal att köpa, för det finns inga platser. Referensimplementationen som vi underhåller är Orca-Code-Review-repositoryt — publikt, MIT-licensierat och koden bakom OrcaCode Review GitHub Action sedan det skapades den 25 juni 2026. Dess medföljande routingrecept använder DeepSeek V4 Flash som standard för granskningspasset och GLM-5.3 som oberoende verifieringsdomare, och båda kan du ändra. Den här artikeln går igenom vad som faktiskt körs vid varje push, vad du konfigurerar, vad det kostar i tokens och de felscenarier du kommer att stöta på i vecka två.

Den korta versionen. Varje push får en granskning. Fynd publiceras inline på de ändrade raderna. P0- och P1-fynd får kontrollen att misslyckas och blockerar merge; en ren körning går igenom. Du kan begära en ny granskning genom att kommentera /orcacode-review. Arbetsflödet ligger i ditt repo; granskningslogiken ligger i den publicerade action; modellvalet ligger i ett routingrecept som du kan redigera i din egen arbetsyta. Granskaren läser diffen och repofilerna och exekverar aldrig koden i din PR. Och den ärliga brasklappen på förhand: den fångar riktiga buggar men missar fortfarande de som kräver en människa som vet varför koden är som den är.

• Ett arbetsflöde + en hemlighet + en token-räkning. Ingen per-användarlicens någonsin.

• Testmiljön är öppen källkod. Kopiera den, fork:a den, granska den, fäst den vid en commit-SHA.

• Modellen är en inställning, inte en leverantör. Ändra granskaren genom att redigera ett routingrecept, inte genom att skriva om YAML eller bumpa åtgärden.

• Överstora diffar kostar ingenting. Storlekskontrollen körs innan modellen.

• Den läser din kod, men kör den aldrig. Det är den säkerhetsegenskap som gör pull_request_target säker att använda överhuvudtaget.

Hur automatiserad kodgranskning faktiskt fungerar

Varje automatiserat granskningssystem är samma tre ingredienser i olika kläder: en händelse, en körning och en granskare.

Händelsen är utlösaren. Det medföljande arbetsflödet utlöses av pull request-händelser — opened, synchronize (en ny push), ready_for_review (en draft blir redo) — och av en PR-kommentar. Eftersom det körs med pull_request_target, läses arbetsflödesdefinitionen från basgrenen, vilket är anledningen till att arbetsflödet måste finnas på basgrenen innan det kan köras för en PR. En granskning per push; concurrency-blocket avbryter den tidigare körningen, så en snabb serie pushar köar inte fem granskningar av föråldrad kod.

nlöpare är GitHub Actions på ubuntu-latest. Jobbet behöver tre behörigheter: läsbehörighet till contents, skrivbehörighet till pull requests (för att posta inline-kommentarer), och skrivbehörighet till issues (för att posta sammanfattningen och rensa bort föråldrade kommentarer).

Den granskaren är en språkmodell. Åtgärden hämtar PR-headen, sammanställer diffen och den repositorykontext som motorn väljer, och skickar det till granskningsmodellen. Resultatet är en uppsättning fynd, var och en taggad med en allvarlighetsgrad och förankrad i en fil och rad. Åtgärden publicerar dem som inline-kommentarer på PR:n och skriver en sammanfattande kommentar i en markörregion överst i PR-beskrivningen, som ersätts på plats vid varje push.

Grinden är en statuskontroll. GitHub vet inte vad “granskning” betyder; den vet bara om granskningskontrollen är godkänd. Du gör grinden verklig genom att markera den kontrollen som obligatorisk i branch protection. Det är hela mekanismen för att blockera merge — inga admin API-anrop, inga etiketter, bara en misslyckad obligatorisk kontroll.

Vad som inte händer: ingenting exekverar PR:ns kod. Motorn läser bara. Den enda invarianten är det som gör den privilegierade pull_request_target-utlösaren säker att använda med en betald API-nyckel.

Det öppna källkodsramverket är det som gör skillnaden.

Allt ovanstående gäller för många verktyg. Det som inte gäller för de flesta är att hela paketet är inspekterbart och självhostbart, vilket är vad Orca-Code-Review-repositoriet ger dig. Det är ett offentligt MIT-licensierat GitHub-repositorium (JavaScript, skapat den 25 juni 2026) som paketerar granskningen som en återanvändbar sammansatt GitHub Action plus en installatör, och det är samma kod som den hostade OrcaCode Review-appen kör.

Lägg {{1}}tio minuter på trädet{{/1}} så kan du namnge varje del som rör din PR{{2}}{{/2}}:

• action.yml — den sammansatta actionen, med ungefär femton dokumenterade indata. Inga modellnamn är hårdkodade någonstans i den.

• workflows/orca-code-review.yml — exempelkonsumentarbetsflödet, de ungefär femton raderna du kopierar in i .github/workflows/.

• recipes/ — routing-DSL:en. Det är här som modellen faktiskt väljs.

• rules/ — allvarlighetsgraderingen (P0–P3), det obligatoriska utdataformatet och ett konventionsdirektiv som matar in projektets eget konventionsdokument i granskningen som ej betrodd referensdata.

• scripts/ — precisionfiltret (L1 plus en L2-domare), diffvakten, mergegrinden, körningsrapporten och tokenmätaren. Var och en är en liten, läsbar .mjs-fil med tester.

• skills/setup-orca-code-review — färdigheten som installationsprogrammet lägger in i din kodningsagent, och som täcker installation, omkonfigurering, felsökning och avinstallation.

• .claude-plugin/ — det som gör att Claude Code kan installera skillen som ett självuppdaterande plugin.

Att installera är en enda rad som lär din AI vad produkten är och slutar sedan:

npx @orcarouter/code-review

CLI:n identifierar vilka kodagenter du använder — katalogen täcker 36 plattformar, från Claude Code, Cursor, Codex, OpenCode och Windsurf till GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode och andra — installerar skillen och lämnar över. Du frågar sedan din agent i klartext: “sätt upp OrcaCode Review i det här repot,” “blockera bara P0,” “varför kördes inte granskningen?” Skillen tar hand om hela livscykeln: den skriver arbetsflödet, guidar dig genom API-nyckeln, sätter gate:n och ställer bara de frågor som verkligen är dina.

Claude Code kan istället installera färdigheten som ett plugin, vilket håller den uppdaterad när repot flyttas:

Lägg till Continuum-AI-Corp/orca-code-review på pluginmarknadsplatsen.

/plugin install orca-code-review

Ingen agent alls? Samma livscykel är helt enkelt underkommandon — init skriver arbetsflödet, reconfigure ändrar blockeringsregler och diffgränser, doctor diagnostiserar granskningar som inte körs eller inte postas, uninstall tar bort det (först tas den obligatoriska checken bort). Färdigheten är huvudingången, inte den enda dörren. Eller koppla in det manuellt: kopiera arbetsflödet, lägg till en hemlighet som heter ORCAROUTER_API_KEY, och markera review-checken som obligatorisk.

Under huven ligger Ali​babas Open Code Review, låst till exakt version och licensierad under Apache-2.0. OrcaCode bestämmer hur granskningen går till; OrcaRouter bestämmer vilken modell som kör den. Kostnadsjämförelsen mellan självhostning och molnhostning — vad “gratis” egentligen kostar när du självhostar en granskare med öppen källkod — går vi igenom i vår artikel om öppen kodgranskning.

Vad körs, i ordning, vid varje push

Det hjälper att känna till ordningen, eftersom varje steg kan misslyckas eller hoppas över oberoende:

• Diff-guarden körs först, innan modellen någonsin gör det. Om merge-base-diffen överstiger 512 KB eller rör fler än 300 filer, hoppas granskningen över och ett meddelande publiceras. Standardvärdet är on-oversized-diff: fail, så en diff som har blåsts upp bortom gränserna kan inte passera en obligatorisk grind utan granskning. Detta är också kostnadskontrollen: en överdimensionerad PR kostar noll tokens.

• Motorn granskar diffen. En genomgång, där samtidigheten per fil som standard är 24, med en övre gräns på 20 minuters väggklockstid per genomgång.

• Precisionsfiltret efterbehandlar råfynden. L1, ett deterministiskt filter, verifierar varje fynds påstådda befintliga kodavsnitt mot den granskade commiten och omplacerar eller kasserar avvikelser. L2, en LLM-domare, klustrar fynd efter grundorsak och kasserar kluster med låg konfidens. Båda lagren är soft-fail: vid ett fel behålls föregående stegs fynd och granskningen avbryts aldrig.

• Porten gäller. P0- och P1-fynd får kontrollen att misslyckas; PR-sammanfattningen räknar varje fynd, inklusive de som är tystade från diffen.

• Mätaren skriver ut vad det kostade. Mätarens indata registrerar tokenredovisning per anrop — prompt, completion, cachade tokens och den modell som routern fastställde — och skriver ut en totalsammanställning i jobbloggen.

• En valfri körningsrapport skickar antal per allvarlighetsgrad och gate-metadata till OrcaRouter-kontrollplanet för analysinstrumentpanelen. Den innehåller varken kod, diff eller fyndtext.

Vad du faktiskt konfigurerar

Det finns tre ytor, och de har mycket olika sprängradie.

1. Arbetsflödesfilen. Konsumentarbetsflödet är avsiktligt tunt. De indata som är värda att justera finns i action: block-on (vilka allvarlighetsnivåer som får kontrollen att misslyckas — standard P0,P1), fix-first (vilka allvarlighetsnivåer som avbryter en uttömmande granskning i förtid), auto-review-authors (en tillåtelselista för vilka som får automatisk granskning), max-diff-kb och max-diff-files och on-oversized-diff (storleksskyddet), timeout-minutes, concurrency, meter, och report. Alla har en dokumenterad standard, så ett nytt arbetsflöde är fem rader YAML plus en hemlighet.

2. Instrumentpanelen. Med settings: true (standard), varje körning hämtar per-repository-inställningar från OrcaRouter → Apps → OrcaCode Review: modellen, granskningsläge, mergepolicy, rapportallvarlighetsgrader, tyst läge, uttömmande granskning, en anpassad bedömningsmatris och skyddsräcken. Ställ in settings: "false" och arbetsflödesfilen är auktoritativ — inget instrumentpanelsvärde kan åsidosätta den. Om du aldrig öppnar konsolen förlorar du inget av verktyget; du konfigurerar bara i YAML.

3. Routingreceptet — det som alla missar. Actionen namnger aldrig en modell. Istället injicerar den råa fakta som requestheaders — vilken nivå körningen registrerades som, om föregående genomgång hittade en P0/P1, och en linsmarkör när begäran är L2-domaren — och arbetsyterouterns DSL-recept mappar dessa headers till en konkret modell. Standardreceptet anger DeepSeek V4 Flash som standard för granskningen och GLM-5.3 för domaren, och routar medvetet de två till separata modeller. Att ändra modellen som granskar din kod är en redigering av det receptet i din egen arbetsyta: ingen action-versionsökning, ingen YAML-omskrivning, ingen ny driftsättning.

Allvarlighetskontraktet är två oberoende inställningar, inte en. Sammanslagningspolicy avgör vad som blockerar sammanslagningen; rapportens allvarlighetsgrader avgör vad som publiceras på diffen. De levererade standardvärdena är att P0/P1 blockerar och P2/P3 godkänns. En allvarlighetsgrad som blockerar publiceras alltid, oavsett vad rapportinställningen säger — en misslyckad kontroll utan något på diffen som förklarar den är värre än en högljudd sådan. P0 innebär en utnyttjbar säkerhetsbrist, dataförlust, en krasch på en normal exekveringsväg eller ett trasigt bygge; P1 innebär en verklig men avgränsad bugg; P2 innebär en äkta defekt som bara utlöses under ett onormalt förhandsvillkor; P3 är stil. När man är osäker mellan två nivåer säger reglerna att man ska välja den lägre.

Vad det kostar

Per token, inte per säte. Du väljer modellen på OrcaRouter, faktureringen sker per förbrukad token, och mätaren gör kostnaden per körning synlig istället för mystisk. GitHub-mekaniken, Copilots mätbaserade kodgranskning sedan 1 juni 2026, och hur tredjepartsgranskare passar in i det arbetsflödet behandlas i vår guide till GitHub-kodgranskning. Hela fält-för-fält-kostnadsjämförelsen — produkter per säte jämfört med per token, med ett räkneexempel — finns i vår jämförelse av AI-kodgranskningsverktyg, och frågan om vad en enskild granskningsomgång kostar i token när granskaren faktiskt utforskar repositoryt (bot-vs-agent-distinktionen) finns i vår artikel om kodgranskningsagenter. Poängen denna artikel tillför är hur fakturan ser ut: den skalar med koden du granskar, inte med antalet anställda som granskar den.

Två utgiftskontroller är viktiga från dag ett. På ett offentligt repository, pull_request_target kringgår GitHubs godkännandespärr för forks, och granskningsnyckeln är plånboksdebiterad — en främling kan öppna en PR och utlösa betalda granskningar. Sätt en plånboksbudget med aviseringar på nyckeln, och sätt auto-review-authors till något i stil med OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR så att okända bidragsgivare inte auto-granskas. Och diff-skyddet, som nämnts, innebär att överdimensionerade PR:er inte kostar något alls.

Vad går sönder?

Automatiserad granskning är CI. Den fallerar som CI, och felfallen är mestadels inte modellens fel:

• Arbetsflödet körs aldrig. För pull_request_target arbetsflödet läses från basgrenen — ett arbetsflöde som bara lagts till i PR-grenen körs inte förrän det slås samman. Kontrollera också att appen är aktiverad, auto_review är på, PR inte är ett utkast (utkast hoppas över i ready_for_review-läge) och att Actions är aktiverade i arkivet (forkade arkiv har dem avstängda från början).

• /orcacode-review gör ingenting. Kommentarutlösaren kräver att kommentaren börjar med en av fyra stavningar — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — och att kommenteraren är en OWNER, MEMBER eller COLLABORATOR. Ett inledande mellanslag bryter matchningen. En extern bidragsgivares kommando ignoreras tyst, medvetet: kommandot kör ett privilegierat arbetsflöde som innehar den betalda nyckeln.

• Ett autentiseringsfel. Hemligheten har fel namn eller saknas, nyckeln är återkallad eller har överskridit sin budget, eller så byttes arbetsflödet till pull_request (som inte kan läsa hemligheter från forks).

• Kontrollen är röd med ett meddelande om “diff too large”. Det är storleksskyddet, som fungerar enligt konfigurationen. Dela PR:en, eller höj gränserna, eller sätt on-oversized-diff: pass — och förstå att med en obligatorisk kontroll innebär pass att en tillräckligt stor PR går rakt igenom grinden utan granskning.

• Granskningen körs, men inga kommentarer visas. Tre orsaker, alla ofarliga eller konfigurerade: en ren körning publicerar en sammanfattning i stället för inline-kommentarer; tyst läge tystar P2 vid publicering (grinden och rapporten räknade fortfarande med den); eller precisionsfiltret filtrerade bort fynden — L1 tar bort fynd vars snippet inte matchar commiten, L2 tar bort kluster med låg konfidens. Jobbloggens allvarlighetsantal talar om vilken.

Säkerhetsläget är värt att anges tydligt, eftersom det är detta som gör hela designen säker. Motorn läser endast diff- och repositoryfilerna; den kör aldrig PR-koden. Granskaren har ingen merge-behörighet — fynd kan blockera en merge eller lägga till en kommentar, men ingen kodväg tillåter modellens utdata att godkänna eller ändra repositoryt. Ett otaggat fynd är felsäkert och behandlas som blockerande snarare än rådgivande. Och körningsrapporten innehåller ingen kod eller fyndtext. Det tvåskiktade upplägget som fångar det en engångsgranskning missar är ämnet för vår artikel om AI-kodgranskning och säkerhet; hotmodellen ovan är dokumenterad i repositoryts SECURITY.md.

När automatisk granskning är fel verktyg

Det är fel oftare än vad verktygsleverantörerna medger. Avstå från den här när:

• Problemet är kontexten, inte volymen. Om granskningar är långsamma eftersom granskare måste förstå varför koden skrevs på det här sättet, tillför en LLM som läser diffen lite. Den har inget minne av förra månadens tråd och ingen känsla för systemets historia.

• Diffen består mestadels av genererad eller incheckad kod. Autoformaterad utdata, skelettfiler, beroendesnapshot. Att granska det förbrukar tokens och skapar brus, och det är precis där som konventionsdirektivet hjälper minst — koden är inte projektets stil avsiktligt.

• Teamet granskar redan allt i par. Automatiserad granskning är en hävstång för volym. Om varje ändring redan granskas av en människa som var med i rummet, tillför maskinen en andra åsikt som oftast är mindre välinformerad än den första.

• Ingen läser slutsatserna. En granskning som ingen agerar på är ett arbetsflöde som alltid misslyckas genom att vara grönt. Detta är det vanligaste tysta felet, och inget precisionsfilter åtgärdar det.

• Granskningen måste köra koden. Om det du behöver är en testsvit mot PR:n är en LLM-granskning fel verktyg. Den läser; den kör inte. En säkerhetsskanning som behöver bygga och köra artefakten hör hemma i ett separat, omsorgsfullt avgränsat jobb — kom ihåg att granskningsarbetsflödet aldrig får utökas för att köra PR-styrd kod.

• Repositoryt är litet eller tillfälligt. Under en viss ändringstakt är granskningen mer overhead än buggarna den fångar.

Falska positiva, och vad precisionsfiltrering åtgärdar och inte åtgärdar.

Anklagelsen mot varje AI-granskare är att den ropar varg. Testramen angriper detta i två lager, och det hjälper att vara precis om vilket lager som åtgärdar vilket fel.

Det deterministiska lagret (L1) eliminerar spökfyndet: en motor hävdar ibland förekomsten av kod som inte finns där — ett kodavsnitt som drivit iväg, ett fynd som kopierats till en syskonfil. L1 verifierar varje fynds befintliga kodavsnitt mot den faktiskt granskade commiten och återplacerar eller tar bort avvikelser. Det åtgärdar klassen av falska positiva resultat av typen “den här raden finns inte ens”, vilket är mekaniskt och verifierbart.

Domarlagret (L2) eliminerar dubbletten och det ogrundade påståendet: en LLM-domare grupperar fynd efter grundorsak och tar bort kluster vars konfidens ligger under domartröskeln (standard 0,5). Det åtgärdar “samma bugg rapporterad på tre sätt” och det spekulativa fyndet.

Det som inget av lagren åtgärdar är värt att säga högt. En felaktig men självsäker upptäckt överlever domaren — domaren är en LLM, och en LLM som låter övertygad är inte detsamma som en upptäckt som är sann. En domare som kör på granskarens egen modell håller med sig själv och körningen blir verkningslös samtidigt som den fortfarande rapporterar framgång, vilket är anledningen till att det medföljande receptet dirigerar domaren till en annan modell än granskaren. Och allvarlighetsgraderingen är medvetet konservativ — ”när man är kluven mellan två nivåer, välj den lägre” — vilket innebär att en verklig men villkorlig bugg med större sannolikhet hamnar som en P2-rekommendation än som en blockerande P1. Det är rätt kalibrering för ett verktyg som inte får blockera allt, men det är en kalibrering: den byter missade blockeringar mot färre falsklarm. PR-sammanfattningen räknar alltid varje upptäckt, så de nedtonade P2:orna finns fortfarande där att läsa. Om avvägningen är fel för ditt team är graderingen och domartröskeln konfiguration, inte ett supportärende.

Slutsatsen

För ett team som redan lever i GitHub Actions är open source-ramverket det billigaste sättet att få automatiserad kodgranskning på varje PR: en workflow-fil, en hemlighet, en token-avgift som skalar med mängden kod som granskas, och ett modellval du själv äger. Köp en per-säte-produkt när du vill ha noll drift och en leverantör att ringa – inte för att granskningen är bättre, utan för att du köper någon annans problem istället för att driva ditt eget. Och innan du sätter upp något av det, fråga om granskningen kommer att läsas. Ramverket kan få granskningen att ske automatiskt. Det kan inte få någon att läsa den.

Vill du ha samma granskare utan att köra den själv? OrcaCode Review kör denna exakta testmiljö som en hostad GitHub-app — samma öppna recept, samma per-token-pris, inga platser.