La domanda da farsi prima di ogni risposta

“Copilot può fare questa cosa?” non è una domanda a cui si possa rispondere. La domanda corretta è sempre un’altra: su quale superficie? Perché una capacità esiste su una superficie e non su un’altra, e i nomi delle opzioni di configurazione non sono trasferibili da una all’altra. Le quattro superfici che GH-600 mette in gioco sono il cloud agent di Copilot, la Copilot CLI, il Copilot SDK e i GitHub Agentic Workflows. Ognuna ha un proprio ambiente di esecuzione, un proprio modello di fiducia e un proprio vocabolario di chiavi e flag.

Prendi l’abitudine di dichiarare la superficie a voce alta prima di descrivere qualsiasi comportamento. È un riflesso che vale sia in esame sia sul lavoro, perché la maggior parte degli errori di progettazione nasce dall’aspettarsi su una superficie una garanzia che appartiene a un’altra.

Le due superfici che vivono su GitHub

Il cloud agent gira in un ambiente di sviluppo effimero, alimentato da GitHub Actions, dove esplora il codice, lo modifica ed esegue test e linter. Il risultato del suo lavoro è sempre lo stesso: commit su un branch e una draft pull request che un essere umano deve rivedere e unire. I punti d’ingresso sono molti — il pannello degli agenti su GitHub.com, un issue, Visual Studio Code, una menzione di @copilot nei commenti di una pull request, le automation pianificate, l’assegnazione di un security alert — ma i vincoli restano: agisce solo sul repository indicato all’avvio del task, lavora su un branch alla volta e apre esattamente una pull request. Dal terminale si avvia una sessione con gh agent-task create, eventualmente con --follow per seguire il log: attenzione, è la CLI che delega al cloud agent, non la CLI che diventa il cloud agent.

Le mitigazioni sono altrettanto caratteristiche di questa superficie: l’accesso a Internet è limitato da un firewall personalizzabile, i caratteri nascosti vengono filtrati prima che l’input arrivi all’agente (contro il prompt injection), i workflow non partono finché il codice non è stato rivisto, chi ha richiesto le modifiche non può approvare la propria pull request e i commit dell’agente risultano attribuiti e firmati come Verified.

I GitHub Agentic Workflows stanno anch’essi su GitHub, ma sono una cosa diversa: file Markdown in .github/workflows/ con un frontmatter YAML che dichiara trigger, permessi e operazioni di scrittura consentite, e un corpo in linguaggio naturale con le istruzioni per l’agente. Si installa l’estensione con gh extension install github/gh-aw e si compila il file con gh aw compile, che genera un workflow di Actions irrigidito con estensione .lock.yml: entrambi i file vanno committati. Le scritture non sono libere, passano solo dai safe-outputs dichiarati, come create-issue, add-comment o create-pull-request.

---
on: weekly on monday
permissions:
  issues: read
network: defaults
tools:
  github:
    toolsets: [issues]
safe-outputs:
  create-issue:
---

La differenza rispetto a un workflow di Actions tradizionale è che le istruzioni non sono regole fisse ma un testo che l’agente interpreta nel contesto: la compilazione serve proprio a mettere confini rigidi attorno a un comportamento flessibile.

Le due superfici che porti tu

La Copilot CLI gira sulla macchina dello sviluppatore, su Linux, macOS e Windows (PowerShell e WSL). Ha una modalità interattiva, una programmatica con -p o --prompt, e una plan mode raggiungibile con Shift+Tab. Le sue leve sono locali: custom agents specializzati, hooks che eseguono comandi shell in punti precisi dell’esecuzione, il local sandboxing con una filesystem policy che decide quali percorsi si possono leggere, scrivere o non toccare affatto (/sandbox policy, /sandbox status, /sandbox config), e i permessi granulari sui tool con --allow-tool, --deny-tool e --allow-all-tools. L’autopilot lascia l’agente procedere senza fermarsi a ogni passo, con --max-autopilot-continues come limite contro i cicli infiniti. Nessuno di questi nomi esiste sulle altre superfici, e la sandbox locale non è un confine assoluto: i tool interni verificano la policy via software e i server MCP remoti restano fuori dal suo raggio.

Il Copilot SDK serve invece a costruire la tua applicazione, in TypeScript, Python, Go, .NET, Java o Rust. Qui il vocabolario è quello di un runtime: l’agent loop in cui ogni iterazione è un turn corrispondente a esattamente una chiamata al modello, delimitata dagli eventi assistant.turn_start e assistant.turn_end, con session.idle come segnale affidabile di fine; la session persistence, dove solo un sessionId scelto da te è ripristinabile con resumeSession(); il fleet mode, in cui un agente padre dispaccia sotto-agenti in parallelo coordinandoli su uno stato condiviso di todo; e l’observability via strumentazione OpenTelemetry.

Identificare i passi e riconoscere gli anti-pattern

Identificare i passi che un agente deve compiere significa due cose insieme: scomporre il lavoro in unità verificabili e assegnare ogni unità alla superficie che può eseguirla. Un passo che deve produrre una pull request appartiene al cloud agent o a un safe-output; un passo che deve interrogare un database locale appartiene alla CLI; un passo che deve girare dentro il tuo prodotto appartiene all’SDK. Un task ideale, secondo la documentazione, descrive con chiarezza il problema, elenca criteri di accettazione completi (per esempio se servono unit test) e indica quali file toccare.

Gli anti-pattern sono l’immagine speculare di quella disciplina. Il primo è il compito vago: requisiti ambigui, obiettivi aperti, lavoro che richiede di attraversare l’incertezza. Il secondo è affidare all’agente ciò che non si dovrebbe: issue critici per la produzione, o lavoro che tocca sicurezza, autenticazione e dati personali. Il terzo, il più insidioso, è credere che i controlli automatici sostituiscano la revisione umana: la code review di Copilot va usata per integrare quella delle persone, non per rimpiazzarla, e la draft pull request del cloud agent resta per costruzione qualcosa che un umano deve leggere e unire. Anche i refactoring ampi che richiedono conoscenza cross-repository o logica di business sostanziale vanno spezzati in task più piccoli e focalizzati.

Su questo punto l’esame gioca sporco in modo prevedibile: le risposte sbagliate sono capacità vere, prese però dalla superficie sbagliata. Se una domanda parla di safe-outputs la scena è quella degli Agentic Workflows; se parla di --deny-tool o di sandbox è la CLI; se parla di turn e di sessioni ripristinabili è l’SDK; se parla di un branch unico e di una draft pull request è il cloud agent. Colloca la scena prima di scegliere.