Mob programming is a whole team working on the same task, at the same time, on the same screen. One person, the driver, types. Everyone else navigates: discussing the approach, spotting mistakes, and directing what the driver should type next, out loud, in real time. The driver role rotates every few minutes so that everyone spends most of the session navigating and only brief stretches typing. It is an extension of pair programming from two people to the whole team, built on the same core idea: code reviewed continuously while it is being written catches more than code reviewed after the fact.
What changed in 2026
- Remote mob programming tooling matured. Shared cursors, follow-mode in editors, and low-latency screen sharing made distributed mobs close in practicality to sitting around one machine, which was the biggest practical barrier a few years earlier.
- Timers and rotation tooling got simpler, with lightweight browser timers replacing the ad hoc kitchen timers teams used to rotate the driver role, which sounds trivial but noticeably improves how well teams stick to the rotation.
- More teams use it selectively rather than as an all-day practice, choosing a few focused hours on a specific hard problem instead of a standing daily format.
How a mob programming session actually runs
- Pick one task the whole group will work on, ideally something genuinely hard or high-stakes rather than routine.
- Assign the first driver. Their only job is to type exactly what the mob directs, not to make design decisions unilaterally.
- Everyone else navigates out loud. Disagreements get resolved by discussion, not by the driver just picking whichever idea they typed fastest.
- Rotate the driver on a timer, commonly every three to five minutes, so no one dominates and everyone stays engaged.
- Take real breaks. A mob session is more mentally demanding per hour than solo work; an hour on, ten minutes off is a common rhythm.
Mob programming vs pair programming
|
Pair programming |
Mob programming |
| People per task |
2 |
Whole team, often three to six or more |
| Roles |
Driver, navigator |
Driver, multiple navigators |
| Best for |
Day-to-day feature work, onboarding |
Hard architectural decisions, tricky bugs, spreading critical knowledge fast |
| Cost |
Two people on one thread |
Entire team on one thread |
| Typical session length |
Hours, often most of a day |
Focused sessions, often a few hours |
Mob programming is not a better version of pair programming, it is a different tool for a different situation. Reaching for a mob on routine work wastes the exact resource that makes it valuable when the problem actually needs it: the attention of the whole team. A mob session is real-time pull request review folded into the writing itself, rather than review deferred until after the code exists.
When it earns its cost
- A genuinely hard problem where more perspectives change the outcome, not just the speed.
- Onboarding a new team member fast, giving them direct exposure to how the team thinks and the codebase works, compressed into hours instead of weeks.
- Spreading knowledge that only lives in one person head, before that person goes on leave or leaves the team.
- A high-stakes change where the cost of a mistake far outweighs the time cost of the whole team.
FAQ
Is mob programming just pair programming with more people?
Conceptually yes, same principle of continuous review while writing. Practically it needs more structure: a strict driver rotation and explicit facilitation, because coordination overhead grows with group size in a way it does not with two people.
Does mob programming replace code review?
No. Code that is mobbed still typically goes through a pull request, though the review is often lighter since the whole team already reviewed it in real time while it was written.
How long should a mob programming session last?
Long enough to make progress on the task, short enough that attention does not collapse, commonly a few focused hours with real breaks rather than an entire day.
Does remote work make mob programming impractical?
No, though it requires the right tooling: screen sharing with low latency, a way to hand off driver access quickly, and a shared timer everyone can see. Distributed mobs work well once that tooling is in place.
Where to go next