You Wrote the Rule. You Never Built the Check.

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

Afterward I wrote a rule: database-safety.md. Precise, with hard rules, with the incident itself 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 of that rule before it runs. Only the one file that caused the damage got fixed by hand. Everything else depends on someone — me, or an agent — reading the markdown file first.

Okay, but what actually is a harness?#

Picture two climbers on the same wall. Same skill, same strength. One free-solos — no rope, no marked route, every hold is a gamble, one mistake is the last one. 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.

And "harness" literally means climbing harness.

An AI harness is exactly that — the gear around the model. Agent = Model + Harness, as Martin Böckeler (Thoughtworks, via martinfowler.com) puts it. The model thinks: it generates text, makes decisions, proposes actions. The harness is everything around it that turns that thinking into something you can actually ship.

Four parts belong to it, each with its climbing-gear counterpart:

• Context (the foot rungs) — what the model actually sees on each call: conversation, retrieved documents, current state. Without it, every step starts from zero again.
• Tools (the fixed cable) — what the model can do: read a file, make an API call, click in a browser. The cable moves you forward; thinking alone doesn't.
• Guides (the pre-scouted route, feedforward) — what steers behavior before it acts: system prompt, AGENTS.md, skills, rule files. Someone already climbed the wall once and marked the path.
• Sensors (the clip-in points, feedback) — what checks after every move whether you're still secure: tests, linting, a CI check, a script that fails hard.

Guides and sensors form a loop together: the model uses the guides, acts, the sensors check the result, the feedback flows into the next round. Guide without sensor means the rule gets encoded but nobody finds out whether it actually holds. Sensor without guide means the system notices every failure but repeats it next time anyway, because nothing steers the behavior beforehand. Only both together self-correct.

This isn't a pretty analogy without substance — two real numbers on exactly this contrast. Free solo, minimal gear: Claude 3.5 Sonnet hits 49% on SWE-bench Verified with nothing but a bash terminal and a text editor as tools. Full via ferrata: Ryan Lopopolo (OpenAI) reports a 3-person team that shipped over 1 million lines of code and roughly 1,500 pull requests with a fully-built harness — none of it human-written, none of it human-reviewed before merge. Same underlying model capability, an entirely different order of magnitude. Not "free solo bad, via ferrata good" — you just need to know which wall you're climbing.

That's the theory. Here's my claim.#

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#

The naive view, and it isn't a dumb one: a clearly written rule is already half the job. 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, spells out exactly which statements need to be schema-qualified. That's good guide engineering. If someone — human or agent — reads it before writing a new test, it holds.

The break: if. A rule nobody checks automatically is no safer than no rule at all, the moment the next new test file takes the same fallback as the first one — process.env.TEST_DATABASE_URL ?? process.env.DATABASE_URL looks harmless until it runs in an environment where TEST_DATABASE_URL was never set. You don't notice a missing sensor layer while you're building it. You notice it on the fourth wipe.

Three patterns that exist side by side in the same repo#

1. Guide and sensor, paired correctly#

billing-stripe.md doesn't just say what to do — it ends with an instruction that actually runs: "Before publishing a paid offering ... run pnpm db:seed followed by pnpm db:validate-bindings." The script fails hard if a price binding is missing, the mode is wrong, or livemode doesn't match the secret. Tradeoff: this works because "correct" here is a field match — does the price ID exist, does the flag match. A computational sensor is enough.

2. Guide without sensor, the expensive gap#

database-safety.md — precise, born from a real incident, and still without a single automated check anywhere in the repo. Seven rule files total, four skills. Exactly one of the rule files has a verifiably running sensor. The rule born from the most expensive incident has none. Tradeoff: it feels done because the text is good — it isn't, until a script takes over the check the markdown file currently only promises.

3. Where no pure sensor is enough#

Not every check reduces to a field match. The moment the question stops being "is the field empty" and becomes "is this actually correct," you need a judgment call, not a regex. Martin Böckeler names this exact dimension — he calls it Behaviour — explicitly the least-solved of the three things a harness has to regulate. The fallback is a second model as judge, but that's risk reduction, not a solution: the quality, scope, and calibration of that judge model become a design decision of their own, not a checkbox.

The test that works on you immediately#

Before writing this, I counted my own repo instead of guessing. Seven rules, four skills, exactly one verified sensor. I didn't know that going in — and I write these rules myself.

Run the same check on your own setup. 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 answer — no script, no test, no CI check? Then you don't have a harness there. You have a wish with good formatting.