Planeje com Rigor com o Claude: Modo de Planejamento, DDD e PRD/ERD como Passagens de Sessão

Se você usou o Claude Code em qualquer coisa maior do que um projeto de fim de semana, você bateu nessa parede: você está há três horas em uma funcionalidade, as especificações estão passando, e a sessão termina, o limite de uso acaba e o contexto é compactado em algo irreconhecível. Você abre uma nova sessão e passa os próximos vinte minutos reexplicando o que estava fazendo e por quê.

A solução, para mim, não é uma janela de contexto maior. É escrever o projeto antes de pedir ao Claude para escrever qualquer código. Como faço isso é escrevendo a parte que a maioria das pessoas pula.

Passo Zero: Modo de Planejamento

Um novo projeto começa no modo de planejamento. Sem edições, sem commits, sem chamadas de ferramentas que alterem o mundo. Apenas uma conversa.

Eu descrevo o que quero construir, os fluxos de trabalho principais, os usuários e as restrições que já conheço. Então, eu passo a palavra com um prompt que guardo como um snippet:

I'm going to describe a project. Use a Domain-Driven Design (DDD) lens to
find gaps before we write anything down:

- What bounded contexts are implied?
- What entities and aggregates are not named yet?
- Where am I using two words for the same thing, or one word for two different things?
- What domain events does this system react to, or emit?

Ask me whatever you need. Do not propose a schema or write code. We are not leaving plan mode until the questions stop surfacing real ambiguity.

O modo de planejamento é o que torna isso seguro. O Claude não pode sair criando um web app enquanto eu ainda estou identificando lacunas, conceitos e casos de uso. A sessão inteira é uma conversa, não um projeto semi-construído.

Por que usar DDD como lente

Não sou um especialista em DDD, mas uso o DDD como lente porque ele traz à tona as perguntas que eu não pensei em fazer:

• Bounded contexts – onde estão as costuras? O "usuário no onboarding" é realmente a mesma coisa que o "usuário no faturamento"?
• Ubiquitous language – estou usando duas palavras para a mesma coisa, ou uma palavra para duas coisas diferentes?
• Agregados e invariantes – o que deve ser sempre verdadeiro em conjunto? O que pode ter consistência eventual?
• Eventos de domínio – o que realmente acontece neste sistema, nomeado na linguagem do negócio?

A maioria das perguntas que o Claude faz eu consigo responder em uma frase. As interessantes são aquelas que me fazem parar e pensar – essas são exatamente as lacunas que teriam se transformado em refações mais tarde.

Então, e Somente Então: PRD e ERD

Assim que a conversa de descoberta converge, saio do modo de planejamento e peço ao Claude que produza dois documentos:

• Product Requirements Document (PRD). O que estamos construindo e por que. Usuários, fluxos, escopo, o que está explicitamente fora do escopo. Isso captura o acordo que acabamos de chegar. Uma vez estabilizado, não muda muito.
• Engineering Requirements Document (ERD). Define as especificações técnicas que cumprem o PRD, mas, com a mesma importância, é onde ficam os tickets e onde acompanho o projeto. Tickets faseados (T-001 até T-00N), cada um com critérios de aceitação, cada um marcado como a fazer / em progresso / concluído conforme o trabalho avança. Este arquivo muda constantemente.

O PRD é o porquê. O ERD é o como, além de onde estamos na entrega. Juntos, eles são a memória do projeto e, crucialmente, são a forma escrita da conversa de descoberta que já tivemos, não um substituto para ela.

Por que o ERD é um documento vivo

O truque que faz a passagem de sessão funcionar é que o ERD é atualizado conforme o trabalho é realizado. Quando o T-005 é enviado, eu (ou o Claude, sob meu comando) o marco como concluído no ERD e adiciono quaisquer notas que tickets futuros precisarão, como "usa a nova classe RankingPolicy adicionada em T-005," "schema migrado, veja o commit abc123."

Isso significa que, a qualquer momento, o ERD responde a três perguntas de uma vez: como estamos entregando o PRD, o que está pronto e o que vem a seguir.

Então, quando uma sessão morre no meio de uma funcionalidade, por limite de uso, compactação acidental, porque eu saio com raiva por estar cansado ou qualquer outra coisa. A próxima sessão não precisa de um prompt de passagem do meu lado. Ela abre o ERD, vê o que foi marcado e o que não foi, e assume o próximo ticket.

O que Isso me Proporciona

Algumas coisas, todas discretas, mas importantes:

