Everyone I talk to is using AI, and it’s changing how they run their business. But most are uneasy about whether they’re using it well. They suspect their competitors have figured out something they haven’t. One practice from software engineering can help: pair programming, where two people work through a problem together, making their reasoning visible as they go. It’s a practical way to learn how to use AI, and to spread the judgement already present in your organization.
A pairing session
Last week I spent an hour pair programming with a director of engineering on his system. He was using Claude Code and we were in a Google Meet together, discussing the changes.
We were changing feature-flagging, a feature that allows his company to slowly roll out new features and changes, ensuring that things don’t break as they release software. During the session we discovered that a misconfigured flag would unintentionally be released to all users. This was a big bug that needed to be fixed; however, there was a bigger problem we needed to address - the tests for this feature would pass regardless of the bug.
How did this happen? The code wasn’t careless, but the tests weren’t validating the right things. To a naive observer or an agent, the presence of tests could have been enough, but the tests hadn’t captured an important decision: what should happen when a flag is misconfigured? Pairing gave us a chance to make that decision explicit and check that the tests enforced it.
Using agents
Coding agents will happily write tests. Over time the quality of test code generated by LLMs has improved, but a common mistake is creating structural tests - they assert the system is structured a certain way, not that it behaves a certain way. This can be helpful for sticking to system standards, spotting coding errors etc, but in this case it was the reason for a significant behaviour gap.
The key question to be asking in this scenario - is the right approach? - is a judgment call. Agentic coding systems aren’t necessarily going to answer that the same way as you. The correct judgement exists in your organization, and it needs to be shared.
Why pairing?
When an agent does the typing, most of what the human is doing is judgment. In the session I described, we spent a little time discussing what, and most of the time describing how. Here are some examples of our asks:
Write tests before touching the code (clear acceptance criteria)
Ensure the tests fail before implementing a fix (high quality tests)
Use mutations to validate the quality of the tests (testing the right thing)
Code review the change against our standards. (a second set of “eyes”)
Update coding standards (ensure the next person doesn’t repeat mistakes)
None of that is new. What’s new is that an agent will follow best practices that you ask for, or write down. You need to be clear about what good looks like.
Human code reviews are critical but don’t serve the same function. A reviewer sees the finished change, not the questions that shaped it. Pairing puts those questions in the room while the work is happening, and influences both the outcome, and future sessions.
If you’re paying for AI tools
If you’re using AI tools in your organization, ensure “what good looks like” has been defined. A weekly pairing session with an experienced, senior member of your team helps to solve this: it’s one of the most effective ways I know to disseminate best practices within a team.
This approach has worked for me for years, and I now do this with my clients: 90 minutes pairing on their own work, and a short note afterwards summarizing key points. If you’d like to try one, hit me up at ken@talltree.io.