Simple explanation
More detail should mean better results. Right?
Sometimes. Not always. And understanding the difference saves you hours of frustration.
When longer IS better:Complex builds that touch multiple files — more context prevents wrong assumptions. Anything with specific style requirements — colors, fonts, tone, layout details. Tasks where the constraint is as important as the ask — what NOT to change matters as much as what to change.
When longer makes things WORSE:Simple one-file changes — extra context confuses Claude Code about what is actually being asked. Long sessions where the context window is already filling up — adding more tokens accelerates the problem. When your prompt contains contradictions — the more you write the more likely you are to accidentally say two things that conflict.
What to do
The real rule:Length should match complexity. Not ambition.
A simple change needs a simple prompt. A complex build needs a detailed brief. The mistake most people make is writing long prompts for simple tasks — and short prompts for complex ones.
The test before you send:Read your prompt back. Can you cut any sentence without losing important information?
If yes — cut it.
The perfect prompt contains everything necessary and nothing extra.
A useful structure for complex prompts:
- What I am trying to achieve (one sentence)
- What I already have (one sentence)
- What I want changed (specific)
- What must NOT change (critical)
For simple prompts: just describe what you want. One clear sentence often beats one unclear paragraph.
Copy-paste prompt
Here is what I want to do: [one sentence]. Here is what I already have: [one sentence]. Here is what needs to change: [specific]. Here is what must not change: [specific constraints].
Course note
Key takeaway
Match prompt length to task complexity. Simple tasks need simple prompts. The perfect prompt has everything necessary and nothing extra.