You Wrote the Rule. You Never Built the Check.

pnpm test:integration wiped the public schema of my database. Four times, across four runs. The cause: a migration test dropped and rebuilt public in both beforeAll and afterAll, and fell back to DATABASE_URL whenever TEST_DATABASE_URL wasn't set. No race condition, no exotic bug — a ?? fallback in the wrong place, missed four times in a row.

I wrote a rule after that: database-safety.md. Precise, with the incident documented as the first paragraph, so nobody — not even an agent — loses the context. And yet: to this day, there isn't a single automated check in that repo that catches a future violation before it runs. Only the one file that caused the damage got fixed by hand.

What a harness actually is#

Picture two climbers on the same wall. One free-solos — no rope, every hold is a gamble. The other climbs a via ferrata: fixed cable, foot rungs, a carabiner clip-in point every few meters. Same climber. Only one of them reaches the top reliably. "Harness" literally means climbing harness.

Agent = Model + Harness, as Martin Böckeler (Thoughtworks, via martinfowler.com) puts it. The model thinks — generates text, proposes actions. The harness is everything that turns that thinking into something you can ship, and it splits into two halves:

• Guides (the pre-scouted route) — what steers behavior before it acts: system prompt, AGENTS.md, skills, rule files.
• Sensors (the clip-in points) — what checks after every move: tests, linting, a CI check, a script that fails hard.

Together they form a loop: the model uses the guides, acts, the sensors check the result, feedback flows into the next round. Guide without sensor means the rule gets encoded but nobody finds out whether it holds. Sensor without guide means every failure gets noticed but repeats anyway, because nothing steers the behavior beforehand.

Two real numbers make the gap concrete. With nothing but a bash terminal and a text editor, Claude 3.5 Sonnet hits 49% on SWE-bench Verified. With a fully-built harness, Ryan Lopopolo (OpenAI) reports a 3-person team shipping over 1 million lines of code and roughly 1,500 pull requests — none of it human-written, none of it human-reviewed before merge. Same model, an entirely different order of magnitude.

Almost everyone builds guides. Almost nobody builds the sensors — and you don't find out until it's too late.

Why a good rule feels like enough#

database-safety.md isn't a vague intention — it names the exact fallback that's banned, explains why schema isolation is enough in one case and not the other. That's good guide engineering, and it holds if someone reads it before writing a new test. The break is that "if": a rule nobody checks automatically is no safer than no rule at all, the moment the next test file takes the same shortcut as the first one. You don't notice a missing sensor layer while you're building it. You notice it on the fourth wipe.

Two patterns, one gap#

billing-stripe.md doesn't just say what to do — it ends with an instruction that actually runs: before publishing a paid offering, pnpm db:validate-bindings fails hard if a price binding is missing or livemode doesn't match the secret. That works because "correct" here is a field match — a computational sensor is enough.

database-safety.md has no equivalent. Seven rule files, four skills in the repo — exactly one has a sensor that verifiably runs. The rule born from the most expensive incident has none. It feels done because the text is good. It isn't, until a script takes over the check the file currently only promises.

Not every check reduces to a field match, either. The moment the question moves from "is the field empty" to "is this actually correct," you need judgment, not a regex — Böckeler calls this dimension Behaviour, the least-solved of the three things a harness has to regulate. The fallback is a second model as judge, which is risk reduction, not a solution: its quality, scope, and calibration become a design decision of their own.

The test that works on you immediately#

I counted my own repo instead of guessing: seven rules, four skills, exactly one verified sensor. Run the same check on yours. Take one rule, one skill, one AGENTS.md instruction. Don't ask what the model is supposed to do — ask how you'd know, six months from now, that it stopped working. No script, no test, no CI check that answers that? You have a wish with good formatting, not a harness.