Il Copilot coding agent e i Copilot Spaces rappresentano l’evoluzione di GitHub Copilot da assistente in-editor a collaboratore asincrono capace di lavorare su task interi e di condividere contesto strutturato. Per l’esame GH-300 è cruciale distinguere cosa l’agent fa in autonomia e, soprattutto, dove finisce la sua autonomia: ogni output passa dal processo di review.

Copilot coding agent: dal task alla pull request

Il coding agent è pensato per delegare unità di lavoro complete. Il flusso tipico parte da un’issue che viene assegnata a Copilot (oppure da una richiesta in Copilot Chat con #-reference al task). Da quel momento l’agent lavora in modo asincrono in un ambiente isolato ed effimero, alimentato da GitHub Actions, dove clona il repository, installa le dipendenze, esplora il codebase, applica modifiche ed esegue test e linter.

Il punto architetturale chiave è il confine: l’agent non fa commit diretti sul branch protetto e non esegue merge. Il suo deliverable è una draft pull request su un branch dedicato. Man mano che procede, aggiorna la PR e documenta il ragionamento in un log di sessione, così il revisore umano può ricostruire cosa è stato fatto e perché.

Perché un ambiente isolato

L’isolamento serve a tre scopi che l’esame ama testare:

  • Sicurezza: l’agent opera con permessi limitati e non tocca l’ambiente di produzione né i segreti non autorizzati.
  • Governance: il codice generato attraversa gli stessi controlli del codice umano — branch protection rules, required reviewers, status check e CODEOWNERS.
  • Tracciabilità: ogni cambiamento è materializzato come commit su una PR, quindi versionato e reversibile.

Casi d’uso realistici in cui indirizzare l’agent: correzione di bug ben definiti, aumento della copertura di test, aggiornamento di dipendenze, refactoring circoscritti, miglioramenti di documentazione. È meno adatto a task ampi, ambigui o architetturalmente aperti, dove il valore di un umano nel definire i requisiti resta alto.

Copilot Spaces: contesto condiviso e riusabile

Un Copilot Space è un contenitore di contesto curato che tu prepari una volta e riutilizzi in molte conversazioni. Al suo interno raccogli:

  • File e repository di riferimento (codice, snippet, esempi canonici),
  • istruzioni e linee guida (convenzioni di stile, standard architetturali, policy interne),
  • conoscenza aggiuntiva come documentazione, transcript o note tecniche.

Quando poni una domanda dentro uno Space, Copilot fonda le risposte su quel materiale, riducendo allucinazioni e allineandosi alle regole del tuo team. Il vantaggio rispetto al contesto implicito dell’editor è la condivisibilità: uno Space può essere organizzativo, così che più persone (e l’agent) ragionino sullo stesso “modello mentale” del progetto. Gli Space sono ottimi per onboarding, per rispondere a domande ricorrenti su un sistema, o per fornire all’agent istruzioni di progetto coerenti.

Come si integrano

Il contesto di uno Space aiuta a produrre risultati più aderenti agli standard, ma non modifica il modello di controllo: anche partendo da uno Space ben fornito, quando l’agent genera codice il risultato resta una PR soggetta a review. Lo Space migliora la qualità dell’input; non elimina il gate umano sull’output.

Il confine invalicabile: tutto passa dalla review

Il principio da fissare per l’esame è che Copilot, in modalità agent, è un contributore, non un maintainer. Produce proposte; l’accettazione resta umana e governata dalle policy del repository. Questo abilita adozione sicura in contesti enterprise, perché il codice AI-generato non scavalca mai i controlli esistenti.

Trappole tipiche d’esame

  • Scenario: “Assegno un’issue al coding agent — mergia da solo la fix quando i test passano?” → No. L’agent apre una PR in review; il merge richiede approvazione umana e rispetto di branch protection.
  • Scenario: “Voglio dare a Copilot codice, istruzioni e documenti come contesto stabile e condiviso col team.” → Copilot Space, non un semplice prompt in chat.
  • Scenario: “L’agent lavora direttamente sul mio branch main locale?” → No. Opera in un ambiente isolato/effimero su GitHub Actions e produce commit su un branch dedicato.
  • Scenario: “Uno Space ben configurato permette all’agent di bypassare i required reviewer?” → No. Il contesto migliora la qualità, ma il gate di review e le policy restano invariati.
  • Scenario: “Task ampio e ambiguo da affidare all’agent?” → Preferire task ben definiti e circoscritti (bug fix, test, refactor mirati); l’ambiguità resta compito dell’umano.