Over the past months, a question has been making the rounds in engineering circles:
Is anyone doing “triplet programming” — two humans and an AI agent?
We are. Here is why.
The Setup
When we introduced GitHub Copilot as an agentic coding assistant, the default assumption was that each developer would work one-on-one with the agent. That is not what we ended up doing.
Instead, we run sessions with two developers and one agent.
It feels slightly unusual at first. It looks expensive on paper. But the reasons behind it are pragmatic, not ideological.
1. Shared Learning at the Point of Work
Not everyone on our team came in with the same instincts for working with an AI agent. How you phrase a task, how much context you give, when you push back versus accept the output — these are learnable skills, and they vary widely between developers.
Formal training helps, but nothing beats watching a colleague handle a tricky prompt and realising you would have done it differently. Two people in the same session means that knowledge transfer happens naturally, at the moment it is most relevant.
The gap between developers who are fluent with AI tools and those who are not can grow quietly and quickly. We wanted to close it before it became a problem.
2. A Human Safety Net for the Whole Codebase
An AI agent working on a modern codebase is not making small, contained edits. It can generate changes that ripple across many files at once. That is enormously powerful — and it raises the stakes of a mistaken direction considerably.
One developer reviewing AI output is better than none. Two is meaningfully better than one. Not because either of them is checking a formal list, but because having a second person in the room changes how carefully the first person looks.
Having a second human in the loop has become our most reliable safeguard against changes that look locally correct but break something we did not anticipate elsewhere.
3. Preventing the Underspecification Trap
This is perhaps the subtlest reason — and the one we discovered rather than planned for.
AI agents are extraordinarily good at generating plausible-looking solutions to the problem you described. They are less good at noticing when the problem you described is not quite the problem you meant.
When one developer steers an agent alone, the task definition often stays implicit. The developer knows what they mean, the agent produces something coherent, and by the time the mismatch becomes visible, you are several hundred lines deep in the wrong direction.
Two developers talking through the task — even briefly — before letting the agent run surfaces those ambiguities before they become expensive. This single change has had the most obvious impact on output quality.
What It Does Not Look Like
A recent LinkedIn discussion pointed to peer-reviewed research suggesting that in traditional pair programming, the driver and navigator do not actually split the work the way the metaphor implies. Both people traverse levels of abstraction together rather than one focusing on the big picture while the other handles syntax.
We see something similar in our triplet setup.
There is no clean division where one developer “manages the agent” while the other “thinks strategically.” Both developers are constantly moving between high-level intent and low-level output, calibrating what the agent is doing against what they actually want. The agent adds a third node to that loop — it does not replace either human or slot neatly into a predefined role.
Is It Worth the Cost?
The honest answer is: yes, for where we are right now.
We are early in bringing agentic AI into the team. The risks of codebase-wide errors are real. The learning value is high. We expect the format to evolve as fluency increases across the team.
Triplet programming is not a permanent architecture. It is a transitional one — and a deliberate choice to treat that transition as a collaborative process rather than something each developer navigates alone.
If you are experimenting with similar setups, I would genuinely like to hear what you are seeing — what works, what does not, and whether the economics look different in your context.