Um pedido grande ou vários menores: como dividir a tarefa antes de falar com o Claude Code

Você escreve um prompt gigante, aperta enter e vai tomar um café

Volta, e tem um diff enorme na tela, mexendo em arquivo que você nem sabia que existia

Aí vem a pergunta chata: você vai MESMO revisar isso, ou vai só aceitar e torcer? 😅

A decisão real aqui não é entre prompt curto e prompt longo

É entre um pedido que você consegue conferir e um pedido que você aceita no escuro

E é isso que a gente vai resolver neste post: como dividir tarefas no Claude Code de um jeito que cada entrega caiba numa revisão sua, sem virar burocracia

Quando cada formato funciona melhor

Antes de fatiar qualquer coisa, vale olhar os sinais

Nem toda tarefa merece plano, e nem toda tarefa aguenta um pedido direto

A documentação oficial de boas práticas resume isso numa régua muito boa: se você consegue descrever o diff em uma frase, pule o plano

É literalmente o teste que eu faço antes de abrir a boca com o agente

"Trocar o texto do botão de enviar", uma frase, sem plano

"Adicionar autenticação e ajustar o dashboard e limpar aquele serviço legado", opa, aí não é uma frase, são três tarefas se escondendo dentro de um prompt

O antipadrão que a própria doc marca:

A doc oficial pede pra você NÃO misturar tarefas não relacionadas em um único pedido

O exemplo ruim que ela usa é exatamente esse tipo de frase: "corrija estes dois bugs, melhore a interface e otimize a performance"

E o resultado provável também está lá: bug parcialmente corrigido, pouca atenção à interface e alterações confusas

Não é que o modelo seja burro, é que você pediu quatro coisas e deu uma chance só de acertar todas

O que definir antes de abrir o Claude Code

Aqui é a parte que quase todo mundo pula

Antes do primeiro prompt, tenha escrito (nem que seja num bloco de notas):

• Resultado esperado, em texto, do que precisa existir quando terminar
• Prova de conclusão, uma verificação ponta a ponta que mostra que a funcionalidade funciona de verdade
• Arquivos e interfaces envolvidos, com nome, não "o módulo de login"
• O que está fora de escopo, pra não voltar diff surpresa
• Critérios de aceite, declarados antes de começar a editar

Por que antes e não depois? Porque declarar critério de aceite no começo é mais eficiente do que várias rodadas de revisão depois

Rodada de correção é cara em atenção sua, não só em execução da máquina

E tem um efeito colateral bom: quanto mais precisa a instrução (arquivos específicos, restrições, padrões de exemplo pra seguir), menos correção você precisa fazer depois

Se você ainda está na dúvida sobre se a tarefa vale delegar, resolve isso primeiro, porque fatiar uma tarefa que nem devia ir pro agente é só perder tempo com mais organização

Como dividir a tarefa, passo a passo

1. Escreva o resultado esperado e a prova de conclusão

A recomendação oficial é definir o resultado e a prova de conclusão ANTES de qualquer edição, e usar um plano quando o trabalho tem dependências ou risco material

A prova é o que te salva do "parece pronto": não é "o código compila", é "eu crio uma conta, faço login e vejo meu nome no header"

O erro comum deste passo: escrever resultado vago tipo "melhorar o fluxo de login", que não dá pra provar nem pra reprovar

2. Transforme isso numa spec autocontida

As specs mais úteis citam os arquivos e interfaces envolvidos, dizem o que está fora de escopo e terminam com um passo de verificação ponta a ponta

Algo assim:

Objetivo: tela de login com e-mail e senha
Arquivos: src/auth/login.tsx, src/auth/session.ts
Fora de escopo: dashboard, recuperacao de senha, OAuth
Verificacao: subir o projeto, criar conta, logar e ver o nome do usuario no header

Se a spec ficar gorda demais pra caber numa entrega só, o caminho é dividir em specs menores em vez de espremer tudo num prompt

