The dominant story in software development right now: AI writes the code, developers review the output, everyone learns to write better prompts. The developer becomes a prompt engineer, or optional, depending on who is telling the story. Either exciting or threatening. Either way, the same story.
I don't buy it. Not because I'm worried about being replaced. I'm not. But because it misses the more interesting thing happening on the other side of the screen.
If all AI does is write your code for you, where is the thinking? Where is the design work, the edge case discovery, the moment you realise the approach you started with was wrong? Where is the fun in that?
The better frame is not automation. It is AI pair programming.
What pair programming actually is
Not the version where two people take turns at a keyboard. The real thing: a partner who pushes back on your ideas, proposes a different approach, catches what you missed, and argues for a different design when they think yours will not hold. Kent Beck formalised pair programming in Extreme Programming because the feedback loop produces better software. The research on that is consistent.
The honest objection to pair programming has never been about quality. It has always been about cost. Two developers, one piece of work. That is expensive. That is why most teams do not do it consistently, even when they know it works. You reserve it for the hard problems and the onboarding sessions, and the rest of the time each developer works alone.
AI pair programming removes that objection. You get the full feedback loop without a second salary attached to it. The partner is always there, always free, and never pulling someone away from their own work.
Most senior developers have had one or two genuinely good pair programming sessions. You know what it feels like. Faster decisions, better ideas, less time reasoning in circles, more confidence when you commit to a direction. The partner is the thing. That feeling used to be expensive. Now it is not.
What AI pair programming actually feels like
A simple example. When I am stuck on naming something, a variable, a class, a concept that resists clean description, I ask: "Give me five better names and pick the best one and explain why." Simple. But notice what you get: options, a recommendation, and a reason. You can agree, push back, ask for five more with a different constraint. "I do not like option two but the reasoning was right. Try again with that framing." The back-and-forth is the thing.
The same pattern scales to anything. "Propose multiple solutions for this feature and pick the best one and explain why." Sometimes I implement all of them and compare. The cost of trying the alternative is almost always lower than the cost of debating it in theory.
A real session looks like this: you have a problem, you propose an approach, the AI extends it or pushes back, you argue, you try it, you find an issue, you debate whether to fix it or rethink the design from a level up. That is not delegation. That is collaboration.
This is also what good pair programming has always been about: not the mechanics of who holds the keyboard, but the quality of the thinking that happens between two people engaged with the same problem.
The key difference from pairing with a human: AI is always available, it never gets frustrated at the fifth iteration, and the implementation is fast enough that trying something is almost always cheaper than reasoning about it abstractly. That last point changes what you are willing to try. When re-implementing is cheap, you stop arguing about things you could just test.
Plan mode: where AI pair programming gets interesting for architects
For software architects, AI pair programming has a specific use worth its own section.
I use plan mode heavily before any implementation starts. The pattern is this: build the implementation plan in detail first. Then review it. Ask hard questions. What happens when the input is null? What is the retry behaviour? What does this look like in six months when the schema changes? Probe the assumptions. Work through the edge cases. Push until the plan either holds up or breaks. Only when it holds under that kind of questioning, when the corners are covered and the answers make sense, does it get approved for implementation.
This shifts AI from "thing that writes code" to "thinking partner at the design level, before any code exists." The questions you ask reveal what the plan is missing. The gaps surface during the review, not during a late-night debugging session. It is like having a senior reviewer who never gets impatient and always has time to work through one more scenario.
Then there is the level above that.
When a design choice is genuinely unclear, two viable approaches and you are not sure which holds up better, implement both. Before AI, that was expensive. Days of work. You would reason it out on a whiteboard, pick a direction, commit, and hope your reasoning was right. Now it is an afternoon.
Real code tells you things the whiteboard does not. Hidden complexity in approach A. A clean seam in approach B that makes testing elegant. Something neither option revealed until you ran it against actual data and saw what the logic looks like in practice. You make the design decision from real implementations, not theoretical projections.
That is not incrementally better than whiteboard reasoning. It is a different category of thing. You stop committing to directions you have only imagined. You stop arguing about trade-offs you have not measured. You just try it.
The boring parts are not the story
Yes, AI handles the tedious work. Boilerplate, test scaffolding, repetitive type mappings, migration scripts. I delegate those without guilt.
But that is the prerequisite, not the story. Clearing the boring work creates headspace for the sessions where the real thinking happens. The automation of the tedious parts is not what makes the work better. The collaboration on the hard parts is.
And it never gets tired of me
A real pair programmer gets frustrated when you push back five times on the same design decision. They sigh. They suggest you just go with it. You feel the social cost of one more iteration.
I can be pretty stubborn.
And it never gets tired of me.
