AI-codereview in GitHub Actions met Claude en Gemini

12 min leestijd·Matthieu·ci-cdgeminiclaudeai-code-reviewgithub-actions|

Stel Claude Code Action en Gemini in voor geautomatiseerde pull request-reviews. Multi-model workflows met rolscheiding, quality gates die merges blokkeren bij kritieke bevindingen en beveiliging tegen prompt injection.

AI-codereview is verschoven van experiment naar productietooling. Claude Code Action en Gemini Code Assist kunnen elke pull request automatisch beoordelen, waarbij ze logische bugs, beveiligingsproblemen en ontbrekende foutafhandeling opsporen die linters en statische analyse volledig missen.

Deze tutorial richt beide modellen in op dezelfde repository. Claude behandelt de logica- en beveiligingsreview. Gemini behandelt stijl en documentatie. Een quality gate parseert de ernst van beide reviews en blokkeert merges wanneer kritieke problemen worden gevonden.

AIOps op een VPS: AI-gestuurde serverbeheer met open-source tools

Wat detecteert AI-codereview dat linters missen?

Linters controleren syntax en opmaak. Statische analysetools zoals Semgrep herkennen bekende patronen. AI-codereviewers doen iets anders: ze lezen de diff in context en redeneren over wat de code doet. Ze signaleren race conditions, ontbrekende foutafhandelingspaden, onveilige standaardinstellingen en bedrijfslogicafouten die patroongebaseerde tools niet kunnen detecteren.

Een Milvus-studie testte vijf AI-modellen op het detecteren van echte bugs in productie-PR's. Het beste individuele model detecteerde 53% van de bugs. Wanneer meerdere modellen dezelfde PR beoordeelden en hun bevindingen bespraken over meerdere rondes, steeg de detectie naar 80%. De moeilijkste bugs, die systeemniveau-begrip van aanroepketens en foutpropagatie vereisen, bereikten 100% detectie in multi-model debatmodus.

Die studie is de reden waarom deze tutorial twee modellen gebruikt in plaats van één.

Concrete voorbeelden van wat AI-review detecteert:

  • Niet-gevalideerde gebruikersinvoer die door drie functieaanroepen stroomt voordat een databasequery wordt bereikt
  • Ontbrekende null-controles waarbij een functie Optional<T> retourneert maar de aanroeper aanneemt dat het altijd slaagt
  • Hardgecodeerde geheimen in configuratiebestanden die eruitzien als plaatshouderwaarden maar echte inloggegevens zijn
  • Gaten in foutafhandeling waarbij een try/catch een generieke uitzondering vangt en stilzwijgend negeert
  • Race conditions in gelijktijdige code waar gedeelde staat wordt gewijzigd zonder synchronisatie

Hoe stel je Claude Code Action in voor pull request-reviews?

Claude Code Action is een GitHub Action die wordt onderhouden door Anthropic en Claude draait op je GitHub-runner. Het leest PR-diffs, plaatst inline-opmerkingen en kan ook fixes implementeren. De setup duurt ongeveer vijf minuten.

De Claude GitHub App installeren

Ga naar github.com/apps/claude en installeer het op je repository of organisatie. Verleen toegang tot de repository's die je wilt laten beoordelen. De app heeft deze rechten nodig:

  • Contents: Read
  • Pull Requests: Read & Write
  • Issues: Read & Write (optioneel, voor issue-triage)

De API-sleutel toevoegen

Ga in je repository naar Settings > Secrets and variables > Actions en maak een nieuw repository-secret aan:

  • Name: ANTHROPIC_API_KEY
  • Value: Je Anthropic API-sleutel (begint met sk-ant-)

Commit nooit API-sleutels in je repository. Als je organisatiebrede toegang nodig hebt, gebruik dan omgevingssecrets in plaats van repository-secrets.

De workflow aanmaken

Maak .github/workflows/claude-review.yml aan:

name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "lib/**"
      - "app/**"
      - "config/**"
    paths-ignore:
      - "**/*.md"
      - "**/*.txt"
      - "docs/**"

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: write
      id-token: write

    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Review this pull request. Focus on:
            1. Security: injection flaws, auth bypass, hardcoded secrets, insecure defaults
            2. Logic errors: off-by-one, null dereference, race conditions, resource leaks
            3. Error handling: swallowed exceptions, missing retries, unclear error messages
            4. Performance: N+1 queries, unbounded loops, unnecessary allocations

            Skip cosmetic issues (formatting, naming style). Another reviewer handles those.

            Rate each finding as CRITICAL, HIGH, MEDIUM, or LOW.

            Use inline comments for specific code issues.
            Use a summary PR comment for overall assessment.

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Het paths-filter beperkt reviews tot broncode-wijzigingen. PR's die alleen documentatie aanraken slaan de workflow over, wat API-kosten bespaart. Het concurrency-blok annuleert lopende reviews wanneer een nieuwe commit naar dezelfde PR wordt gepusht, zodat je niet betaalt voor het beoordelen van verouderde code.

De --allowedTools-beperking is een beveiligingsmaatregel. Het beperkt Claude tot het lezen van diffs en het plaatsen van opmerkingen. Het kan geen bestanden wijzigen, willekeurige commando's uitvoeren of toegang krijgen tot andere repository's.

Hoe voeg je Gemini-codereview toe aan dezelfde repository?

Twee opties voor Gemini-review: de Gemini Code Assist GitHub App (beheerd door Google, geen YAML) of de run-gemini-cli GitHub Action (zelf beheerd, volledige controle). Deze tutorial gebruikt de GitHub Action omdat het controle geeft over de prompt en integreert met de quality gate-workflow.

Een Gemini API-sleutel verkrijgen

Maak een sleutel aan op Google AI Studio. Voeg deze toe als repository-secret:

  • Name: GEMINI_API_KEY
  • Value: Je Gemini API-sleutel

Voor zakelijk gebruik met Vertex AI-authenticatie, raadpleeg de run-gemini-cli-documentatie voor Workload Identity Federation-configuratie.

De Gemini-workflow aanmaken

Maak .github/workflows/gemini-review.yml aan:

name: Gemini Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "lib/**"
      - "app/**"
      - "config/**"
    paths-ignore:
      - "**/*.md"
      - "**/*.txt"
      - "docs/**"

concurrency:
  group: gemini-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: google-github-actions/run-gemini-cli@main
        with:
          gemini_api_key: ${{ secrets.GEMINI_API_KEY }}
          prompt: |
            Review this pull request. Focus on:
            1. Code style: naming conventions, function length, complexity
            2. Documentation: missing docstrings, outdated comments, unclear variable names
            3. Test coverage: untested edge cases, missing assertions, test quality
            4. Maintainability: code duplication, tight coupling, violation of SOLID principles

            Skip security and logic analysis. Another reviewer handles those.

            Rate each finding as CRITICAL, HIGH, MEDIUM, or LOW.

            Post your review as a single PR comment with structured sections.

De run-gemini-cli-action is momenteel in bèta, daarom wijst de workflow naar @main. Voor productiegebruik pin je naar een specifieke commit-SHA (bijv. @abc1234) om onverwachte wijzigingen te voorkomen wanneer de main-branch wordt bijgewerkt.

Waarom twee aparte workflows?

Claude en Gemini in aparte workflowbestanden uitvoeren betekent dat ze parallel draaien. Een fout in de ene blokkeert de andere niet. Je kunt ook tijdelijk een model uitschakelen zonder de andere workflow aan te raken.

De rolscheiding is opzettelijk. Claude volgt doorgaans aanroepketens van boven naar beneden en is goed in het vinden van gaten in foutafhandeling en beveiligingslekken. Gemini is sterk in codestijl, documentatievolledigheid en structurele patronen. Overlap is normaal. Overeenstemming tussen modellen verhoogt het vertrouwen in de bevindingen.

