LLM 101 — 04: Prompt as Representation
Patching a prompt rule by rule means controlling consequences as if they could be adjusted independently — the deeper choice is which coordinates represent the task at all.
Suppose a model gives you an answer you do not like. You add an instruction.
The next answer is too long, so you add Be concise. Now it skips an important qualification, so you add Do not omit important caveats. Now every answer carries three paragraphs of caveats, so you add Only include caveats when necessary.
At some point the prompt begins to look less like a description of a task and more like a treaty negotiated after a long series of border disputes.
This loop is familiar to anyone who maintains prompts, and the interesting thing about it is that it loops. Every rule was reasonable. Every rule fixed the failure in front of it. And every fix produced the next failure.
Perhaps the problem is that we are trying to control the wrong object.
Part of the answer is visible in the rules themselves. Concise, rigorous, intuitive — each is written as if it adjusted an independent dial on the output.
But these properties are not independent. A two-sentence answer is concise for a philosophical question and absurdly verbose for a date; pressing on concision was exactly what pushed the caveats out. The knobs are connected. Turning one turns the others.
So instead of adjusting the output, look at the task.
Suppose the task is:
Explain this paper rigorously but intuitively.
One way to steer it is the way we have been steering:
Be concise. Avoid jargon. Explain any notation you use. Stay rigorous, but do not oversimplify.
Another way says almost nothing about the answer itself:
The reader is mathematically comfortable but has never studied information theory. The goal is to make the central argument understandable without hiding the mathematical structure. Mathematics matters where it preserves structure that prose alone would blur.
The first prompt describes desirable properties of the answer. The second describes the variables from which those properties should follow.
Follow the derivations once. The reader has no information-theory vocabulary, so jargon is unfit — not forbidden, just useless for the purpose.
The goal is understanding that preserves the mathematical structure, so intuition cannot be bought by deleting the mathematics. And since mathematics matters exactly where prose alone would blur the structure, notation has a condition of use built in — no separate rule about when to introduce it is needed.
What looked like separate rules in the first prompt now begin to follow from the same underlying description.
The second prompt is not more specific about the output. It is better specified about the problem.
There is a more general way to write the difference.
Let stand for the visible properties of the answer — its length, vocabulary, notation, abstraction level, what it explains and what it leaves implicit. A patching prompt tries to control these variables directly.
But many of them are downstream of a smaller set of variables : who the reader is, what the explanation is for, what structure must survive.
Change , and several parts of should change together. Change the reader, and vocabulary, abstraction, notation, and depth all move.
This is the representation problem. The two prompts are not merely different sets of instructions — they use different coordinates for the same task. Both pick a space and name values in it; they differ in which space.
The first conditions on properties of the answer; the second conditions on the variables those properties should follow from.
The first prompt parameterizes the answer. The second parameterizes the problem.
And the loop we started with now has an explanation. Too long — constrain length. Too technical — constrain vocabulary. Too shallow — constrain depth. Each rule repairs one coordinate of .
But if several coordinates are joint consequences of the same underlying variables, treating them as independent controls ignores the structure that connects them. Fixing one locally can move another, so the next failure becomes another rule, and the loop continues.
Patching begins when we treat a consequence as an independent knob.
A useful representation does the opposite: it compresses many local decisions into a smaller number of meaningful coordinates.
And the representation changes what control feels like.
Control the output coordinates directly, and every interaction becomes another exception to manage. Control the underlying variables, and one change can move a whole family of behaviors coherently.
Of course, some constraints really are constraints: return valid JSON, stay under 500 characters, use only the supplied documents. Representing the task does not replace hard boundaries.
Once the task is represented this way, a different question appears: what makes a set of coordinates a good representation of a problem?
Prompt design begins before wording. It begins with deciding how to represent the problem.