Is GitHub Copilot Pair Programming?
Written on September 11th, 2021 by Naser
I can’t hide that I am impressed by GitHub Copilot, and I encourage you to see it for yourself if you haven’t already. Basically, it is an AI tool that automatically writes code snippets (or entire programs) from comments and existing code context. It is built on top of the fascinating language modeling AI GPT-3. I remember showing my CS1 students a well-made video by 2 Minutes Papers on GPT-3 using natural language and how amazed we all were by this new technology. I will leave a link for the video here, also I recommend subscribing to the 2 Minutes Papers channel if you like to get a 2-minute review of some interesting AI-related research.
GitHub Copilot claims to be an automated pair-programming tool, but I am a little skeptical despite being impressed and thinking that Copilot has merit beyond being a cool party piece. Pair-programming is a software development methodology where two programmers write code together and alternate roles as “driver” and “navigator.” The adoption of pair-programming in the industry is patchy at best, and in academia I hold the opinion that it is overhyped a bit. Many of the empirical research done to illustrate the value of pair-programming comes from experiments done in academic settings, and the results tend to show that programmers enjoy this technique for its social aspects. I believe that pair-programming is great for knowledge sharing in an organization, as it results in having two programmers who are familiar with any piece of code. Also, undeniably the code quality will be higher if two people work on it. Some of the disadvantages include being difficult to adopt (sometimes) and resulting in longer development time. In fact, research shows that pair-programming is faster than a single programmer, but slower than two.
Going back to assessing GitHub Copilot as a pair-programming alternative, we can clearly see that it is missing the social aspect which gives pair-programming its likability. In addition, with Copilot we don’t get the benefit of having at least two people in the organization who are familiar with the codebase. Moreover, I have doubts about the cohesion of the generated code with the existing one, which might result in “Frankenstein” codebase, which cannot be associated with quality code. For these reasons, I don’t think GitHub is a pair-programming alternative.
Before I end this post, I must share why I think Copilot has merit as a supportive software development tool. I believe that autocomplete tools such as Copilot can make programming faster, and it has the potential to reduce bugs in code. Advertising Copilot as a pair-programming alternative is a mistake in my opinion for the reasons I listed above. Presenting Copilot as an assistive software development tool might be more suitable. Under the assistive tool designation, I think Copilot could exceed the success of pair-programming today. Just like autopilots in aviation which were introduced more than 60 years ago, they didn’t replace pilots, but they made flying safer and reduced pilot workload. We still have planes that require two pilots today, and I don’t think programing as a profession is threatened at all by GitHub copilot. You still need programmers to operate GitHub Copilot and review the generated code, and in many cases, work is needed to make the generated code fit the codebase. Therefore, I think Copilot might be helpful for many existing organizations, especially ones with an approaching deadline and a programmer shortage. Finally, I look forward to seeing the future of assistive software development technology, and I hope to see tools that address the issues of mental-health and equality in the tech industry.
