AI Pair Programming: How Senior Engineers Work With AI

AI pair programming is the part of AI-native engineering that looks the most like the old job and is the most quietly different. You still sit with a partner, talk through the problem, and write code in a back-and-forth. The partner is just a model now. Most of what gets written about this is either a productivity fantasy or a doom post, and neither helps if you actually pair with AI every day. The honest version: it genuinely speeds up some work, it confidently produces wrong and insecure code, and the difference between the two is entirely in how the human runs the session. This piece covers what AI pair programming actually is, the driver-navigator model with a model in one seat, a real session step by step, where it shines, where it fails and how senior engineers catch it, and the habits that make it work.

What AI pair programming is

AI pair programming is working with an AI coding tool as your programming partner rather than a human one, in a continuous back-and-forth where one of you writes and the other reviews and steers. It is not handing off a task and collecting the result later. It is the running conversation: you propose, the model responds, you correct, it revises, and the loop stays tight enough that you are always in the code together.

That framing borrows directly from human pairing, which has had a name and a shape for two decades. In the practice formalized by Extreme Programming and laid out in Laurie Williams and Robert Kessler's Pair Programming Illuminated, two engineers share one task in two roles: the driver has the keyboard and writes code, while the navigator watches, catches mistakes, and thinks one step ahead about the direction. AI pairing keeps the roles and swaps one of the seats. The new question is who drives.

It helps to put it next to the other ways people work with AI, because the words get used interchangeably and they are not the same thing.

• Versus human pairing. Two people pairing bring two sets of judgment, shared accountability, and a side channel of mentoring and design talk. An AI partner brings none of those and a different set of strengths: it is always available, never tired, has read far more code than any colleague, and will draft a function faster than you can describe it. You trade a second human's judgment for a tireless, fluent, and occasionally confidently wrong assistant.
• Versus vibe coding. Vibe coding is the mode where you stop reading the output and accept code by whether it runs. Pairing is the opposite posture: the whole point is that you stay in the loop and keep reading. Vibe coding is fine for a throwaway prototype. Pairing is how you work when the code has to be understood and maintained.
• Versus agentic coding. Agentic coding hands a whole, well-scoped task to an agent that plans, edits across files, and verifies itself in a longer loop, while you review the plan and the final diff. Pairing is more continuous and more hands-on: you are present for the turns, not only the bookends of the task. The two blur at the edges, and good engineers move between them depending on how much they trust the task to run unattended.

Laid out side by side, the difference is how close you stay to the code:

AI pair programming is not handing work to a model and grading the result. It is staying in the loop with it, turn by turn, and never letting it merge something a human does not understand.

The reason this matters as its own practice is that the skill is not "prompting." It is the old reviewing-and-steering skill of a navigator, applied to a partner that types faster than anyone and is wrong in unfamiliar ways. That is a learnable craft, and it is the one this article is about.

The driver and navigator model, with an AI

The most useful way to think about pairing with AI is to ask, in any given moment, which of you has the keyboard. The roles are the same as human pairing. What changes is that you can flip them mid-session, instantly, in a way two humans never could.

When the AI drives, it generates the implementation and you do the navigator's job: read what it produces, catch the tactical mistakes, and watch the strategic direction. This is the mode for boilerplate, scaffolding, an unfamiliar API, or a first draft of something you will reshape. You describe the outcome, the model writes it, and you stay alert for the wrong-but-plausible. The risk is the navigator's classic failure: going quiet, letting the driver run, and waking up to a tangle you now have to understand from scratch. With an AI driver that produces code at speed, the temptation to stop watching is stronger and the cost of giving in is higher.

When you drive, you write the code and the AI navigates: an inline suggestion completing your thought, a flag on the edge case you skipped, a different approach offered in the margin. Modern AI-native editors put the model in this seat by default. It is lower-risk, because you are reading and writing every line, and it is where a lot of the day-to-day value lives. The model is a navigator that has seen the bug before, the standard-library function you forgot, the off-by-one you are about to commit. You keep authorship; it keeps you honest.

The senior move is flipping deliberately. Let the AI drive the dull, well-understood, easily-verified parts. Take the keyboard back the moment the work gets subtle, security-sensitive, or deep in a system the model cannot see. The role you never give up, in either mode, is the navigator's judgment, because the human is the only one in the pair who can actually stand behind the result. The keyboard moves. Accountability does not.

