Copilot può approvare una pull request: come evitare il merge in autopilot

Cosa cambia, e cosa resta una decisione umana

GitHub ha annunciato il 1° settembre 2026 una public preview per i piani Copilot Pro, Pro+, Max, Business ed Enterprise. Ogni code review di Copilot mostra ora un approval assessment, cioè una valutazione sintetica sulla possibilità di approvare la pull request. Questo assessment non soddisfa da solo i requisiti di merge.

La seconda capacità è più delicata: se gli amministratori la abilitano, Copilot può inviare una vera review di approvazione. Una configurazione separata decide se quell’approvazione può contare nei requisiti della pull request. GitHub dichiara entrambe le opzioni disattivate per impostazione predefinita e permette controlli a livello enterprise, organizzazione e repository.

Il fatto tecnico è quindi preciso: una review AI può contribuire a sbloccare il merge. La conclusione editoriale non è che il codice sia sicuro o corretto. Un’approvazione attesta l’esito di quella review, con il contesto che Copilot ha potuto analizzare; responsabilità, impatto e rischio restano da valutare nel workflow del team.

Perché un’approvazione AI non è una review indipendente

La regola “serve un’approvazione” nasce per introdurre un controllo distinto da chi ha prodotto la modifica. Nei workflow agentici, autore e reviewer possono condividere modello, istruzioni, contesto incompleto o punti ciechi. Anche se le due esecuzioni sono separate, il secondo passaggio non diventa automaticamente indipendente.

Il rischio cresce quando una pull request è stata aperta da un agente, corretta dallo stesso ecosistema e approvata da Copilot senza una persona che controlli requisiti, comportamento e conseguenze. Il risultato può essere internamente coerente e insieme sbagliato rispetto al bisogno reale, ai dati coinvolti o a un vincolo non presente nel repository.

GitHub mantiene una protezione distinta per le pull request Copilot non attribuite a una persona: nei ruleset, il requisito di un’approvazione aggiuntiva è attivo per impostazione predefinita. È un guardrail utile, ma non sostituisce la scelta esplicita di chi deve revisionare autenticazione, pagamenti, dati personali, infrastruttura e altri percorsi critici.

Quattro modalità, dal segnale al requisito di merge

Non serve passare direttamente da “funzione spenta” a “approvazione che sblocca il merge”. Le impostazioni separano la capacità di inviare una review dal suo peso nei requisiti. Questo consente un rollout osservabile, con un livello intermedio in cui Copilot approva ma il suo voto non conta ancora.

La scelta dovrebbe dipendere dalla classe di rischio e dalla qualità dei controlli automatici, non dall’entusiasmo per la novità. Se il team non sa spiegare quale livello usa e perché, la configurazione è già troppo implicita.

Solo assessment

Copilot mostra la propria valutazione, ma non invia un’approvazione formale. È il punto di partenza per osservare falsi positivi e omissioni.

Approva, ma non conta

Copilot può inviare una review positiva, mentre i requisiti di merge continuano a richiedere le approvazioni già configurate.

Conta su percorsi limitati

L’approvazione soddisfa il requisito soltanto se tutti i file modificati rientrano nei glob consentiti, per esempio documentazione non eseguibile.

Conta su tutto il repository

Lasciare vuoti i percorsi consente all’approvazione di contare per tutti i file. È la scelta con il perimetro più ampio e richiede guardrail forti.

Parti da file a basso rischio, non dall’intero repository

Nelle impostazioni del repository, GitHub permette di inserire fino a 15 glob. L’approvazione di Copilot conta soltanto quando ogni file modificato dalla pull request corrisponde ad almeno uno dei percorsi ammessi. Se lasci il campo vuoto, invece, può contare per tutti i file.

Un primo esperimento ragionevole può includere documentazione editoriale o esempi non eseguibili ed escludere codice, workflow, dipendenze e configurazioni di deploy. La regola “tutti i file devono corrispondere” è importante: una pull request mista, con documentazione e codice, deve uscire dal perimetro agevolato.

I glob sotto sono un esempio da adattare alla struttura reale. Prima di abilitarli, elenca i file che possono modificare produzione anche se sembrano documentazione: configurazioni, template eseguibili, script incorporati e file di istruzioni per agenti meritano una valutazione separata.

docs/**/*.md
README.md
CHANGELOG.md

Verifica attesa:
- solo docs/ e README.md -> l’approvazione può contare
- docs/ più src/ -> l’approvazione non deve contare
- workflow o configurazione -> richiede il percorso umano

Il ruleset minimo per non affidarsi a un solo giudizio

L’approvazione è un controllo, non l’intero gate. I ruleset di GitHub possono richiedere test, review di code owner, risoluzione delle conversazioni e una nuova approvazione dopo modifiche al diff. La combinazione conta più del singolo segnale.

Per i percorsi sensibili, assegna code owner umani e rendi obbligatoria la loro review. Per il codice eseguibile, richiedi gli status check della build e dei test e, quando possibile, limita la fonte accettata per ciascun check all’app prevista. Blocca i bypass non necessari: un guardrail che chiunque può ignorare non è un requisito.