O erro comum deste passo: prompt sem arquivo e sem restrição, aí o agente escolhe por você e escolhe diferente do que você faria

3. Para iniciativa maior, registre num arquivo

A doc oficial recomenda guardar escopo, decisões, questões abertas e critérios de aceite em um plan.md ou tasks.md

Isso vira sua fonte de verdade entre uma fatia e outra, principalmente quando você limpa o contexto no meio do caminho

O erro comum deste passo: deixar as decisões só no histórico do chat, que é justo a coisa que você vai jogar fora daqui a pouco

4. Separe exploração e planejamento da execução

A orientação oficial é não deixar o Claude ir direto pro código, porque assim ele pode gerar código que resolve o problema errado

No Claude Code você entra no modo de plano com Shift+Tab (que alterna entre os modos de permissão) ou prefixando um único prompt com /plan

/plan implementar login com e-mail e senha em src/auth/, sem tocar no dashboard

Apertar Shift+Tab de novo sai do modo de plano sem aprovar o plano

E quando você aprova, a sessão sai do modo de plano e passa pro modo de permissão da opção de aprovação que você escolheu, e aí o Claude começa a editar

O fluxo típico descrito na doc é esse mesmo: entrar no modo de plano, refinar o plano, trocar para aceitar edições automaticamente e deixar executar

O erro comum deste passo: aprovar plano bonito sem critério de aceite dentro dele, o plano vira só uma lista de intenções

5. Execute uma fatia por vez

Plano pronto não é autorização pra mandar construir tudo de uma vez

Uma fatia, um pedido, sem carona de tarefa não relacionada

Tem outro detalhe que a doc alerta e que dói na prática: pedir pro agente "investigar tudo" e depois esperar implementação focada não funciona bem, porque saídas grandes de comando e leituras exploratórias longas ocupam o contexto que a mudança precisa

Ou seja, investigação ampla no mesmo contexto compete com a implementação

O erro comum deste passo: emendar "e já aproveita e arruma aquilo ali" no fim do prompt 😛

6. Revise cada fatia em contexto novo

Aqui mora a parte que mais muda a qualidade da revisão

Quando o Claude Code aciona um subagente pela ferramenta Agent, esse subagente roda numa janela de contexto própria e isolada, e só o relatório final volta pra conversa principal

Na prática, um revisor em contexto novo vê só o diff e os critérios que você passou, não o raciocínio que gerou a mudança

É revisão sem herdar as suposições de quem escreveu o código, sacou? Bem diferente de perguntar "tá certo?" pra mesma conversa que acabou de te entregar o código

Tem uma skill embutida pra isso, que revisa o diff atual em busca de bugs num subagente novo e devolve os achados pra sessão:

/code-review

E tem o padrão citado na doc de usar um subagente pra revisar o diff contra o PLAN.md, conferindo se todo requisito foi implementado, se os casos de borda listados têm testes e se nada fora do escopo da tarefa mudou

Se quiser um revisor seu, subagentes personalizados são arquivos markdown em .claude/agents/ (nível de projeto, compartilhado com o time) ou ~/.claude/agents/ (nível de usuário, disponível em todos os projetos)

O erro comum deste passo: revisar a fatia na mesma conversa que a produziu, e receber de volta a mesma justificativa que já te convenceu antes

7. Faça higiene de contexto entre as fatias

Fatia entregue e validada? Limpa a mesa antes da próxima

/clear

O /clear reseta a conversa pra um contexto vazio mantendo a memória do projeto, e a conversa anterior continua salva em disco

Se você ainda precisa do fio da meada, o /compact pede ao modelo um resumo da conversa e substitui o histórico por esse resumo, e ele aceita instrução junto:

/compact foca nas decisoes de autenticacao e descarta a investigacao de build

E quando a fatia saiu errada mesmo, Esc duas vezes ou /rewind abre o menu de rewind, que permite restaurar o estado anterior da conversa e do código

