---
title: "Zuill's Mob Programming, Remastered"
date: 2026-08-11
slug: mob-programming-reimagined
summary: "Mob programming says the whole team works on the same thing, at the same time, in the same space, on the same computer — one driver, many navigators, and a rule that an idea only enters the code through someone else's hands. This post tells its story: from XP's pair programming (1999) and the Paris coding dojo (2005), through the Hunter Industries meeting room where the mob got its name (2011), the Agile2014 report, the 'ensemble programming' rename, and the remote mob — to the thing that looks like a brand-new invention: multiplayer AI coding agents, whose shared live sessions a whole team can enter and steer. A remaster does not rewrite the song; it re-engineers the master tape. Multiplayer AI is mob programming, remastered — the same practice, with the driver replaced by an agent. The objection that kept mob programming out of the enterprise — five developers on one computer is wasteful — has died, because the driver is now a machine. And the single-player era answered the old question on its own terms: LeadDev's analysis of 25,264 agent-generated PRs found 79% were reviewed by the same developer who prompted the agent. This post maps the practice onto the product, explains why the mob is back now, connects the practice to its intellectual ancestor — Marvin Minsky's 1986 Society of Mind, in which intelligence emerges from mindless agents that check each other — and lays out how to run one."
tags: mob-programming, ensemble-programming, coding-dojo, pair-programming, multiplayer, coding-agents, driver-navigator, strong-style-pairing, collective-code-ownership, self-review-problem, agent-teams, remote-mob-programming, agile, software-craft, verification, society-of-mind, minsky
---

In 2011, a software team at Hunter Industries in Southern California needed to restart a project that had been on hold for months. A few members and a contractor had worked on it; most of the team had not. They gathered in a meeting room to review the code and decide how to take the work on — and somewhere in that review, out of a habit of pair programming and TDD practice sessions, they started passing the keyboard around. After several hours another group needed the room, so they moved, held a mini-retrospective, and agreed the day had been remarkably productive. They booked the meeting room again. Two weeks later they were still working that way, and they had a name for it: mob programming. Woody Zuill presented it to the Agile Alliance in 2014.

Fifteen years later, teams gather again — not around a projector and a single keyboard, but inside a shared live agent session: the same files, the same terminal, the same browser preview, open to everyone at once, anyone able to steer. The products call it multiplayer AI. The name is new. The shape is not.

> Multiplayer AI for coding agents is not a new way of working. It is mob programming, remastered — with the driver replaced.

This sounds like marketing fluff until you take the architecture seriously. Mob programming's entire structure — one shared surface, a driver and navigators, the strong-style rule, single-piece flow, continuous code review — maps one-for-one onto the shared agent session. And the objection that dogged mob programming for fifteen years — "how can five developers be productive on one computer?" — has reappeared, word for word, as the objection to shared sessions: "why not just run more agents in parallel?" The data answers both the same way, because the bottleneck was never typing. It was review.

## The mob's lineage

The 2011 meeting room was not a beginning. It was the latest turn in an evolution that had been running for more than a decade — the story of an idea that kept getting re-housed: many minds on one surface, and only one pair of hands on the code at a time, so that everyone else had to think out loud. Follow that constraint, and the whole history unfolds in acts.

**1999 — the pair.** Kent Beck's *Extreme Programming Explained* made "two programmers, one computer" the centerpiece of a new way of building software: one person's hands on the keyboard, the other's eyes and voice on the code — the split mob programming would later formalize as Driver and Navigator, carrying the claim, radical at the time, that two minds on one task beat two minds on two tasks. XP gave the idea its first vehicle. The pair was the smallest possible mob.

**2005 — the dojo.** Six years later, in Paris, Laurent Bossavit and Emmanuel Gaillard founded the Coding Dojo, borrowing the language of martial arts on purpose: the dojo is the training hall, the kata is the practice form, randori is free-form sparring. Groups met to practice on a single computer with a projector, passing the keyboard every few minutes the way sparring partners trade roles. The dojo's discovery was that the constraint itself teaches: with one keyboard and many people, no idea enters the code until it has been spoken. It was practice, not production. But the seed was planted.

