TL;DR: Pair programming with AI means running a four-phase loop (plan, implement, verify, review) instead of one long unstructured chat. Plan before code gets written, implement in reviewable chunks, verify with something other than your own eyes, and review the diff like a stranger wrote it. The loop produces the speed gain, not the model alone.
What does pair programming with AI actually mean now?
It means treating an AI coding tool the way a disciplined human pairing partner would be treated: someone proposes an approach, someone implements it, and both check the result before it ships. What changed from a decade of two-human pair programming is that one half of the pair now writes at machine speed, never gets tired, and never says "wait, are we sure about this" unless you build that question into the process yourself.
The classic pairing setup split a driver, who typed, from a navigator, who thought one step ahead and caught mistakes in real time. An AI coding assistant can do both roles at once, which sounds like an upgrade until you notice the failure mode it introduces: nobody is left playing navigator. Anthropic's own description of its coding agent states the shift plainly: "Claude explores, plans, and implements." That is a description of capability, not of judgment. The method below exists to put a navigator back into the loop, deliberately, at four fixed points rather than hoping good instincts show up on their own.
The four-phase loop: plan, implement, verify, review
The loop runs the same regardless of which model or tool sits on the other side of it.
| Phase | You do | The AI does | What closes the loop |
|---|---|---|---|
| Plan | State the goal, the constraints, and which files are in scope | Proposes an approach before touching any code | A plan short enough to approve or edit in one read |
| Implement | Approve the plan, or redirect it before code is written | Writes the smallest diff that satisfies the approved plan | A change small enough to review in a single pass |
| Verify | Point at a test, a build, or a script that returns pass/fail | Runs the check and reports the result | A signal that isn't your own eyeballing of "looks right" |
| Review | Read the diff as if a stranger wrote it, or assign a fresh session to | Sees only the diff and the criteria, not its own reasoning | Findings that either block the change or get filed as follow-ups |
Skip any one phase and the loop degrades into exactly the thing it's meant to prevent: a single unverified pass that either you or the model has to trust blind.
Why plan before you let anything touch code?
Because a tool that jumps straight to implementation can confidently solve the wrong problem, and a fluent, working-looking diff gives you no signal that it happened.
Anthropic's Claude Code documentation states the risk in one sentence: "Letting Claude jump straight to coding can produce code that solves the wrong problem." Its recommended four-phase workflow (explore, plan, code, commit) separates research and planning from implementation for exactly that reason, and its own guidance is explicit that this step is not free: "Planning is most useful when you're uncertain about the approach, when the change modifies multiple files, or when you're unfamiliar with the code being modified."
The plan itself does not need to be elaborate. State the goal, the constraint that matters (an existing API contract, a performance budget, a file you must not touch), and ask for an approach before any code exists:
We need to add rate limiting to the /api/upload endpoint.
Constraint: existing clients must keep working with no config change.
Constraint: do not touch anything outside src/api/upload/.
Propose an approach before writing any code. List the files you'd change
and why, and flag anything you're uncertain about.
Read the plan the way you'd read a colleague's design doc: not for style, but for whether it solves the problem you actually described.
How small should each AI-implemented change be?
Small enough that you can hold the entire diff in your head and explain it back in one sentence — not defined by a line count, but by whether review at the next phase is still honest.
A large, multi-file diff generated in one pass defeats the next two phases before they start. Verification against a test suite tells you the whole thing didn't break something it touches, not which of the twelve changed files caused a given failure. Review of a five-hundred-line diff turns into skimming, and skimming is where a plausible-looking mistake survives. Chunking by the unit of the approved plan — one file, one function, one endpoint at a time — keeps both checks meaningful, and it keeps the context window the model is reasoning over smaller too, which independently reduces the odds of it losing track of an earlier constraint mid-change.
The practical rule: if the plan named three files, ask for three implementation passes, each with its own verification, rather than one pass across all three.
What counts as verification for AI-written code?
Anything that returns a pass or fail you didn't produce yourself by reading the code and deciding it looks right. A test suite, a build's exit code, a linter, or a script that diffs real output against a known-good fixture all qualify. A sentence of the form "yes, that looks correct" does not, because it's the same judgment that already produced the code in question.
Anthropic's Claude Code guidance frames the underlying problem directly: "Claude stops when the work looks done." Without an external check, "looks done" is the only signal in the room, and every mistake waits for a human to notice it by hand. The fix it recommends is mechanical: "Give Claude something that produces a pass or fail, and the loop closes on its own." In practice that means asking for the check in the same message as the task, not as an afterthought:
Write a validateEmail function.
Test cases: user@example.com is true, "invalid" is false, user@.com is false.
Run the tests after implementing and show me the output.
That last sentence, "run the tests after implementing," is doing the real work — it turns an assertion into evidence. Ask to see the test output, the exit code, or the screenshot rather than a summary of it; a one-line "all tests pass" claim is exactly the kind of unverifiable assertion this phase exists to replace. Anthropic's own framing of the failure mode this catches: "Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it." The debugging prompt library is a useful companion once a check does fail and you need to trace why.
Who should review the diff — you, another model, or both?
Both, but for different failure modes. A fresh-context review, human or AI, catches the plausible-but-wrong output that a same-session model won't flag, because it never argued itself into producing that output in the first place. An automated code-review tool catches a narrower, more mechanical set of issues, and its own vendor is explicit about the ceiling on that.
Anthropic's guidance on this step: "A reviewer running in a fresh subagent context sees only the diff and the criteria you give it, not the reasoning that produced the change, so it evaluates the result on its own terms." That's the mechanism worth copying even without the specific tool: assign the review to a fresh conversation, hand it only the diff and your criteria, and withhold the reasoning that produced the change.
Review this diff against the plan below. Check that every requirement is
implemented, that the listed edge cases have tests, and that nothing outside
the task's scope changed. Report gaps only, not style preferences.
GitHub is candid about the same ceiling on its own Copilot code review feature: "Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes. Always validate Copilot's feedback carefully. Supplement Copilot's feedback with a human review." Its documentation also lists what the feature never even looks at — dependency management files such as package.json and Gemfile.lock, log files, and SVG files are excluded from review entirely. An automated reviewer is a filter, not a verdict, and knowing what it silently skips matters as much as trusting what it flags. For prompts that get more out of that step specifically, see how to prompt for a genuinely useful code review and the broader code review and debugging prompt set.
Does this actually make you faster, or does it just feel faster?
It depends heavily on the task and on whether the loop above was actually run, and the two best-known controlled studies on this question reached opposite headline numbers because they measured different things.
GitHub ran a controlled experiment in 2022: 95 professional developers, split randomly into two groups, timed on writing an HTTP server in JavaScript, one group with Copilot and one without. The result, in GitHub's own words: "developers who used GitHub Copilot completed the task significantly faster–55% faster than the developers who didn’t use GitHub Copilot." The developers using Copilot averaged 1 hour 11 minutes against 2 hours 41 minutes for the control group, a statistically significant result. That is a short, well-specified, greenfield task measured mostly as raw completion speed — closer to accelerated autocomplete than to the full plan-verify-review loop described here.
METR's 2025 randomized controlled trial measured something different: 16 experienced open-source maintainers, working on 246 real issues in their own large repositories (codebases averaging 22,000+ stars and a million-plus lines of code), each issue randomly assigned to allow or disallow AI tools. The finding: "they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts." The gap between belief and result is the part worth sitting with: "developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%." Experienced developers, working in code they knew well, felt faster while measurably running slower — which is close to a textbook description of the trust-then-verify gap the four-phase loop is built to catch.
METR later flagged its own follow-up data as compromised: a February 2026 update on the same research line reported that participant self-selection (developers increasingly declining to work without AI at all) meant the newer numbers "gives us an unreliable signal of the current productivity effect of AI tools." Treat the original 19%-slower finding as the well-supported result and the follow-up as inconclusive, not as a quiet reversal.
Neither study is wrong. They measured different populations doing different kinds of work under different conditions, and citing either one alone to settle "does AI make you faster" launders a specific, narrow finding into a universal claim it was never built to support. What the two studies agree on, read together, is that raw output speed and verified output speed are not the same measurement — which is the entire argument for running verify and review as separate steps rather than trusting the plan-to-implementation speed on its own.
How do you keep the loop from being rebuilt every session?
By saving the four prompts you actually reuse — the plan prompt, the verify prompt, the review prompt, and the project-specific constraints that don't change week to week — as templates instead of retyping them from memory every time you sit down.
Most of what breaks this method in practice isn't the four-phase structure; it's that nobody keeps the phase-specific prompts anywhere, so each session reinvents them slightly worse than the last. A saved "review this diff against the plan, report gaps only" template stays exact across sessions. A remembered approximation of it drifts. Prompt Architects' reusable prompt variables approach is built for exactly this: fill in the file path, the constraint, or the task once as a variable, and reuse the surrounding prompt structure across every project rather than hand-editing it each time.
When this method doesn't apply
The loop assumes the model is a legitimate participant in the task at all, and that assumption doesn't always hold. Security-critical code, genuinely novel algorithms, and work in a domain neither you nor the model understands well are a different problem with a different answer, covered separately in when not to use AI for code rather than re-argued here. No amount of planning, verifying, or reviewing rescues a task where the underlying risk assessment was wrong from the start. The loop earns its keep most clearly on the unglamorous middle ground: refactoring legacy code safely, where the plan phase forces you to state what must not change before anything does.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.
Create An AccountWhere Prompt Architects fits, and where it does not
Straight answer, because the four phases above happen in your editor and your terminal, not inside a prompt manager. Prompt Architects doesn't write your plan, run your tests, or review your diff — there's no coding agent here, and no claim that there is one.
What it does hold is the layer around those phases: an MCP server at https://mcp.prompt-architects.com/mcp that Claude Code, Cursor, Claude Desktop, Claude.ai, Codex and Codex CLI can connect to directly, exposing improve, refine, shorten and enhance tools so the plan prompt or the review prompt you're about to send gets tightened without switching windows, plus a saved template library and global variables so the prompts in this post don't get retyped from memory next week. It's a detail worth noting from our own usage data: customers who connect that MCP server are disproportionately our highest-engagement users, which tracks with the pattern above — the people getting real value are the ones who reuse a method instead of starting cold every session.
That's the honest boundary. The loop is yours to run. We help make sure the four prompts inside it don't degrade every time you open a new chat.