Copilot: dal suggerimento inline all’agente autonomo
GitHub Copilot non è una funzione sola, ma una famiglia di funzionalità. Il livello più semplice sono le code completions: mentre scrivi, Copilot propone la riga o il blocco successivo, che puoi accettare o ignorare. Le next edit suggestions vanno oltre e prevedono dove farai la prossima modifica, non solo che cosa scrivere. Copilot Chat è l’interfaccia conversazionale, disponibile su GitHub.com, negli IDE supportati, su GitHub Mobile e da riga di comando con Copilot CLI.
Il salto delle versioni recenti è l’agentività, ed è qui che l’esame si concentra. In agent mode Copilot non si limita a rispondere: lavora in autonomia dentro il tuo ambiente di sviluppo, apre e modifica più file, esegue comandi e itera sull’esito. Il Copilot cloud agent (l’agente che gira su GitHub, non sulla tua macchina) fa un passo ulteriore: gli assegni un compito da un issue, dal pannello agents o citandolo in un commento di pull request, e lui esplora il repository, prepara un piano e produce modifiche su un branch dedicato, che rivedi prima di aprire la pull request. Gira in un ambiente effimero alimentato da GitHub Actions, quindi può anche eseguire test e linter. Completano il quadro Copilot code review, che commenta le modifiche proposte, le custom instructions e gli MCP servers, con cui l’agente raggiunge strumenti e dati esterni.
Ultimo elemento: il multi-model support. Copilot non è legato a un unico modello. Nel selettore di Chat, della CLI e dell’agente trovi modelli di fornitori diversi, oltre a un’opzione di selezione automatica; quali modelli vedi dipende dal piano.
Che cosa verifica l’esame: la capacità di distinguere il suggerimento passivo dall’azione autonoma. La confusione tipica è fra agent mode (autonomo, ma dentro il tuo editor) e cloud agent (autonomo, ma sull’infrastruttura GitHub, con branch e pull request come risultato).
Individuals, Business ed Enterprise: che cosa cambia davvero
Sul lato individuale la scala parte da Copilot Free, prosegue con Copilot Student per gli studenti verificati e sale con Copilot Pro, Copilot Pro+ e Copilot Max: cambiano il volume di utilizzo incluso e l’ampiezza del catalogo modelli, dato che i piani gratuiti restano sulla selezione automatica. Sono sottoscrizioni personali, legate al tuo account.
Il confine che conta non è fra Pro e Pro+, ma fra il mondo individuale e i piani per le organizzazioni. Copilot Business e Copilot Enterprise si assegnano per posto (seat): paga l’organization o l’enterprise, un amministratore decide chi riceve il posto e applica le policies centralizzate, cioè quali funzionalità abilitare, il content exclusion per tenere certi file fuori dal contesto e i log di audit. Enterprise, disponibile su GitHub Enterprise Cloud, aggiunge un’allocazione di utilizzo più ampia e accesso prioritario a modelli e funzionalità nuove.
Confusione tipica da evitare: credere che un piano individuale offra il controllo delle policy. Non lo offre. La governance centralizzata arriva solo con Business ed Enterprise.
Codespaces: un ambiente completo, definito nel repository
Un codespace è un ambiente di sviluppo ospitato nel cloud: un container Docker su una macchina virtuale Linux gestita da GitHub. Ha CPU, memoria, disco e un terminal vero, quindi puoi compilare, eseguire i test, avviare un server e raggiungerlo con il port forwarding. Ci si collega dal browser, da Visual Studio Code sul desktop oppure via GitHub CLI.
La personalizzazione ha tre livelli, e la distinzione è materia d’esame. Il dev container è il file devcontainer.json, collocato in .devcontainer/ oppure come .devcontainer.json nella radice: versionato nel repository, definisce immagine, features (unità riutilizzabili che installano tool e runtime), estensioni e comandi di setup, e vale per chiunque apra il progetto. Senza quel file GitHub usa un’immagine predefinita con i runtime più diffusi. I dotfiles sono invece personali, per alias e preferenze di shell, e Settings Sync riporta impostazioni ed estensioni del tuo VS Code.
Se modifichi devcontainer.json serve un rebuild del container. Un codespace si può fermare con stop e riprendere; dopo un periodo di inattività si ferma da solo; se lo elimini con delete, il lavoro non committato sparisce. Le prebuilds preparano il container in anticipo per accorciare l’avvio.
github.dev: l’editor che non esegue codice
Da un repository premi il tasto punto, oppure il tasto maggiore per aprirlo in una nuova scheda, oppure sostituisci github.com con github.dev nell’URL: compare un editor in stile VS Code dentro il browser, gratuito per tutti gli account. Serve a modificare file, navigare il codice e fare commit e push senza clonare nulla in locale.
Il punto da memorizzare è uno: github.dev non ha compute associato. Niente terminale integrato, niente build, niente esecuzione, niente debug, e solo le estensioni web funzionano. Codespaces esegue il codice, github.dev lo modifica e basta. Se lo scenario richiede di lanciare i test o avviare l’applicazione, la risposta è Codespaces; se chiede la via più rapida per correggere un refuso in un README, è github.dev.