Pair-programming with two AI assistants sounds like a gimmick until you actually do it. Then it becomes ordinary, useful, and occasionally humbling. I built htmlEdit, a small tool for editing HTML documents visually by pointing and clicking instead of re-prompting, with two assistants working alongside me. Here's what held up and what didn't.
The mental model that worked was old-fashioned pair-programming, where one person drives and the other navigates. I stayed the driver throughout. The assistants navigated: suggesting, drafting, spotting things I'd miss. The moment I let one take the wheel, quietly accepting whatever it produced, quality dropped and I stopped understanding my own project.
Stay the driver
Driving means you decide direction, you type the final word on what lands, and you hold the map. It's tempting to let a capable assistant just go, especially when it's producing plausible work fast. Resist that. The speed is real, but speed you can't follow just piles up debt you'll pay back later with interest, usually while debugging something you never actually read.
Concretely, staying the driver meant I read everything before it went in. Not skimmed, read. If a change was too large to read properly, that was a signal the task was scoped wrong, not a reason to trust it more. Which brings me to the thing that mattered most.
Scope so you can review in one sitting
The single biggest lever was task size. A task scoped so its output fits in one review sitting is one you can actually check. A task that sprawls across dozens of changes is one you'll wave through because reviewing it properly feels like more work than writing it yourself would have been.
So I kept each job small enough to hold in my head. Build this one behaviour. Handle this one edge case. Wire up this one piece. When I felt the urge to ask for something big and vague, that was usually a sign I hadn't thought it through, and the fix was to break it down, not to hope the assistant would.
This has a nice side effect. Small tasks are also the ones you can hand cleanly to either assistant, because they don't need much shared history to make sense. Scope and delegation solve the same problem from two directions.
Never merge what you don't understand
This is the rule I'd carve above the desk. Plausible is not the same as correct, and AI-generated code is extremely good at looking plausible. It reads well. It's confidently structured. And sometimes it's quietly wrong in a way that only bites three weeks later.
So the rule was simple: if I didn't understand why a change worked, it didn't land, no matter how good it looked. Sometimes that meant asking the assistant to explain itself. Sometimes it meant asking the other assistant to look at it cold, which I've written about in using one AI to check another's work. Either way, understanding came before merging, every time. The few occasions I broke that rule are, predictably, the ones that cost me later.
Let them disagree
One unexpected benefit of running two assistants: they don't always agree, and the disagreement is a gift. When one suggests an approach and the other, looking at the same problem fresh, suggests something different, the gap between them is almost always a place where I'd left something unspecified. The disagreement surfaces the assumption I forgot to make.
I started deliberately using this. When a decision felt important and I wasn't sure, I'd get a view from each and read the difference rather than the answers. The point wasn't to hold a vote. It was to see the seam in my own thinking that the two of them had each filled in differently.
Momentum is the real risk
If I had to name the one thing that catches people out, it's momentum. Two capable assistants produce work fast enough that it's genuinely thrilling, and thrill makes you sloppy. You start accepting more, reading less, understanding later. The project accelerates away from your comprehension of it.
The discipline is boring and it's the whole game: when you notice you've stopped following, stop. Read back. Rebuild your understanding before you write another line. The assistants will happily keep going without you. Your job is to make sure the thing you ship is a thing you actually understand. That's what separates a tool you built from a pile of code you're merely standing next to.