Sources checked
From Mob Programming to Mob Elaboration
Mob Elaboration shares a central idea with mob programming: bring the people who hold different parts of the answer together around one piece of work. AI changes the tools and the conversation, but people still own the decisions.
What is mob programming?
Mob programming is a collaborative way of developing software in which a group works together on a shared task and workspace. It involves discussion, design and problem solving as well as entering code. Woody Zuill documented his team’s approach in Mob Programming Basics in 2012, well before today’s AI coding assistants.
You may also encounter the names ensemble programming and software teaming. The Software Teaming site uses these names for the same whole-team approach. Teams vary in how they organise it; the label does not prescribe one universal team size or timetable.
Driver, navigators and rotation
In the driver/navigator pattern described by Zuill, one person operates the keyboard while the others discuss and guide the work. The driver translates the group’s ideas into changes and can ask for clarification. The rest of the group is actively solving the problem, not watching a demonstration.
Rotating the driver gives different people time at the keyboard. Zuill’s early account describes 15-minute turns; that is an example of a team’s practice, not a rule every group must adopt. Choose an interval that lets people participate without making the handover dominate the session.
Does everyone need to be in the same room?
No. Remote Mob Programming describes working in a shared virtual space, with a screen-sharing typist and the rest of the group discussing the next steps. Its authors use short rotations and an explicit handover of the work.
For a remote session, agree how to transfer control or changes, make the shared screen readable, and check that everyone can hear the discussion. These are practical starting points, not a requirement to copy another team’s entire setup. A participant who cannot follow the screen cannot meaningfully review the decisions being made there.
How Mob Elaboration is connected
The connection is explicit in AWS’s AI-DLC description for financial services: its Inception section describes cross-functional collaboration in a mob programming format, with AI helping clarify requirements and organise work. This supports a connection between the practices; it does not mean AWS invented mob programming.
Our Mob Elaboration runbook adapts shared working to a focused conversation about intent, rules, acceptance criteria and unresolved decisions. One designated driver communicates with the AI on behalf of the team. The AI asks questions and drafts artifacts; people supply domain knowledge and approve the results.
The distinction is the session’s focus. Mob programming can include requirements and design; Mob Elaboration concentrates on clarifying and approving work before implementation. They overlap rather than forming a strict “requirements versus code” divide.
The named decision owners, deadlines and unit-boundary sign-off described on this site belong to this runbook. They are not universal rules of mob programming. Likewise, our 2 h 25 min session timebox is a facilitation choice, not a general rule for ensemble work.
What happens when AI joins the group?
AI is optional in mob programming. In our elaboration workflow, it takes a specific supporting role: proposing questions, keeping track of answers and drafting units of work. That does not give it authority to choose a business policy or approve an architectural boundary.
A useful practice is to pause when the model introduces a new assumption. Ask whether the team accepts it and who has the mandate to decide. If nobody does, record the question and its owner. A fluent answer is not evidence of agreement.
An example: from refund rules to implementation
This is an illustrative workflow, not a reported case study. Imagine a team adding self-service refunds to an online shop:
- Elaborate together. Product, engineering, testing and support discuss eligibility, partial refunds and failure cases. The AI helps turn answers into testable criteria.
- Record the gap. Nobody can authorise the refund deadline. The team names a decision owner and marks dependent work as blocked instead of silently selecting a value.
- Build a ready slice together. Once its prerequisites are settled, an ensemble can implement and test that slice, rotating keyboard control and reviewing the same changes.
- Revisit what implementation reveals. If a payment-provider constraint invalidates an assumption, update the criteria and obtain the necessary decision. Elaboration does not make later learning unnecessary.
The implementation could also happen through pairing or individual work. Mob Elaboration does not require mob programming afterward. For tooling options, see the comparison of spec-driven tools.
When to try it
Consider a shared session when important knowledge is spread across people, or when the team needs to understand an unfamiliar part of the system together. Start with a bounded task and review whether the conversation improved understanding and decisions.
If most attendees cannot contribute, a key decision-maker is absent, or the work needs substantial quiet investigation first, change the setup. Shared attendance is not automatically shared progress. Treat reduced rework or faster delivery as outcomes to measure, not guaranteed benefits.
To try the requirements-focused version, read what Mob Elaboration involves, use the runbook, and tell us how it went. The sources linked above describe the underlying practices; the example and adoption suggestions are this site’s guidance.