A Constraint Is a Design Parameter, Not a Polite Request

Most quality standards live in your head. You know the answer should be short, or written for a non-specialist, or structured so a downstream step can parse it, and you assume that because you know these things the model will honor them. It will not, because it cannot see them. A standard you hold silently has exactly zero effect on the output. It takes effect only when you translate it into something the instruction states, and the unit of that translation is a constraint. A constraint is not a hint or a preference the model weighs against others. It is a parameter that eliminates a whole class of otherwise-valid answers, and the class it eliminates is exactly the set you would have rejected on sight.

Seen this way, writing an instruction is closer to specifying a component than composing a message. There are two mechanics that do most of the work, and they are complementary rather than competing. Constraints narrow variance within a single instruction. Decomposition splits an instruction into several so that each one carries less variance to begin with. Knowing what each does, how they compose, and above all when to reach for one instead of the other is the difference between prompts that behave predictably at scale and prompts you re-roll until something acceptable falls out.

A constraint subtracts, it does not redirect

The cleanest definition of a constraint is subtractive. It does not alter what the task is asking for. It removes answers that would technically satisfy the task but that you do not want. Ask for a summary and you have named an operation; the operation admits a summary of any length, in any structure, at any register, from any point of view. Every one of those degrees of freedom is a dimension along which the output can vary while remaining a valid summary. A constraint pins one dimension. It leaves the task intact and shrinks the field of acceptable results.

Those degrees of freedom fall into a small number of recurring families, and it pays to keep them distinct because each one governs a separate way the answer can drift. Format governs the structure the answer arrives in, prose against a list against a table against named fields. Length governs quantity, and through quantity it forces a decision about what earns a place and what gets dropped. Tone governs register, the technical-to-plain axis and the stylistic target the writing aims at. Perspective governs the point of view, a grammatical person or a named role the answer speaks from. These are not the only constraints you can impose, but they are the ones that account for most of the variance in ordinary output, and naming any of them converts a decision the model was making silently into one you made deliberately.

The reason to treat this as encoding rather than requesting is that the model has no access to your intent except through the words. A quality standard that stays tacit is indistinguishable, from the model’s side, from a standard you do not hold at all. This is why “make it professional” so reliably disappoints: it feels like a constraint because it expresses a real preference, but it names no dimension and removes no region of the output space in any definite way. A usable constraint is one whose satisfaction you could check. If you cannot state how you would test whether the output met it, you have expressed a wish, not encoded a parameter, and the model will resolve the wish however it likes.

Constraints compound along independent axes and collide along shared ones

The practical power of constraints comes from a property that is easy to state and easy to underuse: when they govern independent dimensions, they multiply. Fixing the format does nothing to fix the length; fixing the length does nothing to fix the register. Because each governs a separate axis, a second constraint does not overlap the first, it narrows an entirely new direction, and the acceptable region contracts along both at once. Two constraints do not make the target a little smaller. They make it smaller in two dimensions, which is a sharper reduction than the count suggests. This is why loading several onto one instruction is not the excess it can look like. Each one shuts down an independent way the output could have wandered, and the single pass where you are already specifying the task is the least expensive place to shut any of them down.

That same geometry sets up the first real failure mode. Constraints multiply cleanly only when their axes are genuinely independent. When two constraints touch the same dimension and pull in opposite directions, you have not narrowed the output space, you have encoded a contradiction into it. Demand exhaustive coverage and severe brevity in the same breath and the model cannot satisfy both; it will silently sacrifice one, and which one it sacrifices is now the very variance you were trying to remove. A constraint set is a small specification, and like any specification it can be internally inconsistent. When output wanders despite a heavily constrained prompt, the cause is often not too few constraints but two that quietly disagree, and the fix is to resolve the conflict rather than add a fifth clause on top of it.

The second failure mode is subtler because the output looks correct. Constraints govern the shape of an answer, not its substance. You can specify format, length, tone, and perspective with total precision and still receive a confidently wrong result, because none of those parameters touched what the answer actually claims. A neatly tabulated set of figures computed on the wrong assumption is still wrong, and the tidiness of the table works against you, because a well-formed presentation reads as a signal of care that the underlying reasoning never earned. Constraints eliminate variance you did not want. They do not supply knowledge the model lacks or context the prompt withheld, and mistaking a tighter form for a truer answer is one of the more expensive confusions in the whole practice.

Decomposition is the second mechanic, and it works across instructions rather than within one

Constraints reduce variance inside a single instruction. There is a ceiling to what they can do, because a single instruction can only carry so much before the constraints themselves become the problem. The second mechanic works on a different axis entirely: instead of narrowing one instruction, it splits the work into several, each simpler than the whole.

The case for splitting rests on what happens when one instruction carries several distinct goals. The model does not execute them in sequence with full attention on each. It holds all of them at once, and whatever attention a single goal would have commanded is split among the rest competing in the same pass. The result is that each individual outcome comes out weaker than it would have alone, and, worse, you cannot tell which goal the model shortchanged, because the output is a single blended artifact. Split the same work into ordered steps, each with one goal, one expected kind of output, and one criterion you could check it against, and three things change at once. Each step gets undivided attention. Each step can be judged right or wrong on its own, before anything downstream is built on it. And when something goes wrong, the failure is localized to a specific step rather than smeared across an undifferentiated response. Splitting trades one tangled instruction that fails opaquely for a sequence of small ones, each of which either clears its own check or shows you precisely where it broke.

