Revisione automatica del codice nel 2026: eseguila su ogni PR senza acquistare un posto

La revisione automatica del codice è un job di CI che invia il tuo diff a un modello linguistico, pubblica le segnalazioni sulle righe interessate e fa fallire uno status check quando trova qualcosa di serio. Il modo per farlo girare su ogni pull request senza un abbonamento per posto è self-hostare un harness open-source: copia un workflow di una quindicina di righe nel tuo repository, aggiungi una chiave API e paga solo per i token che ogni revisione consuma. Non c'è un numero di posti da acquistare, perché non c'è alcun posto. L'implementazione di riferimento che manteniamo è il repository Orca-Code-Review — pubblico, con licenza MIT, che dalla sua creazione, il 25 giugno 2026, è il codice alla base della GitHub Action OrcaCode Review. La sua ricetta di routing inclusa usa di default DeepSeek V4 Flash per il passaggio di revisione e GLM-5.3 come giudice di verifica indipendente, e puoi modificarli entrambi. Questo articolo illustra cosa viene effettivamente eseguito a ogni push, cosa configuri, quanto costa in token e le modalità di errore che incontrerai nella seconda settimana.

La versione breve. Ogni push riceve una revisione. I rilievi vengono pubblicati come commenti inline sulle righe modificate. I rilievi P0 e P1 fanno fallire il controllo e bloccano il merge; un'esecuzione pulita passa. Puoi richiedere una nuova revisione quando vuoi commentando con /orcacode-review. Il workflow risiede nel tuo repository; la logica di revisione risiede nell'azione pubblicata; la scelta del modello risiede in una ricetta di routing che puoi modificare nel tuo workspace. Il revisore legge il diff e i file del repository e non esegue mai il codice della tua PR. E l'avvertenza onesta fin dall'inizio: individua bug reali, ma quelli che richiedono una persona che sappia perché il codice è fatto in quel modo continuano a sfuggirgli.

• Un flusso di lavoro + un segreto + una fatturazione a token. Nessuna licenza per utente in alcun momento.

• L'harness è open source. Copialo, fai un fork, auditalo, fissalo a uno SHA di commit.

• Il modello è un'impostazione, non un fornitore. Cambia il revisore modificando una ricetta di routing, non riscrivendo YAML o aggiornando l'azione.

• I diff sovradimensionati non costano nulla. Il controllo dimensionale viene eseguito prima del modello.

• Legge il tuo codice, non lo esegue mai. Questa è la proprietà di sicurezza che rende pull_request_target sicuro da usare.

Come funziona realmente la revisione automatica del codice

Ogni sistema di revisione automatizzata sono gli stessi tre ingredienti con abiti diversi: un evento, un esecutore e un revisore.

L'evento è il trigger. Il workflow fornito si attiva su eventi di pull request — opened, synchronize (un nuovo push), ready_for_review (una bozza diventa pronta) — e su un commento PR. Poiché viene eseguito su pull_request_target, la definizione del workflow viene letta dal ramo di base, motivo per cui il workflow deve esistere sul ramo di base prima di poter essere eseguito per una PR. Una review per push; il concurrency block annulla l'esecuzione precedente, quindi una rapida sequenza di push non accoda cinque review di codice obsoleto.

Il runner è GitHub Actions su ubuntu-latest. Il job richiede tre permessi: accesso in lettura ai contenuti, accesso in scrittura alle pull request (per pubblicare commenti inline), e accesso in scrittura alle issues (per pubblicare il riepilogo e ripulire i commenti obsoleti).

Il revisore è un modello linguistico. L'azione recupera la testa della PR, assembla il diff e il contesto del repository che il motore seleziona, e lo invia al modello di revisione. Il risultato è un insieme di osservazioni, ognuna etichettata con una gravità e ancorata a un file e a una riga. L'azione le pubblica come commenti PR inline e scrive un commento di riepilogo in una regione contrassegnata all'inizio della descrizione della PR, sostituito in loco a ogni push.

Il gate è uno status check. GitHub non sa cosa significhi “review”; sa solo se il review check passa. Rendi il gate reale contrassegnando tale check come obbligatorio nella protezione del ramo. Questo è l'intero meccanismo di blocco del merge — nessuna chiamata API admin, nessuna etichetta, solo un check obbligatorio non riuscito.

