Revisione del codice con IA in GitHub Actions con Claude e Gemini

14 min di lettura·Matthieu·ci-cdgeminiclaudeai-code-reviewgithub-actions|

Configura Claude Code Action e Gemini per la revisione automatizzata delle pull request. Workflow multi-modello con separazione dei ruoli, quality gate che bloccano i merge in caso di problemi critici e protezione contro l'iniezione di prompt.

La revisione del codice con IA è passata dall'essere un esperimento a uno strumento di produzione. Claude Code Action e Gemini Code Assist possono analizzare ogni pull request automaticamente, individuando bug logici, vulnerabilità di sicurezza e gestione degli errori mancante che i linter e l'analisi statica non rilevano.

Questo tutorial configura entrambi i modelli sullo stesso repository. Claude gestisce la revisione di logica e sicurezza. Gemini gestisce stile e documentazione. Un quality gate analizza la gravità di entrambe le revisioni e blocca i merge quando vengono trovati problemi critici.

AIOps su un VPS: gestione dei server con IA e strumenti open source

Cosa rileva la revisione del codice con IA che i linter non trovano?

I linter controllano sintassi e formattazione. Gli strumenti di analisi statica come Semgrep rilevano pattern noti. I revisori di codice IA fanno qualcosa di diverso: leggono il diff nel contesto e ragionano su cosa fa il codice. Segnalano condizioni di gara, percorsi di gestione degli errori mancanti, impostazioni predefinite non sicure ed errori di logica di business che gli strumenti basati su pattern non possono rilevare.

Uno studio di Milvus ha testato cinque modelli IA nel rilevamento di bug reali in PR di produzione. Il miglior modello singolo ha individuato il 53% dei bug. Quando più modelli hanno analizzato la stessa PR e discusso i risultati tra di loro, il rilevamento è salito all'80%. I bug più difficili, quelli che richiedono una comprensione a livello di sistema delle catene di chiamate e della propagazione degli errori, hanno raggiunto il 100% di rilevamento nella modalità di dibattito multi-modello.

Questo studio è il motivo per cui il tutorial usa due modelli invece di uno.

Esempi concreti di cosa rileva la revisione IA:

  • Input utente non validati che attraversano tre chiamate di funzione prima di raggiungere una query al database
  • Controlli null mancanti dove una funzione restituisce Optional<T> ma il chiamante assume che abbia sempre successo
  • Segreti hardcoded in file di configurazione che sembrano valori segnaposto ma sono credenziali reali
  • Lacune nella gestione degli errori dove un try/catch cattura un'eccezione generica e la ignora silenziosamente
  • Condizioni di gara nel codice concorrente dove lo stato condiviso viene modificato senza sincronizzazione

Come si configura Claude Code Action per la revisione delle pull request?

Claude Code Action è una GitHub Action mantenuta da Anthropic che esegue Claude sul tuo runner GitHub. Legge i diff delle PR, pubblica commenti inline e può anche implementare correzioni. La configurazione richiede circa cinque minuti.

Installare l'app GitHub Claude

Vai su github.com/apps/claude e installala sul tuo repository o organizzazione. Concedi l'accesso ai repository che vuoi far analizzare. L'app richiede questi permessi:

  • Contents: Read
  • Pull Requests: Read & Write
  • Issues: Read & Write (opzionale, per il triage delle issue)

Aggiungere la chiave API

Nel tuo repository, vai su Settings > Secrets and variables > Actions e crea un nuovo secret:

  • Name: ANTHROPIC_API_KEY
  • Value: La tua chiave API Anthropic (inizia con sk-ant-)

Non fare mai commit di chiavi API nel repository. Se hai bisogno di accesso a livello di organizzazione, usa i secret di ambiente invece dei secret di repository.

Creare il workflow

Crea .github/workflows/claude-review.yml:

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:*)"

Il filtro paths limita le revisioni alle modifiche del codice sorgente. Le PR che toccano solo la documentazione saltano il workflow, risparmiando sui costi API. Il blocco concurrency annulla le revisioni in corso quando un nuovo commit viene pushato sulla stessa PR, evitando di pagare per l'analisi di codice obsoleto.

La restrizione --allowedTools è una misura di sicurezza. Limita Claude alla lettura dei diff e alla pubblicazione di commenti. Non può modificare file, eseguire comandi arbitrari o accedere ad altri repository.

Come aggiungere la revisione Gemini allo stesso repository?

