Stop prompting your LLM to be correct. Make a checker prove it wrong.

TLDR: Prompt engineering to get correct output from an LLM is a treadmill. The output is correct until the model, the input, or the phase of the moon changes. A deterministic checker that grades the output and hands the failures back is a fixed asset that gets more valuable, not less. Build the checker, not the perfect prompt.

The position

When an LLM produces structured output that has to be correct, the value is not in the generation. It is in the verification. Whoever owns the checker owns the quality. Whoever owns only the prompt owns a coin flip with good odds.

Most teams invest the opposite way. They pour effort into the prompt, the few-shot examples, the temperature, the system message, chasing a version that reliably produces valid output. Then the model updates, or a user sends input the examples did not cover, and the reliability evaporates. Back to the prompt.

What the industry does, and why

The default loop is: model emits something, a human eyeballs it, the prompt gets tweaked. It is seductive because the first tweak works. You add "make sure every output has a driver" to the prompt and the next ten generations comply. Ship it.

It is seductive for a real reason: prompting is fast and needs no engineering. You are editing English, not writing a verifier. For a demo, that is the right call.

The problem is that a prompt is a probabilistic nudge, not a guarantee. It shifts the distribution of outputs toward correct. It does not make incorrect outputs impossible. At scale, "usually correct" means "a steady stream of wrong ones," and you have no mechanism that catches them, because your entire quality strategy was the nudge.

Why it fails for this problem class

We generate electrical schematics with an LLM. Ask it to wire a pushbutton through a gate to a transistor and it produces plausible-looking output. Plausible is not correct. It will tie two gate outputs to one node, or wire a part backwards, or short power to a signal. These break real electrical rules, and no amount of prompt text reliably prevents them, because the model does not simulate the circuit. It pattern-matches.

You could keep enriching the prompt. "Never connect two outputs. Respect polarity. Ensure every net has a driver." Each rule helps a little and none of them holds. The model is not checking; it is guessing more carefully.

The output is unverifiable by construction if the only thing standing between it and the user is more instructions to the guesser.

The better approach

Build a deterministic checker and put it in the loop. In our case that is an electrical rule engine: it walks the generated graph and reports every violation, two outputs on a net, a driverless net, a reversed polarity, a power-to-signal short. It does not guess. It computes.

Then the loop changes shape. The model generates. The checker grades. If the checker finds violations, they go back to the model as specific, concrete corrections: "net 4 has two drivers, fix the wiring." The model re-plans against real findings instead of vague instructions. Generate, verify, repair.

The checker is the asset. When a better model ships, it does not obsolete the checker; it just feeds it higher-quality candidates that still get graded. The checker's value compounds. The prompt's value resets with every model release.

What you give up

A real checker is more work than a prompt. You have to encode the rules of your domain in code that runs, and getting them right is its own project. Our checker had a subtle bug where it silently checked nothing for a whole cycle, which is a failure mode a prompt cannot have. A verifier you trust and that is wrong is more dangerous than no verifier. So you also have to verify the verifier, with tests that assert a known-bad input produces a known finding.

That is genuine cost. You are trading a five-minute prompt tweak for an engineering investment.

When the common pattern is right

If the output does not have to be correct, prompt away. Creative writing, brainstorming, first drafts, anything a human reviews before it matters, does not need a deterministic grader. The nudge is the whole job.

The checker earns its cost precisely when wrong output is expensive and a human cannot cheaply tell right from wrong by looking. A schematic that violates Kirchhoff's laws looks fine to most people and fails in hardware. That is exactly the case where you stop tuning the guesser and start building the grader.

The one line

The scarce thing is not generation. Any model generates. The scarce thing is knowing the output is correct without a human redoing the work. Own the checker, and the model becomes a component you can swap. Own only the prompt, and you are on a treadmill that resets every release.