# AI pair programming: how to work with a coding agent

URL: https://agentvera.dev/en/blog/ai-pair-programming/ · Published: 2026-10-27

A practical guide to AI pair programming: driver and navigator roles with an agent, approval modes, small steps, reviewing diffs and pairing two agents.

**In short:**

- Pairing with an agent works like classic pair programming: one side drives and types, the other navigates and reviews. Decide which role you take before each task, not halfway through.
- Match the approval mode to the risk: review every step for unfamiliar or risky code, let the agent drive with file edits auto-accepted for well-tested, well-understood work.
- Keep steps small, commit or checkpoint after each one, read every diff, and for a second opinion let a second agent review what the first one wrote.

AI pair programming is the same practice developers have used for decades, with one seat taken by a coding agent. One side drives: it types the code. The other navigates: it holds the plan, watches for mistakes and decides what comes next. The difference is that an agent types much faster than you read, so the hard part is no longer writing code. It’s keeping control of what gets written.

This guide covers how to split the roles with an agent, when to let it drive on its own and when to review every step, how approval modes in Claude Code, Codex and Gemini CLI fit that choice, how to keep steps small and diffs readable, how to pair for learning rather than just delegating, and how to let two agents pair with each other while you navigate. Command names and modes follow the official docs as of October 2026.

## Driver and navigator, with an agent in one seat

In classic pairing the roles swap often. With an agent, there are two useful setups.

**You navigate, the agent drives.** This is the default for most work. You describe the goal, the constraints and the next step; the agent edits files and runs commands; you read what it did and steer. Your job is the one a good navigator does: keep the big picture, notice when the code goes in a wrong direction, and stop it early.

**You drive, the agent navigates.** You write the code yourself and use the agent as the second pair of eyes. Ask it to review the function you just wrote, to suggest edge cases, to find where a value comes from, or to write the test before you write the code. This is slower, but it’s the right setup when you need to understand every line, for example in code you’ll maintain alone or when you’re learning a new language.

Decide the setup before you start a task, and say it in the prompt: “I’ll write the parser, you review each function I paste and list edge cases” is a very different session from “Implement the parser; stop after each function so I can review.” Switching roles halfway without saying so is how you end up with code nobody fully understands.

## When to let it drive and when to review each step

The question isn’t whether you trust the agent. It’s how expensive a mistake is and how quickly you’d notice it. A simple rule of thumb:

| Situation | Approach |
| --- | --- |
| Well-tested code, clear task, clean git state | Let it drive; review the final diff |
| New feature in code you know | Plan first, then let it drive in small steps |
| Unfamiliar codebase or library | Review each step |
| Database migrations, auth, payments, deletes | Review each step and each command |
| Anything that touches production or shared remotes | You run it yourself |

Two things make letting the agent drive safe: tests that fail when behaviour breaks, and a way to undo. If you have both, a wrong turn costs a few minutes. If you have neither, review every step, or add tests first ([write unit tests with AI](/en/blog/write-unit-tests-with-ai/ "Write unit tests with AI") shows how).

A good middle ground for bigger tasks is to plan first. In Claude Code, plan mode lets the agent read and propose a plan without editing anything; you review the plan, correct it, then switch modes and let it execute. [Claude Code plan mode](/en/blog/claude-code-plan-mode/ "Claude Code plan mode") walks through it. Reviewing a plan takes a minute; reviewing a wrong implementation takes much longer.

## Approval modes: how much the agent may do without asking

Every major coding agent CLI has a setting for how often it stops to ask you. That setting is your pairing style written as configuration.

**Claude Code** has permission modes, as of October 2026:

- `default`: asks before file edits and before commands that aren’t already allowed. This is review-each-step.
- `acceptEdits`: file edits in the working directory, plus simple file commands such as `mkdir` and `mv`, are accepted without asking; other commands still ask.
- `plan`: reads and proposes, doesn’t edit.
- `auto`: a background classifier checks each action and blocks risky ones, so the agent asks less often. Availability depends on your plan and model, and admins can turn it off.
- `bypassPermissions`: no checks at all. The docs recommend it only in isolated environments such as containers or VMs.

