Il piano è una fase, non un preambolo
Il modo documentato per far dichiarare l’intenzione prima dell’azione non è una casella da spuntare: è conversazionale. Con il cloud agent di Copilot — quello che gira su GitHub e lavora su un branch — il flusso descritto dalla documentazione ha tre momenti distinti. Prima si fa ricerca, aprendo una sessione dal tab degli agenti, dal pannello o da Copilot Chat e chiedendo di indagare (per esempio di investigare i problemi di performance di un’applicazione e proporre miglioramenti). Poi si chiede esplicitamente un piano: si descrive che cosa si vuole ottenere, si legge la risposta e si itera con Copilot finché il piano combacia con la propria intenzione. Solo dopo si passa all’implementazione, chiedendo di realizzare il piano concordato.
⚠️ Qui sta la prima confusione da evitare, e l’esame la sfrutta: non esiste un pulsante di approvazione del piano. Non c’è nessun gate tecnico fra la fase di pianificazione e quella di scrittura del codice; si avanza quando lo si chiede, iterando in chat. La separazione fra pensiero e azione, in questo flusso, è una disciplina di processo, non un controllo di prodotto. Il codice compare su un branch con nome nella forma copilot/BRANCH-NAME, si ispeziona con il pulsante Diff, e la pull request nasce quando si clicca Create pull request: la documentazione precisa che le sessioni non creano pull request automaticamente.
Sulla Copilot CLI — la superficie locale — la separazione è invece incorporata in un comando. Il comando slash /research attiva un agente specializzato che raccoglie informazioni dal codebase, da repository GitHub pertinenti e dal web, e produce un report Markdown con citazioni. La documentazione è esplicita sul confine: la ricerca produce un report, non modifiche al codice, e usa il tool create per salvare il file del report ma non edit, bash o altri tool che modificano codice. È l’esempio più pulito di pianificazione che, per costruzione, non può eseguire.
Un piano strutturato che si può leggere e correggere
Per ottenere un piano in forma prevedibile invece che in prosa libera si usa un custom agent. La libreria di personalizzazione documenta l’agente implementation-planner, definito in .github/agents/implementation-planner.agent.md, che analizza i requisiti e produce specifiche tecniche in Markdown organizzate in sezioni ricorrenti: Overview, Technical Approach, Implementation Plan, Considerations e Not Included. Il punto interessante non è il testo delle istruzioni ma la riga tools: limitando i tool a lettura, ricerca e scrittura di file, l’agente può depositare il documento di piano nel repository senza avere accesso a una shell.
---
name: implementation-planner
description: Creates detailed implementation plans and technical specifications in markdown format
tools: ["read", "search", "edit"]
---Il reference sulla configurazione dei custom agent elenca le chiavi disponibili nel frontmatter: oltre a name, description e tools ci sono target, model, disable-model-invocation, user-invocable, infer, mcp-servers e metadata. Attenzione al fatto che il supporto varia per superficie: sul cloud agent alcune chiavi vengono ignorate, e mcp-servers e metadata non sono usate nei custom agent degli IDE. Il risultato di questo approccio è un artefatto ispezionabile dentro il tooling standard: un file Markdown versionato, che si rivede in pull request come qualsiasi altro file, accanto al session log consultabile da github.com/copilot/agents, dove si vede il ragionamento interno dell’agente e i tool che ha usato, e da dove si può fermare tutto con Stop session.
Trattenere l’azione: automation level, rationale, confidence
Per le automazioni sulle issue il grado di autonomia è invece configurabile davvero. Nelle impostazioni del repository, nella sezione Planning, la voce Agent suggestions for issues espone un Automation level con quattro valori che sono in sostanza una soglia di confidenza. Full control trattiene ogni cambiamento e non applica nulla da sé. Cautious, il default, applica automaticamente solo i cambiamenti ad alta confidenza e trattiene il resto. Balanced applica ciò che è di routine e chiaro, trattenendo quello che presenta ambiguità. Full automation applica tutto, e trattiene solo ciò che risulta segnalato come incerto.
Ogni azione supportata registra il motivo per cui è stata compiuta o proposta: la rationale si apre dall’icona informativa, e accanto compare la confidence su tre livelli (high, medium, low). Le proposte trattenute finiscono nel pannello delle approvazioni sull’issue, dove si vedono la modifica, la sua motivazione e la confidenza, e si risolvono con Accept o Decline, oppure in blocco con Accept all e Decline all. Le issue che aspettano una revisione si trovano con il qualificatore di ricerca has:suggestions, per esempio in una query del tipo is:issue is:open has:suggestions. Da ricordare per l’esame: la documentazione avverte che le approvazioni sono una comodità di flusso, non un controllo di sicurezza — un agente che ha i permessi può applicare cambiamenti direttamente via API aggirando le suggestion.
Autonomia calibrata e guardrail veri
I controlli che tengono davvero sono altrove, e cambiano da superficie a superficie. Sulla CLI l’autonomia si alza con la modalità autopilot, che si raggiunge ciclando le modalità con Shift+Tab o con il flag --autopilot, eventualmente con --max-autopilot-continues per limitare le prosecuzioni; ma in autopilot Copilot non può compiere azioni che richiedono permesso a meno che non gli si conceda accesso pieno con --allow-all (alias --yolo), altrimenti nega da sé le richieste di tool che vorrebbero approvazione. Le regole di deny prevalgono sempre su quelle di allow. Nel Copilot SDK il gate è programmatico: l’hook onPreToolUse può restituire permissionDecision con valore allow, deny o ask, accompagnato da permissionDecisionReason. Nei GitHub Agentic Workflows — i file Markdown in .github/workflows/ compilati in Actions — le operazioni di scrittura sono ammesse solo attraverso i safe-outputs dichiarati nel frontmatter, così l’agente produce issue, commenti e pull request pronti da rivedere mentre approvazioni e merge restano umani.
Sul cloud agent, infine, l’intervento umano non rallenta la consegna perché è posizionato sugli artefatti finali: l’agente è già impedito dal push sul branch di default e dal merge delle pull request, resta soggetto ai ruleset come qualunque persona, i workflow di Actions sulle sue pull request non partono finché qualcuno con accesso di scrittura non li approva, e i file di configurazione di Copilot si proteggono con un CODEOWNERS più la regola di revisione obbligatoria dei code owner.