Going into the event, I was personally most excited about the Copilot CLI. Interestingly, that wasn’t a major focus of the presentations. Instead, the event provided a broad overview of Copilot and the different ways it can be used.
One of the key takeaways from a presentation by Dave Burnison was that Copilot is designed to work across multiple interfaces:
Each of these “form factors” enables a different style of interaction.
From my experience, the CLI is the most powerful for actual development work. It can:
Because it operates within your local environment and permissions, it’s far more flexible and practical for day-to-day engineering work.
VS Code is still very capable, but in my experience it doesn’t go as far in terms of end-to-end problem solving. That said, this may evolve quickly.
The GitHub web interface—where you create issues and assign them to Copilot—is the least exciting to me. It’s useful for code review and issue-driven workflows, but it doesn’t directly execute or validate changes unless you’ve already set up strong automation in your repository.
That approach seems better suited for teams that are heavily issue-driven (e.g., working closely with product managers). If you have robust automated testing, it could be quite powerful. In my current workflow, though, the CLI is clearly the most effective tool.
The second part of the event featured David O’Regan and Klaire, who discussed how they use Copilot in non-development roles.
Their focus was less on writing code and more on: