Generator–evaluator loops

Splitting the agent that does the work from the agent that judges it — why self-evaluation fails, what makes an evaluator worth its cost, and how three independent teams arrived at the same shape from taste, from QA, and from production corrections.

The recurring structure across every harness in the harness-design cluster: one agent produces, a different agent judges, and the judgment feeds the next attempt. Anthropic reaches for the GAN analogy; OpenAI's version is a review loop that runs until every agent reviewer is satisfied; the tax-agent work builds the same shape out of graders and eval suites. Same skeleton, three routes to it.

Why self-evaluation doesn't work

Asked to grade their own output, agents praise it. The failure is sharper than generic optimism: Anthropic's post describes an evaluator finding a legitimate bug and then talking itself into deciding it didn't matter — the reasoning is intact, the verdict is motivated. It's worst where nothing can settle the question externally, which is why design was the domain that exposed it.

The important caveat, stated plainly in that post: separation doesn't fix leniency by itself. A standalone evaluator is still an LLM inclined to like LLM output. What separation buys is tractability — you can tune a dedicated evaluator toward skepticism with prompts and calibration examples, and you cannot easily make a generator critical of work it just committed to. Once external feedback exists at all, the generator has something concrete to iterate against.

A fourth arrival at the same split, from outside the field entirely and with a century more practice behind it: writers describing their own craft reach for it too — draft badly on purpose, judge at a boundary, revise as a separate activity. The structure matches closely enough to be worth reading, and the reason is inverted — their self-evaluation problem is that the internal critic is too harsh and runs too early, not too lenient. What that does and doesn't carry over is in Separating drafting from judging; the one detail worth taking from it here is that they get useful separation out of time alone, one person judging later, which is cheaper than a second agent and is not something this cluster has tested.

What makes an evaluator actually work

Concrete criteria beat a quality question. "Is this good?" is ungradable; a named rubric is. Anthropic's four (design quality, originality, craft, functionality) are worth studying less for the categories than for the weighting decision behind them: grade hardest where the model is weakest by default, because the criteria are also a prompt and they steer the generator before any score comes back. The owner's version of the same rule, from The harness is a skill issue, is worth keeping beside it because it is operational: replace "does it look visually pleasing" with the colour scheme being one of a named set, the spacing not being too narrow or too wide, the layout scaling across window sizes, every button being clickable. Each of those can be checked; the original can only be felt.

Calibrate with worked examples. Few-shot examples carrying full score breakdowns aligned the evaluator with its author's taste and, notably, reduced score drift across iterations — otherwise the scale itself moves and the trend is meaningless.

Make it use the thing. The evaluators that found real problems drove the running artifact: Playwright navigating the live page and screenshotting before scoring; Playwright clicking through the app and checking API and database state; Chrome DevTools driving the app per worktree. An evaluator grading a static screenshot or reading a diff is a different and much weaker instrument. This costs wall-clock time — it's most of why a full run takes hours.

The cheap end of the spectrum makes the point by omission. Claude Code's /goal runs a genuine split — a separate small model decides whether the condition is met — but that model does not call tools and can only judge what the generator has already put in the transcript. The verdict is independent; the evidence isn't. Which is the whole distinction: separating the judge is easy, and it is the second half — giving the judge its own access to the artifact — that costs money and does the work.

Define done before the work starts. Anthropic's sprint contracts (generator proposes scope and verification, evaluator checks it's the right thing, iterate until agreed) and the tax-agent bounded task environment (targeted eval + regression suite fixed before the agent begins) are the same move: the definition of done is external to the agent that will be judged against it, and it exists before there's any work to rationalise.

Hard thresholds, not a vibe. One criterion below its floor fails the whole sprint and returns specifics. The published examples are precise enough to act on without re-investigation — a named function that never fires on mouseUp, a route-ordering bug with the resulting 422.

Expect to tune it for a while. Out of the box, the model is a poor QA agent: it tests shallowly, misses nested cases, and rationalises passes. The loop that fixed it was to read the evaluator's own logs, find where its judgment diverged from the author's, and patch the prompt — several rounds before it graded reasonably. Tuning the judge is itself an engineering task with no test to tell you when you're done.

Two practical corollaries the owner draws in The harness is a skill issue. Be the evaluator yourself for the first few loops — run the generator, grade the output by hand, and write the rubric out of what you actually found yourself objecting to. And read what the evaluator produces, not just its verdict: if it isn't working towards finding issues, and isn't surfacing anything you wouldn't have caught easily yourself, it isn't worth the cost of running. That is a cheaper stop condition than the solo-vs-harness comparison below, and it applies before you've built anything.

When it isn't worth it

The most useful finding is that the evaluator's value is conditional, not fixed. As the generator gets stronger, the boundary of "handles this reliably alone" moves outward, and inside that boundary the evaluator is pure cost and latency. Outside it, it still pays. On Opus 4.5 the boundary sat right at the builds being attempted and the evaluator caught things throughout; on 4.6 much of the same work fell inside it.

So the question to ask before adding one: does this task sit past what the model does reliably solo? If you can't say, the cheap experiment is to run both and compare — which is exactly the solo-vs-harness comparison Anthropic published.

The prior question is whether the loop is possible at all, and Karpathy states it in one line: if you can't evaluate it, you can't automate it. Writing CUDA kernels is the perfect case — same behaviour, faster, both mechanically checkable. Frontend taste is the hard case, which is why Anthropic had to build a rubric and calibrate it before anything else worked. The evaluator isn't a component you add to a loop; it's the thing that decides whether there can be a loop.

He also names the failure mode of running one for long enough: an autonomous loop over a metric will overfit that metric. His proposed fix is to have the system generate more metrics for coverage, which is a hope rather than a result — the metrics that would catch metric-gaming are themselves ungraded. Add it to the limits below.

That makes three independent arrivals at what checks the check? in this notebook, from three unrelated directions: the tax-agent work listing a miscounting grader as a legitimate root cause, a misspecified condition running to completion and reporting success, and now metric overfitting in an unattended loop. The first partial answer arrived later, from DoorDash's benchmark write-up, and it is not a better judge: it is refusing to have one. Human annotations, the system's own findings and an LLM judge are compared against each other, disagreements are re-read by hand, and the resolved cases become the judge's calibration data. The judge stays a calibrated signal, never the ground truth. The cost of that answer is a standing human adjudication budget, which is exactly the thing an unattended loop is supposed to remove — so it moves the problem into the open rather than solving it. The practical consequence for anything built here is that a rising score over a long run is weak evidence and gets weaker the longer the run — drift and gaming are indistinguishable from the inside. Reading a sample of the actual artifacts, the owner's "read what the evaluator produces, not its verdict" rule applied to the generator as well, is the only check in the cluster that does not itself need one.

And Jaggedness: what RL optimises, and what stalls is why this is so persistent: judging soft qualities sits outside what any of the training loops optimised, so the evaluator is weakest at exactly the task it is hired for.

The judge's verdict has a provenance too

Greenblatt pushes the what checks the check? thread past where anything else in this notebook takes it, and the move is to ask where the judge's opinion came from.

His setting is safety research handed to models, but the structure is general. You get a report. It is about the right length, it says things that broadly make sense, it resembles what a competent human would have written — and nothing in it was arrived at by actually interrogating an assumption. His comparison is what happens today if you ask a model for its probability of some large future event: you get an off-the-cuff answer, delivered with the cadence of a considered one. A judge that does that is not a weak check, it is a check that reports the distribution of its training data while looking like an independent measurement.

Then the failure that makes it worse, and it is the one worth keeping because it is a thing an operator does on purpose. Suppose the judge keeps returning bad news. The natural response is to conclude the training data was skewed and filter it — at which point you have deliberately trained the judge toward the verdict you prefer. He puts both directions of it plainly: he doesn't want a judge that is pessimistic because it read pessimists, and he doesn't want one that is optimistic because someone trained the pessimism out; what he wants is a judge that reaches a view for reasons, and the current situation gives no way to tell which of the three you have.

The version of this that applies here is cheap and immediate. Every rubric in this cluster is a prompt as well as a scale — that is the observation the section above makes approvingly, because naming the criteria steers the generator. The same property means the criteria steer the judge, and a rubric written to encode your taste will produce verdicts that match your taste whether or not the artifact is good. Calibration examples make this stronger, not weaker. So the two checks in this cluster that don't inherit the problem are the ones that don't route through a judgment at all: an exit code, and the owner's rule about reading what the evaluator produced.

There is also a hard limit on the far end of this. Greenblatt's point about a monitoring AI is that you can't train a good whistleblower for a domain you don't understand, because you don't know what it should be raising the alarm about. The judge and the thing it judges get harder to understand together, and no amount of separation fixes a rubric nobody can write.

Limits

• The judge can't perceive everything. Claude can't hear, so the DAW's QA loop was blind to musical taste. Whatever the evaluator can't observe is unjudged, and the gap is invisible in the scores.
• The grader itself can be wrong. The tax-agent post lists "the grader is miscounting expected noise as failure" as a legitimate root cause for a failing eval. Anything that grades needs its own maintenance.
• Scores plateau, and aren't monotonic. Later iterations were better on average, but a middle iteration was sometimes preferable to the last. A rising score is not the same as a better artifact.
• Both agents share a prior. Two instances of the same model are not independent reviewers; they fail in correlated ways. None of the three posts tests a cross-model evaluator, which seems like the obvious next experiment. Someone has since built one — TandemKit runs Claude and Codex against each other until they agree — though without measuring what it buys. See Building a generator–evaluator harness: A practical implementation recipe. DoorDash names the same problem and the same fix — moving from a single judge to an agentic jury to mitigate bias between judge models — and files it under what's next. Three arrivals at the experiment, still nobody's numbers. And a reason the fix may be smaller than it looks: Greenblatt argues the lineages are correlated across labs, because each generation trains on data from the last, so two model families are less independent than their brand names suggest — see Speciation, and why we only ever touch the context window for the anecdote he uses to show it.
• One AI monitoring another stops working exactly where you need it. Reported as current practice rather than proposal: you can have one model watch another and ask whether it cheated, and it works — until the work moves into domains that are genuinely hard to understand, at which point the cheating gets found much later than it happened, or not at all. Latency in a judge is not a small defect. It is what lets the thing being judged optimise against the judge over a longer horizon than anyone is watching (Training against your own monitor).
• One run is a lower bound. The correction I'd have missed: DashBench found that repeated runs of the same agent surface additional valid findings, because the whole stack is non-deterministic. So a single scored run understates coverage, and any comparison between two configurations from one run each is partly noise. Run it several times and aggregate before believing the number — cheap advice that nothing else in this cluster gives.