Mob Elaboration: o ritual que substitui o sprint planning
Mob Elaboration é o ritual do AI-DLC em que a IA faz as perguntas e as pessoas que podem decidir respondem, numa sessão só, antes de existir qualquer código. Quem entra na sala, como conduzir a sessão, as três formas de dividir a autoria da spec e o que o AI-DLC 2 agora automatiza.
O sprint planning pergunta o que o time consegue fazer em duas semanas. O Mob Elaboration pede para o time decidir, numa sessão só, tudo o que o agente teria que adivinhar.
Mob Elaboration é o ritual de requisitos do AI-DLC. As pessoas que podem tomar decisões sobre um trabalho sentam numa sessão com um agente de IA. O agente propõe a decomposição e faz as perguntas. O time responde, corrige e aprova. Ninguém escreve código. O que sai dali é a spec a partir da qual o agente vai construir: requisitos, user stories, unidades de trabalho e as decisões de arquitetura por trás delas, tudo gravado em arquivos no repositório. Nos termos do AI-DLC, é o coração da Inception, a fase em que requisitos e design são decididos antes de a Construction escrever qualquer código.
Ele substitui o sprint planning e o refinamento de backlog no AI-Driven Development Life Cycle. O whitepaper da AWS descreve uma sala, uma tela compartilhada, um facilitador e uma IA que propõe user stories, critérios de aceite e Units enquanto o mob corrige o que saiu subdimensionado ou superdimensionado. A promessa do paper é condensar semanas ou meses de trabalho sequencial em poucas horas.
A promessa é verdadeira, e também é a coisa menos útil que você pode saber sobre o ritual. O paper diz o que é o Mob Elaboration. Não diz quem deveria estar na sala, o que fazer antes da sessão, como responder às perguntas do agente, nem por que a terceira hora dá tão errado. Aprendi essas coisas vendo times rodarem o ritual dentro de uma grande organização de engenharia, em pilotos e num treinamento de vários dias para as pessoas que vão espalhar o método. Este é o guia que eu queria que eles tivessem recebido no primeiro dia.
Mob Elaboration comprime semanas de refinamento numa sessão só
Pense em como uma feature é refinada num time ágil normal. O PM escreve um ticket. Um dev tem uma dúvida e pergunta num canal de chat. O designer responde dois dias depois. Alguém decide alguma coisa no corredor, e a decisão vive na cabeça de uma pessoa até aparecer como bug. O refinamento não é lento porque alguém tem preguiça. É lento porque acontece em pedaços, ao longo de dias, e cada pedaço fica esperando uma pessoa.
Com um agente que gera um conjunto completo de requisitos em minutos, essa espera vira o custo inteiro. O Mob Elaboration ataca a espera de frente. Coloca todo mundo que pode responder na mesma sessão e deixa a IA conduzir as perguntas em ordem, então uma decisão que levava uma semana de vai e vem leva cinco minutos de conversa.
O nome vem do mob programming, a prática que o time de Woody Zuill popularizou por volta de 2012: o time inteiro trabalha na mesma coisa, ao mesmo tempo, num computador só. A diferença importa. Um mob de programação escreve código junto. Um mob de elaboração decide junto, e a IA escreve.
Só quem pode decidir ganha uma cadeira
A regra que mais fez diferença nas sessões que eu vi: só entra quem tem poder de decisão sobre alguma dimensão do trabalho. Produto decide escopo e regras de negócio. Engenharia decide arquitetura e trade-offs. Design decide a experiência. Dados decide o que vai ser medido. O resto é observador, e observador deixa a sessão mais cara sem acrescentar contexto.
Parece duro até você fazer a conta. Um mob de oito pessoas por três horas é um dia inteiro de trabalho de uma pessoa. Se três desses oito não conseguem responder nenhuma pergunta do agente, um terço desse dia não comprou nada.
O mob certo muda com o trabalho. O padrão que se firmou:
Quem senta no mob
| Tipo de trabalho | Quem entra |
|---|---|
| Feature com usuário na ponta | Engenharia, produto, design |
| Dados ou machine learning | Engenharia, dados, produto |
| Mudança puramente técnica | Engenharia e um arquiteto |
| Otimização algorítmica | Engenharia e um especialista de domínio |
O AI-DLC 2 tem até um estágio para isso. Nos perfis Feature e Enterprise, o Team Formation (estágio 1.5) faz o agente de entrega avaliar disponibilidade e habilidades e escrever um plano de composição do mob antes de a Inception começar. É um bom estágio. Mesmo assim, ele não tem como saber que o seu tech lead sai de férias semana que vem.
Rode a engenharia reversa antes de alguém entrar
Se o trabalho mexe numa codebase existente, o agente precisa lê-la antes de conseguir fazer boas perguntas. O AI-DLC chama isso de engenharia reversa: o agente varre os módulos que a feature vai tocar, mapeia como eles conversam entre si e anota a stack, os padrões e a arquitetura. Toda pergunta que ele faz depois passa por esse modelo. Sem ele, o agente propõe mudanças que duplicam lógica que já existe ou quebram contratos que ninguém escreveu.
Num repositório pequeno essa passada levou uns vinte minutos nas sessões que eu vi. Num grande, leva mais. De qualquer jeito, são vinte minutos de um mob olhando uma barra de progresso, que é o jeito mais caro de gastar vinte minutos.
Então quem conduz roda isso antes. Instala o workflow, inicia a intent, deixa a engenharia reversa terminar, revisa e aprova o que ela produziu, e só então chama o time. As pessoas entram com um arquivo de perguntas pronto para responder. Os detalhes de fazer isso numa codebase grande, incluindo quanto contexto isso consome, estão em AI-DLC em brownfield.
O arquivo de perguntas é a reunião
Depois da engenharia reversa, o agente escreve um arquivo de perguntas. É um documento markdown simples, com perguntas numeradas, opções de múltipla escolha e uma tag de resposta vazia embaixo de cada uma. Numa sessão que eu acompanhei, o agente produziu quinze perguntas para uma feature pequena de backoffice. Elas cobriam escopo, comportamento, termos de negócio e decisões técnicas que o ticket original nunca mencionou.
Uma pergunta tem esta cara:
## Question 4
How should a cancelled order affect stock that was already reserved?
A) Release the reservation immediately
B) Release it after a grace period
C) Keep it until someone confirms the cancellation
X) Other (please describe)
[Answer]:
Esta é a virada de chave que fez os times pararem de odiar o arquivo. Cada uma dessas perguntas é uma pergunta que um dev teria encontrado no meio da implementação. Sem o ritual, ele pararia de codar, chamaria alguém e esperaria. Com o ritual, a pergunta é respondida antes de existir código, e às vezes a resposta muda a abordagem inteira. O arquivo não acrescenta trabalho. Ele move o trabalho para o ponto mais barato de fazê-lo.
Os times também tiveram que desaprender a tratar o arquivo como uma prova. Estes quatro hábitos resolveram quase tudo, e cada um vem com as palavras que você pode digitar:
Como responder às perguntas do agente
- 01
Responda fora das opções quando as opções estão erradas.
No começo, os times se sentiam presos a A, B ou C. As opções são palpites do agente, não restrições. Ele lê uma resposta livre do mesmo jeito.
Digite isto
None of these. Reservations stay until the warehouse system confirms the cancellation, because a manual refund can still reverse it.
- 02
Adie o que não bloqueia, e dê um dono.
Uma pergunta que depende de uma decisão externa não deveria travar a sessão. O agente pula e pergunta de novo depois. As perguntas que bloqueiam, como um contrato de API do qual as Units dependem, ele não deixa pular, e não deveria deixar.
Digite isto
We don't know yet. Mark it TBD, owner: the payments lead, and ask again before Units Generation.
- 03
Mude de ideia em voz alta. As respostas são reversíveis.
O agente reconstrói os documentos a partir das respostas atuais. Mudar uma resposta manda o workflow de volta ao estágio que dependia dela. Você nunca precisa matar a sessão e começar do zero.
Digite isto
Change question 4 from A to B and update every document that depended on it.
- 04
Pergunte antes de escolher.
Quando ninguém na sala entende uma opção, peça para o agente explicá-la no contexto deste projeto. O prefixo impede que ele trate a sua pergunta como uma ordem de edição.
Digite isto
Do not update any documents. What would option C mean for the current reservation flow?
Mais um hábito vale a pena: mantenha uma lista das perguntas que o agente fez e que o ticket original já respondia. Essa lista mostra o que está faltando na entrada. Leve isso de volta para o jeito como o seu time escreve a próxima intent, e a próxima sessão fica mais curta. De onde essa entrada deveria vir é um problema à parte, tratado em o ponto cego do AI-DLC.
Produto entra nas perguntas de negócio, não na sessão inteira
A agenda é a primeira coisa que mata o Mob Elaboration numa empresa de verdade. Colocar um PM, um designer e três engenheiros na mesma sala por três horas, toda vez que uma feature começa, não sobrevive à semana de ninguém.
A solução veio de alguém de produto no piloto, e era simples. A maioria das perguntas depois da engenharia reversa é técnica. Os engenheiros respondem essas sozinhos. Quando chegam numa pergunta sobre regra de negócio, chamam produto. No caso que essa pessoa contou, produto gastou dez minutos em vez de uma tarde. A frase, mais ou menos: não precisa todo mundo estar na sala ao mesmo tempo.
Produto continua dono de duas coisas que ninguém mais pode assinar. A primeira é se as perguntas são mesmo relevantes, porque às vezes o agente pergunta sobre coisas que o ticket já resolveu. A segunda é o critério de sucesso, que é a coisa que o agente mais erra. Essa armadilha ganha uma seção inteira em o ponto cego do AI-DLC.
Decida quanto da spec a IA escreve
Um time que acompanhei deixava essa escolha explícita no começo de cada tarefa, e acho que todo time deveria fazer o mesmo. Existem três formas de dividir a autoria da spec entre as pessoas e a IA:
Três formas de dividir a autoria da spec
| Modo | Quem escreve | Use quando | O risco |
|---|---|---|---|
| Strict | As pessoas escrevem cada linha. A IA só valida. | Domínios muito regulados ou sensíveis. | Lento. Você abre mão de quase toda a velocidade. |
| Collaborative | A IA pergunta, o time responde, a IA rascunha, o time aprova. | O padrão para quase tudo. | Os gates degradam quando as pessoas estão cansadas. |
| Off | Sem spec. O agente vai direto para o código. | Um spike que você vai jogar fora. | É vibe coding com passos a mais. |
O AI-DLC 2 tem uma escolha parecida, mas diferente, e as pessoas confundem as duas. Todo estágio que coleta informação oferece três modos de interação: Guide Me (o agente faz uma pergunta por vez), Edit File (você mesmo preenche o arquivo de perguntas) e Chat (conversa livre, com o agente gravando as decisões de volta no arquivo). Isso é sobre como você responde. Os três modos acima são sobre quem escreve a spec. Dá para estar em Collaborative e responder no modo Edit File. Os dois convergem no mesmo arquivo de perguntas.
Uma hora, depois pare
Esta é a parte do Mob Elaboration que a documentação nunca menciona, e é onde a maioria das sessões falha.
A IA produz um documento de requisitos, um conjunto de user stories e uma lista de Units em minutos. Uma pessoa precisa de tempo de verdade para ler cada um com cuidado. A distância entre a velocidade de geração e a velocidade de leitura é maior do que com qualquer ferramenta anterior, porque a IA não te entrega uma sugestão, ela te entrega um artefato pronto. Depois de mais ou menos uma hora, as pessoas param de ler e começam a aprovar.
Alguém de engenharia disse isso em voz alta no treinamento, perto do fim de uma Inception longa: quando as Units de trabalho chegaram para revisão, não sobrava mais nada com que revisar, e a pessoa sabia que, se continuasse, ia aprovar qualquer coisa. Parou e voltou outro dia. Foi a decisão certa, e a maioria das pessoas não toma essa decisão.
Regras de ritmo que se sustentaram
- Obrigatório:Limite cada sessão a mais ou menos uma hora.Divida uma Inception grande em duas ou três sessões, em dias diferentes.
- Obrigatório:Pause nos gates, nunca no meio de um estágio.O arquivo de estado registra onde você parou, então retomar não custa nada.
- Obrigatório:Faça commit e push antes de limpar o contexto.O trabalho vive nos arquivos. A conversa é descartável.
- Obrigatório:O manager senta nos dois ou três primeiros mobs.Não para observar. Para chamar a pausa quando as aprovações começam a vir sem perguntas.
- Anti-pattern:Aprovar sem conseguir dizer por que o artefato está certo.Se você não consegue explicar numa frase, você não terminou de ler.
A versão mais funda desse argumento, com as outras formas como os gates de aprovação falham, está em gates são uma função de perda.
O que o AI-DLC 2 automatiza, e o que ele deixa com você
O AI-DLC 2 levou parte do mob para dentro da máquina. A fase de Inception agora roda nove estágios, da engenharia reversa ao planejamento de entrega, e um deles é montado como um mob de agentes. Em User Stories (estágio 2.4), o agente de produto rascunha as personas e as histórias. Depois os agentes de design, desenvolvimento e qualidade revisam esse rascunho em paralelo, sem ver as notas uns dos outros, e escrevem as objeções. O agente de produto incorpora tudo. As decisões de julgamento em que as duas posições são legítimas chegam até você como uma pergunta estruturada. As divergências factuais ganham mais uma rodada limitada entre os agentes. Um revisor de produto separado confere o resultado antes de ele chegar ao seu gate.
Um Mob Elaboration no AI-DLC 2, do começo ao fim
Entrada
Uma intent aprovada e um repositório que o agente consegue ler
- 2.1Engenharia reversa, antes de o time entrar
Um agente de desenvolvimento varre o código, um agente de arquitetura escreve a síntese. Uma passada completa por repositório quando o trabalho atravessa vários.
- 2.3O arquivo de perguntas
Os engenheiros respondem as perguntas técnicas. Produto entra nas de negócio. As respostas podem ser livres, adiadas ou mudadas depois.
- 2.4User stories, rascunhadas por um mob de agentes
O agente de produto rascunha; os agentes de design, desenvolvimento e qualidade fazem objeções em paralelo; você resolve as decisões de julgamento.
- 2.7Units de trabalho
O agente decompõe as histórias em Units com um grafo de dependências. É aqui que você limita o tamanho delas.
- GATEAprove ou peça mudanças, e pare
Um gate de verificação confere se cada requisito está ligado a uma história antes de a Construction começar.
Saída
Uma spec no repositório a partir da qual o agente consegue construir, e um time que concorda com o que ela diz.
É progresso de verdade. Agentes discutindo entre si antes de você ver o rascunho pegam uma classe de erros que antes chegava até o gate. Mas olhe o que o motor ainda não consegue fazer. Ele não escolhe quem senta na sala. Não percebe que o PM parou de ler. Não sabe que a regra de negócio que ele acabou de escrever é a que a empresa abandonou no trimestre passado. As partes difíceis do ritual são humanas, e continuaram humanas.
Planning não é Mob Elaboration
Quando um time adota o ritual, o resto da agenda muda, e os times que não mudam acabam com duas reuniões de planejamento.
O planning decide no que trabalhar a seguir. O Mob Elaboration decide como um trabalho já escolhido vai se comportar. São reuniões diferentes, com pessoas diferentes. A daily encolhe para poucos minutos, porque o estado de cada trabalho está nos arquivos dele. Kanban encaixa melhor do que sprint, porque o trabalho agora chega em fatias de horas ou dias, não em pacotes de duas semanas.
O backlog em si assumiu uma de três formas nos times que eu vi:
Três formas de backlog com AI-DLC
| Forma | Como roda | Quando encaixa |
|---|---|---|
| Uma iniciativa grande por semana | O squad inteiro elabora junto, depois constrói. | Uma feature grande com muitas perguntas em aberto. |
| Várias tarefas pequenas | Uma manhã de elaboração, depois a construção roda de forma assíncrona, em branches isoladas. | Tarefas independentes que precisam de algumas decisões cada. |
| Uma tarefa, sozinho | Um engenheiro experiente e o agente, sem mob. | Trabalho bem delimitado, sem decisões entre times. |
E guarde o piso na cabeça. Um engenheiro do piloto rodou o ritual inteiro para mudar uma única linha de código. Se você já sabe exatamente o que mudar, mude. O Mob Elaboration se paga quando o trabalho precisa de decisões de mais de uma pessoa. Abaixo disso, é cerimônia.
Se o seu time ainda nem escreve spec, a sessão vai parecer um interrogatório, porque cada pergunta expõe uma decisão que ninguém tomou. É o método funcionando, mas também é um sinal para construir o hábito primeiro, do jeito que Spec-Driven Development em time descreve, antes de rodar 33 estágios.
Perguntas frequentes
O que é Mob Elaboration?
Mob Elaboration é o ritual de requisitos do AI-DLC, o AI-Driven Development Life Cycle. As pessoas que podem decidir sobre um trabalho se reúnem com um agente de IA, o agente propõe a decomposição e faz perguntas estruturadas, e o time responde e aprova. O resultado são requisitos, user stories, Units de trabalho e decisões de arquitetura gravados como arquivos no repositório. Nenhum código é escrito.
Quanto tempo leva um Mob Elaboration?
O whitepaper fala em horas em vez de semanas, e isso bate com o que eu vi para uma feature. Mas não rode como um bloco longo único.
Depois de mais ou menos uma hora, quem revisa começa a aprovar sem ler. Divida uma Inception grande em sessões de uma hora, prepare a engenharia reversa antes de o time entrar e pause nos gates.
Quem deveria participar de um Mob Elaboration?
Só pessoas com poder de decisão sobre alguma parte do trabalho: normalmente engenharia e produto, mais design para trabalho com usuário na ponta, dados para trabalho de dados, um arquiteto para mudanças puramente técnicas ou um especialista de domínio para trabalho algorítmico. De três a cinco pessoas é o ponto ideal. Observadores deixam tudo mais caro sem trazer respostas.
Mob Elaboration é a mesma coisa que mob programming?
Não. Os dois compartilham a ideia de um grupo inteiro trabalhando numa coisa ao mesmo tempo. Um mob de programação escreve código junto, num teclado só. Um mob de elaboração toma decisões junto enquanto a IA escreve, e termina antes de existir qualquer código.
Mob Elaboration pode ser remoto ou assíncrono?
Pode. A sessão funciona bem numa call com tela compartilhada. Partes dela podem ser assíncronas: os engenheiros respondem as perguntas técnicas sozinhos e produto responde as de negócio quando é chamado. O que não dá para pular é que toda resposta termine no arquivo de perguntas.
Mob Elaboration substitui o sprint planning?
Substitui o refinamento e muda o planning. O planning continua escolhendo no que trabalhar a seguir. O Mob Elaboration decide como esse trabalho se comporta. A maioria dos times descobre que Kanban encaixa melhor do que sprints de duas semanas quando o trabalho chega em fatias de horas ou dias.
Para onde ir agora
O Mob Elaboration é onde o AI-DLC se paga ou vira teatro. O agente é bom em fazer perguntas. O ritual só funciona se as pessoas certas responderem, num ritmo que deixe elas lerem de verdade o que aprovam. Prepare a sessão, mantenha curta e escreva cada decisão.
A newsletter
Don’t Code, Specify. Toda semana, agentes de IA em produção de verdade. Sem hype: o que funcionou e o que quebrou.
Assinar no Substack (abre em nova aba)