🧠 O overplanning — quando o modelo pensa demais
🧠 Imagine assim: um estagiário brilhante, quando ganha mais tempo e mais autonomia, às vezes usa esse tempo pra pesquisar contexto que ninguém pediu, revisar decisões já tomadas ou "só confirmar" algo óbvio de novo. O overplanning no Fable 5 é essa mesma tendência — e ela aparece justamente porque o modelo é capaz demais pra "desligar" o raciocínio cedo.
O Claude Fable 5 tem muito mais fôlego de raciocínio que os modelos anteriores: ele mantém uma instrução por dias, revisa sistemas inteiros e cruza dezenas de arquivos antes de mexer numa linha. Esse mesmo fôlego, aplicado numa tarefa rotineira, vira desperdício — o modelo pesquisa mais do que precisa, delibera sobre alternativas que não importam e demora pra começar a agir de fato.
Isso não é um defeito escondido: é efeito colateral direto do effort alto, que é o default. Em effort alto, o comportamento certo pra um problema difícil vira exagero numa tarefa simples — e o Fable 5, por padrão, roda em effort alto.
📚 Citação oficial — doc "Prompting Claude Fable 5"
Sobre por que isso acontece justamente em trabalho rotineiro sob effort alto:
"On routine work at higher effort, Claude Fable 5 can gather context and deliberate beyond what the task needs..."
Em 1 frase: quanto mais forte o modelo, mais ele precisa de instrução explícita pra saber quando parar de pensar e começar a agir.
🟢 O prompt oficial anti-overplanning: "Deixe agir"
🎯 A ideia central
O antídoto pro overplanning não é pedir "seja mais rápido" (vago demais pro modelo agir sobre isso) — é dizer exatamente quando parar é obrigatório. Tudo que não se encaixa nesse critério, o Fable 5 deve simplesmente fazer, sem pausa.
- •Ação destrutiva ou irreversível → para e pergunta
- •Mudança real de escopo → para e pergunta
- •Informação que só o usuário tem → para e pergunta
- •Qualquer outra coisa → age, e termina o turno com trabalho, não com uma promessa
Repare no que o prompt oficial NÃO faz: ele não lista comportamentos ("não pergunte antes de ler arquivo", "não pergunte antes de rodar teste"...). Ele dá um critério — destrutivo/irreversível, mudança de escopo real, ou dado que só o usuário sabe — e deixa o modelo aplicar esse critério em qualquer situação nova. É a mesma lógica de "dê o porquê" (módulo 1.2), só que virada pra dentro: o "porquê" de quando parar.
Objetivo: parar de esperar aprovação pra cada micro-decisão reversível (ler arquivo, rodar teste, criar branch, refatorar dentro do escopo pedido) e reservar a pausa só pra quando ela é realmente necessária.
Pause for the user only when the work genuinely requires them: a destructive or irreversible action, a real scope change, or input that only they can provide. If you hit one of these, ask and end the turn, rather than ending on a promise.
Pause para o usuário só quando o trabalho realmente exigir isso: uma ação destrutiva ou irreversível, uma mudança real de escopo, ou uma informação que só ele pode fornecer. Se você encontrar um desses casos, pergunte e encerre o turno — em vez de terminar numa promessa.
Como verificar: cole a versão em inglês (a oficial) no CLAUDE.md ou no system prompt do projeto. Nas próximas sessões, observe se o Fable 5 executa passos reversíveis (ler, testar, criar branch) direto — e se ele SÓ para quando a ação é de fato destrutiva/irreversível, muda o escopo, ou depende de algo que só você sabe. Se ele parar de perguntar "posso continuar?" no meio de tarefas rotineiras, o prompt está funcionando.
✓ O que FAZER
- ✓Deixar o modelo terminar o turno com um resultado real (arquivo mudado, teste rodado)
- ✓Confiar em ações reversíveis (leitura, teste, branch, lint)
- ✓Reservar a pausa só pro destrutivo/irreversível/escopo/decisão-do-usuário
✗ O que EVITAR
- ✗Pedir confirmação pra cada leitura de arquivo ou execução de teste
- ✗Terminar o turno numa promessa ("vou fazer X agora") em vez de num resultado
- ✗Tratar toda mudança como se fosse irreversível "por precaução"
Em 1 frase: pause só quando a ação é destrutiva, muda o escopo, ou depende do usuário — o resto, faça.
🗺️ Plan mode: quando ainda vale a pena
🧠 Imagine assim: plan mode é o agente parando pra desenhar o mapa antes de andar. Faz sentido num território desconhecido. É perda de tempo quando o caminho já é óbvio — e o tópico 2 já resolve o "óbvio" sem precisar de mapa nenhum.
O erro comum é tratar plan mode como hábito padrão — abrir ele pra toda tarefa "só por segurança". Isso reintroduz exatamente o problema do tópico 1: o modelo delibera antes de agir, mesmo quando a tarefa já era clara o suficiente pra simplesmente fazer.
O teste prático é simples: a tarefa é genuinamente ambígua (múltiplos caminhos razoáveis, não dá pra saber qual sem decidir antes), é grande (toca dezenas de arquivos, muda arquitetura) ou pode mudar o rumo do projeto? Se sim, plan mode paga o preço da pausa. Se não — que é a maioria das tarefas do dia a dia — deixar agir (tópico 2) já é a resposta certa.
Olhe pro losango: é o único teste que importa. Se a resposta é "não" — o caso mais comum — o Fable 5 deve seguir direto pra ação, sem abrir plan mode por hábito.
✅ Vale a pena usar plan mode
- ✓Tarefa realmente ambígua: mais de um caminho razoável, precisa decidir antes de tocar em código
- ✓Mudança grande: dezenas de arquivos, migração, troca de arquitetura
- ✓Decisão que é cara de desfazer se sair errada
⏸️ Só atrapalha
- ✗Bug fix pontual, ajuste de estilo, tarefa com um caminho óbvio
- ✗Qualquer coisa que o tópico 2 ("deixe agir") já cobre sozinho
- ✗Usar plan mode "por costume", sem checar se a tarefa exige mesmo
Observação de quem usa isso todo dia: não é só teoria de curso — vários criadores de conteúdo que testam agentes de IA como parte do trabalho relatam o mesmo ajuste: pararam de abrir plan mode por hábito e passaram a reservá-lo só pra tarefas realmente grandes ou ambíguas. No resto do tempo (a maioria), "deixe agir" já resolve sozinho.
🔍 O problema da confiança cega
🧠 Imagine assim: você não confia num colega novo só porque ele disse "terminei" — você confia depois de ver o pull request, rodar o teste, conferir o resultado. Com um agente é igual: "terminei" é uma alegação, não um fato. O fato é a evidência por trás dela.
Deixar o modelo agir sem parar pra cada passo (tópico 2) só é seguro se o fim da história tiver uma prova de verdade. Sem isso, "deixe agir" vira "confie cegamente" — e aí o risco vira o oposto do que você queria: menos pausa, mas nenhuma garantia de que o trabalho relatado é real.
O relatório de "terminei" pode estar certo, pode estar otimista, ou pode ser fabricado sem intenção — o modelo generaliza a partir do que "deveria" ter acontecido, não do que de fato aconteceu na ferramenta. A única forma de saber a diferença é auditar a alegação contra uma evidência concreta desta sessão: um resultado de teste, um diff, um log.
Delegar a tarefa
Você pede, o agente executa sem parar (tópico 2).
Nesse ponto você ainda não sabe se o trabalho foi feito direito — só sabe que ele rodou.
O agente diz "terminei"
Um relatório final, em texto, otimista por natureza.
É uma alegação — ainda não é prova de nada.
Sem checar, você já confiaria?
Com um colega humano novo, a resposta seria não.
Com um agente, o instinto é confiar rápido demais — exatamente o ponto cego que este tópico ataca.
Confiança real = evidência checada
O tópico 5 resolve isso com um prompt oficial.
Só depois de ver o teste passar, o diff correto, o log limpo, a alegação "terminei" vira fato.
💡 Dica prática
Antes de aceitar qualquer "terminei", pergunte de volta: "aponte a evidência exata desta sessão que confirma isso" (um output de teste, um diff, um log). Se o agente não conseguir apontar nada concreto, é sinal de que o trabalho ainda não está verificado — mesmo que pareça pronto no texto.
📋 O prompt oficial de verificação: "Prove que terminou"
Este é o segundo prompt oficial da dupla deste módulo — e ele fecha o ciclo aberto no tópico 4. Em vez de pedir "seja honesto" (vago, o modelo já "acha" que está sendo honesto), o prompt define um procedimento de auditoria: cada alegação de progresso precisa apontar pra um resultado real desta sessão antes de ser reportada.
Objetivo: eliminar relatórios de status fabricados — fazer o agente reportar só o que ele consegue provar com uma saída de ferramenta real, e admitir explicitamente o que ainda não foi verificado.
Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.
Antes de reportar progresso, audite cada alegação contra um resultado de ferramenta desta sessão. Só reporte o trabalho que você consegue apontar evidência; se algo ainda não foi verificado, diga isso explicitamente. Reporte os resultados com fidelidade: se os testes falharem, diga isso com a saída; se uma etapa foi pulada, diga que foi; quando algo estiver pronto e verificado, afirme isso claramente, sem hesitar.
Como verificar: cole a versão em inglês (a oficial) no CLAUDE.md ou no system prompt, junto do prompt do tópico 2. Peça uma tarefa com passos checáveis (rodar suite de testes, aplicar um diff) e observe o relatório final: ele deve citar o resultado exato (ex.: "5 de 5 testes passaram, saída: ...") em vez de "tudo funcionando" genérico — e deve admitir de forma explícita qualquer parte não verificada, em vez de omitir.
📊 Resultado empírico (Anthropic)
A própria Anthropic testou este prompt em tarefas desenhadas de propósito pra induzir relatório fabricado:
"In Anthropic's testing, this nearly eliminated fabricated status reports even on tasks designed to elicit them."
Siga a seta tracejada em ciano voltando do "Relatório" pro "Agir": é o loop se repetindo. Nenhum passo pula direto de "Agir" pra "Relatório" sem passar pela auditoria contra o tool result.
🛡️ Verificação por subagent supera auto-crítica
🧠 Imagine assim: pedir pro mesmo agente que escreveu o código também revisar o próprio código é como pedir pro autor de um texto ser o único revisor dele — ele já decidiu que está bom, e tende a confirmar as próprias escolhas. Um subagent com contexto fresco não tem esse viés: ele só vê a especificação e a evidência, não a narrativa de quem fez o trabalho.
Em tarefas longas, checar o próprio trabalho a cada passo é caro — mas não checar nunca deixa erros se acumularem até o fim, quando já custam mais caro pra corrigir. A saída oficial é combinar as duas coisas: um ritmo de verificação definido de antemão, delegado a um subagent separado.
Objetivo: estabelecer um checkpoint de verificação regular em tarefas longas, feito por um subagent com contexto fresco em vez de auto-avaliação do próprio agente que construiu a solução.
Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification.
Estabeleça um método pra checar o seu próprio trabalho a um intervalo de [X] enquanto você constrói. Rode isso a cada [intervalo X], verificando seu trabalho com subagents contra a especificação.
Como verificar: substitua [X] (na versão em inglês, a que deve ir pro seu prompt) por um intervalo concreto do seu contexto (ex.: "a cada 3 arquivos modificados" ou "a cada 20 minutos de trabalho agêntico") e cole no system prompt de uma tarefa longa. Confirme que, nesse intervalo, o agente de fato dispara um subagent verificador separado — não apenas reafirma pra si mesmo que "está tudo certo" — e que esse subagent cita a especificação original ao apontar divergências.
📚 Por que o verificador externo vence
Citação oficial (doc "Prompting Claude Fable 5"):
"Separate, fresh-context verifier subagents tend to outperform self-critique."
A razão é estrutural, não é sobre o modelo "ser mais rigoroso": quem escreveu a solução carrega, no próprio contexto, todo o raciocínio que levou às escolhas feitas — e tende a reconfirmar essas escolhas ao invés de questioná-las. Um subagent que nunca viu esse raciocínio, só a especificação e a evidência, não herda esse viés de confirmação.
⚠️ O risco de pular esta etapa
Sem um verificador de contexto fresco, você depende só da auto-avaliação do mesmo agente que fez o trabalho — a raposa cuidando do galinheiro. Combinado com o tópico 2 ("deixe agir"), isso pode acumular decisões erradas por muitos passos antes de alguém perceber. O checkpoint com subagent é o que torna seguro deixar o Fable 5 trabalhar por longos períodos sem supervisão constante.
Em 1 frase: defina um intervalo de checagem e delegue-o a um subagent fresco — ele desconfia por natureza, o autor original não.
🧾 Resumo do Módulo
Próximo módulo:
1.5 — Diga menos, não mais: por que instruções enxutas guiam melhor o Fable 5 do que listas exaustivas de comportamento.