Copilot può approvare le pull request: quali garanzie per la revisione del codice?

Il 1° settembre 2026 GitHub ha annunciato in anteprima pubblica che Copilot Code Review poteva non solo indicare che una pull request gli sembrava pronta, ma anche inviare un'approvazione che conta nelle regole di merge quando un amministratore abilita questa capacità. La funzione è disattivata per impostazione predefinita e configurabile a livello di impresa, organizzazione e repository, con la possibilità di limitarla a determinati percorsi di file. Questa evoluzione può accelerare le modifiche di routine; soprattutto, modifica il confine di fiducia della catena di consegna.

Da ricordare: il parere di un agente può integrare una revisione, ma non deve mai diventare l'unico controllo di una modifica sensibile né approvare una modifica prodotta dalla stessa catena senza una convalida indipendente. Rami protetti, test, CODEOWNERS, separazione dei ruoli e tracciabilità restano le principali salvaguardie.

1. Distinguere valutazione e approvazione

GitHub introduce due comportamenti distinti. Tutte le revisioni Copilot possono includere una valutazione che indica se la pull request sembra pronta per l'approvazione. Questa indicazione appare nel commento di sintesi, ma non soddisfa i requisiti di merge.

Quando l'opzione è attiva, Copilot può inviare una vera approvazione. Può contare nel numero di approvazioni richiesto dalla regola di protezione. Se vengono inviati nuovi commit dopo l'approvazione, GitHub indica che essa viene revocata come quella di un revisore umano e che occorre richiedere una nuova revisione.

Questa distinzione deve rimanere visibile nell'interfaccia e nelle procedure. Uno sviluppatore non deve confondere «il modello non ha trovato un problema bloccante» con «la modifica è autorizzata a entrare in produzione». La prima frase descrive un segnale. La seconda implica una responsabilità e partecipa a una decisione di controllo.

In una prima fase, la valutazione non conteggiata può essere attivata ampiamente per misurare la pertinenza del segnale. L'approvazione effettiva deve restare limitata ai repository e ai percorsi il cui rischio è stato valutato.

2. Perché l'approvazione è un potere, non un commento

Una revisione del codice produce osservazioni. Un'approvazione modifica lo stato della pull request e può sbloccare un merge automatico. Costituisce quindi una chiamata a strumento con conseguenze, paragonabile all'aggiunta di un'etichetta di distribuzione o alla convalida di una modifica dell'infrastruttura.

La domanda centrale non è «Copilot sa rilevare i difetti?». È: in quali condizioni il suo giudizio può sostituire una parte del controllo obbligatorio? Un revisore umano talvolta conosce l'obiettivo aziendale, la storia del componente, un vincolo del cliente o una dipendenza operativa che non compare nel diff.

Il modello può inoltre essere influenzato dal contenuto del repository: commenti, documentazione, nomi di file o istruzioni integrate. Anche quando la piattaforma applica protezioni, i dati analizzati restano un input non affidabile. Una regola importante non deve dipendere unicamente da un sistema probabilistico che legge la modifica che deve autorizzare.

Occorre infine considerare i guasti correlati. Se lo stesso fornitore, modello o istruzione genera il codice e poi lo approva, le due fasi possono condividere gli stessi punti ciechi. Moltiplicare gli agenti non crea automaticamente indipendenza.

3. Preservare la separazione delle responsabilità

Il principio minimo è il seguente: una modifica non deve essere creata e approvata dalla stessa identità logica senza un altro controllo indipendente. Se Copilot o un agente apre la pull request, la sua approvazione non deve bastare per il merge.

Questa regola può essere applicata tramite la provenienza. Aggiungete alle pull request un attributo che indichi se la modifica è umana, assistita o generata da un agente. Le regole di merge richiedono allora una convalida umana per i contributi agentici, anche se è presente una revisione Copilot.

Per le semplici modifiche umane, Copilot può fornire un'approvazione complementare. L'organizzazione può decidere che conti come una delle due approvazioni, ma non come l'ultima approvazione su un componente critico. Un CODEOWNER resta responsabile del perimetro.

