Harness engineering

Verification and acceptance in a coding harness.

The agent cannot mark its own homework, and there is now published evidence rather than just a suspicion.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

Verification is the part of a harness that checks the agent's output before a human spends attention on it, and it is the single strongest predictor of whether an agent is worth using. Agents are unreliable judges of their own work: Anthropic documents that when asked to evaluate what they produced, agents tend to praise it confidently even when quality is obviously mediocre. The fix is separating the evaluator from the generator and wiring deterministic checks into the loop.

The self-evaluation problem

Anthropic's harness-design article states it plainly: when asked to evaluate work they have produced, agents tend to respond by confidently praising it, even when a human observer would call the quality obviously mediocre. That single finding invalidates the most tempting harness design, which is to ask the model whether it is finished. Their answer is architectural, separating a generator from an evaluator so the judging is done by something that did not write the code.

Computational checks first, always

Böckeler's split is the right ordering rule. Computational sensors, tests, linters, type checkers and structural analysis, are deterministic, run in milliseconds to seconds, and give reliable answers. Inferential ones, AI review and LLM-as-judge, are slower, more expensive and non-deterministic. Reaching for an inferential check where a computational one would do is paying more for a less trustworthy result.

Write sensor output for the model

The refinement worth copying is that a sensor is much more useful when its output is written to be consumed by a language model. A linter message that carries its own correction instructions closes the loop without a human in it. Böckeler describes this as a positive kind of prompt injection, which is exactly the right way to think about it.

The publish-state guard

A failure mode nobody else seems to document: after an acceptance check passes, an agent can still run something destructive against the very artifacts it just validated, and the passing result is undone with no record of why. Lucid Train blocks destructive commands against touched artifacts once a check has passed, unless the model supplies an explicit override together with new failing evidence. The guarantee is that a green result stays green unless something demonstrates otherwise.

Isolation is part of verification

Where a failed attempt lands decides how many attempts you are willing to allow. Lucid Train runs dispatched sub-agents in isolated git worktrees and applies the diff back on success, so a bad attempt is discarded rather than reverted, and speculative work costs nothing to abandon.

Harnessability

Böckeler's uncomfortable observation is that not every codebase is equally amenable to this, and the harness is most needed where it is hardest to build. A greenfield service can bake in the checks; a legacy monolith with slow flaky tests and no type coverage resists exactly the verification that would make an agent safe on it. That is a real constraint on where agentic coding pays off, and it is not a tooling problem.

Checks by cost and reliability

CheckTypeSpeedReliability
Type checkerComputationalMillisecondsDeterministic
Linter with model-readable outputComputationalSecondsDeterministic
Unit testsComputationalSecondsDeterministic if not flaky
Structural or architecture fitness checksComputationalSecondsDeterministic
Dependency auditComputationalSecondsDeterministic
AI code reviewInferentialTens of secondsNon-deterministic
LLM as judgeInferentialTens of secondsNon-deterministic, biased toward praise
Human reviewHumanMinutes to hoursThe scarce resource
FAQ

Questions

Can an agent review its own work?

Not reliably. Anthropic documents that agents asked to evaluate their own output tend to praise it confidently regardless of quality, which is why separating the evaluator from the generator is a structural fix rather than a preference.

What should run first, tests or AI review?

Tests, always. They are deterministic, fast and cheap, and an AI review of code that does not compile is wasted spend.

What is a publish-state guard?

A rule that blocks destructive commands against artifacts an acceptance check has just validated, unless an explicit override is supplied with new failing evidence. It stops a passing result being silently undone.

Why do sub-agents run in git worktrees?

So a failed attempt is discarded rather than reverted. When abandoning an attempt is free, you can afford to let the agent try things.

Related