Skip to content

Hard Constraints vs 'Be Concise': Which Prompting Approach Actually Works?

I kept getting frustrated. Every time I asked Claude to “be concise” or “keep it brief,” I’d still get paragraphs of explanation I didn’t need. The output was unpredictable—sometimes 50 words, sometimes 500. I was wasting tokens and time.

Then I tried something different.

The Problem: Subjective Terms Don’t Work

“Be concise” means different things to different people. To me, it might mean “give me the answer in two sentences.” To Claude, without a concrete reference point, “concise” is just a vague quality term—and Claude’s default tendency is toward comprehensive responses.

I ran an experiment. Same question, different prompting approaches:

Test 1: Vague instruction
Prompt: "Give me a concise summary of this article."
# Result: Varied wildly—sometimes 50 words, sometimes 300+ words
# Unpredictable, inconsistent, frustrating
Test 2: Hard constraint
Prompt: "Summarize this article in exactly 3 bullet points.
Each bullet should be 1-2 sentences."
# Result: Consistently delivered 3 bullets, ~20-40 words per bullet
# Predictable, parseable, useful

The difference was stark. Hard constraints worked every time. Vague instructions produced unpredictable results.

Why Hard Constraints Work

Claude (and LLMs generally) struggles with subjective quality terms but excels at following explicit rules. When you say “be concise,” the model has no clear target—it’s guessing what “concise” means to you.

When you say “3 sentences maximum,” there’s no ambiguity. It’s a measurable, verifiable constraint.

This matters for several reasons:

  • Token costs: Fewer output tokens = lower costs
  • Reading time: You get exactly what you need
  • Downstream processing: Predictable output format works better for automation
  • Frustration elimination: No more wading through verbosity

The Replacement Strategy

Replace every subjective term with a specific, measurable constraint:

Instead of…Use…
”Be concise""Answer in exactly 3 sentences"
"Keep it brief""Limit your response to 100 words maximum"
"Don’t give me too much detail""Provide only the top 3 most important points"
"Quick summary""Summarize in 2 bullet points max”

Practical Templates

Here are patterns I now use regularly:

For code explanations
Prompt: "Explain this function in exactly 2 sentences:
1. What it does
2. What it returns"
# Result: Clean, focused, no fluff
For debugging help
Prompt: "Suggest exactly 3 possible causes for this error.
Do not provide fixes—just the causes."
# Result: Targeted troubleshooting without overwhelming detail
For learning new concepts
Prompt: "Answer with:
- 1 sentence: what it is
- 1 sentence: why it matters
- 1 sentence: how to use it"
# Result: Structured knowledge in digestible chunks

Common Mistakes to Avoid

I learned these the hard way:

  1. Using subjective terms (brief, concise, short, quick, simple) — these mean nothing concrete to the model
  2. Setting unrealistic constraints — asking for “5 words max” on a complex topic forces incomplete, useless answers
  3. Not matching constraints to task complexity — a simple question needs tighter constraints than a nuanced analysis
  4. Forgetting to specify format — “3 sentences” is different from “3 bullet points” or “3 numbered items”

Calibrate Your Constraints

The key insight: test your constraints on a few examples to calibrate what “reasonable” looks like for your use case.

I started with “100 words max” and found it too tight for technical explanations. Now I use “150-200 words” for technical summaries and “3-5 bullet points” for quick references. The exact numbers matter less than having specific numbers.

The Bottom Line

Hard constraints are provably effective. Vague instructions are not. Every time you catch yourself typing “be concise” or “keep it brief,” stop and replace it with a specific number and format.

Your future self—reading faster, paying fewer token costs, and building more reliable automation—will thank you.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments