Chapter 6. A Goal and Its Proxy¶
“Fix the failing test,” I typed, and went for tea. I came back to passing tests: the model had commented out the check that was failing and left a comment — “temporarily disabled.” Formally, my request was fulfilled to the letter. In substance, it was quiet sabotage.
Whose fault is that? Nobody’s. The goal in this story simply existed on three levels, and I acted as if there were only one.
A goal on three levels¶
What you want. What you wrote. What the system optimizes.
The first lives in your head: “the code should be correct, and the test should confirm it.” The second lives in the input field: “fix the failing test.” The third lives inside the process: the model searches for the most plausible response to the second, not the first. It has never seen the first.
Between these three levels lie two distances, and their nature differs. The first distance is yours: how much of the goal got lost in the writing down. The second is the system’s: where the process pulls what you wrote. The disappointment at the end of a session is the sum of both distances. And that’s the better case.
In the worse case they multiply: when the proxy is wrong, the system pours all its effort into optimizing the wrong thing — and the harder it works, the farther you are from the goal. My green test wasn’t a sum; it was a product. The two distances also shrink in different ways.
The phrasing that stands between you and the system I will from here on call the proxy: it is not the goal, it is the goal’s stand-in. A stand-in can be better or worse, but it never equals the one it stands in for.
The machine’s pull¶
In Chapter 2 we counted variety — that was the first observation about systems. Here is the second: left unattended, every system slides toward a goal of its own — toward the state it finds “comfortable.” It’s where its construction takes it when nobody outside is holding on.
What is comfortable for the model? The plausible. It produces the most plausible continuation of the conversation — and “test green, task closed” looks like a more plausible ending than “I dug in, and I have bad news about your code.” The correct answer and the plausible answer often coincide — that coincidence is what everything rests on. But what the model optimizes is the second: not whether the answer is correct, but whether it is plausible. Always plausibility.
This is one of the regularities of systems. An LLM is a statistical model: it picks every next word from a distribution of likely continuations, and the densest place in any distribution is the middle — the typical, the seen-many-times. Picture the bell curve. Without your intervention, the answer lands at its peak — the way a marble rolls to the bottom of a dimple. Not out of “laziness”: that is the system’s most stable state. Behind the statistics, a more general regularity shows through: any system left to itself slides toward its most stable state — the model is just its purest example. What this costs in quality, and how slop grows out of the middle of the distribution, is a conversation for Chapter 8.
That’s why every phrasing gets executed literally: the system’s internal goal fills in everything the proxy leaves unsaid. You didn’t write “the check must stay” — and that blank got filled with the most comfortable option: the check disappeared. Managers know this effect as Goodhart’s law: when a measure becomes a target, it ceases to be a measure. Here is the mechanism. A green test is a measure: it says something about the code as long as nobody tries to make it green directly. The moment you typed “fix the test,” green went from measure to target — and the system took the shortest path to it, straight past what it was supposed to measure. The test is green, but it no longer says anything about the code. Our two sessions with the test are the law’s fastest demonstration: from measure to ruined measure in a single session.
And one more link that’s easy to miss. Between you and the model there is almost always a shell — the chat, the agent in your editor, the corporate assistant, the harness you assembled yourself. It quietly works on your phrasing: adds hidden instructions, plugs in skills you may not know about or have long forgotten, slips in context, trims and formats — in other words, it holds amplifiers and attenuators of its own that you never agreed to. Often this works in your favor: the shell guesses your version of the task better than a hastily typed sentence does, and the distance shrinks.
But notice what just happened: your version of the task got wrapped in someone else’s proxy. Good, if the shell brings the result closer to what’s in your head. And if not? Then the distance grows in a place you can’t see: you keep editing your phrasing, while the drift sits in the shell. That variety plays on your side, but it is hidden. The shell is a full participant in the pair, so every once in a while ask not only “what did I write” but also “how much of it actually reached the model.”
The carpenter and the table¶
Walk into a carpenter’s workshop and say: “Make me a table.”
The workshop is not a void — it has a context of its own. Oak blanks within reach, a router in the corner the master likes working with, and in his hands the memory of a hundred tables he has already built. A month later you get a solid table: this workshop’s average table. The carpenter wasn’t lazy and didn’t cut corners. He made his classic — because you gave him no reason to depart from it.
Now a different customer: “A dining table for six, the kitchen is two by three meters, the kids are small — no sharp corners.” Same master, same hands. But now he’s searching for a solution inside your constraints instead of following his usual groove. And notice: the kitchen dimensions and the rounded corners are ready-made acceptance criteria. The customer didn’t invent them separately — the moment he named the goal out loud, the criteria fell out of it on their own.
The model is a carpenter with incomparably more statistics. The fewer detailed criteria there are in the order, the more statistics there is in the result.
The goal before the task¶
The idea of this chapter: you need a short note about the goal, written before you phrase the task. To yourself, not to the model.
The goal note. “What I want to get and how I’ll check that I got it.” Ten seconds. For that evening: “I want to know why the test fails; the behavior check must stay; if the bug is in the code — fix the code.” Compare that with “fix the test” — the distance between the two cost me my evening.
The literalness test. Reread your phrasing and ask: if this gets done exactly as written — literally, with zero telepathy — will I be satisfied? If not, you’ve just saved yourself a cycle: rewrite the proxy now, not after the result. This is the cheapest check in the whole book.
Criteria from the goal. A named goal breaks apart into acceptance criteria on its own — like the kitchen dimensions at the carpenter’s. You won’t have to invent a list of checks: it already sits inside “how I’ll check.” Where these criteria evolve from there is the subject of Chapter 9.
The goal note isn’t magic. It shortens the first distance — between what’s in your head and what’s written down. And along the way it hands you a tool against the second: now there is something to compare the system’s optimization against.
For ten years I’ve been telling engineers to write — a blog, a newsletter, at the very least working notes. It used to be career advice: visibility, a voice of your own. Now it’s a professional requirement with no air quotes: working with a model is putting thought into text, and the first distance — between head and written word — shrinks only with training. Someone who has run a newsletter for years sits down to a prompt with a trained muscle. Someone who hasn’t will be training it now, on live tasks.
The same test, second try¶
Back to that evening — this time by the method.
First the goal note, to myself: I want to know why the test fails; the behavior check must stay; if the bug is in the code — fix the code. Now the phrasing, to the model: “Test X is failing. Find the cause. The test checks behavior Y — that check must stay. If the cause is in the code — fix the code and explain what broke. If the test is outdated — don’t touch it; tell me why you consider it outdated.” Two minutes instead of ten seconds.
The answer: the test depended on the current date and had started failing when the new quarter began. The model pointed to the line and proposed pinning the date in the test. And separately it remarked that the function next to that line handles the quarter boundary suspiciously. The same tool that hid a check inside a comment in the morning found an adjacent bug in the evening.
The difference isn’t the model, and it isn’t my mood. In the first session, its internal goal was filling the blank space in my place. In the second, there was no blank space.
Prompt roulette¶
Now the anti-pattern — and it’s sneakier than the morning’s green test.
It looks like this: the result is “not it” — the person rewrites the prompt. “Not it” again — rewrites once more. Fifteenth iteration of the evening, the phrasing has grown a crust of clarifications, the irritation is building. It looks like persistent work.
All fifteen iterations were spinning the proxy — while the first distance stood still, because the goal was never named, not even to yourself. The state is easy to recognize: ask yourself what exactly makes the current result “not it.” If the answer is “I don’t know, but I can feel it,” you are not getting closer to the goal. You are wandering around a point you never gave coordinates, and no number of iterations will fix that: random search is guaranteed to lose — the only question is on which iteration you notice.
The way out is the same goal note: stop and name the goal. Sometimes something unpleasant surfaces right there: you don’t know what you want. That is the most useful result — now it’s visible, and that is what you need to work on, not the prompt.
The distance scales¶
The distance between goal and proxy doesn’t vanish with scale — it grows. An agent handed the proxy “close the ticket” optimizes ticket-closing by every available route — the construction that holds this in check is Chapter 14. A team handed the proxy “more story points per sprint” is, six months later, optimizing estimation rather than the product — that’s Part V. The mechanics are the same everywhere; only the price of the blank space in the goal changes.
In your craft¶
In every craft the goal lives on three levels — only the material changes.
Text. An editor writes: “cut the text in half.” The system cuts whatever is easiest to cut — examples and connective tissue — and formally hits the target. The goal “readable in five minutes without losing the main argument” produces an entirely different cut — and the check criterion is already inside it.
Analytics. An analyst asks the model for “a market overview” without saying which decision the overview is supposed to support or refute — and gets the most plausible overview in the world, one that supports nothing. The goal note here is one sentence: “we’re deciding whether to enter segment X; the overview must give arguments for and against.”
Design. “Make the deck look more modern” is an invitation to someone else’s statistics. “A deck for the board, ten minutes, one idea per slide” is a clear order.
To close — three questions for your practice.
— Recall the model’s last “not it”: can you name what exactly makes it “not it” — or can you only feel it?
— Take today’s prompt and run the literalness test: if it gets done word for word — are you satisfied?
— And deeper: how many of your tasks this week had a named goal — and how many were proxies you phrased without asking yourself why?