A real session, step by step

Abstractions only get you so far. Here is what a single, ordinary AI pairing session looks like, the kind that happens dozens of times a week on a real team. The task: add rate limiting to an existing API endpoint.

1. Set the task and the context. You do not open with "add rate limiting." You point the model at the actual code: "We rate-limit by API key elsewhere in src/middleware. Add the same pattern to the /v1/export endpoint, 100 requests per minute per key." The model can only reason about what it can see, so the session lives or dies on what you put in front of it. A vague prompt with no context gets plausible code that fits nothing around it.
2. Let it draft, and read while it does. The AI takes the driver's seat and writes the middleware. You read it as it lands, the way a navigator watches the road, not as an after-the-fact review, already asking the right questions: is it reusing the existing limiter, where is the counter stored, what happens when the limit trips.
3. Catch the wrong-but-plausible. It compiles. It also stores the counter in memory, which silently breaks the moment the service runs more than one instance, and returns a bare 429 with no Retry-After header. Neither is a syntax error. Both are exactly the confident, runs-fine mistake a human stays in the loop to catch.
4. Steer specifically. "It doesn't work" gives the model nothing. "The counter has to survive across instances, use the Redis client from src/cache" gives it a fix. The quality of your steering is the quality of the result, and the model reads the correction and revises. This is the navigator-to-driver conversation, just faster.
5. Close the loop on a real check. You do not eyeball it and merge. You ask for a test that proves the behavior: a request that passes under the limit, one blocked over it, one confirming the counter is shared. The test turns "looks done" into "is done." If the model wrote the test, you read that carefully too, because a test that asserts the wrong thing is worse than none.
6. Read the final diff, then decide. Before anything merges, you read the whole change as one diff, in your own context, as if a junior had handed it to you. You are the reviewer of record. If you understand it and stand behind it, it merges. If you do not, it does not, no matter how good it looks.

The whole session took fifteen minutes instead of forty. None of the speed came from skipping the review. It came from the model doing the typing and the first draft while a human did the part a human is for: knowing that an in-memory counter is a bug, that a 429 needs a Retry-After, and that nothing merges until someone understands it.

Where AI pairing shines

AI pairing earns its keep on a recognizable class of work: tasks where the context is in the code rather than in your head, where "done" is easy to check, and where the cost of a first draft being rough is low. The research backs this up sharply. A controlled GitHub study found developers completed a greenfield HTTP server 55% faster with an AI pair programmer, finishing in about 1 hour 11 minutes against 2 hours 41 minutes without, a statistically significant gap. Greenfield is the key word: there was no existing system to misread, and the work was the kind AI does best.

The patterns where it consistently helps:

• Boilerplate and scaffolding. The CRUD endpoint, the form, the config, the test harness, the fiftieth variation on a shape the model has seen ten thousand times. This is pure typing you would rather not do, and the AI driver does it in seconds while you read along.
• Unfamiliar APIs and languages. Working in a library or a language you do not know cold is where an AI navigator shines. It has read the docs you are about to search and knows the idiomatic call, so you learn from a working example instead of a blank page.
• Exploration and first drafts. When you are not sure of the shape yet, letting the AI draft a few rough versions to react to beats getting the first one perfect in your head. You use it to think, then take over once the direction is clear.
• The stuck moment. A second opinion on a bug, a rubber duck that talks back, a different angle when you have stared at the same error for twenty minutes. The model is a tireless pair that has, statistically, seen something like your problem before.

What these share is the property that makes AI pairing safe and fast at once: the context lives in the code the model can read, and you can cheaply verify the result. When both hold, the AI doing the typing is close to free speed.

Where it fails, and how seniors catch it

This is the section the demos skip, and it is the reason the human seat is non-negotiable. AI pairing fails in specific, repeatable ways, and the value a senior engineer adds is catching them before they ship.

The failure modes that recur:

