Mob programming is a way of working where a whole team works on one thing together, instead of everyone taking a separate piece. This page explains how it works, how it compares with pairing and working alone, what teams report about adding AI agents to the mob, and how to try one session.
Definition
Woody Zuill, who developed the approach with his team, defines it in his Agile2014 experience report: the whole team works on the same thing, at the same time, in the same space, and on the same computer. TechTarget describes it as a group of developers working together in real time on one task, with roots in pair programming.
Roles
There are two main roles. The driver is the one at the keyboard. The navigators, everyone else, discuss, suggest and guide. Zuill’s report states the rule behind this: for an idea to get from your head into the computer, it must go through someone else’s hands. The driver translates what the mob says into code, and does not run ahead alone.
Roles rotate. Zuill’s team rotated the driver every 15 minutes, and sometimes started with 4 or 5. TechTarget also says roughly every 15 minutes, and mentions an optional champion who keeps the discussion on task and signals changes. A team at Scania, writing on Crisp’s blog, rotates by team dynamics instead of strict timers.
Why teams do it
The teams that write about it give these reasons. Shared knowledge: everyone sees the same code and decisions, so nobody is the only person who understands a part. Faster decisions: Zuill reports less task switching and quicker, more visible decision-making. Fewer review queues: the Crisp team wrote that mobbing removed the need for code reviews, because “we review as we build”.
These are reports from teams, not controlled studies. Zuill himself warns that the improvement his team saw cannot be credited to mobbing alone, because they changed other things too. And mobbing has costs: TechTarget notes that some developers find it slow, that it needs the team’s full commitment, and that remote mobs are hard across time zones. The Crisp team found that splitting up to meet a deadline backfired, because putting the work back together was painful.
Mob, pair, and solo
| Solo | Pair | Mob | |
|---|---|---|---|
| People on one task | One | Two | The whole team |
| Computers | One | One | One |
| Roles | None | Driver and navigator | One driver, several navigators |
Pair programming is where mobbing comes from (TechTarget calls it an Extreme Programming technique), and the choice is not all or nothing. Many teams mob only on the hard or risky tasks.
When an AI agent joins the mob
Teams are starting to write about this. Three accounts, each from a different team:
- Atlassian. An engineer’s post on mobbing with AI describes mobs of two to four developers. One person facilitates: they share their screen, drive the editor and handle the AI prompts, and that role rotates. The mob agrees the standards and the spec, an agent generates code and tests, and the mob reviews and refines. The team reports shipping about ten features, with pull requests usually merged within a day or two against close to a week for similar work, and says early drafts met less than half of what they wanted and later ones about 80%. Their advice: keep standards short, start with small tasks, and never accept AI output blindly.
- Crisp. The Scania team above treats AI as a teammate and not only a tool, and warns about the same trap as any mob: the driver carries all the load while the others become passive observers.
- flurdy. In a post from February 2026 the author argues for small mobs of four or five (“you need coordination, not headcount”), with agents taking parallel work, for example one implementing a feature and another writing tests, and says “the mob provides what AI lacks: judgment, context, and coherence”.
So an agent can be the one doing the typing, or several agents can work in parallel while the people navigate and review. In these accounts, deciding and checking stay with the people.
Running a mob session with a board
A board keeps that split visible. Each step of the work is a card. An agent claims one card at a time, builds it on a branch and submits a pull request, and a card shows who holds it and what state it is in. The mob reads the result together and accepts or sends it back. Agents cannot accept; a person has to. See good first tasks for a session for the first cards, and set up a polling agent for giving an agent a seat.
Try it
A suggested 90-minute plan:
- Minutes 0 to 10: agree the goal in one paragraph and put six to ten cards on the board.
- Minutes 10 to 20: one person shares their screen and is the first driver. Everyone else navigates. If agents join, start the first one on a small card.
- Minutes 20 to 80: four rounds of 15 minutes. Rotate the driver each round. Review what any agent submitted as a mob.
- Minutes 80 to 90: accept or send back what is in review, and talk about how it felt. The Crisp team’s advice is to start small and talk about how it feels.