Rethinking Pair Programming in the Age of AI
Why "pairing with AI" is harmful to your team and what to do instead
Senior dev: I’m so productive with AI, I just pair with it and ship a lot of code
I’m seeing a lot of this content on LinkedIn. At first, it just feels wrong. And after thinking it in depth, it is so wrong.
Imagine a junior on your team hearing seniors say they’re so productive pairing with AI, they can ship a lot of code by themselves now. Not only that, but now we use Claude Code subagents and agent teams, we can automate a lot of work!
I wouldn’t like to be a junior in that team. I would feel so anxious.
“So, if seniors are more productive with AI agents, how can I learn? Will the AI replace my job? Why do seniors prefer to just use Claude over spending time with us? What happens if I’m so slow compared to them? I’ll use Claude Code as seniors do, and open as many PRs as possible to show my impact.”
I cannot imagine what a junior might feel right now. Too late to learn the fundamentals without the “productivity” pressure, too soon to have the new practices well established.
If you’re a junior, please share your experiences in the comments. It will help others become aware of this problem.
And then, us as seniors, we decided to move our attention into AI agents, learn the new thing, and stop doing the necessary pairing to help them grow.
Pairing is Beyond Code
I discovered pair programming early in my career, but it wasn’t until I joined ThoughtWorks in 2017 that I fully understood its potential. Seeing it in practice really helped.
Pairing goes beyond writing quality code. It might feel like the obvious benefit, but it is way more.
This post isn’t about listing all the benefits—they’ve been shared many times—but here’s a short summary:
Knowledge sharing & skill development
Improved code quality
Enhanced problem-solving
Increased focus and accountability
Better team dynamics
Faster onboarding and reduced risk (no single person holding all the knowledge)
Mentorship and career growth
And more...
Without going in depth into each point, we can see that pairing is about human work: shared understanding, upskilling each other, and oiling the whole team dynamics to achieve high productivity as a team.
We pair in the benefit of the team over the individual. We help junior team members become the seniors of tomorrow. We focus on shared understanding of the business problem, reducing the bus factor, and ensuring more people have the necessary context.
The Problem: Seniors Are Abandoning Juniors
Here’s what’s happening in many teams right now:
Seniors discover AI agents and see massive productivity gains
Seniors stop pairing with juniors because “it’s slower”
Juniors feel pressure to use AI the same way, skipping fundamental learning
Juniors ship code they don’t understand, unable to debug or improve it
Knowledge gaps widen instead of narrowing
This isn’t theoretical. We’re already seeing juniors who can prompt AI well but can’t reason about code structure, debug issues, or make architectural decisions.
Rethinking Pairing in the Age of AI Agents
Pairing doesn’t mean we need to go back to writing all the code ourselves. It means delivering impactful work while learning the new practices that are just emerging.
We’re seeing this trend: developers need to focus on product impact, moving from low-level code to business impact decisions. From developer to product developer.
Something we expected from senior developers, not so much for juniors a few years back. Now that’s becoming the expectation.
As seniors, we had years to learn the fundamentals, then learn about the business. Today’s juniors no longer have this time. We’re asking them to go from 0 to impact.
So how can we help them reason better about product decisions, and how to make better judgments on AI outputs that sound confident—often with solutions better than their own on the first try?
Practical Guidelines for Senior-Juniour Pairing in the AI Era
Here are concrete things we can do while pairing with colleagues (and alone in some cases):
1. Reason Before the Prompt
AI agents can drive your thinking process. They put their ideas forward, and then it’s hard to move away from those. They poison your thinking.
Example: You want to add a discount calculation. Instead of asking AI immediately, first write down: “We need to calculate a 10% discount for loyal customers on orders over $50. This applies to the cart total before shipping.”
Then:
Write down/explain to your colleague the intention of the change, at product level
Find the key areas to introduce the change—navigate the code to find what needs to change
Debate first how the solution looks like, its pros and cons
My suggestion: spend time doing it manually until the person gains proficiency on reasoning about the business and navigating the code. Regardless if it’s adding a feature, an architectural change, or tests.
Remember that smaller steps always help. Sometimes we think seniors do bigger iterations, but when we do, we fool ourselves, mess everything up, and go back to smaller iterations.
In case of doubt, reduce the scope. Yet, make the iteration vertical sliced—see a product improvement, don’t focus on the architectural layer.
Concrete tip: Draw an architectural diagram (C4 model) of what’s being considered. This helps you and your junior colleague point to which areas need change.
2. Add at Least Some E2E Test for the Happy Path
You cannot trust AI output without proper testing. And asking the AI itself to add the test might fail on business expectations.
Example: If you’re building a checkout flow, write a Playwright test that adds an item to cart, applies a coupon code, and verifies the total is correct. Don’t let AI write this alone—you define what “correct” means.
Do an outside-in approach and add an e2e test. It can be UI-level with Playwright, or an API call if the change is only backend.
Whatever suits you, that test will be your guide in the session. While implementation might change, a good test suite prevents a green pipeline and broken production.
Concrete tip: Dedicate time to write tests manually, or with AI support, but you ensure the setup and assertions make sense from a business perspective.
3. Compare Your Plan with the AI Agent Plan
Set the AI agent in plan mode. This is essential to dedicate time understanding the differences between your plan and AI’s plan.
Once you have the first step done, ask the AI agent to do the work in two different ways:
Guided mode: Give your change plan, the implementation details, and let AI implement it. Verify it solves the business problem, store in a git branch.
Open mode: Give only the change intention, at product level, and let AI figure it out.
This is interesting because it gives you two perspectives and outputs.
Concrete example:
Branch
feat/tax-calc-guided-mode: You explain “calculate 5% tax for EU customers on cart subtotal”Branch
feat/tax-calc-open-mode: You say “add tax calculation for European customers”
Compare what each approach produces.
4. Compare Multiple Models
Decide which plan is best to solve the product problem and maintain good code quality.
You will see how each aims to solve the problem and the steps. But do not trust the first output—try multiple models and see how each reaches different solutions.
Store each result in different branches:
feat/tax-calc-guided-mode(your plan)feat/tax-calc-claude-opus-4-6feat/tax-calc-openai-codex-5-3
Debate the different outputs and which ones are better. Ask:
Did the model solve the right business problem?
Did it add technical debt? Code duplication? Is it reusing existing patterns or introducing new ones?
Are the tests good enough or are they superficial?
Pro tip: This is also excellent for mentoring—walk through the differences with your junior and explain why one approach might be better than another.
5. Do Code Reviews Together
Don’t just review PRs asynchronously. Schedule time to review together:
Walk through what AI generated
Identify areas needing refactoring
Discuss trade-offs made
Explain architectural decisions
This is where juniors learn to evaluate code quality.
6. Explicitly Teach Prompting as a Skill
Treat prompting like any other technical skill:
What makes a good prompt vs a bad one?
How to iterate on prompts based on output?
When to give more context vs less?
Model this behavior yourself.
What This Means for Team Leads and Tech Leads
If you’re responsible for team health, consider:
Don’t celebrate AI productivity in public channels if it makes juniors feel inadequate
Create space for juniors to learn fundamentals without “impact” pressure
Pair seniors with juniors specifically on AI-assisted work
Measure what matters: Are juniors growing? Understanding code? Making good decisions?
Conclusion
The phrase “pairing with AI” misses the point. You’re not pairing—you’re delegating. And when you delegate without mentoring, you create a generation of developers who can prompt but can’t think.
The real opportunity is using AI to amplify human connection, not replace it. Use AI to handle the mechanical parts so you have more time for the human parts: mentoring, reasoning, deciding together.
The best developers in 2026 won’t be the ones who prompt best—they’ll be the ones who still know how to think, and who can teach others to do the same.
If you’re a junior experiencing this, please share your story. It helps the industry understand what’s really happening.