The behaviour
You ask for a small change. You get a new module, a config file, an interface “for flexibility later”, and three files you did not want. The work is competent. It is also four times the size of the job.
This is not you writing a bad prompt. It is a documented tendency in the current Opus models, and Anthropic ships a ready-made prompt to damp it down.
What the docs say
From Anthropic’s prompting best practices, verbatim:
“Claude Opus 4.5 and Claude Opus 4.6 have a tendency to overengineer by creating extra files, adding unnecessary abstractions, or building in flexibility that wasn’t requested.”
The documentation follows that sentence with a sample minimal-scope prompt block. So the vendor has both named the behaviour and handed you the remedy. Most people have read neither.
The minimalism block
Here is the version I keep in my own project instructions. It extends the official sample with the two rules that saved me the most cleanup — no unrequested error handling, and ask before building:
## Scope
Do the smallest thing that satisfies the request, and nothing else.
Do not create new files if an existing file can hold the change.
Do not add abstractions, interfaces, config options or extensibility I did not ask for.
Do not add error handling for cases I have not described.
If you think extra work is needed, say so in one line and wait. Do not build it.The last line is the one that changes the relationship. Without it, Claude’s instinct when it spots a gap is to fill the gap. With it, the instinct becomes to flag the gap and let you decide. That is what you want from a competent colleague too.
Retro-fixing a change already made
If the sprawl has already happened, do not unpick it by hand. Ask for the diff back:
Review the change you just made against the request I actually gave you.
List anything you added that I did not ask for: new files, new abstractions, new options, new dependencies.
For each one, say whether it is required for the request to work.
Remove everything that is not required.Claude is good at this. It knows what it added speculatively, because it added it speculatively. Asking the question out loud is enough to get most of it back out.
Why the block works
“Keep it simple” fails for the same reason “be concise” fails. It is a preference, not a rule, so the model applies its own definition. Every line in the block above is a check that can be run against a diff:
- Did you create a file? Was one needed?
- Did you add an abstraction? Was it requested?
- Did you add an option? Did I name it?
Testable rules survive contact with a large model. Vibes do not.
The trade-off worth knowing
A tight scope block makes Claude a better editor of your codebase and a slightly worse architect of a blank one. That is the correct trade for day-to-day work, where most requests are changes to something that already exists. When you genuinely want the model to design ahead — a new service, a schema, a migration path — drop the block for that session and ask for options instead.
Constrain the default. Loosen it deliberately.
Sources
From idea to operation
Make the next AI decision concrete.
NavAIgate helps leadership teams identify high-value AI opportunities, prove them safely and turn the winners into working systems.