Separate anche le configurazioni. L'account che gestisce le regole di approvazione non deve essere modificabile dal workflow valutato. Le modifiche alle impostazioni aziendali, alla protezione dei rami e ai file di politica passano attraverso un gruppo ristretto e una revisione umana.

Infine, l'identità di Copilot deve essere esplicita nella cronologia. Un'approvazione automatizzata non deve apparire come quella di un membro del team. L'audit deve consentire di ritrovare il modello, la versione della funzione, la data, i commit esaminati e i controlli disponibili al momento della decisione.

4. Definire i percorsi che l'IA non può approvare da sola

GitHub permette agli amministratori di scegliere i percorsi che Copilot è autorizzato ad approvare. Questa capacità deve essere usata come una lista positiva: l'approvazione è valida soltanto nelle aree esplicitamente considerate poco rischiose.

Un primo perimetro può includere modifiche alla documentazione, esempi, traduzioni, test senza modifiche alla produzione, dipendenze di sviluppo o correzioni ripetitive in un componente ben coperto. Anche in queste aree, test e limiti di volume restano necessari.

Escludete almeno:

• file di segreti, identità e permessi;
• workflow CI/CD, script di distribuzione e infrastruttura;
• migrazioni e schemi di database;
• codice di autenticazione, pagamento, cifratura o controllo degli accessi;
• politiche di sicurezza, CODEOWNERS e protezioni;
• dipendenze di produzione e file di lock quando il loro impatto non è analizzato;
• codice regolamentato o soggetto a convalida contrattuale;
• modifiche massicce, generate o difficili da rivedere.

La sensibilità non dipende soltanto dal percorso. Una documentazione può contenere un comando operativo pericoloso; un test può disattivare un'asserzione. Aggiungete regole sulla dimensione del diff, sul tipo di file, sui permessi modificati e sulla presenza di indicatori di rischio.

I percorsi devono essere riesaminati a ogni evoluzione dell'architettura. Una cartella un tempo statica può diventare una fonte di configurazione attiva.

5. Rafforzare le protezioni dei rami e la CI

L'approvazione Copilot non deve aggirare i controlli esistenti. Richiedete un ramo aggiornato, stati CI obbligatori, nessuna conversazione irrisolta, firma dei commit quando la politica lo prevede e revoca delle approvazioni dopo una modifica.

I test devono coprire più della sintassi. Aggiungete analisi statica, dipendenze, segreti, migrazioni, contratti API, permessi e test di sicurezza adatti al componente. Una revisione IA può commentare un'intenzione; la CI fornisce prove riproducibili.

Usate una merge queue per evitare che un'approvazione convalidi uno stato diverso da quello realmente integrato. La coda riesegue i controlli sulla combinazione finale delle modifiche e limita i conflitti tra pull request approvate separatamente.

Per i repository ad alto impatto, richiedete un ambiente di preproduzione o una convalida di distribuzione distinta. Il codice può essere corretto localmente e produrre un effetto inatteso su dati, configurazione o osservabilità.

Non date all'agente la capacità di modificare i test obbligatori nello stesso percorso che approva. Quando una modifica riguarda la CI, la politica o i set di valutazione, si impone una revisione umana specifica.

6. Valutare la qualità della revisione prima dell'attivazione

Iniziate osservando le valutazioni non conteggiate. Per diverse settimane, confrontate il giudizio di Copilot con il risultato dei revisori umani, gli incidenti dopo il merge e i riscontri di produzione.

Costruite un insieme di pull request storiche contenente difetti noti: bug logico, controllo d'accesso mancante, migrazione rischiosa, concorrenza, rottura di compatibilità, fuga di dati, test indebolito e modifica documentale legittima. Misurate ciò che Copilot rileva, ciò che lascia passare e ciò che blocca erroneamente.

Le metriche utili sono il richiamo sui difetti critici, il tasso di falsa sensazione di sicurezza, il numero di commenti utilizzabili, il tempo di revisione e il tasso di disaccordo umano. Un tasso globale di accordo può essere elevato pur nascondendo gli errori rari più gravi.

Testate anche la robustezza: istruzione contraddittoria nel repository, diff molto voluminoso, codice generato, rinomina massiva, sottomodulo e file binario. Verificate che il sistema si astenga quando il contesto è incompleto o la pull request è fuori dal suo perimetro.

Ripetete la valutazione dopo ogni modifica importante del modello o della funzionalità. Un'anteprima pubblica evolve; un risultato ottenuto a settembre 2026 non garantisce lo stesso comportamento alcuni mesi dopo.

7. Distribuire per fasi e prevedere il rollback

La prima fase è informativa: Copilot commenta e pubblica la propria valutazione senza contare nelle regole. La seconda autorizza l'approvazione su un repository a basso rischio, ma richiede sempre un'approvazione umana. La terza consente all'approvazione di soddisfare una regola solo per un elenco molto limitato di percorsi e modifiche.

Non attivate globalmente a livello aziendale prima di avere osservato il comportamento per tipo di repository. Usate la gerarchia delle impostazioni per lasciare che organizzazioni o repository aderiscano esplicitamente al pilota.

Definite soglie di arresto: difetto critico non rilevato, tasso di falsi positivi troppo alto, divergenza con i revisori, modifica di comportamento non documentata o incidente dopo il merge. La disattivazione deve essere immediata e non richiedere la modifica di ogni repository singolarmente.

Conservate la cronologia delle decisioni. Quando un team amplia i percorsi autorizzati, fornisce i risultati della valutazione e il proprietario del rischio. L'autorizzazione scade automaticamente se non viene riesaminata.

Dopo la distribuzione, campionate le pull request approvate da Copilot ed eseguite una revisione a posteriori. L'assenza di un incidente visibile non prova l'assenza di difetti; il controllo continuo evita che la funzione diventi un automatismo dimenticato.

8. Una politica di riferimento per le organizzazioni

Una politica semplice può essere formulata così:

1. la valutazione Copilot è per impostazione predefinita un segnale consultivo;
2. l'approvazione effettiva è disattivata a livello aziendale, salvo delega esplicita;
3. solo i repository iscritti al pilota possono attivarla;
4. i percorsi autorizzati sono definiti positivamente;
5. i contributi agentici richiedono sempre un'approvazione umana;
6. i file sensibili e le modifiche di politica sono esclusi;
7. gli stati CI e CODEOWNERS restano obbligatori;
8. ogni nuovo commit revoca la decisione e attiva una nuova revisione;
9. il comportamento è valutato e sottoposto ad audit periodicamente;
10. un meccanismo centrale consente la disattivazione immediata.

Questa politica deve essere accompagnata da esempi, perché i team devono capire cosa costituisce una modifica semplice o sensibile. Deve anche precisare che l'approvazione tecnica non sostituisce la convalida di prodotto, legale o di sicurezza richiesta da alcuni progetti.

Il ritorno d'esperienza su Asana e l'uso di Codex per una migrazione del debito tecnico ricorda l'importanza di una forte copertura dei test e di una revisione umana di ogni modifica, anche quando gli agenti accelerano notevolmente il lavoro.

Conclusione

La possibilità che Copilot approvi una pull request può ridurre la latenza delle modifiche di routine, ma attribuisce a un sistema probabilistico un ruolo nella decisione di merge. Questo ruolo deve essere trattato come una delega di potere e non come un semplice commento arricchito.

Il quadro solido si basa su percorsi autorizzati, separazione tra autore e approvatore, protezioni dei rami, CI indipendente, CODEOWNERS, valutazioni locali e distribuzione progressiva. Partitech accompagna i team nella progettazione di queste politiche, nell'automazione GitHub e nell'integrazione degli agenti di sviluppo senza indebolire il controllo della consegna.

Riferimenti verificati il 3 settembre 2026

• GitHub — «Copilot code review can now approve pull requests», 1° settembre 2026: https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/
• Documentazione GitHub — protezione dei rami e regole delle pull request: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository
• Documentazione GitHub — CODEOWNERS: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners