Working in Cursor
AI Pair Programming Best Practices: The Four-Mode Method
Ten AI pair programming best practices from daily production use, hung off one mental model: the four modes (driver, navigator, planner, reviewer).
TL;DR — AI pair programming pays off when it is run as a discipline, not a vibe: four modes — driver, navigator, planner, reviewer — and ten rules, all from daily production use.
AI pair programming works when it is run as a discipline and burns time when it is run as a vibe. This guide is the set of best practices we actually follow — on this site's own codebase and on client work — condensed into one mental model (the four modes) and ten rules. Every rule here comes from running the practice daily on production code, not from a demo.
What AI pair programming means (and what it doesn't)
AI pair programming is a tight, turn-by-turn loop between an engineer and an AI coding agent — Claude Code, Cursor, Copilot, Aider, or similar — in a shared workspace. The agent can read and edit files, run tests and shell commands; you see its reasoning and its diffs before they land, and you can interrupt at any point.
Three adjacent patterns get confused with it:
- Autocomplete — the model suggests the next few tokens, you accept or reject. No conversation, no plan. Useful, but not pairing.
- Chat-with-your-IDE — you ask, it answers, you copy-paste. Read access at best. Good for explanations, weak for shipping.
- Autonomous agents — the agent runs to completion without you in the loop. That is delegation, a different practice with different failure modes (covered below).
Pairing is the middle path: the agent has full repo access and can act, but you are present every turn, steering scope and approving meaningful changes.
The four-mode method
Every best practice below hangs off one mental model. In any working session, the human and the agent swap between four modes — and naming them is what lets you notice when you are stuck in the wrong one.
| Mode | Who types | Who checks | Right for |
|---|---|---|---|
| Driver | AI | You | Small, bounded tasks you can verify by reading the diff |
| Navigator | You | AI | Code you care about: auth, payments, migrations |
| Planner | Neither yet | Both | Any non-trivial change, before either of you codes |
| Reviewer | AI, autonomously | You | Mechanical multi-file work with a clear destination |
Driver mode is where beginners live and where most AI-induced production bugs come from: the agent happily produces plausible code that does not fit the surrounding system. Navigator mode — you write, the agent critiques every diff — is the most underrated of the four, because it catches review-grade mistakes before the code lands and never features in a demo video. Planner mode is the highest-leverage and the most skipped. Reviewer mode looks like delegation but stays inside the pairing frame because you read every line before merge.
AI pair programming best practices
1. Plan before any change bigger than ten lines
Before non-trivial work, produce a short written plan together: what changes, which files, what can break, what proves it works. Three to ten bullets in a scratch file is enough. The agent has good recall of the codebase; you know which constraints are real. The minutes spent planning are the cheapest in the whole session — they are what mid-session backtracking gets traded against — and most modern agents have an explicit plan mode that makes them cheap.
2. Default to navigator mode on code you care about
Anything user-facing or on the critical path — auth, payments, data migrations — write yourself, then have the agent review every diff before commit. You keep the design judgement; the agent supplies the tireless second reader.
3. Read every diff before merge, no exceptions
The better the agent gets, the easier it is to skip the read — and the more expensive the missed bug. A change the agent calls "done" with green tests can still stub the part it could not figure out. The discipline of reading every line before merge is the cheapest defence in this whole list.
4. Never let the agent write both the code and the tests
Tests written by the same source as the implementation are written to pass. Either you write the tests and the agent writes the code, or the reverse — the same separation-of-interests principle human teams already use, applied to the agent.
5. Restart drifting sessions instead of arguing with them
Long sessions forget constraints you set an hour ago — naming conventions, "don't touch the auth module", performance requirements. The symptom is slightly-off code followed by an apology followed by more slightly-off code. Don't argue. Start a fresh session pointed at a written brief (a dated plan file in the repo works well) and it picks up where you left off.
6. Scope the agent to named files
"You may only edit files matching X" in the working brief, plus small frequent commits. The single largest source of pairing-induced regressions is the agent making a "helpful" change in a file you never asked it to touch.
7. Ask "what did you skip?" after every long task
Capable models prefer declaring success over surfacing incomplete work. After any reviewer-mode run, ask explicitly: what is stubbed, what is fake, what did you not verify? The honest answer is almost never "nothing".
8. Pair against a verified contract, not against guesses
The structural failure mode: the frontend agent knows the frontend perfectly and knows nothing about what the backend actually returns. It will call /api/users/by-email when the real endpoint is /v2/users?email=, and you find out in staging, one deploy-and-DevTools cycle at a time. Extract the real contract — OpenAPI spec, schema, actual call sites — and put it in front of the agent before it writes a line. This is the problem AppHandoff was built to solve, but even done by hand the lesson stands: the pair is only as good as the contract it works against.
9. Bring the task — never ask the agent what to work on
The agent does not know your business priorities or customer commitments. Asked to choose, it picks interesting work, which is not the same as important work. You own the what; the agent helps with the how.
10. Measure cycle time and defect rate, not tokens
Two numbers tell you whether the practice is working: time from ticket-open to deployed, and how often a change is reverted or hot-fixed within days of shipping. Pairing should compress the first without inflating the second; if PR review time is climbing instead, the agent is producing bigger diffs than the team can absorb — tighten scope. "Lines of AI-generated code" and "tokens spent" are vanity metrics.
When to delegate instead of pair
Pairing is not the right mode for everything.
- Delegate to an autonomous agent when the task is well-bounded, success is easy to verify, and the cost of getting it wrong is low: dependency upgrades with passing tests, doc regeneration, porting a test suite.
- Pair when the task is novel, success criteria are partly emergent, or the cost of a mistake is high. Most product work lives here.
- Go solo when time-to-prompt exceeds time-to-type. Renaming one variable does not need an agent.
Most teams over-pair and under-delegate. Where delegation is taken to its limit — one operator supervising many agents in parallel — the same review disciplines still apply, just at fleet scale; we have documented that end of the spectrum in 99 PRs in 24 hours and one operator, 52 PRs across 11 repos in a day. Pairing is where you build the judgement those setups depend on.
Introducing the practice to a team
The two failure modes are mandating it and banning it. Mandating forces non-fluent engineers into driver-mode-only and ships bad code; banning drives the engineers already using it underground and loses the institutional knowledge. What works: let one or two visibly fluent engineers demonstrate on real PRs, write down the local conventions (which agent, which modes for which tasks, what the agent never touches), and let adoption spread by demonstration — then retro on it specifically after a few weeks.
FAQ
Is AI pair programming the same as vibe coding?
No. Vibe coding is letting an agent run on an unclear task with no plan, tests, or review. Real pairing is mode-disciplined, plan-driven, and review-gated.
Which tool should I start with?
Terminal-first: Claude Code. IDE-and-frontend-first: Cursor. Organisation standardised on GitHub Enterprise, where admin controls and compliance tooling weigh more than raw model choice: GitHub Copilot. Open source or bring-your-own model: Aider or Continue. Pick one and use it for a month before evaluating a second — fluency with one tool beats familiarity with four. Full comparison: the best AI coding assistant in 2026.
Will it replace human pair programming?
For most teams it largely has, except where human pairing was never about the code: onboarding juniors, hairy incidents, mentorship. An agent does not teach you to be a better engineer the way a senior pair does. Mix the two.
If the bottleneck on your team is the working practice rather than the model or the tooling, that is the kind of engagement we take on — start at /hire-ai-developer or /fractional-cto.