🧠 O que e Outcome Delegation (vs Imperativo)
Outcome Delegation e uma mudanca fundamental na forma como voce escreve prompts. Em vez de dar instrucoes passo a passo (imperativo), voce descreve o resultado final desejado e os criterios de sucesso (declarativo). O Claude escolhe o caminho. E como a diferenca entre dizer a um taxi "vire a direita, depois a esquerda" versus "me leve ao aeroporto".
🎯 Conceito Principal
A diferenca fundamental entre os dois estilos:
- • Por que funciona melhor: O Claude em 2026 conhece milhoes de implementacoes. Quando voce descreve o resultado, ele escolhe a melhor abordagem para SEU projeto especifico
- • Imperativo limita: Ao dizer "use bcrypt", voce impede o Claude de sugerir argon2 se for mais adequado. Ao dizer "crie auth.ts", voce impede uma estrutura de arquivos melhor
- • Outcome liberta: Voce define O QUE e as restricoes. O Claude decide COMO, usando seu conhecimento do projeto, das convencoes e das melhores praticas
- • Nao e "faca qualquer coisa": Outcome Delegation e preciso no resultado. O que muda e que voce nao microgerencia o caminho
💡 Dica Pratica
Comece praticando com tarefas que voce ja sabe resolver. Escreva o prompt imperativo como faria normalmente, depois reescreva como outcome delegation. Compare os resultados. Na maioria dos casos, o outcome delegation gera codigo melhor porque o Claude tem liberdade para aplicar patterns que voce talvez nao conheca.
Regra pratica: se voce esta dizendo ao Claude QUAL funcao criar e QUAL biblioteca usar, voce esta sendo imperativo demais. Descreva o comportamento, nao a implementacao.
🔄 De Imperativo para Declarativo (Rewriting)
A transicao de imperativo para declarativo nao acontece da noite para o dia. Existe uma tecnica de rewriting em 3 passos que facilita a conversao. Voce pega qualquer prompt imperativo e transforma sistematicamente em outcome delegation.
🎯 Conceito Principal
Os 3 passos para converter qualquer prompt imperativo em outcome delegation:
- • Passo 1 - Resultado: Pergunte "o que muda para o usuario final?" Em vez de "add debounce", o resultado e "search nao dispara em cada tecla"
- • Passo 2 - Criterios: Como voce sabe que funcionou? Definicoes mensuráveis e observaveis. "300ms de delay" e um criterio. "Funciona bem" nao e
- • Passo 3 - Restricoes: Nao diga COMO resolver (use lodash debounce). Diga o que NAO pode acontecer (no new dependencies). O Claude encontra o melhor caminho dentro das restricoes
💡 Dica Pratica
Quando voce pegar um prompt imperativo para reescrever, faca o "teste do taxi": imagine que voce esta delegando para um developer senior que conhece o projeto. Voce diria "crie um arquivo auth.ts com funcao login usando bcrypt"? Ou diria "preciso de autenticacao segura, os usuarios devem poder fazer login e acessar rotas protegidas"?
O segundo e outcome delegation. Voce confia na competencia do Claude e foca no resultado, nao no passo-a-passo.
📋 Definindo Resultados Esperados
A qualidade do outcome delegation depende diretamente da clareza com que voce descreve o resultado. Um resultado vago gera codigo vago. Um resultado preciso gera codigo preciso. Neste topico, voce aprende a estruturar resultados que nao deixam margem para interpretacao errada.
🎯 Conceito Principal
Use o framework OSCAR para definir resultados claros:
- • Outcome preciso: "Users can reset their password via email" e claro. "Improve password functionality" e vago. Quanto mais especifico o outcome, melhor o resultado
- • Scope definido: "Affects auth module and email service. Does not touch user profile or settings." Isso evita que o Claude modifique areas que voce nao quer
- • Constraints explicitas: "Existing login flow must not change. Token expiration stays at 24h." Constraints previnem efeitos colaterais indesejados
- • Acceptance verificavel: "Test: request reset, receive email within 30s, click link, set new password, login with new password succeeds." O Claude pode auto-verificar
💡 Dica Pratica
Voce nao precisa usar o framework OSCAR completo em toda tarefa. Para tarefas simples, Outcome + Acceptance ja e suficiente. Reserve o framework completo para features complexas que tocam multiplos modulos.
Dica: adicione OSCAR como template no seu CLAUDE.md. O Claude aprendera a pedir essas informacoes quando voce der prompts vagos, criando um loop de feedback positivo.
✅ Criterios de Sucesso Embutidos
Criterios de sucesso embutidos sao a arma secreta do outcome delegation. Em vez de verificar manualmente se o Claude fez certo, voce inclui os criterios no proprio prompt e o Claude se auto-verifica. Isso reduz dramaticamente o ciclo de "faz, revisa, pede correcao, revisa de novo".
🎯 Conceito Principal
Criterios de sucesso podem ser funcionais, tecnicos e negativos (o que NAO deve acontecer):
- • Criterios funcionais: O que o usuario final observa. Sao os mais importantes e os mais faceis de verificar
- • Criterios tecnicos: Testes, linting, performance. O Claude pode verificar automaticamente rodando os comandos
- • Criterios negativos: "Must NOT" e tao importante quanto "must". Previne regressoes e efeitos colaterais
💡 Dica Pratica
A frase magica e "Verify all criteria before marking complete". Isso faz o Claude rodar testes, checar linting e verificar cada criterio antes de dizer que terminou. Sem essa frase, ele pode pular a verificacao.
Comece com 3-5 criterios por tarefa. Muitos criterios sobrecarregam o contexto. Poucos criterios deixam margem para erros. O sweet spot e suficiente para cobrir o essencial sem ser excessivo.
🔀 Exemplos Praticos de Conversao (Before/After)
Nada ensina melhor que exemplos reais. Aqui estao conversoes praticas de prompts imperativos para outcome delegation, cobrindo cenarios comuns do dia-a-dia com Claude Code.
🎯 Conceito Principal
5 conversoes do mundo real, do imperativo para outcome delegation:
- • CRUD: Note que o "depois" nao menciona Express, Prisma ou Jest. O Claude usa o que ja esta no projeto. Se o projeto usa Fastify e Drizzle, ele usa Fastify e Drizzle
- • Bug Fix: Em vez de "add null check" (que pode nao ser a melhor solucao), o outcome descreve o comportamento desejado. O Claude pode resolver com null check, default value, ou reestruturacao
- • Performance: Em vez de "use Redis" (pode nao ser a melhor opcao), o outcome define o target de performance. O Claude pode usar Redis, in-memory cache, CDN, ou otimizar a query
💡 Dica Pratica
Pratique o "rewrite mental" sempre que for escrever um prompt. Antes de enviar, pergunte: "Estou descrevendo o resultado ou o caminho?" Se voce esta dizendo ao Claude qual funcao criar, qual biblioteca usar ou qual arquivo editar, voce esta sendo imperativo.
Excecao: se voce tem uma razao especifica para uma tecnologia ("use Redis because we already have it in production"), inclua como constraint, nao como instrucao. "Constraint: we already run Redis in production, prefer it for caching."
⚖️ Quando Usar e Quando Nao Usar
Outcome Delegation nao e a resposta para tudo. Existem situacoes onde o estilo imperativo e mais eficiente e situacoes onde o declarativo brilha. Saber quando usar cada estilo e o que separa um usuario avancado de um intermediario.
🎯 Conceito Principal
Guia de decisao para escolher o estilo certo:
- • USE Outcome Delegation quando: A tarefa e complexa (multiplos arquivos), voce nao tem certeza da melhor implementacao, quer que o Claude use convencoes do projeto, ou quer resultados de nível senior
- • USE Imperativo quando: Voce sabe EXATAMENTE o que quer (rename de variavel, fix pontual), a tarefa e trivial (menos de 5 linhas), ou voce precisa de uma implementacao especifica por razoes tecnicas
- • USE Hibrido quando: Voce quer outcome delegation mas com restricoes especificas. "Outcome: X. Constraint: must use Y approach because Z." Isso combina liberdade com direcao
- • EVITE Outcome para: Tarefas de infraestrutura muito especificas (configuracao de CI/CD), mudancas que exigem formato exato (migrations SQL), ou quando voce tem um padrao obrigatorio do time
Regra geral: Se a tarefa leva mais de 10 minutos para descrever imperativamente, use outcome delegation. Se leva menos de 1 minuto, use imperativo. No meio? Use hibrido.
💡 Dica Pratica
Na pratica, a maioria dos seus prompts sera hibrida. Voce define o outcome (declarativo) mas inclui constraints importantes (diretivas). "I need a notification system. Users get notified of new messages in real-time. Constraint: use WebSocket because we already have the infrastructure. Must NOT use polling."
O objetivo nao e eliminar o imperativo. E ter mais uma ferramenta no seu arsenal. Com o tempo, voce vai sentir naturalmente qual estilo e mais adequado para cada situacao.
Exercicio Pratico
Reescrever 5 prompts imperativos como outcome delegation
Pegue 5 prompts que voce ja usou com Claude Code (ou invente cenarios reais) e converta:
- 1. Escreva 5 prompts no estilo imperativo (como voce normalmente faria). Tente cobrir: feature nova, bug fix, refactoring, performance e teste
- 2. Reescreva cada um usando os 3 passos de conversao (Resultado, Criterios, Restricoes)
- 3. Rode os 5 prompts imperativos e os 5 declarativos no Claude Code no mesmo projeto. Compare os resultados
- 4. Para cada par, anote: qual gerou codigo melhor? Qual foi mais facil de escrever? Qual exigiu menos correcoes depois?
- 5. Identifique quais dos 5 cenarios funcionaram melhor com outcome delegation e quais com imperativo
✅ Criterios de Sucesso
📋 Resumo do Modulo
Proximo Modulo:
4.8 - Verificacao e Prompts Auto-validantes