Claude Fable 5: Context, Not Constraints

There is a prompt pattern almost every team is using right now that limits their AI more than it helps it. It shows up in system prompts, in task descriptions, in comments dropped into Claude Code sessions. It sounds reasonable. It feels like good engineering discipline.

It goes like this: "Keep it simple." "Don't over-engineer." "Use existing patterns." "Avoid adding new dependencies."

These are constraints. And they are the wrong tool for the job.

Rules Limit. Reasons Let the Model Reason.

A constraint tells the model what to avoid. It draws a fence. The model will respect the fence, but it has no idea why the fence exists. That matters more than it sounds, because most of the interesting decisions in software happen at the edge of the fence, not in the middle of the field.

The Anthropic Claude Code team published something sharp on this in June 2026, discussing how they prompt with Fable 5-class models. They call it Fable 5 change #1, and the specific sub-insight is this: stop writing constraints. Write context instead.

Their example is exact. Instead of:

"Keep it simple, don't over-engineer, use existing patterns."

Write this:

"This feature is an experiment. Real chance we delete it in a month. Don't build anything painful to throw away."

One sentence. And yet everything changes. The model now knows why you want simplicity. It can reason from that why to trade-offs you never listed. The team put it plainly: "Context lets it catch things you didn't think of." Constraints just limit it.

What Fable 5 Can Actually Do With This

Earlier models needed explicit constraints because they could not reliably infer. You wrote "don't add migrations" because you couldn't trust the model to figure out that migrations were a bad idea here. You listed everything you wanted it to avoid, because the model couldn't reason backward from the situation to its implications.

Fable 5-class models can make that inference. Give Claude Code the sentence "we might delete this in a month" and it correctly derives a set of behaviors you never had to specify:

Five bullet points of constraints, replaced by one sentence of context. And the context version catches more. Because the model reasons from it to edge cases you didn't think to list.

That last point is the one worth sitting with. A constraint list can only protect you from what you anticipated. Context protects you from what you didn't.

Karpathy's Frame: The Context Window Is Your Program

Andrej Karpathy put the underlying principle cleanly at AI Ascent 2026. In Software 3.0, the context window is your program. What you put in it is how you program the model. The quality of your prompts is the quality of your software.

Most teams are filling their context windows with constraints. What to avoid. What not to do. What patterns to stay away from. They are writing negative space into their programs, and then wondering why the model can't do more than the negative space allows.

Context is the positive version. It tells the model what is true about the situation. The deadline, the business reason, the risk level, the audience, the intended lifespan. The model can reason from any of those to the right set of trade-offs. Constraints tell it one set of walls. Context tells it the shape of the territory.

A Concrete Rewrite

Here is what this looks like in practice across a few common prompt types.

Notice that each context sentence contains its constraint, plus more. "We're mid-migration" tells the model why new dependencies are a problem, which means it can also flag the one new dependency you forgot to think about. The constraint version only stops the ones you remembered.

Why Beats What

There is a principle underneath all of this: why is always more useful than what.

Telling the model what not to do is answering a question it shouldn't need you to answer. A model capable enough to reason about trade-offs should be getting the reason, not the list. The list is what you produce when you distrust the model's ability to infer. And for Fable 5, that distrust is mostly outdated.

The why contains all the implied constraints, plus the ones you forgot. That is not a marginal improvement. Teams running constraint-heavy prompts are systematically leaving inference on the table. The model is capable of more. They are just not giving it enough to reason from.

For every constraint you write in a system prompt or task description, ask one question: is there a context sentence that contains this? Almost always, there is. One sentence of context about the business situation, the timeline, the team structure, or the feature's intended lifespan usually replaces three bullet points of constraints, and does more work.

What to Change in Your Team's Prompts

Start with the system prompts your team uses most. Scan them for negative instructions: don't, avoid, never, keep away from. For each one, ask why that rule exists. Write that why as a single sentence. Swap the rule for the sentence.

Then watch what the model does with it. The first time it flags a shared dependency you hadn't thought about, or pushes back on a design choice because it conflicts with the context you gave it, you'll understand why the Anthropic team framed this as change number one.

Constraints tell it what to avoid. Context tells it what to understand.

Understand wins.