Uma tarefa por prompt ou várias de uma vez no Claude Code: qual formato rende mais?

A tentação é sempre a mesma: você abre o terminal com cinco coisas na cabeça e despeja as cinco no mesmo prompt 😀

Parece produtivo, né?

Só que o formato do pedido não mexe só com a velocidade

Ele mexe com o TAMANHO do diff que volta e, principalmente, com a chance real de você revisar aquilo com honestidade

Um pedido único devolve uma mudança que cabe na cabeça

Uma lista de cinco tarefas devolve um bloco grande, e bloco grande a gente aprova no olho, sejamos sinceros haha

Bora comparar os dois formatos direito?

Uma tarefa por prompt x várias no mesmo prompt: comparação direta

Antes da tabela, um detalhe que muda tudo na conta: o Claude Code captura o estado do código automaticamente antes de cada prompt do usuário

Cada prompt enviado cria um novo checkpoint, e eles persistem entre sessões

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Ou seja: a unidade de "desfazer" do Claude Code é o PROMPT, não a tarefa

Juntou cinco tarefas num prompt? Elas viram um pacote só na hora de voltar atrás

Repara que nenhuma linha aí é sobre "qual é mais rápido"

É tudo sobre revisão

E vale o aviso antes que alguém se anime demais: o rewind do Claude Code só cobre edições feitas pelas ferramentas de edição de arquivo dele

O que um comando bash tocou fica invisível pra ele, assim como o que está atrás de um symlink

Então o checkpoint é uma rede de segurança, não um milagre

Quando agrupar tarefas no mesmo prompt faz sentido

Agrupar não é pecado, calma

O que estraga o agrupamento não é a quantidade, é a FALTA de relação entre as coisas

A lista única funciona bem em três cenários:

• Tarefas do mesmo escopo: mesma feature, mesmo módulo, mesmo bug, coisas que o Claude vai ler no mesmo lugar de qualquer jeito
• Correções pequenas e claras: a doc oficial de boas práticas do Claude Code cita corrigir um typo, adicionar uma linha de log e renomear uma variável como casos de pedir direto, sem plano
• Mudança multi-arquivo já planejada: se você passou pelo plan mode e o plano está aprovado, o lote deixou de ser um chute

Esse terceiro caso é o mais subestimado

No plan mode o Claude pesquisa e propõe as mudanças sem executá-las: ele lê arquivos e roda comandos de shell pra explorar, escreve um plano, mas não edita o código-fonte

Você troca o modo de permissão com Shift+Tab no CLI (ou pelo indicador de modo no VS Code e pelo seletor no Desktop)

Quando o plano fica pronto, ele te pergunta como prosseguir, e as opções são: sim usando auto mode, sim aprovando as edições manualmente, ou não, continuar planejando

Se quiser voltar a planejar, cicla com Shift+Tab de novo ou prefixa o próximo prompt com /plan

Aí sim o lote grande tem sentido: você já revisou a intenção antes de revisar o diff

Agora o contraponto

A própria doc descreve a kitchen sink session como erro comum: você começa com uma tarefa, pede algo sem relação, volta pra primeira, e o contexto fica cheio de informação irrelevante

A correção indicada é direta: /clear entre tarefas sem relação

Juntar "arruma o login" com "melhora o CSS do rodapé" com "escreve o README" não é lote

É bagunça 😛

Quando separar em um pedido por prompt

Separar vira a escolha óbvia quando você não sabe direito onde está pisando

A doc lista quando planejar compensa: abordagem incerta, mudança que altera múltiplos arquivos, ou código que você não conhece

Mesma lógica vale pro formato do prompt: se você não consegue prever o que vem de volta, não empilha pedido em cima de pedido

Tem mais três erros documentados que moram exatamente aqui:

• Correction spiral: o contexto se enche de tentativas falhas que o Claude segue referenciando
• Exploração sem escopo: ele lê centenas de arquivos sem produzir nada usável
• Excesso de revisão: revisa demais e puxa pro over-engineering

Os três ficam MUITO piores num prompt-lote, porque você não consegue isolar de onde veio a confusão

Separando, cada pedido ganha o próprio checkpoint e o rewind fica útil de verdade

O menu abre com /rewind ou com Esc duas vezes, mas só quando o campo de prompt está vazio

Tome cuidado: se tiver texto digitado, o Esc duplo limpa o texto em vez de abrir o menu

Dentro do menu você tem restaurar a conversa (volta a mensagem mantendo o código atual), restaurar o código (reverte os arquivos mantendo a conversa), resumir a partir dali, resumir até ali, e cancelar

As duas opções de restaurar só aparecem quando o checkpoint selecionado tem alterações de arquivo rastreadas

É como ter save point no jogo: quanto mais perto do chefão, menos você perde quando morre

E de novo, o lembrete chato: bash e symlink ficam de fora dessa reversão, então não confie nele pros rm -rf da vida

Se você já vive amarrando etapa em cima de etapa, vale olhar como isso se compara com um fluxo de prompts pronto em vez de fazer tudo na mão

O critério simples para decidir na hora

Não precisa de fórmula mágica aqui, precisa de uma pergunta só

1. Você consegue descrever o diff em uma frase? Se sim, pede direto e pula o plano, é o critério que a doc dá com todas as letras
2. As tarefas dividem o mesmo escopo? Mesmo arquivo, mesma feature, mesmo bug: pode agrupar. Assuntos diferentes: separa
3. Roda /context antes de empilhar mais pedido, ele mostra onde os tokens estão sendo gastos e te dá uma noção honesta de quão cheia está a janela
4. Trocou de assunto? /clear, o comando apaga o histórico da conversa e devolve um contexto limpo sem sair da sessão, mantendo a memória de projeto (CLAUDE.md) e as configurações
5. A subtarefa pode viver isolada? Manda pra um subagente, cada um roda na própria janela de contexto, com system prompt e ferramentas próprias, não enxerga o histórico da conversa principal e devolve só o resultado

O passo 5 é o pulo do gato pra quem odeia escolher entre os dois formatos

Você mantém a conversa principal limpa e ainda assim delega um bloco de trabalho inteiro

Se o seu problema é mais decidir o nível de esforço do que o tamanho do pedido, dá pra escolher entre /goal e ultracode com a mesma lógica de escopo

Veredito?

Um pedido por prompt como padrão, porque ele te dá o diff revisável e o checkpoint granular de graça

A condição pra agrupar: as tarefas precisam dividir escopo, ou serem pequenas e óbvias, ou já terem passado pelo plan mode

Fora disso, agrupar é só antecipar retrabalho

Conclusão

O formato do prompt não é uma escolha de velocidade

É uma escolha de REVISÃO

O lote grande parece que economiza tempo, mas ele empurra o custo pra frente: diff maior, contexto mais sujo e um rewind que leva junto o que já estava bom

O pedido único paga um pouquinho mais de digitação e devolve controle

Próximo passo, bem concreto: no seu próximo pedido, antes de apertar enter, tenta descrever o diff em uma frase

Conseguiu? Manda direto

Não conseguiu? Quebra em pedaços ou passa pelo plan mode antes

E quando mudar de assunto, /clear sem dó

Até o próximo post! =)