Pair Programming With AI, The Solo Developer's Way
Pair programming used to mean one person coding, one person reviewing. Today solo developers run the same loop alone — generator on the left, reviewer on the right — using a single AI coding assistant for both roles. This article breaks down the prompt structure, review cadence, and collaboration loops that keep AI-generated code fast and correct.
Why solo developers pair with AI
The original pair-programming model had two jobs: the driver writes code, the navigator catches mistakes and spots blind spots. Solo developers used to do both sequentially, which slows iteration and lets errors accumulate. Modern AI coding assistants — GitHub Copilot, Cursor, Claude, ChatGPT — let you split those two jobs in real time.
The key insight is not to ask the assistant to "write the whole feature." That is the single most common mistake. Instead you run a generator / reviewer split: one prompt produces a solution, the next prompt plays navigator and finds the weaknesses before you ever commit.
| Role | What it does | Who plays it |
|---|---|---|
| Driver | Writes the code, commits, integrates | You (with AI autocomplete) |
| Navigator | Reviews for correctness, edge cases, style | AI in a second prompt session |
| Architect | Decides structure before writing begins | You + AI, before coding |
The three-pass loop
A reliable pair-programming loop with AI has three passes. Skip any of them and you end up with code that compiles but is hard to maintain.
Pass 1 — Architect before writing
Before you write a line, describe the feature to the assistant in plain language and ask for a structural plan, not code. This surfaces requirements you had not thought about.
Pass 2 — Generate in small slices
Generate one file or one function at a time. If the assistant outputs 300 lines, it is too much. Slice the output to < 100 lines per prompt and review each slice before moving on. See our earlier article on onboarding with AI coding assistants for the right context window size.
Pass 3 — Review in a separate session
Open a fresh chat and paste the generated code back in. Ask the assistant to review it as a senior engineer, not to improve it. Force it to find problems first, then suggest fixes. This second session is the real pair-programming moment.
Prompt templates for each role
These three templates cover 90% of solo-pair sessions. Save them locally and reuse them.
Architect prompt
Driver prompt
Navigator (review) prompt
For a deeper look at structured code review with AI, see our article on AI code review workflows.
Common failure modes
These are the mistakes that turn AI pair programming into slow, brittle code generation.
- Skipping the architect pass. You get code that solves the wrong problem correctly.
- One prompt for the whole feature. The assistant loses track of context and the output is shallow.
- Reviewing in the same session. The assistant has confirmation bias about its own code.
- Accepting all generated tests. AI-generated tests are often vacuous — they pass but do not prove correctness.
- Never running the code. Pair programming only catches logic bugs. You still need to run the unit tests locally.
Making it sustainable
The loop only works if you stay in control. The assistant is the navigator, not the driver. Keep three rules:
- You write the acceptance criteria.
- You choose what to commit and what to throw away.
- You run the tests — AI does not ship code for you.
This pattern scales to small teams. When you grow from one developer to three, the same three-pass loop applies: the team decides the architecture, each person generates and reviews their own slices, and the code review pass catches cross-file issues. Pair programming is not about having another human in the room anymore — it is about having another voice in the loop. AI is that voice, as long as you drive.