Over-prompting — when you write so much it loses the thread

1. The failure mode

After learning that context matters, the typical move is to add more. More background. More constraints. More edge cases. More examples. More instructions.

There's a turning point where this becomes net negative. The signs:

• The prompt gets long enough that the task line is buried.
• Edge cases listed before the main task pull the model's focus onto edge cases.
• Constraints start contradicting each other because you didn't notice you added both.
• The model produces hedging, generic output — because it can't tell what you actually care about most.

More isn't always better. Past a certain point, every additional clause is noise.

2. The shape of an over-prompt

Hi! I'm working on a Node.js application using TypeScript with strict mode enabled, on Node 20.

I'm following clean code principles, SOLID principles, and DRY. I want code that is testable, maintainable, has clear naming, follows our team conventions (camelCase for variables, PascalCase for types, kebab-case for file names), uses async/await instead of promises, prefers functional patterns where reasonable, but isn't dogmatic about it, uses ESLint rules including no-explicit-any, no-unused-vars, prefer-const, has good error handling, throws meaningful error messages, and handles edge cases like null, undefined, empty arrays, very large inputs, and Unicode.

Also: it should be performant, but readability over premature optimization, and we use Prettier for formatting (2 spaces, single quotes, trailing commas, semicolons).

Now, can you write a function that takes a list of users and returns the ones whose email is verified?

The actual task — write a function that filters verified users — is buried under 200 words of background. The model now has to balance twenty constraints, half of which don't matter for this task. The output will be over-engineered, hedged, and slow to read.

TypeScript, Node 20, strict mode.

Write a function that takes a list of users and returns the ones whose email is verified.

Use camelCase for variables. Use async/await if any IO is involved. Otherwise stay simple.

Three lines of relevant context, then the task. The other twenty constraints either don't apply to this task or are obvious defaults. The output will be a four-line function.

3. The trim rule

The cheap test: read your prompt and ask, which sentences would change the answer if removed? Delete the rest. If the answer would be the same without a sentence, that sentence was decoration.

A useful mental cap: most prompts get worse past ~200 words for a focused task. Long context blocks (logs, code, examples) are fine. Long instruction sections usually aren't.

4. Try it