Infographic summarising What Happens When You Stop Asking AI Questions and Start Giving It Constraints Instead
AI

What Happens When You Stop Asking AI Questions and Start Giving It Constraints Instead

Most people’s default way of using AI is to ask it a question. “What’s a good way to structure a presentation?” “How do I write a cover letter?” “What should I do about X?” Reasonable instinct — it’s a chat interface, you chat at it.

The problem is that open questions get you open answers. The model has enormous latitude to be generic, to hedge, to give you the seven-item list when you needed one specific thing. It’s not being lazy. It’s filling in underspecified instructions with the safest, broadest pattern that satisfies them.

Switching from questions to constraints changes that dynamic almost immediately.

Infographic summarising What Happens When You Stop Asking AI Questions and Start Giving It Constraints Instead

What “giving constraints” actually means

A constraint isn’t just adding words to your prompt. It’s closing off options the model would otherwise default to. You’re not describing what you want more elaborately — you’re making it impossible for the model to give you certain kinds of bad output.

Compare these two prompts:

Open question: “Help me write a follow-up email after a job interview.”

Constrained version: “Write a follow-up email after a job interview. Under 100 words. No expressions of gratitude in the opening line. No phrases like ‘I wanted to reach out’ or ‘I hope this email finds you well.’ End with one specific thing from the interview conversation, not a generic ‘look forward to hearing from you.'”

The second prompt doesn’t just describe good output — it explicitly closes off the generic patterns that would make the output bad. The model can’t default to the filler phrases because you named them specifically. What comes out is almost always more useful, not because the model got smarter, but because you gave it less room to be mediocre.

Why this works (the actual mechanism)

Language models are trained on enormous amounts of text, and that text has patterns. Cover letters sound a certain way. Motivational advice sounds a certain way. When you ask a vague question, the model gravitates toward the most common, central pattern for that type of output — which is usually also the blandest version.

When you name specific things to avoid, you’re not fighting the model’s tendencies. You’re redirecting them. The model is still pattern-matching, but you’ve excluded the most statistically common (and least useful) patterns. What’s left tends to be more specific, more direct, and more actually yours.

This is different from adding style adjectives like “make it punchy” or “keep it natural.” Those are positive descriptions, and the model has to guess what you mean by them. Constraints are negative: they say what the output cannot be, which is much harder to misinterpret.

The kinds of constraints worth using

Not all constraints pull equal weight. A few categories that tend to do real work:

Format constraints

Not “keep it brief” — “under 150 words, no bullet points, one paragraph.” Length and structure instructions that leave no room for interpretation. These matter because AI output balloons by default, and vague instructions like “concise” get interpreted as “somewhat shorter than my longest output.”

Banned phrases and patterns

List the specific things you don’t want to see. If you’re generating any kind of professional communication, you’ve seen the same filler phrases appear constantly: “I hope this finds you well,” “Please don’t hesitate to reach out,” “As per my previous email.” Name them and say don’t use them. The model will comply, and the output is immediately less generic.

Structural constraints

“Start with the main point, not context-setting.” “No more than two examples.” “Don’t end with a call to action.” These control the shape of the response, not just its length.

Audience constraints with actual specifics

“Written for someone who knows what a pivot table is but has never used a macro” is a real constraint. “Written for a general audience” isn’t — that’s still wide open. The more specifically you can describe who the output is for, the less the model has to guess at register and level of explanation.

Where this matters most

If you’re using AI for a one-off task and you’re happy to do a couple of rounds of back-and-forth editing, open questions are fine. The extra iteration cost is low. But two situations make constraints clearly worth the upfront effort:

First, when you know what you don’t want but struggle to describe what you do want. This covers most creative and professional tasks. You’ve read enough bad cover letters to recognize the tells — you just haven’t written them down. Constraints let you encode that knowledge in the prompt rather than burning it on editing cycles.

Second, when you’re running something repeatedly. If you’re using AI to produce the same type of output regularly — weekly newsletters, product descriptions, project summaries — a prompt built around constraints will drift less over time than one built around positive descriptions. “What’s a banned phrase” is a more stable anchor across runs than “what’s an engaging tone.”

The real cost: iteration

The honest trade-off is that you can’t write good constraints without first seeing what bad output looks like. You need to run the prompt a few times, read outputs that aren’t quite right, and write down specifically what was wrong. That list of specific wrongs becomes your constraint list almost verbatim.

You can shortcut this if you already know the failure modes — if you’ve used AI enough for cover letters to know it always opens with “I am excited to apply,” you can pre-empt it. For new tasks, though, expect the first version of any constraint-heavy prompt to be incomplete. That’s not a failure of the technique; it’s just that the useful work is in reading actual outputs carefully, not in writing longer prompts from the start.

One real caveat: constraints can overconstrain. Pile on too many — especially conflicting ones — and you get output that’s technically compliant but stilted. It satisfies all the rules without reading naturally. The fix is to prioritize: pick the three constraints that eliminate your most common failure modes and leave the rest for editing. A focused set of four constraints usually outperforms an exhaustive set of twelve.

Next time you’re about to type a question into ChatGPT or Claude, pause and ask: what’s the worst version of what I’m about to request? Write that down, then add “don’t do any of that” to your prompt. It catches more bad output than any amount of positive instruction.