Cosa non accade: nessuno esegue il codice della PR. Il motore si limita a leggere. È proprio questo invariante che rende sicuro l'uso del trigger privilegiato pull_request_target con una chiave API a pagamento.

L'harness open-source è il fattore differenziante.

Tutto quanto sopra è vero per molti strumenti. Ciò che non è vero per la maggior parte di essi è che l'intera cosa è ispezionabile e auto-ospitabile, ed è ciò che il repository Orca-Code-Review ti garantisce. È un repository GitHub pubblico con licenza MIT (JavaScript, creato il 25 giugno 2026) che impacchetta la revisione come una GitHub Action composita riutilizzabile e un installer, ed è lo stesso codice che l'app OrcaCode Review ospitata esegue.

Trascorri dieci minuti nell'albero e puoi nominare ogni parte che tocca la tua PR:

• action.yml — l'azione composita, con circa quindici input documentati. Nessun nome di modello è hard-coded al suo interno.

• workflows/orca-code-review.yml — il workflow consumer di esempio, le circa quindici righe che copi in .github/workflows/.

• recipes/ — il DSL di routing. È qui che il modello viene effettivamente scelto.

• rules/ — la rubrica di gravità (P0–P3), la struttura di output obbligatoria e una direttiva sulle convenzioni che inserisce il documento di convenzioni del progetto nella revisione come dati di riferimento non attendibili.

• scripts/ — il filtro di precisione (L1 più un giudice L2), la guardia diff, il gate di merge, il report di esecuzione e il contatore di token. Ciascuno è un piccolo e leggibile .mjs file con test.

• skills/setup-orca-code-review — la skill che l'installer inserisce nel tuo agente di codifica, che copre installazione, riconfigurazione, risoluzione dei problemi e disinstallazione.

• .claude-plugin/ — ciò che consente a Claude Code di installare la skill come plugin auto-aggiornante.

Installare è una sola riga di comando che insegna alla tua IA cos'è il prodotto e poi si ferma:

npx @orcarouter/code-review

La CLI rileva quali agenti di coding usi — il catalogo copre 36 piattaforme, da Claude Code, Cursor, Codex, OpenCode e Windsurf a GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode e altri — installa la skill e passa la mano. Poi chiedi al tuo agente in linguaggio naturale: “configura OrcaCode Review in questo repo,” “blocca solo P0,” “perché non è stata eseguita la review?” La skill gestisce l'intero ciclo di vita: scrive il workflow, ti guida passo passo nella configurazione della chiave API, imposta il gate e pone solo le domande che sono realmente tue.

Claude Code può invece installare la skill come plugin, che la mantiene aggiornata man mano che il repository si evolve:

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

/plugin install orca-code-review

Nessun agente? Lo stesso ciclo di vita è fatto di semplici sottocomandi — init scrive il workflow, reconfigure modifica le regole di blocco e i limiti di diff, doctor diagnostica le review che non vengono eseguite o non vengono pubblicate, uninstall lo rimuove (eliminando prima la check obbligatoria). La skill è la porta d'ingresso, non l'unica porta. Oppure collegalo a mano: copia il workflow, aggiungi un segreto chiamato ORCAROUTER_API_KEY, e segna la review come check obbligatoria.

Il motore sottostante è Open Code Review di Ali​baba, fissato a una versione esatta e con licenza Apache-2.0. OrcaCode decide come revisionare; OrcaRouter decide quale modello la esegue. Il bilancio tra self-host e hosted — quanto costa realmente “gratis” quando si auto-ospita un revisore open-source — viene analizzato nel nostro articolo sulla revisione open source del codice.

Cosa viene eseguito, in ordine, a ogni push?

È utile conoscere l'ordine, perché ogni passaggio può fallire o essere saltato in modo indipendente:

• Il controllo diff viene eseguito per primo, prima ancora che il modello venga eseguito. Se il diff della merge-base supera 512 KB o coinvolge più di 300 file, la revisione viene saltata e viene pubblicato un avviso. Il valore predefinito è on-oversized-diff: fail, quindi un diff che supera i limiti non può attraversare un gate obbligatorio senza essere revisionato. Questo è anche il controllo della spesa: una PR sovradimensionata costa zero token.

• Il motore esamina il diff. Una passata, con concorrenza per file predefinita a 24, con un tetto massimo di tempo reale di 20 minuti per passata.

