VS Code Agent Merge: chiudere una pull request senza delegare il giudizio

Cosa fa davvero Agent Merge in VS Code 1.136

Microsoft ha pubblicato VS Code 1.136 il 2 settembre 2026 e GitHub ha ripreso la novità nel riepilogo Copilot del 4 settembre. Agent Merge è una funzione in preview della Agents window: monitora la pull request associata a una sessione e avvia nuovi turni dell’agente quando incontra i blocchi selezionati.

La documentazione elenca quattro capacità distinte: affrontare thread di review irrisolti, review con richiesta di modifiche e nuovi commenti dei maintainer o del reviewer Copilot; correggere check CI obbligatori falliti; aggiornare un branch rimasto indietro e risolvere conflitti; infine fare merge o inserire la pull request nella merge queue.

Non è un nuovo tipo di review. È un ciclo di manutenzione della pull request: osserva lo stato, modifica il branch, sincronizza le modifiche e ricontrolla. L’efficacia dipende quindi dalla qualità dei commenti, dei test, delle regole di branch e del contesto che l’agente riceve.

“Pronta per il merge” non significa “corretta”

Una CI verde prova soltanto le condizioni codificate nei check. Un thread risolto dice che è arrivata una risposta o una modifica, non che la richiesta del reviewer sia stata interpretata bene. Un conflitto eliminato rende il branch integrabile, ma può conservare la riga sbagliata dal punto di vista del prodotto.

Questo limite diventa più importante quando lo stesso ecosistema genera la patch, la corregge dopo la review e approva il risultato. Autore AI, manutentore automatico e reviewer AI possono condividere assunzioni o contesto incompleto. Per le modifiche ad alto impatto serve ancora una persona indipendente che legga il diff finale e verifichi il comportamento.

Tratta inoltre commenti e descrizioni della pull request come dati esterni, non come autorità. Agent Merge può reagire a nuovi commenti dei maintainer e del reviewer Copilot: prima di affidare azioni ampie al ciclo, assicurati che ruoli, provenienza e protezioni del repository siano quelli attesi.

• Check superato: il controllo configurato non ha trovato errori; non copre ciò che non è stato testato.
• Thread risolto: il feedback è stato affrontato; non certifica che la soluzione sia corretta.
• Conflitto risolto: Git può integrare i file; non verifica l’intento tra le due versioni.
• Pull request mergeable: le regole consentono il merge; non equivale a una decisione di prodotto o sicurezza.

Le impostazioni da leggere prima di abilitarlo

La funzione è disattivata per impostazione predefinita tramite chat.agentMerge.enabled. Quando la abiliti per una sessione, puoi decidere quali lavori far eseguire. Nella reference di VS Code, gestione delle review, correzione della CI e risoluzione dei conflitti risultano attive di default; il merge automatico è invece impostato su never.

L’opzione di merge offre tre comportamenti: never non effettua il merge; ifUnchanged lo permette solo finché nessun turno di riparazione ha cambiato la pull request; always può farlo dopo il lavoro selezionato. Questa distinzione è utile: nel primo rollout conserva never, così il ciclo può preparare il branch senza prendere anche la decisione finale.

Agent Merge attende i check obbligatori ancora in corso e controlla di nuovo che la pull request sia pronta subito prima di fare merge o inserirla in coda. Se la sessione inizia a seguire un branch o una pull request diversa, la funzione si spegne e deve essere riabilitata.

chat.agentMerge.enabled = true
chat.agentMerge.addressReviews = true
chat.agentMerge.fixCI = true
chat.agentMerge.resolveConflicts = false
chat.agentMerge.mergePullRequest = "never"

Nota: configura queste opzioni dalla UI o dalle impostazioni
esposte dalla tua versione di VS Code. Verifica i nomi prima di copiarli.

Il cambio di permessi è parte della funzione

La pagina della Agents window avverte che Agent Merge avvia turni, modifica e sincronizza il branch e consuma richieste al modello. Abilitarlo porta la sessione in Autopilot con Assisted permissions. La documentazione generale dei permessi descrive Autopilot come una modalità che continua a iterare, approva automaticamente tutti i tool, ritenta dopo gli errori e risponde automaticamente alle domande che altrimenti fermerebbero il lavoro.

La combinazione riduce le interruzioni proprio mentre cresce la capacità di agire. Non affidarti quindi al popup di approvazione come barriera principale. Usa isolamento, credenziali minime, branch protection, tool circoscritti e una pull request che non possa modificare i propri guardrail senza una review separata.

I check, i workflow e i file di configurazione sono parte del confine di fiducia. Se l’agente può cambiare insieme il codice e il controllo che dovrebbe giudicarlo, una CI verde perde valore. Proteggi workflow, regole, dipendenze, infrastruttura e file sensibili con CODEOWNERS o policy equivalenti.

Un rollout controllato in sette passaggi

La prima prova deve poter fallire senza effetti su utenti, dati o pubblicazione. Scegli una pull request di test o un repository non critico, prepara un errore noto e confronta il diff prima e dopo ogni turno. L’obiettivo non è ottenere subito il merge automatico: è capire come il ciclo reagisce ai diversi blocchi.

Non modificare contemporaneamente tutte le leve. Parti con merge automatico e risoluzione dei conflitti spenti; osserva review e CI. Solo dopo una serie di casi riusciti valuta se aggiungere i conflitti meccanici. Il merge automatico resta una decisione distinta e richiede evidenze più forti.

