What is Mob Elaboration?
Mob Elaboration is a working session from AI-DLC, the AI-driven development lifecycle that AWS published in 2025 (github.com/awslabs/aidlc-workflows). It belongs to the Inception phase — the part of the lifecycle where a business intent is turned into something precise enough to build. The cross-functional team works together, in person or remotely. An AI agent asks the questions, the team answers, and the agent decomposes the answers into units of work that the team approves one by one.
The practice shares the whole-team working pattern of mob programming and ensemble programming. Mob programming can include design and requirements as well as code. Mob Elaboration focuses that collaboration on scope, acceptance criteria and a written record of decisions the team could not make.
Why the AI asks the questions
The AI drafts a structured question list from the intent and the context the team supplies. This runbook starts with 10–15 questions covering business rules, edge cases, integrations, data, exclusions and verification. The team checks what is missing: an AI-generated list is a starting point, not a guarantee of complete requirements.
In this site's unofficial facilitation format, every question has a proposed temporary assumption. Unresolved decisions get an owner and a deadline. Silence is not approval: review assumptions before implementation and block work that depends on an unsafe guess.
The parts that make it work
- One driver, one keyboard. Only one person types to the AI. Everyone else talks to the driver. This keeps the transcript accountable.
- “I don’t know” is a valid answer. The runner challenges answers that sound like guesses, once. A logged “don’t know” with an owner beats a confident guess every time.
- No solution design in the question round. Answers are rules and facts. How to build it comes later, in decomposition.
- The Decisions Board. Every question the team cannot answer within its mandate is logged with a temporary assumption, an owner, and a deadline. The count of unowned items is read out loud at the close — it is the headline of the session.
From answers to units of work
After a break, the AI proposes units of work, one at a time. Each has a goal, scope, out-of-scope list, testable acceptance criteria, dependencies, and the temporary assumptions it relies on. Each is labelled: autonomous, meaning an AI agent with repository access could build and test it in one working session, or needs-human, meaning it needs a decision, specialist input or further review. The team accepts, amends, or rejects each unit. Unit boundaries are an architecture decision, so nothing is labelled autonomous until an architect or tech lead signs off that the boundaries match how the code is actually coupled.
How it fits alongside backlog refinement
Refinement can already include all of these good practices. The difference is how this runbook makes them explicit, not evidence that one approach always performs better.
| Refinement activity | This Mob Elaboration runbook |
|---|---|
| Clarify requirements together | Start with an AI-drafted list; the team corrects and extends it |
| Identify gaps and dependencies | Gaps become logged assumptions with owners, in the room |
| Prepare and refine backlog items | Review units with acceptance criteria and explicit dependencies |
| Track outstanding questions | Keep a Decisions Board with owners and deadlines |
| Evaluate whether planning helped delivery | Compare session notes with rework and review outcomes after building |
Who should be in the room
This runbook recommends five to eight people, not a universal minimum for mob working. Include the perspectives the intent needs: a facilitator who owns the timer and never answers domain questions. A driver, the single person typing to the AI — several voices in one chat means nobody is accountable for what was said. An intent owner who wrote the intent and can sign off decisions inside the team’s mandate. At least two mob members from whatever the intent touches: domain, engineering, QA, operations.
One role cannot be skipped: an architect or tech lead. Unit boundaries are an architecture decision, so nothing is labelled autonomous until someone confirms the boundaries match how the code is actually coupled. Without that person present, every unit is marked needs-human until the boundaries are reviewed. Smaller teams can adapt roles; larger groups may need more deliberate turn-taking. The facilitation runbook covers each role, the preparation checklist and the failure modes in detail.
When not to run a session
Use a lighter conversation or postpone when these conditions apply:
- No written intent. Without half a page stating the business outcome, the measurable criterion and at least three “not doing” items, the session becomes discovery wearing elaboration’s clothes. Postpone and write the intent first.
- No mandate. If nobody in the room can decide anything, you will produce a board of open items with no owners — occasionally that is the useful finding, but usually it means the wrong people were invited.
- The work is genuinely trivial. A one-line config change may not need the full workshop. Fast answers can reflect good preparation; check their basis rather than assuming they are guesses.
- The intent is really a research question. When nobody yet knows what the product should do, run discovery first. Elaboration sharpens a decision; it does not make one.
Where the ritual sits in the wider lifecycle — Inception, Construction and Operations — is covered in the AI-DLC explainer.
What it is not
It is not a discovery workshop — without a written intent the session should be postponed, not improvised. It is not a design session — the AI parks solution talk until decomposition. And the AI is not an oracle: it runs the process and keeps the memory, but the product decisions stay with the humans, on the record.
The planned session takes at most 2 hours 25 minutes, including the break, and ends with six markdown artifacts saved to the repository and a metrics table. Whether all this actually shortens the path from intent to pull request is an open question — which is exactly why teams should compare their own delivery outcomes. Public session logging is paused; you can share feedback instead.