Geautomatiseerde codereview in 2026: laat hem op elke PR draaien zonder een zitplaats te kopen

Geautomatiseerde codereview is een CI-taak die je diff naar een taalmodel stuurt, bevindingen plaatst op de betreffende regels en een statuscontrole laat mislukken wanneer het iets ernstigs vindt. Om dat op elke pull request te laten draaien zonder een abonnement per stoel, host je een opensource-harness zelf: kopieer een workflow van ongeveer vijftien regels naar je repository, voeg één API-sleutel toe en betaal alleen voor de tokens die elke review verbruikt. Er hoeft geen stoelquotum te worden gekocht, want er is geen stoel. De referentie-implementatie die we onderhouden is de Orca-Code-Review-repository — openbaar, MIT-gelicentieerd en sinds de oprichting op 25 juni 2026 de code achter de OrcaCode Review GitHub Action. Het meegeleverde routeringsrecept stelt de reviewronde standaard in op DeepSeek V4 Flash en de onafhankelijke verificatiebeoordelaar op GLM-5.3, en beide kun je zelf wijzigen. Dit artikel neemt je mee door wat er daadwerkelijk draait bij elke push, wat je configureert, wat het kost aan tokens en de faalmodi die je in week twee tegenkomt.

De korte versie. Elke push krijgt één review. Bevindingen worden inline op de gewijzigde regels geplaatst. P0- en P1-bevindingen laten de check mislukken en blokkeren de merge; een schone run slaagt. Je kunt op verzoek opnieuw reviewen door te reageren met /orcacode-review. De workflow leeft in je repository; de reviewlogica leeft in de gepubliceerde action; de modelkeuze leeft in een routing-recipe dat je in je eigen workspace kunt bewerken. De reviewer leest de diff en repositorybestanden en voert nooit de code van je PR uit. En de eerlijke kanttekening vooraf: het vindt echte bugs en mist nog steeds de problemen die een mens vereisen die weet waarom de code is zoals die is.

• Eén workflow + één secret + een tokenfactuur. Geen per-seat licentie op welk moment dan ook.

• De harness is open source. Kopieer het, fork het, audit het, pin het op een commit-SHA.

• Het model is een instelling, geen leverancier. Wijzig de reviewer door een routeringsrecept te bewerken, niet door YAML te herschrijven of de actie te verhogen.

• Te grote diffs kosten niets. De groottecontrole draait vóór het model.

• Het leest je code, maar voert deze nooit uit. Dat is de veiligheidseigenschap die pull_request_target überhaupt veilig om te gebruiken maakt.

Hoe geautomatiseerde codereview daadwerkelijk werkt

Elk geautomatiseerd beoordelingssysteem is dezelfde drie ingrediënten in een ander jasje: een event, een runner en een reviewer.

De gebeurtenis is de trigger. De meegeleverde workflow wordt geactiveerd bij pull request-gebeurtenissen — geopend, synchroniseren (een nieuwe push), ready_for_review (een concept wordt gereed) — en bij een PR-commentaar. Omdat hij op pull_request_target draait, wordt de workflowdefinitie gelezen vanaf de basisbranch. Daarom moet de workflow op de basisbranch bestaan voordat deze voor een PR kan draaien. Eén review per push; het concurrency-blok annuleert de vorige run, zodat een snelle reeks pushes geen vijf reviews van verouderde code in de wachtrij plaatst.

De runner is GitHub Actions op ubuntu-latest. De job heeft drie machtigingen nodig: leestoegang tot contents, schrijftoegang tot pull requests (om inline opmerkingen te plaatsen), en schrijftoegang tot issues (om de samenvatting te plaatsen en verouderde opmerkingen op te ruimen).

De reviewer is een taalmodel. De actie haalt de PR-head op, stelt de diff en de repositorycontext die de engine selecteert samen, en stuurt dat naar het reviewmodel. Het resultaat is een reeks bevindingen, elk voorzien van een ernstgraad en gekoppeld aan een bestand en regel. De actie plaatst ze als inline-PR-opmerkingen en schrijft één samenvattende opmerking in een markeringsgebied bovenaan de PR-beschrijving, die bij elke push op zijn plaats wordt vervangen.

De gate is een statuscontrole. GitHub weet niet wat “review” betekent; het weet alleen of de review check slaagt. Je maakt de gate echt door die check als vereist te markeren in branch protection. Dat is het hele merge-blokkeringsmechanisme — geen admin API-aanroepen, geen labels, alleen een falende vereiste check.