Press Shift+Tab to cycle through modes during a session, start with `claude --permission-mode acceptEdits`, or set `permissions.defaultMode` in settings. When you answer a prompt with “Yes, and don’t ask again”, the rule is saved so the same command won’t ask again. [Claude Code permissions](/en/blog/claude-code-skip-permissions/ "Claude Code permissions") explains the risky end of the scale.

**Codex CLI** combines a sandbox with an approval policy. Its default Auto preset lets it edit and run commands inside the workspace and asks before going outside it (`--sandbox workspace-write --ask-for-approval on-request`). Use `/permissions` during a session to switch, for example to Read Only, or start with `--sandbox read-only` when you only want it to look.

**Gemini CLI** has `--approval-mode` with `default` (ask), `auto_edit` (accept edits, ask for other tools), `plan` (read-only) and `yolo` (accept everything).

A practical mapping: review-each-step means the default mode everywhere. Letting it drive on routine work means accepting edits but still approving shell commands, because commands are where the irreversible things happen. Full auto belongs in a container or a throwaway worktree, never on a machine with production credentials.

## Small steps

Pairing works because each step is small enough to discuss. With an agent this matters more, since it can produce a thousand lines before you finish reading the first hundred.

- **Ask for one step at a time.** “Add the validation function and its tests, then stop” is better than “build the signup flow.”
- **Say when to stop.** Agents tend to continue to the next obvious thing. “Stop after this and summarize what you changed” keeps the pace yours.
- **Commit after each green step.** A commit per step gives you a clean undo point and a readable history. `git add -p` lets you check each hunk on the way in.
- **Use checkpoints for the in-between.** In Claude Code, `/rewind` (or pressing Esc twice) takes code and conversation back to an earlier prompt. Changes made by shell commands aren’t tracked by it, so git stays your real safety net. [Undo Claude Code changes](/en/blog/undo-claude-code-changes/ "Undo Claude Code changes") covers both.

If a step goes wrong, undo it and re-prompt with what you learned. Asking the agent to fix its own wrong turn on top of the wrong code usually makes a bigger mess than starting the step again.

## Reviewing diffs

As navigator, the diff is your main tool. Read it before you accept the step, not after the next three.

```bash
git status
git diff --stat
git diff
```

In Codex, `/diff` shows the current changes inside the session. In any agent you can ask: “Show me the diff of what you changed and explain each hunk in one line.”

What to look for, beyond whether the code works:

- **Scope.** Files changed that have nothing to do with the task. Renames, reformatting and “small cleanups” hide real changes.
- **Deleted or weakened tests.** An assertion changed to match new output, or a test marked as skipped, is a red flag.
- **Silenced errors.** Empty `catch` blocks, `any` casts, disabled lint rules, `--force` flags.
- **New dependencies.** Each one is code you now maintain.
- **Things you can’t explain.** If you can’t say why a line is there, ask before accepting it.

The [AI code review guide](/en/blog/ai-code-review/ "AI code review") goes deeper on reviewing agent output at the pull request stage.

## Learning versus delegating

Pairing with an agent can make you faster at things you already know, or it can teach you things you don’t. Those need different sessions.

**When you delegate,** you care about the result. Give clear acceptance criteria, let the agent drive, review the diff and the tests. That’s fine for boilerplate, migrations and code in areas you already understand.

**When you want to learn,** slow it down on purpose:

- Ask for a plan and an explanation before any code: “Explain how you’d approach this and why, don’t write code yet.”
- Type the core logic yourself and ask the agent to review it.
- Ask “why this and not that?” about its choices, and ask it to show the alternative.
- Ask it to write a failing test first, then make it pass yourself.

A useful habit: if you couldn’t rewrite a piece of code without the agent, you haven’t learned it yet, you’ve only accepted it. That’s acceptable for some code, but it should be a decision, not an accident.

## Pairing two agents: one writes, one reviews

The navigator role can also go to a second agent. One agent writes; another, ideally a different model so their blind spots differ, reviews; you decide what to act on.

A simple version with two CLIs in the same repository:

```bash
# Terminal 1: Claude Code implements the step
claude "Add rate limiting to the /login route. Stop when tests pass."

# Terminal 2: Codex reviews the uncommitted changes
codex review --uncommitted
```

`codex review` can also review against a base branch (`--base main`) or a single commit (`--commit <sha>`), and inside a session `/review` does the same. Paste the findings you agree with back to the writing agent, and ignore the ones you don’t: the reviewer’s output is advice for you, not orders for the other agent.

