Development reinvented: System Thinking with Copilot Workspace

Published 8/3/2024 8:17:30 AM
Filed under Machine Learning

Last week, I got to try Copilot Workspace for the first time with Joop Snijder. We had a great time trying out this new AI tool that will take developer productivity to the next level. We were so happy; we tried a bunch of different things and were unable to keep quiet about this new feature.

It's time to dive into the details of why I think this feature is going the way we work as developers.

What is Copilot Workspace?

Copilot Workspace is a research experiment on GitHub that uses AI to generate code changes based on an issue description. It can handle complex changes across multiple files in your codebase. It's a step up from the regular Copilot that's often used as a charged-up intelligence in VS Code and other popular editors.

Starting a new session

To use Copilot Workspace, you start with an issue on GitHub. On the issue page, there's a button on the right side of the screen with the name "Open in Workspace". Click the button, and you're taken to the Copilot workspace environment.

The details of an issue you're about to edit in Copilot Workspace.
The details of an issue you're about to edit in Copilot Workspace.

In the copilot workspace, your issue description is converted into a Specification. This is a refinement of the issue into a more detailed plan used to determine what needs to be changed in the code.

Generating and editing specifications.
Generating and editing specifications.

You can change the description of the plan, regenerate it or ask Copilot to revise it using the Revision button that's at the top of the page. Once you're happy with the specification, you can ask Copilot to generate a plan for you.

Generating and revising the implementation plan
Generating and revising the implementation plan

In the plan, Copilot will show you what changes it is about to make to your codebase. The plan lists all the files that copilot creates, modifies or removes. For each file, Copilot lists what changes it will make.

At this stage, you can tweak the plan by adding details to the files. You can also make generic remarks about the changes. When you're happy with the results, it's time to get generating.

Reviewing and revising generated code
Reviewing and revising generated code

Once you have the code files, it's your job to review, revise or edit the code yourself. You can do this in the main copilot screen, or you can open up a code spaces environment to test and edit the code there.

Using Copilot Workspace effectively

Using Copilot Workspace is an entirely different experience from editing regular code. I'm quite used to using GitHub Copilot, and it helps a great deal getting things done. But Copilot Workspace is in a different realm.

Writing features with Copilot Workspace feels a lot faster because I'm not writing code by hand. Instead, I am shifting my attention to designing the system. And that's precisely what makes Copilot Workspace so much different from regular coding.

I've found that it helps a great deal if you embrace system thinking and spend more time creating a high-quality issue.

Write a good quality issue

Since Copilot Workspace starts off with an issue, it's important to have a good-quality description of what you want. Vague requirements lead to vague specifications in the workspace. And that's annoying.

But let me be honest: low-quality specifications were already annoying in a project without AI. When you get a vague set of requirements from your client or product owner, you have to go back and fix them. Or, what happens a lot too? You start building something that isn't quite right.

A good quality issue lists 5 things:

  • It describes one or more functional scenarios that you want the software to support.
  • It describes the user interface (if any) that's to be used to run the scenario.
  • It lists architectural requirements that the implementation must follow.
  • It describes quality aspects, such as what should be tested in the scenario.
  • Finally, it lists security considerations.

I noticed during testing that if I followed this structure, Copilot Workspace was much better at producing a good quality specification and plan. However, I still had to step in from time to time to tweak things.

Revise and regenerate often

Copilot workspace is based on AI, and that's important to keep in mind. It will generate strange content. But that's why You first get a specification, and then a plan. You can revise both by commenting on Copilot Workspace.

Revising code with a comment
Revising code with a comment

I recommend you use the regenerate button and revision buttons liberally to work towards a good specification and plan. And if things go completely bad, you can always use the undo button!

Going back a step with the undo button
Going back a step with the undo button

It may sound like you're going to spend quite a bit of time revising the specs and fighting the AI. But it didn't feel that way to me. It felt like having a constructive discussion with a fellow developer about what needed to be done. In the end, I found that if I spend enough time in this phase, the coding phase is much smoother and I can deploy much quicker.

It only takes you part of the way

For me, Copilot Workspace provides an unexpected amount of leverage over my codebase. It's like pressing two keys on my keyboard to get a complete code file. It's still an 80/20 scenario, but slightly different. Let me explain.

After spending time writing out the perfect plan, I thought I had what I needed, so I created a pull request. When I ran the code locally, I noticed that the user interface wasn't exactly how I imagined it. So I had to edit that on my computer.

Does this final edit step make Copilot Workspace worthless to me? Nope, it makes perfect sense. You can't expect a perfect user interface from a developer or an AI developer. You need to see it before it makes sense.

What's important here is that Copilot Workspace completes 80–90% of the work. You need to review the code and validate it. After Copilot Workspace is done you can touch up any flaws on your own. I know that some developers say: "The last 20% takes 80% of the time", but that's not the case here. I spent 40 minutes designing my feature and generating it with AI; after that, I spent 10 minutes validating the feature on my machine and fixing up the last few problems in the code.

Good craftsmanship will get you more

It may sound like you don't need a lot of knowledge about coding to use Copilot Workspace, but that's misleading. Since you need to review the changes made, you will need to know how the frameworks used work and how to design good software.

Use build automation wherever you can

Validating a code change by hand can be quite tedious. An automated build workflow will make that work a lot easier. I recommend setting up at least a basic build workflow in GitHub actions if you're going to use Copilot Workspace.

When you're done editing in Copilot Workspace, you can create a Pull Request, which is then validated with your workflow saving you time validating that the code compiles and the tests succeed. It makes the coding workflow in the Copilot Workspace a lot more seamless.

Use automated tests

Another great way to increase the power of Copilot Workspace is to include automated tests in your code base and run them as part of your build workflow. You can ask Copilot Workspace to generate unit-tests as part of the plan, so it's easier to get tests for your code.

Know your frameworks and start thinking in systems

You will be writing a lot less code. Instead, you will spend a lot more time writing specs and designing systems instead. This means you need to know your stuff at a higher abstraction level.

I recommend brushing up on your system-thinking skills. System thinking is a skill where you learn to break down a challenge, change or problem into systems that are involved. It helps you break up bigger problems into smaller ones that are more easily fixed. It helps with Copilot Workspace because AI is more capable when it is used on smaller problems.

There's a great book about systems thinking by O'Reilly if you would like to learn more.

Use smaller issues

It's tempting to try Copilot Workspace on a huge issue with many changes. I tried it, and it didn't work. That's not a failure on Copilot's part. There's another problem at hand.

When you give someone on your team a huge issue to solve that's made up of multiple changes, the results will be bad, too. If you're lucky, they will still produce a good result, but with a lot of effort. If you're unlucky, you will get something that's half-assed.

I recommend spending more time managing your backlog. Split large issues into the smallest deployable chunks possible. It will lower the risk of breaking stuff in production. It will make you feel more empowered because you're moving through issues faster. And now you will have a much better time working with Copilot Workspace.

Here's your chance: sign up!

I am convinced that AI has a growing impact on our work as developers. It's time to test tools like Copilot Workspace and make sure we understand the impact these tools will have. This is your chance to shape what your future work looks like! Sign up for the preview and let me know what you think in the comments!