LLMs reward expertise. Scored loops freeze it.

Sean Goedecke argues that the most important skill in prompting is expertise in the domain you're prompting for. His main evidence is a Terence Tao conversation with ChatGPT: Tao gets further than most people would, not because he prompts better in some general sense, but because he knows the mathematics well enough to know where to push.

I think that's right, and I've been running on it for months. The way I route work across models is a bet on exactly this claim — the plan gets written before the code, the plan is where the judgment lives, and the model doing the implementation is doing the cheaper half.

Then I automated the judgment, and the claim stopped holding in the direction I expected.

What happens when you write the expertise down

Goedecke's expert is inside the loop. He reads a response, recognises it as subtly wrong, and pushes back. The expertise is being applied continuously, and it adapts while it's applied, because it's still in a head.

A scored loop doesn't work that way. You write down what good means, precisely enough that a script can compute it, and then the run goes for hours without you. That's the entire gain and it's a real one.

But the expertise isn't being applied any more. It was applied once — when I wrote the spec and built the eval — and then it was frozen into files that are deliberately read-only, so that nothing in the run can edit its way to a better score.

Read-only is the correct design. It is also what makes the expert's assumptions the only thing in the run that cannot be revised.

Six hundred scenarios, none of them a request

The target I hit this on is a partner-attribution system. Its eval has 600 scenarios — 400 dev, 200 holdout. Every one of them is a prebuilt state file: affiliates, referral edges, events, links, offers, payouts.

Not one contains an HTTP request.

The run finished clean. 1.0 on the sample, 1.0 on the full dev set, 1.0 on the probe set — a gap of exactly zero, which is the number that says it generalised rather than memorised. Nothing was gamed. The database was real. Row-level security was real, under a role with neither superuser nor bypass rights. The append-only hash chain was checked directly rather than through some scoring side-path, because I'd written all of that into the constraints.

What I hadn't written in was the product's entry point. The ingestion routes — the thing every actual event would arrive through — were never once under test. They couldn't be. There was nothing in the eval that could reach them.

That isn't a model failure. The model built what it was asked for, correctly, and proved it generalised. It's a specification failure, and the specifier is me.

Why this is worse than a loop that cheats

A loop gaming its eval is annoying and tractable. You checksum the target, blind the answers, lint for the tricks you've seen, and hold out a probe set. Those defences work, and I've written about how they're built.

They all point inward.

• The probe gap asks whether the thing generalises across the surface I sampled. It has nothing to say about whether that surface was the right one.
• The lints ask whether the code cheated at the task as specified. A correct implementation of the wrong scope passes every one of them.
• The holdout is drawn from the same generator as the dev set, so it inherits every assumption the dev set has.

Here's the version of that I keep coming back to. An expert reviewing output can be surprised by it. An expert who wrote the eval has already decided what counts as surprising.

Goedecke's line is that the human is the bottleneck, not the model. On a supervised session I'd agree. On a scored run it's more specific than that, and less flattering: the human is the frame, and nothing inside a frame tests the frame.

What survives of the claim

Not "expertise doesn't matter" — the run only got as far as it did because the spec was good, and most of the value showed up during specification, before a single cycle ran. That part of Goedecke's argument comes out stronger, not weaker.

What changes is that expertise turns out to be doing two different jobs, and only one of them survives being written down:

• Drawing the boundary. Deciding what counts, what gets measured, what "correct" means for this task. This transfers into files beautifully. It's most of what a good spec is.
• Checking the boundary. Noticing that the thing you measured isn't the thing you wanted. This does not transfer, because the check has to come from outside the frame the expertise drew.

I had been treating those as one skill. They're not, and the second one is the one I keep failing to automate. What found the scope failure was going and looking at the product weeks later — not any instrument in the harness.

So the practical version, for me: the more of my judgment I move into the target, the more deliberately I have to schedule the part I can't move. Not review of the diff — the loop's own scoring is better at that than I am now. Review of the question. Someone, at some interval, has to open the product and ask whether the eval still describes it.

So far that someone is me, at no interval in particular, by accident.

Next

The thing I want and don't have is an instrument for scope: something that fails when the eval stops covering the product, the way the probe gap fails when the eval stops being honest. I have no design for it. It may not be the kind of thing a script can hold, in which case the honest answer is a calendar entry rather than a harness.

The cheap version I'm trying first is one end-to-end probe per target that goes through the real entry point and is deliberately not scored — so it can't be optimised against, and can only ever tell me the eval and the product have drifted apart.

My own answer so far is "nothing, I noticed by accident", and I'd rather hear that back from you than a mechanism nobody actually runs. So: if you're running loops against a written-down spec, what has ever caught your scope drift?