Wat er niet gebeurt: niets voert de code van de PR uit. De engine leest alleen. Die ene invariant is wat de geprivilegieerde pull_request_target-trigger veilig maakt om met een betaalde API-sleutel te gebruiken.

De open-source-harness is de onderscheidende factor.

Al het bovenstaande geldt voor veel tools. Wat voor de meeste niet geldt, is dat het geheel inspecteerbaar en zelf-hostbaar is, en dat is wat de repository Orca-Code-Review je oplevert. Het is een openbare GitHub-repository met een MIT-licentie (JavaScript, gemaakt op 25 juni 2026) die de review verpakt als een herbruikbare composite GitHub Action plus een installatieprogramma, en het is dezelfde code die de gehoste OrcaCode Review-app draait.

Breng tien minuten door in de boom en je kunt elk onderdeel benoemen dat jouw PR aanraakt:

• action.yml — de samengestelde actie, met ongeveer vijftien gedocumenteerde inputs. Er staan nergens modelnamen in vastgecodeerd.

• workflows/orca-code-review.yml — de voorbeeld-consumerworkflow, de ongeveer vijftien regels die je kopieert naar .github/workflows/.

• recipes/ — de routing-DSL. Hier wordt het model daadwerkelijk gekozen.

• rules/ — de ernstschaal (P0–P3), de verplichte uitvoervorm en een conventierichtlijn die het eigen conventiedocument van het project als niet-vertrouwde referentiegegevens aan de review toevoert.

• scripts/ — de precisiefilter (L1 plus een L2-beoordelaar), de diff-guard, de mergegate, het runrapport en de tokenmeter. Elk is een klein, leesbaar .mjs bestand met tests.

• skills/setup-orca-code-review — de skill die de installateur in je coding agent plaatst, voor installeren, opnieuw configureren, problemen oplossen en verwijderen.

• .claude-plugin/ — wat Claude Code in staat stelt om de skill als zelfupdaterende plugin te installeren.

Installeren is een one-liner die je AI leert wat het product is en daarna stopt:

npx @orcarouter/code-review

De CLI detecteert welke coding agents je gebruikt — de catalogus omvat 36 platforms, van Claude Code, Cursor, Codex, OpenCode en Windsurf tot GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode en andere — installeert de skill en draagt het over. Vervolgens vraag je je agent in gewone taal: “zet OrcaCode Review op in deze repo,” “blokkeer alleen P0,” “waarom is de review niet uitgevoerd?” De skill beheert de levenscyclus: hij schrijft de workflow, begeleidt je bij de API-sleutel, stelt de gate in en stelt alleen de vragen die echt van jou zijn.

Claude Code kan de skill in plaats daarvan als plug-in installeren, waardoor deze up-to-date blijft terwijl de repo verandert:

/plugin marketplace add Continuum-AI-Corp/orca-code-review

/plugin install orca-code-review

Helemaal geen agent? Dezelfde levenscyclus bestaat uit gewone subcommando's — init schrijft de workflow, reconfigure wijzigt blokkeringsregels en diff-limieten, doctor diagnoseert reviews die niet draaien of niet posten, uninstall verwijdert het (waarbij eerst de check-verplichting wordt opgeheven). De skill is de voordeur, niet de enige deur. Of zet het handmatig op: kopieer de workflow, voeg één geheim toe met de naam ORCAROUTER_API_KEY, en markeer de review-check als vereist.

De onderliggende engine is Ali​baba’s Open Code Review, vastgepind op een exacte versie en gelicenseerd onder Apache-2.0. OrcaCode bepaalt hoe er wordt beoordeeld; OrcaRouter bepaalt welk model het uitvoert. De afweging tussen self-host en hosted — wat “gratis” werkelijk kost wanneer je een open-source reviewer zelf host — wordt uitgewerkt in ons artikel over open code review.

Wat draait er, in volgorde, bij elke push?

Het helpt om de volgorde te kennen, omdat elke stap onafhankelijk kan mislukken of worden overgeslagen:

• De diff-guard draait eerst, voordat het model ook maar aan de beurt komt. Als de merge-base-diff groter is dan 512 kB of meer dan 300 bestanden raakt, wordt de review overgeslagen en wordt er een melding geplaatst. De standaardwaarde is on-oversized-diff: fail, dus een diff die tot voorbij de limieten is opgevuld, kan niet onbeoordeeld door een verplichte gate komen. Dit is ook de uitgavenbeheersing: een te grote PR kost nul tokens.

• De engine beoordeelt de diff. Eén doorgang, met standaard 24 bestanden tegelijk en een maximale wandkloktijd van 20 minuten per doorgang.

