Reducing bike-shedding using GitHub Copilot

Published on
Reading time
Authors

When I moved my blog from Wordpress to a template based on Next.js, I knew that I'd have to pick up some maintenance tasks that I had previously delegated to the Wordpress platform. One of those tasks was going to be ensuring my codebase was up to date with the latest security patches and updates for Node.js.

Thankfully across the past two years, I haven't had to do much in terms of maintenance, but this past week I received an email from Vercel (the hosting provider for my blog) that my Node.js version was out of date and needed updating before September.

Node.js upgrade notification email from Vercel!

Any time I spent on this task could easily be classified as "bike-shedding" - the act of focusing on trivial issues (updating Node.js version) while neglecting more important ones (pretty much anything other than updating the Node.js version). I wanted to get this task done quickly and efficiently. After doing a bit of research on doing the upgrade I decided to see if GitHub Copilot could help.

Using Copilot to help with the upgrade

First up, I created a new GitHub Issue on the repository for my blog, describing what work was required. You can see that I relatively high level in my ask.

GitHub Issue for Node.js upgrade

Next, I assigned the issue to the Copilot AI assistant, with Copilot starting a new session to help me with the task. The Copilot assistant is the final home of what was originally Copilot Workspace, which I used and reviewed in July 2024 while it was in private preview. It's interesting to see how it has ended up being integrated into the GitHub Issues workflow, which actually feels like a natural fit.

I left the Copilot assistant to work on the task for a few minutes, and continued on with other work I had to do, returning to see the status about 30 minutes later, and find a PR waiting for review.

See the working out

What I particularly like about the Copilot assistant is that it shows you the working out of how it arrived at the solution in the session log. Once Copilot has reviewed the state of the repository, it then builds a plan of action, which it then executes. You can see the plan in the session log, and then the code that it generated to implement the plan.

GitHub Copilot plan of attack

The plan is quite comprehensive and includes items that wouldn't have occurred to me, including updating the devcontainer configuration to use an updated base image that supports Node.js 22. The fact Copilot also tries to find the minimal set of changes required to achieve the goal is a great feature, reducing the amount of churn in the codebase that I'd have to review.

Benefits to new developers

I know there's a lot of buzz in the industry about the impact of AI on new developers (early in career, new to the codebase, new to the problem domain). The thinking seems to go, that because you can now use AI to solve the sort of challenges I have tackled in this post, that we need less new developers who would typically gain experience by doing this sort of work.

I think businesses or teams taking this approach will suffer in the long term. You should see AI as the booster for your entire team.

Traditionally, less experienced developers do this sort of work as a way to build their skills and would rely on more experienced developers to review their work. With AI, you can still have that same process, but AI solutions like Copilot help like this:

  1. Experienced developer: Creates a GitHub Issue to perform some task in the codebase. Assigns to the new developer.
  2. New developer: Uses Copilot to tackle the task, ultimately generating a PR. The PR requires testing and debugging which becomes the actual learning experience. Also, as Copilot shows the working out and can use existing reference code and documentation, the new developer can learn from the plan that Copilot generated. This ends up saving time for the experienced developer without sacrificing the learning experience for the new developer.
  3. Peer review: The experienced developer reviews the PR, and provides feedback to the new developer, providing another learning experience. The new developer gets to see how an experienced developer would approach the problem. The review also becomes less about the basics of writing code, and more about the patterns that could be used.
  4. New developer: Takes the review feedback and applies to the PR (or asks Copilot to help). The PR is then submitted for merging.

Granted, this is different from traditional learning, but it means that less experienced developers can hopefully progress to more complex tasks more quickly, and with the help of AI, they can be more productive. This is a win-win for everyone involved, and it means that the team can focus on more important work rather than getting bogged down in trivial tasks like updating Node.js versions.

Updates are waiting for you on a PR

Once Copilot had completed the task, it added its code to a branch in the repository and created a comprehensive PR with the changes it had made, linking it to the intial Issue and to the session log so I could see all the steps it took along the way.

As Copilot understands the lanuage and framework used in the codebase, it undertook additional steps such as linting, running any tests, and finally making sure that it runs!

GitHub Copilot PR summary

As I am using Vercel to host my blog, I can also see the changes in a preview environment, with Vercel's build engine quickly highlighting an issues.

It's not always perfect first time

If I'm unhappy with the contents of the code change in the PR, I can provide a review comment, and Copilot will continue to work on the task until it is complete. I've used this multi-turn approach a few times, most recently with this PR for adding multi-cluster support to the Draft tool.

Again, this process should not seem unfamiliar, and is yet another learning experience for a new developer - particularly if they are unfamiliar with PR-based workflows.

So, did it work?

I guess that's the big question!

The biggest hint is that you're here reading this post, so yes, it did work! I was able to get the Node.js upgrade done in a fraction of the time it would have taken me to do it myself, and I didn't have to worry about the details of how to do it. Copilot took care of that for me.

I could make this change safely as I knew my release process would ensure that any changes would first go through a staging environment, and I could test the changes before they went live.

Happy Days!

😎