Much of the focus in AI-native SDLC is on the individual: it’s either about the workflow between an individual and AI, or about automated AI delivering outputs asynchronously for individuals to review (or pretend to review). Agents handle a lot of tasks for teams, but teams don’t engage with the agents in group settings.
There are a lot of questions around how to plan work for agents in settings where we really need input from multiple people. Mob Elaboration is one attempt to provide some answers. I test-drove it with two colleagues.
Not to bury the lede: Mob Elaboration feels right.
Read on for our findings and advice if you want to give Mob Elaboration a go yourself.
What is Mob Elaboration?
Mob Elaboration is a concept that comes from AWS. It’s part of the AI-Driven Development Life Cycle (AI-DLC) framework. The two main resources for it are:
- White paper for AI-DLC: https://prod.d13rzhkk8cj2z0.amplifyapp.com/
- Accompanying blog post for the paper: https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
If you try to search for more thoughts and experiences on Mob Elaboration and AI-DLC, there isn’t much out there at the time of writing. But even though this is over a year-old concept that hasn’t taken off, the white paper could easily have been written today. The issues that it identifies are things most teams seem to still continue to struggle with.
AI-DLC is also a framework meant for an organization dealing with complexity, rather than a workflow for a single person with a laptop and a Claude Code subscription.
Mob Elaboration is just one of the concepts presented in the AI-DLC white paper. Unfortunately, the paper is very light on the exact implementation details.
This is the process as laid out in the white paper:
- During Mob Elaboration, a team plans work to deliver a product or feature, starting from intent and continuing all the way up until technical design.
- It’s a ritual that takes place in a physical room where participants share a screen operated by the facilitator.
- AI proposes and generates artifacts, and the team adjusts these suggestions by looking for under- and over-engineered parts and adding information about real-world constraints.
- The outputs of the session are a PRFAQ, functional and non-functional requirements, risk mapping, measurement criteria, and iterations for the needed units of work.
Mob Elaboration is followed by technical planning and implementation.
Our experiment with Mob Elaboration
While the high-level idea of Mob Elaboration is clear, there is a lot left unsaid when it comes to actually running a session as a facilitator. Because of this, I ran a one-hour Mob Elaboration experiment to get firsthand experience so that I would be more comfortable trying out the method in a real-life setting.
The session was structured as follows:
- We were three people: I acted as a product owner, my first colleague acted as a designer, and my second colleague acted as a developer. As the product owner, I was also the facilitator.
- We were all in the same meeting room with a single monitor connected to my laptop.
- Our task was to plan the first release of a Slack app that people in our company could use to recognize colleagues by sending them public thank-yous.
- We used Opus 5.5 on High effort through Claude.ai for the whole session.
- The session ran for roughly an hour, which included 5 minutes of prep, 45 minutes of actual Mob Elaboration, and 10 minutes of debriefing about our experience.
The app idea was fictional, and none of us currently work together on the same projects. I would categorize all of us as experienced software professionals who are comfortable wearing more than one hat and are used to running and participating in many forms of planning.
Intent
Before the session, I had written down three short paragraphs of intent (with zero AI assistance):
We are a software consulting company. We use Slack internally. We would like our consultants to recognize their colleagues more often and more publicly. To achieve this, we are planning to build a Slack app where users get X amount of points they can give to their colleagues as recognition: you choose who you want to recognize or thank, how many points you want to give, and the recognition/thank you message for others to see. The recognition then gets posted on a Slack channel. We want the received points to lead to some kind of company-wide benefits/efforts (such as afterwork beers or charity donations) to provide that extra incentive for recognition.
I later asked the other participants whether the intent was enough prep for the session or if I should have generated some more documents ahead of time.
We all felt that the intent was enough, as the idea was to build shared ownership of the AI-generated planning artifacts. Had I generated, for example, the PRFAQ alone, it would have defeated the purpose of the session.
We did, however, discuss that I could have workshopped the intent a bit more to catch some obvious mistakes or omissions. I could have done this by having a conversation about the intent with AI.
Having said that, I personally feel that the shorter your intent is, the better your starting point will be. And you get to catch errors in your intent in the next phase: PRFAQ.
Learnings
For your first Mob Elaboration sessions, the facilitator should prepare the intent and nothing else. Expand the prep work only when you discover a real need for it.
PRFAQ
PRFAQ stands for Press Release and Frequently Asked Questions. It’s a planning document created before any code is written. It contains a fictional press release that describes the product or feature as if it had just been released, an FAQ for anticipated questions from prospective customers and users, and another FAQ for internal people.
The method was popularized by Amazon, which is probably why it made its way into the AI-DLC framework.
We started our session by prompting the agent to generate the PRFAQ for us. Our prompt was as follows (see above for the intent):
[INTENT] We need to construct a PRFAQ for this.
That’s all the context we gave the model. We didn’t use any skills or templates for PRFAQs, but Opus 5.5 understood the task perfectly, and we got our PRFAQ.
The generated PRFAQ also happened to contain measurement criteria and risks, so we reviewed those during the PRFAQ review. In hindsight, I can say that this seems like a bad idea (more about this later).
We went through the PRFAQ together and stopped to discuss points where we felt the document was off. Some issues were design decisions we could push into the future or handle in the next release, while others needed to be corrected here and now. I’ll get back to how we handled note-taking later.
After we had collected all the fixes, we sent the following prompt to get a new version of the PRFAQ (all the prompts in this post are unedited versions, so apologies for any typos or confusing parts):
Let's change the following in "How it works" * Each user gets 10 points each month. User can give max 5 points at a time. * Let's remove the company value. We will get back to this after we have released the first version and categorized thank you’s people actually give. * No separate notifications for recipients. Instead users get tagged to the message and they get a ping if they have allowed those pings from #kudos. * No voting inside this app. Admins set the goals and rewards. Let's change the following in the metrics table: * No cross-team recognition (not possible to measure). * No felt recognition (we don't want to overload our consultants with more surveys). Let's drop the cost table. Additional technical details * We need to figure out a view for the company pool for everyone to see and admin tools to manage Update the PRFAQ accordingly.
We didn’t have time to review the second version of the PRFAQ, as we wanted to get to the requirements during this experiment as well. We also didn’t have time to make all the adjustments we would have wanted to make to the PRFAQ, which is why our notes were so few.
In reality, you need to review and adjust the PRFAQ until it matches what you need to prevent “slop” from having ripple effects in future artifacts (more about this later).
However, had we had more time, we would have been happy to go through the whole document together with care. A PRFAQ is an incredibly easy-to-read and easy-to-understand document compared to a list of user stories or a typical business case document.
Learnings
Use the PRFAQ method. It produces an entertaining document that’s also short enough to review in a group setting.
Do not move to the next step until you are happy with the PRFAQ. Laziness here will cost you later.
User Stories and Non-Functional Requirements
Next, we started a new chat session where we attached the generated PRFAQ along with the following prompt:
We (product owner, designer, engineer) are generating requirements for a Slack app. Read the attached PRFAQ. Generate User Stories and Non-Functional Requirements based on it for us to review.
Again, this was all the context we gave the model (no skills, no templates).
We started reviewing the requirements together and discussing parts where we felt changes were needed.
Right from the beginning, it was clear that we were now paying the price for our shortcuts in the PRFAQ phase.
The PRFAQ seemed to describe a consulting company with a working culture that didn’t match ours. Our designer flagged this, but due to time limits, we parked that conversation. This misunderstanding of our culture resulted in user personas and user stories that completely missed the mark on what we were trying to build: one of the user personas was a manager who would look through the shared thank-yous for a given employee to discuss during a performance review.
As intent elaboration produces more and more details as you move forward, early mistakes in your initial artifacts will likely compound into even more mistakes later on, which in turn means more human adjustments and work.
Unfortunately, we ran out of time and couldn’t review all the requirements or move on to planning the work for iterations. This is how far we got with our prompt for adjusting the requirements:
Let's add the following changes for Personas: * We are less than 100 employees. We don't need a people team to moderate. But we need some kind of admin tool for deleting accidental posts. This could also be an option for a user to edit or remove their thank you. * This app should have zero links to any performance reviews. This is about having fun and giving thanks. * Drop manager persona. These user stories should be modified: * US-03: One value gets applied to all (to remove complexity from UI and avoid bad feels). Also, the UI should alert user if they are trying to give too many points for people. These user stories should be dropped: * US-02 (too much work and too half-baked)
Learnings
Errors in the PRFAQ will find their way into the requirements. Fix them early on.
Risks and measurement criteria
Opus 5.5 had already added risks and measurement criteria to the PRFAQ, which is why we ended up discussing those parts before we got to the requirements.
Both risks and measurement criteria could have used more context at this stage:
- Different implementation strategies result in different types of risks. While doing risk mapping early on is a good idea, you need to remember to complement that mapping later as you gain more knowledge about the planned solution details.
- Instrumentation limits what you can measure. There are things we would all love to measure but simply cannot because we aren’t able to capture certain data, whether due to data privacy or technical constraints.
Learnings
Instruct your model to keep risks and measurement criteria out of the PRFAQ if needed.
Reading together
As the facilitator, I read the PRFAQ and requirements aloud and asked the other participants to interrupt me whenever they felt we needed to discuss something about the AI-generated proposals.
This is not something that is suggested by the AI-DLC. I was initially worried that the reading-aloud part would make the session feel awkward. But in the end, we all felt that it created a great, natural flow for the session.
The alternative would have been for us to read the artifacts silently from the shared screen or our individual screens. But people read at different speeds and skim through certain sections differently.
If I encounter an issue I want to comment on when reading the PRFAQ by myself, others might not have reached that point yet. I would end up breaking someone’s train of thought and forcing them to move ahead before they’re ready.
To avoid this, we could have all read the full artifact by ourselves, made notes, and then reviewed our notes together at the end. However, this might also introduce time pressure for some people, and we don’t want people to skim over important things, as errors will compound in future rounds.
Reading things aloud has another benefit: it creates an incentive for teams to keep the artifacts short. No one wants to read pages and pages of AI slop aloud.
Learnings
As the facilitator, read the documents aloud from the shared screen so that others know when they can jump in with their comments.
Taking notes
During the session, we ended up generating two sets of notes:
- Notes that we wanted to give to the AI to edit the artifact under review.
- Parked conversations that we wanted to get back to later, but not during this session.
As the facilitator, I wrote down all the notes for us on the shared screen. The faster the facilitator can type and write good notes, the smoother the experience will be.
I wrote the notes for the AI directly into the chat’s text box, as these needed to go to the model. I added the parked conversations to a separate document.
In hindsight, I should have written the AI notes in a document that would autosave them. Imagine writing tons of edits for the AI and then experiencing some technical glitch that wipes your whole text box clean.
One of our participants had an AI transcribe our conversation for fun to see whether we could have skipped the manual note-taking and just had another LLM session pass our notes to the LLM session working on the artifact. Imagine discussing the PRFAQ without any note-taking and then pressing a button to send the LLM off to generate a new version of the PRFAQ.
This would make the flow of Mob Elaboration even smoother. But as of today, this would require extra checks to make sure the transcript is correct, so it’s faster for the facilitator to write notes manually.
Learnings
Park conversations in one document (or document section) and notes for the AI in another document (or document section).
Choosing the agent
In our experiment, we started with zero code. Because of this, we didn’t need to use a coding agent or introduce additional context beyond the intent.
If we had been planning a feature, we would have had an existing codebase where the implementation would go. This could have warranted an agent that had access to the codebase.
But given the artifacts you’re generating in Mob Elaboration, a coding agent might not be the right tool for you. After all, coding agents’ system prompts and tools are calibrated towards reading and editing code, which in turn adds a real burden to the LLM’s context when doing more high-level planning and ideation.
If I were to run a Mob Elaboration session for an existing application, I would first, as the facilitator, try to think about what context we really need to give the AI to get a PRFAQ and requirements out of it. After that, I would try to inject the required context as Markdown documents instead of giving the LLM tools to access all the possible context.
Learnings
Expand the context only when needed, preferably through curated Markdown files.
Thinking less
When reviewing the AI-generated risks, I noticed that I was merely checking whether an identified risk made sense in our context or not. I wasn’t using my creative thinking to map out all the possible risks.
If you want the team to engage in “outside-the-box” thinking, I’m not sure Mob Elaboration is the right format for it. You’re much more in “editor” mode compared to “writer” mode. The AI-generated artifacts will anchor your thinking whether you like it or not.
For a truly valuable risk workshop, it does feel like we need to have humans map out the risks first and then have the AI augment the risk map, not the other way around.
However, teams don’t usually do thorough risk mapping for every single feature they release. Because of this, in reality, the alternative to having AI generate some risks is doing zero feature-specific risk management.
Our AI-assisted risk analysis was also extremely naive. In reality, we would want to give the AI more instructions about what kinds of risks to consider based on our context and the types of issues we usually run into with new features.
Learnings
Do not use Mob Elaboration when you want humans to spend time thinking outside the box.
Participant count and location
A product owner, developer, and designer form one typical “Three Amigos” setup. It felt like a good composition for our experiment, given the task at hand and the participants.
In practice, you should always pick the three roles to fit your context instead of forcing every Mob Elaboration session to have the same specific perspectives represented. I recommend sticking with three people, as this way you can keep the energy high in the room.
We ran our experiment in a shared physical space. Everyone participating needs to be able to read paragraphs of text from the shared screen, which means you’ll end up sitting close to each other and close to the screen.
There’s no reason why Mob Elaboration wouldn’t work remotely. It just won’t hit the same highs as in-person sessions can.
Sharing a screen is easy in a remote setting. But as the facilitator, reading things aloud means you need a comfortable setting for yourself and a good mic.
Learnings
Start experimenting with Mob Elaboration in person, with a maximum of three people.
Schedule
We couldn’t finish Mob Elaboration in 45 minutes. We felt that we would have needed at least one more hour, maybe two. But not necessarily more than that.
Mob Elaboration requires focus from all participants. If you get lazy, you (or others) will end up doing more work downstream.
This means you should try to keep Mob Elaboration to a maximum of half a day and schedule breaks. To fit Mob Elaboration into that time box, you need to limit your participant count to three (as mentioned before) and try to minimize the scope of the products and features you’re planning.
A good schedule for us would have been:
- 1 hour PRFAQ
- Lunch
- 1 hour requirements and risks
- Break
- 1 hour measurements and planning the units of work
Learnings
Don’t try to get everything done in a single sitting without breaks.
Final thoughts
I can highly recommend that everyone try Mob Elaboration. A shared screen with one facilitator works. The PRFAQ seems extremely suitable as an AI-generated planning artifact for humans to review in a group setting.
During our debrief, one of the participants raised a great point about how we’re heading towards a miserable and unproductive future with the current status quo of working with agents. People generate documents alone with agents and then pass those documents to others to review asynchronously.
Some organizations have a great tradition of writing prose to communicate ideas internally. Writing forces people to think things through in a way that making a PowerPoint presentation or having a conversation with someone who won’t challenge you doesn’t. But writing doesn’t come naturally to many (for example, simply because they were taught in school to hate writing).
Having an LLM generate a PRFAQ for you isn’t the same as writing one yourself, though. You will end up thinking more like an editor and less like a writer, and there’s no step that forces you to actually read things through and make the document easy to digest for others.
There’s also less and less room for collaboration since a) we’re working with LLMs that can offer all the imaginable perspectives for any kind of planning, b) there’s ever-increasing pressure to “speed up” planning, and c) we’re mostly learning how to use AI in “one person, one laptop” settings instead of “three people, one laptop” settings.
Trying to replace a three-person workshop with three people planning alone with an agent and reading each other’s artifacts might provide only superficial productivity gains.
It feels like we’re saving time because we have fewer meetings in our calendars. But how much of that saved time is eaten up by forcing our colleagues to read (or pretend to read) stuff that was easy for us to generate but that we were too lazy to edit?
And also, if agents are doing so much work on our behalf, isn’t Mob Elaboration just the kind of thing we’re expecting teams to use their saved time for?
In any case, I will continue my experiments with Mob Elaboration. As the saying goes, “If you want to go fast, go alone. If you want to go far, go together.”