• Het precisiefilter verwerkt de ruwe bevindingen na. L1, een deterministisch filter, controleert het geclaimde bestaande-codefragment van elke bevinding tegen de beoordeelde commit en herplaatst of verwijdert afwijkingen. L2, een LLM-beoordelaar, clustert bevindingen op basis van de hoofdoorzaak en verwerpt clusters met een lage betrouwbaarheid. Beide lagen zijn soft-fail: een fout behoudt de bevindingen van de vorige fase en breekt de review nooit af.

• De gate is van toepassing. P0- en P1-bevindingen zorgen ervoor dat de check faalt; de PR-samenvatting telt alle bevindingen, inclusief degenen die in de diff zijn gedempt.

• De meter print wat het kost. De meter input registreert de tokenboekhouding per oproep — prompt, completion, gecachte tokens, en het model dat de router heeft bepaald — en drukt een totaaltabel af in de joblog.

• Een optioneel runrapport verstuurt ernsttellingen en gate-metagegevens naar het control plane van OrcaRouter voor het analyticsdashboard. Het bevat geen code, geen diff en geen bevindingentekst.

Wat je daadwerkelijk configureert

Er zijn drie oppervlakken, en ze hebben een heel verschillende impactradius.

1. Het workflowbestand. De consumer-workflow is bewust slank gehouden. De inputs die de moeite waard zijn om aan te passen, zitten in de action: block-on (welke severities de check laten falen — standaard P0,P1), fix-first (welke severities een uitputtende review vroegtijdig stoppen), auto-review-authors (een allowlist voor wie automatisch gereviewd wordt), max-diff-kb en max-diff-files en on-oversized-diff (de groottebewaker), timeout-minutes, concurrency, meter, en report. Elke input heeft een gedocumenteerde standaardwaarde, dus een nieuwe workflow is vijf regels YAML plus een secret.

2. Het dashboard. Met settings: true (de standaard) haalt elke run instellingen per repository van OrcaRouter → Apps → OrcaCode Review op: het model, beoordelingsmodus, mergebeleid, rapportseveriteiten, stille modus, exhaustieve review, een aangepaste rubric, en guardrails. Stel settings: "false" in en het workflowbestand is doorslaggevend — geen dashboardwaarde kan dit overschrijven. Als je de console nooit opent, verlies je niets van de harness; je configureert gewoon in YAML.

3. Het routing-recept — het recept dat mensen over het hoofd zien. De actie noemt nooit een model. In plaats daarvan injecteert hij ruwe feiten als request-headers — als welke tier de run is geregistreerd, of de vorige pass een P0/P1 vond, en een lensmarkering wanneer het verzoek de L2-judge is — en het DSL-recept van de workspace-router mapt die headers naar een concreet model. Het meegeleverde recept gebruikt standaard DeepSeek V4 Flash voor de review en GLM-5.3 voor de judge, en routeert de twee doelbewust naar afzonderlijke modellen. Het wijzigen van het model dat je code beoordeelt, is een aanpassing aan dat recept in je eigen workspace: geen versiebump van de actie, geen YAML-herschrijving, geen redeploy.

Het ernstcontract bestaat uit twee onafhankelijke instellingen, niet één. Mergebeleid bepaalt wat de merge blokkeert; ernstrapportage bepaalt wat er op de diff wordt geplaatst. De standaardinstellingen zijn P0/P1 blokkeren, P2/P3 toestaan. Een ernst die blokkeert wordt altijd geplaatst, ongeacht wat de rapportage-instelling zegt — een falende controle zonder uitleg op de diff is erger dan een lawaaierige. P0 betekent een exploiteerbaar beveiligingslek, gegevensverlies, een crash in een normaal pad of een kapotte build; P1 betekent een reële maar beperkte bug; P2 betekent een echt defect dat alleen optreedt onder een abnormale voorwaarde; P3 is stijl. Als je twijfelt tussen twee niveaus, zegt de rubric dat je de lagere moet kiezen.

Wat het kost