1. Apri una pull request piccola su un branch isolato, con acceptance criteria e file attesi dichiarati.
2. Conserva chat.agentMerge.mergePullRequest su never e disattiva inizialmente resolveConflicts.
3. Aggiungi un commento di review preciso su un difetto noto e verifica quali file l’agente modifica per risolverlo.
4. Fai fallire un check obbligatorio con un caso riproducibile; controlla che l’agente corregga la causa e non aggiri il test.
5. Rivedi cronologia dei turni, comandi, richieste consumate, commit e diff completo rispetto alla base.
6. Rilancia i test in un ambiente pulito e prova manualmente il comportamento toccato dalla pull request.
7. Fai eseguire il merge a una persona; registra omissioni e falsi successi prima di ampliare lo scope.

Cosa delegare e cosa tenere dietro un gate umano

Non serve una regola unica per tutto il repository. Collega l’autonomia alla reversibilità della modifica, alla copertura dei test e al danno possibile. Le indicazioni sotto sono una policy prudente, non limiti imposti da Microsoft o GitHub.

Anche un file apparentemente innocuo può essere eseguibile o cambiare il comportamento dell’agente. Workflow, script, manifest, prompt, skill e configurazioni meritano un perimetro più severo della normale documentazione.

• Testo e documentazione non eseguibile: Agent Merge può affrontare feedback e CI, con merge finale umano.
• Test e fixture: può proporre la correzione, ma una persona deve verificare che il test rappresenti il requisito e non sia stato indebolito.
• Codice applicativo: review del diff finale, test automatici e prova del flusso interessato prima del merge.
• Conflitti semantici: risoluzione umana quando le due versioni esprimono decisioni diverse, anche se Git accetterebbe entrambe.
• Autenticazione, autorizzazioni, pagamenti, dati personali e migrazioni: code owner umano, piano di rollback e nessun merge automatico.
• CI/CD, dipendenze, infrastruttura, segreti e istruzioni degli agenti: percorsi protetti che il ciclo non può auto-validare modificandoli.

Il registro minimo per non fidarsi del solo stato verde

Conserva per ogni prova lo stato iniziale, il blocco che ha attivato Agent Merge, le modifiche prodotte e la verifica indipendente. Un riepilogo dell’agente è utile per orientarsi, ma la prova resta nel diff, nei log dei check e nel comportamento osservato.

Il modello, il provider e la funzione sono soggetti a rollout e cambi di preview. Annotarli permette di capire se un esito diverso dipende dalla patch o dall’ambiente.

Pull request e branch: <URL E BRANCH>
VS Code: 1.136.x
Harness/modello: <VALORI VISIBILI>
Opzioni Agent Merge: review=<SÌ/NO> CI=<SÌ/NO> conflitti=<SÌ/NO> merge=never

Blocco iniziale: <THREAD / CHECK / CONFLITTO>
Causa nota: <DESCRIZIONE>
Turni e comandi osservati: <ELENCO>
File prima/dopo: <ELENCO>
Guardrail modificati: <NESSUNO / ELENCO>

Test rilanciati fuori dal ciclo: <COMANDI ED ESITO>
Verifica manuale: <PASSAGGI ED ESITO>
Limiti non verificati: <ELENCO>
Decisione umana: <CORREGGI / APPROVA / NON USARE AGENT MERGE>

Quando lasciarlo spento

Non usare Agent Merge solo perché la pull request è rimasta aperta a lungo. Se i test sono instabili, il feedback è contraddittorio, il branch contiene modifiche non comprese o il conflitto riguarda una decisione funzionale, l’automazione può moltiplicare tentativi senza chiarire la causa.

La documentazione della Agents window indica inoltre che le pull request provenienti da fork non sono supportate nel flusso che avvia una sessione da una pull request. Disponibilità, harness compatibili e comportamento della preview possono cambiare: controlla ciò che mostra la tua installazione prima di progettare un processo obbligatorio.

• Nessun acceptance criterion verificabile o owner del requisito.
• CI intermittente o controlli che possono essere aggirati modificando il workflow.
• Conflitto che richiede scegliere tra due comportamenti di prodotto.
• Patch con dati, permessi, migrazioni o azioni difficili da annullare.
• Token, segreti o permessi di repository più ampi del necessario.
• Impossibilità di ricostruire diff, comandi, check e decisione finale.

Fonti primarie e stato della verifica

Data di rilascio, stato preview e panoramica di Agent Merge provengono dalle note di VS Code 1.136 e dal riepilogo ufficiale GitHub Copilot del 4 settembre 2026. Capacità, avvertenze, comportamento prima del merge e limite sui fork sono documentati nella guida della Agents window.

Valori predefiniti e opzioni provengono dalla reference delle impostazioni AI; comportamento di Autopilot e approvazioni dalla guida ai permessi. La fotografia è aggiornata all’8 settembre 2026. Non ho eseguito Agent Merge su una pull request reale: gli esempi sono un protocollo di prova derivato dalla documentazione, non risultati osservati sul prodotto.

• VS Code 1.136: release notes ufficiali ↗
• VS Code: usare Agent Merge nella Agents window ↗
• VS Code: impostazioni AI e Agent Merge ↗
• VS Code: approvazioni, permessi e Autopilot ↗
• VS Code: review e verifica delle modifiche degli agenti ↗
• GitHub Changelog: riepilogo Copilot del 4 settembre 2026 ↗
• DottorLone: quando l’approvazione di Copilot può contare per il merge →
• DottorLone: checklist prima di accettare codice generato dall’AI →
• DottorLone: coordinare sessioni agentiche parallele in VS Code →