AI pair programming: how to work with an AI as your pair

What is AI pair programming?

Pair programming is an old practice: two people share one task. Martin Fowler's article On Pair Programming describes the standard roles. The driver is at the keyboard, focused on the tiny goal at hand and talking through what they are doing. The navigator observes, reviews the code as it appears, and keeps the larger issues, bugs and next steps in mind. The idea of the split is two perspectives on the same code: tactical and strategic.

AI pair programming borrows the roles and puts an AI in one seat. In a chat or an editor, the AI can write code, explain code, propose alternatives and spot mistakes. You supply what it lacks: knowledge of the goal, taste, and the ability to say that something is wrong. Done well, you get the benefit of a second set of eyes at any hour. Done badly, you get a confident partner who agrees with everything and whom nobody is checking.

That second sentence is the heart of the practice. A human pair challenges you. An AI tends to go along with the direction you set, so the challenge has to come from how you work: small steps, tests, and a habit of asking it to find faults.

What are the ways to pair with an AI?

There is more than one way to sit, and the right one depends on what you are doing and how well you know the area.

Most builders using agents such as Claude Code or Cursor work in the second mode. If that is you, the navigator job is real work. You are responsible for the direction, the scope and the verdict. The AI does the typing.

How do you run an AI pair programming session?

A routine keeps you in the navigator seat. This one fits a session of thirty to ninety minutes.

1. Set one goal. Write it in a sentence that includes how you will know it is done. "Add a Reset button that clears the form, tested by a new unit test."
2. Load the context. Name the files to start from and any fact the code does not show. A short project instructions file saves repeating yourself.
3. Ask for a plan before code. Have the AI say what it will change in a few lines. Correct the plan, not the code.
4. Take one small step. One function, one test, one component. If the AI wants to touch ten files, say no and ask for step one.
5. Run it. Run the tests or the app yourself. Do not trust "this should work".
6. Read the diff. Read every changed line before accepting. If you cannot explain a line, ask the AI to explain it, then decide.
7. Commit. A commit after every working step gives you a place to return to when the next step goes wrong.
8. Swap roles now and then. Write the next function yourself, or ask the AI to review your code. Keep the skill from fading.

What prompts work for pairing with an AI?

These prompts set the working agreement. Paste them at the start or reuse them mid-session.

We are pair programming. I navigate, you drive.

Rules for this session:
1. Propose a short plan and wait for my go-ahead before you edit any file.
2. Work in small steps. One step is one function, one test or one component.
3. After each step, tell me how to check it, and run the check if you can.
4. If my instruction looks wrong, say so before doing it and explain why.
5. Do not add anything I did not ask for. Do not refactor unrelated code.

Goal for today: <one sentence with a done-check>.
Start from: <files>.

Here is a failing test I wrote:
<paste the test>

Make it pass with the smallest change. Do not edit the test. Show me the change, then stop. I will write the next test.

Before you write code for this, give me the two best reasons it could be a bad idea, and one simpler alternative. Then ask me one question that would change your recommendation.

Explain the change you just made as if I know the language but not this codebase. For each changed block, say what it does, why it is needed, and what would break if I deleted it.

Review the diff above as a strict reviewer. List bugs, missing edge cases, missing tests and anything you added that I did not request. Do not praise. If you find nothing, say what you checked.

Stop. Summarise in five lines: the goal, what we tried, why each attempt failed, what we know for certain, and the next thing to test. I will start a new session from your summary.

Which skills matter when you pair with an AI?

The AI changes where the effort goes. Less of it is typing. More of it is these four things.

• Describing precisely. A vague request gets a plausible guess. Name the file, the behavior and the limit.
• Reading code you did not write. The diff is the product. A slow, honest read of it is the main safeguard you have.
• Writing the check first. A test or a manual script that fails now and passes when the work is right turns the AI's output from an opinion into evidence.
• Knowing when to stop. The AI will keep adding. You decide when the goal is met.

If you are learning, pair differently. Ask the AI to hold back. Claude Code's output styles include a Learning style, which its documentation describes as Claude explaining its choices and leaving small pieces of code for you to write yourself, and an Explanatory style that adds short notes on the reasoning. Other tools have no such switch, but you get the same effect with a prompt: "Do not write the solution. Give me a hint and let me try." The guide to coding with AI as a learner goes further.

When does AI pair programming go wrong?

• You stop reading. The most common failure. Past a certain size, the diff looks like a wall and you approve it. Keep steps small enough to read.
• The AI marks its own homework. Tests written by the same AI after the code often assert what the code does, not what it should do. Write the test first, or at least read it hard.
• Invented APIs. The AI may call a function or option that does not exist. Run the code and check names against the library's documentation.
• Security by omission. Authentication, payment, file upload and anything that handles other people's data deserves a human-level review, not a skim. Never paste secrets into a chat.
• Scope creep. Left alone, the AI adds options, abstractions and files. Say what is out of scope in the first message.
• Skill drift. If you only navigate, your ability to write the code yourself will fade. Keep a few tasks you do by hand.

For checking the output in a more structured way, see AI code review. For ideas to practise on, the board has plenty of small, well-scoped ones: a tool like Meeting cost ticker fits in one session, and every idea carries a generated build prompt you can use as a kickoff. A bigger map of the field, including agents that work on their own for longer, is in what agentic coding is.