A few rules make agent-to-agent pairing work:

- **Different model, or at least a fresh session.** A reviewer that shares the writer’s context tends to agree with it.
- **The reviewer doesn’t edit.** Run it read-only. Two agents editing the same files at once is a merge conflict, not a review.
- **You stay the navigator.** Don’t pipe review output straight into the writer in an endless loop. Read it, pick the real issues, send those.
- **Write the criteria down.** “Check for missing input validation, unhandled errors and changed behaviour” gives a much more useful review than “review this”.

For larger jobs, the same pattern scales to several writers in separate worktrees with one reviewer, which [AI agent teams](/en/blog/ai-agent-team/ "AI agent teams") covers.

## Doing it with AgentVera

AgentVera runs Claude Code, Codex, Gemini CLI and other CLI agents side by side in one window, so both pairing setups fit in one view.

- **[Workspace](/en/features/workspace/ "Workspace").** Put the writing agent and the reviewing agent in panes next to each other on the same project. Each agent has its own permission setting (Ask, Auto or Full access), so the writer can accept edits while the reviewer only reads.
- **[Auto approval](/en/features/auto-approval/ "Auto approval") (Pro and Team, Claude Code).** Reads, read-only git and test, lint and build commands are approved for you, while risky commands such as `git push`, `rm` or `git reset --hard` always come to you. That’s the “let it drive, but I own the dangerous parts” setup without clicking through every prompt.
- **[Notifications and approvals](/en/features/notifications-and-approvals/ "Notifications and approvals").** When an agent waits for you, a shortcut takes you straight to the one that has been waiting longest.
- **[Checkpoints](/en/features/checkpoints-and-replay/ "Checkpoints and replay").** Each turn is saved, so you can undo one step of a session without touching git history.
- **[Code review](/en/features/code-review/ "Code review").** At the end of a turn, a Claude model you choose reviews the changes and lists findings with severity and file:line, and you can send them back to the agent. That’s a built-in second agent in the navigator seat.
- **[Review inbox](/en/features/review-inbox/ "Review inbox").** Finished work waits as cards with the changed files, risk notes and diffs, where you approve it or send it back with a note.
- **[Agent messaging](/en/features/agent-messaging/ "Agent messaging").** Agents in the same project can message each other and share a task list, across different CLIs, so the writer can ask the reviewer directly.

## Wrapping up

AI pair programming works when the roles are clear. Decide who drives before each task. Set the approval mode to match the risk, not your mood. Keep steps small and commit after each green one. Read every diff before you accept it. Choose on purpose between delegating and learning. When you want a second opinion, let a second agent review while you stay the navigator.

If you want a long, step-by-step job to practise on, [migrating JavaScript to TypeScript with AI](/en/blog/migrate-javascript-to-typescript-with-ai/ "Migrate JavaScript to TypeScript with AI") is a good one: every step is small, and the compiler tells you when it’s done.

## Frequently asked questions

**What is AI pair programming?** It is working on code together with an AI coding agent the way two developers pair: one drives, writing the code, and the other navigates, setting the direction and reviewing each step. With an agent you can take either role.

**Should I let the agent run without approvals?** Only for work you can check cheaply afterwards: well-tested code, a clean git state and a task you understand. For unfamiliar code, migrations, security-sensitive parts or anything touching production, keep approvals on and review each step.

**How big should one step be?** Small enough that you can read the whole diff in a few minutes and explain it to someone else. One function, one bug fix or one file is a good size. If a step needs a long explanation, split it.

**Can I learn while pairing with an AI agent?** Yes, if you choose to. Ask the agent to explain its plan before it writes code, type the key parts yourself, and ask why it chose one approach over another. If you only accept diffs, you delegate the work but learn little.

**Can two AI agents pair with each other?** Yes. A common setup is one agent writing the code and a second one, often a different model, reviewing the uncommitted changes. You stay the navigator who decides which findings to act on.

---

**About AgentVera.** AgentVera is a desktop app for macOS, Windows and Linux, built by Solviera Teknoloji. It runs 18 AI coding agents (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) side by side, per project, in real terminals with the user's own CLI installs and logins. The free plan has unlimited agents. Download: https://agentvera.dev/en/download/ · Pricing: https://agentvera.dev/en/pricing/