Hoe werkt multi-model review met Claude en Gemini samen?

De bovenstaande twee-workflow-configuratie implementeert al multi-model review. Beide modellen beoordelen dezelfde PR onafhankelijk en plaatsen aparte opmerkingen. Dit is het eenvoudigste patroon en werkt goed voor de meeste teams.

Voor teams die een uniforme weergave willen, voeg een aggregatiestap toe. Deze derde workflow draait nadat beide reviews zijn voltooid en plaatst een gecombineerde samenvatting:

name: AI Review Summary

on:
  workflow_run:
    workflows: ["Claude Code Review", "Gemini Code Review"]
    types: [completed]

jobs:
  aggregate:
    if: github.event.workflow_run.event == 'pull_request'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    permissions:
      pull-requests: write
      actions: read

    steps:
      - name: Collect review comments
        id: collect
        uses: actions/github-script@v7
        with:
          script: |
            const pr_number = context.payload.workflow_run.pull_requests[0]?.number;
            if (!pr_number) return;

            const comments = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr_number,
            });

            const aiComments = comments.data.filter(c =>
              c.body.includes('CRITICAL') ||
              c.body.includes('HIGH') ||
              c.body.includes('MEDIUM')
            );

            const critical = aiComments.filter(c => c.body.includes('CRITICAL')).length;
            const high = aiComments.filter(c => c.body.includes('HIGH')).length;

            const summary = `## AI Review Summary\n\n` +
              `| Severity | Count |\n|----------|-------|\n` +
              `| CRITICAL | ${critical} |\n` +
              `| HIGH | ${high} |\n\n` +
              (critical > 0 ? '⛔ **Merge blocked:** Critical findings require human review.\n' :
               high > 0 ? '⚠️ High-severity findings detected. Review recommended before merge.\n' :
               '✅ No critical or high-severity findings.\n');

            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr_number,
              body: summary,
            });

            core.setOutput('critical_count', critical);

      - name: Set status check
        if: steps.collect.outputs.critical_count > 0
        run: exit 1

Dit is een startpunt. Pas de logica voor het parsen van opmerkingen aan op het exacte formaat dat je prompts produceren. De ernst-sleutelwoorden (CRITICAL, HIGH, MEDIUM) in de reviewprompts maken het parsen eenvoudig.

Hoe blokkeer je merges wanneer AI-review kritieke problemen vindt?

De bovenstaande aggregatieworkflow stelt exitcode 1 in wanneer er kritieke bevindingen zijn. Om dit een mergeblokkade te maken, configureer branchbeveiliging:

  1. Ga naar Settings > Branches > Branch protection rules
  2. Selecteer of maak een regel aan voor je hoofdbranch
  3. Schakel Require status checks to pass before merging in
  4. Zoek en voeg "AI Review Summary" toe als vereiste statuscontrole
Ernst Actie Merge geblokkeerd?
CRITICAL Statuscontrole faalt Ja
HIGH Waarschuwing in samenvatting Nee (adviserend)
MEDIUM Vermeld in samenvatting Nee
LOW Weggelaten uit samenvatting Nee

Een waarschuwing: AI-reviewers produceren false positives. Als je de statuscontrole verplicht maakt, moeten ontwikkelaars af en toe onjuiste bevindingen afwijzen. Houd CRITICAL als de enige blokkerende ernst. Als je ook op HIGH blokkeert, verwacht wrijving.

Om een geblokkeerde merge te overschrijven kan een maintainer de admin-bypass op de branchbeveiligingsregel gebruiken, of je kunt een /dismiss-ai-review commenthandler toevoegen die de samenvattingsworkflow opnieuw draait met een force-pass-vlag.

Hoe verminder je false positives in AI-codereview?