• Confidently almost-right. The most common and most dangerous one. The 2025 Stack Overflow Developer Survey found the single biggest frustration with AI tools is output that is "almost right, but not quite," cited by 66% of developers, and 45% said debugging AI-generated code took more time than expected. The model states a wrong answer with the same fluent confidence as a right one. There is no tell in the tone. A senior catches it by reading the code, not the vibe, and by never treating fluency as correctness.
• Runs but insecure. Code that works in the happy path can still carry the SQL injection, the missing auth check, the unvalidated input. The model optimizes for "works," and a navigator who stopped watching does not catch the flaw the model cheerfully introduced. This is why senior pairing keeps security review and scanning in the loop, treating "it ran" as the start of the check, not the end.
• Deep-system blindness. The model can only see what is in context. On a change buried in a large system whose constraints live in a person's head, it is guessing, and it guesses confidently. This is precisely the case where AI goes negative. A 2025 METR randomized controlled trial on experienced developers, working in repositories of over a million lines they knew deeply, found AI made them 19% slower, even though the same developers had forecast a 24% speedup and still believed afterward it had helped. The senior move is recognizing this case and taking the keyboard back, rather than fighting the model through a problem only the human can actually see.
• The throughput-stability trap. Faster code is not automatically better software. Google's 2024 DORA report found that a 25% rise in AI adoption was associated with an estimated 7.2% drop in delivery stability, even as individual productivity ticked up, because more code shipped faster means bigger changes and more ways to break. Seniors counter this by keeping the discipline that AI tempts teams to drop: small changes, real tests, fast feedback.

The thread through all four: the model is a brilliant, fast, fluent junior that has read everything and understood nothing about your specific system, and it never says "I'm not sure." A senior engineer supplies exactly what it lacks, which is judgment about what is actually correct here. The perception gap in the METR study is the warning. Developers felt faster while being slower, because the output looked done. Feeling and reality come apart precisely when you stop checking, which is the one thing the human seat exists to prevent.

Habits that make AI pairing work

The engineers who get real value from AI pairing are not the ones with the best prompts. They are the ones with a handful of disciplined habits, most of which are just good engineering pointed at a faster, less reliable partner. These line up almost exactly with what Anthropic's own Claude Code best practices recommend, which is unsurprising: the people who build the tools pair with them all day.

Give it a way to verify its own work. The highest-leverage habit. A test, a build, a linter, a script that diffs output against a fixture: anything that returns a pass or fail the model can read. With a check in the loop, the model does the work, runs the check, reads the result, and iterates until it passes, instead of stopping at "looks done" and leaving you as the only thing that notices the bug. If you cannot verify it, you should not ship it.

Correct it early and often. The best results come from tight feedback, not from letting a wrong approach run and fixing it at the end. The moment you see the model heading somewhere bad, stop it and redirect. If you have corrected it twice on the same thing and it is still wrong, the context is polluted with failed attempts. Clear it and restart with a sharper prompt that folds in what you just learned. A clean start with a better instruction beats a long thread of accumulated corrections almost every time.

Feed it your actual context. Output quality tracks context more than anything else. Point the model at the real files, the existing patterns, the constraint that matters, rather than describing them from memory. "Follow the pattern in HotDogWidget to build the calendar widget" gets code that fits; "build a calendar widget" gets a plausible stranger. Teams that pair well invest in giving the model their conventions and architecture once so the generated code matches the system instead of fighting it. It is also why tool choice matters more than the demo suggests: the right partner is the one that can see the most of your context, which is the lens we use in our breakdown of the AI coding tools landscape.

Read every diff before it merges. This is the one rule that turns AI pairing from a liability into a tool. You can let the model write all of it. You cannot let it merge without a human understanding what changed. Reviewing AI-written code in a fresh context, ideally not the same session that wrote it, is its own skill, and it is the skill that separates senior AI use from junior. A reviewer who only sees the diff and the requirements, not the reasoning that produced it, catches what the author missed.

Keep a human owning the architecture. Let the AI fill in functions. Do not let it decide the shape of the system. A person holds the design, makes the structural calls, and uses the model to execute them. This is the line between a coherent system and a pile of locally-optimal files that each made sense alone. It is also, not coincidentally, the kind of engineer we hire: one who directs AI through real work and stands behind the result, rather than one who has handed the judgment over.

The pattern across all five is the same one that runs through every honest account of building with AI: the model generates, the human decides. The speed is real and it lands precisely because the team kept the parts that careless AI use throws away. That judgment, knowing when to let the model drive and when to take the keyboard back, is the craft of the modern AI software engineer, and it is the part worth getting right.