Post

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."*

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?"*

In the post, I explore the situation in more depth. I would love to know your stories as a junior, we need to create a more awareness on how to integrate AI and support our peers along the journey.

We shouldn't trade individual productivity over team productivity. We know this doesn't work in the long term.

I thought about this lately; it’s a bit concerning to me. Introducing long autonomous coding windows (+30min) makes the work more individual. If we’re increasing that time (it seems to be the trend) should we shift collaboration earlier (in the specification phase) and reinforce it during reviews?

With juniors, the challenge is even harder, as you said. I would avoid long autonomous coding windows when were working with junior engineers.

The more time passes with the adoption of Coding Agents, the more I see the need of continue pairing to deliver value. We need to integrate the coding agents on the pairing activity, not to replace it all together to delegate into coding agents.

The more time I see myself without collaborating with others, the more concerned I'm on how fast we are deviating our mental models on the product, business, and code base. I'm sure some influencer will rediscover XP, and popularize pairing under a new name in some months.

> If we’re increasing that time (it seems to be the trend) should we shift collaboration earlier (in the specification phase) and reinforce it during reviews? IMHO, I would do the whole process with pairing. From spec to prod.

6/4/26, 8:48 am0 reposts0 likes

Because the landscape of practices are rapidly evolving, I would focus on fast feedback loops, and rapid knowledge sharing. Up to today, the best approach I know is pairing. If tomorrow I discover a better one, I'm happy to switch into that one.

The problem is how to maintain those principles when you’re waiting at certain steps in the process. I’m still figuring out how to avoid falling into the three traps I see: