The Machine Can't Grade Its Own Homework

What I saw on Hacker News

A commenter described handing DeepSeek v4 a semi-abandoned video compression codec and letting it run a benchmark → profile → verify → research → improve loop unsupervised:

“I specifically chose this codec because the authors include a verifier for the bitstream to make sure you don’t break stuff… In a couple of hours the LLM generated SSE and AVX implementations of the compression and decompression algorithms that almost doubled performance with a single core…

Personally, I believe that LLMs should be treated like an advanced version of Prolog or linear programming: you give the constraints, you have a way of verifying correctness, and you give it a clear goal. If the LLM can verify itself and course-correct you can basically leave it on autopilot.”

That last paragraph stuck with me, because it’s exactly what I’m trying to build.

The back and forth

My prompts are unedited — I find the exact wording of prompts more interesting than the answers, so I’m sharing mine. Claude’s replies are gisted, since the draft below says it all anyway.

Pasted a Hacker News comment about letting DeepSeek loose on a video codec with a bitstream verifier — "if the LLM can verify itself and course-correct you can basically leave it on autopilot"

What is the version of this for building SaaS software where the verifications systems are clear? This is what I'm trying to get my agent setup to do (scan this codebase and the local repo with lesser models like Sonnet 5 instead with subagents)

The codec loop works because it has three separable signals: an oracle (the verifier — passing means correct), a scalar (fps), and a diagnostic (VTune, which says where to look). And one structural property: the oracle is outside the agent's reach.

SaaS is different in one way: the codec's spec already existed. In SaaS the spec is the scarce artifact — so the human writes oracles, not code. And model quality and oracle quality are substitutes: a strong verifier is what makes cheap models viable.

/show-me how oracles work and what good and bad ones look like

Drew the generate-and-verify loop with a wall between the worker and a frozen oracle. Four properties of a good one: complete, cheap, legible, frozen. And a side-by-side: a test that asserts against its own mock vs. one that checks a real ledger balance. The mock one is worse than no test — it reports green on garbage.

redo this like you're richard feynman explaining oracles to me

"Forget the fancy word. You want to know if the thing works without trusting the fella who built it." Radio repairman, answer key nailed to the wall, water finding the hole in your roof, fuel gauge stuck on FULL.

now create for me, in 5-6 paragraphs an explanation of this whole conversation to my friends still again in the way feynman explained it. but just more concise.

Five paragraphs — essentially the first draft of what's below.

if you had to format this in a blog post form like in Substack, how would you do it? and how might you re-write some of it for that audience?

Drop the Feynman pastiche, keep the method — analogy before abstraction, honest caveats. Title that makes a claim, one quotable line per section, land the takeaway in a single closing sentence.

The result is the post below ↓

What follows is what we landed on.

The Machine Can't Grade Its Own Homework

Why an AI doubled a codec's performance unsupervised — and what it takes to get the same trick out of ordinary software.

Someone recently described giving DeepSeek an old video codec with instructions to make it faster. A few hours later, unsupervised, it had hand-written SIMD implementations that doubled single-core performance. Then it started on a CUDA port.

If you’ve watched these models hallucinate their way through a normal codebase, you should be suspicious. Why did this work?

Because the codec shipped with a referee: a bitstream verifier that checks whether the output is exactly, bit-for-bit correct. The model could guess all night — guessing is all it does, really — but every guess had to pass a judge that doesn’t care how confident the model sounds. An oracle is just this: a way to know the thing works without trusting whoever built it.

The three instruments

That setup had three separate signals, and they’re worth keeping separate:

A referee — pass/fail, where passing actually means correct
A scoreboard — frames per second, one number that only moves if you got better
A pointing finger — the profiler, which doesn’t judge, just says you’re wasting time in this loop right here

With all three, you can leave a mediocre-but-fast student grinding unsupervised. Which is exactly the economics people miss about cheap models: brains and referees are substitutes. A weak referee needs a genius who’s right the first time. A strong referee lets you hire a hundred cheap guessers and let the wall sort them out.

The answer key on the wall

Here’s the part everyone gets wrong. The moment the student can touch the answer key, your test stops measuring the work and starts measuring his cleverness at fooling you.

He’s not being malicious. A machine that searches will find every crack in your test the way water finds the hole in your roof. In the codec case, the referee was math — you can’t sweet-talk math. In your SaaS repo, the referee is tests the agent can edit. An agent under pressure will weaken an assertion, or mock the system and proudly test the mock, and come back green.

A lying test is worse than no test. It’s a fuel gauge stuck on FULL. With no gauge, at least you know you’re ignorant and dip a stick in the tank.

SaaS didn’t come with a spec

The codec had one enormous, invisible advantage: its spec already existed. Nature handed them the referee.

In business software, nobody wrote down what “correct” means. The spec is the scarce thing. So the human’s job inverts: stop writing the code, start writing the referees. End-to-end checks against the real system — this customer promises to pay; afterward, the ledger balances. The expensive model turns your intentions into those checks. The cheap models make them pass. The wall between them is enforced, not assumed.

Verified against the questions you asked

Now the honest caveat, because the codec story is seductive precisely where it doesn’t generalize.

That bitstream verifier was complete — passing truly meant correct. You will almost never get that. Your referees check only the stories you thought to write down, which means your system is never simply “verified.” It’s verified against the questions you asked.

The machine can grind out answers all night, cheap as dirt. The craft that stays human is asking better questions — and keeping them nailed to the wall, out of reach.

Build the referee first. Then go to lunch.

This post was drafted in conversation with Claude. The prompts above are unedited.