AI pairing speeds up exploring options, boilerplate, and unfamiliar APIs, but automation bias, anchoring, and quiet skill erosion undo those gains fast.
Pair programming with another engineer works because two people bring independent judgment to the same problem. One drives, one navigates, and the value comes from a second brain catching what the first one missed before it becomes a bug. Pairing with an AI assistant borrows the rhythm, typing while it suggests, thinking out loud while it responds, but it is not the same relationship. The assistant has no stake in the outcome, no memory of yesterday's decisions unless you give it one, and a habit of sounding equally confident whether it is right or wrong. Treating it like a fast, tireless junior engineer gets you closer to reality than treating it like a peer.
That difference is an asset in some situations and a liability in others. An assistant that never gets tired or defensive is genuinely useful for the parts of programming that reward volume and exploration. The same traits work against you the moment nothing in the interaction reminds you to keep exercising your own judgment. This post separates where AI pairing earns its keep from where it quietly erodes the judgment it is supposed to support, and lays out concrete ways to stay the one actually driving.
What "pairing" means when your partner is a model
Traditional pair programming rests on an asymmetry that keeps both people honest: the driver writes the code, and the navigator, not looking at the keyboard, has the mental space to question it before it is finished. Swap the navigator for a model and that asymmetry does not disappear, it inverts. The model produces code far faster than a human navigator ever would, which means the questioning has to happen after the code already exists rather than before it is written. You end up reviewing constantly and deliberating in advance rarely, and after-the-fact review is a weaker check than a second opinion formed independently, before anyone has seen an answer.
That is not an argument against using it. It is a reason to stay explicit about which role you are in at any given moment. The model is very good at being asked and much less reliable to be trusted by default, and enforcing that distinction is entirely your job, not something the tool does for you.
Where AI pairing earns its seat at the keyboard
- Exploring options: surveying several ways to structure a function or model a schema, producing in seconds what would take many minutes to sketch by hand.
- Boilerplate and scaffolding: config files, CRUD handlers, and test fixtures that have one obviously correct shape and do not reward original thought.
- Unfamiliar APIs and libraries: a fast first pass at how a method signature or a language feature works, checked against the real documentation before you rely on it.
- Rubber-ducking a design problem: explaining the problem out loud forces you to state your assumptions plainly, and a clarifying question back can surface a gap in your own thinking before you write a line of code.
Rubber-ducking works because the articulation is the actual mechanism, not the answer you get back. A model with no memory of your codebase can still be a useful duck for a single sitting, but it starts from zero every time, re-asking questions you already answered yesterday and missing constraints nobody restated today. A persistent memory layer like MemX is built for exactly that gap, keeping architecture decisions, conventions, and past debugging context available across sessions, so the duck stops asking you to re-explain what you told it last week.
Automation bias and the confidence trap
Automation bias is the well-documented tendency to favor a suggestion from an automated system over your own judgment, even when your judgment is right and the system is not. AI coding assistants are a near-perfect setup for it: output arrives instantly, reads as syntactically clean, and is phrased with the same even confidence whether it is correct or subtly wrong. A Stanford study on AI coding assistants found that developers with access to one wrote measurably less secure code than a control group without it, and were simultaneously more confident their code was secure than the developers who had no AI help at all. The assistance did not just fail to catch the mistake. It made the people using it less likely to go looking for one.
The same trap shows up outside security. A randomized trial by METR gave experienced open source developers real tasks in codebases they already knew, with AI tools available for half the tasks and not the other half. Developers were about 19 percent slower when AI was available, yet afterward still believed it had made them faster. If experienced engineers cannot accurately judge their own speed while sitting inside the task, judging code correctness from a single read of a confident-sounding diff is at least as unreliable, and probably more so.
Sources: METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"
Anchoring on the first suggestion
Anchoring is a separate failure mode from automation bias, and it shows up even when you do not fully trust the model. Once a plausible solution appears on screen, it becomes the frame every alternative gets measured against, including the one you might have reached on your own. A study of how programmers actually work with Copilot found their interactions split into two distinct modes: "acceleration," where the programmer already knows what to do and uses the suggestion to get there faster, and "exploration," where the programmer is unsure and uses the assistant to survey options. The risk is mistaking acceleration mode for exploration when you are genuinely unsure. Accepting the first suggestion because it looks reasonable is not the same as having explored the space and found it best. It just means you stopped looking.
Before accepting a suggestion, say out loud, or type as a comment, why it is correct. If the only reason you can give is "it looks right," you are anchored on the suggestion, not evaluating it.
Silent skill erosion
The hardest backfire to notice is the one with no error message. Skills that used to get exercised daily, tracing a bug through an unfamiliar stack, working out the right data structure for a problem, recalling a library's API from memory, get exercised less often when a model is one keystroke away from doing it for you. Nothing breaks the day this happens. The debt stays invisible until the day the model is wrong, unavailable, or simply not part of the room, a code review, an on-call incident, a technical interview, and the muscle that used to handle this alone has not been used in months.
There is no rigorous longitudinal study yet measuring how much AI pairing erodes a specific engineering skill over time, so treat the mechanism as a hypothesis worth taking seriously rather than a settled number. What is well established is the general principle behind it: skills atrophy with disuse, and a tool that removes the need for repetition removes the repetition along with it. The fix is not avoiding the tool. It is deliberately keeping some reps: writing the tricky function yourself before checking what the model would have done, debugging without the assistant open for the first ten minutes, so the underlying skill stays live enough to catch the model when it is wrong.
The value of an AI pairing partner comes from being a second, independent perspective. The moment you stop forming your own opinion before you see its suggestion, you have not gained a partner. You have replaced your first opinion with its only opinion.
| Task | Where AI pairing helps | Where it backfires |
|---|---|---|
| Exploring an unfamiliar API | Surfaces a plausible method or pattern in seconds | Accepted without checking the real docs, and a hallucinated signature ships |
| Boilerplate and scaffolding | Removes typing time on well-understood, low-risk code | Skimmed rather than read, so a wrong assumption hides inside code that looks routine |
| Design rubber-ducking | Articulating the problem out loud surfaces gaps in your own thinking | A fluent, plausible-sounding answer gets mistaken for a validated one |
| Debugging a stack trace | Narrows the search space faster than reading the trace cold | You anchor on its first theory and stop testing alternatives that fit the evidence better |
| Writing tests | Speeds up mechanical test-case generation for known behavior | A self-generated test validates what the code does, not what it was supposed to do |
Keeping the human as driver and reviewer
Every failure mode above shares the same root cause: letting the model's output become the default and your own judgment become the afterthought, instead of the other way around. Reversing that is mostly a matter of sequencing, not willpower.
- Write your own approach in a sentence or a comment before opening the assistant, so you have a baseline to compare its suggestion against.
- Read every suggestion for what it does, not just what it appears to do. A two-hundred-line diff skimmed in ten seconds was never actually reviewed.
- Ask what would make this suggestion wrong before accepting it, especially when it looks obviously right.
- Keep an independent reviewer, human or a separate model given only the diff and the spec, between the assistant's output and anything that ships.
- Protect a portion of hard problems as no-assistant reps, on purpose, so the underlying skill does not quietly go unused.
That last point is the same principle TLM Forge applies at the process level rather than the individual one: a spec audited before code exists, an independent review pass that did not write the diff and is not motivated to defend it, and a gate that blocks shipping until critical issues hit zero. The habits above are what that discipline looks like inside a single pairing session. How to do agentic coding covers what it looks like across a longer, more autonomous task, and agentic coding vs vibe coding draws the line for when a quick, unreviewed pass is the right call and when it is not.
Frequently asked questions
01Is AI pair programming just autocomplete with extra steps?
No, though it is often used that way. Autocomplete finishes what you were already going to type. Pairing, done well, means the assistant contributes an option you had not considered, and you evaluate it as a separate opinion rather than a completion of your own thought. The difference is whether you formed a view before you saw its suggestion.
02How do you tell if you are anchoring instead of actually pairing?
If you cannot state, in a sentence, why a suggestion is correct beyond "it looks right" or "it compiles," you are anchored rather than evaluating. The test is not whether you eventually accept the suggestion. It is whether you could have argued against it if it had been wrong.
03Does using AI for boilerplate carry the same skill-erosion risk as using it for design work?
Less, generally, because boilerplate rarely needs judgment in the first place, so there is less judgment to lose. The exception is boilerplate you do not fully understand yet, like a new framework's conventions, where letting the assistant handle it every time means you never actually learn the pattern underneath it.
04What is the single highest-impact habit for staying in control?
Forming your own answer, even a rough one, before you look at the assistant's. It costs a few seconds and it is the difference between a second opinion and a first and only opinion. Everything else here is a variation on that one habit.