False positives zijn de belangrijkste klacht van teams die AI-codereview gebruiken. Luidruchtige reviews ondermijnen het vertrouwen snel. Drie technieken helpen.

De prompt strak afbakenen

De bovenstaande prompts doen dit al: Claude beoordeelt beveiliging en logica, Gemini beoordeelt stijl en documentatie. Een model dat gevraagd wordt om "alles te beoordelen" produceert meer ruis dan een met een specifiek mandaat.

Voeg projectspecifieke context toe om false positives verder te verminderen. Maak een CLAUDE.md-bestand in de root van je repository (Claude Code Action leest dit automatisch):

# Project Context

This is a Django REST API. Python 3.12. PostgreSQL.

## Review Guidelines
- We use `rest_framework.exceptions` for all error handling. Do not flag bare `except` blocks in middleware.
- `settings.py` contains environment variable references, not hardcoded secrets. Do not flag `os.environ.get()` calls.
- We intentionally use `Any` type hints in the serializer layer. Do not flag these.
- Test files use `pytest` fixtures. Do not flag unused function parameters in test files.

Voor Gemini maak je een GEMINI.md-bestand in de root van de repository met vergelijkbare projectcontext.

Bestanden filteren

De paths- en paths-ignore-filters in de workflow-YAML voorkomen reviews van bestanden die ruis genereren:

paths-ignore:
  - "**/*.md"
  - "**/*.txt"
  - "**/*.lock"
  - "**/*.generated.*"
  - "migrations/**"
  - "vendor/**"
  - "dist/**"
  - "__snapshots__/**"

Lockbestanden, gegenereerde code, gebundelde afhankelijkheden en migratiebestanden produceren false positives omdat ze machinaal gegenereerd zijn of patronen volgen die het model niet begrijpt in context.

Een ernstdrempel instellen

Als je alleen CRITICAL- en HIGH-bevindingen in de samenvatting toont, bereikt MEDIUM- en LOW-ruis de ontwikkelaar nooit. Dit is een betere standaard dan alles tonen en ontwikkelaars vragen de ruis te negeren.

Wat zijn de beveiligingsrisico's van AI-codereview op pull requests?

AI-codereviewers verwerken onbetrouwbare invoer. De PR-diff, commitberichten, issue-titels en bestandsinhoud worden allemaal door de aanvaller beheerst in open-source repository's of bij het accepteren van externe bijdragen. Dit creëert een prompt injection-risico.

De Clinejection-aanval

In februari 2026 exploiteerde een aanvaller de Cline issue-triage-bot via indirecte prompt injection. De aanval was eenvoudig: een kwaadaardige GitHub issue-titel bevatte instructies vermomd als foutmelding. De workflow van de AI-agent interpoleerde de issue-titel rechtstreeks in de prompt. De agent volgde de geïnjecteerde instructies, voerde npm install uit op een kwaadaardig pakket en exfiltreerde de ANTHROPIC_API_KEY uit de CI-omgeving.

De aanval compromitteerde ongeveer 4.000 ontwikkelaarsmachines voordat het kwaadaardige pakket werd verwijderd.

Je workflows beveiligen

Beperk toolrechten. De --allowedTools-vlag in de bovenstaande Claude-workflow beperkt wat Claude kan doen. Het kan diffs lezen en opmerkingen plaatsen. Het kan geen willekeurige shell-commando's uitvoeren, bestanden schrijven of toegang krijgen tot secrets. Dit is de meest effectieve mitigatiemaatregel.

claude_args: |
  --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Zonder deze beperking zou een gemanipuleerde PR-diff Claude kunnen instrueren om commando's uit te voeren op de runner.

Interpoleer nooit onbetrouwbare invoer in prompts. Gebruik niet ${{ github.event.issue.title }} of ${{ github.event.pull_request.body }} in het prompt-veld. Geef repository en PR-nummer door, en laat de action de inhoud ophalen via de GitHub API.

