The book I wrote because “harness” meant four different things

A developer wrote 'Harness Engineering: Building Reliable Systems Around Non-Deterministic Agents' to address the inconsistency of coding agents across different repositories. The book teaches techniques to narrow variance in agent output through deterministic input, output, and recovery, turning trust from a vague concern into a measurable metric.

You’ve probably felt this. You point the same agent at two of your repos with the same lazy prompt, and one gives you a tight change you can review over coffee while the other hands back a sprawling PR that quietly broke something three files away. Same model, same day. Different repo. That gap is the whole reason I wrote Harness Engineering: Building Reliable Systems Around Non-Deterministic Agents https://leanpub.com/harness-engineering . It’s out, it’s long, and this is the pitch: what it covers, what it’ll teach you to do, and why it’s worth the shelf space. A coding agent is non-deterministic by design. It also writes faster than your team can socially enforce its standards. A human writes a hundred lines a day; an agent writes thousands, and review still moves at human speed. Most of what it writes lands before anyone reads it carefully. And it inherits whatever’s already in the repo and amplifies it; the agent doesn’t change your standards, it enforces them, so the lower the standards, the more enforcement you get. You can’t make the model deterministic. So make the work around it deterministic. That’s the wager the whole book rests on. Reliability isn’t “the agent never varies” — it’s variance that stays inside a band you can read, debug, and ship . You narrow that band three ways: narrow the input scope plus acceptance criteria that can actually fail , narrow the output gates that reject anything outside the band , and narrow the recovery decide the next move after a failure before the failure happens . Here’s the part that turns it from craft into a decision a business can sign off on: every bit of determinism you add moves the trust boundary. The question stops being “do I trust the model?” you never fully will and becomes “how much unreviewed agent output am I willing to ship, and behind which gates?” That’s not a vibe. That’s a number a team can own. The book’s job is to give you the levers to set it where you want it, on purpose. The charter is everything you author to say how the agent should behave, and it’s the bulk of the book. This is where most teams have the most slack and the fastest wins. You’ll learn to write a lean CLAUDE.md — under two thousand words, because a bloated one is just token budget you’re setting on fire. You’ll tier your rules into iron laws, golden rules, and preferences so the agent knows what’s non-negotiable and what’s taste. You’ll build an ontology so one term means exactly one thing across the repo, because the fastest way to get inconsistent output is to let “job,” “task,” and “run” all mean the same thing in three files. And you’ll get honest about a trap I see constantly: aspirational rules teach the agent to lie. A CLAUDE.md that describes a codebase you wish you had is worse than none because it makes the agent confidently obey instructions the rest of the code contradicts. The book covers the Claude primitives directly — CLAUDE.md, rule files, skills, sub-agents, hooks, and MCP servers — and, more usefully, when to reach for which. A skill and a sub-agent solve different problems; a hook and a gate live at different points in the loop. I keep the stock harness what the tool actually gives you separate from my own conventions the rule tiers, the patterns I’ve found useful so you can tell what’s load-bearing from what’s just my preference. Every tool you hand the agent is a capability grant: grant the smallest one that closes the gap. And a limit that only logs is not a limit. When the stock agent can’t express your workflow, you build one. Part V is the engineering of that. The first fork is the shape of control flow: DAG or loop . A DAG is a fixed graph of steps: predictable, testable, easy to reason about, and rigid. A loop lets the agent decide when it’s done: flexible, and dangerous if the exit condition is soft. The book teaches you to pick deliberately and to engineer the loop when you need one: real termination conditions, budgets, and the recovery move baked in, so “the agent decides when it’s done” doesn’t mean “the agent runs until your bill does.” RAG gets treated as what it actually is — retrieval as a harness job, not magic. What you put in the context window, how you rank it, how you keep it from crowding out the instructions that matter. Feeding the agent more isn’t the goal; feeding it the right thing at the right token cost is. Then the operational spine: sandboxing and permissions, prompt injection inside a grant you’ve already given the attack people forget , model selection and routing so you’re not paying frontier prices for a formatting pass, cost and resource caps, and evals so you can measure the harness instead of hoping. It ends with building a coding harness end to end — there’s a from-scratch Go harness you can clone and read, because a harness you can’t read is one more thing you’re trusting blind. One agent is a harness problem. Many agents is orchestration, and it’s the last third of the book. This is where “vibe coding” breaks at team scale. The fix is intent contracts — a scoped statement of what a unit of work must do, with acceptance criteria that can fail. This can be a full spec, or one much smaller in scope. An acceptance criterion that cannot fail isn’t a criterion, it’s a wish. From there: the six phases a piece of work moves through and the interrupt protocol — when an agent hits ambiguity it doesn’t guess, it files an interrupt, the team-level version of raising an exception. You’ll cover graph engineering, a reconciler daemon that keeps the whole thing converging, and the two ends of the spectrum: dark factories fully automated, running unattended and lights-on factories automated but observable, with an audit trail you can read after the fact and proactive approval processes . The rule that keeps a factory honest: one that can edit its own gates has no gates. It’s grounded in real tools, so it’s not architecture astronaut stuff. It’s patterns that run. Every chapter ends with one copyable artifact: a checklist, a hook script, a worksheet, a code module. There’s a 30-day starter plan in the appendices. The template is what survives the read. The patterns aren’t mine. Tests, types, naming, bounded contexts, characterization tests, continuous delivery — they predate the agent and belong to Brooks, Parnas, Fowler, Evans, Beck, Feathers. What’s mine is the assembly: two named disciplines, a shared vocabulary that ends the “harness means four things” argument, a maintenance pattern, and a working tool. And the bet is built to last. If your reliability strategy depends on a specific model’s behavior, that strategy has an eight-month half-life. This one bets on the repo, not the model — so it doesn’t expire the next time a new model ships. It’s big: 62 chapters and a total of 866 pages. Not a weekend read. But it’s built to be used. The book is grounded in an engineering discipline: no vibes . The curator doesn’t stop writing code — the curator stops writing code the agent can write. If that reframe lands for you, this is the long version. Read it on LeanPub: Harness Engineering: Building Reliable Systems Around Non-Deterministic Agents https://leanpub.com/harness-engineering