Pair programming is praised for its numerous benefits. The entire team understands the code base and the technologies used, ensuring continual progress even if some team members are absent or sick.
It makes code reviews easier, if needed at all. It also results in high-quality code.
This is where AI programming tools like GitHub’s Copilot, frequently referred to as “AI pair programmers,” could come in. Some coders might welcome these non-humans who could finally take away the bane of programming, and now we never have to “pair program” with annoying colleagues. Others might feel differently.
No matter your experience with pair programming, AI might be a potential game-changer.
In this article, I’ll explore the world of pair programming and try to answer the question, “Will AI Kill Pair Programming?”
You can use the clickable menu to skip to a specific section.
- What is pair programming?
- Pros and cons of pair programming
- So, will AI kill pair programming?
- Wrap-up
1. What is pair programming?
The main premise of pair programming is that two people work on the same computer. This is, however, not applicable in every case, as there are companies with a version of pair programming known as “mob programming.”
In mob programming, a group of developers (instead of a pair) work together on a single task. They could even work on the same computer.
Remote pair programming has also changed the definition and scope of pair programming.
Remote pairing involves a pair working on a problem over the internet. It’s great for work-from-home teams or companies with members spread across different locations, countries, or regions.
How pair programming works
In pair programming, two people work together, usually on one computer, and write code. They have a clear goal that they need to achieve and tend to ignore the bigger picture during the pairing period.
Sometimes, especially when working with unfamiliar technologies, tools, or code bases, the pair might take some time to do individual research separately before coming back to their pair.
Pairing can include other activities like taking the time to understand a user story and your team’s definition of “done”.
A user story is an approach to building software features. It rephrases the features, with a focus on the end user.
A team’s definition of “done” refers to what the group considers a finished version that could be shared with the end user. This could be one user story or the entire product.
For pair programming to work, you need to think about how to take breaks, manage your time, take turns, and rotate the pair’s roles. If pairing remotely, use software that allows you access to the other person’s code, for example, LiveShare on Visual Studio code.
Pair programming techniques
There are several pair programming techniques, ranging from the driver-navigator style, ping-pong, and strong style pairing. The important thing to note is that these approaches aren’t cast in stone.
You’re free to take what works for you and even combine different strategies to make your pairing productive, fun, and less like a nightmare.
The driver-navigator style
The driver and navigator combination is the most popular pairing style. Let me explain briefly how it works.
The driver is the person at the keyboard, writing the code. It’s their job to talk through what they’re currently doing.
The navigator, on the other hand, is an almost real-time code reviewer. They can give suggestions to the driver, point out things that they may have missed, and even alert them to potential obstacles.
The people in the driver and navigator roles switch after some time, depending on how long they’re pairing.
Pairing usually works best when one person is more knowledgeable and the other can learn from them.
The ping-pong technique
This style heavily relies on test-driven development (TDD). TDD is a programming approach where you write tests for your code before writing the code itself.
In ping-pong, one pair writes the failing test (the ping) and the other person makes the test pass (the pong). Once the test passes, the pair can begin the next ping-pong cycle.
You can choose to refactor the code at the end of each ping-pong cycle. The cycle, therefore, becomes ping-pong-refactor or red-green-refactor.
The strong-style technique
This technique is very similar to the driver-navigator one. However, in strong-style pairing, the navigator is the more experienced one of the pair. The driver is usually less experienced with the technology or code base.
In this pairing approach, the driver should ask for the rationale behind the navigator’s decisions after they’re done implementing the solution.
The strong-style technique is great for knowledge transfer. The driver can learn a lot from the navigator.
2. Pros and cons of pair programming
Pair programming is great by many standards, but it does have its share of problems. For example, it might be great for knowledge transfer, especially with the strong-style technique, but the driver may feel micromanaged.
Let’s explore some more pair programming advantages and disadvantages.
Pros
Knowledge-sharing
When we pair, we learn from each other. The more experienced engineer can teach the less experienced one about a code base or technology. The less experienced person might know a new technology that can solve a problem.
Pairing also allows us to share good engineering practices and techniques we’ve learned along the way.
Sometimes, it may be intriguing to see how someone else approaches solving a problem. You could learn something from that.
As a less experienced engineer, the immediate feedback pair programming provides can go a long way in making you a better developer.
Focus
Sometimes, when we work alone, we might be feeling a bit demotivated or tired. As a result, we end up procrastinating on a task or keep visiting “the socials” to get updates on our friends’ lives or the trending events on X (or Instagram, or TikTok—no judgement here).
Pair programming keeps you focused on the task at hand without distractions and can keep you going on a day when a bit of fatigue gets in the way.
High-quality code
When we pair, we have four eyes on the code. This means that we can see bugs and fix them early on in the Software Development Life Cycle (SDLC) and spend minimal time on code reviews.
Additionally, code resulting from pair programming is more likely to be compliant with industry standards, run quicker, and be refactored.
Team progress
When teams pair, everyone gets to understand the code base and the technologies currently being used. This way, no one “owns” the knowledge.
In the event that a team member leaves, is sick, on leave, or cannot work, then the group’s progress doesn’t grind to a halt.
The user stories can still be completed on time and on schedule, without delays.
The team also creates understandable and maintainable code.
Cons
Pairing for too long
Some learning and working environments require their developers to pair all the time, for the entire workday. While this may be highly productive at the outset, it may be detrimental to the team in the medium and long term.
When you pair, we tend to focus 100% on the task at hand. If you work for an entire work or school day, you might be too exhausted, especially if you don’t take breaks, which you can do when working alone.
This could affect the code quality, creativity, and problem-solving capabilities within your team.
Taking frequent breaks is a great way to keep your energy and focus levels up.
Keyboard hogging
Keyboard hogging can be a problem when pairing. One pair might want to control the keyboard most of the time without allowing the other access.
This is likely to happen when one pair feels that the other is “slow” or doesn’t know much about the programming language or code base.
Power dynamics
Most of the time, pairs are made up of different people in terms of skill set, experience, and even seniority. It might be difficult to share suggestions as a junior developer when you’re working with a senior, more experienced one.
Resource-intensive in the short-term
Some companies avoid pair programming because it looks like an expensive venture. It feels like paying two people to do the same job. They could spend that time accomplishing two different tasks.
However, if well implemented, pair programming benefits will start to show in the medium and long term.
Dysfunctional pairs
Sometimes pair programming can be a pain when the other pair is extremely difficult to work with. We could be from a different culture, so we need to find a way to work with each other. The other pair may also fail to hold up their end of the bargain.
They may not help navigate or drive much, so one person ends up doing both. Sometimes, you might just be out of rhythm and need to switch pairs.
3. So, will AI kill pair programming?
We’re still reeling from all the AI coding assistants that have come to make our lives easier as software engineers.
Of the 37,000 developers using AI tools in the 2023 StackOverflow Survey, the vast majority (82.55%) were using them to write code. However, the bigger question is whether these AI tools can actually help streamline pair programming.
On the one hand, we could choose to compare AI tools that claim to be “your AI pair programmer” with humans. But is this a fair comparison?
Comparing AI assistant tools with human pairs
If we think about the driver-navigator technique, is the AI the driver or navigator? In a programming pair, the driver writes code and the navigator gives suggestions.
In this case, then, the AI cannot be the driver, as it only generates code snippets and would, in most cases, not write code to fulfill an entire user story.
However, wouldn’t it be the driver if it generated entire code snippets?
If we think of the AI as the navigator, it does give you code suggestions via code completions. However, isn’t the navigator supposed to be the more knowledgeable or experienced one?
Would we be saying that the AI, in this case, knows more about the technologies and code base than the human?
Trying to compare AI with humans might not be the best way to think about AI-powered pair programming.
AI coding assistant tools as AI programmers
A better approach to thinking about AI code assistant tools like Copilot, CodeWhisperer, and TabNine is to think about them as what they actually are—AIs, not humans.
Tools like Github’s Copilot market themselves as “your AI pair programmer”. Some developers think that these might be a little misleading, as most of the AI tools can provide only code suggestions and completions.
These AI tools give suggestions that you already had in mind, only that it took you a little longer to type them out. They’re, however, able to generate them quickly, making you faster as a developer.
We’re therefore more productive in terms of the speed at which we’re able to complete scripts and user stories.
In an AI programming case study published by the Nielsen Norman Group, 70 programmers were asked to create an HTTP server in JavaScript. Some of them would use Copilot, and others wouldn’t. The group using Copilot finished their task faster, showing a 126% increase in productivity.
However, when the AI gets it wrong, debugging might end up taking up more time than the AI is actually saving us.
An interesting perspective from which to look at this is that when coding, sometimes all we need is a suggestion, especially when facing a blocker. And the AI can help with exactly that.
We can therefore say that there are a few pair programming aspects that AI has nailed, including debugging.
Well, will it kill pair programming?
AI will kill the kind of pair programming that isn’t properly implemented. For example, if pair programming is done in a way where I play the roles of both driver and navigator, then, in this case, the AI and I are better off.
AI tools now understand context, giving suggestions based on the code base. This means that the AI and I can form a great pair.
So, if your pairing options are a bad pair or a culture that doesn’t encourage good pairing practices, then an AI like Copilot or CodeWhisperer can help.
On the other hand, if pair programming is done effectively, then the need for an AI pair programmer is significantly reduced.
If you and your partner agree on the goals that you need to work towards in a pairing session and one or both of you understand the technologies you’re using and the code base, as well as your user story, then you’ll not need an AI.
However, if you’re coding solo and are a bit stuck, then an AI can come in handy. It would be a technology that you can also consult when your colleagues aren’t reachable, for example, if it’s late at night, they’re in a meeting, or they’re on vacation.
As a result of all this, it’s safe to conclude that we don’t know for sure whether AI will kill pair programming. However, for now, it’s helpful to consider your specific use case when thinking about AI as a pair programmer.
4. Final thoughts
Sometimes, we developers swear by riding solo. We may have had dreadful experiences with pair programming and would rather not take on roles that require pairing. There are right and wrong ways to do pair programming. For example, pairing for the entire workday might be counterproductive.
Pairing has its limits too. At times, the only way to solve a problem is to give your brain some quiet time to think, and it’s difficult to do so when someone is constantly talking. Some engineers’ closest experience with pairing is via rubber duck debugging. But we all agree that, from time to time, we all need help writing code.
Whether your pair programming experience is positive or negative might be highly determined by how it was implemented in your work or learning environment. Surprisingly, this may translate to AI as well. You might need AI to work as your programming pair if your workplace or school culture doesn’t support functional pair programming.
On the other hand, if you have a culture in which pair programming can thrive, then you may not need to use AI when pairing. You might need it, though, if you’re writing code solo.
The final say on whether to use the AI-generated code belongs to you, the human software engineer. To do this, you need to have a solid understanding of the technologies and code base that you’re using.
At CareerFoundry, we ensure that our students have the necessary skills in web development that can help them make informed decisions when using AI code assistants. Our Full-Stack Web Development Program mentors also ensure that our learners know how to pair a program with a human and understand the principles and techniques to do it successfully. This gives them a template to use AI to make them more productive engineers.
If you’re interested in reading more about AI and learning coding, check out these articles: