🧱 Negative prompting + boundaries

An LLM works by predicting, a token at a time, what the most likely continuation of the text so far is. This means it doesn’t stop exactly where the task “ends” — it continues until it thinks the response is complete at your own discretion. In effort the higher this is, the more generous the “complete” criterion becomes: the model gathers more context and deliberates longer before responding.

This isn't a failure; it's a side effect of being capable and careful. Fable 5, especially on routine tasks with high effort, may decide that the "complete answer" for fixing a bug includes cleaning up the surrounding code, adding a refactor or create a validation layer for a case that will never happen. None of that was requested—but none of it was prohibited either.

Negative prompting addresses this at the root: instead of letting the model guess where to stop, you explicitly say “don’t do X.” This removes the ambiguity it would normally resolve in favor of “more comprehensive”—and gives you control over the scope again.

The official docs "Prompting Claude Fable 5" describes exactly the mechanism from the previous topic, in Anthropic’s own words:

And next, the block the docs recommend pasting into the system prompt or in CLAUDE.md. And the official negative prompting against “tidying” and unrequested refactoring:

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.

Don’t add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn’t need cleanup around it, and a one-off operation usually doesn’t need a helper function. 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 can’t happen. Trust the guarantees provided by the code and framework. Validate only at system boundaries (user input, external APIs). Don’t use feature flags or backward-compatibility shims when you can simply change the code.

Two concrete examples illustrate the pattern well. Neither is malicious — both come from a good intention (being careful, being helpful) that simply went beyond the scope of what was requested:

The common pattern: in both cases, the model decided on its own that an adjacent action “was part of” the task. That’s exactly what the two official prompts in this lesson address — the anti-tidying prompt (topic 2) cuts excess inside the code, and the boundaries prompt (topic 4) cuts excess outside the requested scope, including actions that change state.

This is an extra technique that wasn’t in the video but appears in Anthropic’s official documentation: explicit boundaries. It solves the same problem as topic 3, but for the more serious case—actions that change the system's state (deleting, restarting, editing configuration) without confirmation.

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.

The topic 4 boundary prompt handles the “describing vs. asking” case. But the other side of the coin is missing: once it already has enough information to act, when it should still stop to ask, and when it should just move ahead? Anthropic’s official documentation (in its anti-overplanning technique, covered in depth in module 1.4) gives the criteria:

Put into practical terms: destructive or irreversible (delete, overwrite, force push), real change in scope (the original request was X, and the obvious next step would be Y — something bigger or different) or information only you have (a business decision, a personal preference) are the three genuine triggers for pausing. Otherwise, it's routine work — and routine work gets done, not questioned.

An intern on their first day doesn't have the judgment that a senior colleague has already built. It doesn't instinctively know that "fix this bug" doesn't mean "rewrite the entire module," or that "investigate this issue" doesn't mean "send the client an email right away." That's why, with a new intern, you explicitly say what no do it — not because it's bad, but because it doesn't have enough context yet to guess correctly.

This is exactly the role of negative prompting and explicit boundaries in this lesson: they replace the judgment the model hasn’t yet demonstrated in your specific context. It’s not that Fable 5 is “stupid”—it’s that without you saying so, it doesn’t know where the guardrails for your project are.

The interesting part is how this evolves. With an intern you've watched work for months, you can relax the explicit instructions—they've already internalized the standard. The same applies here: as you accumulate sessions with Fable 5 on the same project (and record what worked, the subject of bonus module 1.7 on memory), you need to repeat less explicit negative prompting each time. Trust is built through history; it isn't assumed from the start.