Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
GitHub Next launched the technical preview for GitHub Copilot Workspace in April 2024. Since then, we’ve been listening to the community, learning, and have some tips to share on how to get the most out of it!
Can you believe it has already been five months since we announced the technical preview of GitHub Copilot Workspace? Throughout that time, the GitHub Next team has been listening and learning from the community and steadily iterating on it.
For those joining us at GitHub Universe, we will be talking about GitHub Next’s journey to create Copilot Workspace, along with some valuable concepts and learnings gleaned along the way. But while we put the finishing touches on our talk, we wanted to share a few tips and tricks that we have picked up, both from ourselves and from the amazing community of developers using Copilot Workspace every day.
Before we get started, let’s briefly recap Copilot Workspace and how it works.
Copilot Workspace is a Copilot-native dev environment designed to help you complete everyday coding tasks. From GitHub, you can open a GitHub issue, pull request, template repository, or an ad-hoc task in Copilot Workspace and start working on the problem.
Did you know?
You can start a Copilot Workspace session outside of the above routes. Copilot Workspace sessions take a handful of query parameters, including the task and repository. So, you could build your own entry point. For example, the GitHub Next team built an extension for Raycast!
Once you’ve started a session, you work with Copilot Workspace to iterate through a set of stages to solve your problem. These include:
You can keep iterating and bouncing between the stages as you need, re-prompting Copilot Workspace or regenerating suggestions. Once you have landed on an idea, you can raise a pull request, create a new branch, or in some cases, create a new repository.
Did you know?
There is a Copilot Workspace user manual repository that contains additional tips, a log of recent changes, and more!
Now that we’ve learned the foundations, what tips have we gathered from the team and the community on how to get the most out of Copilot Workspace?
A crisply defined goal is important whether you’re working with a colleague or with GitHub Copilot. The more clearly you can articulate what “done” looks like for a task, the more likely you are to get a result that meets those conditions. AI is better at handling natural language than any other software in history, but ambiguity is still the number one path to poor results.
Working with AI can sometimes feel like a slot machine—it’s not always clear how to coax reliably good results from the tools. Supplying clear goals and context not only improves the quality of results, it also makes those positive results happen consistently. In fact, this is a similar tip that we’ve published before when working with GitHub Copilot in general!
So, what does that mean in practice for Copilot Workspace? When you’re writing your task (such as a GitHub Issue), write some bullet points that capture your criteria for success. It doesn’t need to be fancy or long! Here’s an example of an issue that gives Copilot Workspace clear context and goals.
If you know specific files, classes, components, or directories that need to be changed, include them in your task description. That kind of detail is fantastic context for guiding Copilot Workspace towards a solution. But you’re not just limited to specifying filenames or classes. Copilot Workspace was recently updated with the ability to pull information when you reference URLs such as issues, pull requests, and repository files. It can even take context from public URLs (such as docs) that might provide additional instructions to help with what you’re trying to accomplish.
Overall, the more context you can provide to Copilot Workspace, the more likely you will get a result closer to your expectations. So, if you have information about style guides, coding guidelines for unit tests, or any other relevant documentation, try linking to that in your task!
Kudos to Willem from our Discord community who wrote a post which included this one. It’s also similar to another tip that we’ve published before when working with GitHub Copilot.
When you have a larger task, the desired state may not be easy to articulate. Consider breaking the task down into smaller parts so it’s easier to define success for the task. This also aligns with practices we’re used to as developers, such as one commit for one change.
Copilot Workspace has been designed with a number of principles in mind (If you want to learn about those, then you should check out our talk at GitHub Universe!). One of those principles is allowing users to steer Copilot Workspace, so that you can iterate over ideas and edit the returned suggestions.
Therefore, it’s important to consider Copilot Workspace’s suggestions as a first attempt or a first draft. Revisions are a core part of making that interaction succeed. With that mental model, you begin using Copilot Workspace as a tool to iterate on ideas and potential solutions, helping to bootstrap a first attempt at a solution.
What does this mean in practice? When you launch a Copilot Workspace session, review the topic and make sure that Copilot Workspace is focused on solving the right problem. If not, then edit it!
Copilot Workspace is designed to be steered at every step. Each stage is deliberately editable so that you can adjust course as needed. If the spec or plan doesn’t look quite right, then edit them, or regenerate them by editing an earlier step. Iterate until you have something closer to your expectations. And remember, you can undo those suggestions and return to a previous state if needed.
If you ask another developer for a solution, you probably wouldn’t expect a perfect answer on their first attempt. It might take a bit of time, iteration, and rephrasing of questions to get what you need, whether you’re working with a colleague or working with Copilot!
Once you’ve been through the iteration process with Copilot Workspace, you may have some code that looks good but needs some minor tweaks.
Remember that you can edit the code directly in the Copilot Workspace editor (or even in a codespace). At some point, it might make more sense to make those changes directly rather than asking Copilot Workspace by revising the task, spec, or plan.
Additionally, you can use Copilot’s ghost text capabilities within the environment, as well as other language services, to help you make those changes!
And finally, many of us are used to the inner loop of development. This is the idea that when we write code, we check that it still passes any builds and tests locally before we raise a pull request to run it through a more rigorous set of checks in our continuous integration (CI) process and have it peer reviewed.
You can (and should) run builds and tests within Copilot Workspace as well! You can use the built-in terminal, and terminal assist capabilities to help you fix any errors or issues. That way, you can validate your changes within Copilot Workspaces and keep iterating until you meet a certain level of quality before proceeding through your full CI process.
We’ve learned a lot from our community throughout the Copilot Workspace technical preview, and we hope that these tips help as you continue to explore and experiment!
If you want to learn more about GitHub Copilot Workspace, be sure to check out our session at GitHub Universe, join GitHub Next’s Discord Community and of course, sign up to the waitlist for the preview!
