Last week I spent an hour pairing with a director of engineering on his team’s feature-flag system. We used Claude on the real code, and finished the session with a real pull request.
Within the hour we found that flags failed open. This meant that if a flag was misconfigured, all customers would get the feature! We also found that no test asserted intended behaviour - you could flip the default behaviour to fail closed and every test would still pass.
The code wasn’t careless. There were tests, but they didn’t assert the what happens with bad data. That’s an important distinction, understood by senior technologists, often in their heads.
Agents widen the gap
Coding agents write tests eagerly. Left to their own devices, they write tests about structure: this function was called, this query ran twice. Those tests pass and demonstrate coverage.
The question that matters though - what should happen when this is the wrong approach? - is a judgment call. On many teams senior people can answer it, but they don’t participate in every session. Agents often let teams else ship faster than that judgment can reach them.
Why pairing?
The director had his own rule: when someone has a complaint, ask whether they’re writing tests first and pairing. That is a process judgement call.
When the agent does the typing, the whole session is judgment. In my session we:
Wrote tests for the behaviour we wanted, before touching the code
Ensured they failed before implementing a fix
Used mutations to validate the quality of the tests
Asked the agent to review its own change against the team’s written standards, and update them where there were gaps
None of that is new. What’s new is that the typing is free, so an hour is enough to do all of it on real code, with the person who needs to learn it steering.
A code review can’t do the same job. A reviewer sees the finished change, not the questions that shaped it. Pairing puts those questions in the room while the work is happening.
If you’re paying for AI tools
The organizations I talk to that are spending on AI aren’t always sure it’s paying off. The licences aren’t the problem, it’s that the judgment for using them properly sits with a small number of people.
A weekly pairing session helps to solve this: it’s the cheapest way I know to turn a tool into a practice.
It’s been working so well, that I now do this as a weekly session with teams: 90 minutes 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.