Exploring GitHub Copilot Workspace: Early Insights into a Development Game-Changer

(Disclaimer: This article was written before GitHub Copilot Workspace became mainstream. As of the time of publishing, Copilot Workspace is in technical preview and has been available for around three weeks.)

When GitHub announced “GitHub Copilot Workspace” during the GitHub Universe event in October 2024, I could not help but see it as the next step in improving the developer experience within IDE’s. As a regular IntelliJ user, I appreciate JetBrains, the company behind IntelliJ, working hard on adding AI-powered features to IntelliJ. Yet, Copilot Workspace promises to revolutionize the way we develop code, so I really wanted to try it.

After the announcement of the technical preview’s availability, I logged into my GitHub account, joined the waiting list, and call it a day. To my surprise, the very next morning, I received an email granting me access to the preview.

What is Copilot Workspace?

In case you have not heard, Copilot Workspace is an AI-native development environment from GitHub, be aware it is not the regular Copilot. It allows you to generate code by writing your requests in natural language, you call it, English, Spanish, German, or any other language you are fluent in. As a full development environment, it includes additional code-related capabilities.

After gaining access, I decided to test it using a repository I maintain for teaching Camunda 8. Once you have started a session, you work with Copilot Worskpace in an iterative manner, the main 3 steps of one iteration are:

• Brainstorming
• Plan
• Implement

Brainstorming: Your Thought Partner

I used Copilot Workspace in my browser, so all the screenshots you see were taken from the online session. There is also a plugin for Visual Studio, but I did not use it in this article.

The documentation says you can use Copilot Workspace as your thought partner, this works on different levels, you could have already an idea or you ask Copilot Workspace to start with the brainstorming, which was my case.

Being new to the tool I had no pre-made ideas, I wanted to explore and see, I started by asking in plain-language the following question: Can you provide an overview of this repository?, just like that, without any other details or context. Copilot Workspace analyzed the repository and it gave me an impressive answer.

The exciting part was the level of detail it offered: clear, concrete, and precise explanations. Curious about its flexibility, I wanted to see if I could ask for explanations for specific modules and how it would present them to me. My project consist of two modules:

• A fully functional module with mainly Spring starters
• A “raw” Java module, with several todos and points to improve

Both modules essentially consist of workers for Camunda. When I asked about the difference between the two modules, it summarized major changes and the actual points where the modules differ.

I really liked the way the information was presented, using easy to understand sentences. The flow also felt the right one as it could explain something quite elaborate in an understandable manner.

One standout feature I noticed was the “View References” link, where I checked the files used by Copilot Workspace in its analysis. Comparing this files with my detailed knowledge of the repository I was delighted to see that it listed many of the important files.

I decided it was enough of getting familiar with brainstorming, I wanted to see how it performs with tasks, such as refactoring or adding comments. To be frank the normal Copilot already performs those two at a very good level. The point with Workspace is to see how easy it takes me from idea to implementation, and the flow of it using just plain English. So I asked what could be improved.

Plan: From Idea to Strategy

I picked one idea from the brainstorming: refactor a class. I copied the idea into the chat and hit the “Plan” button. Workspace analyzed the request, performed some changes, and offered a summary of them. The changes were “stacked”, they were not yet implemented. This provides time to review and decide how to proceed, in other words, a thoughtful approach that puts the developer in control.

Implementation: From Plan to Code

Before hitting “Implement selected files”, I noticed the button “Brainstorming” was still active. Curious, I clicked again to see what would happen. To my surprise, Copilot Workspace presented a comparison between the current situation and proposed solution. This provides valuable insights into the potential impact of the changes.

Without any other deviation I clicked on “Implement”. The changes were performed and the code was ready for review. Copilot Workspace offers a live editor for further tweaks, but I limited my role to just observe the generated code and approve it.

Once approved, Copilot Workspace created a pull request (or merge request, my preferred term). I had to go to the regular “pull requests” tab of the repository, and follow the normal procedure of any pull request.

The Big Picture: Reading between the lines

I did not write a single line of code, and I did not do anything else than just typing my ideas as If I were taking notes, and I can say GitHub Copilot Workspace works entirely with plain text, keeping the the opportunity to edit code in the live editor. The developer is in control of the workflow and steps involved. Being just a preview it is already very powerful and has already advanced features and capabilities.

Did I like it ? Yes, I did, but I have some reservations. In this article, I showcase my very first session with it, which went well. Since then, I have made few more changes using Copilot Workspace and noticed that, in my case, it struggled with libraries, however it excelled in structures. In one session, the time I spent with it was longer than if I had coded the change myself. However, I could also argue this was due to my prompting and the fact the product is still in preview.

If we think of Copilot Workspace in terms of an AI Native Development Environment for Professional Coders, these are my early conclusions:

• Developers act as Requirement Engineers. Domain knowledge is still required to provide the proper input.
• Developers act as validators, tools like this, ensure a Human is always in the loop, making sure the IDE is doing what we intend to do.
• AI-powered tools like this often require specialized knowledge to operate effectively. The trend here is that, when a tool is AI-driven and intended for a highly skilled audience, the tool tends to be more specialized in its functionality and design.

With its release one can say, the AI landscape is maturing beyond foundational models. Companies are now leveraging these models to create unique, user-centric applications with agents.

GitHub is increasingly becoming the place to go for the AI development community, other products might not be in the future as good as we know them, because they have the risk of staying behind. The main reasons is, GitHub is integrating efforts from various major players to include access to AI tools and drive the next phase of innovation in development.

If you want to try it out yourself, you can join the waitlist here.