Agents are part of the mob now

Having spent the bulk of my engineering career practising XP and working in environments that value fast feedback and shared understanding in teams through lots of collaboration and human interaction, it’s been interesting learning how agents become part of the team. So when AI agents arrived promising to make each of us far more productive on our own, my first question was what happens to all of that.

A few months of pairing and mobbing with agents later (mostly engineer with engineer, sometimes across disciplines), I think most of the core principles surrounding pairing matter even more. Here’s why.

Why XP, and why it matters more now

XP was never about the practices for their own sake. Kent Beck built it to deal with the risks that sink software teams: building the wrong thing, code that gets harder and riskier to change, defects that reach users, and knowledge that walks out of the door when someone leaves. His answer was fast feedback, shared understanding and a pace a team can keep up.

None of those risks go away now that agents have arrived. Some have got worse. When an agent can turn an idea into a working feature in an afternoon, it’s easy to build the wrong thing faster and ship more code than anyone has properly understood. And it’s easy to do it all alone, in a chat window nobody else sees. The default way of working with an agent is a silo of one.

That’s exactly the situation XP was designed to push against. Pairing and mobbing put more than one set of eyes on what the agent produces. They keep the team’s understanding of the code current. And they force the “should we build this?” conversation before the code exists, and the “how are we building this?” conversation while it’s being written.

It still feels like pair programming

Working from the agent’s plans, prompts and code output doesn’t feel much different to traditional pairing. You’re both looking at one screen or one artefact, reading and digesting it together, and the things worth talking about are the same things they always were.

A typical session goes something like this:

1. Prompt to uncover what’s already in the system.
2. Talk through the problem we actually want to solve.
3. Diagram where things are now and what comes next.
4. Agree the smallest slice we could ship, which matters even more with an agent that will happily build everything at once.
5. Generate a Claude plan for the implementation steps, then follow it together and keep it up to date as we go.

Along the way we still end up discussing data structures and models, how the codebase should be structured, UX goals and the trade-offs between them. The difference is that the agent’s proposed solution becomes a talking point rather than a given. We treat it the way we’d treat a suggestion from a colleague: interesting, probably partly right, worth questioning.

XP’s values still hold

Pairing feels familiar because the ideas behind it haven’t changed. Extreme Programming (XP) popularised pair programming, and the five values Kent Beck set out in Extreme Programming Explained describe our sessions with agents surprisingly well.

XP value	What it looks like with an agent in the pair
Communication	The shared doc and the conversation around the agent’s output hold the knowledge, not one person’s chat history.
Simplicity	Asking for the smallest slice, and picking models whose output is easier to digest.
Feedback	Plans and code arrive in minutes, so the pair can review and change direction far more often.
Courage	Treating the agent’s proposal as a talking point, and being willing to throw it away or cut tests we don’t need.
Respect	Keeping teammates in the loop and leaving work in a state someone else can pick up.

XP’s practices are where those values turn into daily habits. These are the ones I’ve found still earn their place, and some matter more than ever.

Small releases and baby steps

An agent will happily build everything at once if you let it. A huge diff the pair can’t properly review isn’t a step forward, however quickly it arrived.

So we do what XP always asked: agree the smallest slice we could ship, build that, get feedback, then take the next step. The agent makes each step faster; it doesn’t change what a good step looks like. The plan still matters too. Agents work best from a clear plan, and so do pairs.

Test-first thinking

Left alone, an agent will write a lot of tests. XP taught me that tests are a design tool and living documentation, not a coverage number. So pairing means we actively ask:

• Do they make sense, and are they at the right level?
• Do we need all of them?
• Are they easy to read, and do they still work as documentation for the code?
• Will they slow us, or CI, down?

One person might skim past a wall of green ticks. Two people talking it through rarely do.

Collective code ownership

XP says the whole team owns the code. Agents add a new way to lose that: the context behind a change lives in one person’s chat session, and nobody else really knows why the code looks the way it does.

What’s worked for us is a shared Claude doc for each piece of work. We agree the plan in it up front, then keep it updated as we go: what we learned, which PRs merged, what we decided and why. By the end it reads like an Architectural Decision Record we didn’t have to sit down and write, and it’s easy to link from a Notion ticket or a Slack channel. Comments help too: when a side question comes up mid-review, I leave a comment for Claude to investigate and stay focused, with the thread there to come back to.

The payoff is continuity. One evening I finished later than my pair, and the next morning they started before me. They picked up where I’d left off, and when I logged on, the first outputs from our two Claude sessions were almost identical, because we’d both kept the doc up to date. People rotate, get sick and go on holiday, and the work carries on.

You learn each other’s tools, not just each other’s code

We learn so much about each other’s tooling, skills and ways of working, especially when switching drivers and navigators. With agents, that includes how people prompt, which models they reach for and which tools they live in. In the last month alone:

• Skills. I’ve picked up around five new skills from colleagues.
• Models. I’ve got into the habit of switching models a lot more, and using Sonnet in particular, because its output tends to be simpler and more to the point.
• Tools. I use Claude Desktop regularly for its shared artifacts and how easily it lets me organise and see open sessions.

This is XP’s whole-team idea at work: knowledge spreads because people work together, not because someone writes it down afterwards. It holds across disciplines too. When designers and engineers share one plan, the lines between roles blur and each learns more of the other’s craft.

Sustainable pace

XP’s insistence on a pace you can keep up was always about more than hours. It’s about not trading tomorrow’s capacity for today’s output.

Agents make that trade tempting. When building is this cheap, it’s easy to fill every day with more scope, and to build lots of things rather than the right thing. Melissa Perri calls this the build trap in Escaping the Build Trap. Pairing is a natural brake. It forces the “what are we actually trying to achieve?” conversation before the agent starts, not after.

Things to watch out for

Most of the risks are the same ones pairing has always protected against. Agents just make them easier to fall into.

• Bus factor. Working in a silo with an agent means the context lives with one person and their chat history. Shared docs and rotating drivers are the antidote.
• Skipping the planning. It’s easier than ever to write code and build features, so it’s tempting to jump straight in. But are we solving the right problem? Is it the right approach? Code that’s quick to generate doesn’t make the plan optional.
• Overwhelming noise. So many PRs, so much verbose output. We need to manage how much gets generated so it still makes sense, doesn’t slow us down with extra maintenance and admin, and doesn’t bury the key points and the problems we’re actually trying to solve.

What we want to try next

A couple of experiments are on our list:

• Sharing a live session, not just the artifact. Something like the pair-programming tools in IDEs, or Tuple, but for an agent session.
• Handing off from a Claude plan to other agent harnesses e.g. Cursor, to see how well a plan made in one tool travels to another.

Slow down to speed up

None of this is new. Communication, simplicity, feedback, courage and respect were the point of XP long before agents, and the practices built on them still do their job. Agents can make us much faster. Pairing, mobbing and the rest of the XP toolkit make sure that speed goes somewhere useful, with the whole team on the same page and enough shared knowledge and capacity to keep building and delivering.