Due opzioni per la revisione con Gemini: l'app GitHub Gemini Code Assist (gestita da Google, zero YAML) o la GitHub Action run-gemini-cli (autogestita, controllo totale). Questo tutorial usa la GitHub Action perché offre il controllo sul prompt e si integra con il workflow del quality gate.

Ottenere una chiave API Gemini

Crea una chiave su Google AI Studio. Aggiungila come secret del repository:

  • Name: GEMINI_API_KEY
  • Value: La tua chiave API Gemini

Per l'uso aziendale con autenticazione Vertex AI, consulta la documentazione di run-gemini-cli per la configurazione di Workload Identity Federation.

Creare il workflow Gemini

Crea .github/workflows/gemini-review.yml:

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.

L'action run-gemini-cli è attualmente in beta, motivo per cui il workflow punta a @main. Per l'uso in produzione, fissa un SHA di commit specifico (es. @abc1234) per evitare cambiamenti inattesi quando il branch main viene aggiornato.

Perché due workflow separati?

Eseguire Claude e Gemini in file di workflow separati significa che girano in parallelo. Un errore in uno non blocca l'altro. Puoi anche disabilitare temporaneamente un modello senza toccare l'altro workflow.

La separazione dei ruoli è intenzionale. Claude tende a seguire le catene di chiamate dall'alto verso il basso ed è efficace nel rilevare lacune nella gestione degli errori e falle di sicurezza. Gemini è forte su stile del codice, completezza della documentazione e pattern strutturali. La sovrapposizione è normale. L'accordo tra modelli aumenta la fiducia nei risultati.

Come funziona la revisione multi-modello con Claude e Gemini insieme?

La configurazione a due workflow qui sopra implementa già la revisione multi-modello. Entrambi i modelli analizzano la stessa PR indipendentemente e pubblicano commenti separati. È il pattern più semplice e funziona bene per la maggior parte dei team.

Per i team che vogliono una vista unificata, aggiungi un passaggio di aggregazione. Questo terzo workflow si esegue dopo il completamento di entrambe le revisioni e pubblica un riepilogo combinato:

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

Questo è un punto di partenza. Adatta la logica di analisi dei commenti al formato esatto prodotto dai tuoi prompt. Le parole chiave di gravità (CRITICAL, HIGH, MEDIUM) nei prompt di revisione rendono il parsing diretto.

Come bloccare i merge quando la revisione IA trova problemi critici?

Il workflow di aggregazione qui sopra imposta il codice di uscita 1 quando esistono risultati critici. Per renderlo un blocco ai merge, configura la protezione del branch:

  1. Vai su Settings > Branches > Branch protection rules
  2. Seleziona o crea una regola per il tuo branch principale
  3. Attiva Require status checks to pass before merging
  4. Cerca e aggiungi "AI Review Summary" come status check obbligatorio
Gravità Azione Merge bloccato?
CRITICAL Fallimento dello status check Sì
HIGH Avviso nel riepilogo No (consultivo)
MEDIUM Elencato nel riepilogo No
LOW Omesso dal riepilogo No

Un avvertimento: i revisori IA producono falsi positivi. Se rendi lo status check obbligatorio, gli sviluppatori dovranno occasionalmente respingere risultati errati. Mantieni CRITICAL come unica gravità bloccante. Se blocchi anche su HIGH, aspettati attriti.

Per sovrascrivere un merge bloccato, un maintainer può usare il bypass amministratore sulla regola di protezione del branch, oppure puoi aggiungere un handler per il commento /dismiss-ai-review che rilancia il workflow di riepilogo con un flag di approvazione forzata.

Come ridurre i falsi positivi nella revisione del codice con IA?

I falsi positivi sono la lamentela principale dei team che usano la revisione del codice con IA. Revisioni rumorose erodono la fiducia rapidamente. Tre tecniche aiutano.

Definire il prompt con precisione

I prompt qui sopra lo fanno già: Claude analizza sicurezza e logica, Gemini analizza stile e documentazione. Un modello a cui si chiede di "analizzare tutto" produce più rumore di uno con un mandato specifico.

Aggiungi contesto specifico del progetto per ridurre ulteriormente i falsi positivi. Crea un file CLAUDE.md nella root del repository (Claude Code Action lo legge automaticamente):

# 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.

Per Gemini, crea un file GEMINI.md nella root del repository con contesto di progetto equivalente.

Filtrare i file

I filtri paths e paths-ignore nel YAML del workflow impediscono le revisioni di file che generano rumore:

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

I file lock, il codice generato, le dipendenze vendored e i file di migrazione producono falsi positivi perché sono generati da macchine o seguono pattern che il modello non comprende nel contesto.

Impostare una soglia di gravità

Se mostri solo i risultati CRITICAL e HIGH nel riepilogo, il rumore MEDIUM e LOW non raggiunge mai lo sviluppatore. È un'impostazione predefinita migliore rispetto a mostrare tutto e chiedere agli sviluppatori di ignorare il rumore.

Quali sono i rischi di sicurezza della revisione del codice IA sulle pull request?

I revisori di codice IA elaborano input non affidabili. Il diff della PR, i messaggi di commit, i titoli delle issue e il contenuto dei file sono tutti controllati dall'attaccante nei repository open source o quando si accettano contributi esterni. Questo crea un rischio di iniezione di prompt (prompt injection).

L'attacco Clinejection

A febbraio 2026, un attaccante ha sfruttato il bot di triage delle issue Cline tramite iniezione indiretta di prompt. L'attacco era semplice: un titolo di issue GitHub malevolo conteneva istruzioni mascherate da messaggio di errore. Il workflow dell'agente IA interpolava il titolo dell'issue direttamente nel prompt. L'agente ha seguito le istruzioni iniettate, eseguito npm install su un pacchetto malevolo e esfiltrato la chiave ANTHROPIC_API_KEY dall'ambiente CI.

L'attacco ha compromesso circa 4.000 macchine di sviluppatori prima che il pacchetto malevolo fosse rimosso.

Proteggere i tuoi workflow

Limita i permessi degli strumenti. Il flag --allowedTools nel workflow Claude qui sopra limita ciò che Claude può fare. Può leggere diff e pubblicare commenti. Non può eseguire comandi shell arbitrari, scrivere file o accedere ai secret. È la misura di mitigazione più efficace.

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

Senza questa restrizione, un diff di PR manipolato potrebbe istruire Claude a eseguire comandi sul runner.

Non interpolare mai input non affidabili nei prompt. Non usare ${{ github.event.issue.title }} o ${{ github.event.pull_request.body }} nel campo prompt. Passa il repository e il numero della PR, e lascia che l'action recuperi il contenuto tramite l'API di GitHub.

Gestisci le PR da fork con cautela. Le PR da fork vengono eseguite con permessi GITHUB_TOKEN ridotti per impostazione predefinita, ma i tuoi secret sono comunque disponibili per il workflow se attivato da pull_request_target. Usa pull_request (non pull_request_target) per i workflow di revisione IA. Le PR da fork non potranno accedere alle tue chiavi API e la revisione non verrà eseguita, che è il comportamento sicuro predefinito.

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

Ruota le chiavi API. Se una chiave viene esposta attraverso un log CI o un runner compromesso, il raggio di danno è limitato al tempo tra le rotazioni. Ruota almeno ogni trimestre.

Verifica le esecuzioni dei workflow. Controlla periodicamente la scheda Actions per tempi di esecuzione insoliti o invocazioni di strumenti inaspettate. Una revisione che impiega 45 minuti invece dei soliti 3 potrebbe indicare che il modello viene manipolato.

Quanto costa la revisione del codice con IA per pull request?

Il costo scala con la dimensione della PR. Sia Claude che Gemini addebitano per token elaborato. I token di input includono il diff della PR, il contesto dei file e il tuo prompt. I token di output sono i commenti di revisione.

Dimensione PR Diff tipico (righe) Token di input stimati
Piccola 50-100 2.000-5.000
Media 200-500 8.000-20.000
Grande 500-1.500 20.000-60.000

Il conteggio dei token varia in base al linguaggio. Un diff Python di 200 righe usa meno token di un diff Java di 200 righe perché Java è più verboso.

Usare due modelli raddoppia il costo in token ma non il costo in euro, perché i prezzi differiscono tra i fornitori. Consulta le tariffe attuali per token sulla pagina prezzi di Anthropic e la pagina prezzi di Google AI. Entrambi usano una tariffazione per token con tariffe diverse per token di input e output.

Per stimare il tuo budget mensile: moltiplica la dimensione media delle PR (in token) per il numero di PR al mese, poi moltiplica per la tariffa per token di ogni modello. Un team che fa merge di 50 PR a settimana con diff di dimensione media può calcolare:

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

