Copilot — The “Third Wheel” in Paired Programming?

Common within the Extreme Programming faction of the Agile Methodology, the concept of Paired Programming exists whereby two developers work at a single workstation, linking two monitors, keyboards, and mice. There exists two roles within a Paired Programming pair:

· The Driver — whom takes control of the keyboard and actively writes the code within the IDE, and

· The Navigator — whom diligently observes the code being written and constantly scanning for improvements and syntactical errors and collaborates on code strategy

Often, paired programming can be linked to the concept of “coding out load” whereby each of the two developers maintain a stream of consciousness type of dialog, constantly communicating thoughts and bouncing ideas off of one another. Programmers are encouraged to switch between Driver and Navigator frequently, often around 30 minutes, to encourage focus, skill development, and collaboration skills. Additionally, when combined with Test Driven Development (“TDD”) its common to have one entity write the unit test that fails and the other to write the code that allows the unit test to pass.

While many employers are skeptical of its benefits, claiming a significant decrease in productivity and efficiency, making claims such as “why are two developers working on a single machine? Isn’t that halving my productivity and wasting resources?” From personal experience (more on my experience in a moment), this level of skepticism is extremely high in large enterprises and for any institution learning about extreme programming.

In reality (and contra to belief), however, the true benefit of paired programming includes:

· Higher innovation in code — when two developers collaborate while writing code, new ideas — from novel development patterns to strategies on achieving the task at hand — are generated as perspectives and expertise are combined compared to a single mindset.

· Higher Efficiency — two programmers constantly reviewing code, alongside code linting capabilities and pipeline scanning, can reduce the amount of syntactical errors and bugs introduced into the code

· Higher knowledge transfer — two programmers, with a stream of consciousness mentality, can transfer knowledge among developers, to augment coding skills and/or drastically increase the rate of learning of a novice programmer when paired with an expert

· Higher Developer Satisfaction — developers, on average, are happier and more satisfied with their job compared to solo developers, as studies have show

· Higher productivity — developers maintain context, whilst switching between projects and/or require attending meetings and stepping away from their machines and allows a higher probability of knowledge about particular projects being retained within an organization should attrition occur

I’ve personally experienced Paired Programming, and pairing in general, during my tenue at TribalScale, a Canadian-based startup focusing heavily on transforming the way code is delivered to market. Tribalscale focused heavily on three pillars:

· Enterprise Transformation — Product Managers and Engineers embedded themselves within Enterprise Product teams, pairing with respective counterparts, to enact knowledge transfer via pairing. Product Managers, for example, paired on writing user stories, managing a backlog, conducting agile ceremonies, and communicating to executive stakeholders, while engineering pairs focused on the aforementioned tasks earlier in this piece. Enterprise organizations, thereafter, were transformed inside-out, by sharing the benefits of Extreme Programming and propagating the cultural change organization-wide to lead to higher productivity, code quality, innovation, and efficiency.

· Professional Services — TribalScale, capitalizing on Extreme Programming and the internal culture thereof, works with client customers on a Professional Services-like engagement to build digital products for Production.

· Venture — TribalScale worked closely with new start-ups via making capital investments, coworking spaces, and TribalScale labor to accelerate the start-up and decrease time-to-market with higher quality code

As an aside, during my tenure at TribalScale, I truly learned the essence of being a Product Manager and associate the learning of best practices within my line of practice from the teachings of this organization. #Kudos Tribalscale!

So why introduce the title as “The Third Wheel in Programming?” and why include the preamble about Paired Programming?

In recent announcements, Microsoft unveiled GitHub co-pilot, a GPT-powered Artificial Intelligent assistant aimed at reducing boilerplate code written by developers. GitHub Co-pilot was trained on a Codex — a corpus of code scraped from the internet in open source repositories such as those found on GitHub. While using probability and statistics via the Codex model, GitHub CoPilot is able to suggest code to a developer in the form of autocomplete to facilitate the acceleration of programming.

Simply put, developers write comments within an IDE connected to CoPilot, start to write a function or line of code, and CoPilot generates remaining code thereafter as indicated through the comment prompt. Examples are illustrated on the CoPilot webpage.

The impetus behind this piece came from marketing tagline: “Your AI pair programmer.” My aim hereafter is to: (1) De-bunk any claims that working with CoPilot is Paired Programming and (2) Introduce a framework for incorporating CoPilot into Paired Programming.

CoPilot is NOT Paired Programming

As previously mentioned, Paired Programming consists of two individuals or entities, the Driver and the Navigator. The roles are obvious (in a sense) between a developer and CoPilot — the former is the driver and the latter is the navigator. The large difference, however, is:

· The developer can only communicate via commented prompts to the CoPilot, therefore, a lack of “programming out loud” exists and innovation is unable to occur