O erro comum deste passo: seguir pra próxima fatia arrastando trinta mil tokens de investigação que já não servem pra nada

Três tipos de trabalho, três formas de fatiar

A doc oficial nomeia fluxos diferentes pra tipos diferentes de trabalho, e o ponto de conferência muda em cada um

Feature nova: explore, plan, code, commit

Primeiro entender o código, depois planejar, depois codar, depois commitar

O ponto de conferência é o plano: se você não consegue apontar qual arquivo muda e qual é a verificação final, o plano ainda não está pronto pra aprovar

Trabalho algorítmico: TDD

Quando a regra é fechada e dá pra descrever o certo e o errado, o teste vira sua prova de conclusão

O ponto de conferência sai do diff e vai pro teste: o caso de borda que você listou tem teste, ou só tem o caminho feliz?

Mudança de interface: iteração visual

Aqui você compara o resultado com o que queria ver, e ajusta em ciclos

O ponto de conferência é a tela, não o código, e é justo por isso que interface não deve andar de carona num prompt de bug, ela sempre fica pra trás

O que muda quando a IA planeja antes de codar

No vídeo abaixo eu testo a Verdent AI, e o interessante é que comecei o projeto pela etapa de planejamento em vez de mandar o pedido de código direto

Escrevi um prompt descrevendo o produto inteiro, um encurtador de URL com login, link curto, redirecionamento, registro de cliques e dashboard com gráficos, e pedi ajuda pra planejar antes de codar

Já defini a stack no próprio prompt de planejamento, pra manter o escopo simples, porque isso limita o que a IA propõe

Aí veio o plano completo na mão

E mesmo com o plano completo eu NÃO mandei construir tudo de uma vez

Preferi escrever meus próprios prompts, fatiando o plano em tarefas menores, por dois motivos: plano completo tende a gerar coisa que você não pediu e esbarra em limite de tokens, e pra um MVP boa parte do que foi planejado nem precisava ser feita agora

A primeira fatia foi a autenticação, por ser a base do sistema, e descrita com entregável concreto: tela de login com e-mail e senha, tela de registro, e header no dashboard com nome do usuário e botão de sair

Assim que ficou pronta eu testei na hora: subi o projeto, criei conta e fiz login pra confirmar que a autenticação funcionava antes de seguir

Só depois de validar a base pedi o coração do produto na segunda fatia, também detalhada: colar URL longa e receber link curto, escolher slug ou deixar automático, redirecionar e registrar o clique, e no dashboard ver os links, total de cliques, botão de copiar, edição e exclusão

Teve percalço, claro: o servidor caiu quando eu atualizei a página, e resolvi pedindo pra ferramenta subir o projeto de novo

Outra coisa que notei: quando existe um planejamento grande por trás, a execução demora mais que o normal

Pra escolher a fatia seguinte eu usei a sugestão de próximo passo da própria ferramenta (uma página de analytics detalhada por link) em vez de abrir uma tarefa genérica

E isso não é papo de ferramenta específica, eu trabalho assim em qualquer uma

Entrega parcial e concreta é mais previsível, e eu sei exatamente o que testar a cada passo

No Claude Code o espelho disso é o modo de plano: ver o plano antes muda o que você aprova, e muda o tamanho do diff que vai cair na sua frente depois

No vídeo você vê o projeto nascendo pelo planejamento e sendo entregue por fatias testáveis, uma de cada vez

Conclusão

O critério de decisão cabe numa linha: se você consegue descrever o diff em uma frase, peça direto, se não consegue, fatie e planeje

O resto é consequência disso: resultado escrito, prova de conclusão, arquivos e restrições no prompt, uma fatia por vez, revisão em contexto novo e limpeza entre as etapas

Pega a próxima tarefa da sua semana e faz o exercício agora: escreve o resultado esperado e a prova de conclusão, abre o modo de plano, e só aprova quando a primeira fatia couber numa revisão SUA, de verdade

Se não couber, corta de novo 🙂

até o próximo post!