Over the past few months, I've used a combination of GitHub CoPilot and ChatGPT as coding tools. While we're far from an autonomous RoboCoder, the toolset is improving fast. We will still need human software developers, but I am starting to see how these tools will eventually replace human pair programmers.
The practice of pair programming is older than most people think, dating all the way back to the mid-50s. The idea is simple: Humans make mistakes and wrong assumptions, so having an extra brain counters that.
That brain doesn't need to be carbon-based.
Pair programming serves different functions, and I'd like to share my subjective opinion on how far we are with each.
Checking for mistakes
The most common mistakes get caught by linters, strong typing, and static analysis tools these days. The only mistakes that still need human intervention are of the functional kind: the system doesn't do what it's supposed to do. Automated tools are not helping out with that kind of error. Yet.
Verdict: 4/5. Superhuman but not perfect.
Debugging
Debugging with a pair programmer is more than rubber ducking. They have experiences and insights that might help us track the bug faster. For complicated bugs, that is still a requirement.
But for straightforward bugs, I'm surprised how effective ChatGPT has become.
Prompt: "I have this code, but the e-mail address isn't set after form submission. Why is that? <copy-paste-of-the-class>"
Not only does the tool pinpoint where I made the dumb mistake, it explains why it's not working and shows a code snippet of what can be done to fix it. This is the equivalent of finding a StackOverflow answer for your exact issue!
Verdict: 3/5 As good as humans for simple bugs.
Refactoring
A lot of the value in pair programming comes from refactoring. We've got the code to work; now it's time to make it better. I've always found pair refactoring to be a great way to learn about syntactic sugar and clean concepts.
Prompt: "What can I do to make this more readable? <copy-paste-of-the-code>"
While nothing groundbreaking, these are some good suggestions. Again, an explanation and an improved code example are given.
Verdict: 3/5 As good as humans
Inspiration
There are always multiple ways to solve a problem, and another developer can be a great sounding board. ChatGPT can also do that.
Prompt: "I have a REST call to upload a list of users. The body of this call can be up to 100MB. What are some good ways to handle this?"
Those aren't bad suggestions, but I've yet to find an answer I couldn't have come up with myself.
Verdict: 2/5 Better than junior developers
Mentoring
The most powerful benefit of pair programming is mentoring juniors. When a young developer joins a company, pairing with a senior dev is the fastest way to level up. Not only do they learn the system they're working on, but they also learn the trade of software engineering.
While I believe an AI can take over this role eventually, the technology is not there yet.
Verdict 0/5 Not even close
Knowledge transfer
If you haven't touched a part of the codebase, it's always easier to get an introduction by a pair. Sure, documentation might help, but let's be honest: it's faster to ask.
While it's technically possible to load the entire codebase into an LLM, I haven't found a user-friendly tool that does this. A GitGPT would be a great way to share knowledge.
"Where are the exceptions handlers?"
"Which controllers are public?"
"Which React components still need to be switched to functional components?"
Verdict: 0/5 Technically possible, but good tooling doesn't exist yet
We are not there yet, but it's clear to see how pairing with a human developer will be uncommon a few years from now. Coding assistants will evolve to take over that role.
Juniors will no longer "weigh down" seniors. An automated mentor can do most of the training. This should make the barrier to entry lower.
Async teams no longer have to sync up for pairing sessions. Their assistant will always be ready when they are.
Knowledge sharing will be team-wide. An AI that is involved in pairing and reads all changes to the codebase will be a product-specific expert system. We could ask it technical questions like "Which parts of the code would be impacted if we were to swap Mongo for MySQL?"
We are closer to that reality than I thought a few months ago.
Member discussion