• Il filtro di precisione post-elabora i risultati grezzi. L1, un filtro deterministico, verifica lo snippet di codice esistente dichiarato da ciascun risultato rispetto al commit esaminato e ricolloca o scarta le discrepanze. L2, un giudice LLM, raggruppa i risultati per causa principale e scarta i cluster a bassa confidenza. Entrambi i livelli sono soft-fail: un errore mantiene i risultati dello stadio precedente e non interrompe mai la revisione.

• Il gate si applica. I risultati P0 e P1 non superano il controllo; il riepilogo della PR conta ogni risultato, inclusi quelli silenziati dal diff.

• Il contatore stampa quanto è costato. Il contatore di input registra la contabilità dei token per chiamata — prompt, completamento, token memorizzati nella cache e il modello risolto dal router — e stampa una tabella dei totali nel log del job.

• Un report di esecuzione opzionale invia i conteggi di gravità e i metadati dei gate al piano di controllo OrcaRouter per il dashboard di analisi. Non trasporta codice, né diff, né testo dei finding.

Cosa configuri effettivamente

Ci sono tre superfici, e hanno raggi d'esplosione molto diversi.

1. Il file del workflow. Il workflow consumer è volutamente minimale. Gli input che vale la pena toccare risiedono nell'azione: block-on (quali severità fanno fallire il controllo — default P0,P1), fix-first (quali severità interrompono prematuramente una revisione esaustiva), auto-review-authors (un'allowlist per chi viene revisionato automaticamente), max-diff-kb e max-diff-files e on-oversized-diff (la protezione per la dimensione), timeout-minutes, concurrency, meter, e report. Ciascuno ha un default documentato, quindi un nuovo workflow è cinque righe di YAML più un segreto.

