Constraint prompting: what actually moved the needle for me

After a year of trying every prompt style under the sun, one boring pattern kept out-performing the rest: give the model explicit constraints, in a specific order, in the same place every time.

I spent most of last spring collecting prompt templates. Long ones, short ones, the "you are a senior X with 20 years of experience" ones, the ones with a fake reward function attached. Some worked. Most didn't. Almost none of them worked in a way I could reproduce two weeks later on a slightly different task.

What ended up sticking, after too many hours of A/B, is one very unromantic pattern I now use for basically every non-trivial call. I want to write it down before I forget it.

The layout

Four sections, always in this order, always with the same headings:

## Role
one sentence. what kind of thing is doing the work.

## Task
one paragraph. what has to come out at the end.

## Constraints
- format:  ...
- length:  ...
- must include: ...
- must NOT include: ...
- tone:   ...

## Input
<the actual thing to work on>

That's the whole shape. No motivational preamble. No "take a deep breath and think step by step." No fake reward. The Role sentence exists because it changes vocabulary; the Task paragraph exists because it fixes the goal; the Constraints list exists because that is where all the ambiguity actually lives; the Input block exists because if the input isn't clearly delimited, the model will read the constraints as part of it.

Why explicit constraints beat "be professional"

The word professional is doing an enormous amount of work in most bad prompts. It means everything and nothing. If I write Constraints: format = 3 bullet points, length < 80 words, must include: 1 example, must NOT include: adjectives, the model has something to fail against. If I write be professional, the model has an aesthetic to gesture at, and will produce beige mush in the general direction of that aesthetic.

My rough rule now: for every noun in the task, name a constraint. Not because the constraint is always necessary, but because writing it down forces me to notice when I don't know what I actually want.

Most "bad model output" is really "bad specification, hallucinated well."

A very small eval

I ran a tiny in-house eval over about 60 short tasks (rewrite this paragraph, summarise this brief, extract these fields, propose three headlines). Two conditions: my old freeform prompts, and the four-section pattern above. Same model, same seed, blind-graded on a 1-5 scale by two colleagues.

• Freeform prompts: mean 3.2, high variance (a lot of 5s, a lot of 2s).
• Constraint prompts: mean 3.9, much tighter variance (mostly 4s, very few 2s).

The mean lift is nice; the variance drop is nicer. Cheaper prompt = cheaper review, because the answer is less often "well, sort of, but…".

Things that did not help

• Adding a fake persona ("You are Ernest Hemingway"). Marginal for tone, zero for accuracy.
• Reward-shaping language ("you'll be tipped $500"). Statistically indistinguishable from omitting it.
• Long system prompts describing the company. Marginal for tone, sometimes hurt on accuracy because the model would try to reference nonexistent products.

Things that did help, a little

• Putting a worked example in the Constraints block ("Example of a good output: …"). Modest lift, more on long tasks.
• Asking for the output in a structured wrapper (JSON, tagged sections) even when I was going to strip it. Kept the model on rails.
• Ending with a "Now, before answering, restate the constraints in your own words" line for the very hardest tasks. Cost more tokens; sometimes worth it.