**2011 — the mob gets its name.** Zuill's team at Hunter Industries had been running TDD and pair-programming practice sessions as dojos, and when they gathered to restart a project that had been on hold for months, the habit took over — "we started passing the keyboard around," Zuill later wrote. What began as a review meeting became two weeks of meetings, became a way of working. "All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer" — that was how the team described what they had stumbled into, and someone proposed the most memorable name anyone could offer: mob programming. It stuck, which was the practice's first taste of its own marketing problem; the word "mob" would spend the next decade being fought.

**2014 — the canon.** Zuill's Agile2014 experience report gave the practice its founding text: the Driver/Navigators pattern adapted from Llewellyn Falco's strong-style pairing — "for an idea to go from your head into the computer it MUST go through someone else's hands" — the list of problems that simply "fade away," and the claim that the team delivered roughly ten times as many projects the year after adopting the mob. Then came the tour: Zuill and Falco crisscrossed conferences and code retreats, mobbing live on stage. It was the practice's peak of visibility, and it was still a niche — the name was winning and losing at the same time.

**2018 — the rename.** Maaret Pyhäjärvi proposed "ensemble programming." Mob carried baggage — crowds, violence, mob rule — and ensemble named what the practice actually was: the whole team, all its skills, one surface, playing together. The rename is the tell that the practice had matured into a discipline with a canon and a community — and an identity problem it could not quite solve. Ensemble stuck in the corners where the practice survived: agile meetups, code retreats, the teams that refused to give it up.

**2020 — the remote mob.** Simon Harrer, Jochen Christ, and Martin Huber systematized the distributed mob: cameras always on, a ten-minute typist rotation, git handoff at every interval, decisions made by the group. They claimed the distributed version was "superior to anything we ever tried before." But the discipline tax was heavy — cameras on, voices metered, a handoff every ten minutes — and most teams paid it for a sprint, not for years.

**The plateau.** By the late 2010s, mob programming was a conference-circuit staple that never became mainstream. Not because it failed on its own terms — the teams that mobbed kept mobbing — but because its benefits were structural and its costs were visible, and management's arithmetic counted only the costs. Five minds on one keyboard looked like waste from the outside, and the practice remained what it had been since the dojo: a discipline of believers.

**2026 — the remaster.** And then the constraint that mob programming had enforced socially became the architecture of a tool. The shared live agent session is one surface, many navigators, a single driver — with the driver now a model that types at machine speed. The line of evolution completes itself. Every step kept the surface singular and made the driver more mechanical: a pair of people, a passing keyboard, a rotating typist, a remote screen-sharer — and finally an agent.

