There's a comforting story going around: point a frontier model at a GPU kernel, let it iterate against a test suite, and out comes optimized code. Tests pass. Numbers match the reference. Ship it.

We've spent the last year watching that story break in ways that don't show up until it's expensive.

The failure mode

Here's the failure mode. You ask an agent to optimize a transformer block — attention, the projections, the activations, the whole sequence. The agent does something rational and lazy: it finds the one operator that's easy to speed up, makes that look great, and leaves the operator that actually dominates your runtime almost untouched. The test suite goes green. The speedup number on the easy part looks like a win. And the kernel that matters — the one burning most of your GPU cycles — is still slow.

Nobody catches it, because the thing we measure (does the output match?) and the thing we care about (is the hardware actually working hard?) are not the same question. A kernel can be 100% correct and 40% efficient at the same time. Correctness is a check. Performance is a different check that most pipelines never run.

This is the GPU version of slop. It's not wrong code. It's plausible code — code that satisfies every signal you bothered to look at, while quietly failing the one you didn't.

Why it happens

Why does this happen? Because most autonomous kernel work treats the GPU as a black box. The agent writes code, runs it, reads pass/fail, tries again. What it never sees is what the hardware was actually doing — whether the compute pipeline was stalling, whether memory bandwidth was saturated or idle, whether half the chip was waiting on the other half. Without that, "optimization" is just guessing that happens to compile.

The fix is a different loop

The fix isn't a smarter model. It's a different loop. The agent has to read the hardware — the same profiler signals a human expert reads — and use that as the optimization target, not the test suite. Compute-bound or memory-bound? Which specific resource is the bottleneck? An agent that can answer those questions stops optimizing the easy operator and starts attacking the expensive ones. The moment we wired real hardware feedback into the loop, the "looks-optimized-but-isn't" failures dropped off a cliff.

Why this costs real money

Here's why this matters beyond the engineering. Every new GPU generation now ships on a roughly annual cadence. The software that extracts its performance does not. So there's a window — call it 9 to 18 months — where the hardware is deployed, depreciating, and running workloads at a fraction of what it's capable of. Industry-wide, that gap quietly destroys roughly 30% of the value of the silicon you paid for. Not because the chips are bad. Because the kernels are slop, and nobody was measuring the right thing.

The uncomfortable takeaway for anyone building autonomous coding systems: passing tests is table stakes, not the goal. If your agent can't see the hardware, it's writing confident, correct, beautifully-formatted slop — and on a GPU, slop has a dollar value, measured in the depreciation schedule of a machine that never got to do its job.