🎯 Por que dizer "não faça X" funciona
🧠 Imagine assim: voce da uma missao a um estagiario talentoso e diz so o que fazer, nunca o que nao fazer. Sem limites explicitos, ele preenche as lacunas do jeito dele — e "do jeito dele" pode incluir refatorar, adicionar testes, criar validacoes que ninguem pediu. Negative prompting e a lista de cercas que voce planta antes de comecar.
Um LLM funciona prevendo, um token de cada vez, qual e a continuacao mais provavel do texto ate agora. Isso significa que ele nao para exatamente onde a tarefa "termina" — ele continua ate achar que a resposta esta completa pelo seu proprio criterio. Em effort mais alto, esse criterio de "completo" fica mais generoso: o modelo reune mais contexto e delibera mais tempo antes de responder.
Isso nao e falha, e um efeito colateral de ser capaz e cuidadoso. O Fable 5, especialmente em tarefas de rotina com effort alto, pode decidir que a "resposta completa" para corrigir um bug inclui limpar o codigo ao redor, adicionar um refactor ou criar uma camada de validacao para um caso que nunca vai acontecer. Nada disso foi pedido — mas nada disso foi proibido tambem.
Negative prompting resolve isso na raiz: em vez de deixar o modelo adivinhar onde parar, voce diz explicitamente "nao faca X". Isso remove a ambiguidade que ele resolveria, por padrao, na direcao de "mais completo" — e devolve o controle do escopo pra voce.
📊 Dado tecnico (doc oficial de effort)
"Effort is a behavioral signal, not a strict token budget. At lower effort levels, Claude will still think on sufficiently difficult problems, but it will think less than it would at higher effort levels for the same problem." — quanto mais effort, mais espaco o modelo tem pra "ir alem"; e exatamente esse espaco que o negative prompting precisa conter.
Leitura do diagrama: o mesmo pedido, com effort alto, pode virar tres extras nao solicitados (esquerda) ou ficar so no escopo pedido quando ha negative prompting explicito (direita).
Em 1 frase: o modelo preve o proximo token ate achar que "terminou"; negative prompting define, por fora, onde esse "terminou" deve estar.
🚫 O prompt oficial anti-tidying
🧠 Imagine assim: isso nao e teoria de video, e um paragrafo tirado da propria documentacao oficial da Anthropic para o Fable 5. Cole direto no seu CLAUDE.md ou system prompt.
A doc oficial "Prompting Claude Fable 5" descreve exatamente o mecanismo do topico anterior, com as palavras da propria Anthropic:
"On routine work at higher effort, Claude Fable 5 can gather context and deliberate beyond what the task needs… To prevent unrequested tidying or refactoring at higher effort:"
E na sequencia, o bloco que a doc recomenda colar no system prompt ou no CLAUDE.md. E o negative prompting oficial contra "arrumacao" (tidying) e refactor nao pedido:
Don't add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper. Don't design for hypothetical future requirements: do the simplest thing that works well. Avoid premature abstraction and half-finished implementations. Don't add error handling, fallbacks, or validation for scenarios that cannot happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
Nao adicione funcionalidades, nao refatore nem introduza abstracoes alem do que a tarefa exige. Uma correcao de bug nao precisa de limpeza ao redor, e uma operacao pontual geralmente nao precisa de uma funcao auxiliar. Nao projete para requisitos hipoteticos futuros: faca a coisa mais simples que funcione bem. Evite abstracao prematura e implementacoes pela metade. Nao adicione tratamento de erro, fallbacks ou validacao para cenarios que nao podem acontecer. Confie nas garantias internas do codigo e do framework. Valide apenas nas fronteiras do sistema (entrada do usuario, APIs externas). Nao use feature flags ou atalhos de compatibilidade retroativa quando voce pode simplesmente mudar o codigo.
✗ Sem o prompt
- ✗Bug fix vem com "cleanup" ao redor
- ✗Aparecem helpers para um uso unico
- ✗Validacao para casos que nunca ocorrem
- ✗Feature flag para algo que podia so mudar
✓ Com o prompt
- ✓Diff minimo, so o necessario pro bug
- ✓Sem abstracao pra "requisito futuro"
- ✓Validacao so nas fronteiras reais do sistema
- ✓Muda o codigo direto, sem shim de compatibilidade
Em 1 frase: o prompt anti-tidying oficial da Anthropic corta refactor, abstracao e validacao nao pedidos direto na fonte.
🌀 Quando o Fable 5 "vai alem" sozinho
🧠 Imagine assim: nao e so refactor de codigo. O mesmo instinto de "ser prestativo alem do pedido" aparece em acoes fora do codigo — como rascunhar um email que ninguem pediu, ou criar uma rede de seguranca por conta propria.
Dois exemplos concretos ilustram bem o padrao. Nenhum dos dois e malicioso — os dois vem de uma intencao boa (ser cuidadoso, ser util) que simplesmente extrapolou o escopo do que foi pedido:
Rascunhar um email nao pedido
Voce pediu para investigar um problema com um fornecedor
Ao terminar a investigacao, o modelo decide que o proximo passo "logico" e comunicar o fornecedor — e ja deixa um rascunho de email pronto, sem ninguem ter pedido isso. E util? Talvez. Foi pedido? Nao.
Criar um branch de backup defensivo
Voce pediu para refatorar um modulo direto na branch principal
Antes de comecar, o modelo cria uma branch extra "so por seguranca", sem avisar e sem ter sido instruido a fazer isso. De novo: intencao boa (nao perder trabalho), mas uma acao que muda o estado do repositorio sem autorizacao explicita.
O padrao comum: em ambos os casos, o modelo decidiu sozinho que uma acao adjacente "faz parte" da tarefa. E exatamente isso que os dois prompts oficiais desta aula resolvem — o anti-tidying (topico 2) corta o excesso dentro do codigo, e o prompt de fronteiras (topico 4) corta o excesso fora do escopo pedido, incluindo acoes que mudam estado.
Em 1 frase: intencao boa + escopo indefinido = acao adjacente nao pedida; a solucao e declarar o escopo por escrito.
🧱 O prompt oficial de fronteiras (boundaries)
🧠 Imagine assim: tem uma diferenca enorme entre voce "pensar em voz alta" com um colega e voce "pedir pra ele executar algo". O prompt de fronteiras ensina o modelo a reconhecer essa diferenca — e a nao confundir as duas.
Esta e uma tecnica extra, que nao estava no video mas aparece na documentacao oficial da Anthropic: fronteiras explicitas (boundaries). Ela resolve o mesmo problema do topico 3, so que para o caso mais serio — acoes que mudam o estado do sistema (deletar, reiniciar, editar configuracao) sem confirmacao.
When the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one. Before running a command that changes system state (restarts, deletes, config edits), check that the evidence actually supports it.
Quando o usuario esta descrevendo um problema, fazendo uma pergunta ou pensando em voz alta em vez de pedir uma mudanca, o entregavel e a sua avaliacao. Reporte os achados e pare. Nao aplique uma correcao ate que peçam uma. Antes de rodar um comando que muda o estado do sistema (reiniciar, deletar, editar configuracao), confira se a evidencia realmente sustenta essa acao.
⚠️ Sem esse limite
Sem o prompt de fronteiras, "acho que essa configuracao esta errada" pode ser lido como "conserte essa configuracao" — e o modelo aplica a mudanca antes de voce confirmar que era isso que voce queria. Em comandos que reiniciam servico, deletam dado ou editam config, essa confusao custa caro.
Em 1 frase: descrever um problema nao e pedir uma correcao; o prompt de fronteiras faz o modelo respeitar essa diferenca.
⚖️ Quando SIM deve agir sem perguntar
🧠 Imagine assim: fronteira nao e sinonimo de paralisia. Um colega bom sabe distinguir "isso eu resolvo sozinho" de "isso eu preciso confirmar antes". A Fable 5 precisa do mesmo criterio, dito de forma explicita.
O prompt de fronteiras do topico 4 resolve o caso "descrevendo x pedindo". Mas falta o outro lado da moeda: uma vez que ele ja tem informacao suficiente pra agir, quando ele deve parar mesmo assim pra perguntar, e quando deve so seguir em frente? A doc oficial da Anthropic (na tecnica de anti-overplanning, aprofundada no modulo 1.4) da o criterio:
"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."
Traduzindo em criterio pratico: destrutivo ou irreversivel (deletar, sobrescrever, force push), mudanca real de escopo (o pedido original era X, e o proximo passo obvio seria Y — algo maior/diferente) ou informacao que so voce tem (uma decisao de negocio, uma preferencia pessoal) sao os tres gatilhos genuinos para pausar. Fora disso, e trabalho de rotina — e trabalho de rotina se faz, nao se pergunta.
Leitura do diagrama: so pause quando a acao for destrutiva, irreversivel ou mudar o escopo real; no resto do caminho, o modelo confere a evidencia e age.
✗ Pausa e pergunta
- ✗Deletar tabela, force push, sobrescrever arquivo
- ✗"Corrigir o bug" virar "reescrever o modulo"
- ✗Decisao que so o usuario pode tomar (preco, prazo)
✓ Age direto
- ✓Rodar os testes, formatar, corrigir o bug reportado
- ✓Investigar e reportar achados sem aplicar mudanca
- ✓Seguir uma convencao ja estabelecida no projeto
Em 1 frase: so pausa por acao destrutiva, irreversivel ou mudanca real de escopo — o resto e rotina e se faz direto.
🎓 A analogia do video: trate como um estagiario
🧠 Imagine assim: essa e a analogia usada no video (nao e uma citacao oficial da Anthropic, e sim um jeito de organizar o raciocinio): escreva o prompt como se estivesse explicando pra um estagiario no primeiro dia.
Um estagiario no primeiro dia nao tem o julgamento que um colega senior ja construiu. Ele nao sabe, por instinto, que "corrigir esse bug" nao significa "reescrever o modulo inteiro", ou que "investigar esse problema" nao significa "ja mandar o email pro cliente". Por isso, com um estagiario novo, voce diz explicitamente o que nao fazer — nao porque ele e ruim, mas porque ele ainda nao tem contexto suficiente pra adivinhar certo.
E exatamente esse o papel do negative prompting e das fronteiras explicitas nesta aula: eles substituem o julgamento que o modelo ainda nao demonstrou ter, no seu contexto especifico. Nao e sobre a Fable 5 ser "burra" — e sobre ela nao saber, sem voce dizer, onde ficam as cercas do seu projeto.
A parte interessante e como isso evolui. Com um estagiario que voce ja viu trabalhar por meses, voce relaxa as instrucoes explicitas — ele ja internalizou o padrao. O mesmo vale aqui: a medida que voce acumula sessoes com o Fable 5 no mesmo projeto (e registra o que funcionou, tema do modulo bonus 1.7 sobre memoria), menos negative prompting explicito voce precisa repetir toda vez. Confianca se constroi com historico, nao se assume de saida.
🆕 Estagiario novo
- •Negative prompting explicito e detalhado
- •Fronteiras escritas por extenso, sem assumir nada
- •Revisao de cada diff antes de confiar
🤝 Colega de confianca
- •Instrucoes mais curtas, so o que mudou
- •Fronteiras ja registradas no CLAUDE.md/memoria
- •Mais autonomia em trabalho de rotina
Em 1 frase: escreva pro modelo como pro estagiario de hoje, mas relaxe as instrucoes conforme o historico de confianca cresce.
🧾 Resumo do Modulo
Proximo modulo:
1.4 — Deixe agir + prove que terminou: anti-overplanning e verificacao de evidencia antes de reportar progresso.