This is a different altitude from decomposing a goal into subtasks for separate agents or pipeline stages, which is a question of system architecture. Here the unit is the instruction and the currency is verifiability. The point of splitting is not parallelism or specialization. It is that a step with a single goal has a single notion of correct, and a single notion of correct is something you can actually confirm before you build the next step on it. When the output of step one feeds step two, checking step one first means step two runs on an input you have already validated, which is what makes an otherwise fragile chain tractable.

Scope is the decomposition you perform on the edges of a task

There is a specific and badly underused form of this discipline that works not on the steps of a task but on its perimeter. The gaps that produce bad output are usually silences, not misstatements: the trouble is rarely that an instruction said something poorly, and usually that it never addressed the thing at all. Four kinds of silence are worth closing by hand. An explicit inventory of what belongs in the output keeps the model from guessing at inclusion. A direct statement of what to leave out spares you the material you would have cut anyway. Marking which background is settled stops the model from re-explaining or hedging over ground you have already covered. And naming the point at which the work is finished keeps the output from running on past it for want of a signal to stop.

Closing those four silences converts a task with no fixed extent into one with a definite edge, and it buys that reliability without forcing you to dictate the interior in detail. That is what makes scope efficient: a handful of boundary decisions removes the largest ambiguities at the rim and leaves the middle to the ordinary constraints. An instruction whose inside and outside are both drawn is far easier to make dependable than one that is meticulous about the center and mute at the border.

Constraint density is the signal to stop constraining and start splitting

Because constraints and decomposition both attack output variance, the real skill is not mastering either one but knowing which to reach for, and there is a reliable signal for the switch. It is the moment you notice that each new clause you add is there to plug a failure the previous clause did not prevent. When you find yourself adding a fifth and sixth constraint to hold one prompt on target, the constraints have stopped being precision and become a symptom. Past a certain density, another clause yields less than a split would, and the clauses begin to interact in the conflicting ways described earlier, so that each addition risks introducing a new source of variance even as it closes an old one.

A few patterns let you catch the crossover before the density climbs that high. When a task moves through phases that each yield a different kind of output, one instruction cannot hold them, because no single standard of correct covers a phase that extracts and a phase that summarizes at the same time; those phases want to be separate calls. When one phase has to be confirmed before the next can safely run on its result, the seam between them is already a natural cut. When an instruction needs more than two or three constraints just to approach precision, that alone is evidence it is carrying more than one job. And the most telling sign is historical: if a single prompt kept dropping part of the task no matter how it was reworded, the trouble is not the wording but the unit of work, and one more constraint will not make a single instruction do what two would do without effort. Another constraint is the right move right up until it is not, and the density is the gauge.

Test whether the instruction is specific enough before the model does

Both mechanics presuppose that you can separate an underspecified instruction from a sound one before running it, and that call can be made deliberate instead of intuitive by interrogating the instruction directly. Ask first whether a careful reader could land on two honest readings of it; if so, the ambiguity is real and the moment to close it is now. Ask next what the model would be forced to assume in order to finish, write those assumptions down, and settle each one on purpose instead of meeting it later in the output. Then picture the response concretely: if two materially different answers would both count as reasonable, the space between them is precisely where a constraint is missing. And ask whether the instruction actually terminates, or whether nothing in it says where to stop.

Running these checks is what turns instruction writing into a design activity rather than a guess you evaluate after the fact. The alternative is to run the prompt, read a disappointing result, and try to reverse-engineer which decision the instruction handed off, which is strictly more expensive because it happens after the model has already spent its effort on the wrong target. Evaluating the specification before execution is the same economy that applies anywhere else: defects are cheapest to catch in the artifact that produced them, before they have propagated into everything downstream.

Where these mechanics reach their limits

Neither mechanic is unbounded, and using them well means knowing where they stop paying off. Constraints run out of usefulness the moment the goal itself is unsettled. If the point of a prompt is to survey what the model might produce, to turn up framings you had not thought of, then pinning every dimension in advance defeats the exercise, because you cannot discover an option you have already ruled out. Specificity earns its keep once you have a target and want to land on it repeatedly. While the target is still being chosen, it only locks in whatever you happened to want first.

Decomposition has a symmetric limit in the opposite direction. Every split introduces a boundary, and every boundary is a handoff that has to be specified, verified, and maintained. Cut a task into too many steps and the overhead of coordinating them starts to exceed the variance you were removing by separating them. The goal is not maximum granularity any more than it is maximum constraint. It is the coarsest decomposition that still gives each step a single, checkable notion of correct. And underneath both sits the ceiling already named: form is the whole of what either one touches. A perfectly constrained, cleanly decomposed instruction can still be wrong about the world, because neither mechanic adds knowledge or context the model never had. They make an instruction predictable and verifiable. They do not make it true.

The instruction is an artifact you design

The throughline is that a quality standard has no force until it is encoded, and there are two ways to encode it. Constraints narrow the acceptable output within one instruction, compounding when their axes are independent and colliding when they are not. Decomposition splits the work across instructions so each carries a single goal you can verify before the next depends on it. The two are responses to the same underlying problem, unwanted variance, and fluency is knowing which one a given instruction needs, with constraint density as the tell that marks the crossover from one to the other.

What ties it together is a shift in how the instruction itself is regarded. It is not a message you send and then judge by what comes back. It is a specification you design, one you can inspect for ambiguity, for conflicting requirements, and for a definite stopping point before the model ever runs. The instructions that behave the same way on the hundredth invocation as on the first are the ones that were engineered rather than written, and the two mechanics here are most of what that engineering consists of.