Per token, niet per gebruiker. Je kiest het model op OrcaRouter, de facturering loopt per verbruikt token, en de meter maakt het bedrag per run zichtbaar in plaats van mysterieus. De GitHub-mechanismen, Copilot’s op verbruik gebaseerde codebeoordeling sinds 1 juni 2026, en hoe externe beoordelaars in die workflow passen, worden behandeld in onze gids voor codebeoordeling op GitHub. De volledige veld-voor-veld-kostenvergelijking — producten per gebruiker versus producten per token, met een uitgewerkt voorbeeld — staat in onze vergelijking van AI-codebeoordelingstools, en de vraag wat een enkele beoordelingsronde kost in tokens wanneer de beoordelaar daadwerkelijk de repository verkent (het bot-versus-agent-onderscheid) staat in ons artikel over codebeoordelingsagenten. Het punt dat dit artikel toevoegt is de vorm van de rekening: die schaalt met de code die je beoordeelt, niet met het aantal mensen dat de code beoordeelt.

Twee uitgavencontroles zijn belangrijk op dag één. Op een openbare repository, pull_request_target omzeilt GitHub’s goedkeuringspoort voor forks, en de review-sleutel is wallet-gemeten — een onbekende kan een PR openen en betaalde reviews activeren. Stel een wallet-budget in met waarschuwingen op de sleutel, en stel auto-review-authors in op zoiets als OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR zodat onbekende bijdragers niet automatisch worden gereviewd. En de diff-bewaking, zoals gezegd, betekent dat te grote PR's helemaal niets kosten.

Wat breekt

Geautomatiseerde review is CI. Het faalt zoals CI, en de faalmodi zijn meestal niet de schuld van het model:

• De workflow draait nooit. Voor pull_request_target wordt de workflow uit de basisbranch gelezen — een workflow die alleen in de PR-branch is toegevoegd, zal niet draaien totdat deze is gemerged. Controleer ook dat de app is ingeschakeld, dat auto_review aanstaat, dat de PR geen draft is (drafts worden overgeslagen in de ready_for_review-modus) en dat Actions op de repository zijn ingeschakeld (forked repos hebben ze standaard uitstaan).

• /orcacode-review doet niets. De commentaartrigger vereist dat de opmerking begint met een van vier spellingen — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — en dat de commentator een EIGENAAR, LID of MEDEWERKER is. Een voorafgaande spatie verbreekt de match. Het commando van een externe bijdrager wordt stilzwijgend genegeerd, met opzet: het commando voert een bevoorrechte workflow uit die de betaalde sleutel bevat.

• Een auth-fout. Het geheim is verkeerd benoemd of ontbreekt, de sleutel is ingetrokken of buiten het budget, of de workflow is omgeschakeld naar pull_request (die geen geheimen uit forks kan lezen).

• De check is rood met een melding 'diff too large'. Dat is de size guard, die werkt zoals geconfigureerd. Splits de PR, of verhoog de limieten, of zet on-oversized-diff: pass — en begrijp dat bij een vereiste check pass betekent dat een grote PR rechtstreeks door de gate loopt zonder review.

• De review draait, maar er verschijnen geen opmerkingen. Drie oorzaken, allemaal onschuldig of geconfigureerd: een schone run plaatst een samenvatting in plaats van inline-opmerkingen; stille modus dempt P2 bij het plaatsen (de gate en het rapport telden het nog steeds mee); of de precisiefilter heeft de bevindingen verwijderd — L1 verwijdert bevindingen waarvan het snippet niet overeenkomt met de commit, L2 verwijdert clusters met lage betrouwbaarheid. De ernsttellingen in het joblog vertellen je welke.

De beveiligingshouding is het waard om duidelijk te vermelden, want die maakt het hele ontwerp veilig. De engine leest alleen de diff en repositorybestanden; hij voert nooit PR-code uit. De reviewer heeft geen merge-autoriteit — bevindingen kunnen een merge blokkeren of een opmerking toevoegen, maar geen enkele codepad laat modeloutput de repository goedkeuren of wijzigen. Een niet-gelabelde bevinding faalt veilig en wordt behandeld als blokkerend in plaats van adviserend. En het runrapport bevat geen code- of bevindingentekst. De tweelaagse opzet die opvangt wat een eenmalige review mist, is het onderwerp van ons beveiligingsartikel over AI-code-review; het bovenstaande dreigingsmodel is gedocumenteerd in de SECURITY.md van de repository.

Wanneer geautomatiseerde review het verkeerde hulpmiddel is

Het is vaker fout dan de toolingleveranciers toegeven. Sla deze over wanneer:

• Het probleem is context, niet volume. Als beoordelingen traag zijn omdat beoordelaars moeten begrijpen waarom de code zo is geschreven, voegt een LLM die de diff leest weinig toe. Het heeft geen geheugen van de thread van vorige maand en geen gevoel voor de geschiedenis van het systeem.