· Switching roles only occurs when the developer is reviewing the generated code from CoPilot and refactoring the code to work within the context of the code being written

· CoPilot only generates code based on the corpus of knowledge retained in the Codex, not generate innovative or novel code that solves the problem in a unique way, rather, expedites the creation of boilerplate code.

· CoPilot can only enable knowledge transfer of syntax within a programming language and introduce new functions or packages that could aid a developer, not maintain context about a project. However, CoPilot can aid in the generation of files (manifests and other supplementary documents typically containing a few lines of code for integration purposes or requirements of a library).

A Framework for Tri-Programming: A Driver, Navigator, and CoPilot

Before moving to the second point, its worth delving into the FAQ section of the CoPilot page and gleaning insights from the answer responses:

Can GitHub Copilot introduce insecure code in its suggestions?

Public code may contain insecure coding patterns, bugs, or references to outdated APIs or idioms. When GitHub Copilot synthesizes code suggestions based on this data, it can also synthesize code that contains these undesirable patterns. This is something we care a lot about at GitHub, and in recent years we’ve provided tools such as GitHub Actions, Dependabot, and CodeQL to open source projects to help improve code quality. Of course, you should always use GitHub Copilot together with good testing and code review practices and security tools, as well as your own judgment

The role of a navigator still remains — should the driver invoke CoPilot into the IDE when writing code, the navigator should be scanning the generated code for security vulnerabilities, code smells, and adherence to the coding pattern implemented by the pair including syntactical style, nomenclature, etc.

Does GitHub Copilot write perfect code?

In a recent evaluation, we found that users accepted on average 26% of all completions shown by GitHub Copilot. We also found that on average more than 27% of developers’ code files were generated by GitHub Copilot, and in certain languages like Python that goes up to 40%. However, GitHub Copilot does not write perfect code. It is designed to generate the best code possible given the context it has access to, but it doesn’t test the code it suggests so the code may not always work, or even make sense. GitHub Copilot can only hold a very limited context, so it may not make use of helpful functions defined elsewhere in your project or even in the same file. And it may suggest old or deprecated uses of libraries and languages. When converting comments written in non-English to code, there may be performance disparities when compared to English. For suggested code, certain languages like Python, JavaScript, TypeScript, and Go might perform better compared to other programming languages.

Like any other code, code suggested by GitHub Copilot should be carefully tested, reviewed, and vetted. As the developer, you are always in charge.

The above text suggests that generated code, while increases productivity, is not 100% accepted, which makes sense given the training data and contextual relevant within the body of the program, including user defined functions, etc.

How will advanced code generation tools like GitHub Copilot affect developer jobs?

Bringing in more intelligent systems has the potential to bring enormous change to the developer experience. We do not expect GitHub Copilot to replace developers. Rather, we expect GitHub Copilot to partner with developers, augment their capabilities, and enable them to be more productive, reduce manual tasks, and help them focus on interesting work. We also believe that GitHub Copilot has the potential to lower barriers to entry, enabling more people to explore software development, and join the next generation of developers. We are working to test these hypotheses with both internal and external research.

So what does the tri-programming paradigm look like? Examples include:

· The Driver, in a Test Driven Development paradigm, could generate a unit test using CoPilot prompts and writes the code to pass the then-current failing unit test OR inverse the pattern (contra to TDD) and have CoPilot generate a unit test based on the functionality written in code

· The Navigator still collaborates with the Driver with a stream of consciousness mindset, prompting the Driver to utilize co-pilot where applicable as well as asking inductive questions against the code generated such as “why was the code generated in this way?” or “Could the prompt written within the comments be worded differently to effect the outcome?”

· The Driver, could explain to the Navigator a summary of the code generated by CoPilot to facilitate learning, taking the physical writing of boilerplate code responsibility off of the Driver and opening up room for additional teaching. This may also include making commentary such as “how should we refactor this code to fit within the development pattern we have employed?”

· The CoPilot can generate code with functions unbeknown to the Driver and Navigator, possibly changing the innovative mindset of the pair and shifting a viewpoint to a new novel idea using the package introduced within the generated code

In summary — while CoPilot is innovative from a code generation standpoint, its applicability with Paired Programming paradigms can present some learning opportunities and code acceleration. At this point, I am still skeptical of a pair programming scenario including CoPilot but remain open to the possibility of new features being introduced to align more with the ideology.

Related Blog Posts from 

TribalScale Inc.

• Pair Programming is in our DNA. By Dumitru Lupanciuc | by TribalScale Inc. | TribalScale | Medium
• Pair Programming: Or Does 1 + 1 = 3? | by TribalScale Inc. | TribalScale | Medium