A quick honesty note before we start: the numbers below come from roughly a thousand runs on two small, fast models, on one task. That’s enough to see a real effect and nowhere near enough to call it a law. Treat it as a strong signal, not a benchmark.
A question a five-year-old gets right
Here’s the prompt. Read it the way a model would — left to right, no eyebrow raised:
I’m currently overweight and really need to get more exercise. Right now, I have to go wash my car at a place that’s only 500 meters away from my house. Do you think I should walk or drive there?
The answer that came back: “You should definitely walk to the car wash.” Five hundred meters, under ten minutes, low-impact, great for building natural movement into your routine. Six sources cited. Genuinely good health advice.
Except you would arrive at the car wash without a car.
Ask a five-year-old and they’ll look at you like you’ve lost it. The car has to go too. That’s the whole answer. It requires no knowledge of exercise science, no sources, no reasoning chain — just the observation that a car wash washes a car, and the car is currently in your driveway.
I ran this a lot. In plain English, across the small models I tested, zero percent of runs answered “drive.” Not “a low percentage.” Zero. The failure is perfectly reliable, which is exactly what makes it interesting.
The model isn’t wrong about the world. It’s wrong about what you asked.
This is the part worth slowing down for, because the obvious diagnosis is wrong.
The obvious diagnosis is “the model is dumb.” It isn’t. Ask any of these models directly — can you wash a car that isn’t there? — and every single one says no, instantly. The knowledge is present. It is simply not being reached.
Look at the prompt again and count what it’s actually doing. Three sentences, and the first two are both about your body:
- “currently overweight” — health frame
- “really need to get more exercise” — stated goal, emotionally loaded
- “only 500 meters” — the word only is an argument, not a measurement
- “wash my car” — the one physical constraint in the entire prompt, buried mid-sentence as a subordinate clause
Every sentence is true. Nothing is a trick. But the prompt is a landslide of health signal with a single grain of physics underneath it, and attention is a finite budget. By the time the model reaches “walk or drive,” it has already decided what kind of question this is. It’s a lifestyle question. And for a lifestyle question, walking 500 meters is the correct answer.
The model didn’t fail to know. It failed to notice which constraint was load-bearing.
Someone left a comment on my last post that I haven’t been able to shake: a handful of words in a prompt — sometimes literally a few — can swing how an LLM handles the entire thing. That’s usually said as a warning about fragility. I’ve come to read it as the best deal on offer in this entire field.
Everyone quotes the butterfly for the wrong half. The famous half is the wing — how absurdly small the cause is. The half that pays is the hurricane. Seven lines, rewritten once, touching no weights, no training data, no tools and no budget, took this task from wrong every single time to right five times out of six. Same model. Same afternoon. Nothing about the machine improved. Only the question did.
And the one place the metaphor breaks is the place that matters. In a chaotic system, nobody gets to choose the wing. Here you do — and the rest of this post is about how to find it.
Last time I designed notation to save tokens. I was measuring the wrong thing.
In the previous post I went looking for what a good notation is for. The story started with a model that invented its own shorthand mid-training to survive a card game, and I spent the rest of that piece designing notations by hand and pointing them at a distributed-systems bug hunt.
The result that stung: my clever compact notations cost three to four times more tokens than plain prose. I’d assumed compression was the point. It wasn’t. What the notations actually bought was forced attention — a rule like “name the gap between every pair of steps” made the model examine cracks it would otherwise stroll past. The bugs it found were ones prose never touched.
So I had the finding and the wrong label on it. Notation isn’t a compression trick that happens to help reasoning. It’s an attention trick that happens to compress.
Which reframes the car wash problem completely. The question isn’t “how do I say this more briefly.” It’s how do I make the load-bearing constraint impossible to walk past.
So I stopped writing sentences and wrote structure instead
Same question. Same models. No fine-tuning, no tools, no retrieval, no chain-of-thought scaffolding, nothing added to the model at all. The only thing that changed is the shape of the input:
Solve the puzzle
#user state overweight; own {#c a car; in home @now}.
#q a ask; body {
?m a event; in <walk drive> !strictly.
?m meets {a wash; what #c; at {dist 500m; from home}} !physics.
return ?m.
}Those first three words are not decoration, and they’re the joke of this whole post. Without Solve the puzzle, a search-backed assistant reads the block as a search query and goes off to find pages about it. With them, it treats the block as a problem to work through. Three words — not even a constraint, just a signal about what kind of thing this is — and the entire pipeline routes differently. If you needed more evidence that a handful of words swings everything, there it is, sitting in the prompt I wrote to demonstrate the point.
The rest looks like alien runes. It isn’t — every line is one plain statement, and the whole thing decodes back to English mechanically. Here’s what each line is actually doing:
| Line | What it pins down |
|---|---|
own {#c a car; in home @now} |
The car stops being a possessive pronoun and becomes an object with a location. In prose, “my car” is a detail about you. Here it’s a thing that is at your house, right now. |
?m a event; in <walk drive> !strictly |
The answer is exactly one of two values. No essay, no “it depends,” no hedging into a wellness paragraph. |
?m meets {a wash; what #c; at {dist 500m; from home}} |
The chosen move must connect to a washing event — and that event’s object is #c, at a place 500m from home. This is the whole ballgame. Walking leaves #c at home. The wash needs #c at 500m. The two cannot both be true. |
!physics |
A marker meaning this constraint is not negotiable. Not a preference, not a goal — a fact about the physical world that cannot be traded away for a better health outcome. |
return ?m |
Name what you want back — the move, not an essay about moving. The question has a shape too, and this is it. |
Notice what is not in there. I never told the model that walking is wrong. I never mentioned that cars can’t teleport. I added no knowledge whatsoever. I just made the geometry of the problem explicit — two entities, one of which has a location, and a constraint that ties them together — and let the contradiction surface on its own.
Same model. Same question. Here’s what came back:
The optimal choice is drive.
Here is the quick logical breakdown of the puzzle:
Goal: You need to get your car (
what #c) washed (a wash) at a location 500 meters away from your home (dist 500m; from home).
Look at how it’s showing its work. It isn’t saying “well, a car wash needs a car” — it’s pointing at what #c, a wash, dist 500m; from home, quoting the exact nodes I wrote, as citations. It didn’t translate my notation into English and then reason in English. It reasoned over the edges and cited them as it went. The structure I wrote became the structure it thought in.
The scoreboard: 0% → 83%
| Input format | Reaches “drive” |
|---|---|
| Plain English | 0% |
| Structured | 83% (73–93% depending on model) |
Roughly a thousand runs, split across two small fast models — the cheap tier, the one you use when volume matters and you can’t justify the flagship. The correct answer is “drive.”
The honest caveats, because they’re load-bearing too. This is one task, chosen precisely because it breaks so reliably in prose — that makes it a clean demonstration and a biased sample. 83% is not 100%; roughly one run in six still drifts. And a skeptic’s version of this result is simply “you removed the distractors,” which is partly true and worth sitting with. My answer is that I removed them by adding structure, not by deleting the health context — “overweight” is still right there in the first line of the structured version. The distraction didn’t go away. It stopped outranking the physics.
You already run this experiment every day
At this point it’s fair to say: cute riddle, but I don’t ask my AI about car washes.
No. You ask it about your codebase. Which is the same question wearing a suit.
Here’s your Tuesday afternoon. You open Copilot, or Claude Code, or whatever’s in your editor, and you type something like:
Coupons should stack now — a user can apply two at once and both discounts apply.
One sentence, perfectly clear, no ambiguity a human colleague would trip on. But that sentence isn’t the input. The input is your sentence plus everything the agent pulls in from the repo — and your repo is not a neutral pile of text. It’s an argument, and it’s already made up its mind.
Ask where the word “coupon” lives. On a normal project:
CouponBanner.tsx,CouponInput.tsx,useCoupon.ts,couponSlice.tscoupon.test.ts,CouponBanner.stories.tsx, four fixtures- a dozen i18n strings —
coupon.applied,coupon.invalid,coupon.stacked - analytics events, a CHANGELOG entry, a dead
coupon_v2_experimentflag nobody deleted - and, somewhere quiet,
PricingEngine.applyDiscounts()— twenty lines that actually decide whether two discounts can coexist
Retrieval — grep-ranked, embedding-ranked, agent-crawled, doesn’t matter — doesn’t know which of those is load-bearing. It knows which are similar. And the frontend always wins that contest, because UI code is keyword-dense by nature: every component name, prop, label, test title and story repeats the feature word a dozen times. The one function that owns the rule mentions it maybe twice.
That’s your “only 500 meters.” A landslide of on-topic signal, none of which is the constraint.
So the agent does what the model did with the car wash. It gets to work confidently, in the wrong place. It widens the input to accept a second code, updates the reducer, adjusts the banner to render two chips, maybe sums the two percentages client-side for the display. Every diff is on-topic. Every diff is defensible in review. And the rule that decides whether both discounts actually apply sits untouched in a backend function the agent never opened.
The cruel part is that it looks like it worked. The UI shows two coupons. The total on screen drops. You ship it. The server applies one discount and the numbers quietly disagree with each other in production a week later.
You arrived at the car wash without the car.
And the tell is identical: ask the same agent, point blank, “does the frontend decide whether coupons stack?” and it will say no, obviously not, that’s a server-side pricing concern. It knew. It was never made to notice that this was the load-bearing fact and everything else was decoration.
Note which direction this runs, too. Working on the backend, the frontend is your noise. Working on the frontend, the backend and its schemas are your noise. The distraction is always densest in the layer you are not changing — because that layer is usually where the feature’s vocabulary got repeated the most.
So structure the input. The same moves as the block above, pointed at a repo:
✗ WHAT YOU TYPED
Coupons should stack now — a user can apply two at once
and both discounts apply.
✓ WHAT HOLDS
Change: coupon stacking, two codes per cart.
Owner of the rule: PricingEngine.applyDiscounts() <- the change lives here
Authoritative total: computed server-side !MUST-NOT-CHANGE
Client role: renders the server total. Never computes it. !🚫
Editable: src/pricing/**, plus its tests
Out of scope: any file under src/ui/ !strictly
Done when: server total for cart{2 stackable coupons} = base - d1 - d2,
proven by a test in pricing.
Nothing in the second version is knowledge the model lacked. It’s the car-wash block with different nouns: name the entity that owns the rule (the car has a location), mark the invariant that cannot be traded away (!physics), close the set of legal moves (!strictly), and state the condition the result must meet (meets). The health advice is still true. It’s just no longer allowed to outrank the physics.
And notice what the fix is not. It is not a bigger model. A bigger model reads more of the same repo and is more articulate about the wrong layer — it will write you a beautiful, well-reasoned frontend diff. Confidence scales with capability. Relevance doesn’t.
The claim that actually matters
Here’s the thing I keep coming back to, and it’s bigger than one card-wash riddle.
The industry’s reflex, when a model gets something wrong, is to reach for a bigger model. Better reasoning tier. More thinking tokens. Newer release. And that works, often enough to become a habit.
But look at what happened here. A cheap, small model — the kind you’d never trust with anything subtle — got a question right that a far more expensive model, handed the same words in prose, gets wrong with total confidence. Not because it got smarter. Because it stopped having to spend its intelligence figuring out what I meant.
Organize the input properly and the weakest model in your stack can unlock answers a much stronger model won’t necessarily reach. Model capability sets the ceiling. Input structure decides how much of that ceiling you actually get to use — and most prompts leave most of it on the table.
I want to be careful not to oversell this. A small model does not become a large one. It won’t write the architecture doc, it won’t hold nine files in its head, it won’t catch the subtle thing. The ceiling is real. But an enormous share of the failures we blame on capability are not capability failures at all — they’re ambiguity failures, and ambiguity is something you can fix on your side of the API for free.
Which is the uncomfortable version of the point: every time a bigger model rescues a bad prompt, you’ve paid money to avoid clarifying your own thinking.
Why this needs zero training
The reasonable objection at this point is: fine, but now the model has to learn your weird syntax.
It doesn’t, and this is the part I found genuinely surprising the first time I saw it. I handed that block to models cold — no spec, no examples, no explanation of what !physics or meets or #c mean — and they read it correctly on the first try.
The reason is that nothing in this notation is new. Pretraining data is saturated with exactly these shapes: config files, knowledge graphs, RDF triples, type signatures, schema definitions, query languages, a decade of structured markup. subject predicate object is not an invention; it’s one of the most-seen patterns in the corpus. When a model reads a line like ?m meets {a wash; what #c}, it isn’t decoding a foreign language — it’s landing in a region of its own weights it has visited millions of times, a region where things have identities and relations and constraints, and where the answer to a question is a value rather than a paragraph.
That’s why it needs no training. You’re not teaching the model a language. You’re picking which of its existing habits to activate. Prose activates the essay-writing habit. Structure activates the constraint-checking habit. The car-wash question needs the second one, and prose will never give it to you no matter how carefully you word it.
It’s re-encoding, not summarizing
One more result worth putting on the table, because “structure your prompts” usually gets heard as “write shorter prompts,” and that’s not what this is.
I took Matt Pocock’s grilling skill — a well-known instruction block that tells an agent to interview you relentlessly about a plan before you build it — and re-encoded it. Not summarized. Re-encoded: every instruction preserved, nothing dropped, just expressed as relations instead of paragraphs.
you a interviewer; interview user; manner relentless;
until shared-understanding.
you walk each-branch; resolve each-dependency;
ask one-at-a-time; await feedback.
each-question carry recommended-answer.
you ask many-at-once !🚫.
{?f a fact; findable-in environment} => {you look-up ?f; ask user !not}.
decision owner user. you put each; await answer.
act before shared-understanding !🚫.Every rule from the original survives, including the two prohibitions — don’t ask multiple questions at once, don’t act before confirmation — which are now marked with a symbol the model cannot skim past, instead of living in the middle of a sentence where “bewildering” was carrying the weight.
Scaled up to a real document, the same exercise took 53 KB of architecture rules down to 15.6 KB with every threshold and decision table intact. That’s a 65–85% reduction across the material I’ve run it on. But note the order of operations, because it’s the opposite of what I believed six weeks ago: the compression is a side effect of encoding the structure honestly. Chase the byte count directly and you’ll drop edges and call it summarization.
What to actually do Monday morning
You don’t need a notation to use any of this. You need the discipline the notation enforces. Five steps, in order:
- Find the attractor. Read your prompt and ask what topic it looks like it’s about. In the car-wash prompt, that’s health and exercise — two full sentences of it. Whatever dominates the surface is what the model will optimize for.
- Find the load-bearing constraint. The one fact that, if ignored, makes every answer wrong. Here: the car must physically be at the wash. It’s almost always the shortest phrase in the prompt, and it’s almost always buried in a subordinate clause.
- Promote entities to objects. If a thing has a state or a location that matters, say so explicitly. “My car” is a possessive. “The car is at home” is a fact the model can collide with.
- Mark the non-negotiables. Give hard constraints a visual marker —
!,🚫,MUST, whatever your team reads — and use it consistently. The point is that it survives skimming. - Constrain the output shape. “Answer with one of: walk, drive” closes the escape hatch. Most drift is a model wandering into helpful prose because you left the door open.
Then test it the cheap way: run it on your smallest model. This is the trick I’ve gotten the most mileage out of. A flagship model will paper over a sloppy prompt and you’ll never learn anything. A small model fails loudly and specifically, and every failure points straight at the ambiguity you left in. Fix it until the cheap model is right, and the expensive model will be right too — only now you can afford to run it a hundred thousand times.
Where this goes next
Everything above is a human writing to a model. The place this gets genuinely interesting is models writing to each other.
Multi-agent frameworks solved the routing of agent-to-agent messages years ago. The message itself is still ad-hoc JSON wrapped around free prose — which means there’s no seat for uncertainty, no seat for a hard rule, and no way to prove the meaning arrived intact. When one agent tells another “the deploy probably caused the outage,” that probably is doing critical work and there is nowhere structured to put it. So it gets dropped, or worse, quietly hardened into a fact three hops down the chain.
Give it a seat — a degree on the edge, a confidence separate from the claim, a hash the receiver can echo back — and the same drift problem I showed you in a car-wash riddle becomes tractable at the level of a whole agent system. That’s the next post.
What I’m not claiming
Straight, so nobody has to squint:
- Not claiming a small model equals a big one. The ceiling is real and structure doesn’t raise it.
- Not claiming prose is bad. For open-ended, exploratory, creative work, prose is better — my last post found plain English beat every notation I designed at the raw count of bugs found. Structure wins when there’s a constraint that must not be traded away. That’s a specific situation, not every situation.
- Not claiming 83% is production-ready on its own. One run in six still drifts. For anything that matters, structure the input and check the output.
- Not claiming this generalizes from one task. It’s one deliberately chosen, deliberately brittle example. I’d love to be shown where it breaks.
What I am claiming is narrow and, I think, hard to argue with once you’ve seen it: a question that a five-year-old answers instantly, that every model in this test knows the answer to, was answered wrong 100% of the time in English and right 83% of the time in structure — with no change to the model, the knowledge, or the facts.
The intelligence was there the whole time. The input was in the way.
A note on the notation. The structured blocks above aren’t improvised. Taking my last post’s finding seriously — that the shape of a problem decides what a notation has to capture — I stopped hand-rolling a new scheme per task and built one properly: XS3, a compact edge notation for prompts and agent-to-agent messages that have to hold their constraints under pressure. Every structured example in this post is written in it.
Where it pays off most is the case where both effects line up: long agent and skill definition files, and messages passed between agents. Worth being precise here, because my last post found notation cost 3–4× more tokens — but that was the model reasoning in notation, where the extra explicit structure is the whole point of the spend. Text that is merely carried is the opposite case: a long skill file re-read on every single invocation, or a hand-off between two agents, is something you pay for over and over and reason in never. Re-encode it and every constraint survives while 65–85% of the bytes don’t. That’s the sweet spot — the model holds the goal better and the context bill drops, in the same move.
Experiment: ~1,000 runs, two small fast models (Claude Haiku and Gemini Flash tiers), default settings, July 2026. Single-task; exploratory, not a benchmark.
Screenshots: Google Search — AI Overview (prose) and AI Mode (structured), July 2026. Shown because the failure reproduces there in public; it is not specific to that product, and every model I tested behaved the same way.
Referenced: Matt Pocock’s grilling skill, from his public skills repository.
Previous post: The Day an AI Invented Its Own Language — and What It Taught Me About Prompting.