# Tell the AI What It Cannot Touch: Why Hard Constraints Beat Better Prompts > Source: > Published: 2026-10-07 15:13:47+00:00 Most people ask an AI for "a better resume" and get back something that reads well and is wrong. The numbers have been rounded up, the second page has appeared, and every bullet now starts with "Dynamic, results-driven professional". Then they spend twenty minutes fixing it by hand, and call that the AI being unreliable. The model did what you asked. You never told it where the edges were. When a draft comes back unusable, the usual reaction is to add more detail to the prompt: more background, a longer role description, a nicer tone. That helps a little. It rarely fixes the thing that actually hurts, which is a specific violation you could have predicted before pressing enter. A language model is trying to produce plausible text. Plausible and acceptable are different things. If you do not define the floor, the model fills every gap with whatever sounds most natural, and for a resume, the most natural continuation of "managed a team" is "managed a team of 15 and increased revenue by 40%". Think about how a product manager writes a spec. The document has a list of things the feature must do and a list of things it must never do. Nobody expects an engineer to guess that the checkout flow cannot store card numbers. You say it up front, because discovering it in review is expensive. Prompts work the same way. The cost of a missing rule is paid at the end, in rewrites. This article rests on two ideas, and the rest is mechanics. **Claim one: constraints are the cheapest part of a specification.** A "must" or "must not" costs you one short sentence. A missing one costs you a full revision cycle, and sometimes costs you a mistake you did not notice. **Claim two: the most valuable constraint is the one that tells the AI what to do when it cannot comply.** Most people write rules without an exit. A model that is told "keep all quantified results" and "highlight growth experience" has no honest option when your resume contains no growth numbers. It will invent some. A rule needs a failure path. The ordering is not cosmetic. Put the hard constraints before the task details, then restate the most important ones briefly at the end if the prompt is long. There is research behind this. In [Lost in the Middle: How Language Models Use Long Contexts](https://arxiv.org/abs/2307.03172), the authors found that performance is often highest when relevant information sits at the beginning or end of the input, and degrades significantly when it sits in the middle. A constraint buried in paragraph four of a six-paragraph prompt is exactly the kind of information that gets weak attention. The practical reading is simple. Do not hide a requirement in the middle of a story about your career. Give it its own line, near the top, where it cannot be mistaken for background. **Author's Comment:** I treat the phrase "rules first, errors last" as a drafting order, not a slogan. Write the boundaries before you write the task. If you start with the task, the constraints become afterthoughts and end up as an apologetic "oh, and please don't make anything up" at the bottom. A constraint is useful when you could check it without asking the AI. This is also how researchers evaluate instruction following. The [IFEval benchmark](https://arxiv.org/abs/2311.07911) from Google focuses on "verifiable instructions" such as writing more than 400 words or mentioning a keyword at least three times, because those can be scored by a script instead of an opinion. Borrow that standard for everyday prompts. Compare these two: The second version leaves nothing to interpret. You can count the bullets and look at the page. If the output fails, you know which rule broke, and you can point at it. Must-haves protect what is valuable in your input. For a resume, that is the information that took years to earn. Must-nots protect you from the model's default habits. Every model has a recognizable house style of inflated adjectives, filler openings, and unrequested additions. Name the ones that bother you. **Practical Pitfall Avoidance Guide:** Pair every ban with a replacement behavior when you can. "No vague adjectives" works better as "No vague adjectives; describe the result with the metric instead." A bare prohibition tells the model what to avoid but not what to do in its place, and it tends to swap one cliché for the next. This is the part most prompt guides skip, and it is the one I would keep if I could only keep one. Suppose your resume says you "improved onboarding" but gives no number. A strict instruction to "quantify every achievement" now collides with reality. The model has two options: break the rule by leaving the bullet unquantified, or satisfy the rule by fabricating a figure. Fluent models usually choose the second, because the output looks more compliant. You prevent this by defining a third option: if a result lacks supporting data, write "TBD" next to it and tell me. Now the honest path is also the compliant path. The model is rewarded for flagging a gap instead of covering it. This is the same logic behind prompts that let a model express uncertainty. If that idea is new to you, the site's guide on [prompts that make AI admit it doesn't know](https://appliedaihub.org/blog/prompts-that-make-ai-admit-it-doesnt-know/) covers the structures that shift a model from confident fabrication to honest uncertainty. The resume case is a small version of the same problem. Here is the original request that most people send: ``` Help me revise my resume. ``` The model has no job target, no limits, and no definition of failure. It will produce something generic and probably longer than before. Here is the version with boundaries: ``` Optimize my resume for a Product Manager application. Must: - Keep every quantified result exactly as written. - Fit on one page. - Emphasize user growth and data analysis experience. Must not: - Use vague adjectives such as "excellent" or "outstanding". - Add any number, employer, or title I did not provide. If an achievement has no supporting data, mark it "TBD" and list it at the end so I can fill it in. ``` Same resume, same model, a very different outcome. The first draft comes back on one page, the numbers match your source, and anything that was soft is flagged for you instead of polished into a lie. You review a short list of "TBD" items rather than hunting for hidden inventions line by line. Adding adjectives to a task description makes the target richer but not narrower. Adding constraints makes the target narrower. A prompt that says "write a professional, impactful resume" still allows millions of acceptable-sounding outputs, most of which violate something you care about. Constraints cut the space of outputs from the outside. They do not require the model to understand your taste. They only require it to stay inside a fence. Context still matters, of course. A rule list on top of a one-line request is better than nothing, but it is not a replacement for describing your situation. If you want the longer argument for rich context, read [Stop Using One-Liner Prompts](https://appliedaihub.org/blog/stop-using-one-liner-prompts/). The two habits stack: context says what the task is, constraints say what the answer cannot do. A few notes from using this pattern daily. Keep the list short. Five to seven constraints is usually the ceiling before the model starts dropping some. If you need twenty rules, the task is probably two tasks. Rank them. When two rules can conflict, such as "one page" and "keep all data", tell the model which wins. Without a priority, the model chooses for you. Check the output against the list before you read it for style. A violated rule is cheaper to spot than a bad sentence, and it tells you exactly what to add to the next prompt. If you reuse the same boundaries often, structure helps. [Prompt Scaffold](https://appliedaihub.org/tools/prompt-scaffold/) includes a dedicated Negative Constraints field next to Role, Task, Context, and Format, so the must-not list has a fixed place instead of floating at the bottom of a paragraph. It runs in the browser, so your resume text stays on your machine. Before your next request, write two lists on a scratch note: what must be true of the answer, and what must never appear in it. Then add one more line that says what to do if the AI cannot meet a rule. Send those three things before the task itself. The first draft will not be perfect, but it will be wrong in ways you chose to allow.