GitHub indica che i nuovi commit successivi a un’approvazione di Copilot la invalidano come avviene per una review umana. Conserva comunque nel ruleset l’opzione che elimina le approvazioni stale quando cambia il diff: rende esplicito il comportamento anche per gli altri reviewer e riduce il rischio di aggiunte non revisionate.

• Pull request obbligatoria sulla branch protetta.
• Status check richiesti per build, test e controlli di sicurezza pertinenti.
• Review umana di CODEOWNERS sui percorsi ad alto rischio.
• Approvazioni precedenti invalidate quando il diff cambia.
• Conversazioni da risolvere prima del merge.
• Bypass limitati e verificabili.

Una prova controllata prima di far contare l’approvazione

Esegui la prova su un repository non critico o su percorsi documentali. Abilita prima la capacità di approvare lasciando disattivato il conteggio nei requisiti di merge. In questo modo puoi confrontare il giudizio di Copilot con la review umana senza cambiare chi può sbloccare la pull request.

Non misurare soltanto quante approvazioni arrivano. Registra cosa Copilot ha visto, quali finding ha prodotto, quali problemi ha mancato e se ha distinto una modifica innocua da una variazione che cambia comportamento. Solo dopo una serie di casi noti valuta un perimetro di file limitato.

1. Definisci un repository, una branch e un insieme di file a basso rischio.
2. Attiva le review automatiche sui nuovi push, ma lascia l’approvazione fuori dai requisiti di merge.
3. Apri una pull request documentale corretta e confronta assessment, commenti e review umana.
4. Aggiungi un errore noto e non ambiguo, poi verifica se Copilot evita l’approvazione e lo segnala.
5. Dopo un’approvazione, invia un nuovo commit e controlla che il voto precedente venga invalidato.
6. Prova una pull request mista con un file fuori dai glob e verifica che l’approvazione non conti.
7. Conserva esiti e omissioni; abilita il conteggio soltanto se il rischio residuo è accettabile.

Repository e branch: <VALORI>
Percorsi ammessi: <GLOB>
Review sui nuovi push: sì / no
Copilot può approvare: sì
L'approvazione conta: no durante la prova

Caso: <DOCS CORRETTE / ERRORE NOTO / PR MISTA / NUOVO PUSH>
Assessment: <ESITO OSSERVATO>
Finding: <ELENCO O NESSUNO>
Review Copilot: <APPROVA / COMMENTA / RICHIEDE MODIFICHE>
Review umana: <ESITO>
Requisito di merge: <SODDISFATTO / NON SODDISFATTO>
Scostamenti: <ELENCO>
Decisione: <SPENTO / SOLO SEGNALE / PERIMETRO LIMITATO>

Dove può aiutare e dove non dovrebbe bastare

La tabella più utile non confronta modelli: collega tipi di modifica e forma di approvazione. L’elenco seguente è una policy editoriale prudente, non un requisito imposto da GitHub.

Anche nel perimetro a basso rischio, un errore ripetuto o una modifica difficile da annullare deve riportare il workflow alla review umana. Il livello non è un’etichetta permanente del repository: cambia con i file e con l’impatto della singola pull request.

• Documentazione non eseguibile: possibile prova con approvazione Copilot limitata per glob e controlli automatici.
• Test e fixture: Copilot può essere un secondo segnale, ma serve chi verifica che il test rappresenti il requisito.
• Codice applicativo: review umana più test; l’approvazione AI non dovrebbe essere l’unico gate.
• Autenticazione, autorizzazioni, pagamenti e dati personali: code owner umano obbligatorio.
• CI/CD, infrastruttura, segreti e dipendenze: review indipendente, provenance e piano di rollback.
• Pull request generata da un agente: conserva almeno un approvatore umano non coinvolto nella generazione.

Fonti primarie e stato della verifica

Annuncio, piani supportati, public preview, comportamento dell’assessment e approvazione disattivata di default provengono dal changelog GitHub del 1° settembre 2026. I due interruttori, il limite di 15 glob e la regola “tutti i file devono corrispondere” sono documentati nella guida di configurazione di Copilot Code Review.

Ruleset, invalidazione delle approvazioni, code owner, conversazioni e status check derivano dalla documentazione GitHub sulle regole disponibili. La fotografia è aggiornata al 2 settembre 2026: nomi delle opzioni, rollout e comportamento della public preview possono cambiare. Verifica sempre ciò che il tuo piano e la tua organizzazione mostrano prima di applicare la configurazione.

• GitHub Changelog: Copilot code review can now approve pull requests ↗
• GitHub Docs: configurare Copilot Code Review e auto-approval ↗
• GitHub Docs: regole disponibili nei ruleset ↗
• DottorLone: checklist prima di accettare codice generato dall’AI →
• DottorLone: usare VS Code Agent Merge senza delegare il giudizio →