Ridurre i costi

  • I filtri dei percorsi impediscono le revisioni di documentazione, file lock e codice generato. È il risparmio maggiore.
  • La cancellazione per concorrenza interrompe l'analisi di commit obsoleti quando arriva un nuovo push.
  • Salta le PR in bozza non includendo ready_for_review nei tipi di trigger, poi aggiungilo solo quando vuoi revisioni sulle transizioni da bozza a pronto.
  • Usa modelli più piccoli per la revisione dello stile. Gemini Flash è più economico di Gemini Pro per i controlli di stile e documentazione dove il ragionamento approfondito non è necessario.

Confronto: strumenti di revisione del codice con IA

Caratteristica Claude Code Action Gemini Code Assist CodeRabbit GitHub Copilot
Metodo di configurazione GitHub Action (YAML) GitHub App o Action GitHub App Integrato
Modello di prezzo Per token (API) Per token o livello gratuito Abbonamento per repository Abbonamento per postazione
Commenti inline Sì Sì Sì Sì
Prompt personalizzati Controllo totale Controllo totale (Action) File di configurazione Limitato
Runner self-hosted Sì Sì (Action) No No
Supporto multi-modello Combinabile Combinabile Modello singolo Modello singolo
Open source Sì (MIT) Sì (Action) No No

Claude Code Action e l'action Gemini CLI sono open source e girano sui tuoi runner. Il tuo codice non lascia mai la tua infrastruttura, ad eccezione della chiamata API al fornitore del modello. CodeRabbit e Copilot sono servizi gestiti dove il codice viene elaborato sulla loro infrastruttura.

Quali sono i limiti della revisione del codice con IA?

La revisione del codice con IA non sostituisce la revisione umana. È un primo passaggio che rileva i problemi comuni e libera i revisori umani per concentrarsi su architettura, design e decisioni di logica di business.

Limiti della finestra di contesto. Le PR grandi (oltre 1.500 righe modificate) possono superare la finestra di contesto del modello o produrre revisioni superficiali perché il modello non riesce a mantenere l'intero diff nel contesto. Dividi le PR grandi in più piccole. È una buona pratica indipendentemente dalla revisione IA.

Nessuna comprensione a runtime. I revisori IA vedono codice statico. Non possono rilevare problemi che si manifestano solo a runtime: memory leak sotto carico, condizioni di gara dipendenti dal timing o degrado delle prestazioni su larga scala.

I falsi positivi sono inevitabili. Anche con prompt ben definiti e file di contesto del progetto, i modelli segnaleranno codice corretto. Prevedi il 10-20% di falsi positivi nei risultati. Se il tasso è più alto, affina i tuoi prompt e aggiungi più contesto a CLAUDE.md o GEMINI.md.

Nessuna conoscenza istituzionale. Il modello non conosce le convenzioni non scritte del tuo team, le decisioni storiche o i pattern specifici del dominio a meno che non li documenti nei file di contesto. Investi tempo nello scrivere buoni file CLAUDE.md e GEMINI.md. Questo investimento ripaga in ogni futura revisione.

Determinismo. La stessa PR analizzata due volte può produrre risultati diversi. La revisione IA è probabilistica. Non trattare "nessun risultato" come "nessun bug".

Risoluzione dei problemi

Il workflow di revisione Claude non si attiva mai. Controlla il filtro paths. Se il tuo codice sorgente si trova fuori da src/, lib/ o app/, adatta i percorsi alla struttura del tuo progetto. Verifica anche che l'app GitHub Claude sia installata nel repository.

Gemini restituisce revisioni vuote. Conferma che il secret GEMINI_API_KEY è impostato e che la chiave è valida. Testala localmente:

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

Se vedi un elenco di modelli, la chiave funziona.

Le revisioni impiegano troppo tempo. L'impostazione timeout-minutes: 15 termina il workflow se supera i 15 minuti. Le PR grandi con oltre 1.000 righe possono richiedere 5-10 minuti. Se i timeout sono frequenti, restringi il filtro paths per ridurre la dimensione del diff.

Troppi falsi positivi. Aggiungi contesto del progetto a CLAUDE.md e GEMINI.md. Sii specifico sui pattern che il modello deve ignorare. "Non segnalare X" è più efficace di "sii indulgente".

Lo status check resta in attesa. Il workflow di aggregazione si attiva al completamento di workflow_run. Se uno dei due workflow di revisione viene saltato (perché nessun file corrispondente è cambiato), l'aggregazione potrebbe non attivarsi. Aggiungi un filtro paths al workflow di aggregazione che copra l'unione di entrambi i workflow di revisione, oppure usa uno status check separato che viene sempre eseguito.

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.

Pronto a provare?

Distribuisci il tuo server in pochi secondi. Linux, Windows o FreeBSD.

Vedi piani VPS