• O raciocínio pesado acontece antes de haver código para defender. No modo de planejamento, ninguém está investido em uma implementação feita pela metade. Mudar de ideia sai de graça.
• Limites de uso param de ser caros. Eles costumavam significar "perder vinte minutos fazendo um novo briefing". Agora eles significam "abrir um novo terminal, apontar para o ERD".
• Subagentes fazem o próprio briefing. Quando eu crio um agente de revisão ou um implementador paralelo, não escrevo um resumo de contexto; eu digo para ele ler o PRD e o ticket do ERD relevante. O mesmo contexto todas as vezes.
• Posso rodar dois Claudes em paralelo. Um no T-004, outro no T-006. Ambos herdam o mesmo plano. O ERD os coordena: quem termina primeiro marca seu ticket como concluído, e o outro vê a atualização na próxima vez que ler o arquivo.
• O aumento de escopo é barrado na porta. Se uma solicitação não mapeia para algo no PRD ou ERD, isso é um sinal de que ou o plano precisa mudar deliberadamente, ou a solicitação não deve acontecer.

Uma Sequência de Abertura Típica

Vamos pegar um app de TODO simples como exemplo, a abertura foi mais ou menos assim:

1. Modo de planejamento. Preciso criar um app de TODO, precisamos ter gerenciamento de sessão, um usuário pode compartilhar, se quiser, uma tarefa com outro usuário. O sistema deve notificar os usuários atribuídos/presentes nas tarefas quando estiver próximo do prazo ou quando estiver atrasado. Assim que uma tarefa for marcada como concluída, não deve haver nenhuma notificação sobre ela; um usuário pode abrir/editar a tarefa concluída ou criar cópias dela. Use as lentes de DDD para me ajudar a encontrar as lacunas disso e discuta qualquer outro caso de uso que eu possa estar esquecendo. Não estamos construindo ou escolhendo uma stack tecnológica, este é um passo conceitual do que estamos construindo.

2. Q&A de descoberta de DDD. O Claude voltou com perguntas como:

• "O ‘atribuído’ é o mesmo agregado que ‘criado por’ ou um é uma projeção do outro?"
• "Qual é o ciclo de vida do envio de uma tarefa — criada, a fazer, em progresso, revisão, fechada? Quais transições são válidas?"

Metade delas eu respondi em uma frase. Algumas genuinamente mudaram o design do que eu estava pensando, mas tudo bem porque ainda estamos planejando, não custará nenhuma refatoração no código.

3. PRD. Quando as perguntas pararam de chegar, pedi ao Claude para escrever o PRD refletindo o que acabamos de acordar. Eu o li a frio; se qualquer frase me surpreendesse, significava que na verdade não tínhamos convergido, e eu o enviava de volta.

4. ERD. "Dado o PRD, rascunhe a especificação de engenharia: escolhas de arquitetura, componentes principais e a divisão de tickets em fases. Cada ticket é atômico e entregável por conta própria, com critérios de aceitação explícitos. Marque cada ticket como [ ] por enquanto." Isso me deu de T-001 a T-008, situados sob uma seção de especificações técnicas que explica como estamos entregando o PRD.

Só então o código da funcionalidade é escrito. E cada sessão de implementação começa da mesma maneira.

Como é uma Sessão Retomada

Read docs/PRD.md and docs/ERD.md.
Pick up the next unfinished ticket. Implement it using TDD. Commit atomically.
When the ticket’s acceptance criteria are met, mark it done in the ERD with any notes future tickets will need, then stop.

Esse é todo o briefing. Sem reexplicações. Sem "lembre-se quando decidimos…". O ERD tem o próximo ticket e o contexto técnico ao redor dele. O PRD tem o porquê. O Claude tem tudo o que precisa no diretório de trabalho.

Quando a sessão termina, o ERD já está atualizado, porque atualizá-lo faz parte da conclusão do ticket. A próxima sessão abre com o mesmo briefing e se encontra um ticket à frente.

Meus pensamentos sobre experimentar este fluxo

O Claude é excelente em executar um ticket bem especificado e medíocre em reconstruir um projeto inacabado a partir do histórico do chat. Então eu paro de pedir que ele faça a segunda coisa.

O modo de planejamento mais a lente de DDD força as ambiguidades a virem à tona antes que qualquer código exista para defendê-las. O PRD e o ERD então capturam essa conversa em uma forma que sobrevive aos limites da sessão. Juntos, eles tornam cada sessão retomável, cada subagente instruível e cada Claude paralelo utilmente independente.

O planejamento não é um custo extra. É o que faz projetos longos sobreviverem a sessões curtas.

We want to work with you. Check out our Services page!