• De diff bestaat grotendeels uit gegenereerde of vendorcode. Automatisch geformatteerde uitvoer, scaffold-bestanden, dependency-snapshots. Het reviewen ervan verbruikt tokens en levert ruis op, en het is precies waar de conventions-richtlijn het minst helpt — de code is niet bewust in de stijl van het project geschreven.

• Het team reviewt al alles paarsgewijs. Geautomatiseerde review is een hefboom voor volume. Als elke wijziging al wordt beoordeeld door een mens die erbij was, voegt de machine een tweede mening toe die meestal minder geïnformeerd is dan de eerste.

• Niemand leest de bevindingen. Een review waar niemand iets mee doet, is een workflow die voorgoed groen faalt. Dit is de meest voorkomende stille fout, en geen precisiefilter verhelpt het.

• De review moet de code uitvoeren.Als je een testsuite voor de PR nodig hebt, is een LLM-review het verkeerde hulpmiddel. Het leest; het voert niet uit. Een beveiligingsscan die het artefact moet bouwen en uitvoeren, hoort thuis in een aparte, zorgvuldig afgebakende taak — onthoud dat de reviewworkflow nooit mag worden uitgebreid om PR-gecontroleerde code uit te voeren.

• De repository is klein of tijdelijk.Onder een bepaalde wijzigingsfrequentie is de review meer overhead dan de bugs die hij opvangt.

Vals-positieven, en wat precisiefiltering wel en niet oplost

De beschuldiging tegen elke AI-recensent is dat hij vals alarm slaat. Het harnas pakt dit op twee lagen aan, en het helpt om precies te zijn over welke laag welke fout oplost.

De deterministische laag (L1) elimineert de spookbevinding: een engine beweert soms code te zien die er niet is — een snippet die is afgedwaald, een bevinding die naar een zusterbestand is gekopieerd. L1 verifieert de bestaande code-snippet van elke bevinding tegen de daadwerkelijk gereviewde commit en herplaatst of verwijdert mismatches. Dat verhelpt de klasse van valse positieven van “deze regel bestaat niet eens”, die mechanisch en verifieerbaar is.

De beoordelaarslaag (L2) verwijdert het duplicaat en de ongefundeerde claim: een LLM-beoordelaar clustert bevindingen op basis van hoofdoorzaak en laat clusters vallen waarvan de betrouwbaarheid onder de drempelwaarde van de beoordelaar ligt (standaard 0.5). Dat verhelpt de “dezelfde bug op drie manieren gerapporteerd” en de speculatieve bevinding.

Wat geen van beide lagen oplost, is de moeite waard om hardop te zeggen. Een onjuiste maar zelfverzekerde bevinding overleeft de rechter. De rechter is een LLM, en een LLM die zeker klinkt is niet hetzelfde als een bevinding die waar is. Een rechter die op het eigen model van de beoordelaar draait, is het met zichzelf eens en de beoordeling wordt inert terwijl hij toch succes rapporteert. Daarom stuurt het meegeleverde recept de rechter naar een ander model dan de beoordelaar. En de ernstrubriek is opzettelijk conservatief — “bij twijfel tussen twee niveaus, kies het lagere” — wat betekent dat een echte maar voorwaardelijke bug eerder als een P2-advies wordt aangemerkt dan als een blokkerende P1. Dat is de juiste kalibratie voor een tool die niet alles moet blokkeren, maar het is een kalibratie: het ruilt gemiste blokkeerders in voor minder valse alarmen. De PR-samenvatting telt altijd elke bevinding, dus de afgezwakte P2's zijn er nog steeds om te lezen. Als de afweging voor jouw team verkeerd is, zijn de ernstrubriek en de drempelwaarde van de rechter configuratie, geen supportticket.

De bottom line

Voor een team dat al werkt met GitHub Actions, is de open-source harness de goedkoopste manier om op elke PR geautomatiseerde code review te krijgen: één workflowbestand, één geheim, een tokenrekening die meeschaalt met de beoordeelde code, en een modelkeuze die je zelf beheert. Koop een product per werkplek als je geen beheer wilt en een leverancier om te bellen — niet omdat de review beter is, maar omdat je het probleem van iemand anders koopt in plaats van je eigen te runnen. En voordat je iets opzet, stel je de vraag of de review gelezen zal worden. De harness kan de review automatisch laten plaatsvinden. Het kan er niet voor zorgen dat iemand hem leest.

Wil je dezelfde reviewer zonder het zelf te draaien? OrcaCode Review draait deze exacte testomgeving als een gehoste GitHub App — hetzelfde open recept, dezelfde per-token factuur, geen licenties.