![The mob's lineage — from XP pair programming (1999) and the Paris coding dojo (2005) through Hunter Industries (2011), the Agile2014 report, the ensemble rename (2018) and the remote mob (2020), to the multiplayer agent session (2026). The driver evolves from a person who types to the agent, permanently.](/images/mob-lineage.png)

A remaster does not rewrite the song. It takes the original master tape and re-engineers it with modern tools — same performance, cleaner delivery, new instruments. The industry calls multiplayer AI a new way of working, which is like calling a remaster a new song. The master tape is mob programming, and the master tape was always the point.

## What mob programming actually is

The Agile Alliance's glossary defines mob programming as "a software development approach where the whole team works on the same thing, at the same time, in the same space, and on the same computer." One work item at a time. Continuous code review, whole team involvement, self-organizing teams. Almost all work happens in "working meetings" — defining stories, designing, testing, even working with the customer.

The operational core is the Driver/Navigators pattern. Two roles. The Driver sits at the keyboard and types — "a much more mechanical job" — and must trust the Navigators. The Navigators discuss the idea and guide the Driver "in a slow, metered approach," speaking "at the highest level of abstraction that the Driver is able to digest" at that moment. A timer rotates the driver every ten to fifteen minutes. The result, Zuill writes, is "a sort of collective intelligence of the Navigators."

The benefits are best stated negatively. Mobbers don't claim the mob adds productivity; they claim problems "fade away": communication problems (waiting for answers, back-and-forth email, misunderstanding via documentation); decision-making dysfunctions (reluctance to decide, the need to defend decisions); the waste of doing more than barely sufficient; technical debt, because "many sets of eyes" sit on the current work as it is written; thrashing, because single-piece flow means no one is switching contexts; workplace politics; and "management by meetings," with its separation of decision-making from knowledge creation.

And then there is the question everyone asks. Zuill quotes it directly: "How can 5 or 6 developers be productive while working this way? Wouldn't it be more productive to have them working on different things?" His answer, offered with appropriate caveats: the year after the team adopted mob programming, it delivered roughly ten times the number of projects it had delivered the year before. The point was never that five people on one keyboard is fast at typing. It was that typing was a rounding error against the cost of misunderstanding, and the mob spent its effort where the money was.

## What multiplayer AI actually is

By 2026 the single-player agent is the incumbent. Claude Code, Codex, Cursor: each is a private channel between one developer and one model — one person, one terminal, one context window, one transcript. Work exits the channel as a package: a diff, a pull request. The agents are everywhere — installed in 75 percent of Linear's enterprise workspaces, per The Register — which is exactly why the layer around them is now the bottleneck. The industry's first answer to the coordination problem was to run more of them: parallel runners, worktree managers, cloud agents, fleets. Coshell's verdict on that strategy is the sharpest one-sentence critique in the space: "That is more parallelism, not more collaboration. It is still single-player, just with more players who cannot see each other."

The 2026 multiplayer wave is a different bet: make the session itself the shared place. AQ — the "multiplayer coding harness" — defines the category as "AI coding agents whose working sessions are shared, live places that a whole team can enter: everyone sees the same running agent, the same terminal, the same code, and the same app preview, and anyone can steer." Coshell: "Multiplayer AI coding is when several engineers prompt one shared, live AI agent working in a single cloud workspace"; the analogy the industry keeps reaching for is "closer to a Google Doc than to git." collab, a small open-source Go CLI, does it peer-to-peer: "Two devs. Two agents. One session" — each developer keeps their own agent and their own API key, and the two agents share a conversation log and a `./shared/` directory across the wire.

AQ's test for what counts is the right one: a tool is multiplayer when the running session, not just its output, is shared — the same live session (not a replay, not a read-only transcript); anyone can steer mid-run, "the way anyone can grab a marker at a whiteboard"; handoff without re-setup; roles beyond engineers (a PM or designer can watch the preview and push feedback without touching a terminal); outsiders can look. Screen sharing fails the first test — one person still owns the session. Shared tmux over SSH passes the first two and fails the rest.

Why this exists is a measured fact, not a pitch. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular repositories found that in 79 percent of agentic PRs, the same developer both reviewed and modified the agent's contribution — and only about one in eight agentic workflows involved more than one human at all. The loop closed structurally, in three steps: the agent session lives in one person's private transcript; the PR is the only artifact that escapes it; and the prompter becomes the reviewer, reading the diff through the memory of their own prompt. As AQ puts it: "The decisions that determine whether agent work is good live in the session, not in the diff. A review process that cannot see the session is auditing the residue of the work rather than the work."

The self-review problem is not new. It is the pre-mob problem set — one person's cubicle, one person's understanding, one person's review — recreated at scale by the tool that was supposed to give everyone a teammate. Mob programming was invented precisely because that arrangement has a ceiling. Multiplayer AI is the industry rediscovering the mob's answer, in the medium that forced the question.

Why the shared layer exists at all is an industry-structure question, and it is worth being clear-eyed about. The model vendors are structurally disincentivized from building it: Anthropic shipping Agent Teams, and the steady drift toward "Claude Code for teams," point toward collaboration inside one model's session on one vendor's terms. The layer between people — many models, many providers, your own git — has to be neutral to be useful. That is why the multiplayer products are an independent layer (Coshell, built on the open-source OpenCode engine; AQ; the peer-to-peer collab) rather than a vendor feature. The mob needs a room, and the room cannot belong to the driver.

## Why the mob is back now

If multiplayer AI is the mob's endpoint, why is the endpoint arriving in 2026 and not in 2018, when mob programming was a conference-circuit staple? Three forces.

**The waste objection died.** The mob's killer objection — five minds, one keyboard — assumed the driver's time was the scarce resource, and management arithmetic said it was. The agent era inverts the mob's cost structure. The driver is now a model that types at machine speed, never tires, and never gets bored; the scarce resource is what the navigators contribute — the articulation, the judgment, the verification. "One agent, many navigators" is no longer five salaries idle; it is five minds loaded onto a machine that works faster than any of them. The objection that kept mob programming out of the enterprise was an accounting artifact, and the accounting changed.

**Remote work killed the room.** Mob programming was a room practice, and the remote mob that kept it alive demanded more discipline than most teams had. The shared agent session is the first mob room that is easier to enter than a video call: a link, and the environment is already there, loaded, warm. The remote mob's hardest problems — handoff, shared state, who sees what — are precisely the problems the session solves mechanically.

**The single-player agent recreated the disease the mob was invented to cure.** This is the one nobody chose. The tool that was supposed to give every developer a tireless teammate instead recreated the cubicle: one person, one private transcript, one self-review, 79 percent of agentic PRs. The industry ran a fifteen-year control experiment on the null hypothesis — everyone in their own session, working on their own thing — and measured the result at scale. The null hypothesis lost. The mob is back because the alternative failed on its own terms.

## Same shape, new driver

![The same shape, the driver changed — mob programming's one-computer mob (2011) and multiplayer AI's one shared session (2026): many navigators converge on a single shared surface and one work item.](/images/mob-same-shape.png)

Run the mapping and it holds at every layer.

**Same surface.** The mob's rule was "all code that enters the code base is input through this single computer." The multiplayer rule is that all code enters through the session. One place, many minds, everyone watching the same thing at the same time.

**Same roles.** The agent is the driver; the humans are navigators, permanently. Read Zuill's description of the navigator's job and it reads like instructions for prompting an agent: express the idea "in a slow, metered approach," speak "at the highest level of abstraction that the Driver is able to digest," guide without touching the keyboard. In mob programming you could not type because the keyboard belonged to the driver. In a shared agent session you cannot type because there is no keyboard — there is a prompt. The social role has become the interface.

The industry files this under pair programming, and the categories say otherwise. AQ's FAQ: "Pair programming shares a human's editor. Multiplayer coding agents share an agent's working session: the humans present are steering an AI that does the typing." But pair programming is two people, one editor, one conversation. Mob programming is the whole team on one surface, one work item at a time — and the multiplayer test's own criteria, roles beyond engineers and outsiders in the room, are mob criteria, not pair criteria. What AQ described is mob programming's Driver/Navigators pattern with the rotation removed. Call it multiplayer if you like; the architecture is a mob room, not a pair table.

**Same constraint.** The strong-style rule — an idea must go through someone else's hands — was mob programming's hardest discipline, and it was social: the team enforced it on itself, person by person. In multiplayer AI it is architectural. The only hands on the code belong to the agent. You cannot drift, you cannot grab the keyboard, you cannot produce output you did not first articulate. This is the least noticed and most profound property of agentic coding: mob programming needed a norm to guarantee what the agent tool provides by construction.

**Same objection, same answer.** "Why not parallel agents?" is "why not have everyone in their own cubicle?" with better branding. It fails at the same point: the work is generated in private and reviewed at the end by whoever generated it. The 79 percent figure is the quantified version of the problem set the mob was built to make fade away.

**Same fading problems.** Communication: the session is the artifact — "what is it doing?" questions die because everyone watched it happen; there is no back-and-forth email, there is the scrollback. Decision-making: the whole team steers, in the open, with the current information, and the transcript preserves the reasoning. Waste: single-piece flow on one work item. Technical debt: many sets of eyes on every line, live, not at PR time. Thrashing: nobody re-ingests the codebase from cold — Coshell's point that a shared warm context is loaded once for the team rather than re-read per person is the token-economics version of the mob's anti-thrashing argument.

![Where the eyes land — the self-review problem: 79% of agent-generated PRs are reviewed and modified by the same developer who prompted, ~1 in 8 agentic workflows involve a second human, while the mob baseline is continuous review by design.](/images/mob-self-review.png)

The two figures above are the whole argument in pictures: the mob's topology, and the cost of abandoning it.

## What the remaster changes

A remaster keeps the original; it also changes the delivery. Five deltas are genuinely new.

**The driver never rotates.** In mob programming, the rotation existed so everyone got the driver's seat — the learning and the engagement, not just the typing. In multiplayer AI the driver is always the agent, so the humans are all navigators, all the time. That is a pedagogy change with a measured price, and this blog has covered it: in [You Don't Learn What You Delegate](https://blog.hackspree.com/#ai-impacts-skill-formation), a pre-registered randomized trial found that delegating to an AI cut learning by 17 percent (d ≈ 0.74) — and the damage concentrated exactly where the mob's navigators need skill most: debugging. The mob's driver rotation was how a team learned by doing. A mob with a permanent driver must learn by articulating and reviewing instead. The mob still teaches — it teaches navigation, not typing. But the team that lets the agent drive while the humans spectate has stopped mobbing and started watching.

**The mob admits non-human navigators.** Zuill's navigators were all people. A shared session's navigators can be agents: a verifier subagent that checks the diff as it lands, a reviewer agent that reads the session's scrollback, an always-on agent that patrols the repo overnight. This is the direction Anthropic's multi-agent research system pointed at in 2025 — subagents with their own context windows, exploring in parallel, compressing their findings back to a lead — with the observation that "groups of agents can accomplish far more." Mob programming at that scale is mob programming where the mob itself has scaled past human attention. And it makes the navigator's job, verification, the expensive and decisive one — the thesis of this blog's [Verifiers Are King](https://blog.hackspree.com/#verifiers-are-king-sonar-acdc) and [The Verification Horizon](https://blog.hackspree.com/#verification-horizon). In a mob of agents, the driver is cheap; the navigators are the product.

**The mob has perfect memory.** Face-to-face mob memory was perishable: what the team agreed at the whiteboard at 10 a.m. lived in their heads at 4 p.m., if it survived at all. The shared session is the memory — the transcript, the scrollback, the dead ends, the decisions. AQ's review guidance is blunt about why this matters: "Dead ends are signal: they mark the parts of the codebase the agent found confusing, which is where the surviving code deserves the closest reading." collab's motivation is the same point from the loss side: "By the time the diff lands in a PR, the chain of thought that produced it is gone." The mob's knowledge no longer leaves at 5 p.m.; it stays in the room, reviewable.

**The mob never sleeps.** The session persists. A teammate joins from another timezone mid-run and finds the work where it was left, environment, history, and running processes intact — the "handoff without re-setup" test. This is the always-on agent economy this blog has written about before ([Always-on agents](https://blog.hackspree.com/#always-on-agents)), except the always-on entity is the mob itself, and humans are the visitors.

**The one-keyboard rule must be re-imposed in software.** This is the deepest point. The physical mob's single-writer guarantee was hardware: one keyboard. The moment agents run in separate sessions over the same repo, the guarantee disappears — two agents can reach for the same lines of the same file, and the engine underneath is last-write-wins. Coshell's overlap control is exactly the mob's rule rebuilt as a protocol: "the second edit is held before it lands, and a coordinator steers that agent to proceed if the changes are compatible, or to take other lines, wait, or let the first land first." The mob's most important property is no longer enforced by furniture; it is a design problem, and it is the entire job of the coordination layer. Multiplayer agents relate to mob programming the way flying machines related to bird flight: the constraint that made the original work — one writer at a time — had to be rediscovered in the new medium before anything could fly.

## The Society of Mind

In 1986 — forty years before the shared agent session, twenty-five years before the mob got its name — Marvin Minsky published *The Society of Mind*, and in doing so described the mob's architecture in advance. Minsky's claim is that intelligence is not one big thing. It is a society: many small, mindless parts, which he called agents, interacting until the whole does what no part can do alone. There is no homunculus, no little person inside the head doing the thinking. "What magical trick makes us intelligent?" he asked. "The trick is that there is no trick. The power of intelligence stems from our vast diversity, not from any single, perfect principle."

Run that thesis against the mob and it reads like a design document for what Zuill's team stumbled into in 2011:

- **The navigators are Minsky's agents.** Each holds part of the problem and knows almost nothing about the rest — that is the point. The mob's "sort of collective intelligence of the Navigators" is the society doing what no single member can: no navigator builds the product alone; the product is what the connections produce.
- **The strong-style rule is Minsky's communication problem made social.** An idea only enters the code through someone else's hands — through articulation. Minsky spent most of the book on how agents connect, because intelligence is not in the parts; it is in the connections. The one-keyboard rule exists precisely to force the connection.
- **The driver is the anti-homunculus.** Minsky's core methodological warning was the homunculus fallacy — explaining the mind by hiding a smaller mind inside it. The mob's driver is explicitly "a much more mechanical job": hands without a mind. In the session era it is genuinely mechanical — a model. Nobody explains the mob's intelligence by pointing at the driver, because there is no intelligence there to point at. It all lives in the society. That is the whole point of the exercise.

![The Society of Mind, three decades, three rooms — Minsky's mindless agents and the connections between them (1986); the mob's navigators converging on one pair of hands (2011); the shared session where human navigators and model agents share one room, with a verifier agent checking the output (2026). The intelligence is never in a single part; it is in the connections and the checks.](/images/mob-society-of-mind.png)

Then notice the vocabulary. The word Minsky chose for his mindless parts — agent — is the same word the industry uses for the things now sitting in the mob's navigator seats. The lineage runs from Minsky's 1986 agents through the software-agents literature of the 1990s to the model agents of the 2020s, and the session is where the metaphor stopped being a metaphor: the society is now a literal one, human navigators and model agents in one room — subagents with their own context windows, verifier agents, always-on patrols, the Anthropic multi-agent system referenced above. Minsky's society got machines in it. And the discipline that keeps mindless parts from producing a mob in the bad sense is the same in all three rooms: checking. Mindless parts do not make a mind until something verifies them — which is the navigator's job, and the reason the session's scarce resource is verification, not generation ([Verifiers Are King](https://blog.hackspree.com/#verifiers-are-king-sonar-acdc), [The Verification Horizon](https://blog.hackspree.com/#verification-horizon)).

The man who named the mob has spent the years since 2011 telling this story in person. At DDD Europe in 2024 — forty years after Minsky's book, thirteen years after the mob got its name — Zuill gave *Advanced Software Teaming*, the full account from the founder: the dojo lineage, the Driver/Navigators pattern, the problems that "fade away," and why the practice outlived its objections. It is the primary source for this post's central claim — that the shared agent session is mob programming, remastered, with the society of mind run as an actual society.

![Woody Zuill — Advanced Software Teaming [Mob Programming] (DDD Europe 2024): the founder's full account of mob programming, from the 2011 Hunter Industries room to the practice that met the agent era. Watch at youtube.com/watch?v=gL4WxpiG1D8](/images/mob-zuill-talk.png)

Forty years after the theory, the society of mind is no longer hypothetical. It is a room you can join, the driver's seat held by a machine, the mind spread across everyone and everything in the session — checking each other, which is the only way mindless parts ever made anything intelligent.

## How to run an agent mob

Mob programming's fifteen years of practice boil down to a small set of disciplines, and each has a direct translation into the session era. The cheat sheet:

![Same practice, new room — every mob discipline translates directly into the shared agent session: one session per work item, the agent as driver, the strong-style rule made architectural, session review instead of PR review, scrollback retrospectives, and the whole team in the room.](/images/mob-practice-map.png)

**One session, one work item.** Single-piece flow survives unchanged: start, work on, deliver one item before the next. The session is the unit of flow now — when the session wanders, the mob wanders.

**Invite the reviewer before the code.** In mob programming, review happened because everyone watched every line. In the package model, review happens at PR time and fails (the 79 percent). The translation: the second set of eyes should be in the session, not on the diff. Make "someone other than the prompter ran the result" the definition of done. Where to spend that attention is the mob's instinct made explicit: review effort concentrates where the session shows the agent struggled, not where it sailed through.

**Prompt at the highest level the driver can digest — then verify the step.** This is Zuill's instruction for navigators, verbatim, now the interface: express the next step at the right abstraction, and do not let the driver run ahead of your ability to check it. Small steps, metered, the way the mob did it.

**Rotate the navigator roles, not the driver.** The driver no longer needs the rotation; the humans do. Rotate who steers the session, who verifies the agent's work, who reads the scrollback for dead ends, who speaks for the customer. The mob's learning loop — everyone takes the seat — moves from the keyboard to the roles around it.

**Hold the retrospective on the transcript.** The mob's "turn up the good" ritual has a new artifact to review: the session itself. Where did the agent go wrong, and how did we steer it back? Which prompts were unclear? What did we almost ship that looked right and was not? The transcript is the first mob memory that can be reviewed by people who were not in the room.

**Keep it chosen.** The mob's first rule transfers intact: it only works if the team chooses it. A session that is imposed is not a mob; it is a panopticon.

## The honest costs

Mob programming's glossary entry comes with a pitfalls section, and it transfers almost unchanged. Constant collaboration all day is not for everyone. And above all: "Mob Programming will only work if the team sees value in this approach and chooses to work in this manner... the change will not be nearly effective if people feel they are being forced to make the change." The same is true of shared sessions. The moment a shared session is imposed for surveillance — who steered, who typed the prompt, who was idle — the navigators stop navigating and start performing. The mob's first sign of use is "kindness, consideration, and respect"; a multiplayer tool that tracks instead of hosts will earn the 79 percent problem back, now with dashboards.

And the discipline is not optional. A swarm of parallel agents in one repo without single-piece flow is a mob in the bad sense: uncoordinated, clobbering, review by firehose. Mob programming's norms are precisely what keep a multi-agent session from degenerating into chaos — one work item at a time; anyone can steer; continuous review; frequent retrospectives, because the team "always turn[s] up the good"; participation that is chosen, not coerced. The practice has fifteen years of accumulated thinking about how to make many minds work on one thing. The products are months old. The products will need the practice more than the practice needs the products.

And a new contagion replaces the old one. The glossary warns that a mob working in close physical proximity spreads illness; the session mob has its own epidemiology. Shared context is shared attack surface: a prompt injection in one transcript, or a poisoned artifact in the shared workspace, travels to everyone who joins the session — and unlike a cold, it is engineered, and it is aimed. Sandboxing the room is not optional infrastructure; it is the mob's hygiene ([Sandboxing AI Agents](https://blog.hackspree.com/#sandboxing-ai-agents), [Zero Overhead Is Zero Attack Surface](https://blog.hackspree.com/#zero-overhead-is-zero-attack-surface)).

## The mob was never about the keyboard

Mob programming was dismissed for years as a waste of five minds and one keyboard. The five minds were the point. The keyboard was the constraint that forced them to think out loud — that made articulation, and therefore review, and therefore shared understanding, unavoidable. Every artifact of the mob's discipline — the driver who cannot act on an unspoken idea, the navigators who must speak at the highest level the driver can digest, the many eyes on every line as it is written — is the same constraint doing its work from a different angle.

Multiplayer AI re-imposes that constraint in software — mob programming, remastered: a driver that never tires, navigators who never have to wait their turn, a session that remembers everything, and a mob that does not go home. The industry is calling it multiplayer because the tooling changed. The reason it will matter is that the practice did not change — it was waiting for a driver that never needs to be rotated. In 2026, the driver arrived. The mob is back, and this time it never leaves.

---

**References:**

- Marvin Minsky. *The Society of Mind* (Simon & Schuster, 1986) — intelligence from the interaction of mindless agents; the homunculus warning; the word "agent."
- Kent Beck. *Extreme Programming Explained: Embrace Change* (1999) — pair programming, the seed of the Driver/Navigator split.
- Laurent Bossavit, Emmanuel Gaillard — the Coding Dojo (Paris, 2005): groups practicing kata on a single computer with a projector, keyboard passed in randori style. The dojo is the direct ancestor of the mob's one-keyboard constraint.
- Agile Alliance. [What is Mob Programming?](https://agilealliance.org/glossary/mob-programming/) — glossary entry: definition, expected benefits, common pitfalls, signs of use, origins (Hunter Industries, 2011; Zuill's Agile2014 report). Source of the definition and pitfalls quoted in this post.
- Woody Zuill. [Mob Programming — A Whole Team Approach](https://www.agilealliance.org/resources/experience-reports/mob-programming/) (Agile Alliance Experience Report, 2014) — the Driver/Navigators pattern, the strong-style rule, fading problems, and the ~10x projects-delivered comparison.
- Woody Zuill. [Advanced Software Teaming [Mob Programming]](https://www.youtube.com/watch?v=gL4WxpiG1D8) (DDD Europe, 2024) — the founder's full account of the practice; the primary source for this post.
- Llewellyn Falco — strong-style pairing: "for an idea to go from your head into the computer it MUST go through someone else's hands," as adapted by Zuill.
- Maaret Pyhäjärvi — [Ensemble Programming Practiced](https://maaretp.com/) (Pragmatic Bookshelf, 2023): the "ensemble programming" rename (2018), emphasizing the whole team, all skills, one surface.
- Simon Harrer, Jochen Christ, Martin Huber. [Remote Mob Programming](https://www.remotemobprogramming.org/) — the distributed mob: cameras always on, ten-minute typist rotation, git handoff; "superior to anything we ever tried before."
- AQ. [What are multiplayer coding agents?](https://aq.dev/multiplayer-coding-agents/) (updated Aug 2026) — the definition, the "package vs place" distinction, the multiplayer test, the July 2026 vendor map, and the Linear/Register adoption figure.
- AQ. [The self-review problem](https://aq.dev/self-review-problem/) (Jul 2026) — LeadDev's analysis of 25,264 agent-generated PRs; session review as the fix; "auditing the residue of the work."
- Coshell. [Why multiplayer](https://coshell.ai/why-multiplayer) — shared live sessions, overlap control, warm shared context, "more parallelism, not more collaboration," and why the layer between people has to be neutral.
- collab. [Multiplayer for AI coding agents](https://aman035.github.io/collab-ai/) — peer-to-peer shared sessions across Claude Code/Codex/Cursor: "Two devs. Two agents. One session."
- Anthropic. [How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) (Jun 2025) — subagents, parallel context windows, "groups of agents can accomplish far more."
- Related: [You Don't Learn What You Delegate](https://blog.hackspree.com/#ai-impacts-skill-formation) — the 17% learning cost of delegation (d ≈ 0.74), concentrated in debugging, when the agent does the typing.
- Related: [Verifiers Are King](https://blog.hackspree.com/#verifiers-are-king-sonar-acdc) — in agent work, verification is the bottleneck the mob's navigators must fill.
- Related: [The Verification Horizon](https://blog.hackspree.com/#verification-horizon) — why verifying agent output is harder than generating it.
- Related: [Always-on agents: state, memory, and the governance gap](https://blog.hackspree.com/#always-on-agents) — the session as persistent state.
- Related: [Sandboxing AI Agents](https://blog.hackspree.com/#sandboxing-ai-agents) — the mob room's hygiene: shared context is shared attack surface.
- Related: [Zero Overhead Is Zero Attack Surface](https://blog.hackspree.com/#zero-overhead-is-zero-attack-surface) — why the coordination layer should add nothing beyond the shared room.
- Related: [Software dark factories: specs in, software out](https://blog.hackspree.com/#software-dark-factories) — the factory the mob now runs.
- Related: [Every Token Has a Price Tag](https://blog.hackspree.com/#every-token-has-a-price-tag) — why the shared warm context is also a shared budget line.