When I was in Atomic Object’s Accelerator program, I paired constantly. As I moved on to smaller projects and earned more trust, pairing slowly faded out of my day-to-day, and AI agents filled the gap. Then I was asked some specific questions about code I’d recently written. The code worked, but I couldn’t explain why it worked the way it did.
Honestly, it was embarrassing. The agent had quietly gone from a tool I used after thinking something through to the place where my thinking started. I was shipping, but I wasn’t learning at the same pace I was before. The answer I keep coming back to is one I’d let fade: pair programming.
Same Output, Different Judgment
At LDX3 in New York this year, Giordano Scalzo gave a talk called “Tackling the Junior Developer Crisis in the Age of AI” that put a name to what I’d been feeling. His talk was aimed at juniors, but I’d argue it applies to all of us.
One line from Scalzo’s talk stuck with me: “Same output, different judgment.” AI makes everyone’s output look about the same. A PR from someone who really explored the problem and a PR from someone who pasted the ticket into an agent can look nearly identical. The difference shows up later, when something breaks, when you have to demo it, or when a client asks why you built it that way.
As consultants, that last one matters a lot. Clients aren’t paying us for keystrokes. They’re paying for judgment. We need to be able to explain trade-offs, demo our work confidently, and own what we ship. An agent can write the code, but it can’t stand in front of the client for you.
The Ladder Is Missing a Few Rungs
Scalzo framed the problem around three patterns from Apprenticeship Patterns, a book on how developers learn their craft:
- Be the Worst: surround yourself with people who know more than you and absorb as much as you can.
- Breakable Toys: build small, safe things where failing is part of the point.
- Sweep the Floor: volunteer for the humble tasks nobody else wants, and learn the system along the way.
Then he showed what happened to each one. Be the Worst became “you are alone in the room.” With hybrid work and an agent always available, it’s easy to go a whole day without solving a problem alongside another person. Breakable Toys became “the agent fills in the answer before you get the chance to fail.” And Sweep the Floor? “We bought a Roomba.” The grunt work we used to learn from is exactly the work agents are great at.
You could read that as a junior developer problem, but I don’t think it is. In consulting, every new project puts you back at the bottom of the ladder. New codebase, new domain, new client. Whatever your experience, you’re learning again, and those rungs still matter just as much.
His summary hit home for me: “Hybrid work took the desk. AI took away the friction.” Pairing is how we put both back.
Pilots Have Seen This Before
Scalzo also told the story of Air France Flight 447. When ice crystals blocked the plane’s speed sensors, the autopilot disconnected, and the crew had to fly by hand at high altitude, something they rarely practiced. In the six months before the crash, the captain had logged 346 hours of flying, and only two of them were flown manually. The accident report found that training hadn’t made up for that missing practice. Today, airlines require manual flying training.
Our stakes are much lower, thankfully. But the lesson carries over. Skills you don’t practice fade, no matter how experienced you are. Pairing is our version of that manual flying practice.
How This Changes How We Pair
My colleague Patrick Pale already made a great case for why we should keep pairing even with LLMs, so I won’t repeat it here. What I want to add is how pairing should look now that there’s a third participant in the room, one that types faster than both of us. Some of these come from my own experience, some come from Scalzo’s talk, and one is something I’m still itching to try.
Think First, Then Prompt
Scalzo runs an “AI-Off” exercise in his workshops. Before anyone opens the agent, spend 10 to 15 minutes writing out the plan in plain sentences, not code. What does this do for the user? Which states matter? Which edge case bites first? What are we least sure about? “We don’t know yet” is a perfectly good answer.
I do a lighter version of this. Before I open the agent, I sketch out a rough game plan with my tech lead. It’s usually pretty vague, just the general approach and the pieces I think are involved. Then I bring that plan to the agent and work with it to fill in the details and turn it into a task checklist. The agent is great at the details. But the direction came from two people talking it through first, and that’s the part I don’t want to hand off.
Use the Agent as a Sparring Partner
Scalzo was honest about what didn’t work in his workshops, and treating AI as an oracle was at the top of the list. What worked was treating it as a sparring partner. Instead of asking the agent for a solution, ask it to critique yours. Then talk it through together. What did we catch that the agent didn’t? What did the agent catch that we missed?
Say the Decision Out Loud
At the end of a decision, finish this sentence: “We’re picking X because Y. We’re rejecting Z because W.” It sounds simple, but if you can’t fill in the blanks, that’s the sign to slow down and dig in together.
Narrate Your Judgment
There have been times when an agent took a route I didn’t agree with. When I looked closer, I realized the problem wasn’t really the agent. I hadn’t given it the same context I had in my head. Once I explained why its approach wouldn’t work, it agreed, picked up that context, and went a route that did.
The most valuable part of the exchange was the why, and it only came out because I had to put it into words. A pair pulls that out of you all the time. When you or your pair push back on something the agent suggests, say why out loud. That reasoning is exactly what an agent can’t pass on, and it’s what you learn the most from in pairing.
Make Prompting a Shared Act
Patrick ended his post with a question I’ve been thinking about: how can the prompting itself be more collaborative? I haven’t tried this yet, but here’s what I want to experiment with. Treat a prompt like a tiny code review. One person writes it, and the other reviews it before it’s sent.
My context story above is exactly why I think this could work. A prompt shows what you understand, and also what you forgot to say. A second set of eyes might catch the missing context before the agent heads down the wrong path. If you give this a try, I’d love to hear how it goes.
How I Use Agents Now
None of this means I’ve stopped using agents. I use them every day. What changed is what I ask them for. These days, I lean on them to help me understand a system before anything gets built.
Ask for a Tour First
I joined an older project once with very little documentation and no one around who knew the code that well. My first request wasn’t a fix. It was a tour. I asked the agent for an overview of the repo, and it gave me a map of how the pieces connected, what each folder was for (including which ones were just noise), and how data flowed from end to end.
With a pair, this gets even better. Each of you sketches how you think the system works first, then compare that to the agent’s map. Then open a couple of the files it points to and check whether the map is actually right.
Test a Theory
On that same project, a teammate had a theory about a problem the app kept running into. Instead of asking the agent for “the answer,” I asked it to check that theory against the code. It turned a hunch into a specific, testable explanation, with a plan to confirm it before changing anything.
The agent sped up the reading. But the question, the context, and the judgment about what was safe to try all stayed with us.
Ask “Can I Do This Myself First?”
At one point, instead of letting the agent take the next step, I asked how I could investigate something myself first. It walked me through what to check, what each result would mean, and what I shouldn’t do. That small change kept me in the driver’s seat. “How would I check this?” builds skill. “Do it for me” doesn’t.
Ask Why Each Step Matters
On another project, I had the agent break a big infrastructure change into an ordered checklist. Then I went step by step and asked questions until I understood each one, including why the order mattered. It turned out that doing one step too early could have let preview environments connect to the production database. The checklist was the agent’s. Understanding why was mine, and that’s what I’ll need if something goes wrong.
Looking back, most of my time with an agent now goes into the prep work: understanding the system, shaping the plan, and asking why. By the time any code gets written, I know what I’m looking for and why it should look that way.
Try It in Your Next Pairing Session
If you want to give this a try, here’s a simple way to structure your next pairing session:
- Pick a real, ticket-sized problem from your actual codebase.
- Sketch a rough plan together before anyone opens the agent.
- Bring that plan to the agent to fill in the details, or ask it to critique the plan.
- Talk through what each of you caught.
- Have one person write the prompt and the other review it before sending.
- Say your decision out loud: “We’re picking X because Y.”
- Before you wrap up, ask each other: “Could you explain this without the agent?”
Keep the Friction
The goal is to keep thinking for ourselves while we use AI. For me, pairing is the simplest way to do that. It puts another person back in the room, gives me a reason to form my own opinion before I prompt, and keeps the “why” part of the job in human hands.
An agent can write the code. It can’t sit next to you and ask why.