Ga voorzichtig om met fork-PR's. Fork-PR's draaien standaard met beperkte GITHUB_TOKEN-rechten, maar je secrets zijn nog steeds beschikbaar voor de workflow als deze wordt getriggerd door pull_request_target. Gebruik pull_request (niet pull_request_target) voor AI-review workflows. Fork-PR's hebben dan geen toegang tot je API-sleutels en de review wordt niet uitgevoerd, wat het veilige standaardgedrag is.

on:
  pull_request:        # Safe: fork PRs cannot access secrets
    types: [opened, synchronize]
  # pull_request_target:  # Dangerous: fork PRs CAN access secrets

Roteer je API-sleutels. Als een sleutel wordt blootgesteld via een CI-log of een gecompromitteerde runner, is de schaderadius beperkt tot de tijd tussen rotaties. Roteer minimaal elk kwartaal.

Controleer workflow-uitvoeringen. Bekijk het Actions-tabblad regelmatig op ongebruikelijke looptijden of onverwachte tool-aanroepen. Een review die 45 minuten duurt in plaats van de gebruikelijke 3 minuten kan erop wijzen dat het model wordt gemanipuleerd.

Hoeveel kost AI-codereview per pull request?

De kosten schalen met de PR-grootte. Zowel Claude als Gemini rekenen per verwerkt token. De invoertokens omvatten de PR-diff, bestandscontext en je prompt. De uitvoertokens zijn de reviewopmerkingen.

PR-grootte Typische diff (regels) Geschatte invoertokens
Klein 50-100 2.000-5.000
Gemiddeld 200-500 8.000-20.000
Groot 500-1.500 20.000-60.000

Tokenaantallen variëren per taal. Een 200-regels Python-diff verbruikt minder tokens dan een 200-regels Java-diff omdat Java uitgebreider is.

Twee modellen gebruiken verdubbelt de tokenkosten maar niet de eurokosten, omdat de prijsstelling verschilt tussen providers. Bekijk de huidige per-tokentarieven op de Anthropic-prijspagina en de Google AI-prijspagina. Beide gebruiken per-tokenprijzen met verschillende tarieven voor invoer- en uitvoertokens.

Om je maandbudget te schatten: vermenigvuldig de gemiddelde PR-grootte (in tokens) met het aantal PR's per maand, vermenigvuldig dan met het per-tokentarief voor elk model. Een team dat 50 PR's per week mergt met gemiddelde diffs kan berekenen:

weekly_cost = 50 * avg_tokens_per_pr * (claude_input_rate + gemini_input_rate)
              + 50 * avg_output_tokens * (claude_output_rate + gemini_output_rate)

Kosten verlagen

  • Padfilters voorkomen reviews van documentatie, lockbestanden en gegenereerde code. Dit is de grootste kostenbesparing.
  • Concurrency-annulering stopt het beoordelen van verouderde commits wanneer een nieuwe push binnenkomt.
  • Sla concept-PR's over door ready_for_review niet in je triggertypes op te nemen, en voeg het alleen toe wanneer je reviews wilt bij concept-naar-klaar-transities.
  • Gebruik kleinere modellen voor stijlreview. Gemini Flash is goedkoper dan Gemini Pro voor stijl- en documentatiecontroles waar diep redeneren niet nodig is.

Vergelijking: AI-codereviewtools

Kenmerk Claude Code Action Gemini Code Assist CodeRabbit GitHub Copilot
Configuratiemethode GitHub Action (YAML) GitHub App of Action GitHub App Ingebouwd
Prijsmodel Per token (API) Per token of gratis tier Abonnement per repository Abonnement per werkplek
Inline-opmerkingen Ja Ja Ja Ja
Aangepaste prompts Volledige controle Volledige controle (Action) Configuratiebestand Beperkt
Zelf-gehoste runner Ja Ja (Action) Nee Nee
Multi-model ondersteuning Combineerbaar Combineerbaar Enkel model Enkel model
Open source Ja (MIT) Ja (Action) Nee Nee