2. La dashboard. Con settings: true (l'impostazione predefinita), ogni esecuzione recupera le impostazioni per repository da OrcaRouter → Apps → OrcaCode Review: il modello, la modalità di revisione, la policy di merge, i livelli di gravità dei report, la modalità silenziosa, la revisione esaustiva, una rubrica personalizzata e i guardrails. Imposta settings: "false" e il file del workflow fa fede — nessun valore della dashboard può sovrascriverlo. Se non apri mai la console, non perdi nulla dell'infrastruttura; configuri semplicemente in YAML.

3. La ricetta del routing — quella che tutti si lasciano sfuggire. L'azione non nomina mai un modello. Invece inietta dati grezzi come header di richiesta — a quale tier è stato registrato il run, se il passaggio precedente ha trovato un P0/P1, e un marcatore lens quando la richiesta è il giudice L2 — e la ricetta DSL del workspace router mappa quegli header su un modello concreto. La ricetta preinstallata assegna di default la revisione a DeepSeek V4 Flash e il giudice a GLM-5.3, instradando i due su modelli separati appositamente. Cambiare il modello che revisiona il tuo codice è una modifica a quella ricetta nel tuo workspace: nessun bump di versione dell'azione, nessuna riscrittura YAML, nessun redeploy.

Il contratto di severità è composto da due impostazioni indipendenti, non da una sola. La politica di merge decide cosa blocca il merge; la segnalazione delle severità decide cosa viene pubblicato sul diff. Le impostazioni predefinite incluse sono: P0/P1 bloccano, P2/P3 passano. Una severità che blocca viene sempre pubblicata, qualunque cosa dica l'impostazione di segnalazione — un controllo fallito senza nulla sul diff che lo spieghi è peggio di uno rumoroso. P0 indica una vulnerabilità di sicurezza sfruttabile, perdita di dati, un crash su un percorso normale o una build rotta; P1 indica un bug reale ma contenuto; P2 indica un difetto genuino che si attiva solo in una precondizione anomala; P3 è una questione di stile. Quando si è indecisi tra due livelli, la regola dice di scegliere quello più basso.

Quanto costa

Per token, non per utente. Scegli il modello su OrcaRouter, la fatturazione avviene per token consumato, e il contatore rende visibile il numero per esecuzione invece di lasciarlo misterioso. Le meccaniche di GitHub, la revisione del codice a consumo di Copilot dal 1° giugno 2026 e il modo in cui i revisori di terze parti si inseriscono in quel flusso di lavoro sono trattati nella nostra guida alla revisione del codice su GitHub. Il confronto completo dei costi voce per voce — prodotti per utente vs prodotti per token, con un esempio svolto — si trova nel nostro confronto degli strumenti di revisione del codice con IA, e la questione di quanto costa in token una singola passata di revisione quando il revisore esplora effettivamente il repository (la distinzione bot-vs-agente) è trattata nel nostro articolo sugli agenti di revisione del codice. Il punto che questo articolo aggiunge è la forma della fattura: scala con il codice che revisioni, non con il numero di persone che lo revisionano.

Due controlli di spesa contano fin dal primo giorno. Su un repository pubblico, pull_request_target bypassa il gate di approvazione delle fork di GitHub e la chiave di revisione è a consumo sul wallet — uno sconosciuto può aprire una PR e innescare revisioni a pagamento. Imposta un budget del wallet con avvisi sulla chiave, e imposta auto-review-authors a qualcosa come OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR così i contributor sconosciuti non vengono revisionati automaticamente. E la protezione del diff, come già detto, fa sì che le PR sovradimensionate non costino nulla.

Cosa si rompe

La revisione automatizzata è CI. Si rompe come la CI, e le modalità di errore, per lo più, non sono colpa del modello:

• Il workflow non viene mai eseguito. Per pull_request_target il workflow viene letto dal branch di base — un workflow aggiunto solo nel branch della PR non verrà eseguito finché la PR non viene unita. Verifica anche che l'app sia abilitata, che la funzione auto_review sia abilitata, che la PR non sia una bozza (le bozze vengono saltate in modalità ready_for_review) e che le Actions siano abilitate sul repository (i repository forkati hanno le Actions disabilitate per impostazione predefinita).

• /orcacode-review non fa nulla. Il trigger del commento richiede che il commento inizi con una delle quattro grafie — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — e che chi commenta sia un OWNER, MEMBER o COLLABORATOR. Uno spazio iniziale interrompe la corrispondenza. Il comando di un contributore esterno viene ignorato silenziosamente, di proposito: il comando esegue un workflow privilegiato che detiene la chiave a pagamento.

• Un errore di autenticazione. Il segreto ha un nome errato o manca, la chiave è revocata o fuori budget, oppure il workflow è stato commutato su pull_request (che non può leggere i segreti dai fork).

• Il check è rosso con un avviso “diff troppo grande”. È il controllo dimensionale, che funziona come configurato. Dividi la PR, oppure alza i limiti, oppure imposta on-oversized-diff: pass — e tieni presente che con un check obbligatorio, pass significa che una PR abbastanza grande passa dritta attraverso il gate senza revisione.

• La revisione viene eseguita ma non compaiono commenti. Tre cause, tutte innocue o configurate: un'esecuzione pulita pubblica un riepilogo anziché commenti inline; la modalità silenziosa sta silenziando P2 al momento della pubblicazione (il gate e il report lo hanno comunque conteggiato); oppure il filtro di precisione ha scartato le segnalazioni — L1 scarta le segnalazioni il cui frammento non corrisponde al commit, L2 scarta i cluster a bassa confidenza. I conteggi di severità del job log indicano quale.

La postura di sicurezza merita di essere esposta chiaramente, perché è ciò che rende sicuro l'intero design. Il motore legge solo i file del diff e del repository; non esegue mai il codice della PR. Il revisore non ha autorità di merge — le segnalazioni possono bloccare un merge o aggiungere un commento, ma nessun percorso di codice consente all'output del modello di approvare o modificare il repository. Una segnalazione non taggata ha un comportamento fail-safe, trattata come bloccante piuttosto che consultiva. E il report di esecuzione non riporta né codice né testo delle segnalazioni. La configurazione a due livelli che rileva ciò che una revisione a singolo passaggio si lascia sfuggire è l'oggetto del nostro articolo sulla sicurezza della revisione del codice con IA; il modello di minaccia sopra descritto è documentato nel file SECURITY.md del repository.

Quando la revisione automatizzata è lo strumento sbagliato

È sbagliato più spesso di quanto i fornitori di strumenti ammettano. Non usarla quando:

• Il problema è il contesto, non la quantità. Se le revisioni sono lente perché i revisori devono capire il motivo per cui il codice è stato scritto in questo modo, un LLM che legge il diff aggiunge poco. Non ha memoria del thread del mese scorso e nessun senso della storia del sistema.

• Il diff è in gran parte codice generato o di terze parti. Output auto-formattato, file generati da scaffold, snapshot delle dipendenze. Esaminarlo brucia token e genera rumore, ed è esattamente dove la direttiva sulle convenzioni aiuta meno — il codice non è nello stile del progetto per scelta.

• Il team revisiona già tutto in coppia. La revisione automatizzata è una leva di volume. Se ogni modifica è già revisionata da un umano che era nella stanza, la macchina aggiunge una seconda opinione che di solito è meno informata della prima.

• Nessuno legge le segnalazioni. Una revisione su cui nessuno interviene è un flusso di lavoro che fallisce restando verde per sempre. Questo è il fallimento silenzioso più comune, e nessun filtro di precisione lo risolve.

• La revisione deve eseguire il codice. Se quello che ti serve è una suite di test per la PR, una revisione LLM è lo strumento sbagliato. Legge; non esegue. Una scansione di sicurezza che deve compilare ed eseguire l'artefatto appartiene a un lavoro separato e attentamente circoscritto — ricorda, il flusso di lavoro di revisione non deve mai essere esteso per eseguire codice controllato dalla PR.

• Il repository è minuscolo o usa e getta. Al di sotto di un certo tasso di modifiche, la revisione è più un overhead che i bug che intercetta.

Falsi positivi, e ciò che il filtraggio di precisione risolve e non risolve

L'accusa contro ogni revisore AI è che grida al lupo. L'harness affronta questo problema su due livelli, ed è utile essere precisi su quale livello risolve quale errore.

Il livello deterministico (L1) elimina la segnalazione fantasma: un motore a volte segnala codice che non esiste — uno snippet che si è spostato, una segnalazione copiata su un file adiacente. L1 verifica lo snippet di codice esistente di ogni segnalazione rispetto al commit effettivamente revisionato e riposiziona o scarta le discrepanze. Questo risolve la classe di falsi positivi del tipo "questa riga non esiste nemmeno", che è meccanica e verificabile.

Il livello di giudizio (L2) elimina il duplicato e l'affermazione non supportata: un giudice LLM raggruppa i riscontri per causa radice e scarta i gruppi la cui confidenza scende al di sotto della soglia di giudizio (default 0.5). Ciò risolve “lo stesso bug segnalato in tre modi” e il riscontro speculativo.

Ciò che nessuno dei due livelli risolve merita di essere detto ad alta voce. Una segnalazione sbagliata ma sicura di sé sopravvive al giudice — il giudice è un LLM, e un LLM che sembra sicuro non è la stessa cosa di una segnalazione vera. Un giudice che gira sul modello del revisore concorda con sé stesso e il pass diventa inerte pur continuando a riportare successo, ed è per questo che la ricetta predefinita indirizza il giudice verso un modello diverso da quello del revisore. E la griglia di severità è deliberatamente conservativa — “quando sei indeciso tra due livelli, scegli quello più basso” — il che significa che un bug reale ma condizionato ha più probabilità di essere classificato come avviso P2 che come P1 bloccante. È la calibrazione giusta per uno strumento che non deve bloccare tutto, ma è una calibrazione: scambia bloccanti mancati con meno falsi allarmi. Il riepilogo della PR conta sempre ogni segnalazione, quindi i P2 smorzati sono ancora lì da leggere. Se il compromesso non è giusto per il tuo team, la griglia e la soglia del giudice sono configurazione, non un ticket di supporto.

La conclusione

Per un team che vive già in GitHub Actions, l'harness open-source è il modo più economico per ottenere una revisione automatica del codice su ogni PR: un file di workflow, un segreto, una bolletta dei token che scala con il codice revisionato e una scelta del modello che ti appartiene. Compra un prodotto per utente quando vuoi zero operazioni e un fornitore a cui rivolgerti — non perché la revisione sia migliore, ma perché stai comprando il problema di qualcun altro invece di gestire il tuo. E prima di configurare qualsiasi cosa, chiediti se la revisione verrà letta. L'harness può far sì che la revisione avvenga automaticamente. Non può far sì che qualcuno la legga.

Vuoi lo stesso revisore senza eseguirlo tu stesso? OrcaCode Review esegue questo stesso harness come app GitHub ospitata — stessa ricetta aperta, stessa fatturazione per token, nessun posto.