How pair prompting could mitigate the risks of AI assisted programming

Contents#

AI assistance impacts the formation of coding skills
Pair prompting
Pair programming
Pair prompting styles
Increased Engagement and Focus
Conclusion

Intro#

Last week, Anthropic published a paper, measuring how AI assisted programming affects skill development. The first thing that came to my mind was whether collaborative work could mitigate some of the risks. This post is my theory on how pair prompting could help.

Note: None of the following has been applied in practice, they are just ideas I wanted to share, and get feedback on them.

Note 2: This post was 100% written by a human, every mistake is mine.

AI assistance impacts the formation of coding skills#

The Anthropic paper concludes that AI assisted coding could result in:

Lower conceptual understanding.
Impaired code reading.
Worse debugging skills.

And all of these are caused because people are less cognitively engaged when working with AI.

Pair prompting#

As pair programming is when two developers write code together on one machine, we could define pair prompting as

When two developers prompt together an AI agent on the same machine.

Two devs prompting together an AI agent — Pair prompting

Pair programming#

Pair programming is a dividing topic for developers, usually they either hate it or love it. You get the idea by just reading the comments in this reddit post.

I'm not going to get into details about pair programming, there's an exceptional post you could read if you want to learn more.

But in order to get a better idea on how collaborative coding works, let's quickly go through the different pair programming styles.

Driver navigator: In this style the driver is the person who writes the code, focusing on the implementation details, and the navigator is observing the driver and reviews the code on the go. The navigator should focus on the bigger picture.
Ping pong: Ping pong usually goes together with TDD (Test Driven Development), and one participant is writing a failing test and the other is writing the implementation, until the test passes.
Strong style: Here one person is dictating to the other one exactly what to type and do.
Unstructured: This is what most of the people do when collaboratively working on something, from simple quick collaboration on a bug fix to brainstorming sessions.
Tour guide: Here one person leads the session and the other asks questions.

Pair prompting styles#

We could try to do 1-to-1 mappings from pair programming to pair prompting, but this doesn't make a lot of sense to me. For example, if we were going to replicate the driver-navigator style, one participant should write the prompt and the other should review it, but this could still lead to people not having adequate comprehension of the generated code.

Instead we could take inspiration from this collaborative way of programming and come up with new styles which would address the new problems.

Prompter-Interrogator#

In this style one person is prompting the AI for the implementation, while the other is asking explanatory questions about the generated code.

For example, it could work like this:

The prompter is prompting the AI until they are happy with the implementation. The interrogator is taking notes on the overall direction and on implementation details.
Then the interrogator based on their notes and a review of the code, is asking questions to the AI. The questions could be about edge cases, about implementation details, about architecture design, etc.
If after the questions changes are needed, the prompter takes over again and continues.

With this approach, both participants are engaged in the process, the prompter is focused on the implementation and the interrogator is focused on understanding the code and finding gaps. This could lead to better and more detailed understanding of the final solution.

Rubber Duck Pairing#

This collaborative approach is inspired by the rubber ducky technique.

The prompts should be created collaboratively. When both participants are happy with the generated code, one of them will have to present the AI's implementation to the other (both of the participants will have to review the implementation). By presenting the implementation the presenter will challenge their own understanding, and could even find issues.

Again with this technique code comprehension should be improved.

Parallel Implementations#

Here we can take advantage of the fact that AI generates code much faster than humans.

In this style both participants should independently create an implementation of the same problem. Then, they should review each other's implementation.

This approach could be beneficial, because both participants will already have created their own mental model of the solution, and by looking at another one, their model will be challenged. Bugs and gaps in both implementations will be easier to be found.

Explorer-Builder#

This approach is inspired by the Anthropic paper, where they found that

Participants who only asked conceptual questions and relied on their improved understanding to complete the task, although they encountered many errors, they also independently resolved them. On average, this mode was the fastest among high-scoring patterns and second fastest overall, after AI delegation.

Instead of having one person doing what they noticed in the paper, we can split the roles:

One person is asking conceptual questions to the AI.
The other implements the solution. While implementing they can also ask conceptual questions if they find any gaps in their understanding.

With this style, not only will the participants have increased understanding, but they will also hone their debugging skills, because they will have to find and fix the issues in the implementation.

Increased Engagement and Focus#

A benefit of pair programming is increased focus, due to having less distractions when working with someone else. In my opinion, this is even more important with AI assisted coding, because it's easier to get distracted when waiting for the code generation.

I believe working with someone else could be more beneficial to increased code understanding, than just being more careful when working alone. Being questioned and challenged about your assumptions should result in increased effort when reading the code.

Conclusion#

It could be that in the future no humans will be needed for programming, and the agents will do everything, write, test and improve the code. In this scenario it wouldn't matter that programmers won't develop programming related skills. But if we're going to still have humans in the loop, it might be that collaborating with someone else in real time could mitigate some of the risks of AI assisted development.

At Hopp, our goal is to make the best screen sharing tool for devs, which means we have to explore how screen-sharing tools need to evolve for collaboration in the age of AI assisted programming. We'd love to hear about your collaboration challenges with AI tools: share your experience here (2 minute survey). If you don't want to fill the form you could also pop into our discord server and chat with us.