Claude Code Action en de Gemini CLI-action zijn open source en draaien op je eigen runners. Je code verlaat nooit je infrastructuur, behalve voor de API-aanroep naar de modelprovider. CodeRabbit en Copilot zijn beheerde diensten waarbij code wordt verwerkt op hun infrastructuur.

Wat zijn de beperkingen van AI-codereview?

AI-codereview vervangt geen menselijke review. Het is een eerste doorloop die veelvoorkomende problemen opspoort en menselijke reviewers vrijmaakt om zich te richten op architectuur, ontwerp en bedrijfslogicabeslissingen.

Contextvenster-limieten. Grote PR's (meer dan 1.500 gewijzigde regels) kunnen het contextvenster van het model overschrijden of oppervlakkige reviews produceren omdat het model niet de volledige diff in context kan houden. Splits grote PR's op in kleinere. Dit is een goede gewoonte ongeacht AI-review.

Geen runtime-begrip. AI-reviewers zien statische code. Ze kunnen geen problemen detecteren die zich alleen tijdens runtime manifesteren: geheugenlekkages onder belasting, timing-afhankelijke race conditions of prestatievermindering op schaal.

False positives zijn onvermijdelijk. Zelfs met strakke prompts en projectcontextbestanden zullen modellen correcte code signaleren. Reken op 10-20% false positives in de bevindingen. Als het percentage hoger is, verscherp je prompts en voeg meer context toe aan CLAUDE.md of GEMINI.md.

Geen institutionele kennis. Het model kent de ongeschreven conventies van je team, historische beslissingen of domeinspecifieke patronen niet, tenzij je ze documenteert in de contextbestanden. Investeer tijd in het schrijven van goede CLAUDE.md- en GEMINI.md-bestanden. Deze investering betaalt zich terug bij elke toekomstige review.

Determinisme. Dezelfde PR twee keer beoordeeld kan verschillende bevindingen opleveren. AI-review is probabilistisch. Behandel "geen bevindingen" niet als "geen bugs".

Probleemoplossing

De Claude-review workflow triggert nooit. Controleer het paths-filter. Als je broncode buiten src/, lib/ of app/ staat, pas de paden aan zodat ze overeenkomen met je projectstructuur. Controleer ook of de Claude GitHub App is geïnstalleerd op de repository.

Gemini geeft lege reviews. Bevestig dat het GEMINI_API_KEY-secret is ingesteld en de sleutel geldig is. Test lokaal:

curl -s "https://generativelanguage.googleapis.com/v1beta/models?key=YOUR_KEY" | head -20

Als je een lijst met modellen ziet, werkt de sleutel.

Reviews duren te lang. De instelling timeout-minutes: 15 beëindigt de workflow als deze 15 minuten overschrijdt. Grote PR's met meer dan 1.000 regels kunnen 5-10 minuten duren. Als timeouts vaak voorkomen, verscherp het paths-filter om de diff-grootte te verkleinen.

Te veel false positives. Voeg projectcontext toe aan CLAUDE.md en GEMINI.md. Wees specifiek over patronen die het model moet negeren. "Signaleer X niet" is effectiever dan "wees mild".

Statuscontrole blijft in afwachting. De aggregatieworkflow triggert bij voltooiing van workflow_run. Als een van de twee reviewworkflows wordt overgeslagen (omdat er geen overeenkomende bestanden zijn gewijzigd), triggert de aggregatie mogelijk niet. Voeg een paths-filter toe aan de aggregatieworkflow dat de unie van beide reviewworkflows dekt, of gebruik een aparte statuscontrole die altijd draait.

Copyright 2026 Virtua.Cloud. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.

Klaar om het zelf te proberen?

Deploy uw eigen server in seconden. Linux, Windows of FreeBSD.

Bekijk VPS-aanbod